From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun May 4 21:51:26 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10617 for ; Sun, 4 May 2003 21:51:11 -0400 (EDT) Received: (qmail 9397 invoked by uid 605); 5 May 2003 01:53:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9388 invoked from network); 5 May 2003 01:53:31 -0000 Received: from shitei.mindrot.org (203.36.198.97) by mail.netbsd.org with SMTP; 5 May 2003 01:53:31 -0000 Received: from mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 5BC8094226; Mon, 5 May 2003 11:37:23 +1000 (EST) Message-ID: <3EB5C3CF.6080105@mindrot.org> Date: Mon, 05 May 2003 11:52:15 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-au, en-gb, en, en-us, ja MIME-Version: 1.0 To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: Agent protocol References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Simon Tatham wrote: > byte SSH_AGENT_EXTENSION > string extension id > ... extension-specific data follows ... > > `extension id' will of course be allocated in the same way all other > SSH string ids are done: anything with an @ in it belongs to the > owner of the domain after the @. That way, I can safely invent > extensions to the agent protocol in a namespace I can be sure nobody > else will attempt to re-use for other purposes. > > My vision of this message type is that it can be sent from client to > agent _or_ from agent to client, depending on the extension. An > agent should not be the first to send it, so a client can rely on > not seeing strange unexpected extension messages in response to its > requests; but if the client sends an extension message, the agent > might need to respond with other extension messages if no existing > response message is appropriate. I strongly support an extension mechanism along such lines. We have generic extension mechanisms in place thoughout the protocol, so why not here? -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 5 18:12:12 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18251 for ; Mon, 5 May 2003 18:12:11 -0400 (EDT) Received: (qmail 7187 invoked by uid 605); 5 May 2003 22:15:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7180 invoked from network); 5 May 2003 22:15:03 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 5 May 2003 22:15:03 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18159; Mon, 5 May 2003 18:09:07 -0400 (EDT) Message-Id: <200305052209.SAA18159@ietf.org> To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: The IESG SUBJECT: Last Call: Using DNS to securely publish SSH key fingerprints to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 05 May 2003 18:09:07 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list The IESG has received a request from the Secure Shell Working Group to consider Using DNS to securely publish SSH key fingerprints as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-19. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-04.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 9 11:18:05 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19829 for ; Fri, 9 May 2003 11:18:04 -0400 (EDT) Received: (qmail 16416 invoked by uid 605); 9 May 2003 15:21:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16401 invoked from network); 9 May 2003 15:20:57 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 9 May 2003 15:20:57 -0000 Received: by xanthine.gratuitous.org with local; Fri, 09 May 2003 11:20:38 -0400 From: "Joel N. Weber II" To: ietf-ssh@netbsd.org Subject: comments on section 3.1 of draft-ietf-secsh-architecture-13 Message-Id: Date: Fri, 09 May 2003 11:20:38 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list I object to the text of section 3.1 of draft-ietf-secsh-architecture-13, in that it claims that there are only two possible models for verifying host keys. This is wrong; there is one ssh server I use regularly which I either log in to using Kerberos to verify the server identity, or using an OpenPGP host key to verify the server identity, neither of which is discussed in the architecture document. I would like to propose changing this existing text: Two different trust models can be used: o The client has a local database that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure, and no third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain. o The host name-to-key association is certified by some trusted certification authority. The client only knows the CA root key, and can verify the validity of all host keys certified by accepted CAs. The second alternative eases the maintenance problem, since ideally only a single CA key needs to be securely stored on the client. On the other hand, each host key must be appropriately certified by a central authority before authorization is possible. Also, a lot of trust is placed on the central infrastructure. replacing it with this text: Several different trust models can be used: o The client has a local database that associates each host name (as typed by the user) with the corresponding public host key. This method requires no centrally administered infrastructure, and no third-party coordination. The downside is that the database of name-to-key associations may become burdensome to maintain. o The host name-to-key association is certified by some trusted certification authority. This can be done using X.509, in which case the client only knows the CA root key, and can verify the validity of all host keys certified by accepted CAs. Another option is a symmetric cryptography based system such as Kerberos, in which case the client only knows a secret shared with the trusted certification authority, and can verify the validity of all host keys certified by the kdc. Using a trusted certification authority eases the maintenance problem, since ideally only a single CA key needs to be securely stored on the client. On the other hand, each host key must be appropriately certified by a central authority before authorization is possible. Also, a lot of trust is placed on the central infrastructure. Yet another option is the use of OpenPGP format certificates. The model used with OpenPGP is that anyone can be a certifying authority. This has the potential to reduce the amount of effort required for an appropriate trusted party to certify a host key, as well as greatly reducing the need to trust any single central authority. However, exchanging signatures to build the web of trust, and maintaining the database of which level of trust is placed in which keys, can be a significant amount of effort. Implementations SHOULD support as many of these options as possible, because different users and different sites have different organizational structures, for which different methods of verifying the host identity are most convenient. Also, I'd like to propose a paragraph added at the end: The documentation supplied with implementations SHOULD include a discussion of the problems of weak or nonexistent host verification, strongly encouraging the use of mechanisms that provide strong verification of host identity. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 13:39:09 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25171 for ; Mon, 12 May 2003 13:39:08 -0400 (EDT) Received: (qmail 22174 invoked by uid 605); 12 May 2003 17:42:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22167 invoked from network); 12 May 2003 17:42:04 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 12 May 2003 17:42:04 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1514627; Mon, 12 May 2003 11:42:02 -0600 Message-ID: <007401c318ad$a2cb57f0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Chris Lonvick" , References: Subject: Comments on the reviesed Security Section open issues. Date: Mon, 12 May 2003 11:40:53 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > 11.1.2 Data Integrity > > > > This protocol does allow the Data Integrity mechanism to > > be disabled. Implementors SHOULD be wary of exposing this > > feature for any purpose other than debugging. Users and > > administrators SHOULD be explicitly warned anytime the > > "none" mac is enabled. > > > > So long as the "none" mac is not used, this protocol > > provides data integrity. > > > > Because MACs use a 32 bit sequence number, they might > > start to leak information after 2**32 packets have > > been sent. However, following the rekeying > > recommendations should prevent this attack. > > The transport protocol [1] recommends rekeying after > > one gigabyte of data, and the smallest possible > > packet is 16 bytes. Therefore, rekeying SHOULD happen > > after 2**28 packets at the very most. > > > > 11.1.3 Replay > > > > This protocol binds each session key to the session by including > > random data that is specific to the session in the hash used to > > produce session keys. If the random data here (e.g., DH parameters) > > are pseudo-random then the PRNG should be cryptographically secure > > (i.e., its next output not easily guessed, even when knowing all > > previous outputs) and, furthermore, the PRNG should be seeded with some > > truly random inputs, or as random as can be available. In any case, > > the amount of entropy available to a given client or server sometimes > > may be less than what is needed to run the protocol, in which case > > either one must resort to PRNGs anyways or refuse to run the protocol. > > In practice implementors will generally rely on some PRNG. RFC 1750 > > [1750] contains more discussion on this. > > > > [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness > > Recommendations for Security", RFC 1750, December 1994. > > > > > > The use of a MAC other than 'none' provides integrity and > > authentication. In addition, the transport protocol provides a unique > > session identifier (bound in part to pseudo-random data that is part > > of the algorithm and key exchange process) that can be used by higher > > level protocols to bind data to a given session and prevent replay of > > data from prior sessions. For example, the authentication protocol uses > > this to prevent replay of signatures from previous sessions. Because > > public key authentication exchanges are cryptographically bound to the > > session (i.e., to the initial key exchange) they cannot be successfully > > replayed in other sessions. Note that the session ID can be made > > public without harming the security of the protocol. > > > > If two session happen to have the same session ID [hash of key > > exchanges] then packets from one can be replayed against the other. It > > must be stressed that the chances of such an occurrence are, needless > > to say, minimal when using modern cryptographic methods. This is all > > the more so true when specifying larger hash function outputs and DH > > parameters. > > > > [RJA: I imagine that a sequence number does help preclude replay attacks, > > [RJA: but I was hoping that someone else had actually done some analysis > > [RJA: that we could cite to justify the claim that this MAC combined with > > [RJA: this kind of sequence numbering would actually provide replay > > [RJA: attack prevention. If no one knows of something to cite here, I'm not sure what to do at this point? Baring someone stepping forward witht the requested citation, what should we do? I'd like to move forward. > > 11.1.4 Man-in-the-middle > > 2. Use an authentication method that is not vulnerable to > > man-in-the-middle attacks. For example, public-key authentication > > is not vulnerable to man-in-the-middle attack as long as the > > public-key of the server has been securely distributed to the > > clients before the first SSH connection is made. This is because *** see below *** > > the signature is made across data that is session specific. The > > session specific data between the attacker and server will be > > different between the client-to-attacker session and the > > attacker-to-server sessions due to the randomness discussed above. > > From this, the attacker will not be able to make this attack work > > since the attacker will not be able to correctly sign packets > > containing this session specific data from the server since he does > > not have the private key of that server. > > > > [RJA: Is this really true and sufficient ? Public key authentication is not vulnerable regardless of whether the server's public key has been securely distrubuted. Client --> MITM server / MITM client --> Server Client uses robust cryptographic PRNG, and correct implemenations, forcing the Session Identifier for the Client --> MITM Server to be unpredicatable. Server also uses robust cryptographic PRNG, and correct implementations, forcing the Session Identifier for the MITM Client --> Server Session to be unpredictable, and most importantly, different from that of Client --> MITM Server. Now, client uses its private key to sign the Client -> MITM Server session id, and sends that signature as authentication data. Becasuse MITM Client can't use the signature it just received (MITM client --> Server has a different Session Id to be signed), and it doesn't have access to the private key, it cannot proceed forward with authentication. --- Now, of course MITM Client can simply defer completing authentication with Server, and wait for client to request Agent forwarding. Then, using agent, obtain the signature it needs to complete the authentication with Server, and quickly bring MITM client --> Server state up to date with Client --> MITM Server state. Maybe the whole argument isn't worth including. > > 11.2.3 Local security policy > > > > Implementer MUST ensure that the credentials provided > > validate the professed user and also MUST ensure that > > the local policy of the server permits the user the > > access requested. > > > > In particular, because of the flexible nature of the SSH connection > > protocol, it may not be possible to determine the local security > > policy that should apply at the time of authentication, because the > > kind of service being requested is not yet clear. For example, local > > policy might allow a user to access files on the server, but not start > > an interactive shell. However, during the authentication protocol, it > > is not known whether the user will be accessing files or attempting to > > use an interactive shell, or even both. In any event, local security > > policy for the server host MUST be applied and enforced correctly. > > > > [Nico: What if no policy is available? Then there is nothing to enforce? Perhaps we should say, In any event, where local security policy for the server host exists, it MUST be applied and enforced correctly. and sprinkle a few 'if any' around judiciously. > > 11.3.3 X11 forwarding > > > > Another form of proxy forwarding provided by the ssh > > connection protocol is the forwarding of the X11 protocol. > > > > Implementors of the X11 protocol SHOULD implement the magic cookie > > spoofing, to prevent unauthorized use of the proxy. More information > > about the use of the X11 magic cookie may be found in many of the > > available manual references and implementation guides for X11. For > > example, viewing the manual page for "xauth" in BSD systems may be one > > place to start. > > > > X11 forwarding relies on end-point security. If end-point > > security has been compromised, X11 forwarding will allow > > any attack against the X11 server possible locally. > > > > Users and administrators should, as a matter of course, use > > X11 security mechanism to prevent unauthorized use of > > the X11 server. > > > > [RJA: Which "X11 security mechanism" is meant ? > > [RJA: Also, please add a citation for that mechanism. > > > > [JG: Well, I didn't have a particular one in mind. The > > [JG: advice is to use any X11 security mechanism. I'd > > [JG: be willing to remove the paragraph. > > [RJA: I'd like to keep text encouraging folks to use as much > > [RJA: security as they can. I'm not an expert on the security > > [RJA: properties of X11. I was thinking that there probably were > > [RJA: some specific security mechanisms (e.g. my vague recollection > > [RJA: of the MIT-magic-cookie hack noted above) that we ought > > [RJA: to mention and cite. I would suggest the following two citations for this section: [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, Feburary 1992. and draft-ietf-secsh-connect-16.txt, section 4.3.1., "Requesting X11 Forwarding" - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 14:43:10 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27444 for ; Mon, 12 May 2003 14:43:09 -0400 (EDT) Received: (qmail 23079 invoked by uid 605); 12 May 2003 18:46:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23072 invoked from network); 12 May 2003 18:46:06 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 12 May 2003 18:46:06 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 14E4667106; Mon, 12 May 2003 15:11:01 -0400 (EDT) Date: Mon, 12 May 2003 14:45:44 -0400 Subject: Re: Comments on the reviesed Security Section open issues. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Joseph Galbraith" From: RJ Atkinson In-Reply-To: <007401c318ad$a2cb57f0$4d00a8c0@galb.vandyke.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, May 12, 2003, at 13:40 America/Montreal, Joseph Galbraith wrote: >>> [RJA: I imagine that a sequence number does help preclude replay > attacks, >>> [RJA: but I was hoping that someone else had actually done some > analysis >>> [RJA: that we could cite to justify the claim that this MAC combined > with >>> [RJA: this kind of sequence numbering would actually provide replay >>> [RJA: attack prevention. > > If no one knows of something to cite here, I'm > not sure what to do at this point? > > Baring someone stepping forward witht the requested > citation, what should we do? I'd like to move forward. Generic comment (applies to above and other places): I'd rather delete a claim that the WG can't clearly justify than have this document accidentally make a claim that later turns out to be inaccurate or misleading. >>> 11.1.4 Man-in-the-middle > >>> 2. Use an authentication method that is not vulnerable to >>> man-in-the-middle attacks. For example, public-key >>> authentication >>> is not vulnerable to man-in-the-middle attack as long as the >>> public-key of the server has been securely distributed to the >>> clients before the first SSH connection is made. This is >>> because > > *** see below *** > >>> the signature is made across data that is session specific. >>> The >>> session specific data between the attacker and server will be >>> different between the client-to-attacker session and the >>> attacker-to-server sessions due to the randomness discussed >>> above. >>> From this, the attacker will not be able to make this attack >>> work >>> since the attacker will not be able to correctly sign packets >>> containing this session specific data from the server since he > does >>> not have the private key of that server. >>> >>> [RJA: Is this really true and sufficient ? > > Public key authentication is not vulnerable regardless > of whether the server's public key has been securely > distrubuted. > > Client --> MITM server / MITM client --> Server > > Client uses robust cryptographic PRNG, and > correct implemenations, forcing the Session > Identifier for the Client --> MITM Server > to be unpredicatable. > > Server also uses robust cryptographic PRNG, > and correct implementations, forcing the Session > Identifier for the MITM Client --> Server Session > to be unpredictable, and most importantly, > different from that of Client --> MITM Server. Seems to me that we ought to note the criticality of the quality of the PRNG implementation in the Security Considerations section of the document. > Now, client uses its private key to sign the > Client -> MITM Server session id, and sends > that signature as authentication data. > > Becasuse MITM Client can't use the signature it > just received (MITM client --> Server has a different > Session Id to be signed), and it doesn't have access to > the private key, it cannot proceed forward with authentication. > > --- > > Now, of course MITM Client can simply defer completing > authentication with Server, and wait for client to > request Agent forwarding. Then, using agent, obtain > the signature it needs to complete the authentication > with Server, and quickly bring MITM client --> Server > state up to date with Client --> MITM Server state. > > Maybe the whole argument isn't worth including. I'd go with that last sentence, particularly since the robustness of the PRNG is very implementation-specific. It is hard to get PRNGs correct in actual code, so it is not unlikely that one or more SSH implementations would not get it right. >>> 11.2.3 Local security policy >>> >>> Implementer MUST ensure that the credentials provided >>> validate the professed user and also MUST ensure that >>> the local policy of the server permits the user the >>> access requested. >>> >>> In particular, because of the flexible nature of the SSH >>> connection >>> protocol, it may not be possible to determine the local security >>> policy that should apply at the time of authentication, because >>> the >>> kind of service being requested is not yet clear. For example, >>> local >>> policy might allow a user to access files on the server, but not > start >>> an interactive shell. However, during the authentication >>> protocol, it >>> is not known whether the user will be accessing files or >>> attempting > to >>> use an interactive shell, or even both. In any event, local >>> security >>> policy for the server host MUST be applied and enforced correctly. >>> >>> [Nico: What if no policy is available? > > Then there is nothing to enforce? > > Perhaps we should say, > In any event, where local security policy for the server host exists, > it MUST be applied and enforced correctly. > > and sprinkle a few 'if any' around judiciously. Those proposed edits seem reasonable to me. >>> 11.3.3 X11 forwarding >>> >>> Another form of proxy forwarding provided by the ssh >>> connection protocol is the forwarding of the X11 protocol. >>> >>> Implementors of the X11 protocol SHOULD implement the magic cookie >>> spoofing, to prevent unauthorized use of the proxy. More >>> information >>> about the use of the X11 magic cookie may be found in many of the >>> available manual references and implementation guides for X11. >>> For >>> example, viewing the manual page for "xauth" in BSD systems may be > one >>> place to start. >>> >>> X11 forwarding relies on end-point security. If end-point >>> security has been compromised, X11 forwarding will allow >>> any attack against the X11 server possible locally. >>> >>> Users and administrators should, as a matter of course, use >>> X11 security mechanism to prevent unauthorized use of >>> the X11 server. >>> >>> [RJA: Which "X11 security mechanism" is meant ? >>> [RJA: Also, please add a citation for that mechanism. >>> >>> [JG: Well, I didn't have a particular one in mind. The >>> [JG: advice is to use any X11 security mechanism. I'd >>> [JG: be willing to remove the paragraph. >>> [RJA: I'd like to keep text encouraging folks to use as much >>> [RJA: security as they can. I'm not an expert on the security >>> [RJA: properties of X11. I was thinking that there probably were >>> [RJA: some specific security mechanisms (e.g. my vague recollection >>> [RJA: of the MIT-magic-cookie hack noted above) that we ought >>> [RJA: to mention and cite. > > > I would suggest the following two citations for this > section: > > [SCHEIFLER] Scheifler, R., "X Window System : The Complete > Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd > edition.", Digital Press ISBN 1555580882, Feburary > 1992. > > and > > draft-ietf-secsh-connect-16.txt, section 4.3.1., > "Requesting X11 Forwarding" It turns out that the X11 cookie security has significant issues. A good reference for folks here to read might be: Wietse Venema, "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose, CA, July 1996. It is likely that the above paper can be downloaded from USENIX, http://www.usenix.org. I don't know the correct URL for that paper, so one would have to browse to find it. Also, if we reach back to 1997, there were other issues identified: http://lists.insecure.org/lists/bugtraq/1997/Sep/0062.html I'm not comfortable with the current text on X11, though I'm only one person... Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 15:18:24 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29640 for ; Mon, 12 May 2003 15:18:23 -0400 (EDT) Received: (qmail 12581 invoked by uid 605); 12 May 2003 19:21:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12573 invoked from network); 12 May 2003 19:21:20 -0000 Received: from netcore.fi (193.94.160.1) by mail.netbsd.org with SMTP; 12 May 2003 19:21:20 -0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4CJLB210923; Mon, 12 May 2003 22:21:12 +0300 Date: Mon, 12 May 2003 22:21:11 +0300 (EEST) From: Pekka Savola To: ietf-ssh@netbsd.org cc: jakob@crt.se, Subject: draft-ietf-secsh-dns-04 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, A few layman's (to SSH specs & DNS details) comments to the secsh-dns draft. Most of the comments should be easy to understand. In 2.4, I think the language must be much more specific what's required. "MUST .. unless" is not good, IMO. (looking back, you could also add a reference to RFC2434 in the IANA considerations section) --- draft-ietf-secsh-dns-04.txt Wed Apr 2 19:54:58 2003 +++ draft-ietf-secsh-dns-04.txt.new Mon May 12 22:12:30 2003 @@ -8,7 +8,7 @@ April 2, 2003 - Using DNS to securely publish SSH key fingerprints + Using DNS to Securely Publish SSH Key Fingerprints draft-ietf-secsh-dns-04.txt Status of this Memo @@ -125,14 +125,14 @@ saved locally and used for verification for all following connections. While some security-conscious users verify the fingerprint out-of-band before accepting the key, many users blindly - accepts the presented key. + accept the presented key. The method described here can provide out-of-band verification by looking up a fingerprint of the server public key in the DNS [1][2] and using DNSSEC [4] to verify the lookup. In order to distribute the fingerprint using DNS, this document - defines a new DNS resource record to carry the fingerprint. + defines a new DNS resource record, "SSHFP", to carry the fingerprint. Basic understanding of the DNS system [1][2] and the DNS security extensions [4] is assumed by this document. @@ -196,8 +196,8 @@ 2.4 Authentication - A public key verified using this method MUST only be trusted if the - SSHFP resource record (RR) used for verification was authenticated by + A public key verified using this method MUST NOT be trusted if the + SSHFP resource record (RR) used for verification was not authenticated by a trusted SIG RR. Clients that do not validate the DNSSEC signatures themselves MUST @@ -234,7 +234,9 @@ / fingerprint / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - +==> please use the more common textual representation, seems much more +natural +==> the picture is 74 chars wide --- not good! 3.1.1 Algorithm Number Specification @@ -319,7 +321,7 @@ replacing the corresponding SSHFP in DNS. If SSH host key verification can be configured to require SSHFP, - we can implement SSH host key revocation by removing the + SSH host key revocation by can be implemented by removing the corresponding SSHFP from DNS. As stated in Section 2.2, we recommend that SSH implementors provide -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 15:59:18 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01577 for ; Mon, 12 May 2003 15:59:17 -0400 (EDT) Received: (qmail 3383 invoked by uid 605); 12 May 2003 20:02:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3155 invoked from network); 12 May 2003 20:02:14 -0000 Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by mail.netbsd.org with SMTP; 12 May 2003 20:02:14 -0000 Received: from latte-wlan.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.9/8.12.9) with ESMTP id h4CK1tB4026201 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Mon, 12 May 2003 22:01:56 +0200 To: iesg@ietf.org Cc: ietf-ssh@netbsd.org Subject: Re: Last Call: Using DNS to securely publish SSH key fingerprints to Proposed Standard References: <200305052209.SAA18159@ietf.org> From: Simon Josefsson X-Payment: hashcash 1.2 0:030512:iesg@ietf.org:e3c72b6c39d5ebec X-Hashcash: 0:030512:iesg@ietf.org:e3c72b6c39d5ebec X-Payment: hashcash 1.2 0:030512:ietf-ssh@netbsd.org:83e12192fed0f052 X-Hashcash: 0:030512:ietf-ssh@netbsd.org:83e12192fed0f052 Date: Mon, 12 May 2003 22:01:55 +0200 In-Reply-To: <200305052209.SAA18159@ietf.org> (The IESG's message of "Mon, 05 May 2003 18:09:07 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-32.4 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) Sender: ietf-ssh-owner@netbsd.org Precedence: list Was it considered to allow for other security mechanisms to authenticate the SSHFP data, besides DNSSEC? The document says: 2.4 Authentication A public key verified using this method MUST only be trusted if the SSHFP resource record (RR) used for verification was authenticated by a trusted SIG RR. Clients that do not validate the DNSSEC signatures themselves MUST use a secure transport, e.g. TSIG [8], SIG(0) [9] or IPsec [7], between themselves and the entity performing the signature validation. This seem to require that DNSSEC is used by at least some entity. I believe this is an unnecessary restriction, and that SSHFP would be more useful if it the wording was changed to allow for any secure mechanism. The document may mention that it was designed for DNSSEC and that DNSSEC is the recommended way to authenticate data, but I believe it should not explicitly preclude other (secure) ways of authenticating the SSHFP data. Some scenarios that are precluded by the current text: * TSIG/IPSEC-protected query to authoritative server with SSHFP. * TSIG/IPSEC-protected query to trusted server with SSHFP. (The server may have received the data using a secure channel from the authoritative server.) * Using data from zone files received securely out of band. (E.g., via SSH, or by mail protected by CMS or OpenPGP, from the authoritative domain.) Thanks. (I searched the SSH mailing list but could not find anything related to this. I'd appreciate a pointer if this has discussed before.) The IESG writes: > The IESG has received a request from the Secure Shell Working Group to > consider Using DNS to securely publish SSH key fingerprints > as a Proposed Standard. > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@ietf.org or ietf@ietf.org mailing lists by 2003-5-19. > > Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-secsh-dns-04.txt From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 16:09:19 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01984 for ; Mon, 12 May 2003 16:09:18 -0400 (EDT) Received: (qmail 8371 invoked by uid 605); 12 May 2003 20:12:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8323 invoked from network); 12 May 2003 20:12:17 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 12 May 2003 20:12:17 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id 18E717FD06; Mon, 12 May 2003 23:11:56 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id 16A267FD05 for ; Mon, 12 May 2003 23:11:56 +0300 (EEST) Date: Mon, 12 May 2003 23:11:55 +0300 (EEST) From: Heikki Nousiainen To: ietf-ssh@netbsd.org Subject: Re: Comments on the reviesed Security Section open issues. In-Reply-To: <503EDCF3F59A474EBC2B140690DEF47A0C7BE5@fsusmail1.US.F-Secure.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Monday, May 12, 2003, at 13:40 America/Montreal, Joseph Galbraith > wrote: > >>> [RJA: I imagine that a sequence number does help preclude replay > > attacks, > >>> [RJA: but I was hoping that someone else had actually done some > > analysis > >>> [RJA: that we could cite to justify the claim that this MAC combined > > with > >>> [RJA: this kind of sequence numbering would actually provide replay > >>> [RJA: attack prevention. > > > > If no one knows of something to cite here, I'm > > not sure what to do at this point? > > > > Baring someone stepping forward witht the requested > > citation, what should we do? I'd like to move forward. > > Generic comment (applies to above and other places): > I'd rather delete a claim that the WG can't clearly justify > than have this document accidentally make a claim that later > turns out to be inaccurate or misleading. I for one believe replay protection is an important property for the protocol and I would like this claim to remain in the documents. IpSec AH uses sequence number with HMAC for replay protection (rfc2085), so does TLS (rfc2246). HMAC security considerations are discussed in rfc2104. The document describes security of the construct in general, and I believe the replay protection scheme is a small subset compared to that, given the so many bits an attacker can affect (sequence number, padding). How about "to our best knowledge"? > > Public key authentication is not vulnerable regardless > > of whether the server's public key has been securely > > distrubuted. > > [snip] > > Now, of course MITM Client can simply defer completing > > authentication with Server, and wait for client to > > request Agent forwarding. Then, using agent, obtain > > the signature it needs to complete the authentication > > with Server, and quickly bring MITM client --> Server > > state up to date with Client --> MITM Server state. > > > > Maybe the whole argument isn't worth including. In my opinion, this belongs into the agent spec, not here. [Don't do agent forwarding for the servers you don't trust.] > Seems to me that we ought to note the criticality > of the quality of the PRNG implementation in the > Security Considerations section of the document. I second that. Regards, Heikki Nousiainen From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 16:25:09 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02575 for ; Mon, 12 May 2003 16:25:08 -0400 (EDT) Received: (qmail 16810 invoked by uid 605); 12 May 2003 20:28:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16803 invoked from network); 12 May 2003 20:28:05 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 12 May 2003 20:28:05 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id DD6F367104; Mon, 12 May 2003 16:53:22 -0400 (EDT) Date: Mon, 12 May 2003 16:28:05 -0400 Subject: Re: Comments on the reviesed Security Section open issues. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-ssh@netbsd.org To: Heikki Nousiainen From: RJ Atkinson In-Reply-To: Message-Id: <3CA03ED9-84B8-11D7-B619-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, May 12, 2003, at 16:11 America/Montreal, Heikki Nousiainen wrote: > I for one believe replay protection is an important property for the > protocol and I would like this claim to remain in the documents. > > IpSec AH uses sequence number with HMAC for replay protection > (rfc2085), > so does TLS (rfc2246). > > HMAC security considerations are discussed in rfc2104. The document > describes security of the construct in general, and I believe the > replay > protection scheme is a small subset compared to that, given the so many > bits an attacker can affect (sequence number, padding). > > How about "to our best knowledge"? Does someone want to try to construct a rationale for the document about why folks believe the attempted replay protection actually works ? Barring that, maybe the words should be more tentative (edit to taste): Through the use of a sequence number and ... and ..., the SSH specification seeks to provide protection against replay attacks. ??? >>> Public key authentication is not vulnerable regardless >>> of whether the server's public key has been securely >>> distrubuted. >>> > [snip] >>> Now, of course MITM Client can simply defer completing >>> authentication with Server, and wait for client to >>> request Agent forwarding. Then, using agent, obtain >>> the signature it needs to complete the authentication >>> with Server, and quickly bring MITM client --> Server >>> state up to date with Client --> MITM Server state. >>> >>> Maybe the whole argument isn't worth including. > > In my opinion, this belongs into the agent spec, not here. [Don't do > agent forwarding for the servers you don't trust.] That would be OK with me. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 17:00:48 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04037 for ; Mon, 12 May 2003 17:00:47 -0400 (EDT) Received: (qmail 4853 invoked by uid 605); 12 May 2003 21:03:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4846 invoked from network); 12 May 2003 21:03:42 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 12 May 2003 21:03:42 -0000 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 05F486193; Mon, 12 May 2003 23:03:41 +0200 (CEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id A68991D99; Mon, 12 May 2003 23:03:40 +0200 (MEST) Date: Mon, 12 May 2003 23:03:40 +0200 (CEST) From: Jakob Schlyter To: Pekka Savola Cc: ietf-ssh@netbsd.org, wgriffin@tislabs.com Subject: Re: draft-ietf-secsh-dns-04 comments In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 12 May 2003, Pekka Savola wrote: > Most of the comments should be easy to understand. In 2.4, I think the > language must be much more specific what's required. "MUST .. unless" is > not good, IMO. thanks, I've integrated your changes. since this is only editoral changes, I assume we do not need another last call. > (looking back, you could also add a reference to RFC2434 in the IANA > considerations section) why? > @@ -234,7 +234,9 @@ > / fingerprint / > / / > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > +==> please use the more common textual representation, seems much more > +natural > +==> the picture is 74 chars wide --- not good! textual representation? please elaborate. jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 17:46:13 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04971 for ; Mon, 12 May 2003 17:46:12 -0400 (EDT) Received: (qmail 27281 invoked by uid 605); 12 May 2003 21:49:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27270 invoked from network); 12 May 2003 21:49:09 -0000 Received: from nic.crt.se (193.12.107.10) by mail.netbsd.org with SMTP; 12 May 2003 21:49:09 -0000 Received: from mail.crt.se (postiljon.crt.se [193.12.115.230]) by nic.crt.se (Postfix) with ESMTP id 38A166195; Mon, 12 May 2003 23:49:07 +0200 (CEST) Received: from crt.se (stargate-i.crt.se [193.12.115.229]) by mail.crt.se (Postfix) with ESMTP id B0B6B1D99; Mon, 12 May 2003 23:49:06 +0200 (MEST) Date: Mon, 12 May 2003 23:49:06 +0200 (CEST) From: Jakob Schlyter To: Simon Josefsson Cc: iesg@ietf.org, IETF Secure Shell WG Subject: Re: Last Call: Using DNS to securely publish SSH key fingerprints to Proposed Standard In-Reply-To: Message-ID: References: <200305052209.SAA18159@ietf.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 12 May 2003, Simon Josefsson wrote: > Was it considered to allow for other security mechanisms to authenticate > the SSHFP data, besides DNSSEC? yes, but that does not scale. > Some scenarios that are precluded by the current text: > > * TSIG/IPSEC-protected query to authoritative server with SSHFP. > > * TSIG/IPSEC-protected query to trusted server with SSHFP. (The > server may have received the data using a secure channel from the > authoritative server.) just because the server is authoritative does not mean the data can be trusted. the entity signing the zonefile is what should be trusted, not the box serving it. > * Using data from zone files received securely out of band. (E.g., > via SSH, or by mail protected by CMS or OpenPGP, from the > authoritative domain.) what you are describing here is not DNS, it is some other mechanism using DNS zone files as transport format. jakob From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 12 18:57:42 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07673 for ; Mon, 12 May 2003 18:57:42 -0400 (EDT) Received: (qmail 3014 invoked by uid 605); 12 May 2003 23:00:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3005 invoked from network); 12 May 2003 23:00:39 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 12 May 2003 23:00:39 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id C9B287FD06; Tue, 13 May 2003 02:00:26 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id C75F57FD05; Tue, 13 May 2003 02:00:26 +0300 (EEST) Date: Tue, 13 May 2003 02:00:26 +0300 (EEST) From: Heikki Nousiainen To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: Comments on the reviesed Security Section open issues. In-Reply-To: <3CA03ED9-84B8-11D7-B619-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 12 May 2003, RJ Atkinson wrote: > > Does someone want to try to construct a rationale for the > document about why folks believe the attempted replay > protection actually works ? I'm not much of an editor, but maybe someone can slash something out of the following: Running sequence number gives us an unique input for the MAC function regardless of the contents of the packet, as long as the sequence number doesn't wrap. With rekeying before the sequence number wraps, we get an unique input into the MAC function (well, HMAC at least) regardless of the sequence counter wrapping. If an attacker captures a packet and inserts it within the SSH stream in order to replay the packet, either the sequence number or the MAC key will be different, and the MAC check will fail. We assume MAC is secure of course, specifically it being infeasible to construct x' such that MAC(x) = MAC(x'). For HMACs it is discussed in rfc 2104. I don't know if it's relevant or not, but given that an attacker wants to re-use data from the packet, there are even less bits to work with, and, even less of a chance of succeeding in creating a valid MAC. Regards, Heikki Nousiainen From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 01:17:28 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15432 for ; Tue, 13 May 2003 01:17:25 -0400 (EDT) Received: (qmail 10595 invoked by uid 605); 13 May 2003 05:20:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10588 invoked from network); 13 May 2003 05:20:22 -0000 Received: from netcore.fi (193.94.160.1) by mail.netbsd.org with SMTP; 13 May 2003 05:20:22 -0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4D5KJo16039; Tue, 13 May 2003 08:20:19 +0300 Date: Tue, 13 May 2003 08:20:18 +0300 (EEST) From: Pekka Savola To: Jakob Schlyter cc: ietf-ssh@netbsd.org, Subject: Re: draft-ietf-secsh-dns-04 comments In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, 12 May 2003, Jakob Schlyter wrote: > thanks, I've integrated your changes. since this is only editoral changes, > I assume we do not need another last call. Oh, that's why I got around to see the draft. Yes, I agree this doesn't necessitate another IETF LC. > > (looking back, you could also add a reference to RFC2434 in the IANA > > considerations section) > > why? To get a reference to what "IETF Consensus" by the definition of RFC2434 means. > > @@ -234,7 +234,9 @@ > > / fingerprint / > > / / > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > - > > +==> please use the more common textual representation, seems much more > > +natural > > +==> the picture is 74 chars wide --- not good! > > textual representation? please elaborate. please look at e.g. RFC2460 and many other RFC's on how they have represented it there: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Destination Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. this is the de-facto way of representing bits, I think -- and should be used. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 12:38:49 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19493 for ; Tue, 13 May 2003 12:38:47 -0400 (EDT) Received: (qmail 8444 invoked by uid 605); 13 May 2003 16:41:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8437 invoked from network); 13 May 2003 16:41:44 -0000 Received: from patan.sun.com (HELO brmea-mail-2.sun.com) (192.18.98.43) by mail.netbsd.org with SMTP; 13 May 2003 16:41:44 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DGeZY9025876; Tue, 13 May 2003 10:40:35 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DGeZuP010340; Tue, 13 May 2003 10:40:35 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4DGbxQx000580; Tue, 13 May 2003 09:37:59 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4DGbvOk000579; Tue, 13 May 2003 09:37:57 -0700 (PDT) Date: Tue, 13 May 2003 09:37:57 -0700 From: Nicolas Williams To: Joseph Galbraith Cc: Chris Lonvick , ietf-ssh@netbsd.org Subject: Re: Comments on the reviesed Security Section open issues. Message-ID: <20030513093757.A568@binky.central.sun.com> References: <007401c318ad$a2cb57f0$4d00a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <007401c318ad$a2cb57f0$4d00a8c0@galb.vandyke.com>; from galb-list@vandyke.com on Mon, May 12, 2003 at 11:40:53AM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, May 12, 2003 at 11:40:53AM -0600, Joseph Galbraith wrote: > > > [RJA: I imagine that a sequence number does help preclude replay > attacks, > > > [RJA: but I was hoping that someone else had actually done some > analysis > > > [RJA: that we could cite to justify the claim that this MAC combined > with > > > [RJA: this kind of sequence numbering would actually provide replay > > > [RJA: attack prevention. > > If no one knows of something to cite here, I'm > not sure what to do at this point? > > Baring someone stepping forward witht the requested > citation, what should we do? I'd like to move forward. Er, this is a time-honored technique. Examples of protocols that support the use of sequence numbers as a replay detection technique are: - GSS-API (generally) [RFC2743] - The KerberosV GSS-API mechanism (specifically) [RFC1964] - The Simple Public-Key GSS-API Mechanism (SPKM) (specifically) [RFC2025] - Kerberos V [RFC1510] - TLS 1.0 [RFC2246] Need I go on? Probably not. Each of those documents makes reference to the use of sequence numbers for replay and out-of-sequence detection. > > > 11.1.4 Man-in-the-middle > > > > 2. Use an authentication method that is not vulnerable to > > > man-in-the-middle attacks. For example, public-key authentication > > > is not vulnerable to man-in-the-middle attack as long as the > > > public-key of the server has been securely distributed to the > > > clients before the first SSH connection is made. This is because > > *** see below *** > > > > the signature is made across data that is session specific. The > > > session specific data between the attacker and server will be > > > different between the client-to-attacker session and the > > > attacker-to-server sessions due to the randomness discussed above. > > > From this, the attacker will not be able to make this attack work > > > since the attacker will not be able to correctly sign packets > > > containing this session specific data from the server since he > does > > > not have the private key of that server. > > > > > > [RJA: Is this really true and sufficient ? > > Public key authentication is not vulnerable regardless > of whether the server's public key has been securely > distrubuted. Insecure distribution of server public keys allows a different sort of MITM: one with suitable host keys. If the server public keys are not securely distributed then the client cannot know if it is talking to a legitimate server. > Client --> MITM server / MITM client --> Server > > Client uses robust cryptographic PRNG, and > correct implemenations, forcing the Session > Identifier for the Client --> MITM Server > to be unpredicatable. This applies only to a MITM who does not posses host keys. Obiously, any MITM can generate host keys. The questions is: can a MITM fool a client into thinking that it (the MITM) is the server that the client intended to connect to. > > > 11.2.3 Local security policy > > > > > > Implementer MUST ensure that the credentials provided > > > validate the professed user and also MUST ensure that > > > the local policy of the server permits the user the > > > access requested. > > > > > > In particular, because of the flexible nature of the SSH connection > > > protocol, it may not be possible to determine the local security > > > policy that should apply at the time of authentication, because the > > > kind of service being requested is not yet clear. For example, local > > > policy might allow a user to access files on the server, but not > start > > > an interactive shell. However, during the authentication protocol, it > > > is not known whether the user will be accessing files or attempting > to > > > use an interactive shell, or even both. In any event, local security > > > policy for the server host MUST be applied and enforced correctly. > > > > > > [Nico: What if no policy is available? > > Then there is nothing to enforce? The implementation MUST provide a default policy, either the "null" policy (anything goes) or a highly restrictive policy (the client can establish an SSHv2 connection but do nothing with it other than close it :). > Perhaps we should say, > In any event, where local security policy for the server host exists, > it MUST be applied and enforced correctly. > > and sprinkle a few 'if any' around judiciously. Sure. > > > 11.3.3 X11 forwarding > > > > > > Another form of proxy forwarding provided by the ssh > > > connection protocol is the forwarding of the X11 protocol. > > > > > > Implementors of the X11 protocol SHOULD implement the magic cookie > > > spoofing, to prevent unauthorized use of the proxy. More information > > > about the use of the X11 magic cookie may be found in many of the > > > available manual references and implementation guides for X11. For > > > example, viewing the manual page for "xauth" in BSD systems may be > one > > > place to start. > > > > > > X11 forwarding relies on end-point security. If end-point > > > security has been compromised, X11 forwarding will allow > > > any attack against the X11 server possible locally. > > > > > > Users and administrators should, as a matter of course, use > > > X11 security mechanism to prevent unauthorized use of > > > the X11 server. > > > > > > [RJA: Which "X11 security mechanism" is meant ? > > > [RJA: Also, please add a citation for that mechanism. > > > > > > [JG: Well, I didn't have a particular one in mind. The > > > [JG: advice is to use any X11 security mechanism. I'd > > > [JG: be willing to remove the paragraph. > > > [RJA: I'd like to keep text encouraging folks to use as much > > > [RJA: security as they can. I'm not an expert on the security > > > [RJA: properties of X11. I was thinking that there probably were > > > [RJA: some specific security mechanisms (e.g. my vague recollection > > > [RJA: of the MIT-magic-cookie hack noted above) that we ought > > > [RJA: to mention and cite. Well, the MIT magic cookie approach is about the only one truly in use and, IMO, it is sufficient for the purposes of SSHv2. > > I would suggest the following two citations for this > section: > > [SCHEIFLER] Scheifler, R., "X Window System : The Complete > Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd > edition.", Digital Press ISBN 1555580882, Feburary > 1992. > > and > > draft-ietf-secsh-connect-16.txt, section 4.3.1., > "Requesting X11 Forwarding" Er, sure. I'm not very familiar with the X11 standards, so I'm not sure what would be a good reference. Apparently X.ORG and the Open Group own the X11 standards now. A quick search through X.org and XFree86.org yielded little conclusive information, but a further search finally yielded: http://www.xfree86.org/4.3.0/XStandards.7.html Likely the best reference is: X Window System Protocol X Version 11, Release 6.4 Robert W. Scheifler Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 12:49:41 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19723 for ; Tue, 13 May 2003 12:49:40 -0400 (EDT) Received: (qmail 14303 invoked by uid 605); 13 May 2003 16:52:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14218 invoked from network); 13 May 2003 16:52:38 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 13 May 2003 16:52:38 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA29630; Tue, 13 May 2003 09:52:00 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DGq0Ng004437; Tue, 13 May 2003 10:52:00 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4DGnQQx000589; Tue, 13 May 2003 09:49:26 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4DGnPLQ000588; Tue, 13 May 2003 09:49:25 -0700 (PDT) Date: Tue, 13 May 2003 09:49:25 -0700 From: Nicolas Williams To: Heikki Nousiainen Cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: Comments on the reviesed Security Section open issues. Message-ID: <20030513094925.B568@binky.central.sun.com> References: <3CA03ED9-84B8-11D7-B619-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from htn@sumu.org on Tue, May 13, 2003 at 02:00:26AM +0300 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, May 13, 2003 at 02:00:26AM +0300, Heikki Nousiainen wrote: > On Mon, 12 May 2003, RJ Atkinson wrote: > > > > Does someone want to try to construct a rationale for the > > document about why folks believe the attempted replay > > protection actually works ? > > I'm not much of an editor, but maybe someone can slash something out of > the following: > > Running sequence number gives us an unique input for the MAC > function regardless of the contents of the packet, as long as the > sequence number doesn't wrap. With rekeying before the sequence number > wraps, we get an unique input into the MAC function (well, HMAC at least) > regardless of the sequence counter wrapping. > > If an attacker captures a packet and inserts it within the SSH stream in > order to replay the packet, either the sequence number or the MAC key will > be different, and the MAC check will fail. > > > We assume MAC is secure of course, specifically it being infeasible to > construct x' such that MAC(x) = MAC(x'). For HMACs it is discussed in > rfc 2104. > I don't know if it's relevant or not, but given that an attacker wants to > re-use data from the packet, there are even less bits to work with, and, > even less of a chance of succeeding in creating a valid MAC. I like this text. Note that because the "packet sequence number itself is not included in the packet sent over the wire" out-of-sequence detection and recovery is not possible. Rekeying before sequence number wrapping is a MUST though. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 14:52:16 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24214 for ; Tue, 13 May 2003 14:52:15 -0400 (EDT) Received: (qmail 16371 invoked by uid 605); 13 May 2003 18:55:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16339 invoked from network); 13 May 2003 18:54:59 -0000 Received: from elvis.mu.org (192.203.228.196) by mail.netbsd.org with SMTP; 13 May 2003 18:54:59 -0000 Received: by elvis.mu.org (Postfix, from userid 1192) id 77FE02ED406; Tue, 13 May 2003 11:54:43 -0700 (PDT) Date: Tue, 13 May 2003 11:54:43 -0700 From: Alfred Perlstein To: ietf-ssh@netbsd.org Cc: Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513185443.GQ65456@elvis.mu.org> References: <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030513153216.GB24601@folly> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list Basically we're having a discussion about why rename under sftp doesn't provide true rename(2) semantics. Can someone comment or provide a suggestion to resolve this? I have several half-baked solutions at the end of this email to choose from or a new idea would be welcome. thank you, -Alfred * Markus Friedl [030513 08:33] wrote: > On Tue, May 13, 2003 at 04:19:17AM -0700, Alfred Perlstein wrote: > > I was trying to use sftp to upload pictures for a camera project > > and came across a problem, basically the rename code is trying > > to be clever for some reason that I can't determine and is broken > > for renaming a file over an existing one: > > but this is how it's supposed to work: > > 6.5 Removing and Renaming Files > > .... ... > where `id' is the request identifier, `oldpath' is the name of an > existing file or directory, and `newpath' is the new name for the > file or directory. It is an error if there already exists a file > with the name specified by newpath. The server may also fail rename > requests in other situations, for example if `oldpath' and `newpath' > point to different file systems on the server. ... > > Why not just use rename(2)? Or fall back to rename(2) if on unix > > or if the link fails? If the "race" is that there may be data > > lossage then this is pointless unless you fsync the target files > > between operations. > > The original code was ... > } > > but since newpath might be created after the stat(2) > we changed this to the current code. > > however, i think that for the traditional unix 'mv', this > specification of SSH_FXP_RENAME is bogus, so you should > talk to ietf-ssh@netbsd.org. any other ideas? > or am i missing something. a rename(2) semantic would > be much better.... I totally agree that having a true mechanism for getting real rename(2) semantics is desireable. Perhaps a flag though, rename -f or something to do an actual rename or perhaps a "-i" for the link(2) behaviour. Or maybe adding the ability for the built in "ln" command to do hardlinks then if the user wanted the current behaviour they could just use "ln". :) Just some suggestions. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 15:25:44 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26562 for ; Tue, 13 May 2003 15:25:43 -0400 (EDT) Received: (qmail 1586 invoked by uid 605); 13 May 2003 19:28:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1541 invoked from network); 13 May 2003 19:28:42 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 13 May 2003 19:28:42 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1517562; Tue, 13 May 2003 13:28:41 -0600 Message-ID: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Alfred Perlstein" , Cc: "Markus Friedl" , References: <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> Subject: Re: sftp rename not good. Date: Tue, 13 May 2003 13:28:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Let me make sure I understand the problem: - SSH_FXP_RENAME specifies that it is an error if the new file exists. - rename(2) specifies that if the new file exists, it is always overwritten. Therefore rename(2) can't be used to implement SSH_FXP_RENAME. Is this a correct summary of the problem? Thanks, Joseph ----- Original Message ----- From: "Alfred Perlstein" To: Cc: "Markus Friedl" ; Sent: Tuesday, May 13, 2003 12:54 PM Subject: Re: sftp rename not good. > Basically we're having a discussion about why rename under sftp > doesn't provide true rename(2) semantics. Can someone comment > or provide a suggestion to resolve this? I have several > half-baked solutions at the end of this email to choose from > or a new idea would be welcome. > > thank you, > -Alfred > > * Markus Friedl [030513 08:33] wrote: > > On Tue, May 13, 2003 at 04:19:17AM -0700, Alfred Perlstein wrote: > > > I was trying to use sftp to upload pictures for a camera project > > > and came across a problem, basically the rename code is trying > > > to be clever for some reason that I can't determine and is broken > > > for renaming a file over an existing one: > > > > but this is how it's supposed to work: > > > > 6.5 Removing and Renaming Files > > > > .... > ... > > where `id' is the request identifier, `oldpath' is the name of an > > existing file or directory, and `newpath' is the new name for the > > file or directory. It is an error if there already exists a file > > with the name specified by newpath. The server may also fail rename > > requests in other situations, for example if `oldpath' and `newpath' > > point to different file systems on the server. > ... > > > Why not just use rename(2)? Or fall back to rename(2) if on unix > > > or if the link fails? If the "race" is that there may be data > > > lossage then this is pointless unless you fsync the target files > > > between operations. > > > > The original code was > ... > > } > > > > but since newpath might be created after the stat(2) > > we changed this to the current code. > > > > however, i think that for the traditional unix 'mv', this > > specification of SSH_FXP_RENAME is bogus, so you should > > talk to ietf-ssh@netbsd.org. any other ideas? > > or am i missing something. a rename(2) semantic would > > be much better.... > > I totally agree that having a true mechanism for getting > real rename(2) semantics is desireable. > > Perhaps a flag though, rename -f or something to do an actual rename > or perhaps a "-i" for the link(2) behaviour. Or maybe adding the > ability for the built in "ln" command to do hardlinks then if the > user wanted the current behaviour they could just use "ln". :) > > Just some suggestions. > > -- > -Alfred Perlstein [alfred@freebsd.org] > 'Instead of asking why a piece of software is using "1970s technology," > start asking why software is ignoring 30 years of accumulated wisdom.' > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 16:00:19 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27554 for ; Tue, 13 May 2003 16:00:19 -0400 (EDT) Received: (qmail 18510 invoked by uid 605); 13 May 2003 20:03:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18503 invoked from network); 13 May 2003 20:03:17 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 13 May 2003 20:03:17 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19FfzY-0003oS-00; Tue, 13 May 2003 21:03:16 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> Subject: Re: sftp rename not good. Message-Id: Date: Tue, 13 May 2003 21:03:16 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joseph Galbraith wrote: > Let me make sure I understand the problem: > > - SSH_FXP_RENAME specifies that it is an error if the new file exists. > - rename(2) specifies that if the new file exists, it is always overwritten. > Therefore rename(2) can't be used to implement SSH_FXP_RENAME. > > Is this a correct summary of the problem? AIUI, that's only half the problem. The other half is that SSH_FXP_RENAME can't be used to implement rename(2)! The rename(2) semantics are useful if you want to avoid race conditions with other processes reading a file: you create a new version of the file under a different name, and atomically rename(2) it over the top of the old one, and at _all_ observable instants on the server there is a file with valid contents stored under the original name. I believe it's being asserted that this would be a useful feature in SFTP. Cheers, Simon -- Simon Tatham "Thieves respect property; they only wish the property to be their own, that they may more properly respect it." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 17:55:00 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00302 for ; Tue, 13 May 2003 17:54:59 -0400 (EDT) Received: (qmail 29011 invoked by uid 605); 13 May 2003 21:57:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29001 invoked from network); 13 May 2003 21:57:56 -0000 Received: from elvis.mu.org (192.203.228.196) by mail.netbsd.org with SMTP; 13 May 2003 21:57:56 -0000 Received: by elvis.mu.org (Postfix, from userid 1192) id 677B12ED3F0; Tue, 13 May 2003 14:57:56 -0700 (PDT) Date: Tue, 13 May 2003 14:57:56 -0700 From: Alfred Perlstein To: Joseph Galbraith Cc: ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513215756.GS65456@elvis.mu.org> References: <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list * Joseph Galbraith [030513 12:28] wrote: > Let me make sure I understand the problem: > > - SSH_FXP_RENAME specifies that it is an > error if the new file exists. > > - rename(2) specifies that if the new file > exists, it is always overwritten. > > Therefore rename(2) can't be used to implement > SSH_FXP_RENAME. > > Is this a correct summary of the problem? That's the cause of the problem. The actual problem is that it doesn't seem possible to do atomic updates of files using sftp because of the way SSH_FXP_RENAME must be implemented. Also, I _think_ that using link(2) (without fsync) instead of rename(2) allows for the system to lose the file completely during an outtage. I think there should be some way of invoking an actual rename(2) on the server. thank you, -Alfred From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 18:15:21 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01920 for ; Tue, 13 May 2003 18:15:21 -0400 (EDT) Received: (qmail 8276 invoked by uid 605); 13 May 2003 22:18:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8267 invoked from network); 13 May 2003 22:18:18 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 13 May 2003 22:18:18 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUKWWFPXO9N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 16:18:10 -0700 (MST) Date: Tue, 13 May 2003 16:14:55 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: <20030513215756.GS65456@elvis.mu.org> X-Sender: oreilly@raptor.psccos.com To: Alfred Perlstein Cc: Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Message-id: <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 03:57 PM 5/13/2003, Alfred Perlstein wrote: >* Joseph Galbraith [030513 12:28] wrote: > > Let me make sure I understand the problem: > > > > - SSH_FXP_RENAME specifies that it is an > > error if the new file exists. > > > > - rename(2) specifies that if the new file > > exists, it is always overwritten. > > > > Therefore rename(2) can't be used to implement > > SSH_FXP_RENAME. > > > > Is this a correct summary of the problem? > >That's the cause of the problem. > >The actual problem is that it doesn't seem possible to do atomic >updates of files using sftp because of the way SSH_FXP_RENAME must >be implemented. > >Also, I _think_ that using link(2) (without fsync) instead of >rename(2) allows for the system to lose the file completely >during an outtage. > >I think there should be some way of invoking an actual rename(2) >on the server. That would be best, IMHO. That way, you can implement server-specific behavior. For example, those of us on VMS have versioned file systems, so the behavior of a rename on VMS could be drastically different than that on a UNIX system. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 18:19:39 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02104 for ; Tue, 13 May 2003 18:19:39 -0400 (EDT) Received: (qmail 10289 invoked by uid 605); 13 May 2003 22:22:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10282 invoked from network); 13 May 2003 22:22:37 -0000 Received: from elvis.mu.org (192.203.228.196) by mail.netbsd.org with SMTP; 13 May 2003 22:22:37 -0000 Received: by elvis.mu.org (Postfix, from userid 1192) id 0F0022ED413; Tue, 13 May 2003 15:22:37 -0700 (PDT) Date: Tue, 13 May 2003 15:22:37 -0700 From: Alfred Perlstein To: "Dan O'Reilly" Cc: Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513222237.GT65456@elvis.mu.org> References: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list * Dan O'Reilly [030513 15:18] wrote: > At 03:57 PM 5/13/2003, Alfred Perlstein wrote: > > > >I think there should be some way of invoking an actual rename(2) > >on the server. > > That would be best, IMHO. That way, you can implement server-specific > behavior. For example, those of us on VMS have versioned file systems, > so the behavior of a rename on VMS could be drastically different than > that on a UNIX system. Now that scares me. :) My intention was to gather support for UNIX semantics for this, not "whatever rename(2) does on the server". -Alfred From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 18:26:27 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02335 for ; Tue, 13 May 2003 18:26:26 -0400 (EDT) Received: (qmail 13701 invoked by uid 605); 13 May 2003 22:29:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13694 invoked from network); 13 May 2003 22:29:24 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 13 May 2003 22:29:24 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVULARUDLY9N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 16:29:21 -0700 (MST) Date: Tue, 13 May 2003 16:26:05 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: <20030513222237.GT65456@elvis.mu.org> X-Sender: oreilly@raptor.psccos.com To: Alfred Perlstein Cc: Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Message-id: <5.2.0.9.2.20030513162328.00b8e2b8@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 04:22 PM 5/13/2003, Alfred Perlstein wrote: >* Dan O'Reilly [030513 15:18] wrote: > > At 03:57 PM 5/13/2003, Alfred Perlstein wrote: > > > > > >I think there should be some way of invoking an actual rename(2) > > >on the server. > > > > That would be best, IMHO. That way, you can implement server-specific > > behavior. For example, those of us on VMS have versioned file systems, > > so the behavior of a rename on VMS could be drastically different than > > that on a UNIX system. > >Now that scares me. :) My intention was to gather support for UNIX >semantics for this, not "whatever rename(2) does on the server". Well, the point is, not everything is UNIX (and Lord knows, that whole subject has come up before!). If you allow it to be server-based, then the whole issue of "how do I do a rename" is obviated from the client's perspective. Makes things cleaner all around, I think. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:06:25 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03487 for ; Tue, 13 May 2003 19:06:25 -0400 (EDT) Received: (qmail 4880 invoked by uid 605); 13 May 2003 23:09:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3481 invoked from network); 13 May 2003 23:07:50 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 13 May 2003 23:07:50 -0000 Received: from folly.informatik.uni-erlangen.de (localhost [127.0.0.1]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h4DN7iG3008295; Wed, 14 May 2003 01:07:45 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 9BE082D042; Wed, 14 May 2003 01:06:45 +0200 (CEST) Date: Wed, 14 May 2003 01:06:45 +0200 From: Markus Friedl To: Joseph Galbraith Cc: Alfred Perlstein , ietf-ssh@netbsd.org, openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513230645.GA24704@folly> References: <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, May 13, 2003 at 01:28:41PM -0600, Joseph Galbraith wrote: > Let me make sure I understand the problem: > > - SSH_FXP_RENAME specifies that it is an > error if the new file exists. > > - rename(2) specifies that if the new file > exists, it is always overwritten. > > Therefore rename(2) can't be used to implement > SSH_FXP_RENAME. > > Is this a correct summary of the problem? yes, and the usual unix semantics for 'move' cannot be easily emulated with SSH_FXP_RENAME. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:08:52 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03533 for ; Tue, 13 May 2003 19:08:51 -0400 (EDT) Received: (qmail 8110 invoked by uid 605); 13 May 2003 23:11:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8103 invoked from network); 13 May 2003 23:11:47 -0000 Received: from shitei.mindrot.org (203.36.198.97) by mail.netbsd.org with SMTP; 13 May 2003 23:11:47 -0000 Received: from mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id AD1E494213; Wed, 14 May 2003 09:10:45 +1000 (EST) Message-ID: <3EC17B63.1090205@mindrot.org> Date: Wed, 14 May 2003 09:10:27 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-au, en-gb, en, en-us, ja MIME-Version: 1.0 To: "Dan O'Reilly" Cc: Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. References: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> In-Reply-To: <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Dan O'Reilly wrote: > At 03:57 PM 5/13/2003, Alfred Perlstein wrote: >>* Joseph Galbraith [030513 12:28] wrote: >>I think there should be some way of invoking an actual rename(2) >>on the server. > > That would be best, IMHO. That way, you can implement server-specific > behavior. For example, those of us on VMS have versioned file systems, > so the behavior of a rename on VMS could be drastically different than > that on a UNIX system. Please no! Protocol methods should be specified to behave in a particular way, regardless of what server environment is in use. A "protocol method with unix-like rename semantics" has some merit though. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:12:05 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03629 for ; Tue, 13 May 2003 19:12:04 -0400 (EDT) Received: (qmail 9827 invoked by uid 605); 13 May 2003 23:15:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9820 invoked from network); 13 May 2003 23:15:02 -0000 Received: from shitei.mindrot.org (203.36.198.97) by mail.netbsd.org with SMTP; 13 May 2003 23:15:02 -0000 Received: from mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 712E794213; Wed, 14 May 2003 09:14:07 +1000 (EST) Message-ID: <3EC17C2D.6090509@mindrot.org> Date: Wed, 14 May 2003 09:13:49 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-au, en-gb, en, en-us, ja MIME-Version: 1.0 To: Alfred Perlstein Cc: Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. References: <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513215756.GS65456@elvis.mu.org> In-Reply-To: <20030513215756.GS65456@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Alfred Perlstein wrote: > That's the cause of the problem. > > The actual problem is that it doesn't seem possible to do atomic > updates of files using sftp because of the way SSH_FXP_RENAME must > be implemented. > > Also, I _think_ that using link(2) (without fsync) instead of > rename(2) allows for the system to lose the file completely > during an outtage. No, there is always at least one link to the file during the usual sequence of events: if (!exists(new)) link(old, new) unlink(old) Unless you are using some idiot filesystem that writes out directory changes asynchronously (not mentioning any names...) -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:20:39 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03762 for ; Tue, 13 May 2003 19:20:39 -0400 (EDT) Received: (qmail 13534 invoked by uid 605); 13 May 2003 23:23:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13526 invoked from network); 13 May 2003 23:23:33 -0000 Received: from patan.sun.com (HELO brmea-mail-2.sun.com) (192.18.98.43) by mail.netbsd.org with SMTP; 13 May 2003 23:23:33 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DNNRY9027986; Tue, 13 May 2003 17:23:27 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DNNQNg010934; Tue, 13 May 2003 17:23:27 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4DNKqQx000831; Tue, 13 May 2003 16:20:53 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4DNKo1D000830; Tue, 13 May 2003 16:20:50 -0700 (PDT) Date: Tue, 13 May 2003 16:20:50 -0700 From: Nicolas Williams To: Alfred Perlstein Cc: "Dan O'Reilly" , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513162050.A826@binky.central.sun.com> Mail-Followup-To: Alfred Perlstein , Dan O'Reilly , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com References: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030513222237.GT65456@elvis.mu.org>; from bright@mu.org on Tue, May 13, 2003 at 03:22:37PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, May 13, 2003 at 03:22:37PM -0700, Alfred Perlstein wrote: > * Dan O'Reilly [030513 15:18] wrote: > > At 03:57 PM 5/13/2003, Alfred Perlstein wrote: > > > > > >I think there should be some way of invoking an actual rename(2) > > >on the server. > > > > That would be best, IMHO. That way, you can implement server-specific > > behavior. For example, those of us on VMS have versioned file systems, > > so the behavior of a rename on VMS could be drastically different than > > that on a UNIX system. > > Now that scares me. :) My intention was to gather support for UNIX > semantics for this, not "whatever rename(2) does on the server". If the semantics of file renaming vary so much from platform to platform, without even the ability to reliably emulate one behaviour on all those platforms, then either that variance will have to carry through to SFTP or the SFTP server will have to have a way to tell the SFTP client what file rename semantics it supports so the client can choose which to use. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:23:46 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03805 for ; Tue, 13 May 2003 19:23:45 -0400 (EDT) Received: (qmail 14941 invoked by uid 605); 13 May 2003 23:26:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14934 invoked from network); 13 May 2003 23:26:45 -0000 Received: from elvis.mu.org (192.203.228.196) by mail.netbsd.org with SMTP; 13 May 2003 23:26:45 -0000 Received: by elvis.mu.org (Postfix, from userid 1192) id D82132ED402; Tue, 13 May 2003 16:26:44 -0700 (PDT) Date: Tue, 13 May 2003 16:26:44 -0700 From: Alfred Perlstein To: Damien Miller Cc: Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513232644.GU65456@elvis.mu.org> References: <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513215756.GS65456@elvis.mu.org> <3EC17C2D.6090509@mindrot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EC17C2D.6090509@mindrot.org> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list * Damien Miller [030513 16:15] wrote: > > No, there is always at least one link to the file during the usual > sequence of events: > > if (!exists(new)) > link(old, new) > unlink(old) > > Unless you are using some idiot filesystem that writes out directory > changes asynchronously (not mentioning any names...) What you have there is atomicity, not durability. You must fsync(2) either "dirname(new)" or possibly "new" after the link(2) for that to be safe, otherwise you are relying on the filesystem's implementation. Only rename(2) has the semantics you actually want without the need for fsync(2). -Alfred From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:29:59 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03897 for ; Tue, 13 May 2003 19:29:58 -0400 (EDT) Received: (qmail 18070 invoked by uid 605); 13 May 2003 23:32:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18063 invoked from network); 13 May 2003 23:32:57 -0000 Received: from elvis.mu.org (192.203.228.196) by mail.netbsd.org with SMTP; 13 May 2003 23:32:57 -0000 Received: by elvis.mu.org (Postfix, from userid 1192) id B8A112ED419; Tue, 13 May 2003 16:32:57 -0700 (PDT) Date: Tue, 13 May 2003 16:32:57 -0700 From: Alfred Perlstein To: "Dan O'Reilly" , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513233257.GV65456@elvis.mu.org> References: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <20030513162050.A826@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030513162050.A826@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list * Nicolas Williams [030513 16:23] wrote: > > If the semantics of file renaming vary so much from platform to > platform, without even the ability to reliably emulate one behaviour on > all those platforms, then either that variance will have to carry > through to SFTP or the SFTP server will have to have a way to tell the > SFTP client what file rename semantics it supports so the client can > choose which to use. Which is why I was hoping for "rename -f" to at least attempt the unix rename(2). If rename(2) is not available it should do something like this: if (rename(old, new) == -1) if (errno != ENOSYS || errno != ENOTSUP) return (-1); /* emulate rename, XXX: output a warning to client? */ (void) unlink(new); if (link(old, new) != 0) return (-1); if (fsync(new) != 0) { (void) unlink(new); return (-1); } (void) unlink(old); } -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:30:29 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03912 for ; Tue, 13 May 2003 19:30:28 -0400 (EDT) Received: (qmail 18776 invoked by uid 605); 13 May 2003 23:33:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18769 invoked from network); 13 May 2003 23:33:26 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 13 May 2003 23:33:26 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUNJ3SVM49N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 17:33:21 -0700 (MST) Date: Tue, 13 May 2003 17:27:38 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: <3EC17B63.1090205@mindrot.org> X-Sender: oreilly@raptor.psccos.com To: Damien Miller Cc: Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Message-id: <5.2.0.9.2.20030513172319.00b80a40@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 05:10 PM 5/13/2003, Damien Miller wrote: >Dan O'Reilly wrote: > > At 03:57 PM 5/13/2003, Alfred Perlstein wrote: > >>* Joseph Galbraith [030513 12:28] wrote: > >>I think there should be some way of invoking an actual rename(2) > >>on the server. > > > > That would be best, IMHO. That way, you can implement server-specific > > behavior. For example, those of us on VMS have versioned file systems, > > so the behavior of a rename on VMS could be drastically different than > > that on a UNIX system. > >Please no! Protocol methods should be specified to behave in a >particular way, regardless of what server environment is in use. Why should a protocol specify more than "you must support a rename function in the server", without specifying specifics of the implementation? To do other than that is to restrict a server and to possibly limit it in its functionality vis-a-vis a normal (e.g., ftp) file system operation. By specifying that a function must be supported (e.g., "you have to be able to rename a file") but not HOW it must be supported (e.g, in VMS you can create another file of the same name with a new version number, or you could simply replace an existing file), you provide the maximum flexibility while still hiding the specifics of the host system operating system and/or file system. And that, I was always given to understand, is the definition of "flexible" in a protocol. Why should every OS and every file system conform to a UNIX (or Windows or ????) "standard" when it inherently limits the functionality of those systems? ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:30:37 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03927 for ; Tue, 13 May 2003 19:30:36 -0400 (EDT) Received: (qmail 18832 invoked by uid 605); 13 May 2003 23:33:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18781 invoked from network); 13 May 2003 23:33:27 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 13 May 2003 23:33:27 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUNJ3SVM49N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 17:33:23 -0700 (MST) Date: Tue, 13 May 2003 17:29:51 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: <20030513162050.A826@binky.central.sun.com> X-Sender: oreilly@raptor.psccos.com To: Nicolas Williams Cc: Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Message-id: <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <"from bright"@mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 05:20 PM 5/13/2003, Nicolas Williams wrote: >On Tue, May 13, 2003 at 03:22:37PM -0700, Alfred Perlstein wrote: > > * Dan O'Reilly [030513 15:18] wrote: > > > At 03:57 PM 5/13/2003, Alfred Perlstein wrote: > > > > > > > >I think there should be some way of invoking an actual rename(2) > > > >on the server. > > > > > > That would be best, IMHO. That way, you can implement server-specific > > > behavior. For example, those of us on VMS have versioned file systems, > > > so the behavior of a rename on VMS could be drastically different than > > > that on a UNIX system. > > > > Now that scares me. :) My intention was to gather support for UNIX > > semantics for this, not "whatever rename(2) does on the server". > >If the semantics of file renaming vary so much from platform to >platform, without even the ability to reliably emulate one behaviour on >all those platforms, then either that variance will have to carry >through to SFTP or the SFTP server will have to have a way to tell the >SFTP client what file rename semantics it supports so the client can >choose which to use. Why should the client care at all? The basic requirement is "support a rename function". Why should the client *SOFTWARE* (not USER) care how the server system actually performs that? A VMS system should be allowed to behave as a VMS system should when renaming a file; as should a UNIX system or a Windows system. That's not client-specific. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:34:46 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04026 for ; Tue, 13 May 2003 19:34:45 -0400 (EDT) Received: (qmail 20961 invoked by uid 605); 13 May 2003 23:37:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20954 invoked from network); 13 May 2003 23:37:44 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 13 May 2003 23:37:44 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DNbhPH015721; Tue, 13 May 2003 16:37:43 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DNbgNg015107; Tue, 13 May 2003 17:37:43 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4DNZ9Qx000860; Tue, 13 May 2003 16:35:09 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4DNZ8vi000859; Tue, 13 May 2003 16:35:08 -0700 (PDT) Date: Tue, 13 May 2003 16:35:08 -0700 From: Nicolas Williams To: "Dan O'Reilly" Cc: Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513163508.N4352@binky.central.sun.com> Mail-Followup-To: Dan O'Reilly , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com References: <"from <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <20030513162050.A826@binky.central.sun.com> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com>; from dano@process.com on Tue, May 13, 2003 at 05:29:51PM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, May 13, 2003 at 05:29:51PM -0600, Dan O'Reilly wrote: > At 05:20 PM 5/13/2003, Nicolas Williams wrote: > >On Tue, May 13, 2003 at 03:22:37PM -0700, Alfred Perlstein wrote: > > > Now that scares me. :) My intention was to gather support for UNIX > > > semantics for this, not "whatever rename(2) does on the server". > > > >If the semantics of file renaming vary so much from platform to > >platform, without even the ability to reliably emulate one behaviour on > >all those platforms, then either that variance will have to carry > >through to SFTP or the SFTP server will have to have a way to tell the > >SFTP client what file rename semantics it supports so the client can > >choose which to use. > > Why should the client care at all? The basic requirement is "support a > rename function". Why should the client *SOFTWARE* (not USER) care how > the server system actually performs that? A VMS system should be allowed > to behave as a VMS system should when renaming a file; as should a UNIX > system or a Windows system. That's not client-specific. If the client doesn't care, then the semantics of rename should be upto the server (within some parameters? which parameters?). But I think the client cares, or, rather, this user cares :) :) Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:39:51 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04115 for ; Tue, 13 May 2003 19:39:51 -0400 (EDT) Received: (qmail 23889 invoked by uid 605); 13 May 2003 23:42:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23880 invoked from network); 13 May 2003 23:42:49 -0000 Received: from shitei.mindrot.org (203.36.198.97) by mail.netbsd.org with SMTP; 13 May 2003 23:42:49 -0000 Received: from mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 7236594213; Wed, 14 May 2003 09:41:53 +1000 (EST) Message-ID: <3EC182AF.3060404@mindrot.org> Date: Wed, 14 May 2003 09:41:35 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-au, en-gb, en, en-us, ja MIME-Version: 1.0 To: "Dan O'Reilly" Cc: Nicolas Williams , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. References: <"from bright"@mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> In-Reply-To: <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Dan O'Reilly wrote: > Why should the client care at all? The basic requirement is "support a > rename function". Why should the client *SOFTWARE* (not USER) care how > the server system actually performs that? Because the semantics matter: will the server's rename() overwrite an existing file? Is it atomic? Will it cross filesystems? Put a different way: if the semantics are irrelevant, then why are we even having this discussion? -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:50:09 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04248 for ; Tue, 13 May 2003 19:50:08 -0400 (EDT) Received: (qmail 29327 invoked by uid 605); 13 May 2003 23:53:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29320 invoked from network); 13 May 2003 23:53:06 -0000 Received: from etoh.eviladmin.org (206.145.58.62) by mail.netbsd.org with SMTP; 13 May 2003 23:53:06 -0000 Received: from etoh.eviladmin.org (mouring@localhost.eviladmin.org [127.0.0.1]) by etoh.eviladmin.org (8.12.6/8.12.6) with ESMTP id h4DNmAaQ030690; Tue, 13 May 2003 18:48:10 -0500 (CDT) Received: from localhost (mouring@localhost) by etoh.eviladmin.org (8.12.6/8.12.6/Submit) with ESMTP id h4DNlsup017170; Tue, 13 May 2003 18:47:59 -0500 (CDT) Date: Tue, 13 May 2003 18:47:54 -0500 (CDT) From: Ben Lindstrom To: "Dan O'Reilly" cc: Nicolas Williams , Alfred Perlstein , Joseph Galbraith , , Subject: Re: sftp rename not good. In-Reply-To: <3EC182AF.3060404@mindrot.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, 14 May 2003, Damien Miller wrote: > Dan O'Reilly wrote: > > Why should the client care at all? The basic requirement is "support a > > rename function". Why should the client *SOFTWARE* (not USER) care how > > the server system actually performs that? > > Because the semantics matter: will the server's rename() overwrite an > existing file? Is it atomic? Will it cross filesystems? > > Put a different way: if the semantics are irrelevant, then why are we > even having this discussion? > I agree. It does matter. One person's definition and implement of what 'rename' does and does not do can be very different than someone elses. And without some constant baseline to work from it will drive the user insane. Lot of places deploy ssh/sftp instead of ftp for website updating. And frankly, most end-users don't care why NT acts one way and VMS works another. - Ben From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 19:58:36 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04441 for ; Tue, 13 May 2003 19:58:36 -0400 (EDT) Received: (qmail 2950 invoked by uid 605); 14 May 2003 00:01:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2942 invoked from network); 14 May 2003 00:01:32 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 14 May 2003 00:01:32 -0000 Received: from CELLO (c-24-126-120-178.we.client2.attbi.com [24.126.120.178]) by carnelian.propagation.net (8.9.3p2/8.8.5) with SMTP id TAA13620; Tue, 13 May 2003 19:01:26 -0500 From: "Howard Chu" To: "'Nicolas Williams'" Cc: , Subject: RE: sftp rename not good. Date: Tue, 13 May 2003 17:01:07 -0700 Message-ID: <007101c319ab$f5a04810$0e01a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-To: <20030513163508.N4352@binky.central.sun.com> Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On Behalf Of Nicolas Williams > On Tue, May 13, 2003 at 05:29:51PM -0600, Dan O'Reilly wrote: > > At 05:20 PM 5/13/2003, Nicolas Williams wrote: > > >On Tue, May 13, 2003 at 03:22:37PM -0700, Alfred Perlstein wrote: > > > > Now that scares me. :) My intention was to gather > support for UNIX > > > > semantics for this, not "whatever rename(2) does on the server". > > > > > >If the semantics of file renaming vary so much from platform to > > >platform, without even the ability to reliably emulate one > behaviour on > > >all those platforms, then either that variance will have to carry > > >through to SFTP or the SFTP server will have to have a way > to tell the > > >SFTP client what file rename semantics it supports so the > client can > > >choose which to use. > > > > Why should the client care at all? The basic requirement > is "support a > > rename function". Why should the client *SOFTWARE* (not > USER) care how > > the server system actually performs that? A VMS system > should be allowed > > to behave as a VMS system should when renaming a file; as > should a UNIX > > system or a Windows system. That's not client-specific. > > If the client doesn't care, then the semantics of rename > should be upto > the server (within some parameters? which parameters?). > > But I think the client cares, or, rather, this user cares :) :) I think that can be accomodated... If you are a VMS user, then you're already familiar with how "rename" behaves on your VMS system. You could reasonably expect that when you ftp/sftp to your system and perform a rename, the same semantics that you already expect, are carried out. Likewise if you're a Unix user connecting to a Unix server. I don't believe there's any mechanism for the client to connect to an arbitrary server and say "I expect Unix semantics" though, nor do I think there should be. When you're connecting to a foreign system, you get the semantics that system supports. What's the big problem with that? I recall countless ftp sessions to TOPS-20 servers and IBM mainframes, with their weird 9-bit-per-byte words or their record-oriented filesystems. If you try to force every system into a Unix-like interface, you make it impossible to exchange files with these systems, that have no notion of flat octet-stream files. Putting an artificial Unix-like wrapper over things seems like the wrong approach. If I'm using VMS, I want my tools to act like every other VMS tool. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 20:23:54 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04934 for ; Tue, 13 May 2003 20:23:53 -0400 (EDT) Received: (qmail 17470 invoked by uid 605); 14 May 2003 00:26:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17463 invoked from network); 14 May 2003 00:26:50 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 14 May 2003 00:26:50 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUPE8UCJI9N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 18:26:42 -0700 (MST) Date: Tue, 13 May 2003 18:19:16 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: <20030513163508.N4352@binky.central.sun.com> X-Sender: oreilly@raptor.psccos.com To: Nicolas Williams Cc: Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Message-id: <5.2.0.9.2.20030513181642.0245be78@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <"from dano"@process.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 05:35 PM 5/13/2003, Nicolas Williams wrote: >On Tue, May 13, 2003 at 05:29:51PM -0600, Dan O'Reilly wrote: > > At 05:20 PM 5/13/2003, Nicolas Williams wrote: > > >On Tue, May 13, 2003 at 03:22:37PM -0700, Alfred Perlstein wrote: > > > > Now that scares me. :) My intention was to gather support for UNIX > > > > semantics for this, not "whatever rename(2) does on the server". > > > > > >If the semantics of file renaming vary so much from platform to > > >platform, without even the ability to reliably emulate one behaviour on > > >all those platforms, then either that variance will have to carry > > >through to SFTP or the SFTP server will have to have a way to tell the > > >SFTP client what file rename semantics it supports so the client can > > >choose which to use. > > > > Why should the client care at all? The basic requirement is "support a > > rename function". Why should the client *SOFTWARE* (not USER) care how > > the server system actually performs that? A VMS system should be allowed > > to behave as a VMS system should when renaming a file; as should a UNIX > > system or a Windows system. That's not client-specific. > >If the client doesn't care, then the semantics of rename should be upto >the server (within some parameters? which parameters?). > >But I think the client cares, or, rather, this user cares :) :) Well, actually, I agree with you, and you've made my point. The client doesn't care, but the user does. And a user on a VMS system will expect to see things done the way VMS does things, just as a user on a UNIX system will expect to see things done with way UNIX does things. So, if the functionality is left up to the server, it accomplishes that quick nicely. I can tell you a common complaint we hear from our users is "why doesn't this work on VMS as I would expect it to?". I'm thinking "preemption" here. Let the servers work as the servers will, and have the protocol simply specify "you must support a rename function" (or whatever other function is at hand). ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 20:24:03 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04951 for ; Tue, 13 May 2003 20:24:03 -0400 (EDT) Received: (qmail 17777 invoked by uid 605); 14 May 2003 00:26:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17471 invoked from network); 14 May 2003 00:26:51 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 14 May 2003 00:26:51 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUPE8UCJI9N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 18:26:45 -0700 (MST) Date: Tue, 13 May 2003 18:21:31 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: <3EC182AF.3060404@mindrot.org> X-Sender: oreilly@raptor.psccos.com To: Damien Miller Cc: Nicolas Williams , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Message-id: <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <"from bright"@mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 05:41 PM 5/13/2003, Damien Miller wrote: >Dan O'Reilly wrote: > > Why should the client care at all? The basic requirement is "support a > > rename function". Why should the client *SOFTWARE* (not USER) care how > > the server system actually performs that? > >Because the semantics matter: will the server's rename() overwrite an >existing file? Is it atomic? Will it cross filesystems? > >Put a different way: if the semantics are irrelevant, then why are we >even having this discussion? Because somebody is trying to make the semantics relevant in a VERY system-specific (i.e., UNIX) way. I'm trying to make the semantics irrelevant as I believe they should be. Why should I care how UNIX does a rename function versus VMS? The important thing is that the rename occurs. For example: in UNIX, it may be illegal to rename a file if one of the same name exists. In VMS, it may or may not be illegal, depending on if file versions are specified for the complete file specification supplied to the rename function. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 20:24:12 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04966 for ; Tue, 13 May 2003 20:24:11 -0400 (EDT) Received: (qmail 17872 invoked by uid 605); 14 May 2003 00:26:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17708 invoked from network); 14 May 2003 00:26:55 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 14 May 2003 00:26:55 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUPE8UCJI9N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 18:26:49 -0700 (MST) Date: Tue, 13 May 2003 18:22:20 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: X-Sender: oreilly@raptor.psccos.com To: Ben Lindstrom Cc: Nicolas Williams , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, openssh@openssh.com Message-id: <5.2.0.9.2.20030513182155.00b8e2b8@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <3EC182AF.3060404@mindrot.org> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 05:47 PM 5/13/2003, Ben Lindstrom wrote: >On Wed, 14 May 2003, Damien Miller wrote: > > > Dan O'Reilly wrote: > > > Why should the client care at all? The basic requirement is "support a > > > rename function". Why should the client *SOFTWARE* (not USER) care how > > > the server system actually performs that? > > > > Because the semantics matter: will the server's rename() overwrite an > > existing file? Is it atomic? Will it cross filesystems? > > > > Put a different way: if the semantics are irrelevant, then why are we > > even having this discussion? > > > >I agree. It does matter. One person's definition and implement of what >'rename' does and does not do can be very different than someone elses. >And without some constant baseline to work from it will drive the user >insane. > >Lot of places deploy ssh/sftp instead of ftp for website updating. And >frankly, most end-users don't care why NT acts one way and VMS works >another. Exactly my point. They don't care. So let the systems do the work the way they're designed to do it! ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 20:25:02 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04996 for ; Tue, 13 May 2003 20:25:02 -0400 (EDT) Received: (qmail 19206 invoked by uid 605); 14 May 2003 00:28:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19196 invoked from network); 14 May 2003 00:28:00 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 14 May 2003 00:28:00 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUPFTA6ES9N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 18:27:56 -0700 (MST) Date: Tue, 13 May 2003 18:24:01 -0600 From: "Dan O'Reilly" Subject: RE: sftp rename not good. In-reply-to: <007101c319ab$f5a04810$0e01a8c0@CELLO> X-Sender: oreilly@raptor.psccos.com To: Howard Chu Cc: "'Nicolas Williams'" , ietf-ssh@netbsd.org, openssh@openssh.com Message-id: <5.2.0.9.2.20030513182249.00bab700@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <20030513163508.N4352@binky.central.sun.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 06:01 PM 5/13/2003, Howard Chu wrote: > > -----Original Message----- > > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On Behalf >Of Nicolas Williams > > > On Tue, May 13, 2003 at 05:29:51PM -0600, Dan O'Reilly wrote: > > > At 05:20 PM 5/13/2003, Nicolas Williams wrote: > > > >On Tue, May 13, 2003 at 03:22:37PM -0700, Alfred Perlstein wrote: > > > > > Now that scares me. :) My intention was to gather > > support for UNIX > > > > > semantics for this, not "whatever rename(2) does on the server". > > > > > > > >If the semantics of file renaming vary so much from platform to > > > >platform, without even the ability to reliably emulate one > > behaviour on > > > >all those platforms, then either that variance will have to carry > > > >through to SFTP or the SFTP server will have to have a way > > to tell the > > > >SFTP client what file rename semantics it supports so the > > client can > > > >choose which to use. > > > > > > Why should the client care at all? The basic requirement > > is "support a > > > rename function". Why should the client *SOFTWARE* (not > > USER) care how > > > the server system actually performs that? A VMS system > > should be allowed > > > to behave as a VMS system should when renaming a file; as > > should a UNIX > > > system or a Windows system. That's not client-specific. > > > > If the client doesn't care, then the semantics of rename > > should be upto > > the server (within some parameters? which parameters?). > > > > But I think the client cares, or, rather, this user cares :) :) > >I think that can be accomodated... If you are a VMS user, then you're already >familiar with how "rename" behaves on your VMS system. You could reasonably >expect that when you ftp/sftp to your system and perform a rename, the same >semantics that you already expect, are carried out. Likewise if you're a Unix >user connecting to a Unix server. > >I don't believe there's any mechanism for the client to connect to an >arbitrary server and say "I expect Unix semantics" though, nor do I think >there should be. When you're connecting to a foreign system, you get the >semantics that system supports. What's the big problem with that? I recall >countless ftp sessions to TOPS-20 servers and IBM mainframes, with their >weird 9-bit-per-byte words or their record-oriented filesystems. If you try >to force every system into a Unix-like interface, you make it impossible to >exchange files with these systems, that have no notion of flat octet-stream >files. > >Putting an artificial Unix-like wrapper over things seems like the wrong >approach. If I'm using VMS, I want my tools to act like every other VMS tool. Bless you, my son...... Seriously, I'm not trying to take a VMS-centric approach here. What I *am* saying is there are more filesystems out there that are different from the say UNIX does things. A truly flexible approach allows for that. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 21:39:46 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06631 for ; Tue, 13 May 2003 21:39:46 -0400 (EDT) Received: (qmail 25739 invoked by uid 605); 14 May 2003 01:42:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25730 invoked from network); 14 May 2003 01:42:41 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 14 May 2003 01:42:41 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4E1gex9003692; Tue, 13 May 2003 18:42:40 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4E1gduP020689; Tue, 13 May 2003 19:42:39 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4E1e5Qx000986; Tue, 13 May 2003 18:40:05 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4E1e59P000985; Tue, 13 May 2003 18:40:05 -0700 (PDT) Date: Tue, 13 May 2003 18:40:05 -0700 From: Nicolas Williams To: "Dan O'Reilly" Cc: Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513184005.O4352@binky.central.sun.com> Mail-Followup-To: Dan O'Reilly , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com References: <"from <20030513163508.N4352@binky.central.sun.com> <5.2.0.9.2.20030513181642.0245be78@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.2.0.9.2.20030513181642.0245be78@raptor.psccos.com>; from dano@process.com on Tue, May 13, 2003 at 06:19:16PM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, May 13, 2003 at 06:19:16PM -0600, Dan O'Reilly wrote: > At 05:35 PM 5/13/2003, Nicolas Williams wrote: > >If the client doesn't care, then the semantics of rename should be upto > >the server (within some parameters? which parameters?). > > > >But I think the client cares, or, rather, this user cares :) :) > > Well, actually, I agree with you, and you've made my point. The client > doesn't care, but the user does. And a user on a VMS system will expect > to see things done the way VMS does things, just as a user on a UNIX > system will expect to see things done with way UNIX does things. So, if > the functionality is left up to the server, it accomplishes that quick > nicely. Quite convincing. I'm afraid that scripted clients may nonetheless need to know what semantics are implemented on the server side, or at least what platform it is. But overall I agree with you, let the server do as it will, and possibly, give the client a hint. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 21:47:59 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06796 for ; Tue, 13 May 2003 21:47:59 -0400 (EDT) Received: (qmail 342 invoked by uid 605); 14 May 2003 01:50:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 334 invoked from network); 14 May 2003 01:50:57 -0000 Received: from shitei.mindrot.org (203.36.198.97) by mail.netbsd.org with SMTP; 14 May 2003 01:50:57 -0000 Received: from mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id 1860694214; Wed, 14 May 2003 11:50:00 +1000 (EST) Message-ID: <3EC1A0B7.2030101@mindrot.org> Date: Wed, 14 May 2003 11:49:43 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-au, en-gb, en, en-us, ja MIME-Version: 1.0 To: "Dan O'Reilly" Cc: Nicolas Williams , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. References: <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <"from bright"@mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> In-Reply-To: <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Dan O'Reilly wrote: >>Put a different way: if the semantics are irrelevant, then why are we >>even having this discussion? [...] > For example: in UNIX, it may be illegal to rename a file if one of the > same name exists. In VMS, it may or may not be illegal, depending on > if file versions are specified for the complete file specification supplied > to the rename function. So if we followed you suggestion and had sftp's rename method simply use the OS-supplied function, we would have clients that behave differently depending on the server. This would break, among other things, scripted/automated applications and would be a step back from where we are now (where we at least know the semantics of sftp's rename method). -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 21:55:52 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06938 for ; Tue, 13 May 2003 21:55:51 -0400 (EDT) Received: (qmail 3178 invoked by uid 605); 14 May 2003 01:58:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3171 invoked from network); 14 May 2003 01:58:51 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 14 May 2003 01:58:51 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA09108; Tue, 13 May 2003 18:58:34 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4E1wYNg018250; Tue, 13 May 2003 19:58:34 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4E1u0Qx001003; Tue, 13 May 2003 18:56:00 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4E1txtB001002; Tue, 13 May 2003 18:55:59 -0700 (PDT) Date: Tue, 13 May 2003 18:55:59 -0700 From: Nicolas Williams To: Damien Miller Cc: "Dan O'Reilly" , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030513185559.Q4352@binky.central.sun.com> Mail-Followup-To: Damien Miller , Dan O'Reilly , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com References: <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> <3EC1A0B7.2030101@mindrot.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3EC1A0B7.2030101@mindrot.org>; from djm@mindrot.org on Wed, May 14, 2003 at 11:49:43AM +1000 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, May 14, 2003 at 11:49:43AM +1000, Damien Miller wrote: > Dan O'Reilly wrote: > >>Put a different way: if the semantics are irrelevant, then why are we > >>even having this discussion? > > [...] > > > For example: in UNIX, it may be illegal to rename a file if one of the > > same name exists. In VMS, it may or may not be illegal, depending on > > if file versions are specified for the complete file specification supplied > > to the rename function. > > So if we followed you suggestion and had sftp's rename method simply use > the OS-supplied function, we would have clients that behave differently > depending on the server. > > This would break, among other things, scripted/automated applications > and would be a step back from where we are now (where we at least know > the semantics of sftp's rename method). Unless a) the server can tell the client what semantics to expect and b) the client can use that information to work in all cases; the sticking point is likely going to be about atomicity, but there's no guarantee that any user-land SFTP server implementation can provide atomicity on platforms that normally don't. As others have pointed out, humans may well cope with these variations in rename semantics, and as you point out it's the scripts that will have trouble - but can they be made to cope? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 22:23:09 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07448 for ; Tue, 13 May 2003 22:23:07 -0400 (EDT) Received: (qmail 16632 invoked by uid 605); 14 May 2003 02:26:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16622 invoked from network); 14 May 2003 02:25:59 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 14 May 2003 02:25:59 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUTJZAAXC9N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 20:25:52 -0700 (MST) Date: Tue, 13 May 2003 20:18:21 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: <20030513184005.O4352@binky.central.sun.com> X-Sender: oreilly@raptor.psccos.com To: Nicolas Williams Cc: Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Message-id: <5.2.0.9.2.20030513201643.00b85108@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <"from dano"@process.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 07:40 PM 5/13/2003, Nicolas Williams wrote: >On Tue, May 13, 2003 at 06:19:16PM -0600, Dan O'Reilly wrote: > > At 05:35 PM 5/13/2003, Nicolas Williams wrote: > > >If the client doesn't care, then the semantics of rename should be upto > > >the server (within some parameters? which parameters?). > > > > > >But I think the client cares, or, rather, this user cares :) :) > > > > Well, actually, I agree with you, and you've made my point. The client > > doesn't care, but the user does. And a user on a VMS system will expect > > to see things done the way VMS does things, just as a user on a UNIX > > system will expect to see things done with way UNIX does things. So, if > > the functionality is left up to the server, it accomplishes that quick > > nicely. > >Quite convincing. I'm afraid that scripted clients may nonetheless need >to know what semantics are implemented on the server side, or at least >what platform it is. But overall I agree with you, let the server do as >it will, and possibly, give the client a hint. I've often wondered why there wasn't a provision for that "hint"; some sort of optional part of some initialization message that the server could use to inform the client (and, I suppose, vice-versa) of what system is running. I have to believe there would be some good uses for that. ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 13 22:23:22 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07473 for ; Tue, 13 May 2003 22:23:21 -0400 (EDT) Received: (qmail 16872 invoked by uid 605); 14 May 2003 02:26:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16842 invoked from network); 14 May 2003 02:26:05 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 14 May 2003 02:26:05 -0000 Received: from ntbsod.process.com ([207.225.29.50]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KVUTJZAAXC9N3Z9Q@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Tue, 13 May 2003 20:25:58 -0700 (MST) Date: Tue, 13 May 2003 20:22:53 -0600 From: "Dan O'Reilly" Subject: Re: sftp rename not good. In-reply-to: <3EC1A0B7.2030101@mindrot.org> X-Sender: oreilly@raptor.psccos.com To: Damien Miller Cc: Nicolas Williams , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Message-id: <5.2.0.9.2.20030513201839.00bc7150@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <"from bright"@mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 07:49 PM 5/13/2003, Damien Miller wrote: >Dan O'Reilly wrote: > >>Put a different way: if the semantics are irrelevant, then why are we > >>even having this discussion? > >[...] > > > For example: in UNIX, it may be illegal to rename a file if one of the > > same name exists. In VMS, it may or may not be illegal, depending on > > if file versions are specified for the complete file specification supplied > > to the rename function. > >So if we followed you suggestion and had sftp's rename method simply use >the OS-supplied function, we would have clients that behave differently >depending on the server. Why in the world would the CLIENT behave differently? The client says "rename this file". The server does so, according to the rules of the system that the server is running on. Case closed. The client doesn't have to know *ANYTHING* about what the server is doing. Perhaps the USER might, but not the client itself. >This would break, among other things, scripted/automated applications >and would be a step back from where we are now (where we at least know >the semantics of sftp's rename method). How would it break them? I've seen that said, but nobody's done anything to show how it would break them. Besides, if you're going to a VMS system, don't you, as a user, kind of implicitly have to KNOW that if you're getting into some esoteric scripted stuff? You see what I'm saying, I hope: your solution is "treat everything as UNIX, regardless of what it REALLY is". And I'll make the point that the only supported (offically) sftp server in existence today is from my company anyway. There's not a whole heckuva lot of scripted stuff going to VMS, because it's brand new for that system (and I mean that literally). So, the idea of "it'll break scripted applications" is somewhat specious, since for VMS, they simply don't exist yet! ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 02:42:17 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07212 for ; Wed, 14 May 2003 02:42:16 -0400 (EDT) Received: (qmail 2291 invoked by uid 605); 14 May 2003 06:45:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2284 invoked from network); 14 May 2003 06:45:11 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 14 May 2003 06:45:11 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id CFA4E567D; Wed, 14 May 2003 08:44:54 +0200 (CEST) Message-ID: <3EC1E5F8.5010607@siliconcircus.com> Date: Wed, 14 May 2003 08:45:12 +0200 From: Jon Bright Organization: Silicon Circus Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dan O'Reilly" Cc: ietf-ssh@netbsd.org Subject: Re: sftp rename not good. References: <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <"from bright"@mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> <5.2.0.9.2.20030513201839.00bc7150@raptor.psccos.com> In-Reply-To: <5.2.0.9.2.20030513201839.00bc7150@raptor.psccos.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Dan O'Reilly wrote: > > Why in the world would the CLIENT behave differently? The client says I think you'd have to admit that for the Client's purposes, it's interesting to know whether a rename is going to overwrite an existing file or not. Irrespective of the Unix and VMS ways of doing things, it seems sensible to have a normal rename (which refuses to overwrite existing files) and a rename -f (which will overwrite where appropriate). *How* the server goes about providing those two very generalised facilities is a matter for the server... -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 02:46:37 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07284 for ; Wed, 14 May 2003 02:46:35 -0400 (EDT) Received: (qmail 4755 invoked by uid 605); 14 May 2003 06:49:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4748 invoked from network); 14 May 2003 06:49:34 -0000 Received: from elanus.its.uu.se (130.238.4.143) by mail.netbsd.org with SMTP; 14 May 2003 06:49:34 -0000 Received: from elanus (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7733B487A; Wed, 14 May 2003 08:49:33 +0200 (DFT) Received: from elanus.its.uu.se(127.0.0.1) by elanus.its.uu.se via virus-scan id s21002; Wed, 14 May 03 08:49:13 +0200 Received: from r3.ekonomikum.uu.se (dns.ekonomikum.uu.se [130.238.166.240]) by elanus.its.uu.se (Postfix) with ESMTP id 1CCC54972; Wed, 14 May 2003 08:48:05 +0200 (DFT) Received: (from pont@localhost) by r3.ekonomikum.uu.se (8.10.2+Sun/8.10.2) id h4E6m2n15987; Wed, 14 May 2003 08:48:02 +0200 (MEST) X-Authentication-Warning: r3.ekonomikum.uu.se: pont set sender to pont@soua.net using -f From: Pontus Skoeld To: "Dan O'Reilly" Cc: Damien Miller , Nicolas Williams , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. References: <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <"from bright"@mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> <5.2.0.9.2.20030513201839.00bc7150@raptor.psccos.com> Date: 14 May 2003 08:48:01 +0200 In-Reply-To: <5.2.0.9.2.20030513201839.00bc7150@raptor.psccos.com> Message-ID: Lines: 34 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA07284 "Dan O'Reilly" writes: > >So if we followed you suggestion and had sftp's rename method simply use > >the OS-supplied function, we would have clients that behave differently > >depending on the server. > > Why in the world would the CLIENT behave differently? The client says > "rename this file". The server does so, according to the rules of the > system that the server is running on. Case closed. The client doesn't > have to know *ANYTHING* about what the server is doing. Perhaps the > USER might, but not the client itself. The client may try to hide the sftp protocol and act like the user expects her normal system to act, which is probably what matters to her. She shouldn't need to know if someone decides to move her files from a UN*X box to a VMS server. (I'm not sure whatever that answers your question, but if the client wants to present a consistent "user experience", it would have to keep track of server peculiarities and work around those). Also, I think not specifying the semantics would make it harder to implement things like file system drivers (for mounting sftp sites as normal filesystems) and guess it could mean it takes even longer before programs like Adobe GoLive and Dreamweaver get sftp support, both those things are bad. That said, I do of course encourage everyone to make sure that we end up with good, useful semantics. /Pontus -- Pontus Sköld, see for more information. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 02:58:33 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07428 for ; Wed, 14 May 2003 02:58:32 -0400 (EDT) Received: (qmail 10034 invoked by uid 605); 14 May 2003 07:01:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10026 invoked from network); 14 May 2003 07:01:30 -0000 Received: from elvis.mu.org (192.203.228.196) by mail.netbsd.org with SMTP; 14 May 2003 07:01:30 -0000 Received: by elvis.mu.org (Postfix, from userid 1192) id 706BE2ED419; Wed, 14 May 2003 00:01:30 -0700 (PDT) Date: Wed, 14 May 2003 00:01:30 -0700 From: Alfred Perlstein To: "Dan O'Reilly" Cc: Nicolas Williams , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030514070130.GX65456@elvis.mu.org> References: <"fromdano"@process.com> <5.2.0.9.2.20030513201643.00b85108@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20030513201643.00b85108@raptor.psccos.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list * Dan O'Reilly [030513 19:26] wrote: > At 07:40 PM 5/13/2003, Nicolas Williams wrote: > >On Tue, May 13, 2003 at 06:19:16PM -0600, Dan O'Reilly wrote: > >> At 05:35 PM 5/13/2003, Nicolas Williams wrote: > >> >If the client doesn't care, then the semantics of rename should be upto > >> >the server (within some parameters? which parameters?). > >> > > >> >But I think the client cares, or, rather, this user cares :) :) > >> > >> Well, actually, I agree with you, and you've made my point. The client > >> doesn't care, but the user does. And a user on a VMS system will expect > >> to see things done the way VMS does things, just as a user on a UNIX > >> system will expect to see things done with way UNIX does things. So, if > >> the functionality is left up to the server, it accomplishes that quick > >> nicely. > > > >Quite convincing. I'm afraid that scripted clients may nonetheless need > >to know what semantics are implemented on the server side, or at least > >what platform it is. But overall I agree with you, let the server do as > >it will, and possibly, give the client a hint. > > I've often wondered why there wasn't a provision for that "hint"; some sort > of optional part of some initialization message that the server could use > to inform the client (and, I suppose, vice-versa) of what system is > running. I have to believe there would be some good uses for that. Isn't that somewhat like what ftp does? Afaik you used to see something like "remote system is UNIX" when logging in, maybe that was just infomative and not part of the spec though. -Alfred From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 03:02:49 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07499 for ; Wed, 14 May 2003 03:02:47 -0400 (EDT) Received: (qmail 11957 invoked by uid 605); 14 May 2003 07:05:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11947 invoked from network); 14 May 2003 07:05:47 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 14 May 2003 07:05:47 -0000 Received: from CELLO (c-24-126-120-178.we.client2.attbi.com [24.126.120.178]) by carnelian.propagation.net (8.9.3p2/8.8.5) with SMTP id CAA26468; Wed, 14 May 2003 02:05:21 -0500 From: "Howard Chu" To: "'Pontus Skoeld'" , "'Dan O'Reilly'" Cc: "'Damien Miller'" , "'Nicolas Williams'" , "'Alfred Perlstein'" , "'Joseph Galbraith'" , , "'Markus Friedl'" , Subject: RE: sftp rename not good. Date: Wed, 14 May 2003 00:05:02 -0700 Message-ID: <008501c319e7$2c5084c0$0e01a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-To: Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On Behalf Of Pontus Skoeld > "Dan O'Reilly" writes: > > > >So if we followed you suggestion and had sftp's rename > method simply use > > >the OS-supplied function, we would have clients that > behave differently > > >depending on the server. > > > > Why in the world would the CLIENT behave differently? The > client says > > "rename this file". The server does so, according to the > rules of the > > system that the server is running on. Case closed. The > client doesn't > > have to know *ANYTHING* about what the server is doing. Perhaps the > > USER might, but not the client itself. > > The client may try to hide the sftp protocol and act like the user > expects her normal system to act, which is probably what matters to > her. She shouldn't need to know if someone decides to move her files > from a UN*X box to a VMS server. This statement implies a situation where the client is not expected to know anything about the remote server. In practice, this situation is non-sensical. You cannot connect to the server in the first place unless you're either a regular user of that system, or you have made a special pre-arrangement to obtain an account on that system. You certainly won't have write privileges to rename arbitrary files on a server that is completely unknown to you. Theoretical discussions about what might cause problems may be an interesting intellectual diversion, but they are just that - *diversions*. Real users will have knowledge about the remote server that they're operating on. To assume the client has no knowledge of the server is pointless. > That said, I do of course encourage everyone to make sure that we end > up with good, useful semantics. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 03:28:00 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08105 for ; Wed, 14 May 2003 03:27:59 -0400 (EDT) Received: (qmail 22827 invoked by uid 605); 14 May 2003 07:30:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22820 invoked from network); 14 May 2003 07:30:58 -0000 Received: from outpost.oankali.net (207.106.87.68) by mail.netbsd.org with SMTP; 14 May 2003 07:30:58 -0000 Received: from h000393b62a98.ne.client2.attbi.com (h000393b62a98.ne.client2.attbi.com [65.96.185.9]) (authenticated bits=0) by outpost.oankali.net (8.12.8/8.12.2) with ESMTP id h4E7TXbE027592 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 14 May 2003 03:29:34 -0400 (EDT) Date: Wed, 14 May 2003 03:30:58 -0400 (EDT) From: Richard Silverman X-X-Sender: res@h000393b62a98.ne.client2.attbi.com To: Damien Miller cc: "Dan O'Reilly" , Nicolas Williams , Alfred Perlstein , Joseph Galbraith , "" , Markus Friedl , "" Subject: Re: sftp rename not good. In-Reply-To: <3EC1A0B7.2030101@mindrot.org> Message-ID: References: <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <"from bright"@mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> <3EC1A0B7.2030101@mindrot.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list I think this disagreement reflects a more basic difference of opinion on the purpose of the sftp protocol, which needs to be resolved. One side views sftp as defining a fully abstract storage mechanism, having its own internally consistent semantics which all compliant implementations must uphold. The constraint might be stated thus: "Given a sequence S of sftp operations, and an sftp-observable initial state I, the sftp-observable result state R of executing S from I must be the same on any implementation." In other words, one purpose of sftp is to hide the details of server host operation in favor of a predictable storage abstraction. The other side of the fence says no, no -- the purpose of sftp is to provide convenient remote manipulation of a host's filesystem, in such a way as to be as familiar as possible to users of the host OS. Thus, each implementation should be free to choose mappings of basic sftp operations (such as SSH_FXP_RENAME) onto the server's filesystem primitives, in a way its authors think will be most useful and familiar to users. In non-obvious cases, users will have no way of knowing what the mapping will be, short of reading the software documentation (not the protocol spec), or just trying it out. Dan O'Reilly points out that this is what many of his users expect -- the underlying assumption here is that the "user" is first and foremost a user of the host OS, merely employing sftp as a way to get at some files when not directly logged into the host. While I agree this is a common scenario, it is not the only one. Equally valid is the following: the user employs an sftp client as his *sole* method of accessing some file store; he has never logged into the host, nor does he know or care what OS it's running. One day, the systems department replaces the server with a new machine running a different OS, but also with an sftp server. Our putative user then performs some sequence of file manipulations he's done many times before -- but gets different results! He screams, because wasn't using a consistent abstraction supposed to protect him from this sort of thing? Well, that's the question: is sftp supposed to afford such protection, or not? Despite the inherent elegance of a fully-abstract model, and its advantages in some situations, I have to (reluctantly) say that model #2 is probably the way to go, for a number of reasons: 1) The sftp spec as it stands does not articulate or support viewpoint #1 at all. There is no requirement for fully abstract operation, and in fact, there is recognition of the opposite principle; from section 6.2 (File Names): "... It is understood that the lack of well-defined semantics for file names may cause interoperability problems between clients and servers using radically different operating systems. However, this approach is known to work acceptably with most systems, and alternative approaches that e.g. treat file names as sequences of structured components are quite complicated." 2) The two models solve related but different problems. One is remote access to different filesystem types via a usable least-common-denominator protocol, which will necessarily have some limitations. The other is defining a consistent, server-independent remote filing protocol. While the second problem is valid and could use a solution, I think in reality sftp is more geared toward solving the first. 3) The fully-abstract requirement will severely limit and complicate implementation. For example, the Mac OS X HFS+ filesystem is case-preserving but not case-sensitive. In a directory containing files "foo" and "bar", the result of renaming "foo" -> "Bar" using naive server-side semantics is going to be *very* different from what a user of a traditional Unix system would expect! If abstract operation required case-sensitivity, how would you implement that on the server? And would it make any sense to someone logging into the server and viewing the result? 4) Given that people *will* be accessing files both via sftp and via the host OS, it gets worse -- even if the fully-abstract requirement stated earlier is met, there's no guarantee the user will be happy with the server-side result. For example: NTFS allows multiple streams per file. Sftp has no notion of that, and I imagine that all extant Windows sftp implementations simply read stream 0. The sftp operation sequence "create bar; open foo; read foo; write bar; delete foo" will be sftp-observably identical to "rename foo -> bar" (atomicity and concurrency issues aside for the moment)... but again with naive server-side semantics, one will probably end up trashing a multi-stream file, while the other preserves it. - Richard Silverman slade@shore.net From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 03:37:14 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08323 for ; Wed, 14 May 2003 03:37:14 -0400 (EDT) Received: (qmail 27007 invoked by uid 605); 14 May 2003 07:40:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26968 invoked from network); 14 May 2003 07:40:04 -0000 Received: from outpost.oankali.net (207.106.87.68) by mail.netbsd.org with SMTP; 14 May 2003 07:40:04 -0000 Received: from h000393b62a98.ne.client2.attbi.com (h000393b62a98.ne.client2.attbi.com [65.96.185.9]) (authenticated bits=0) by outpost.oankali.net (8.12.8/8.12.2) with ESMTP id h4E7drbE016541 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 14 May 2003 03:39:54 -0400 (EDT) Date: Wed, 14 May 2003 03:41:19 -0400 (EDT) From: Richard Silverman X-X-Sender: res@h000393b62a98.ne.client2.attbi.com To: Howard Chu cc: SECSH Discussion List , "" Subject: RE: sftp rename not good. In-Reply-To: <008501c319e7$2c5084c0$0e01a8c0@CELLO> Message-ID: References: <008501c319e7$2c5084c0$0e01a8c0@CELLO> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list > This statement implies a situation where the client is not expected to know > anything about the remote server. In practice, this situation is > non-sensical. You cannot connect to the server in the first place unless > you're either a regular user of that system, or you have made a special > pre-arrangement to obtain an account on that system. You certainly won't have > write privileges to rename arbitrary files on a server that is completely > unknown to you. Theoretical discussions about what might cause problems may > be an interesting intellectual diversion, but they are just that - > *diversions*. Real users will have knowledge about the remote server that > they're operating on. > > To assume the client has no knowledge of the server is pointless. I completely disagree with this statement. It is a perfectly possible to give someone an account on a system for the sole purpose of (and limited to) sftp access. The user may never log into the directly, or even know what the host OS is or how to use it; it acts as an opaque sftp file server. This situation is neither nonsensical nor pointless; on the contrary, it is useful and reasonably common, follows normal and useful principles of abstraction, and is likely to become more common as sftp becomes more widely implemented. - Richard Silverman slade@shore.net From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 04:00:55 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08867 for ; Wed, 14 May 2003 04:00:55 -0400 (EDT) Received: (qmail 8754 invoked by uid 605); 14 May 2003 08:03:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8746 invoked from network); 14 May 2003 08:03:54 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 14 May 2003 08:03:54 -0000 Received: from CELLO (c-24-126-120-178.we.client2.attbi.com [24.126.120.178]) by carnelian.propagation.net (8.9.3p2/8.8.5) with SMTP id DAA01361; Wed, 14 May 2003 03:03:32 -0500 From: "Howard Chu" To: "'Richard Silverman'" Cc: "'SECSH Discussion List'" , Subject: RE: sftp rename not good. Date: Wed, 14 May 2003 01:03:17 -0700 Message-ID: <008601c319ef$4d802df0$0e01a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-To: Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Richard Silverman [mailto:slade@shore.net] > > This statement implies a situation where the client is not > expected to know > > anything about the remote server. In practice, this situation is > > non-sensical. You cannot connect to the server in the first > place unless > > you're either a regular user of that system, or you have > made a special > > pre-arrangement to obtain an account on that system. You > certainly won't have > > write privileges to rename arbitrary files on a server that > is completely > > unknown to you. Theoretical discussions about what might > cause problems may > > be an interesting intellectual diversion, but they are just that - > > *diversions*. Real users will have knowledge about the > remote server that > > they're operating on. > > > > To assume the client has no knowledge of the server is pointless. > > I completely disagree with this statement. It is a perfectly > possible to > give someone an account on a system for the sole purpose of > (and limited > to) sftp access. The user may never log into the directly, > or even know > what the host OS is or how to use it; it acts as an opaque sftp file > server. This situation is neither nonsensical nor pointless; on the > contrary, it is useful and reasonably common, follows normal > and useful > principles of abstraction, and is likely to become more common as sftp > becomes more widely implemented. Yes, it is possible to do what you describe. It is also possible for the user to call you up when they have a problem or get confused. Legitimate users have access to information about the system they're using, because they have access to whoever gave them the account in the first place. As I said, the client is either a regular user or has gotten pre-arranged access to the server. If you're giving out accounts to your server, you should expect to provide support for those accounts, even if "support" consists merely of a README file. If you hand out accounts to users without telling them how to use them, you have a different problem, and that's certainly outside the realm of SSH to address. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 04:35:59 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09446 for ; Wed, 14 May 2003 04:35:58 -0400 (EDT) Received: (qmail 22963 invoked by uid 605); 14 May 2003 08:38:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22954 invoked from network); 14 May 2003 08:38:57 -0000 Received: from shitei.mindrot.org (203.36.198.97) by mail.netbsd.org with SMTP; 14 May 2003 08:38:57 -0000 Received: from mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id A5AC99420B; Wed, 14 May 2003 18:37:56 +1000 (EST) Message-ID: <3EC20056.6050302@mindrot.org> Date: Wed, 14 May 2003 18:37:42 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-au, en-gb, en, en-us, ja MIME-Version: 1.0 To: ietf-ssh@netbsd.org Cc: "'Alfred Perlstein'" Subject: Re: sftp rename not good. References: <008501c319e7$2c5084c0$0e01a8c0@CELLO> In-Reply-To: <008501c319e7$2c5084c0$0e01a8c0@CELLO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Howard Chu wrote: >> The client may try to hide the sftp protocol and act like the user >> expects her normal system to act, which is probably what matters to >> her. She shouldn't need to know if someone decides to move her files >> from a UN*X box to a VMS server. > > This statement implies a situation where the client is not expected to know > anything about the remote server. In practice, this situation is > non-sensical. That is bogus: many ISPs and hosting providers provide ssh and sftp access to their servers without disclosing details about the OS environment. All the user knows is an IP address, a username and a password. Chances are, right now, that these are running an Unix-like OS of some sort, but there are no guarantees. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 04:55:54 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09803 for ; Wed, 14 May 2003 04:55:54 -0400 (EDT) Received: (qmail 3153 invoked by uid 605); 14 May 2003 08:58:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2749 invoked from network); 14 May 2003 08:58:08 -0000 Received: from carnelian.propagation.net (209.164.120.1) by mail.netbsd.org with SMTP; 14 May 2003 08:58:08 -0000 Received: from CELLO (c-24-126-120-178.we.client2.attbi.com [24.126.120.178]) by carnelian.propagation.net (8.9.3p2/8.8.5) with SMTP id DAA09489; Wed, 14 May 2003 03:57:19 -0500 From: "Howard Chu" To: "'Damien Miller'" , Cc: "'Alfred Perlstein'" Subject: RE: sftp rename not good. Date: Wed, 14 May 2003 01:57:06 -0700 Message-ID: <008801c319f6$d13ab280$0e01a8c0@CELLO> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-To: <3EC20056.6050302@mindrot.org> Importance: Normal Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On Behalf Of Damien Miller > Howard Chu wrote: > >> The client may try to hide the sftp protocol and act like the user > >> expects her normal system to act, which is probably what matters to > >> her. She shouldn't need to know if someone decides to move > her files > >> from a UN*X box to a VMS server. > > > > This statement implies a situation where the client is not > expected to know > > anything about the remote server. In practice, this situation is > > non-sensical. > > That is bogus: many ISPs and hosting providers provide ssh and sftp > access to their servers without disclosing details about the OS > environment. All the user knows is an IP address, a username > and a password. > > Chances are, right now, that these are running an Unix-like OS of some > sort, but there are no guarantees. Details, no. But everyone operates under a certain set of assumptions. This works today precisely because the vast majority of SPs use Unix servers. And most ISPs explicitly advertise "Unix hosted" or "Windows hosted" or whatever, it's a selling point in itself. If you sign up with an ISP and all they give you is an IP address, username, and a password on an IBM mainframe running OS/390, with a "home directory" residing in a partitioned data set, you can bet that (a) all of your unspoken assumptions about how the host behaves will be wrong and (b) you will need to call tech support very early on. The vast majority of The Internet today runs on Unix systems, using hierarchical filesystems with forward-slashes as pathname separators, and so a majority of people are accustomed to working with their servers in a particular manner. Even if no one handed them docs for it, that does *not* mean they have zero information about the server, it means they're operating on implicit information. There's a big difference between that and using a system with zero information. You cannot use a server without knowledge of how the server behaves. When you are a legitimate user of a server, you also have legitimate access to information about the server - whoever provides your account has no choice but to give you this information. The information may just be "it works just like your PC" or it may be a detailed guidebook, but the information is there nonetheless. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 09:21:25 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17178 for ; Wed, 14 May 2003 09:21:24 -0400 (EDT) Received: (qmail 23385 invoked by uid 605); 14 May 2003 13:24:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23276 invoked from network); 14 May 2003 13:24:15 -0000 Received: from etoh.eviladmin.org (206.145.58.62) by mail.netbsd.org with SMTP; 14 May 2003 13:24:15 -0000 Received: from etoh.eviladmin.org (mouring@localhost.eviladmin.org [127.0.0.1]) by etoh.eviladmin.org (8.12.6/8.12.6) with ESMTP id h4EDJiaQ027570; Wed, 14 May 2003 08:19:44 -0500 (CDT) Received: from localhost (mouring@localhost) by etoh.eviladmin.org (8.12.6/8.12.6/Submit) with ESMTP id h4EDJh0l020792; Wed, 14 May 2003 08:19:44 -0500 (CDT) Date: Wed, 14 May 2003 08:19:43 -0500 (CDT) From: Ben Lindstrom To: Pontus Skoeld cc: "Dan O'Reilly" , Alfred Perlstein , Joseph Galbraith , , Subject: Re: sftp rename not good. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list [..] > Also, I think not specifying the semantics would make it harder to > implement things like file system drivers (for mounting sftp sites as > normal filesystems) and guess it could mean it takes even longer > before programs like Adobe GoLive and Dreamweaver get sftp support, > both those things are bad. > Dreamweaver MX supports sftp. - Ben From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 10:16:32 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19674 for ; Wed, 14 May 2003 10:16:31 -0400 (EDT) Received: (qmail 23811 invoked by uid 605); 14 May 2003 14:19:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23804 invoked from network); 14 May 2003 14:19:30 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 14 May 2003 14:19:30 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4EEJOx9025375; Wed, 14 May 2003 07:19:24 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4EEJNuP019108; Wed, 14 May 2003 08:19:23 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4EEGmQx001344; Wed, 14 May 2003 07:16:48 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4EEGkuP001343; Wed, 14 May 2003 07:16:46 -0700 (PDT) Date: Wed, 14 May 2003 07:16:46 -0700 From: Nicolas Williams To: Pontus Skoeld Cc: "Dan O'Reilly" , Damien Miller , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com Subject: Re: sftp rename not good. Message-ID: <20030514071646.V4352@binky.central.sun.com> Mail-Followup-To: Pontus Skoeld , Dan O'Reilly , Damien Miller , Alfred Perlstein , Joseph Galbraith , ietf-ssh@netbsd.org, Markus Friedl , openssh@openssh.com References: <20030513111917.GO65456@elvis.mu.org> <20030513153216.GB24601@folly> <20030513185443.GQ65456@elvis.mu.org> <007501c31985$dc92d160$4d00a8c0@galb.vandyke.com> <5.2.0.9.2.20030513161344.00bcdde8@raptor.psccos.com> <20030513222237.GT65456@elvis.mu.org> <5.2.0.9.2.20030513172806.0245be78@raptor.psccos.com> <5.2.0.9.2.20030513181927.00b80a40@raptor.psccos.com> <5.2.0.9.2.20030513201839.00bc7150@raptor.psccos.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pont_secsh@soua.net on Wed, May 14, 2003 at 08:48:01AM +0200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, May 14, 2003 at 08:48:01AM +0200, Pontus Skoeld wrote: > "Dan O'Reilly" writes: > > > >So if we followed you suggestion and had sftp's rename method simply use > > >the OS-supplied function, we would have clients that behave differently > > >depending on the server. > > > > Why in the world would the CLIENT behave differently? The client says > > "rename this file". The server does so, according to the rules of the > > system that the server is running on. Case closed. The client doesn't > > have to know *ANYTHING* about what the server is doing. Perhaps the > > USER might, but not the client itself. > > The client may try to hide the sftp protocol and act like the user > expects her normal system to act, which is probably what matters to > her. She shouldn't need to know if someone decides to move her files > from a UN*X box to a VMS server. Even on one platform some filesystem semantics can change from one fs type to another (think NTFS vs. FAT32 or UFS vs FAT floppies). Why should the client try so hard to hide the differences? And SFTP is not a remote file system protocol; you can use NFSv4 if what you want is a multi-platform file system protocol. SFTP already borrows from NFSv4; perhaps this tradition should be followed in this case: what's good for NFSv4 should be good for SFTP. > (I'm not sure whatever that answers your question, but if the client > wants to present a consistent "user experience", it would have to keep > track of server peculiarities and work around those). Atomicity differences may not be possible to hide. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 11:26:30 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21682 for ; Wed, 14 May 2003 11:26:30 -0400 (EDT) Received: (qmail 8188 invoked by uid 605); 14 May 2003 15:29:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8181 invoked from network); 14 May 2003 15:29:29 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 14 May 2003 15:29:29 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1519661; Wed, 14 May 2003 09:29:28 -0600 Message-ID: <011501c31a2d$9bd369c0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Silverman" , "Howard Chu" Cc: "SECSH Discussion List" , References: <008501c319e7$2c5084c0$0e01a8c0@CELLO> Subject: Re: sftp rename not good. Date: Wed, 14 May 2003 09:29:28 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > This statement implies a situation where the client is not expected to know > > anything about the remote server. In practice, this situation is > > non-sensical. You cannot connect to the server in the first place unless > > you're either a regular user of that system, or you have made a special > > pre-arrangement to obtain an account on that system. You certainly won't have > > write privileges to rename arbitrary files on a server that is completely > > unknown to you. Theoretical discussions about what might cause problems may > > be an interesting intellectual diversion, but they are just that - > > *diversions*. Real users will have knowledge about the remote server that > > they're operating on. > > > > To assume the client has no knowledge of the server is pointless. > > I completely disagree with this statement. It is a perfectly possible to > give someone an account on a system for the sole purpose of (and limited > to) sftp access. The user may never log into the directly, or even know > what the host OS is or how to use it; it acts as an opaque sftp file > server. This situation is neither nonsensical nor pointless; on the > contrary, it is useful and reasonably common, follows normal and useful > principles of abstraction, and is likely to become more common as sftp > becomes more widely implemented. Precisely. Much of this discussion has focused around one type of user. The VMS user sitting someplace else accessing his VMS files remotely. (Replace VMS with any other operating system you'd like, in both places.) In practice, I see at least one other scenerio is extremely common. The Windows user, sitting at a windows box, accessing files on some other platform. For example, managing a website on a unix server. This user has some minimal experience on the host operating system, but is not and doesn't want to be intimately familar with the host operating system. And the question they ask me, is "Why doesn't it behave just like every other windows program." It is a reasonable expectation: the sftp client they are running is a windows program. It presents their files like windows does. They have every right to expect it to manipulate those files in the manner they are most familar with: windows. (Again, substitute windows in all locations with any other OS of your choice.) - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 16:24:06 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04076 for ; Wed, 14 May 2003 16:24:04 -0400 (EDT) Received: (qmail 26028 invoked by uid 605); 14 May 2003 20:27:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26021 invoked from network); 14 May 2003 20:27:03 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by mail.netbsd.org with SMTP; 14 May 2003 20:27:03 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4EKR2oe020798 for ; Wed, 14 May 2003 13:27:02 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA24139 for ; Wed, 14 May 2003 13:27:01 -0700 (PDT) Date: Wed, 14 May 2003 13:27:01 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: New Proposal for Section 11.3.3 X11 Forwarding In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Folks, I'm trying to work in all of the suggestions for improvements in the text. It's a bit ungainly to put all of that in a single note so I'm separating it into subsections. Here's a rewrite of 11.3.3. Below that is a grouping of comments I've seen on this thread. Please make comments on this text. Specific textual contributions will be especially appreciated. Thanks, Chris ========================================================================== 11.3.3 X11 Forwarding Another form of proxy forwarding provided by the ssh connection protocol is the forwarding of the X11 protocol. If end-point security has been compromised, X11 forwarding may allow attacks against the X11 server. Users and administrators should, as a matter of course, use all available X11 security mechanisms to prevent unauthorized use of the X11 server. Implementors, administrators and users who wish to further explore the security mechanisms of X11 are invited to read [SCHEIFLER] and analyze previously reported problems with the interactions between SSH forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 [CERT]. Additionally, they are advised to review the problems found and the lessons learned in a paper by Wietse Venema [Venema] presented to the 6th USENIX Security Symposium. Implementors of the X11 forwarding protocol SHOULD implement the magic cookie access checking spoofing mechanism as described in [ssh-connect] as an additional mechanism to prevent unauthorized use of the proxy. [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, February 1992. [CERT] The CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 U.S.A. ( http://www.cert.org/nav/index_red.html ) [ssh-connect] ssh-connect ID to be replaced with the RFC information when available [Venema] Wietse Venema, "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose, CA, July 1996. http://www.usenix.org/publications/library/proceedings/sec96/venema.html ---Notes--- [RJA: Which "X11 security mechanism" is meant ? [RJA: Also, please add a citation for that mechanism. [JG: Well, I didn't have a particular one in mind. The [JG: advice is to use any X11 security mechanism. I'd [JG: be willing to remove the paragraph. [RJA: I'd like to keep text encouraging folks to use as much [RJA: security as they can. I'm not an expert on the security [RJA: properties of X11. I was thinking that there probably were [RJA: some specific security mechanisms (e.g. my vague recollection [RJA: of the MIT-magic-cookie hack noted above) that we ought [RJA: to mention and cite. ---Nico---vv Well, the MIT magic cookie approach is about the only one truly in use and, IMO, it is sufficient for the purposes of SSHv2. ---Nico---^^ ---Joseph---vv I would suggest the following two citations for this section: [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, Feburary 1992. and draft-ietf-secsh-connect-16.txt, section 4.3.1., "Requesting X11 Forwarding" ---Joseph---^^ ---Nico---vv Er, sure. I'm not very familiar with the X11 standards, so I'm not sure what would be a good reference. Apparently X.ORG and the Open Group own the X11 standards now. A quick search through X.org and XFree86.org yielded little conclusive information, but a further search finally yielded: http://www.xfree86.org/4.3.0/XStandards.7.html Likely the best reference is: X Window System Protocol X Version 11, Release 6.4 Robert W. Scheifler ---Nico---^^ ---Ran---vv It turns out that the X11 cookie security has significant issues. A good reference for folks here to read might be: Wietse Venema, "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose, CA, July 1996. It is likely that the above paper can be downloaded from USENIX, http://www.usenix.org. I don't know the correct URL for that paper, so one would have to browse to find it. Also, if we reach back to 1997, there were other issues identified: http://lists.insecure.org/lists/bugtraq/1997/Sep/0062.html I'm not comfortable with the current text on X11, though I'm only one person... ---Ran---^^ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 16:47:03 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04745 for ; Wed, 14 May 2003 16:47:02 -0400 (EDT) Received: (qmail 8607 invoked by uid 605); 14 May 2003 20:50:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8582 invoked from network); 14 May 2003 20:50:00 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 14 May 2003 20:50:00 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4EKnwfK016067 for ; Wed, 14 May 2003 13:49:58 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA11507 for ; Wed, 14 May 2003 13:49:58 -0700 (PDT) Date: Wed, 14 May 2003 13:49:58 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: New Proposal for Section 11.2.3 Local Security Policy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, Continuing on with Section 11.2.3. Please comment. Thanks, Chris ===================================================================== 11.2.3 Local Security Policy Implementer MUST ensure that the credentials provided validate the professed user and also MUST ensure that the local policy of the server permits the user the access requested. In particular, because of the flexible nature of the SSH connection protocol, it may not be possible to determine the local security policy, if any, that should apply at the time of authentication because the kind of service being requested is not clear at that instant. For example, local policy might allow a user to access files on the server, but not start an interactive shell. However, during the authentication protocol, it is not known whether the user will be accessing files or attempting to use an interactive shell, or even both. In any event, where local security policy for the server host exists, it MUST be applied and enforced correctly. Implementors are encouraged to provide a default local policy and make its parameters known to administrators and users. At the discretion of the implementors, this default policy may be along the lines of 'anything goes' where there are no restrictions placed upon users, or it may be along the lines of 'excessively restrictive' in which case the administrators will have to actively make changes to this policy to meet their needs. Alternatively, it may be some attempt at providing something practical and immediately useful to the administrators of the system so they don't have to put in much effort to get SSH working. Whatever choice is made MUST be applied and enforced as required above. ---Notes--- [Nico: What if no policy is available? ---Joseph---vv Then there is nothing to enforce? ---Nico---vv The implementation MUST provide a default policy, either the "null" policy (anything goes) or a highly restrictive policy (the client can establish an SSHv2 connection but do nothing with it other than close it :). ---Nico---^^ Perhaps we should say, In any event, where local security policy for the server host exists, it MUST be applied and enforced correctly. and sprinkle a few 'if any' around judiciously. ---Joseph---^^ ---Nico---vv Sure. ---Nico---^^ ---Ran---vv Those proposed edits seem reasonable to me. ---Ran---^^ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 17:36:38 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06895 for ; Wed, 14 May 2003 17:36:33 -0400 (EDT) Received: (qmail 10089 invoked by uid 605); 14 May 2003 21:39:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10082 invoked from network); 14 May 2003 21:39:21 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 14 May 2003 21:39:21 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4ELdJfK019786 for ; Wed, 14 May 2003 14:39:20 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA22226 for ; Wed, 14 May 2003 14:39:19 -0700 (PDT) Date: Wed, 14 May 2003 14:39:19 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: New Proposal for Section 11.1.3 Replay In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, Moving right along, another edit for your perusal. Thanks, Chris =================================================================== 11.1.3 Replay This protocol binds each session key to the session by including random data that is specific to the session in the hash used to produce session keys. If the random data here (e.g., DH parameters) are pseudo-random then the PRNG should be cryptographically secure (i.e., its next output not easily guessed, even when knowing all previous outputs) and, furthermore, the PRNG should be seeded with some truly random inputs, or as random as can be available. In any case, the amount of entropy available to a given client or server sometimes may be less than what is needed to run the protocol, in which case either one must resort to PRNGs anyways or refuse to run the protocol. In practice implementors will generally rely on some PRNG. RFC 1750 [1750] contains more discussion on this. The use of a MAC other than 'none' provides integrity and authentication. In addition, the transport protocol provides a unique session identifier (bound in part to pseudo-random data that is part of the algorithm and key exchange process) that can be used by higher level protocols to bind data to a given session and prevent replay of data from prior sessions. For example, the authentication protocol uses this to prevent replay of signatures from previous sessions. Because public key authentication exchanges are cryptographically bound to the session (i.e., to the initial key exchange) they cannot be successfully replayed in other sessions. Note that the session ID can be made public without harming the security of the protocol. If two session happen to have the same session ID [hash of key exchanges] then packets from one can be replayed against the other. It must be stressed that the chances of such an occurrence are, needless to say, minimal when using modern cryptographic methods. This is all the more so true when specifying larger hash function outputs and DH parameters. Replay detection using monotonically increasing sequence numbers as input to the MAC, or HMAC in some cases, is described in RFC 2085 [2085], RFC 2246 [2246], RFC 2743 [2743], RFC 1964 [1964], RFC 2025 [2025], and RFC 1510 [1510]. The underlying construct is discussed in RFC 2104 [2104]. Essentially a different sequence number in each packet ensures that at least this one input to the MAC function will be unique and will provide a nonrecurring MAC output that is not predictable to an attacker. If the session stays active long enough, however, this sequence number will wrap. This event may provide an attacker an opportunity to replay a previously recorded packet with an identical sequence number but only if the peers have not rekeyed since the transmission of the first packet with that sequence number. If the peers have rekeyed, then the replay will be detected as the MAC check will fail. For this reason, it must be emphasized that peers MUST rekey before a wrap of the sequence numbers. Naturally, if an attacker does attempt to replay a captured packed before the peers have rekeyed, then the receiver of the duplicate packet will see that it has the sequence number of a packet that has already been received and will discard it. [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [2246] TLS [2085] IPsec AH [2104] HMAC [2743] GSS-API [1964] The KerberosV GSS-API mechanism [2025] SPKM [1510] Kerberos V ---Notes--- [RJA: I imagine that a sequence number does help preclude replay attacks, [RJA: but I was hoping that someone else had actually done some analysis [RJA: that we could cite to justify the claim that this MAC combined with [RJA: this kind of sequence numbering would actually provide replay [RJA: attack prevention. ---Joseph---vv If no one knows of something to cite here, I'm not sure what to do at this point? Baring someone stepping forward witht the requested citation, what should we do? I'd like to move forward. ---Joseph---^^ ---Nico---vv Er, this is a time-honored technique. Examples of protocols that support the use of sequence numbers as a replay detection technique are: - GSS-API (generally) [RFC2743] - The KerberosV GSS-API mechanism (specifically) [RFC1964] - The Simple Public-Key GSS-API Mechanism (SPKM) (specifically) [RFC2025] - Kerberos V [RFC1510] - TLS 1.0 [RFC2246] Need I go on? Probably not. Each of those documents makes reference to the use of sequence numbers for replay and out-of-sequence detection. ---Nico---^^ ---Ran---vv Generic comment (applies to above and other places): I'd rather delete a claim that the WG can't clearly justify than have this document accidentally make a claim that later turns out to be inaccurate or misleading. ---Ran--^^ ---Heikki---vv I for one believe replay protection is an important property for the protocol and I would like this claim to remain in the documents. IpSec AH uses sequence number with HMAC for replay protection (rfc2085), so does TLS (rfc2246). HMAC security considerations are discussed in rfc2104. The document describes security of the construct in general, and I believe the replay protection scheme is a small subset compared to that, given the so many bits an attacker can affect (sequence number, padding). How about "to our best knowledge"? ---Heikki---^^ ---Ran---vv Does someone want to try to construct a rationale for the document about why folks believe the attempted replay protection actually works ? Barring that, maybe the words should be more tentative (edit to taste): Through the use of a sequence number and ... and ..., the SSH specification seeks to provide protection against replay attacks. ---Ran---^^ ---Heikki---vv I'm not much of an editor, but maybe someone can slash something out of the following: Running sequence number gives us an unique input for the MAC function regardless of the contents of the packet, as long as the sequence number doesn't wrap. With rekeying before the sequence number wraps, we get an unique input into the MAC function (well, HMAC at least) regardless of the sequence counter wrapping. If an attacker captures a packet and inserts it within the SSH stream in order to replay the packet, either the sequence number or the MAC key will be different, and the MAC check will fail. We assume MAC is secure of course, specifically it being infeasible to construct x' such that MAC(x) = MAC(x'). For HMACs it is discussed in rfc 2104. I don't know if it's relevant or not, but given that an attacker wants to re-use data from the packet, there are even less bits to work with, and, even less of a chance of succeeding in creating a valid MAC. ---Heikki---^^ ---Chris---vv I'm going to put that last part into the MITM section rather than here in the Replay section. ---Chris---^^ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 14 18:23:36 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08928 for ; Wed, 14 May 2003 18:23:36 -0400 (EDT) Received: (qmail 4283 invoked by uid 605); 14 May 2003 22:26:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4276 invoked from network); 14 May 2003 22:26:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 14 May 2003 22:26:36 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1520768; Wed, 14 May 2003 16:26:35 -0600 Message-ID: <023501c31a67$e0d36590$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Chris Lonvick" , References: Subject: Re: New Proposal for Section 11.1.3 Replay Date: Wed, 14 May 2003 16:26:35 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Naturally, if an > attacker does attempt to replay a captured packed before the peers > have rekeyed, then the receiver of the duplicate packet will see that > it has the sequence number of a packet that has already been received > and will discard it. The packet sequence number is not actually sent on the wire, but is maintained independantly by each side. If an attacker replays a captured packet, it will be input into the mac routines with the next valid sequence number. Since that is not the sequence number that was used in the original computation of the mac, it will show up as a MAC error. Thanks, Chris, for compiling these. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 00:20:20 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA14886 for ; Thu, 15 May 2003 00:20:19 -0400 (EDT) Received: (qmail 8435 invoked by uid 605); 15 May 2003 04:23:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8428 invoked from network); 15 May 2003 04:23:19 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 May 2003 04:23:19 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4F4NDx9007863; Wed, 14 May 2003 21:23:13 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4F4NDNg000699; Wed, 14 May 2003 22:23:13 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4F4KcQx002198; Wed, 14 May 2003 21:20:38 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4F4KbGH002197; Wed, 14 May 2003 21:20:37 -0700 (PDT) Date: Wed, 14 May 2003 21:20:37 -0700 From: Nicolas Williams To: Chris Lonvick Cc: ietf-ssh@netbsd.org Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding Message-ID: <20030514212037.A2009@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from clonvick@cisco.com on Wed, May 14, 2003 at 01:27:01PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list I take issue with this comment. X11 forwarding helps fix exactly those problems that Wietse Venema describes, particularly if: a) the X11 server does not accept connections except over local IPC mechanisms that are protected by ACLs or file permissions (e.g., Unix domain sockets), and b) (a) applies to the SSHv2 server pseudo-X11 server used in X11 forwarding. Given (a) and (b) those magic cookies add no value and their weakness is irrelevant. Xsun, for example, can be configured not to listen for display opens over TCP. Cheers, Nico On Wed, May 14, 2003 at 01:27:01PM -0700, Chris Lonvick wrote: > ---Ran---vv > It turns out that the X11 cookie security has significant issues. > > A good reference for folks here to read might be: > Wietse Venema, "Murphy's Law and Computer Security", Proceedings > of 6th USENIX Security Symposium, San Jose, CA, July 1996. > > It is likely that the above paper can be downloaded from USENIX, > http://www.usenix.org. I don't know the correct URL for that > paper, so one would have to browse to find it. > > Also, if we reach back to 1997, there were other issues identified: > http://lists.insecure.org/lists/bugtraq/1997/Sep/0062.html > > I'm not comfortable with the current text on X11, though I'm > only one person... > ---Ran---^^ > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 08:46:10 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07247 for ; Thu, 15 May 2003 08:46:09 -0400 (EDT) Received: (qmail 29842 invoked by uid 605); 15 May 2003 12:49:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29835 invoked from network); 15 May 2003 12:49:05 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 15 May 2003 12:49:05 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4FCn3KT024499 for ; Thu, 15 May 2003 05:49:04 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA15944 for ; Thu, 15 May 2003 05:49:03 -0700 (PDT) Date: Thu, 15 May 2003 05:49:03 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: 2nd version -Re: New Proposal for Section 11.1.3 Replay In-Reply-To: <023501c31a67$e0d36590$4d00a8c0@galb.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Joseph, On Wed, 14 May 2003, Joseph Galbraith wrote: > > Naturally, if an > > attacker does attempt to replay a captured packed before the peers > > have rekeyed, then the receiver of the duplicate packet will see that > > it has the sequence number of a packet that has already been received > > and will discard it. > > The packet sequence number is not actually sent on > the wire, but is maintained independantly by each > side. > > If an attacker replays a captured packet, it will > be input into the mac routines with the next valid > sequence number. Since that is not the sequence > number that was used in the original computation of > the mac, it will show up as a MAC error. > > Thanks, Chris, for compiling these. > > - Joseph Got it. Is what I've revised below better? Also, would anyone object if I took the first paragraph out of this section (Replay) and turned it into the basis for a separate section on the importance of a good PRNG? That would be consistent with the discussion on the list to emphasize it's importance. Thanks, Chris ====================================================================== 11.1.3 Replay This protocol binds each session key to the session by including random data that is specific to the session in the hash used to produce session keys. If the random data here (e.g., DH parameters) are pseudo-random then the PRNG should be cryptographically secure (i.e., its next output not easily guessed, even when knowing all previous outputs) and, furthermore, the PRNG should be seeded with some truly random inputs, or as random as can be available. In any case, the amount of entropy available to a given client or server sometimes may be less than what is needed to run the protocol, in which case either one must resort to PRNGs anyways or refuse to run the protocol. In practice implementors will generally rely on some PRNG. RFC 1750 [1750] contains more discussion on this. The use of a MAC other than 'none' provides integrity and authentication. In addition, the transport protocol provides a unique session identifier (bound in part to pseudo-random data that is part of the algorithm and key exchange process) that can be used by higher level protocols to bind data to a given session and prevent replay of data from prior sessions. For example, the authentication protocol uses this to prevent replay of signatures from previous sessions. Because public key authentication exchanges are cryptographically bound to the session (i.e., to the initial key exchange) they cannot be successfully replayed in other sessions. Note that the session ID can be made public without harming the security of the protocol. If two session happen to have the same session ID [hash of key exchanges] then packets from one can be replayed against the other. It must be stressed that the chances of such an occurrence are, needless to say, minimal when using modern cryptographic methods. This is all the more so true when specifying larger hash function outputs and DH parameters. Replay detection using monotonically increasing sequence numbers as input to the MAC, or HMAC in some cases, is described in RFC 2085 [2085], RFC 2246 [2246], RFC 2743 [2743], RFC 1964 [1964], RFC 2025 [2025], and RFC 1510 [1510]. The underlying construct is discussed in RFC 2104 [2104]. Essentially a different sequence number in each packet ensures that at least this one input to the MAC function will be unique and will provide a nonrecurring MAC output that is not predictable to an attacker. If the session stays active long enough, however, this sequence number will wrap. This event may provide an attacker an opportunity to replay a previously recorded packet with an identical sequence number but only if the peers have not rekeyed since the transmission of the first packet with that sequence number. If the peers have rekeyed, then the replay will be detected as the MAC check will fail. For this reason, it must be emphasized that peers MUST rekey before a wrap of the sequence numbers. Naturally, if an attacker does attempt to replay a captured packet before the peers have rekeyed, then the receiver of the duplicate packet will not be able to validate the MAC and it will be discarded. The reason that the MAC will fail is because the receiver will formulate a MAC based upon the packet contents, the shared secret, and the expected sequence number. Since the replayed packet will not be using that expected sequence number (the sequence number of the replayed packet will have already been passed by the receiver) then the calculated MAC will not match the MAC received with the packet. [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [2246] TLS [2085] IPsec AH [2104] HMAC [2743] GSS-API [1964] The KerberosV GSS-API mechanism [2025] SPKM [1510] Kerberos V ---Notes--- [RJA: I imagine that a sequence number does help preclude replay attacks, [RJA: but I was hoping that someone else had actually done some analysis [RJA: that we could cite to justify the claim that this MAC combined with [RJA: this kind of sequence numbering would actually provide replay [RJA: attack prevention. ---Joseph---vv If no one knows of something to cite here, I'm not sure what to do at this point? Baring someone stepping forward witht the requested citation, what should we do? I'd like to move forward. ---Joseph---^^ ---Nico---vv Er, this is a time-honored technique. Examples of protocols that support the use of sequence numbers as a replay detection technique are: - GSS-API (generally) [RFC2743] - The KerberosV GSS-API mechanism (specifically) [RFC1964] - The Simple Public-Key GSS-API Mechanism (SPKM) (specifically) [RFC2025] - Kerberos V [RFC1510] - TLS 1.0 [RFC2246] Need I go on? Probably not. Each of those documents makes reference to the use of sequence numbers for replay and out-of-sequence detection. ---Nico---^^ ---Ran---vv Generic comment (applies to above and other places): I'd rather delete a claim that the WG can't clearly justify than have this document accidentally make a claim that later turns out to be inaccurate or misleading. ---Ran--^^ ---Heikki---vv I for one believe replay protection is an important property for the protocol and I would like this claim to remain in the documents. IpSec AH uses sequence number with HMAC for replay protection (rfc2085), so does TLS (rfc2246). HMAC security considerations are discussed in rfc2104. The document describes security of the construct in general, and I believe the replay protection scheme is a small subset compared to that, given the so many bits an attacker can affect (sequence number, padding). How about "to our best knowledge"? ---Heikki---^^ ---Ran---vv Does someone want to try to construct a rationale for the document about why folks believe the attempted replay protection actually works ? Barring that, maybe the words should be more tentative (edit to taste): Through the use of a sequence number and ... and ..., the SSH specification seeks to provide protection against replay attacks. ---Ran---^^ ---Heikki---vv I'm not much of an editor, but maybe someone can slash something out of the following: Running sequence number gives us an unique input for the MAC function regardless of the contents of the packet, as long as the sequence number doesn't wrap. With rekeying before the sequence number wraps, we get an unique input into the MAC function (well, HMAC at least) regardless of the sequence counter wrapping. If an attacker captures a packet and inserts it within the SSH stream in order to replay the packet, either the sequence number or the MAC key will be different, and the MAC check will fail. We assume MAC is secure of course, specifically it being infeasible to construct x' such that MAC(x) = MAC(x'). For HMACs it is discussed in rfc 2104. I don't know if it's relevant or not, but given that an attacker wants to re-use data from the packet, there are even less bits to work with, and, even less of a chance of succeeding in creating a valid MAC. ---Heikki---^^ ---Chris---vv I'm going to put that last part into the MITM section rather than here in the Replay section. ---Chris---^^ ---David Williams---vv > attacker does attempt to replay a captured packed before the peers > should read "... packet before the peers" ---David---^^ ---Joseph---vv The packet sequence number is not actually sent on the wire, but is maintained independantly by each side. If an attacker replays a captured packet, it will be input into the mac routines with the next valid sequence number. Since that is not the sequence number that was used in the original computation of the mac, it will show up as a MAC error. ---Joseph---^^ ---Chris---vv I knew that. No, really; I knew that. S-) ---Chris---^^ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 09:53:57 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08909 for ; Thu, 15 May 2003 09:53:55 -0400 (EDT) Received: (qmail 5705 invoked by uid 605); 15 May 2003 13:56:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5698 invoked from network); 15 May 2003 13:56:55 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 15 May 2003 13:56:55 -0000 Received: from extremenetworks.com (unknown [10.0.8.120]) by gnat.inet.org (Postfix) with ESMTP id 9C95467115; Thu, 15 May 2003 10:22:06 -0400 (EDT) Date: Thu, 15 May 2003 09:56:16 -0400 Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Chris Lonvick , ietf-ssh@netbsd.org To: Nicolas Williams From: RJ Atkinson In-Reply-To: <20030514212037.A2009@binky.central.sun.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, May 15, 2003, at 00:20 America/Montreal, Nicolas Williams wrote: > Given (a) and (b) those magic cookies add no value ... This is consistent with my stated unhappiness with the text that was implying that those cookies did have security value. We need text that is clear and accurate. I'm not exactly sure what that text looks like, unfortunately, or I'd propose a block of new text. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 10:06:03 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09404 for ; Thu, 15 May 2003 10:06:01 -0400 (EDT) Received: (qmail 11643 invoked by uid 605); 15 May 2003 14:09:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11636 invoked from network); 15 May 2003 14:09:01 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 15 May 2003 14:09:01 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4FE8x9s008861 for ; Thu, 15 May 2003 07:08:59 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA17248 for ; Thu, 15 May 2003 07:08:59 -0700 (PDT) Date: Thu, 15 May 2003 07:08:59 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: New Proposal for Section 11.1.4 Man-in-the-middle In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, The section on MITM for your review. Thanks, Chris ======================================================================== 11.1.4 Man-in-the-middle This protocol makes no assumptions nor provisions for an infrastructure for distributing public keys. It is expected that this protocol will sometimes be used without insisting on reliable association between the server host key and the server host name. Such usage is vulnerable to man-in-the-middle attacks. This vulnerability to man-in-the-middle attacks can be mitigated in several fashions: 1. Narrow the window during which the client is vulnerable to such a man-in-the-middle attack. If the client ensures that the host key for a given server remains consistant, an attacker must execute the man-in-the-middle attack on the _first_ connection to a given server. 2. Use an authentication method that is not vulnerable to man-in-the-middle attacks. For example, public-key authentication is not vulnerable to man-in-the-middle attack as long as the public-key of the server has been securely distributed to the clients before the first SSH connection is made. This is because the signature is made across data that is session specific. The session specific data between the attacker and server will be different between the client-to-attacker session and the attacker-to-server sessions due to the randomness discussed above. From this, the attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session specific data from the server since he does not have the private key of that server. 3. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, storing the hostkey fingerprint in a secure dns database, or using kerberos over gssapi during keyexchange to authenticate the server. Insecure distribution of server public keys allows a different sort of man-in-the-middle: one with suitable but incorrect host keys. If the server public keys are not securely distributed then the client cannot know if it is talking to the intended server. Server administrators are encouraged to make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms include secured Web pages, the DNS [draft-ietf-secsh-dns], physical pieces of paper, etc. Implementors SHOULD provide recommendations on how best to do this with their implementation. Use of this protocol without a reliable association of the binding between a host and its host keys is inherently insecure and is NOT RECOMMENDED. It may however be necessary in non-security critical environments, and will still provide protection against passive attacks. Implementors of protocols and applications running on top of this protocol should keep this possibility in mind. Attackers may attempt to manipulate packets in transit between peers. As described in the Replay part of this section, a successful attack of this nature is very improbable. As in the Replay section, this reasoning does assume that the MAC is secure and that it is infeasible to construct inputs to a MAC algorithm to give a known output. This is discussed in much greater detail in Section 6 of RFC 2104. If the MAC algorithm has a vulnerability or is weak enough, then the attacker may be able to specify certain inputs to yeild a known MAC. With that they may be able to alter the contents of a packet in transit. Alternatively the attacker may be able to exploit the algorithm vulnerability or weakness to find the shared secret by reviewing the MACs from captured packets. With either of those cases, an attacker could construct a packet that could be inserted into an SSH stream. To prevent that, implementors are encouraged to utilize commonly accepted MAC algorithms and administrators are encouraged to watch current literature and discussions of cryptography to ensure that they are not using a MAC algorithm that has a recently found vulnerability or weakness. ---Notes---[Chris: These notes revolve around (2) above.] [RJA: Is this really true and sufficient ? --Joseph--vv Public key authentication is not vulnerable regardless of whether the server's public key has been securely distrubuted. ---Nico---vv Insecure distribution of server public keys allows a different sort of MITM: one with suitable host keys. If the server public keys are not securely distributed then the client cannot know if it is talking to a legitimate server. > Client --> MITM server / MITM client --> Server > > Client uses robust cryptographic PRNG, and > correct implemenations, forcing the Session > Identifier for the Client --> MITM Server > to be unpredicatable. This applies only to a MITM who does not posses host keys. Obiously, any MITM can generate host keys. The questions is: can a MITM fool a client into thinking that it (the MITM) is the server that the client intended to connect to. ---Nico---^^ Client --> MITM server / MITM client --> Server Client uses robust cryptographic PRNG, and correct implemenations, forcing the Session Identifier for the Client --> MITM Server to be unpredicatable. Server also uses robust cryptographic PRNG, and correct implementations, forcing the Session Identifier for the MITM Client --> Server Session to be unpredictable, and most importantly, different from that of Client --> MITM Server. ---Ran---vv Seems to me that we ought to note the criticality of the quality of the PRNG implementation in the Security Considerations section of the document. ---Ran---^^ Now, client uses its private key to sign the Client -> MITM Server session id, and sends that signature as authentication data. Becasuse MITM Client can't use the signature it just received (MITM client --> Server has a different Session Id to be signed), and it doesn't have access to the private key, it cannot proceed forward with authentication. --- Now, of course MITM Client can simply defer completing authentication with Server, and wait for client to request Agent forwarding. Then, using agent, obtain the signature it needs to complete the authentication with Server, and quickly bring MITM client --> Server state up to date with Client --> MITM Server state. Maybe the whole argument isn't worth including. --Joseph--^^ ---Ran---vv I'd go with that last sentence, particularly since the robustness of the PRNG is very implementation-specific. It is hard to get PRNGs correct in actual code, so it is not unlikely that one or more SSH implementations would not get it right. ---Ran---^^ ---Heikki---vv I second that. ---Heikki---^^ ---Heikki---vv In my opinion, this belongs into the agent spec, not here. [Don't do agent forwarding for the servers you don't trust.] ---Heikki---^^ ---Ran---vv That would be OK with me. ---Ran---^^ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 10:24:43 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10687 for ; Thu, 15 May 2003 10:24:43 -0400 (EDT) Received: (qmail 22952 invoked by uid 605); 15 May 2003 14:27:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22945 invoked from network); 15 May 2003 14:27:42 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 15 May 2003 14:27:42 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19GJht-0004b4-00; Thu, 15 May 2003 15:27:41 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: New Proposal for Section 11.1.4 Man-in-the-middle Message-Id: Date: Thu, 15 May 2003 15:27:41 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Chris Lonvick wrote: > 2. Use an authentication method that is not vulnerable to > man-in-the-middle attacks. For example, public-key authentication > is not vulnerable to man-in-the-middle attack as long as the > public-key of the server has been securely distributed to the > clients before the first SSH connection is made. Surely the other way round? If the server's key has already been securely distributed to the client, then _no_ authentication method is vulnerable to MITM - that's precisely what the server's host key is for! I don't see how public-key authentication is any better than other methods in this respect. If the _user's_ public key has been securely distributed to the _server_ before the first SSH connection is made, then public-key authentication might be able to verify the server's host key which was previously unknown. However, this is conditional on the user being sure they really have connected to the right server! I grant that an MITM seeing a public-key authentication request wouldn't be able to use it to gain access to the real server; but they could simply return Yes, and _pretend_ to be the real server for as long as they could get away with it in the absence of a genuine login there, in the hope that the user might try to (for example) connect through to some other system and type a password in. The user would have to verify the connection by requesting some other piece of information from the server which they already knew but which the MITM would be unlikely to guess right. Cheers, Simon -- Simon Tatham "The distinction between the enlightened and the terminally confused is only apparent to the latter." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 10:30:55 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10948 for ; Thu, 15 May 2003 10:30:54 -0400 (EDT) Received: (qmail 26135 invoked by uid 605); 15 May 2003 14:33:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26125 invoked from network); 15 May 2003 14:33:55 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 May 2003 14:33:55 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4FEXeY9027986; Thu, 15 May 2003 08:33:40 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FEXduP012675; Thu, 15 May 2003 08:33:39 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4FEV4Qx002349; Thu, 15 May 2003 07:31:04 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4FEV3gT002348; Thu, 15 May 2003 07:31:03 -0700 (PDT) Date: Thu, 15 May 2003 07:31:03 -0700 From: Nicolas Williams To: RJ Atkinson Cc: Chris Lonvick , ietf-ssh@netbsd.org Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding Message-ID: <20030515073103.C4352@binky.central.sun.com> References: <20030514212037.A2009@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rja@extremenetworks.com on Thu, May 15, 2003 at 09:56:16AM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, May 15, 2003 at 09:56:16AM -0400, RJ Atkinson wrote: > > On Thursday, May 15, 2003, at 00:20 America/Montreal, Nicolas Williams > wrote: > > Given (a) and (b) those magic cookies add no value ... > > This is consistent with my stated unhappiness with the text that > was implying that those cookies did have security value. Ah, sorry I misread your comment. > We need text that is clear and accurate. I'm not exactly sure > what that text looks like, unfortunately, or I'd propose a block > of new text. How about this?: X11 display forwarding, by itself, is not sufficient to correct well known problems with X11 security [Venema]. However, X11 display forwarding in SSHv2 (or other, secure protocols), combined with actual and pseudo-displays which accept connections only over local IPC mechanisms authorized by permissions or ACLs, does correct most X11 security problems. It is RECOMMENDED that X11 display implementations default to allowing display opens only over local IPC. It is RECOMMENDED that SSHv2 server implementations that support X11 forwarding default to allowing display opens only over local IPC. On single-user systems it is reasonable to default to allowing local display opens over TCP/IP. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 11:06:16 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11797 for ; Thu, 15 May 2003 11:06:14 -0400 (EDT) Received: (qmail 19556 invoked by uid 605); 15 May 2003 15:09:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19549 invoked from network); 15 May 2003 15:09:13 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 May 2003 15:09:13 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4FF9CY9024233; Thu, 15 May 2003 09:09:12 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FF9CuP028021; Thu, 15 May 2003 09:09:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4FF6bQx002382; Thu, 15 May 2003 08:06:37 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4FF6bHV002381; Thu, 15 May 2003 08:06:37 -0700 (PDT) Date: Thu, 15 May 2003 08:06:37 -0700 From: Nicolas Williams To: Simon Tatham Cc: ietf-ssh@netbsd.org Subject: Re: New Proposal for Section 11.1.4 Man-in-the-middle Message-ID: <20030515080636.A2369@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from anakin@pobox.com on Thu, May 15, 2003 at 03:27:41PM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Than you Simon, your comment makes the point I tried to make the other day, but more clearly and eloquently than my poor attempt. Nico On Thu, May 15, 2003 at 03:27:41PM +0100, Simon Tatham wrote: > Chris Lonvick wrote: > > 2. Use an authentication method that is not vulnerable to > > man-in-the-middle attacks. For example, public-key authentication > > is not vulnerable to man-in-the-middle attack as long as the > > public-key of the server has been securely distributed to the > > clients before the first SSH connection is made. > > Surely the other way round? > > If the server's key has already been securely distributed to the > client, then _no_ authentication method is vulnerable to MITM - > that's precisely what the server's host key is for! I don't see how > public-key authentication is any better than other methods in this > respect. > > If the _user's_ public key has been securely distributed to the > _server_ before the first SSH connection is made, then public-key > authentication might be able to verify the server's host key which > was previously unknown. > > However, this is conditional on the user being sure they really have > connected to the right server! I grant that an MITM seeing a > public-key authentication request wouldn't be able to use it to gain > access to the real server; but they could simply return Yes, and > _pretend_ to be the real server for as long as they could get away > with it in the absence of a genuine login there, in the hope that > the user might try to (for example) connect through to some other > system and type a password in. The user would have to verify the > connection by requesting some other piece of information from the > server which they already knew but which the MITM would be unlikely > to guess right. > > Cheers, > Simon > -- > Simon Tatham "The distinction between the enlightened and the > terminally confused is only apparent to the latter." > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 11:15:23 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11933 for ; Thu, 15 May 2003 11:15:22 -0400 (EDT) Received: (qmail 24435 invoked by uid 605); 15 May 2003 15:18:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24426 invoked from network); 15 May 2003 15:18:23 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 15 May 2003 15:18:23 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 1388967107; Thu, 15 May 2003 11:44:11 -0400 (EDT) Date: Thu, 15 May 2003 11:18:22 -0400 Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-ssh@netbsd.org To: Nicolas Williams From: RJ Atkinson In-Reply-To: <20030515073103.C4352@binky.central.sun.com> Message-Id: <772ED410-86E8-11D7-BB92-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, May 15, 2003, at 10:31 America/Montreal, Nicolas Williams wrote: > How about this?: > > X11 display forwarding, by itself, is not sufficient to correct well s/X11 display forwarding/X11 display forwarding with SSH/ > known problems with X11 security [Venema]. However, X11 display > forwarding in SSHv2 (or other, secure protocols), combined with > actual and pseudo-displays which accept connections only over local > IPC mechanisms authorized by permissions or ACLs, does correct most > X11 security problems. Proposed edits: s/most X11/many X11/ > It is RECOMMENDED that X11 display implementations default to > allowing display opens only over local IPC. It is RECOMMENDED that > SSHv2 server implementations that support X11 forwarding default to > allowing display opens only over local IPC. On single-user systems > it is reasonable to default to allowing local display opens over > TCP/IP. s/it is reasonable/it might be reasonable/ Otherwise looks OK to me. Ran rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 11:21:59 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12068 for ; Thu, 15 May 2003 11:21:59 -0400 (EDT) Received: (qmail 27926 invoked by uid 605); 15 May 2003 15:25:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27916 invoked from network); 15 May 2003 15:24:59 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 15 May 2003 15:24:59 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4FFOxsa011777; Thu, 15 May 2003 09:24:59 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FFOwNg028681; Thu, 15 May 2003 09:24:58 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4FFMNQx002417; Thu, 15 May 2003 08:22:23 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4FFMNPC002416; Thu, 15 May 2003 08:22:23 -0700 (PDT) Date: Thu, 15 May 2003 08:22:23 -0700 From: Nicolas Williams To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding Message-ID: <20030515082223.D4352@binky.central.sun.com> References: <20030515073103.C4352@binky.central.sun.com> <772ED410-86E8-11D7-BB92-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <772ED410-86E8-11D7-BB92-00039357A82A@extremenetworks.com>; from rja@extremenetworks.com on Thu, May 15, 2003 at 11:18:22AM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, May 15, 2003 at 11:18:22AM -0400, RJ Atkinson wrote: > > On Thursday, May 15, 2003, at 10:31 America/Montreal, Nicolas Williams > wrote: > > How about this?: > > > > X11 display forwarding, by itself, is not sufficient to correct well > > s/X11 display forwarding/X11 display forwarding with SSH/ I intended that the first sentence reference X11 display forwarding in general - the point being that "X11 display forwarding," whatever protocol is used for the purpose, by itself does not solve the X11 display security problems. The next sentence references X11 display forwarding with SSHv2 specifically. Perhaps we should mention non-use of the "none" encryption and MAC algs... > > known problems with X11 security [Venema]. However, X11 display > > forwarding in SSHv2 (or other, secure protocols), combined with > > actual and pseudo-displays which accept connections only over local > > IPC mechanisms authorized by permissions or ACLs, does correct most > > X11 security problems. > > Proposed edits: > > s/most X11/many X11/ Yes, thank you. > > It is RECOMMENDED that X11 display implementations default to > > allowing display opens only over local IPC. It is RECOMMENDED that > > SSHv2 server implementations that support X11 forwarding default to > > allowing display opens only over local IPC. On single-user systems > > it is reasonable to default to allowing local display opens over > > TCP/IP. > > s/it is reasonable/it might be reasonable/ Good one. > Otherwise looks OK to me. Thanks, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 11:23:15 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12121 for ; Thu, 15 May 2003 11:23:14 -0400 (EDT) Received: (qmail 28671 invoked by uid 605); 15 May 2003 15:26:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28664 invoked from network); 15 May 2003 15:26:15 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 15 May 2003 15:26:15 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 59B7967107; Thu, 15 May 2003 11:52:03 -0400 (EDT) Date: Thu, 15 May 2003 11:26:15 -0400 Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-ssh@netbsd.org To: Nicolas Williams From: RJ Atkinson In-Reply-To: <20030515082223.D4352@binky.central.sun.com> Message-Id: <91A58F7E-86E9-11D7-BB92-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, May 15, 2003, at 11:22 America/Montreal, Nicolas Williams wrote: > I intended that the first sentence reference X11 display forwarding in > general - the point being that "X11 display forwarding," whatever > protocol is used for the purpose, by itself does not solve the X11 > display security problems. The next sentence references X11 display > forwarding with SSHv2 specifically. OK. > Perhaps we should mention non-use of the "none" encryption and MAC > algs... Yes. My oversight, terribly sorry. Thanks, Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 11:40:32 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12595 for ; Thu, 15 May 2003 11:40:31 -0400 (EDT) Received: (qmail 7637 invoked by uid 605); 15 May 2003 15:42:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7406 invoked from network); 15 May 2003 15:42:35 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 15 May 2003 15:42:35 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4FFgXKT020113; Thu, 15 May 2003 08:42:33 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA01822; Thu, 15 May 2003 08:42:33 -0700 (PDT) Date: Thu, 15 May 2003 08:42:33 -0700 (PDT) From: Chris Lonvick To: RJ Atkinson cc: Nicolas Williams , Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding In-Reply-To: <91A58F7E-86E9-11D7-BB92-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Nico and Ran, Should this proposal entirely replace the prior proposal or are there parts of the prior proposal that should be kept with this? I appreciate the suggestions you've made here. Thanks, Chris On Thu, 15 May 2003, RJ Atkinson wrote: > > On Thursday, May 15, 2003, at 11:22 America/Montreal, Nicolas Williams > wrote: > > I intended that the first sentence reference X11 display forwarding in > > general - the point being that "X11 display forwarding," whatever > > protocol is used for the purpose, by itself does not solve the X11 > > display security problems. The next sentence references X11 display > > forwarding with SSHv2 specifically. > > OK. > > > Perhaps we should mention non-use of the "none" encryption and MAC > > algs... > > Yes. My oversight, terribly sorry. > > Thanks, > > Ran > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 11:58:57 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13395 for ; Thu, 15 May 2003 11:58:55 -0400 (EDT) Received: (qmail 16445 invoked by uid 605); 15 May 2003 16:01:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16351 invoked from network); 15 May 2003 16:01:52 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 15 May 2003 16:01:52 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4FG1esa004421; Thu, 15 May 2003 10:01:40 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FG1dNg010367; Thu, 15 May 2003 10:01:39 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4FFx4Qx002446; Thu, 15 May 2003 08:59:04 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4FFx4x8002445; Thu, 15 May 2003 08:59:04 -0700 (PDT) Date: Thu, 15 May 2003 08:59:04 -0700 From: Nicolas Williams To: Chris Lonvick Cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding Message-ID: <20030515085904.E4352@binky.central.sun.com> References: <91A58F7E-86E9-11D7-BB92-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from clonvick@cisco.com on Thu, May 15, 2003 at 08:42:33AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, May 15, 2003 at 08:42:33AM -0700, Chris Lonvick wrote: > Should this proposal entirely replace the prior proposal or are there > parts of the prior proposal that should be kept with this? I appreciate > the suggestions you've made here. How about this (my proposed text added between the first and second paragraphs you proposed): 11.3.3 X11 Forwarding Another form of proxy forwarding provided by the ssh connection protocol is the forwarding of the X11 protocol. If end-point security server. Users and administrators should, as a matter of course, use all available X11 security mechanisms to prevent unauthorized use of the X11 server. Implementors, administrators and users who wish to further explore the security mechanisms of X11 are invited to read [SCHEIFLER] and analyze previously reported problems with the interactions between SSH forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 [CERT]. Additionally, they are advised to review the problems found and the lessons learned in a paper by Wietse Venema [Venema] presented to the 6th USENIX Security Symposium. X11 display forwarding, by itself, is not sufficient to correct well known problems with X11 security [Venema]. However, X11 display forwarding in SSHv2 (or other, secure protocols), combined with X11 actual and pseudo-displays which accept connections only over local IPC mechanisms authorized by file permissions or other ACLs, does correct many X11 security problems. It is RECOMMENDED that X11 display implementations default to allowing display opens only over local IPC. It is RECOMMENDED that SSHv2 server implementations that support X11 forwarding default to allowing display opens only over local IPC. On single-user systems it may be reasonable to default to allowing local display opens over. Implementors of the X11 forwarding protocol SHOULD implement the magic cookie access checking spoofing mechanism as described in [ssh-connect] as an additional mechanism to prevent unauthorized use of the proxy. [references] Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 13:30:21 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15951 for ; Thu, 15 May 2003 13:30:20 -0400 (EDT) Received: (qmail 4819 invoked by uid 605); 15 May 2003 17:33:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4810 invoked from network); 15 May 2003 17:33:18 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 15 May 2003 17:33:18 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id B184367107; Thu, 15 May 2003 13:59:07 -0400 (EDT) Date: Thu, 15 May 2003 13:33:18 -0400 Subject: Re: New Proposal for Section 11.3.3 X11 Forwarding Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-ssh@netbsd.org To: Nicolas Williams From: RJ Atkinson In-Reply-To: <20030515085904.E4352@binky.central.sun.com> Message-Id: <51267C1E-86FB-11D7-BB92-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, May 15, 2003, at 11:59 America/Montreal, Nicolas Williams wrote: > How about this (my proposed text added between the first and second > paragraphs you proposed): > > 11.3.3 X11 Forwarding > > Another form of proxy forwarding provided by the ssh connection > protocol is the forwarding of the X11 protocol. If end-point > security server. Users and administrators should, as a matter of There is a typo just above ("If end-point security server."). > course, use all available X11 security mechanisms to prevent s/all available/appropriate/ - some X11 security mechanisms are mutually exclusive - some X11 security mechanisms might not make sense in some environments > unauthorized use of the X11 server. Implementors, administrators > and > users who wish to further explore the security mechanisms of X11 are > invited to read [SCHEIFLER] and analyze previously reported problems > with the interactions between SSH forwarding and X11 in CERT > vulnerabilities VU#363181 and VU#118892 [CERT]. Additionally, they > are advised to review the problems found and the lessons learned in > a > paper by Wietse Venema [Venema] presented to the 6th USENIX Security > Symposium. > > X11 display forwarding, by itself, is not sufficient to correct well > known problems with X11 security [Venema]. However, X11 display > forwarding in SSHv2 (or other, secure protocols), combined with > X11 actual and pseudo-displays which accept connections only over > local IPC mechanisms authorized by file permissions or other ACLs, > does correct many X11 security problems. It is RECOMMENDED that X11 > display implementations default to allowing display opens only over > local IPC. It is RECOMMENDED that SSHv2 server implementations that > support X11 forwarding default to allowing display opens only over > local IPC. On single-user systems it may be reasonable to default > to > allowing local display opens over. > > Implementors of the X11 forwarding protocol SHOULD implement the > magic cookie access checking spoofing mechanism as described in > [ssh-connect] as an additional mechanism to prevent unauthorized use > of the proxy. > > [references] Other than the proposed edits, the above looks OK to me. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 14:10:48 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17347 for ; Thu, 15 May 2003 14:10:47 -0400 (EDT) Received: (qmail 197 invoked by uid 605); 15 May 2003 18:13:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 190 invoked from network); 15 May 2003 18:13:46 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 15 May 2003 18:13:46 -0000 Received: from [127.0.0.1] (HELO chaos) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1522930; Thu, 15 May 2003 12:13:46 -0600 Message-ID: <02e101c31b0d$b9c2ebf0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Simon Tatham" , References: Subject: Re: New Proposal for Section 11.1.4 Man-in-the-middle Date: Thu, 15 May 2003 12:13:46 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > However, this is conditional on the user being sure they really have > connected to the right server! I grant that an MITM seeing a > public-key authentication request wouldn't be able to use it to gain > access to the real server; but they could simply return Yes, and > _pretend_ to be the real server for as long as they could get away > with it in the absence of a genuine login there, in the hope that > the user might try to (for example) connect through to some other > system and type a password in. The user would have to verify the > connection by requesting some other piece of information from the > server which they already knew but which the MITM would be unlikely > to guess right. Right... this is what the origal claim was; man in the middle is not feasable with public key. However, as you point out, a spoofing attack is-- which really makes this protection quite useless. I think we should remove #2. Thanks, Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 14:19:45 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17545 for ; Thu, 15 May 2003 14:19:44 -0400 (EDT) Received: (qmail 4105 invoked by uid 605); 15 May 2003 18:22:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4096 invoked from network); 15 May 2003 18:22:44 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 15 May 2003 18:22:44 -0000 Received: from extremenetworks.com (unknown [10.18.3.101]) by gnat.inet.org (Postfix) with ESMTP id 60EDA67107 for ; Thu, 15 May 2003 14:48:33 -0400 (EDT) Date: Thu, 15 May 2003 14:22:43 -0400 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: aside on formal methods From: RJ Atkinson To: ietf-ssh@netbsd.org Content-Transfer-Encoding: 7bit Message-Id: <38974EB6-8702-11D7-BEDB-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Putting the practical questions of document editing aside for the moment, the length of the discussion on Security Considerations and the informal nature of that discussion are a bit troubling to me. It makes one wonder whether the SSH spec really did get all the pieces right -- and, if it did, whether it did so by accident. It would be pleasant and helpful if there some more formal analysis of the SSH protocol performed -- and published. The first step would probably to try to come up with a formal specification of the protocol in some appropriate logic. If there are any academic folks on this list, please consider whether such formal methods work might be a reasonable research topic to undertake. IMHO, Ran rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 15:29:27 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20639 for ; Thu, 15 May 2003 15:29:26 -0400 (EDT) Received: (qmail 15652 invoked by uid 605); 15 May 2003 19:32:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15627 invoked from network); 15 May 2003 19:32:25 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 15 May 2003 19:32:25 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4FJWN2Q015597 for ; Thu, 15 May 2003 12:32:24 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA04265 for ; Thu, 15 May 2003 12:32:23 -0700 (PDT) Date: Thu, 15 May 2003 12:32:23 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: 2nd Version was: New Proposal for Section 11.3.3 X11 Forwarding In-Reply-To: <51267C1E-86FB-11D7-BB92-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, Latest revision incorporating the suggestions. I've removed the duplicate reference to Venema's work and make the recommended substitutions. Please comment. Thanks, Chris ======================================================================= 11.3.3 X11 forwarding Another form of proxy forwarding provided by the ssh connection protocol is the forwarding of the X11 protocol. If end-point security has been compromised, X11 forwarding may allow attacks against the X11 server. Users and administrators should, as a matter of course, use appropriate X11 security mechanisms to prevent unauthorized use of the X11 server. Implementors, administrators and users who wish to further explore the security mechanisms of X11 are invited to read [SCHEIFLER] and analyze previously reported problems with the interactions between SSH forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 [CERT]. X11 display forwarding with SSH, by itself, is not sufficient to correct well known problems with X11 security [VENEMA]. However, X11 display forwarding in SSHv2 (or other, secure protocols), combined with actual and pseudo-displays which accept connections only over local IPC mechanisms authorized by permissions or ACLs, does correct many X11 security problems as long as the "none" MAC is not used. It is RECOMMENDED that X11 display implementations default to allowing display opens only over local IPC. It is RECOMMENDED that SSHv2 server implementations that support X11 forwarding default to allowing display opens only over local IPC. On single-user systems it might be reasonable to default to allowing local display opens over TCP/IP. Implementors of the X11 forwarding protocol SHOULD implement the magic cookie access checking spoofing mechanism as described in [ssh-connect] as an additional mechanism to prevent unauthorized use of the proxy. [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, Feburary 1992. [CERT] The CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 U.S.A. ( http://www.cert.org/nav/index_red.html ) [ssh-connect] ssh-connect ID to be replaced with the RFC information when available [VENEMA] Wietse Venema, "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose, CA, July 1996. http://www.usenix.org/publications/library/proceedings/sec96/venema.html From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 15:44:46 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21004 for ; Thu, 15 May 2003 15:44:46 -0400 (EDT) Received: (qmail 23802 invoked by uid 605); 15 May 2003 19:47:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23794 invoked from network); 15 May 2003 19:47:29 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by mail.netbsd.org with SMTP; 15 May 2003 19:47:29 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FJlSG4024228 for ; Thu, 15 May 2003 12:47:28 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA03593 for ; Thu, 15 May 2003 12:47:28 -0700 (PDT) Date: Thu, 15 May 2003 12:47:28 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Proposal for New Section 11.1 PRNG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Everyone, I'd like to suggest the following as a new section to call out the importance of the PRNG to this effort. Essentially the first paragraph of the Replay section was removed from there to form this new section. I'm thinking it should just be a new Section 11.1 and then everything that had been 11.1 (Transport) and below just move downwards. Your comments on this are requested. Thanks, Chris =========================================================================== 11.1 PRNG This protocol binds each session key to the session by including random data that is specific to the session in the hash used to produce session keys. If the random data here (e.g., DH parameters) are pseudo-random then the PRNG should be cryptographically secure (i.e., its next output not easily guessed even when knowing all previous outputs) and, furthermore, the PRNG should be seeded with some truly random inputs, or as random as can be available. RFC 1750 [1750] contains more discussion on this and suggestions for randomness. Implementors should note well the importance of truly random values where needed in this document. They should also heed the well-meant, anecdotal warning that implementing PRNG functions are difficult to get right. The amount of entropy available to a given client or server sometimes may be less than what is needed to run the protocol. In this case one must either resort to PRNGs anyways or refuse to run the protocol. In practice implementors will generally rely on some PRNG. [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 17:01:56 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23014 for ; Thu, 15 May 2003 17:01:56 -0400 (EDT) Received: (qmail 6242 invoked by uid 605); 15 May 2003 21:03:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6235 invoked from network); 15 May 2003 21:03:05 -0000 Received: from woodstock.binhost.com (207.228.252.5) by mail.netbsd.org with SMTP; 15 May 2003 21:03:05 -0000 Received: (qmail 18572 invoked by uid 0); 15 May 2003 21:02:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.215.24) by woodstock.binhost.com with SMTP; 15 May 2003 21:02:01 -0000 Message-Id: <5.2.0.9.2.20030515165519.037f8080@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 15 May 2003 17:02:26 -0400 To: Chris Lonvick From: Russ Housley Subject: Re: Proposal for New Section 11.1 PRNG Cc: ietf-ssh@netbsd.org In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: ietf-ssh-owner@netbsd.org Precedence: list Chris: > ... and, furthermore, the PRNG should be seeded with > some truly random inputs, or as random as can be available. RFC 1750 > [1750] contains more discussion on this and suggestions for > randomness. Implementors should note well the importance of truly > random values where needed in this document. They should also heed > the well-meant, anecdotal warning that implementing PRNG functions are > difficult to get right. I think that the term "truly random" ought to be avoided. In the subsequent paragraph. the term "entropy" is used. I think that is a better way to go. I propose: ... and, furthermore, entropy needs to be added to the PRNG. RFC 1750 [1750] offers suggestions for sources of entropy. Implementors should note the importance of entropy and the well-meant, anecdotal warning about the difficulty in properly implementing PRNG functions. Russ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 17:28:52 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23805 for ; Thu, 15 May 2003 17:28:51 -0400 (EDT) Received: (qmail 22620 invoked by uid 605); 15 May 2003 21:31:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22613 invoked from network); 15 May 2003 21:31:52 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 May 2003 21:31:52 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4FLVpY9028714; Thu, 15 May 2003 15:31:51 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FLVpNg005744; Thu, 15 May 2003 15:31:51 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4FLTGQx002596; Thu, 15 May 2003 14:29:16 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4FLTFrg002595; Thu, 15 May 2003 14:29:15 -0700 (PDT) Date: Thu, 15 May 2003 14:29:15 -0700 From: Nicolas Williams To: Joseph Galbraith Cc: Simon Tatham , ietf-ssh@netbsd.org Subject: Re: New Proposal for Section 11.1.4 Man-in-the-middle Message-ID: <20030515142915.A2591@binky.central.sun.com> References: <02e101c31b0d$b9c2ebf0$4d00a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <02e101c31b0d$b9c2ebf0$4d00a8c0@galb.vandyke.com>; from galb-list@vandyke.com on Thu, May 15, 2003 at 12:13:46PM -0600 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, May 15, 2003 at 12:13:46PM -0600, Joseph Galbraith wrote: > > However, this is conditional on the user being sure they really have > > connected to the right server! I grant that an MITM seeing a > > public-key authentication request wouldn't be able to use it to gain > > access to the real server; but they could simply return Yes, and > > _pretend_ to be the real server for as long as they could get away > > with it in the absence of a genuine login there, in the hope that > > the user might try to (for example) connect through to some other > > system and type a password in. The user would have to verify the > > connection by requesting some other piece of information from the > > server which they already knew but which the MITM would be unlikely > > to guess right. > > Right... this is what the origal claim was; > man in the middle is not feasable with public > key. Yes, and I screwed up in my comment. What I meant to say was that pubkey userauth with server host keys that are not securely distributed is subject to spoofing - but I said instead that it's subject to MITM attack. My apologies for the confusion. > However, as you point out, a spoofing attack > is-- which really makes this protection quite > useless. Right. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 15 19:00:46 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26898 for ; Thu, 15 May 2003 19:00:45 -0400 (EDT) Received: (qmail 20048 invoked by uid 605); 15 May 2003 23:03:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20041 invoked from network); 15 May 2003 23:03:45 -0000 Received: from client-200.60.210.144.speedy.net.pe (HELO weekonline.com) (200.60.210.144) by mail.netbsd.org with SMTP; 15 May 2003 23:03:45 -0000 Message-ID: From: To: Anthony@netbsd.org, Susan@netbsd.org Subject: My portfolio Date: Thu, 15 May 2003 10:44:55 +1200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V10.0.2616 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA26898 Hi, I am not sure I have the right email address, if not please excuse the intrusion. My name is Ernie Simmons. I am looking for web design and logo work. Please click the link below to see my portfolio. http://www.abcinsuranceca.com Thanks Ernie From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 08:30:49 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20859 for ; Fri, 16 May 2003 08:30:48 -0400 (EDT) Received: (qmail 9909 invoked by uid 605); 16 May 2003 12:33:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9902 invoked from network); 16 May 2003 12:33:46 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 16 May 2003 12:33:46 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4GCXjWh028120 for ; Fri, 16 May 2003 05:33:45 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA19758 for ; Fri, 16 May 2003 05:33:45 -0700 (PDT) Date: Fri, 16 May 2003 05:33:45 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: 2nd version - Proposal for New Section 11.1 PRNG In-Reply-To: <5.2.0.9.2.20030515165519.037f8080@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, Integrating Russ' suggestion. Thanks, Chris ============================================================ 11.1 PRNG This protocol binds each session key to the session by including random data that is specific to the session in the hash used to produce session keys. If the random data here (e.g., DH parameters) are pseudo-random then the PRNG should be cryptographically secure (i.e., its next output not easily guessed even when knowing all previous outputs) and, furthermore, entropy needs to be added to the PRNG. RFC 1750 [1750] offers suggestions for sources of entropy. Implementors should note the importance of entropy and the well-meant, anecdotal warning about the difficulty in properly implementing PRNG functions. The amount of entropy available to a given client or server sometimes may be less than what is needed to run the protocol. In this case one must either resort to PRNGs anyways or refuse to run the protocol. In practice implementors will generally rely on some PRNG. [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 08:39:03 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21055 for ; Fri, 16 May 2003 08:39:02 -0400 (EDT) Received: (qmail 14411 invoked by uid 605); 16 May 2003 12:42:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14404 invoked from network); 16 May 2003 12:42:04 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by mail.netbsd.org with SMTP; 16 May 2003 12:42:04 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4GCg2x5021081 for ; Fri, 16 May 2003 05:42:03 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id FAA29572 for ; Fri, 16 May 2003 05:42:02 -0700 (PDT) Date: Fri, 16 May 2003 05:42:02 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Nmap and SSH in "The Matrix: Reloaded" In-Reply-To: <5.2.0.9.2.20030515165519.037f8080@mail.binhost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Folks, From a note from Fyodor on the nmap-hackers@insecure.org mailing list: http://lists.insecure.org/lists/nmap-hackers/2003/Apr-Jun/0010.html -snip- > Like almost any self-respecting geek, I bought tickets to 'Matrix: > Reloaded' several weeks back (no spoilers, I promise). After all, who > can resist the combination of philosophical mind games and Trinity > (Carrie-Anne Moss) in that tight leather bodysuit? > > So after waiting an hour in a line snaking out of the theatre to the > parking lot, I finally got in to my 10pm Wednesday showing. All was > going well until Trinity needed to do some hacking. Oh, no! I was > sure we'd see a silly "Hackers"-esque 3D animated "hacking scene". > Not so! Trinity is as smart as she is seductive! She whips out > Nmap (!!!), scans her target, finds 22/tcp open, and proceeds with an > Uber ssh technique! I was so surprised, I almost jumped out of my > seat and did the "r00t dance" right there in the theatre! -/snip- While this may be good news for Fyodor and the Nmap crew, this is definitely bad news for our effort. I suspect that some future/ alternate-reality implementor will not have heeded the warnings about the correct implementation of the PRNG. I think it best that my employer should send me to see the movie (and pay for the popcorn, soft drink, maybe some Milk Duds and a bottle of water as well) so I can do some _research_ on this future/alternate-reality problem with SSH. Thanks, Chris Special note to the humor impaired: This is it. :-) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 12:11:51 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01035 for ; Fri, 16 May 2003 12:11:51 -0400 (EDT) Received: (qmail 20085 invoked by uid 605); 16 May 2003 16:14:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20077 invoked from network); 16 May 2003 16:14:51 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 16 May 2003 16:14:51 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4GGEnY9023680; Fri, 16 May 2003 10:14:49 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4GGEnNg019614; Fri, 16 May 2003 10:14:49 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4GGCDQx003040; Fri, 16 May 2003 09:12:13 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4GGCD4P003039; Fri, 16 May 2003 09:12:13 -0700 (PDT) Date: Fri, 16 May 2003 09:12:13 -0700 From: Nicolas Williams To: Chris Lonvick Cc: ietf-ssh@netbsd.org Subject: Re: Nmap and SSH in "The Matrix: Reloaded" Message-ID: <20030516091213.A2983@binky.central.sun.com> References: <5.2.0.9.2.20030515165519.037f8080@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from clonvick@cisco.com on Fri, May 16, 2003 at 05:42:02AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, May 16, 2003 at 05:42:02AM -0700, Chris Lonvick wrote: > While this may be good news for Fyodor and the Nmap crew, this is > definitely bad news for our effort. I suspect that some future/ > alternate-reality implementor will not have heeded the warnings about the > correct implementation of the PRNG. I think it best that my employer > should send me to see the movie (and pay for the popcorn, soft drink, > maybe some Milk Duds and a bottle of water as well) so I can do some > _research_ on this future/alternate-reality problem with SSH. Even in the heady `90s such a business expense might be too much - certainly it could be enough to bankrupt a typical, small dot-bomb. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 13:25:36 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04167 for ; Fri, 16 May 2003 13:25:35 -0400 (EDT) Received: (qmail 1057 invoked by uid 605); 16 May 2003 17:28:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1028 invoked from network); 16 May 2003 17:28:36 -0000 Received: from mailrelay2.lanl.gov (128.165.4.103) by mail.netbsd.org with SMTP; 16 May 2003 17:28:36 -0000 Received: from lanl.gov (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (8.12.9/8.12.9/(ccn-5)) with ESMTP id h4GHSXqt016712; Fri, 16 May 2003 11:28:34 -0600 Message-ID: <3EC51FC1.4010207@lanl.gov> Date: Fri, 16 May 2003 11:28:33 -0600 From: "David M. Williams" Organization: CCN-2 User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Lonvick CC: ietf-ssh@netbsd.org Subject: Re: 2nd version - Proposal for New Section 11.1 PRNG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Chrris, I hope that my signal-to-noise ratio on comments hasn't gotten too low that I can't make a few comments on the PRNG section. Comments below: >============================================================ > >11.1 PRNG > the acronym PRNG lacks a parenthetical reference at it's first occurance in the draft. s/PRNG/Pseudo-Random Number Generation/ with the parenthetical reference in the following paragraphs or s/PRNG/Pseudo-Random Number Generator (PRNG)/ This is probably not correct per the style RFC. also we seem to be using the acronym for both "generator" and "generation". Do we care about the gramatical agreement? > > This protocol binds each session key to the session by including > random data that is specific to the session in the hash used to > maybe this is clearer, s/random data that is specific to the session/random, session specific data/ > produce session keys. If the random data here (e.g., DH parameters) > are pseudo-random then the PRNG should be cryptographically secure > (i.e., its next output not easily guessed even when knowing all > previous outputs) and, furthermore, entropy needs to be added to the > PRNG. RFC 1750 [1750] offers suggestions for sources of entropy. > Implementors should note the importance of entropy and the well-meant, > anecdotal warning about the difficulty in properly implementing PRNG > functions. > s/PRNG functions/PRNGs/ fixes the usage issue, now all uses reflect the implied "generator" usage. > > The amount of entropy available to a given client or server sometimes > may be less than what is needed to run the protocol. In this case > s/sometimes may/may sometimes/ s/to run the protocol/to provide > one must either resort to PRNGs anyways or refuse to run the protocol. > s/anyways/regardless of insufficient entropy/ > In practice implementors will generally rely on some PRNG. > I'd like to suggest we drop this sentence. > > > >[1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness > Recommendations for Security", RFC 1750, December 1994. > > > > > -- David M. Williams, CISSP Phone: 505-665-8062 Systems Engineer, CCN-2 Fax: 505-667-7942 Los Alamos National Laboratory Email: d_wllmsATlanlDOTgov "Nel mezzo del cammin di nostra vita / mi ritrouvai per una selva oscura / che la diritta via era smarrita" -Dante Aligheri From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 13:34:13 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04502 for ; Fri, 16 May 2003 13:34:13 -0400 (EDT) Received: (qmail 6375 invoked by uid 605); 16 May 2003 17:37:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6368 invoked from network); 16 May 2003 17:37:15 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 16 May 2003 17:37:15 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4GHbDWh008064; Fri, 16 May 2003 10:37:13 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA12739; Fri, 16 May 2003 10:37:13 -0700 (PDT) Date: Fri, 16 May 2003 10:37:12 -0700 (PDT) From: Chris Lonvick To: Nicolas Williams cc: Simon Tatham , Subject: Re: New Proposal for Section 11.1.4 Man-in-the-middle In-Reply-To: <20030515080636.A2369@binky.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Simon and Nico, I believe that the point you're trying to make would come under the Authentication Protocol section rather than being left in the Transport section on MITM. That section starts with the following: === 11.3 Authentication Protocol The purpose of this protocol is to perform client user authentication. It assumed that this runs over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. === Is that sufficient for your concerns or should this section also contain a warning about trying to run _any_ authentication mechanism over an SSH session that has not already been authenticated (at the device level)? Thanks, Chris On Thu, 15 May 2003, Nicolas Williams wrote: > Than you Simon, your comment makes the point I tried to make the other > day, but more clearly and eloquently than my poor attempt. > > Nico > > On Thu, May 15, 2003 at 03:27:41PM +0100, Simon Tatham wrote: > > Chris Lonvick wrote: > > > 2. Use an authentication method that is not vulnerable to > > > man-in-the-middle attacks. For example, public-key authentication > > > is not vulnerable to man-in-the-middle attack as long as the > > > public-key of the server has been securely distributed to the > > > clients before the first SSH connection is made. > > > > Surely the other way round? > > > > If the server's key has already been securely distributed to the > > client, then _no_ authentication method is vulnerable to MITM - > > that's precisely what the server's host key is for! I don't see how > > public-key authentication is any better than other methods in this > > respect. > > > > If the _user's_ public key has been securely distributed to the > > _server_ before the first SSH connection is made, then public-key > > authentication might be able to verify the server's host key which > > was previously unknown. > > > > However, this is conditional on the user being sure they really have > > connected to the right server! I grant that an MITM seeing a > > public-key authentication request wouldn't be able to use it to gain > > access to the real server; but they could simply return Yes, and > > _pretend_ to be the real server for as long as they could get away > > with it in the absence of a genuine login there, in the hope that > > the user might try to (for example) connect through to some other > > system and type a password in. The user would have to verify the > > connection by requesting some other piece of information from the > > server which they already knew but which the MITM would be unlikely > > to guess right. > > > > Cheers, > > Simon > > -- > > Simon Tatham "The distinction between the enlightened and the > > terminally confused is only apparent to the latter." > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 13:44:13 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04737 for ; Fri, 16 May 2003 13:44:13 -0400 (EDT) Received: (qmail 11357 invoked by uid 605); 16 May 2003 17:47:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11350 invoked from network); 16 May 2003 17:47:14 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 16 May 2003 17:47:14 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4GHlCY9018935; Fri, 16 May 2003 11:47:12 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4GHlCNg001059; Fri, 16 May 2003 11:47:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4GHiaQx003182; Fri, 16 May 2003 10:44:36 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4GHiaBt003181; Fri, 16 May 2003 10:44:36 -0700 (PDT) Date: Fri, 16 May 2003 10:44:36 -0700 From: Nicolas Williams To: Chris Lonvick Cc: Simon Tatham , ietf-ssh@netbsd.org Subject: Re: New Proposal for Section 11.1.4 Man-in-the-middle Message-ID: <20030516104436.X4352@binky.central.sun.com> References: <20030515080636.A2369@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from clonvick@cisco.com on Fri, May 16, 2003 at 10:37:12AM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Ah, yes, that is good. Thank you, Nico On Fri, May 16, 2003 at 10:37:12AM -0700, Chris Lonvick wrote: > Hi Simon and Nico, > > I believe that the point you're trying to make would come under the > Authentication Protocol section rather than being left in the Transport > section on MITM. That section starts with the following: > === > 11.3 Authentication Protocol > > The purpose of this protocol is to perform client user > authentication. It assumed that this runs over a secure transport > layer protocol, which has already authenticated the server machine, > established an encrypted communications channel, and computed a > unique session identifier for this session. > === > Is that sufficient for your concerns or should this section also contain a > warning about trying to run _any_ authentication mechanism over an SSH > session that has not already been authenticated (at the device level)? > > Thanks, > Chris > > > On Thu, 15 May 2003, Nicolas Williams wrote: > > > Than you Simon, your comment makes the point I tried to make the other > > day, but more clearly and eloquently than my poor attempt. > > > > Nico > > > > On Thu, May 15, 2003 at 03:27:41PM +0100, Simon Tatham wrote: > > > Chris Lonvick wrote: > > > > 2. Use an authentication method that is not vulnerable to > > > > man-in-the-middle attacks. For example, public-key authentication > > > > is not vulnerable to man-in-the-middle attack as long as the > > > > public-key of the server has been securely distributed to the > > > > clients before the first SSH connection is made. > > > > > > Surely the other way round? > > > > > > If the server's key has already been securely distributed to the > > > client, then _no_ authentication method is vulnerable to MITM - > > > that's precisely what the server's host key is for! I don't see how > > > public-key authentication is any better than other methods in this > > > respect. > > > > > > If the _user's_ public key has been securely distributed to the > > > _server_ before the first SSH connection is made, then public-key > > > authentication might be able to verify the server's host key which > > > was previously unknown. > > > > > > However, this is conditional on the user being sure they really have > > > connected to the right server! I grant that an MITM seeing a > > > public-key authentication request wouldn't be able to use it to gain > > > access to the real server; but they could simply return Yes, and > > > _pretend_ to be the real server for as long as they could get away > > > with it in the absence of a genuine login there, in the hope that > > > the user might try to (for example) connect through to some other > > > system and type a password in. The user would have to verify the > > > connection by requesting some other piece of information from the > > > server which they already knew but which the MITM would be unlikely > > > to guess right. > > > > > > Cheers, > > > Simon > > > -- > > > Simon Tatham "The distinction between the enlightened and the > > > terminally confused is only apparent to the latter." > > > > > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 14:16:29 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05782 for ; Fri, 16 May 2003 14:16:29 -0400 (EDT) Received: (qmail 28234 invoked by uid 605); 16 May 2003 18:19:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28160 invoked from network); 16 May 2003 18:19:29 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by mail.netbsd.org with SMTP; 16 May 2003 18:19:29 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4GIJSBP023710 for ; Fri, 16 May 2003 11:19:28 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA12167 for ; Fri, 16 May 2003 11:19:28 -0700 (PDT) Date: Fri, 16 May 2003 11:19:27 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: 2nd Version - Section 11.1.4 Man-in-the-middle In-Reply-To: <20030516104436.X4352@binky.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, I've pulled out #2 from the prior version and didn't like it until I reformatted it. I've kept a lot of the verbiage and hopefully the thoughts. Please comment. Thanks, Chris ======================================================================= 11.1 Transport 11.1.4 Man-in-the-middle This protocol makes no assumptions nor provisions for an infrastructure or means for distributing the public keys of hosts. It is expected that this protocol will sometimes be used without first verifying the association between the server host key and the server host name. Such usage is vulnerable to man-in-the-middle attacks. This section describes this and encourages administrators and users to understand the importance of verifying this association before any session is initiated. There are two cases of man-in-the-middle attacks to consider. The first is where an attacker places a device between the client and the server before the session is initiated. In this case, the attack device is trying to mimic the legitimate server and will offer its public key to the client when the client initiates a session. If it were to offer the public key of the server, then it would not be able to decrypt or sign the transmissions between the legitimate server and the client unless it also had access to the private-key of the host. The attack device will also, simultaneously to this, initiate a session to the legitimate server masquerading itself as the client. If the public key of the server had been securely distributed to the client prior to that session initiation, the key offered to the client by the attack device will not match the key stored on the client. In that case, the user SHOULD be given a warning that the offered host key does not match the host key cached on the client. As described in Section 3.1 of [ARCH], the user may be free to accept the new key and continue the session. It is RECOMMENDED that the warning provide sufficient information to the user of the client device so they may make an informed decision. If the user chooses to continue the session with the stored public-key of the server (not the public-key offered at the start of the session), then the session specific data between the attacker and server will be different between the client-to-attacker session and the attacker-to-server sessions due to the randomness discussed above. From this, the attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session specific data from the server since he does not have the private key of that server. Insecure distribution of server public keys allows a second type of man-in-the-middle attack that should also be considered in this case; one with suitable but incorrect host keys. If the server public keys are not securely distributed then the client cannot know if it is talking to the intended server. An attacker may use social engineering techniques to pass off server keys to unsuspecting users and may then place a man-in-the-middle attack device between the legitimate server and the clients. If this is allowed to happen then the clients will form client-to-attacker sessions and the attacker will form attacker-to-server sessions and will be able to monitor and manipulate all of the traffic between the clients and the legitimate servers. Server administrators are encouraged to make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also include secured Web pages, physical pieces of paper, etc. Implementors SHOULD provide recommendations on how best to do this with their implementation. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, making the host key fingerprint available through a secure DNS lookup, or using kerberos over gssapi during key exchange to authenticate the server are possibilities. As a second man-in-the-middle case, attackers may attempt to manipulate packets in transit between peers after the session has been established. As described in the Replay part of this section, a successful attack of this nature is very improbable. As in the Replay section, this reasoning does assume that the MAC is secure and that it is infeasible to construct inputs to a MAC algorithm to give a known output. This is discussed in much greater detail in Section 6 of RFC 2104. If the MAC algorithm has a vulnerability or is weak enough, then the attacker may be able to specify certain inputs to yield a known MAC. With that they may be able to alter the contents of a packet in transit. Alternatively the attacker may be able to exploit the algorithm vulnerability or weakness to find the shared secret by reviewing the MACs from captured packets. In either of those cases, an attacker could construct a packet or packets that could be inserted into an SSH stream. To prevent that, implementors are encouraged to utilize commonly accepted MAC algorithms and administrators are encouraged to watch current literature and discussions of cryptography to ensure that they are not using a MAC algorithm that has a recently found vulnerability or weakness. In summary, the use of this protocol without a reliable association of the binding between a host and its host keys is inherently insecure and is NOT RECOMMENDED. It may however be necessary in non-security critical environments, and will still provide protection against passive attacks. Implementors of protocols and applications running on top of this protocol should keep this possibility in mind. -end From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 14:50:10 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06561 for ; Fri, 16 May 2003 14:50:10 -0400 (EDT) Received: (qmail 18234 invoked by uid 605); 16 May 2003 18:53:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18226 invoked from network); 16 May 2003 18:53:11 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 16 May 2003 18:53:11 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4GIr7Wh012858; Fri, 16 May 2003 11:53:08 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA19252; Fri, 16 May 2003 11:53:07 -0700 (PDT) Date: Fri, 16 May 2003 11:53:07 -0700 (PDT) From: Chris Lonvick To: "David M. Williams" cc: ietf-ssh@netbsd.org Subject: 3rd version - Proposal for New Section 11.1 PRNG In-Reply-To: <3EC51FC1.4010207@lanl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, How's this? I punted on the PRNG and just replaced it with the proper words as grammar dictates. I worked in a sentence that originally appears in Section 8 of [SSH-ARCH] and replaced the last sentence as that seems to be consistent with the intent of that Section 8. Thanks, Chris ========================================================================= 11.1 Pseudo-Random Number Generation This protocol binds each session key to the session by including random, session specific data in the hash used to produce session keys. Special care should be taken to ensure that all of the random numbers are of good quality. If the random data here (e.g., DH parameters) are pseudo-random then the pseudo-random number generator should be cryptographically secure (i.e., its next output not easily guessed even when knowing all previous outputs) and, furthermore, proper entropy needs to be added to the pseudo-random number generator. RFC 1750 [1750] offers suggestions for sources of random numbers and entropy. Implementors should note the importance of entropy and the well-meant, anecdotal warning about the difficulty in properly implementing pseudo-random number generating functions. The amount of entropy available to a given client or server may sometimes be less than what is required. In this case one must either resort to pseudo-random number generation regardless of insufficient entropy or refuse to run the protocol. The latter is preferable. [1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. On Fri, 16 May 2003, David M. Williams wrote: > Chrris, > I hope that my signal-to-noise ratio on comments hasn't gotten too > low that I can't make a few comments on the PRNG section. > > Comments below: > > >============================================================ > > > >11.1 PRNG > > > the acronym PRNG lacks a parenthetical reference at it's first occurance > in the draft. > > s/PRNG/Pseudo-Random Number Generation/ > with the parenthetical reference in the following paragraphs or > > s/PRNG/Pseudo-Random Number Generator (PRNG)/ > This is probably not correct per the style RFC. > > also we seem to be using the acronym for both "generator" and > "generation". Do we care about the gramatical agreement? > > > > > This protocol binds each session key to the session by including > > random data that is specific to the session in the hash used to > > > maybe this is clearer, > s/random data that is specific to the session/random, session specific data/ > > > produce session keys. If the random data here (e.g., DH parameters) > > are pseudo-random then the PRNG should be cryptographically secure > > (i.e., its next output not easily guessed even when knowing all > > previous outputs) and, furthermore, entropy needs to be added to the > > PRNG. RFC 1750 [1750] offers suggestions for sources of entropy. > > Implementors should note the importance of entropy and the well-meant, > > anecdotal warning about the difficulty in properly implementing PRNG > > functions. > > > s/PRNG functions/PRNGs/ > fixes the usage issue, now all uses reflect the implied "generator" usage. > > > > > The amount of entropy available to a given client or server sometimes > > may be less than what is needed to run the protocol. In this case > > > s/sometimes may/may sometimes/ > > s/to run the protocol/to provide > > > one must either resort to PRNGs anyways or refuse to run the protocol. > > > s/anyways/regardless of insufficient entropy/ > > > In practice implementors will generally rely on some PRNG. > > > I'd like to suggest we drop this sentence. > > > > > > > > >[1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness > > Recommendations for Security", RFC 1750, December 1994. > > > > > > > > > > > > -- > David M. Williams, CISSP Phone: 505-665-8062 > Systems Engineer, CCN-2 Fax: 505-667-7942 > Los Alamos National Laboratory Email: d_wllmsATlanlDOTgov > > "Nel mezzo del cammin di nostra vita / mi ritrouvai per una selva oscura / > che la diritta via era smarrita" -Dante Aligheri > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 16:44:44 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10507 for ; Fri, 16 May 2003 16:44:44 -0400 (EDT) Received: (qmail 20659 invoked by uid 605); 16 May 2003 20:47:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20650 invoked from network); 16 May 2003 20:47:38 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 16 May 2003 20:47:38 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4GKlYWh017296 for ; Fri, 16 May 2003 13:47:34 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA24400 for ; Fri, 16 May 2003 13:47:34 -0700 (PDT) Date: Fri, 16 May 2003 13:47:34 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: New Proposal for Section 11.3 Authentication Protocol In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, I've made changes to the first part of Section 11.3 "Authentication Protocol" and 11.3.1 "Weak Transport" to address the concerns from Simon and Nico about MITM and _user_ authentication mechanisms. Please comment. Thanks, Chris =================================================================== 11.3 Authentication Protocol The purpose of this protocol is to perform client user authentication. It assumes that this run over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. Several authentication methods with different security characteristics are allowed. It is up to the server's local policy to decide which methods (or combinations of methods) it is willing to accept for each user. Authentication is no stronger than the weakest combination allowed. The server may go into a "sleep" period after repeated unsuccessful authentication attempts to make key search more difficult for attackers. Care should be taken so that this doesn't become a self-denial of service vector. 11.3.1 Weak Transport If the transport layer does not provide confidentiality, authentication methods that rely on secret data SHOULD be disabled. If it does not provide strong integrity protection, requests to change authentication data (e.g. a password change) SHOULD be disabled to prevent an attacker from modifying the ciphertext without being noticed, or rendering the new authentication data unusable (denial of service). The assumption as stated above that the Authentication Protocol only run over a secure transport that has previously authenticated the server is very important to note. People deploying SSH are reminded of the consequences of man-in-the-middle attacks if the client does not have a very strong a priori association of the server with the host key of that server. Specifically for the case of the Authentication Protocol the client may form a session to a man-in-the-middle attack device and divulge user credentials such as their username and password. Even in the cases of authentication where no user credentials are divulged, an attacker may still gain information they shouldn't have by capturing key-strokes in much the same way that a honeypot works. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 18:45:44 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13815 for ; Fri, 16 May 2003 18:45:43 -0400 (EDT) Received: (qmail 22587 invoked by uid 605); 16 May 2003 22:48:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22536 invoked from network); 16 May 2003 22:48:39 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 16 May 2003 22:48:39 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id 695667FD06; Sat, 17 May 2003 01:48:30 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id 5E53B7FD05; Sat, 17 May 2003 01:48:30 +0300 (EEST) Date: Sat, 17 May 2003 01:48:30 +0300 (EEST) From: Heikki Nousiainen To: ietf-ssh@netbsd.org Cc: RJ Atkinson Subject: SSH paper and a possible transport layer extension [was: aside on formal methods] In-Reply-To: <38974EB6-8702-11D7-BEDB-00039357A82A@extremenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list I found one paper on discussing the security of SSH, weakness with the CBC encryption modes and proofs of security in with CTR modes: Bellare, M., Kohno, T. adn Namprempre, C. "Authenticated Encryption in SSH: Provably Fixing the SSH Binary Packet Protocol" The attack presented in the paper against CBC mode encryption in SSH is, in my understanding, thwarted with inclusion of SSH_MSG_IGNORE packets as described in 11.1.1. An attacker has no knowledge of IV of the packets in which he can insert data, if the chapter is followed. The paper raises a question about the length of the sequence number used in conjunction with MACs and the possibilty of using encrypt-then-mac to check the authenticity of the ciphertext. Now, as far as I see, both of these limitations could be lifted by defining the size and the use of sequence number and the order in which the MAC is applied as properties of the selected MAC algorithm (similiar of the mode of operation for the ciphers). Backward compatibility with the current implementations could be maintained by careful selection of the initial counter values even when a MAC algorithm is changed during re-keying. I don't want to delay the drafts for this, but if there's an interest on this in the WG, maybe we can come up with an extension draft. Thoughts, anyone? - Heikki Nousiainen Examples: hmac-sha1 Initial sequence number is number-of-sent-packets modulo 2^32. Sequence number, 32 bit unsigned integer, is incremented for each packet and wraps around to zero after reaching 2^32-1. MAC is calculated as MAC = HMACsha1_K(sequence_number || unencrypted_packet) hmac-sha2-64_bit_sequence-encrypt_then_authenticate Initial sequence number is number-of-sent-packets modulo 2^32. Sequence number, 64 bit unsigned integer, is incremented for each packet and wraps around to zero after reaching 2^64-1. MAC is caclulated as MAC = HMACsha2_K(sequence_number || encrypted_packet) On Thu, 15 May 2003, RJ Atkinson wrote: > > Putting the practical questions of document editing aside > for the moment, the length of the discussion on Security > Considerations and the informal nature of that discussion > are a bit troubling to me. It makes one wonder whether the SSH > spec really did get all the pieces right -- and, if it did, > whether it did so by accident. > > It would be pleasant and helpful if there some more formal > analysis of the SSH protocol performed -- and published. The > first step would probably to try to come up with a formal > specification of the protocol in some appropriate logic. > > If there are any academic folks on this list, please consider > whether such formal methods work might be a reasonable research topic > to undertake. > > IMHO, > > Ran > rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 16 19:05:45 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14248 for ; Fri, 16 May 2003 19:05:45 -0400 (EDT) Received: (qmail 5333 invoked by uid 605); 16 May 2003 23:08:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5323 invoked from network); 16 May 2003 23:08:45 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 16 May 2003 23:08:45 -0000 Received: by xanthine.gratuitous.org with local; Fri, 16 May 2003 19:08:43 -0400 From: "Joel N. Weber II" To: ietf-ssh@netbsd.org cc: simon@sxw.org.uk Subject: rekeying, host key verification, and gssapi Message-Id: Date: Fri, 16 May 2003 19:08:43 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The current design of the ssh protocol makes the host key verification (whether by public key or by gssapi) and the DH exchange a single step. That seems fine for the initial key exchange. However, it can be a little bit unfortunate for rekeying, especially if the mechanism used for initial host key verification might not work at the time of rekeying. It also makes rekeying more expensive, and some of the mail seems to suggest that some people have some concern about the cost of rekeying. http://www.sxw.org.uk/computing/patches/openssh.html says ``Note that if you're using OpenSSH with GSSAPI support and your clients will only be performing GSSAPI authenticated connections and you can ensure that clients will have valid credentials when rekeying occurs, then you no longer need a host key for the version 2 protocol.'' If it is possible to do rekeying after GSSAPI credentials expire, that is something that many will find desireable. (There might be some who would prefer to see their connections terminate as soon as their credentials expire, and that is also an appropriate option to offer.) The current status quo that expired credentials don't terminate connections unless you happen to need rekeying seems poorly thought out, however. None of the justifications for rekeying I've seen (such as in the archives of this list in March and April of this year) mention any need to verify the identity of the server again, and furthurmore, if there were some need to do so, I would expect that the server would need to authenticate the client again, and the protocol does not appear to have any support for verifying the client again at the time of rekeying. My understanding is that the key exchange is protected by the symmetric cipher during rekeying. I think it would be appropriate to support the use of ``none'' as the public key algorithm during rekeying, using key exchange methods that normally do get used with public keys. The way this would be defined is that rather than sending a signature, a zero-length block of data would be sent by the protocol. Clients which do not have any desire to recheck the server's host key, whether because of concerns about expired GSSAPI credentials, or in order to reduce the overhead of rekeying, could prefer the use of the ``none'' host key algorithm, and the use of a non-GSSAPI key exchange method. (This would define ``none'' somewhat differently from how http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-06.txt defines it.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (NetBSD) iD8DBQE+xW90NIJPyVx4GhgRAgbrAKCJVTgoAlAa8Vi7/TFf1GwnUsHPzACguiTX wKsOB9PzKI5ojybjP/j5ILs= =ERvB -----END PGP SIGNATURE----- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat May 17 12:27:10 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10955 for ; Sat, 17 May 2003 12:27:09 -0400 (EDT) Received: (qmail 8137 invoked by uid 605); 17 May 2003 16:30:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8129 invoked from network); 17 May 2003 16:30:09 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 May 2003 16:30:09 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4HGU5HN013462; Sat, 17 May 2003 09:30:05 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4HGTxuP001842; Sat, 17 May 2003 10:29:59 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4HGRNQx003938; Sat, 17 May 2003 09:27:23 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4HGRM7e003937; Sat, 17 May 2003 09:27:22 -0700 (PDT) Date: Sat, 17 May 2003 09:27:22 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org, simon@sxw.org.uk Subject: Re: rekeying, host key verification, and gssapi Message-ID: <20030517092722.A3931@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ietf-secsh@joelweber.com on Fri, May 16, 2003 at 07:08:43PM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list One very nice side effect of rekeying with GSS-API keyex is that it allows your client to automatically re-delegate new GSS-API credentials. With Kerberos this means that when you tickets are close to expiration, you re-kinit at your console and the let rekeying re-forward your tickets. I do think that there should be an option to force GSS-API rekeying after GSS-API context expiration. Re-authenticating the server is not as important as re-authenticating the user. Normally rekeying does not re-authenticate the user, but that is what happens with GSS-API rekeying, and I think it's a fine thing too, though it would be obnoxious to re-run normal userauth as part of each rekeying event. But I see the point about unsigned rekeying being potentially useful. Cheers, Nico On Fri, May 16, 2003 at 07:08:43PM -0400, Joel N. Weber II wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > The current design of the ssh protocol makes the host key verification > (whether by public key or by gssapi) and the DH exchange a single > step. That seems fine for the initial key exchange. > > However, it can be a little bit unfortunate for rekeying, especially > if the mechanism used for initial host key verification might not work > at the time of rekeying. It also makes rekeying more expensive, and > some of the mail seems to suggest that some people have some concern > about the cost of rekeying. > > http://www.sxw.org.uk/computing/patches/openssh.html says ``Note that > if you're using OpenSSH with GSSAPI support and your clients will only > be performing GSSAPI authenticated connections and you can ensure that > clients will have valid credentials when rekeying occurs, then you no > longer need a host key for the version 2 protocol.'' > > If it is possible to do rekeying after GSSAPI credentials expire, that > is something that many will find desireable. (There might be some who > would prefer to see their connections terminate as soon as their > credentials expire, and that is also an appropriate option to offer.) > The current status quo that expired credentials don't terminate > connections unless you happen to need rekeying seems poorly thought > out, however. > > None of the justifications for rekeying I've seen (such as in the > archives of this list in March and April of this year) mention any > need to verify the identity of the server again, and furthurmore, if > there were some need to do so, I would expect that the server would > need to authenticate the client again, and the protocol does not > appear to have any support for verifying the client again at the time > of rekeying. > > My understanding is that the key exchange is protected by the symmetric > cipher during rekeying. > > I think it would be appropriate to support the use of ``none'' as the > public key algorithm during rekeying, using key exchange methods that > normally do get used with public keys. The way this would be defined > is that rather than sending a signature, a zero-length block of data > would be sent by the protocol. Clients which do not have any desire > to recheck the server's host key, whether because of concerns about > expired GSSAPI credentials, or in order to reduce the overhead of > rekeying, could prefer the use of the ``none'' host key algorithm, and > the use of a non-GSSAPI key exchange method. (This would define > ``none'' somewhat differently from how > http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-06.txt > defines it.) > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.0 (NetBSD) > > iD8DBQE+xW90NIJPyVx4GhgRAgbrAKCJVTgoAlAa8Vi7/TFf1GwnUsHPzACguiTX > wKsOB9PzKI5ojybjP/j5ILs= > =ERvB > -----END PGP SIGNATURE----- > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat May 17 12:29:18 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10972 for ; Sat, 17 May 2003 12:29:18 -0400 (EDT) Received: (qmail 9927 invoked by uid 605); 17 May 2003 16:32:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9876 invoked from network); 17 May 2003 16:32:18 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 May 2003 16:32:18 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4HGWHHN013934; Sat, 17 May 2003 09:32:17 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4HGWCuP002623; Sat, 17 May 2003 10:32:12 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4HGTZQx003946; Sat, 17 May 2003 09:29:36 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4HGTZu5003945; Sat, 17 May 2003 09:29:35 -0700 (PDT) Date: Sat, 17 May 2003 09:29:35 -0700 From: Nicolas Williams To: Heikki Nousiainen Cc: ietf-ssh@netbsd.org, RJ Atkinson Subject: Re: SSH paper and a possible transport layer extension [was: aside on formal methods] Message-ID: <20030517092935.B3931@binky.central.sun.com> References: <38974EB6-8702-11D7-BEDB-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from htn@sumu.org on Sat, May 17, 2003 at 01:48:30AM +0300 Sender: ietf-ssh-owner@netbsd.org Precedence: list It is bad to let sequence numbers wrap around while using the same key. Rekeying takes care of this problem. Nico On Sat, May 17, 2003 at 01:48:30AM +0300, Heikki Nousiainen wrote: > I found one paper on discussing the security of SSH, weakness with the > CBC encryption modes and proofs of security in with CTR modes: > Bellare, M., Kohno, T. adn Namprempre, C. > "Authenticated Encryption in SSH: Provably Fixing the SSH Binary Packet > Protocol" > > The attack presented in the paper against CBC mode encryption in SSH is, > in my understanding, thwarted with inclusion of SSH_MSG_IGNORE packets as > described in 11.1.1. An attacker has no knowledge of IV of the packets in > which he can insert data, if the chapter is followed. > > > The paper raises a question about the length of the sequence number used > in conjunction with MACs and the possibilty of using encrypt-then-mac to > check the authenticity of the ciphertext. Now, as far as I see, both of > these limitations could be lifted by defining the size and the use of > sequence number and the order in which the MAC is applied as properties > of the selected MAC algorithm (similiar of the mode of operation for the > ciphers). Backward compatibility with the current implementations could > be maintained by careful selection of the initial counter values even > when a MAC algorithm is changed during re-keying. > > I don't want to delay the drafts for this, but if there's an interest on > this in the WG, maybe we can come up with an extension draft. > > Thoughts, anyone? > > - Heikki Nousiainen > > > Examples: > > hmac-sha1 > > Initial sequence number is number-of-sent-packets modulo 2^32. Sequence > number, 32 bit unsigned integer, is incremented for each packet and wraps > around to zero after reaching 2^32-1. MAC is calculated as > MAC = HMACsha1_K(sequence_number || unencrypted_packet) > > > hmac-sha2-64_bit_sequence-encrypt_then_authenticate > > Initial sequence number is number-of-sent-packets modulo 2^32. Sequence > number, 64 bit unsigned integer, is incremented for each packet and wraps > around to zero after reaching 2^64-1. MAC is caclulated as > MAC = HMACsha2_K(sequence_number || encrypted_packet) > > > On Thu, 15 May 2003, RJ Atkinson wrote: > > > > Putting the practical questions of document editing aside > > for the moment, the length of the discussion on Security > > Considerations and the informal nature of that discussion > > are a bit troubling to me. It makes one wonder whether the SSH > > spec really did get all the pieces right -- and, if it did, > > whether it did so by accident. > > > > It would be pleasant and helpful if there some more formal > > analysis of the SSH protocol performed -- and published. The > > first step would probably to try to come up with a formal > > specification of the protocol in some appropriate logic. > > > > If there are any academic folks on this list, please consider > > whether such formal methods work might be a reasonable research topic > > to undertake. > > > > IMHO, > > > > Ran > > rja@extremenetworks.com > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat May 17 14:25:58 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12254 for ; Sat, 17 May 2003 14:25:57 -0400 (EDT) Received: (qmail 6420 invoked by uid 605); 17 May 2003 18:28:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6411 invoked from network); 17 May 2003 18:28:57 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 17 May 2003 18:28:57 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id A87B47FD06; Sat, 17 May 2003 21:28:44 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id A7A9F7FD05; Sat, 17 May 2003 21:28:44 +0300 (EEST) Date: Sat, 17 May 2003 21:28:44 +0300 (EEST) From: Heikki Nousiainen To: ietf-ssh@netbsd.org Cc: Nicolas Williams , RJ Atkinson Subject: Re: SSH paper and a possible transport layer extension [was: aside on formal methods] In-Reply-To: <20030517092935.B3931@binky.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, 17 May 2003, Nicolas Williams wrote: > It is bad to let sequence numbers wrap around while using the same key. > Rekeying takes care of this problem. Oh yes, the rekeying is required, but with a 64bit counter, a suitable MAC algorithm and a suitable cipher, we can bump up the re-keying requirement up to every 2^64 packets. Excessive? Maybe as for today, but modularising this aspect of the protocol paves way for future changes if so needed. Here's some motivation behind the proposed change, something I should have included in the earlier post already: - modularising integrity protection of the protocol, making future changes easy to incorporate - lifting the re-keying constraints on the MAC algorithm (e.g. 64bit counter, cipher with blocksize of 256 bits => rekey after 2^64 packets) - authentication of either plaintext or ciphertext (or even both for that matter) at the selection of a MAC algorithm - complete backward compatibility with careful specification of the MAC algorithms Best regards, Heikki Nousiainen > On Sat, May 17, 2003 at 01:48:30AM +0300, Heikki Nousiainen wrote: [snip] > > The paper raises a question about the length of the sequence number used > > in conjunction with MACs and the possibilty of using encrypt-then-mac to > > check the authenticity of the ciphertext. Now, as far as I see, both of > > these limitations could be lifted by defining the size and the use of > > sequence number and the order in which the MAC is applied as properties > > of the selected MAC algorithm (similiar of the mode of operation for the > > ciphers). Backward compatibility with the current implementations could > > be maintained by careful selection of the initial counter values even > > when a MAC algorithm is changed during re-keying. [snip] > > > > Examples: > > > > hmac-sha1 > > > > Initial sequence number is number-of-sent-packets modulo 2^32. Sequence > > number, 32 bit unsigned integer, is incremented for each packet and wraps > > around to zero after reaching 2^32-1. MAC is calculated as > > MAC = HMACsha1_K(sequence_number || unencrypted_packet) > > > > > > hmac-sha2-64_bit_sequence-encrypt_then_authenticate > > > > Initial sequence number is number-of-sent-packets modulo 2^32. Sequence > > number, 64 bit unsigned integer, is incremented for each packet and wraps > > around to zero after reaching 2^64-1. MAC is caclulated as > > MAC = HMACsha2_K(sequence_number || encrypted_packet) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat May 17 18:40:10 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17402 for ; Sat, 17 May 2003 18:40:10 -0400 (EDT) Received: (qmail 18299 invoked by uid 605); 17 May 2003 22:43:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18291 invoked from network); 17 May 2003 22:43:10 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 May 2003 22:43:10 -0000 Received: by xanthine.gratuitous.org with local; Sat, 17 May 2003 18:43:05 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: ietf-ssh@netbsd.org, simon@sxw.org.uk In-reply-to: <20030517092722.A3931@binky.central.sun.com> (message from Nicolas Williams on Sat, 17 May 2003 09:27:22 -0700) Subject: Re: rekeying, host key verification, and gssapi References: <20030517092722.A3931@binky.central.sun.com> Message-Id: Date: Sat, 17 May 2003 18:43:05 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > One very nice side effect of rekeying with GSS-API keyex is that it > allows your client to automatically re-delegate new GSS-API credentials. You're right, and I hadn't realized that, but being able to redelegate credentials is certainly a feature the protocol ought to support. Perhaps the correct semantic is for rekeying to redo GSSAPI keyex iff the credentials currently available are unexpired, don't expire for at least 10 minutes (to allow enough time for clock skew and for keyex to take whatever real time it actually takes, since if GSSAPI keyex fails I believe your session immediately dies), and are different from the credentials that were used last time GSSAPI keyex happened, and otherwise do rekeying that does not do any verification. I do wonder if that leaves a race condition where if I run kinit at the exact same time ssh recieves an update of the clock in the status line from my emacs running on a remote system, causing automatic rekeying to happen, if it's possible for a gssapi call to fail as a result of trying to use credentials that are changing while the keyex is happening. > With Kerberos this means that when you tickets are close to expiration, > you re-kinit at your console and the let rekeying re-forward your > tickets. Or, the way I tend to use kerberos tickets for AFS access, it would mean that after my tickets expire, I notice that my remote logins to machines that use AFS no longer have access to my homedir, and I rekinit on the console and manually force rekeying to push the tickets. > I do think that there should be an option to force GSS-API rekeying > after GSS-API context expiration. Can this be done in such a way that the session gets stuck in the rekeying state where all data is queued until rekeying is successful? (Otherwise, I'm not sure that it would be meaningfully different from an option to just close the connection if the gssapi credentials ever are allowed to expire without being renewed.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (NetBSD) iD8DBQE+xrqvNIJPyVx4GhgRAr7zAJ9FgMHH41IpHIyzoH7m52AcD/3JXACdGBuL goaYfw+VC9467rRiwkAjujo= =jwFs -----END PGP SIGNATURE----- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun May 18 00:04:39 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20385 for ; Sun, 18 May 2003 00:04:39 -0400 (EDT) Received: (qmail 8464 invoked by uid 605); 18 May 2003 04:07:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8457 invoked from network); 18 May 2003 04:07:40 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 18 May 2003 04:07:40 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4I47bY9008184; Sat, 17 May 2003 22:07:37 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4I47aNg028506; Sat, 17 May 2003 22:07:36 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4I450Qx004368; Sat, 17 May 2003 21:05:00 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4I44wVK004367; Sat, 17 May 2003 21:04:58 -0700 (PDT) Date: Sat, 17 May 2003 21:04:58 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org, simon@sxw.org.uk Subject: Re: rekeying, host key verification, and gssapi Message-ID: <20030517210458.K4352@binky.central.sun.com> References: <20030517092722.A3931@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ietf-secsh@joelweber.com on Sat, May 17, 2003 at 06:43:05PM -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, May 17, 2003 at 06:43:05PM -0400, Joel N. Weber II wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > One very nice side effect of rekeying with GSS-API keyex is that it > > allows your client to automatically re-delegate new GSS-API credentials. > > You're right, and I hadn't realized that, but being able to redelegate > credentials is certainly a feature the protocol ought to support. Keep in mind that with the GSS-API (v2, update 1) re-delegating creds always requires establishing a new context. > Perhaps the correct semantic is for rekeying to redo GSSAPI keyex iff > the credentials currently available are unexpired, don't expire for at > least 10 minutes (to allow enough time for clock skew and for keyex to > take whatever real time it actually takes, since if GSSAPI keyex fails > I believe your session immediately dies), and are different from the > credentials that were used last time GSSAPI keyex happened, and > otherwise do rekeying that does not do any verification. The client can always force rekeying with GSS-API to forward creds if and when it wants to. The client could easily check on its credentials around and after the time of their expiration and rekey as soon as fresh creds appear to be available. > I do wonder if that leaves a race condition where if I run kinit at > the exact same time ssh recieves an update of the clock in the status > line from my emacs running on a remote system, causing automatic > rekeying to happen, if it's possible for a gssapi call to fail as a > result of trying to use credentials that are changing while the keyex > is happening. Depends on the implementation. But I think implementors generally know about locking :) > > I do think that there should be an option to force GSS-API rekeying > > after GSS-API context expiration. > > Can this be done in such a way that the session gets stuck in the > rekeying state where all data is queued until rekeying is successful? Dunno - 'twould be a nice feature though (should the server stop your processes too?) > (Otherwise, I'm not sure that it would be meaningfully different from > an option to just close the connection if the gssapi credentials ever > are allowed to expire without being renewed.) It sure is different; some implementations might cache users' longterm keys and keep refreshing their creds as long as the user is logged in on the console, say (I believe on implementation of Kerberos does this), so that the user effectively always has creds as long as she stays logged in on console somewhere and is not terminated or locked out. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun May 18 00:09:40 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20411 for ; Sun, 18 May 2003 00:09:40 -0400 (EDT) Received: (qmail 10756 invoked by uid 605); 18 May 2003 04:12:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10733 invoked from network); 18 May 2003 04:12:39 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 18 May 2003 04:12:39 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4I4Ccx9007165; Sat, 17 May 2003 21:12:38 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4I4CbNg000521; Sat, 17 May 2003 22:12:37 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4I4A1Qx004378; Sat, 17 May 2003 21:10:01 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4I4A0M9004377; Sat, 17 May 2003 21:10:00 -0700 (PDT) Date: Sat, 17 May 2003 21:10:00 -0700 From: Nicolas Williams To: Heikki Nousiainen Cc: ietf-ssh@netbsd.org, RJ Atkinson Subject: Re: SSH paper and a possible transport layer extension [was: aside on formal methods] Message-ID: <20030517211000.L4352@binky.central.sun.com> References: <20030517092935.B3931@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from htn@sumu.org on Sat, May 17, 2003 at 09:28:44PM +0300 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, May 17, 2003 at 09:28:44PM +0300, Heikki Nousiainen wrote: > On Sat, 17 May 2003, Nicolas Williams wrote: > > It is bad to let sequence numbers wrap around while using the same key. > > Rekeying takes care of this problem. > > Oh yes, the rekeying is required, but with a 64bit counter, a suitable MAC > algorithm and a suitable cipher, we can bump up the re-keying requirement > up to every 2^64 packets. Excessive? Maybe as for today, but modularising > this aspect of the protocol paves way for future changes if so needed. I don't see anything stopping a future SSHv2 encr/mac alg set from requiring larger sequence numbers. I wouldn't mind sequence number sizes being negotiable though (I take it this is what you mean by "modularizing"). I think larger sequence numbers (e.g., 64 bits and up) are a must for protocols that don't support rekeying; for those that do, unless rekeying is onerous (and I don't think SSHv2 rekeking is), smaller sequence numbers (e.g., 32 bits) are not such a bad thing. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun May 18 01:30:01 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21233 for ; Sun, 18 May 2003 01:30:01 -0400 (EDT) Received: (qmail 13011 invoked by uid 605); 18 May 2003 05:33:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13001 invoked from network); 18 May 2003 05:32:59 -0000 Received: from shadow.sumu.org (194.100.33.96) by mail.netbsd.org with SMTP; 18 May 2003 05:32:59 -0000 Received: by shadow.sumu.org (Postfix, from userid 1002) id 0487A7FD06; Sun, 18 May 2003 08:32:50 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by shadow.sumu.org (Postfix) with ESMTP id 021C97FD05; Sun, 18 May 2003 08:32:50 +0300 (EEST) Date: Sun, 18 May 2003 08:32:49 +0300 (EEST) From: Heikki Nousiainen To: ietf-ssh@netbsd.org Cc: Nicolas Williams , RJ Atkinson Subject: Re: SSH paper and a possible transport layer extension [was: aside on formal methods] In-Reply-To: <20030517211000.L4352@binky.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sat, 17 May 2003, Nicolas Williams wrote: > > I don't see anything stopping a future SSHv2 encr/mac alg set from > requiring larger sequence numbers. I wouldn't mind sequence number > sizes being negotiable though (I take it this is what you mean by > "modularizing"). The only thing stopping this is the section 4.4 of the transport layer spec. As it now stands, the spec dictates 32 bit counter and authenticating the plaintext. It's an artificial limitation, which, I think, could be lifted by defining these properties with the MAC algorithm [algorithm, as defined for use in secsh]. > I think larger sequence numbers (e.g., 64 bits and up) are a must for > protocols that don't support rekeying; for those that do, unless > rekeying is onerous (and I don't think SSHv2 rekeking is), smaller > sequence numbers (e.g., 32 bits) are not such a bad thing. MAC is not the only part requiring rekey, but yes, with ciphers with bigger blocksizes, the rekeying is likely to be required for the MAC first. Rekeying is not that much of a problem with the current algorithms, but it may be in the future. We need bigger DH groups and more expensive calculations for bigger keysizes. With data growing and transports getting faster we are likely to hit the limitation faster. Why not change the behaviour before it becomes a problem? Regards, Heikki Nousiainen Few corrections to my earlier post: - The underlying cipher doesn't know packets, so the rekeying requirement can't be expressed as 2^64 packets as I wrote. For 256bit block cipher, this should be every 2^64 blocks or with 64 bit sequence number, 2^64 packets, whichever comes first. - I mix use the term MAC algorithm with both the function and how MAC algorithm is specified in the spec; first occurence should be function, the latter two refer to how MAC is specified in the spec. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun May 18 11:40:51 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11769 for ; Sun, 18 May 2003 11:40:50 -0400 (EDT) Received: (qmail 15434 invoked by uid 605); 18 May 2003 15:43:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15422 invoked from network); 18 May 2003 15:43:47 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 18 May 2003 15:43:47 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4IFhkY9013361; Sun, 18 May 2003 09:43:46 -0600 (MDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4IFhjuP001045; Sun, 18 May 2003 09:43:45 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4IFf8Qx004627; Sun, 18 May 2003 08:41:08 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4IFf7xN004626; Sun, 18 May 2003 08:41:07 -0700 (PDT) Date: Sun, 18 May 2003 08:41:07 -0700 From: Nicolas Williams To: Heikki Nousiainen Cc: ietf-ssh@netbsd.org, RJ Atkinson Subject: Re: SSH paper and a possible transport layer extension [was: aside on formal methods] Message-ID: <20030518084107.N4352@binky.central.sun.com> References: <20030517211000.L4352@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from htn@sumu.org on Sun, May 18, 2003 at 08:32:49AM +0300 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Sun, May 18, 2003 at 08:32:49AM +0300, Heikki Nousiainen wrote: > On Sat, 17 May 2003, Nicolas Williams wrote: > > > > I don't see anything stopping a future SSHv2 encr/mac alg set from > > requiring larger sequence numbers. I wouldn't mind sequence number > > sizes being negotiable though (I take it this is what you mean by > > "modularizing"). > > The only thing stopping this is the section 4.4 of the transport layer > spec. As it now stands, the spec dictates 32 bit counter and > authenticating the plaintext. It's an artificial limitation, which, I Sure, but I don't think that really stops a future SSHv2 mac/enc alg spec from saying otherwise. > think, could be lifted by defining these properties with the MAC > algorithm [algorithm, as defined for use in secsh]. > > > > I think larger sequence numbers (e.g., 64 bits and up) are a must for > > protocols that don't support rekeying; for those that do, unless > > rekeying is onerous (and I don't think SSHv2 rekeking is), smaller > > sequence numbers (e.g., 32 bits) are not such a bad thing. > > MAC is not the only part requiring rekey, but yes, with ciphers with > bigger blocksizes, the rekeying is likely to be required for the MAC > first. > > Rekeying is not that much of a problem with the current algorithms, but it > may be in the future. We need bigger DH groups and more expensive > calculations for bigger keysizes. With data growing and transports > getting faster we are likely to hit the limitation faster. Why not change > the behaviour before it becomes a problem? I'm not saying "don't." I'm pointing out that I don't think the current drafts need modifying to accomodate larger sequence numbers and so on - unless one wishes to make those directly negotiable during initial keyex, as opposed to indirectly by negotiation of enc/mac algs, but that would be a an incompatible change unless it were associated with a new keyex type, but that would mean introducing a new keyex type for GSS-API. It will be easier to associate these features of the SSHv2 crypto system with mac and enc alg types than to make them directly negotiable, so the current drafts, IMO, need no changes then. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon May 19 22:21:52 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13291 for ; Mon, 19 May 2003 22:21:51 -0400 (EDT) Received: (qmail 2043 invoked by uid 605); 20 May 2003 02:24:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2036 invoked from network); 20 May 2003 02:24:51 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 20 May 2003 02:24:51 -0000 Received: from [127.0.0.1] (HELO BHAG3) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 1530455 for ietf-ssh@netbsd.org; Mon, 19 May 2003 20:24:49 -0600 Message-ID: <000f01c31e76$fbb7b240$6601a8c0@BHAG3> From: "Jeff P. Van Dyke" To: Subject: It the WG planning on meeting in Austria? Date: Mon, 19 May 2003 20:24:36 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Are they any plans for the WG to meet in Vienna, Austria (July 13-18)? Jeff P. Van Dyke jpv@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 20 20:56:45 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07493 for ; Tue, 20 May 2003 20:56:42 -0400 (EDT) Received: (qmail 12109 invoked by uid 605); 21 May 2003 00:56:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12102 invoked from network); 21 May 2003 00:56:39 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 21 May 2003 00:56:39 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.9/8.12.6) with ESMTP id h4L0ucMB025536 for ; Tue, 20 May 2003 17:56:38 -0700 Received: from vger.corp.google.com (vger.corp.google.com [10.32.60.132]) by moma.corp.google.com (8.12.9/8.12.3) with ESMTP id h4L0ucYh025694 for ; Tue, 20 May 2003 17:56:38 -0700 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id h4L0uc902443 for ietf-ssh@netbsd.org; Tue, 20 May 2003 17:56:38 -0700 Date: Tue, 20 May 2003 17:56:38 -0700 From: Frank Cusack To: ietf-ssh@netbsd.org Subject: kbdint in userauth Message-ID: <20030520175638.B2428@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list Any thoughts on whether kbdint should be directly embedded in the userauth document? How about just a reference to it, perhaps at the end of the password auth discussion? /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 21 12:36:38 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27602 for ; Wed, 21 May 2003 12:36:37 -0400 (EDT) Received: (qmail 462 invoked by uid 605); 21 May 2003 16:36:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 454 invoked from network); 21 May 2003 16:36:29 -0000 Received: from fe3-cox.cox-internet.com (HELO fe3.cox-internet.com) (66.76.2.40) by mail.netbsd.org with SMTP; 21 May 2003 16:36:29 -0000 Received: from cox-internet.com ([66.233.161.129]) by fe3.cox-internet.com (InterMail vK.4.04.00.03 201-232-140-20030416 license f018ea6efd6984189790b5f401fab223) with ESMTP id <20030521163622.GQMQ17119.fe3@cox-internet.com> for ; Wed, 21 May 2003 11:36:22 -0500 Message-ID: <131680-220035321151719562@RICKSCHULZ> Disposition-Notification-To: rschulz@cox-internet.com Organization: Home Based Buisness From: "Rick Schulz" To: ietf-ssh@netbsd.org Subject: Home Based Business for you.Check it out !!! Date: Wed, 21 May 2003 10:17:19 -0500 MIME-Version: 1.0 Content-type: text/plain; charset="windows-1252" Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA27602 Hi Everyone This web site www.imagine2020.com/759705302 and www.mynetmarketer.com/members/2338. Check it out everyone it is free to check it out.If it is okay pass this message around to everyone in the organization via email. Sincerely Rick Schulz Net work marketing From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 21 15:37:10 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05669 for ; Wed, 21 May 2003 15:37:08 -0400 (EDT) Received: (qmail 8552 invoked by uid 605); 21 May 2003 19:36:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8543 invoked from network); 21 May 2003 19:36:51 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by mail.netbsd.org with SMTP; 21 May 2003 19:36:51 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4LJaoed027528 for ; Wed, 21 May 2003 12:36:50 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA18703 for ; Wed, 21 May 2003 12:36:50 -0700 (PDT) Date: Wed, 21 May 2003 12:36:49 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: Pulling it all together - New Section 11 on Security Considerations Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Folks, Below is the latest version of the Security Considerations section. This reflects all of the discussions on the lists on the various parts of this over the past few weeks. I appreciate all of the feedback and help. I've also put together an html document of the changes from the previous version; red strike outs for deletions and green text for insertions. I'll put it on a web server and send around a pointer rsn. [The server isn't doing so well today but I think it will be fixed in the next day or so.] If you'd like to see that sooner rather than later, please email me directly and I'll send it to you. If you would like to suggest any changes, please call out the relevent section in the Subject line of your email. Also, please remove the non-related sections from your reply as this thing is getting a bit long. Thanks, Chris ========================================================================== 11. Security Considerations In order to make the entire body of Security Considerations more accessible, Security Considerations for the transport, authentication, and connection documents have been gathered here. The transport protocol [SSH-TRANS] provides a confidential channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. The authentication protocol [SSH-USERAUTH] provides a suite of mechanisms which can be used to authenticatethe client user to the server. Individual mechanisms specified in the in authentication protocol use the session id provided by the transport protocol and/or depend on the security and integrity guarantees of the transport protocol. The connection protocol [SSH-CONNECT] specifies a mechanism to multiplex multiple streams (channels) of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for 'proxy-forwarding' various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure 'subsystems' on the server host. 11.1 PRNG This protocol binds each session key to the session by including random, session specific data in the hash used to produce session keys. Special care should be taken to ensure that all of the random numbers are of good quality. If the random data here (e.g., DH parameters) are pseudo-random then the pseudo-random number generator should be cryptographically secure (i.e., its next output not easily guessed even when knowing all previous outputs) and, furthermore, proper entropy needs to be added to the pseudo-random number generator. RFC 1750 [RFC1750] offers suggestions for sources of random numbers and entropy. Implementors should note the importance of entropy and the well-meant, anecdotal warning about the difficulty in properly implementing pseudo-random number generating functions. The amount of entropy available to a given client or server may sometimes be less than what is required. In this case one must either resort to pseudo-random number generation regardless of insufficient entropy or refuse to run the protocol. The latter is preferable. 11.2 Transport 11.2.1 Confidentiality It is beyond the scope of this document and the Secure Shell Working Group to analyze or recommend specific ciphers other than the ones which have been established and accepted within the industry. At the time of this writing, ciphers commonly in use include 3DES, ARCFOUR, twofish, serpent and blowfish. AES has been accepted by The US Federal Information Processing Standards [FIPS-197] and the cryptographic community as being acceptable for this purpose as well. As always, implementors and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementors should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen. The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. It's cryptographic properties are sufficiently described in RFC 2410 [RFC2410], which will show that its use does not meet the intent of this protocol. The relative merits of these and other ciphers may also be found in current literature. Two references that may provide information on the subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these describe the CBC mode of operation of certain ciphers and the weakness of this scheme. Essentially, this mode is theoretically vulnerable to chosen cipher-text attacks because of the high predictability of the start of packet sequence. However, this attack is still deemed difficult and not considered fully practicable especially if relatively longer block sizes are used. Additionally, another CBC mode attack may be mitigated through the insertion of packets containing SSH_MSG_IGNORE. Without this technique, a specific attack may be successful. For this attack (commonly known as the Rogaway attack) to work, the attacker would need to know the IV of the next block that is going to be encrypted. In CBC mode that is the output of the encryption of the previous block. If the attacker does not have any way to see the packet yet (i.e it is in the internal buffers of the ssh implementation or even in the kernel) then this attack will not work. If the last packet has been sent out to the network (i.e the attacker has access to it) then he can use the attack. In the optimal case an implementor would need to add an extra packet only if the packet has been sent out onto the network and there are no other packets waiting for transmission. Implementors may wish to check to see if there are any unsent packets awaiting transmission, but unfortunately it is not normally easy to obtain this information from the kernel or buffers. If there are not, then a packet containing SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream every time the attacker knows the IV that is supposed to be used for the next packet, then the attacker will not be able to guess the correct IV, thus the attack will never be successfull. As an example, consider the following case: Client Server ------ ------ TCP(seq=x, len=500) -> contains Record 1 [500 ms passes, no ACK] TCP(seq=x, len=1000) -> contains Records 1,2 <- ACK (1) The Nagle algorithm + TCP retransmits mean that the two records get coalesced into a single TCP segment (2) Record 2 is *not* at the beginning of the TCP segment and never will be, since it gets ACKed. (3) Yet, the attack is possible because Record 1 has already been seen. As this example indicates, it's totally unsafe to use the existence of unflushed data in the TCP buffers proper as a guide to whether you need an empty packet, since when you do the second write(), the buffers will contain the un-ACKed Record 1. On the other hand, it's perfectly safe to have the following situation: Client Server ------ ------ TCP(seq=x, len=500) -> contains SSH_MSG_IGNORE TCP(seq=y, len=500) -> contains Data Provided that the IV for second SSH Record is fixed after the data for the Data packet is determined -i.e. you do: read from user encrypt null packet encrypt data packet 11.2.2 Data Integrity This protocol does allow the Data Integrity mechanism to be disabled. Implementors SHOULD be wary of exposing this feature for any purpose other than debugging. Users and administrators SHOULD be explicitly warned anytime the "none" MAC is enabled. So long as the "none" MAC is not used, this protocol provides data integrity. Because MACs use a 32 bit sequence number, they might start to leak information after 2**32 packets have been sent. However, following the rekeying recommendations should prevent this attack. The transport protocol [1] recommends rekeying after one gigabyte of data, and the smallest possible packet is 16 bytes. Therefore, rekeying SHOULD happen after 2**28 packets at the very most. 11.2.3 Replay The use of a MAC other than 'none' provides integrity and authentication. In addition, the transport protocol provides a unique session identifier (bound in part to pseudo-random data that is part of the algorithm and key exchange process) that can be used by higher level protocols to bind data to a given session and prevent replay of data from prior sessions. For example, the authentication protocol uses this to prevent replay of signatures from previous sessions. Because public key authentication exchanges are cryptographically bound to the session (i.e., to the initial key exchange) they cannot be successfully replayed in other sessions. Note that the session ID can be made public without harming the security of the protocol. If two session happen to have the same session ID [hash of key exchanges] then packets from one can be replayed against the other. It must be stressed that the chances of such an occurrence are, needless to say, minimal when using modern cryptographic methods. This is all the more so true when specifying larger hash function outputs and DH parameters. Replay detection using monotonically increasing sequence numbers as input to the MAC, or HMAC in some cases, is described in RFC 2085 [RFC2085], RFC 2246 [RFC2246], RFC 2743 [RFC2743], RFC 1964 [RFC1964], RFC 2025 [RFC2025], and RFC 1510 [RFC1510]. The underlying construct is discussed in RFC 2104 [RFC2104]. Essentially a different sequence number in each packet ensures that at least this one input to the MAC function will be unique and will provide a nonrecurring MAC output that is not predictable to an attacker. If the session stays active long enough, however, this sequence number will wrap. This event may provide an attacker an opportunity to replay a previously recorded packet with an identical sequence number but only if the peers have not rekeyed since the transmission of the first packet with that sequence number. If the peers have rekeyed, then the replay will be detected as the MAC check will fail. For this reason, it must be emphasized that peers MUST rekey before a wrap of the sequence numbers. Naturally, if an attacker does attempt to replay a captured packet before the peers have rekeyed, then the receiver of the duplicate packet will not be able to validate the MAC and it will be discarded. The reason that the MAC will fail is because the receiver will formulate a MAC based upon the packet contents, the shared secret, and the expected sequence number. Since the replayed packet will not be using that expected sequence number (the sequence number of the replayed packet will have already been passed by the receiver) then the calculated MAC will not match the MAC received with the packet. 11.2.4 Man-in-the-middle This protocol makes no assumptions nor provisions for an infrastructure or means for distributing the public keys of hosts. It is expected that this protocol will sometimes be used without first verifying the association between the server host key and the server host name. Such usage is vulnerable to man-in-the-middle attacks. This section describes this and encourages administrators and users to understand the importance of verifying this association before any session is initiated. There are two cases of man-in-the-middle attacks to consider. The first is where an attacker places a device between the client and the server before the session is initiated. In this case, the attack device is trying to mimic the legitimate server and will offer its public key to the client when the client initiates a session. If it were to offer the public key of the server, then it would not be able to decrypt or sign the transmissions between the legitimate server and the client unless it also had access to the private-key of the host. The attack device will also, simultaneously to this, initiate a session to the legitimate server masquerading itself as the client. If the public key of the server had been securely distributed to the client prior to that session initiation, the key offered to the client by the attack device will not match the key stored on the client. In that case, the user SHOULD be given a warning that the offered host key does not match the host key cached on the client. As described in Section 3.1 of [SSH-ARCH], the user may be free to accept the new key and continue the session. It is RECOMMENDED that the warning provide sufficient information to the user of the client device so they may make an informed decision. If the user chooses to continue the session with the stored public-key of the server (not the public-key offered at the start of the session), then the session specific data between the attacker and server will be different between the client-to-attacker session and the attacker-to-server sessions due to the randomness discussed above. From this, the attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session specific data from the server since he does not have the private key of that server. Insecure distribution of server public keys allows a second type of man-in-the-middle attack that should also be considered in this case; one with suitable but incorrect host keys. If the server public keys are not securely distributed then the client cannot know if it is talking to the intended server. An attacker may use social engineering techniques to pass off server keys to unsuspecting users and may then place a man-in-the-middle attack device between the legitimate server and the clients. If this is allowed to happen then the clients will form client-to-attacker sessions and the attacker will form attacker-to-server sessions and will be able to monitor and manipulate all of the traffic between the clients and the legitimate servers. Server administrators are encouraged to make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also include secured Web pages, physical pieces of paper, etc. Implementors SHOULD provide recommendations on how best to do this with their implementation. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, making the host key fingerprint available through a secure DNS lookup, or using kerberos over gssapi during key exchange to authenticate the server are possibilities. As a second man-in-the-middle case, attackers may attempt to manipulate packets in transit between peers after the session has been established. As described in the Replay part of this section, a successful attack of this nature is very improbable. As in the Replay section, this reasoning does assume that the MAC is secure and that it is infeasible to construct inputs to a MAC algorithm to give a known output. This is discussed in much greater detail in Section 6 of RFC 2104. If the MAC algorithm has a vulnerability or is weak enough, then the attacker may be able to specify certain inputs to yield a known MAC. With that they may be able to alter the contents of a packet in transit. Alternatively the attacker may be able to exploit the algorithm vulnerability or weakness to find the shared secret by reviewing the MACs from captured packets. In either of those cases, an attacker could construct a packet or packets that could be inserted into an SSH stream. To prevent that, implementors are encouraged to utilize commonly accepted MAC algorithms and administrators are encouraged to watch current literature and discussions of cryptography to ensure that they are not using a MAC algorithm that has a recently found vulnerability or weakness. In summary, the use of this protocol without a reliable association of the binding between a host and its host keys is inherently insecure and is NOT RECOMMENDED. It may however be necessary in non-security critical environments, and will still provide protection against passive attacks. Implementors of protocols and applications running on top of this protocol should keep this possibility in mind. 11.2.5 Denial-of-service This protocol is designed to be used over a reliable transport. If transmission errors or message manipulation occur, the connection is closed. The connection SHOULD be re-established if this occurs. Denial of service attacks of this type ("wire cutter") are almost impossible to avoid. In addition, this protocol is vulnerable to Denial of Service attacks because an attacker can force the server to go through the CPU and memory intensive tasks of connection setup and key exchange without authenticating. Implementors SHOULD provide features that make this more difficult. For example, only allowing connections from a subset of IPs known to have valid users. 11.2.6 Covert Channels The protocol was not designed to eliminate covert channels. For example, the padding, SSH_MSG_IGNORE messages, and several other places in the protocol can be used to pass covert information, and the recipient has no reliable way to verify whether such information is being sent. 11.2.7 Forward Secrecy It should be noted that the Diffie-Hellman key exchanges may provide perfect forward secrecy (PFS). PFS is essentially defined as the cryptographic property of a key-establishment protocol in which the compromise of a session key or long-term private key after a given session does not cause the compromise of any earlier session. [ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using diffie-hellman-group1-sha1 are secure even if private keying/authentication material is later revealed, but not if the session keys are revealed. So, given this definition of PFS, SSHv2 does have PFS. It is hoped that all other key exchange mechanisms proposed and used in the future will also provide PFS. This property is not commuted to any of the applications or protocols using SSH as a transport however. The transport layer of SSH provides confidentiality for password authentication and other methods that rely on secret data. Of course, if the DH private parameters for the client and server are revealed then the session key is revealed, but these items can be thrown away after the key exchange completes. It's worth pointing out that these items should not be allowed to end up on swap space and that they should be erased from memory as soon as the key exchange completes. 11.3 Authentication Protocol The purpose of this protocol is to perform client user authentication. It assumes that this run over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. Several authentication methods with different security characteristics are allowed. It is up to the server's local policy to decide which methods (or combinations of methods) it is willing to accept for each user. Authentication is no stronger than the weakest combination allowed. The server may go into a "sleep" period after repeated unsuccessful authentication attempts to make key search more difficult for attackers. Care should be taken so that this doesn't become a self-denial of service vector. 11.3.1 Weak Transport If the transport layer does not provide confidentiality, authentication methods that rely on secret data SHOULD be disabled. If it does not provide strong integrity protection, requests to change authentication data (e.g. a password change) SHOULD be disabled to prevent an attacker from modifying the ciphertext without being noticed, or rendering the new authentication data unusable (denial of service). The assumption as stated above that the Authentication Protocol only run over a secure transport that has previously authenticated the server is very important to note. People deploying SSH are reminded of the consequences of man-in-the-middle attacks if the client does not have a very strong a priori association of the server with the host key of that server. Specifically for the case of the Authentication Protocol the client may form a session to a man-in-the-middle attack device and divulge user credentials such as their username and password. Even in the cases of authentication where no user credentials are divulged, an attacker may still gain information they shouldn't have by capturing key-strokes in much the same way that a honeypot works. 11.3.2 Debug messages Special care should be taken when designing debug messages. These messages may reveal surprising amounts of information about the host if not properly designed. Debug messages can be disabled (during user authentication phase) if high security is required. 11.3.3 Local security policy Implementer MUST ensure that the credentials provided validate the professed user and also MUST ensure that the local policy of the server permits the user the access requested. In particular, because of the flexible nature of the SSH connection protocol, it may not be possible to determine the local security policy, if any, that should apply at the time of authentication because the kind of service being requested is not clear at that instant. For example, local policy might allow a user to access files on the server, but not start an interactive shell. However, during the authentication protocol, it is not known whether the user will be accessing files or attempting to use an interactive shell, or even both. In any event, where local security policy for the server host exists, it MUST be applied and enforced correctly. Implementors are encouraged to provide a default local policy and make its parameters known to administrators and users. At the discretion of the implementors, this default policy may be along the lines of 'anything goes' where there are no restrictions placed upon users, or it may be along the lines of 'excessively restrictive' in which case the administrators will have to actively make changes to this policy to meet their needs. Alternatively, it may be some attempt at providing something practical and immediately useful to the administrators of the system so they don't have to put in much effort to get SSH working. Whatever choice is made MUST be applied and enforced as required above. 11.3.4 Public key authentication The use of public-key authentication assumes that the client host has not been compromised. This risk can be mitigated by the use of passphrases on private keys; however, this is not an enforceable policy. The use of smartcards, or other technology to make passphrases an enforceable policy is suggested. The server could require both password and public-key authentication, however, this requires the client to expose its password to the server (see section on password authentication below.) 11.3.5 Password authentication The password mechanism as specified in the authentication protocol assumes that the server has not been compromised. If the server has been compromised, using password authentication will reveal a valid username / password combination to the attacker, which may lead to further compromises. This vulnerability can be mitigated by using an alternative form of authentication. For example, public-key authentication makes no assumptions about security on the server. 11.3.6 Host based authentication Host based authentication assumes that the client has not been compromised. There are no mitigating strategies, other than to use host based authentication in combination with another authentication method. 11.4 Connection protocol 11.4.1 End point security End point security is assumed by the connection protocol. If the server has been compromised, any terminal sessions, port forwarding, or systems accessed on the host are compromised. There are no mitigating factors for this. If the client end point has been compromised, and the server fails to stop the attacker at the authentication protocol, all services exposed (either as subsystems or through forwarding) will be vulnerable to attack. Implementors SHOULD provide mechanisms for administrators to control which services are exposed to limit the vulnerability of other services. These controls might include controlling which machines and ports can be target in 'port-forwarding' operations, which users are allowed to use interactive shell facilities, or which users are allowed to use exposed subsystems. 11.4.2 Proxy forwarding The SSH connection protocol allows for proxy forwarding of other protocols such as SNMP, POP3, and HTTP. This may be a concern for network administrators who wish to control the access of certain applications by users located outside of their physical location. Essentially, the forwarding of these protocols may violate site specific security policies as they may be undetectably tunneled through a firewall. Implementors SHOULD provide an administrative mechanism to control the proxy forwarding functionality so that site specific security policies may be upheld. In addition, a reverse proxy forwarding functionality is available, which again can be used to bypass firewall controls. As indicated above, end-point security is assumed during proxy forwarding operations. Failure of end-point security will compromise all data passed over proxy forwarding. 11.4.3 X11 forwarding Another form of proxy forwarding provided by the ssh connection protocol is the forwarding of the X11 protocol. If end-point security has been compromised, X11 forwarding may allow attacks against the X11 server. Users and administrators should, as a matter of course, use appropriate X11 security mechanisms to prevent unauthorized use of the X11 server. Implementors, administrators and users who wish to further explore the security mechanisms of X11 are invited to read [SCHEIFLER] and analyze previously reported problems with the interactions between SSH forwarding and X11 in CERT vulnerabilities VU#363181 and VU#118892 [CERT]. X11 display forwarding with SSH, by itself, is not sufficient to correct well known problems with X11 security [VENEMA]. However, X11 display forwarding in SSHv2 (or other, secure protocols), combined with actual and pseudo-displays which accept connections only over local IPC mechanisms authorized by permissions or ACLs, does correct many X11 security problems as long as the "none" MAC is not used. It is RECOMMENDED that X11 display implementations default to allowing display opens only over local IPC. It is RECOMMENDED that SSHv2 server implementations that support X11 forwarding default to allowing display opens only over local IPC. On single-user systems it might be reasonable to default to allowing local display opens over TCP/IP. Implementors of the X11 forwarding protocol SHOULD implement the magic cookie access checking spoofing mechanism as described in [ssh-connect] as an additional mechanism to prevent unauthorized use of the proxy. References from this section: [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996. [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996. [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2246] Diercks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998 [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley and Sons Publisher, 1996 [KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner, Prentice Hall Publisher, 1995 [FIPS-197] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)" FIPS 197. November 26, 2001. [ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom Glossary 2000", American National Standards Institute, Inc., Approved February 28, 2001. [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, Feburary 1992. [CERT] The CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 U.S.A. ( http://www.cert.org/nav/index_red.html ) [VENEMA] Wietse Venema, "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose, CA, July 1996. http://www.usenix.org/publications/library/proceedings/sec96/venema.html From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 21 17:07:47 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08955 for ; Wed, 21 May 2003 17:07:46 -0400 (EDT) Received: (qmail 27389 invoked by uid 605); 21 May 2003 21:07:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27301 invoked from network); 21 May 2003 21:07:42 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 21 May 2003 21:07:42 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4LL7eNS020731 for ; Wed, 21 May 2003 14:07:41 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA22547 for ; Wed, 21 May 2003 14:07:40 -0700 (PDT) Date: Wed, 21 May 2003 14:07:40 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: "diffs" for Section 11 on Security Considerations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, As promised: http://www.employees.org/~lonvick/newssh7.html Thanks, Chris On Wed, 21 May 2003, Chris Lonvick wrote: > Hi Folks, > > Below is the latest version of the Security Considerations section. This > reflects all of the discussions on the lists on the various parts of this > over the past few weeks. I appreciate all of the feedback and help. > > I've also put together an html document of the changes from the previous > version; red strike outs for deletions and green text for insertions. > I'll put it on a web server and send around a pointer rsn. [The server > isn't doing so well today but I think it will be fixed in the next day > or so.] If you'd like to see that sooner rather than later, please email > me directly and I'll send it to you. > > If you would like to suggest any changes, please call out the relevent > section in the Subject line of your email. Also, please remove the > non-related sections from your reply as this thing is getting a bit long. > > Thanks, > Chris > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 21 23:19:49 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA16830 for ; Wed, 21 May 2003 23:19:48 -0400 (EDT) Received: (qmail 10135 invoked by uid 605); 22 May 2003 03:19:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10128 invoked from network); 22 May 2003 03:19:46 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 22 May 2003 03:19:46 -0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4M3JhJV000546 for ; Wed, 21 May 2003 20:19:44 -0700 (PDT) Received: from jsaloweyw2k01 ([128.107.169.154]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 21 May 2003 20:22:56 -0700 From: "Joseph Salowey" To: Subject: URI for SSH Date: Wed, 21 May 2003 20:19:43 -0700 Message-ID: <000601c32010$fd2371f0$9aa96b80@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 22 May 2003 03:22:56.0813 (UTC) FILETIME=[705C35D0:01C32011] Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit It doesn't appear that a URI definition for SSH exisits. Do any vendors have support for invoking their SSH clients with a URI? Perhaps something like ssh://host:port@user ? I think this would be useful. If there is interest in this (escpecially vendors that would like to implement it) I could put together a draft if there wasn't a de-facto standard already. Thanks, Joe From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 22 01:19:54 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18940 for ; Thu, 22 May 2003 01:19:53 -0400 (EDT) Received: (qmail 3295 invoked by uid 605); 22 May 2003 05:19:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3288 invoked from network); 22 May 2003 05:19:45 -0000 Received: from smtp.iamx.com (HELO mail.iamx.com) (166.84.156.6) by mail.netbsd.org with SMTP; 22 May 2003 05:19:45 -0000 Received: from columbia.edu (iam-66.iamx.com [166.84.156.66]) by mail.iamx.com (8.12.1/8.12.1) with ESMTP id h4M5LDOU029441 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 22 May 2003 01:21:15 -0400 Message-ID: <3ECC5DE4.7080207@columbia.edu> Date: Thu, 22 May 2003 01:19:32 -0400 From: Jeffrey Altman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joseph Salowey CC: ietf-ssh@netbsd.org Subject: Re: URI for SSH References: <000601c32010$fd2371f0$9aa96b80@amer.cisco.com> In-Reply-To: <000601c32010$fd2371f0$9aa96b80@amer.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080507030608050703020900" Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a cryptographically signed message in MIME format. --------------ms080507030608050703020900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kermit 95 implements ssh://user:passphrase@host:port which is modeled on the equivalent URI for FTP. Joseph Salowey wrote: >It doesn't appear that a URI definition for SSH exisits. > >Do any vendors have support for invoking their SSH clients with a URI? > >Perhaps something like ssh://host:port@user ? > >I think this would be useful. If there is interest in this (escpecially >vendors that would like to implement it) I could put together a draft if >there wasn't a de-facto standard already. > >Thanks, > >Joe > > > > > --------------ms080507030608050703020900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKtDCC A4IwggJqAgIArjANBgkqhkiG9w0BAQQFADBWMQswCQYDVQQGEwJVUzERMA8GA1UECBMITmV3 IFlvcmsxNDAyBgNVBAoTK0NvbHVtYmlhIFVuaXZlcnNpdHkgaW4gdGhlIENpdHkgb2YgTmV3 IFlvcmswHhcNMDMwNDE0MTMzMDQ1WhcNMDQwNDEzMTMzMDQ1WjCBtjELMAkGA1UEBhMCVVMx ETAPBgNVBAgTCE5ldyBZb3JrMRYwFAYDVQQHEw1OZXcgWW9yayBDaXR5MRwwGgYDVQQKExND b2x1bWJpYSBVbml2ZXJzaXR5MRswGQYDVQQLExJUaGUgS2VybWl0IFByb2plY3QxHDAaBgNV BAMTE0plZmZyZXkgRXJpYyBBbHRtYW4xIzAhBgkqhkiG9w0BCQEWFGphbHRtYW5AY29sdW1i aWEuZWR1MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3BqDkjprtbUObzZi0+Ot q4+8AZD9Mq+LMM/0YuroyVd/AKr0VqA0W2zs1ntLCVXJ+D1WcCU5unLWwSrXislCPcHB9dhK MjoUICqVYU2YH/4YtqlQl8EpYMlAv7s6aK1Zk1Sx3WrwuSuc112+dIeubzDfiGwwMbKxuySl Q4F+YTTEVd+VQjb08hkbf+W5aXqFQHdrVz/0LQ0jYwud6a3TWEtPSyW9AVQNn7dHozVcxVqW 9VA0f8tOM3xmCyX+6Fs6660rITBm7Zh6POEUNWw7qI7f1WiCojMpiLafRdwlK4xaaW855DSU ZcUtjWecZvpWzwQLywD4lZuKFjIuINfPjQIDAQABMA0GCSqGSIb3DQEBBAUAA4IBAQCPFBeK geiYWaMtIPgQB4lOcaGywbkI3NzfBibtD1oOm2dg/t8aUsQOkN+gccnR6vHOrHf7TCTa+8bn HrhQwKiMz6cDxvWxktNDL2Jn9v/dcEaT2bIU1lgA9B7OddtLqUOq+DiBA/0VcLYfSNk9foza clYQvdL90nKaK+VLXieSpPIrRBZEXp4y6FfyeQQSpE8mgZfQDM7mnlpKNhjk54V1TbZlz3yI r/AexQLix2dWPSlFijHV3SNwUelDpnviBozlN758ZIM87eAZuGppOkwyLqRJ6hmxdxuVKuom sg0apswhKEuJ4NnygGnxrf5LJUKTzf1yb5f6pZYuz6r8Tuf6MIIDgjCCAmoCAgCuMA0GCSqG SIb3DQEBBAUAMFYxCzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcgWW9yazE0MDIGA1UEChMr Q29sdW1iaWEgVW5pdmVyc2l0eSBpbiB0aGUgQ2l0eSBvZiBOZXcgWW9yazAeFw0wMzA0MTQx MzMwNDVaFw0wNDA0MTMxMzMwNDVaMIG2MQswCQYDVQQGEwJVUzERMA8GA1UECBMITmV3IFlv cmsxFjAUBgNVBAcTDU5ldyBZb3JrIENpdHkxHDAaBgNVBAoTE0NvbHVtYmlhIFVuaXZlcnNp dHkxGzAZBgNVBAsTElRoZSBLZXJtaXQgUHJvamVjdDEcMBoGA1UEAxMTSmVmZnJleSBFcmlj IEFsdG1hbjEjMCEGCSqGSIb3DQEJARYUamFsdG1hbkBjb2x1bWJpYS5lZHUwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcGoOSOmu1tQ5vNmLT462rj7wBkP0yr4swz/Ri6ujJ V38AqvRWoDRbbOzWe0sJVcn4PVZwJTm6ctbBKteKyUI9wcH12EoyOhQgKpVhTZgf/hi2qVCX wSlgyUC/uzporVmTVLHdavC5K5zXXb50h65vMN+IbDAxsrG7JKVDgX5hNMRV35VCNvTyGRt/ 5blpeoVAd2tXP/QtDSNjC53prdNYS09LJb0BVA2ft0ejNVzFWpb1UDR/y04zfGYLJf7oWzrr rSshMGbtmHo84RQ1bDuojt/VaIKiMymItp9F3CUrjFppbznkNJRlxS2NZ5xm+lbPBAvLAPiV m4oWMi4g18+NAgMBAAEwDQYJKoZIhvcNAQEEBQADggEBAI8UF4qB6JhZoy0g+BAHiU5xobLB uQjc3N8GJu0PWg6bZ2D+3xpSxA6Q36BxydHq8c6sd/tMJNr7xuceuFDAqIzPpwPG9bGS00Mv Ymf2/91wRpPZshTWWAD0Hs5120upQ6r4OIED/RVwth9I2T1+jNpyVhC90v3Scpor5UteJ5Kk 8itEFkRenjLoV/J5BBKkTyaBl9AMzuaeWko2GOTnhXVNtmXPfIiv8B7FAuLHZ1Y9KUWKMdXd I3BR6UOme+IGjOU3vnxkgzzt4Bm4amk6TDIupEnqGbF3G5Uq6iayDRqmzCEoS4ng2fKAafGt /kslQpPN/XJvl/qlli7PqvxO5/owggOkMIICjKADAgECAgUEYAAADTANBgkqhkiG9w0BAQQF ADB0MQswCQYDVQQGEwJVUzE6MDgGA1UEChMxQ1JFTi9Db3JwIGZvciBSZXNlYXJjaCBhbmQg RWR1Y2F0aW9uYWwgTmV0d29ya2luZzEpMCcGA1UECxMgRWR1Y2F0aW9uIGFuZCBSZXNlYXJj aCBDbGllbnQgQ0EwHhcNMDIwMjEzMjIzNDI5WhcNMDcwMjEyMjIzNDI5WjBWMQswCQYDVQQG EwJVUzERMA8GA1UECBMITmV3IFlvcmsxNDAyBgNVBAoTK0NvbHVtYmlhIFVuaXZlcnNpdHkg aW4gdGhlIENpdHkgb2YgTmV3IFlvcmswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDQC7w6HbOh9Kn2ud3R0u/Lp0TBaNCFJ5PHY6SvGKzpc/y0+rV3N6SL7V1RAHLFgcVdUCkl XPanjqKdYqjMJsRx3U/kFFkvW+iCIsSUjR23IldzUpo+30hUCBTLW4EqMNjBKQZRCNjs9QlW GBWE0y9Chhms6lHZJegG6YULe+EKqU2bEa7Zq2xuRj9EpstkbpUsM5wb7zCFmw28Cly8VgOC 8yIU01sIj+91vYsujH+CLgVLUG0D8kr4sbXr+Uk8/d05LpM+iKbRMOEUQPEYHJw/mwXF81/c DCXZnaH3B8ZhFjR0tbk4JecCDfuZ0jnf8HC13PpUHc46RGx5BNK3fUQ/AgMBAAGjWzBZMAwG A1UdEwQFMAMBAf8wHQYDVR0OBBYEFLHbwnjjGeFj8sj00g//ulw1DII0MB0GA1UdIwQWBBSZ XFkzrbStei+68QrYZGLNXx9BeTALBgNVHQ8EBAMCAAYwDQYJKoZIhvcNAQEEBQADggEBAI2U gdjA0FQNBDrGe+6MPDaOpPxY+UeT1/ZAmP7QovRDUC8csGZblO0OBq+XlFaxm0ABgqnu+MkE 9cKikfNH1c61zE9PYD5Kj67u359KhfQPHEoBOxO2t6gAg9AS1Y9nuUK+i90W9x8irA9U6Gar 4rmaLTIl1p+lWjdmLsGd+kywTb3u5zU+BgC0bsMQkwAr2nBjnN0woi23y7LNXkiAWrj9f4VP VLgJBshItbUC6AdNbFhYrKSeA8vaYdMX1z7ZwKs/1IxKNQoV/Du/InzvJgwbN5XCckdQ5G5F /QPbf7nSviQmhDMHNn8ty4uBk9Ss5rpftGrOFx0V/EaNpmn8yRQxggMUMIIDEAIBATBcMFYx CzAJBgNVBAYTAlVTMREwDwYDVQQIEwhOZXcgWW9yazE0MDIGA1UEChMrQ29sdW1iaWEgVW5p dmVyc2l0eSBpbiB0aGUgQ2l0eSBvZiBOZXcgWW9yawICAK4wCQYFKw4DAhoFAKCCAY0wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDMwNTIyMDUxOTMyWjAj BgkqhkiG9w0BCQQxFgQUrTXpQRlj6adxAJgCXQpAlamltA4wUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwawYJKwYBBAGCNxAEMV4wXDBWMQswCQYDVQQGEwJVUzERMA8GA1UECBMI TmV3IFlvcmsxNDAyBgNVBAoTK0NvbHVtYmlhIFVuaXZlcnNpdHkgaW4gdGhlIENpdHkgb2Yg TmV3IFlvcmsCAgCuMG0GCyqGSIb3DQEJEAILMV6gXDBWMQswCQYDVQQGEwJVUzERMA8GA1UE CBMITmV3IFlvcmsxNDAyBgNVBAoTK0NvbHVtYmlhIFVuaXZlcnNpdHkgaW4gdGhlIENpdHkg b2YgTmV3IFlvcmsCAgCuMA0GCSqGSIb3DQEBAQUABIIBAHBa0UOLExHi8JOpem66mWxfBP5E Po+vutGYHHBin7nEblLa+V7ycPwhKSkXCSsaxz1+J9ZOVcY8rF9aVU0kWt79C2jZZocU11xz waYIbZipMvcPCLY4ZVvUfq7cJq4OsFdxyIZIEOUCRZc5Qag0QJUGd2iPo10YLcZ2FQcMmQr3 DCLoY5AYLv64CBylcgnslyIph2QSvxzU1F5D4HsrLH11SUDKBt/1oe93kTkdTgEbtBLApQyd pqxeN2f3bTY49/6myiilRW8pAVd97zy6ElPGrfhKnN4z/CJqhelwv9vKUg3dOuvlrX6rMgbY 3DlSnAc0YA+pthV69Ff4j4mWbekAAAAAAAA= --------------ms080507030608050703020900-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu May 22 04:01:52 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04029 for ; Thu, 22 May 2003 04:01:52 -0400 (EDT) Received: (qmail 22401 invoked by uid 605); 22 May 2003 08:01:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22394 invoked from network); 22 May 2003 08:01:48 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 22 May 2003 08:01:48 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19Il12-0001lD-00; Thu, 22 May 2003 09:01:32 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <000601c32010$fd2371f0$9aa96b80@amer.cisco.com> Subject: Re: URI for SSH Message-Id: Date: Thu, 22 May 2003 09:01:32 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joseph Salowey wrote: > Perhaps something like ssh://host:port@user ? > > I think this would be useful. If there is interest in this (escpecially > vendors that would like to implement it) I could put together a draft if > there wasn't a de-facto standard already. There's interest! The PuTTY team _frequently_ receives requests to implement something like this, and we've been holding off on the grounds that we wouldn't want a standard to come out later that we were subtly incompatible with. We would certainly implement an SSH URI scheme if one were standardised, and we apparently have a great many users who would like this to happen. Cheers, Simon -- Simon Tatham "The voices in my head are trying to ignore me. But if I keep talking, I can drive them insane." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri May 23 09:37:01 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04657 for ; Fri, 23 May 2003 09:37:00 -0400 (EDT) Received: (qmail 15808 invoked by uid 605); 23 May 2003 13:36:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15168 invoked from network); 23 May 2003 13:35:44 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by mail.netbsd.org with SMTP; 23 May 2003 13:35:44 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h4NDZe9N021606 for ; Fri, 23 May 2003 06:35:40 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA27855 for ; Fri, 23 May 2003 06:35:40 -0700 (PDT) Date: Fri, 23 May 2003 06:35:40 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: PRNG in Section 11 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, I was reminded that I was going to remove the PRNG acronym from Section 11. Mea culpa, I had inadvertently left it in as the title for subsection 11.1. I've changed that in the "diffs" web page and will keep that as a mental note for the update, if any. I havn't received any other notes on the subject. Is it cooked and ready to come out of the oven? New "diffs" here: http://www.employees.org/~lonvick/newssh8.html Thanks, Chris From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue May 27 15:36:25 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27687 for ; Tue, 27 May 2003 15:36:21 -0400 (EDT) Received: (qmail 7979 invoked by uid 605); 27 May 2003 19:35:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7971 invoked from network); 27 May 2003 19:35:44 -0000 Received: from smtp2.tie.cl (200.54.144.169) by mail.netbsd.org with SMTP; 27 May 2003 19:35:44 -0000 Received: from JoseLuis (200.54.191.197) by smtp2.tie.cl (6.7.010) id 3EBC023C001F968A; Tue, 27 May 2003 15:32:10 -0400 Message-ID: <411-22003522719300385@JoseLuis> To: "Arriendo de Tecnologia 13" From: "Jose Luis de Leonardo" Subject: Arriendo tecnologico Date: Tue, 27 May 2003 15:30:00 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_01BC2B74.89D1CCC0" Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_01BC2B74.89D1CCC0 Content-type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =20 ------=_NextPart_000_01BC2B74.89D1CCC0 Content-Type: image/gif; name="Arriendo Tecnologico.gif" Content-Description: Arriendo Tecnologico.gif Content-Disposition: attachment; filename="Arriendo Tecnologico.gif" Content-Transfer-Encoding: base64 R0lGODlhHALQAncAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACwAAAAAHALQAoYAAAAR EREAADMAMwAAMzMAM2YAM5kAZmYAZpkAZswAmZkAmcwzAAAzADMzMwAzMzMiIiIzM2YzM5kzZgAz ZjMzZmYzZpkzZswzmWYzmZkzmcwzzMxMTERERERVVVVmAABmADNmMwBmMzNmM2ZmM5lmZjNmZmZ3 d3dmZplmZsxmmTNmmWZmmZlmmcxmzJlmzMyZAACZADOZMwCZMzOZM2aZM5mZZjOZZmaZZpmZZsyZ mTOZmWaAgIiIiIiZmZmZmcyZmf+ZzGaZzJmZzMyZzP+Z/5mZ/8yZ//+zs7uqqqq7u7u75u7MAADM ADPMMwDMMzPMM2bMZgDMZjPMZmbMZpnMmTPMmWbMmZnMmczMzDPMzGbMzJnMzMzd3d3MzP/M/5nM /8zM////MwD/MzP/M2b/ZgD/ZjP/Zmb/Zpn/mTP/mWb/mZn/mcz/zDP/zGb/zJn/zMz/zP///2b/ /5n//8zu7u7///8BAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMBAgMH/4B2goOEhYaHiImKi4yNjo+Q kZKTlJWWl5iZmpucnZ6foKGio6SlpqeoqaqrrK2ur7CxsrO0tba3uLm6u7y9vr/AwcLDxMXGx8jJ ysvMzc7P0NHS09TV1tfY2drb3N3e3+Dh4uPk5ebn6Onq6+zt7u/w8fLz9PX29/j5+vv8/f7/AAMK HEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3DgRjsc3cECKhMOxpElWH9eoVDPlzJkpZqSMkRLT DBSZU8bAfGLmDM0zVs6oUbnG48mjSB/BURlUis8nUqTwpEkTihmYVmH69Hm1a0unUmCK7TlFzVCQ SdOWpLP060yZTv+nkvFqM+ZWsFzH6u16hq7erULXoFVLuKFHlmegzjTzZKfPmXkh4+UJUwoZvE75 Zt67laxnsS8Dw6FTuHRAOGzUxJUac+aTxzu7WrUKVqddvHTvdtba8qpLp6D5avXqcihJ08jphfzK WvEUyotfS30cdat0n5f7cgb+WbcUNVfTvDQDvuxL8d+HB22pRqjR5PDTLfWZU6rrq9HxT4Gbly7m u9n9xx1gTmnnEkyqhSacSz2x1FMaoLE3WHwUegMHS1A9cd9rPEFlk2WsTZYYbHVVpp1mBqKo1Xc+ tbeZS+i1p1p5DobmFHhWkFVcURX2aM1SGY7RIVxTZZgYYzXVd1n/TDSNJSJuvAnnW09BTYlgWb4F Nd5LLh4oHnihnVGFS2Oyx6OPaC6zlFRDdshYfbQtGVZdWdn12og4objZX1P21ZR2NG6JZYtXlScU iy2VNYV4LuV43lbtTZjmpMCskdgTHXboGpFIyjWkTzjZtl9uUHZG4F2IkRVob+b5xmVoYCYIHpiN qnpgly2d8QalvOpyIabNZRqVTjPphBOIVeEHVleW+eXsVwrmmipMVSp4hnhVBjVrX+1BCFRxibLk bbeEfoujS2ec2eu6r7xxqX3wdngpY1IhGx112NWml6hSAsbXmJu11+i131bbXqEtrScUuATHeuir 316bqxlBjanG/3HsZnzKGmxqCKyG8XaaU2sgBtgVZc/2tFm/TjmqFY3h8dbXwFoebPOhN5tX88Lt OYpYzwwqeLHGRIfCMaYfM7Zhc1Lc9BZUl9HknGRc1ambbwXilWCLW7mMrrnfkuenueaZVzDPA48J VIMwPkqezluuUfTcmACJqZDFfiwkXDrxtJhVXF0HFlYxBYjn1acCprbZa8/ILYs/Fyc5uTIurLYV jFbO0uYLny3222CuQRrdpDuy5t0fI610sM196JqxxNZn23+kjgetmGTeqjLukkf8KNAQBqqteZrz DLfAAmvL8OaqlqXuRDxEL330okiPCfWFTH+I9tlzj4z1vcBhBf8USEeB6eptytRYsfW+eTJXAhpe qpRba8U78blj2XPyaMtYPNAA7N/Cgoc7ygklV9rqCVCMIxAkOPCBEIzgA6dHQQla8IIYnGD0MshB B0ovghTkAQgrqEESdvCEKEwhB0VYQhW68IUX5AIcuHCFnGBKDKjDVBT25jF6sc8q0ilWZYgVl/7s ZncvctWVvNU2avUPf906HnuOJ0DlWbGK31qUUMR2QIEFhgtcgKEYx0hGF3ICCSFMoxrXyMY2uvGN cIyjHOdIxzra8Y54VKMPuBDCPR7tCU7I0JCEpJgMMc1NzXlKiZjlncMNqDfZEpu0KPYqgWnRbAT8 n1A0OTxNFk//eZys1cOCoq0rcMEH0ztlHlfJyjqekQcciKUsZ0lL6dXSlrTMpS53KUtc8vKXFJyl L3E5zOjFspiw/KUyl8nMZvbSmM6MpjR3WQIT0NIENUQaIT2GKScEq1Oue85VUOahytQkTk7hV3DE 4i1XZQZ3COIW1zxJPCj2T1v+898Cu4g2UAowgGCq2RWsGUsTlIADSiDoNBfK0Ibu8pUccAT4CDFR O1DQEBelqPUqmtFEhFCjPBgE+CZaUZAqgnsk7ahFqTdSlbY0pIL46EphGlOVrgIOz+km0soALLyp 7nxA7RRcLvOauqzPRAJKEasYlEC4Ga89+Osk2PRphf2VhXNm/yGbWYiXz6suTKpShapYJ/c8bSAB ohLFnklr6tI0slWmM/UeRlmq1pmKFHsppWn39LrXjeLVrW/9K1zXGFiY5tWmqFgD0nDIzbsFsl6v Y9qmsjMVejXJTo1c2W4kdiItqU08LcncP/uHVX1m1SyaQy3P/GfP09JTRmyLkZm6cdZNoDGijSip XXe727z2FqVq1W1M76pX3/JWuMJ9a2CPG1zjMlewxF2rc1HxBqRZ15tPEEO9eghUeAExNqzJiVaC iFQzZIc4BVJber9GyalKUUZcXa25TFu5qqoBDTJaw2nxucnNwTeroBSbVDEJK4xho7aauG1u6xrd lUqXwWxtsP+DJYwIub7UsILla1w9Wle5NtjDe1VuhEfM27lqmBQ51WkgrYs6NtELZIOEi3jphST+ JBUvm2WR2s5jNoFl8olUFQp/AdwzS1lBv0MRsn51ZqkkD8Wr/pUvVkfLOQiZoazUQHAmFMwI5NJV jYWl8IXhWmEIg7mwDAYxhUscV+huL6McbS5NdUtmUihWp9q0jzd56BruEikxIPqbVzDTFds0kneu 4hqjeKe2/4rNtFfNb2CAYin9bnJha4ByuobC2tM2eb+Xrmo/LXfALT7VwFlGa5fN7NcztxnDxc1w nU38Zg/XWc1rHjNw+UrYEjv3sIgNRYpXDEg8sxhem3INoKP/sxrqXGZJdeKToArFtfRodZNR7WJq 04VPKOtTv1dALZKR/G2zIFko4d60kEnb2oZlMWhquIaWMcHlRdDZzSfVXpxhLYnkkjjExD3xWqO7 azG/1OD8/vDBS3E0YgOSkEISKt7YRKT6dGjGcrnsjU0FFgfVCFHIY1vktr0/106a0/oF91BETVX8 WsHl+hV1pjnd6U8T+dJYPR55NsceVENj3peod755vXCAR/iw/05rrOeMb6Tbu8OtlvC+pS5nhJPY 35ugwxWuW2ykYbfYQjIfsgs5VKpQRjqMceQRtxIcQUGVYGMb+Vexrdr2pDvdZrHvVPO78pSjluaV /jtLLG1p/3MDBb+a0/T/QgujlshtGkC3hNDLzMaAH923BRcx1jescKYnnPNPl/Vv8T3izF+96qXf fN2m0IRAOrzr2xTkxHvKt+eESpwgQqpt5DftppCLkojx55faTd/+ruHl90W58gv/6cCna5OZDjxq w+3k/m6a5ev+byUhFjyfMyPylZh8rV2N5oB7j/yAHbqJS0rmXo8fzmdmf/yh7vkvmx/XmoADnpvg dY9JxQl50ybswxM3oRhS0yS2AR17MRa7IR4K5ButskX8E0D4pC1HRmmUlnz9pQb2lWRVBXPmpgbU d2RmEW7kJmlNtkDHl3wc+Hx1l31U1mOP9wzgRwnit37B1v9mfZVm9gdSEFZr4xeEPoh/yoV0RWd5 R7hvIaWEbJZ1z0Fsrtd1r6dDhPRifYYk4hVEVHEX/nEiSwWB45IlESMupEVfiOdpeZdym4ZfK+h3 KFdVgTduIahyMad80FdaakAFpgVklPQ56zEUo9MMNTgJN/gPqlcNOPUE/KeIU7hY6qM+qQNjy8Yp eQJE+fIYttMdj2QosUIlowZAPYN4h8dpQiGKgGcWiBdzckhucshpU+CGbmiHc5hPV5B9+yNAPdYT WIYMgygJhWgPUwcO+heFKxaF2cViXcc3nCIvUFEfgLZIGwclX9KHr2I2/rSHW/V3GwiHcCiCJTiL fheHQ3H/fHTojXKoh8lXi2ahh/qFeM5DctdIRTmiKOThfcbQi5Hwi/VQed+wdfznBE0wA11nbIxV hTDmf5sCNcqIJ/xBXigCGOsUNrMCRfKIhtymhk1GeCHIhtwYjiRIfX7HhiEIksp3ii1Ic0rWHoWH c2jzJZ2DGLuyDPgICfq4j7OmDXTwhDNQjIvYiFJhPjwUYyDDPnEBXlzIgFCyO9Q2KJHjkqD0bWeA d65Fgqe4iiUZjsv3hljphiZ4laRojkKWX6LWbQAUWj32ioF4DDP5CDVZOvmHNK2niCrmdUJCbEH5 OgZIgG+SH3FRFyDSSKDBIlWiRWuzMFOkOWTpWpbSlanI/4GqaI4kiJVduZVZ6XeTaW7c2JiFl1Ux d09UNjNj0iD2GAxr6Qht6ZaXoH9PIANxWWwO53ABCGOPCDJAFCJ9ky+MVESaFSVaoSWEOWT/xIKv SGSoGIKbRpmWOY4ol3LkSI7LWZmcFm6aCYeBkXwaqY2QVpb8Uxaj+Qul2QiniZqUoH8zwASYspNN IAOY0pNc13Xm439CaVTPWE4NyRVX05sKVCOSJCM3wlVQFhTnlpWQiZzLF44pF5kG6pxrYIIECouO +aCRNop6GGqjVSVe1J298J2MEJ7iGQlbZ56A1Jpz2U2ENHZ46UNM8yGLhDJIpRuBmTv9+TPUVl84 p46cef+BTkaSB7qVR2aZKecGKvEGQwGkgvGczNl35viGnCaSp3iGf/eU/LQzvucUMUkMGroIHNqh jnAFccmaq6lTIGpsgRR7QUJxQgInPhQb0gFttdMngFGY8kSjxYdaTMppkemVybkSeqpfb8AUzHkF KRdufUqkfaqce5qVXcmCZyidGnhfLGdPwcM23zKDwnClipClRlcLF3WIzjBdmQoJPNADWGAF5lme xcZ/YWqMLAaUrJM3y7gsLJokfHEdDXhJmaMoUyYjnYR4LidpVdl3PqqcfWoFg+qnQFqsx3oWIkiH QGqo0SmgXQmSm2RfVMmSxdNFCEIllAoMlpoImDpwtPD/UZzaDJ4KrpCwR1bwBDPQmukphciIQwDY WGMqLBtiVGkXFjNBWZnFdhCoQPPIKLe6h+Smd3R4p0m6lXx6pEShBn26sA4rpAvbpxC7oM1aqA5L oCuHci6IcxFKSmBTalqyrb7QrYjwrUk3C8GIDSn7qY+wR89hnqypnoEUkDNLjNZFcdqVkD/0JlOR FfKicfa5mwD7LQUyVomXT6NYp3eooMoHqD/KFMX6BsS6EkL6BldQtURRpA07jlswjgs6FF27owLa jl8pbnlonNe4RRb6OENRqarWbz8IC+M6DeM6t4TABc9Bs/8ol8WIjCwWryzGQ8uoLDVGImuKFxHJ HZVD/5GImS6Rhlp3uhLQqacM+7V7mrWVKxhZG6RroAUPuwaEyrCVO45EGp0Fy4qQaX1z+pJkcyBX Rppvu2o9uFyhx4MgtnCApYT0d3rtl4Nsllw21bue54O+FrzW8xzqyQQ7+QQxEEheOpcrhkNBCU6F hKIGmBVEdJ8oMiXTUkCe+JT5lGTOh6QHO449eqwpJ7GaC6TouwZhi7Xvy7lbwJwTG7HMWbrISZX4 dZzcBmqc40/hQTDOw62xO3SDdZP3J2vy51a5K2cd1WuuRn7gCrwNfMDDi2YOfH7S4wP+6ATNi6qY AqKut4jI+J59hjSzuZdZ2BqjQjjbYSDthD+w8mhPtf+xkKuGk8ucPSqCFiu6RDG/oMu5Dau+mou1 RJysFtu5UGug0Elzeueon8axRsslXSGyuUCyh3CaY8a7lEdwF0a8z/VgF8x5XvZ5FLx0QHh5Y2xc WxzGu/UcMODBgLSTy9tNJGyzOTSmfGOAZGCAUkO4tBEZf4G4bwNajzZlLJd333i2mImwH4m1o1vE C0rEQxykVyvEZ0EUfXoF6AuoDQvECtvD5diVFxiLOHeNktQ5pValu4DFhqDFqDdhJzvLKavBn9eE nTfGa2auVCdwh1h0vxa3o2cHa7CTMYApMPAE5gnCyeya72pdL2ZIgss+RDRjuqm9EhklYlW0USUj +8v/guL4rEysEkRKznrasEh8yZU8xJfsvkHcsOYcxKIbtUkKqGMbgir5jpqGfdoSI07hLax8xQWc xqknwbRsu1ZXvBomUyuLywh8hLy8g2ZMevembz5QB8Rcnq2XzIG0vOrZfyBdojjEJhEHYyJDgFQh J0tCOPvKvWWzLaeFc06KuoDHtEGqrETRyerLsJ4syeprxD4d1JS8uelrzs4KbpvGyIbnZEfbOWc5 M1MQ0LfgyoXQlsHIjyz7u7E8zL3M0LubawZd0F38fqaXhBmsbz3gA2xQnsYMSMesvCBqnismoqoK cYIUL7IzLM54HWiHlAwCSWEiWiNHPKKmjsgXmVTJ/8RX67VECsTo+9NCrbnzC9lDPdkqAcTIqrkK 26CNfMpGFtO3CDQC1hMYCgtUTQhW/dWcWsZGd9WqDcxfrdWkN1e4fNBNh3qu7WY84ANw4KXKC5Do 2XVhKtfGBp/YpT4SJ2OLga9U0aJJdUkPEhp/SHemdYatOM4q4bnM2bVDnMmC0dOU7c7hTdnhnblA bM9SO6yFaoKRm9iLLGX2pDZvcyql7QqnPQipXX+zTNAOtrLBjMZuHOAVvcsaVdvFK+C47cBcbAdp ra5w/QQc3a6m6tF+C2OP5VN4GWit4zRzYol/+SKnghhaBNPsdoIZqZIjWaCVW86aPd6R7eI/Dd5C rP+5lUvEmTukDuuV6uaG36x9xjNAXVTfrHDfgpDfEz3bvUzG02XWF2x6XA1wROi7YfzFCH7bsAZT SQAFABmz/BfhAHmq0OvMjbVdg2QkUHEkhJNUzuJxkDIw/zt3qmXYSMbeBqrdLK614K3OPq3OEvsG fb4UW+DngjHZgt7nQV2knEu1OW7Tz7pyXaR32MdzAmwtUmDFskDkdgDLwhvlFtxWAF7L8/fpFYzA ImbAugbbS/fAZzYFHvzgrOkE6/rRXhpIYYqM2yQF0pspL4aibyFoH+4XJ2I7WzQowdlk1l2cCGuo Wpu5QP3iEmvZEssG6rsUbyDtkW3Z0I7oWEvOgIr/v4ht3cankp/JPOfSaLiA6eEZdUMou7a7wGI8 weqe26o+u0JYu6n+5O7OhNHTA3YAxxD+7+0a18Vts3UZJB/zTRyiorOhLJGhveYBOTfSKIhcX3Ra nJGLchArpE7bzuQtyYFeFCAfEiHBBoHepyHR5yZv6Nke432K2cc3sc1KuZQpvv7Dcp3ERYgRNGJh 6a+A7rDUEHYbC8XMBM37wasZl83r4Mg8kCCtIe+pPhB3SCTzx2IxO0fUG4mzHoJdTxtpXyS5nDvM oJAssTLu09WO8kV89tKe8tK+9iEvGDDe4t49sd2OlaTI3kpWiib3vw2SHueiK7bg87ilEER4C3AQ /+utl56Kf/S0XtytuWKx12dSr5AckhhVf1kLaCAswiIipz84l1rgrJWki8kzvueFbvJwvxSqf/Z+ LhJr7+eB/voSS+2GHvfMvpzOac/Uh89nCDZpqyUG0jVCfgqCT/iFbwt1EMJs7eqtF+uYop5x2bc3 C4D/N3vJPSQkIyqSMRcrwjsswiUt0Wj8dKNP1oqXmb7LScQrn/Yk7+fW3vpwDxIg7+dcoPZ+rvpX EBJFkfKHTvaca8+AsPa2pvamtkZIeHhIeKaopkYFqXYGWXlpdVZplqlmNuWpaTdKWmp6ipqqmoq0 6oqKxMPxSltre4ubq1vL08uzCxxMOhUj02Rs/P+UbOz09MT01NT8NO38JEZtbW32JPU05uw9NvX0 +XT2NDX+yX0m5Q7//n7GfjZlFkqJeakGWkk56RCoRIsQqbnCaJAhQYUEOVQ4CI6giBO5vGHzBg6c KxLhvMkoCKNHjB8/ThQk8Q1HhScVNmy40IpBggTVyIQ0pREkNDb3UcJnj9KUTUPfqRGG1FSrpKNi zWIKNarUqVSrkoID41kMJjOgZeUK7UlWZc6mSctmDRw4bs7ASRnz1hu3uVLa1e0Wj4w8ekUr3esX 9K8/gP/WDFTDUxHNgg3XaEl0ZdCVhw8vqvxI8mNHkJo1r/EIuqRlNqA/KyTZMjJll4hYL1y8GJL/ In4A/VkBiu8TX09T4FjNtZSp09/Eixs/zhTrsWPPuoql1nUGtSbTpVcr6ywK9m7c2cbtpvdcOSlQ 2J2rG8+emfTq8/E70wngJPg7D91cIxP/oEODVvuHCJJHn5mGWUYBGjgSZqF5ZNkWlpmU0n9rqCbI FW4YFNlBhyBEEHyNXOHXIp28JxRgmaQxlG5m+IbcKsElNVyLMs5II3LOwLBcVlnF4EQTzj2jDHXN TDNkWuHA9U05R8pV3nhwqfNOOffs9Q47KcJ3RhqaZGIbbTlhSZMVsjE2U38XrnEmSxCx4SAbLS1I 4IJvWCRngpbZyYVpKG2BmpqtIQLofn8WdN+Y/2O+J6ZPmvCmCYpZDlXjKS8iFWOkll6KKS7E6Lic Ezw+10xWMxAZzXamgtOWdkoiyY036NwjpV3opFflPaCs986tPxEmX32dwFbQmTf15ydEkUVUIBxb oLRSaaGJhGC0dHaWUoEQSWiIS/3VBOwalXiLkyI8hXhJFX4Rpck8UqyR6aTCVJppvPLKi1WPOjbX aQzPASmNvtNZM80YpHrTjVtKNmmGXOfB5Y6VZpQHzz3p2tPoUFh2AkqXAelEKCL5wRToZMWGZJKB ptUZ7bMG5okytJvdiZIgy7K0rEOEZNvahoTaJ9Aj9PHKz3qOwoePrSti6m4w8M7LdNMyPhEDDP+e guUcV0B6SipaRWrz1qpKFlywwuYkXB6UetVDJdGbZLIJ0JbUh5hAOi+2n6CP+Tnzg8im5GzKCIIG eEYqoyygRaeVLGHNExKyBZmMLWKJYW9jXKI/j673FzxIR7W0055/PhUVTBiDI+nP3cvME9H1iNZ2 2LRuTdffxQVFXGeXt9d57KlLMScUsz2ifJWIaSghHDJyUKAGFRvhg2z63TcXGglO/fSBW4/gyQdC 2JJDZ16YLSOJxMYTJY/o9A+JW2pya1/rXpo0MJ2DTn/9ulzBRAw87t8jMmd9yiPqoOUs2qgGW8rw ta89bC5Sios7pHA2oxktHpSQglCydAktUYL/eCBaRGLGRJOFDAJ82JpIaO6EwgVhz3rXWyH1XMYZ k+UJcSOzGSIupIbGGW8Rx0MIP0DBq/Z54jboCoXE3mCp+O1ifvZrohNVATUZ5G9q0YEG/6BGKuaQ ygmoMlLskARGb0BJSnBZhzxwBY80ptGCQNEYifoxiUzscHwaGh+HikWRmcUpe9cTXAur50eNoOxv MTMQFkCixzXMjD+NmQmwAIIfxQBxMOcqYsS0BKlIKVEXTHyiJ584BRyVrgn3AguQPoU1ApoKO2NQ VdeS9J1WwQWCcbEVXPQyq1qxg4hsCwoG3fYtD0IONquBichWs7cDqfBvgGMhHKQnyBVuQZAG/yIN ZxjUvGv5iUL6QV4ibsKYN6qvNliqh8Tkwa4abRI4svikO90Jhxksx3T3Qh2+pjGqswgJdkkKG3e+ QZ63QAkuC4yVBB2WoiuZizclGl4lfBgfHoLQCgspCLEcokeLiEQQh1QmM/tITTp4hA5/82NGpgma aUaLJAkakJ8e0pi6FYog4MTPIUK0wUpYcBNYIlo/6sGiGa0TF518p1GbBjUY5G+U91pOc7LxqbDw s3XNEJgzuMEqJbmKPAlbx8IOqh57OMpiO/2h8ECYk4k68kKJxCOAtKdCj0gvkBoRKRzsGs27agSa gQQkaJo1kZJ0jyWDMt5MJOoISNIGmBf86f8ZzJVGFHFCnZxr51Ev+zn8baUYORJLv/rXHK6wbjtF Cph2kMQdJMlOSQnTKjrOOCW+1IOI9FBDWXPqtg7+I27AmgwdRwYzwpWUmiM1qV7fgNfj4tWvg8SI cwukGjXJRFvefBwhiEeItGIJt2rTB+9ydQYkCrWyT8GseecVtRxNkX/8Y05YnJBPGUTjOtrQRhlT yyRuQGmBUEIHO8qGxlo9VhMXA4p8gFiY+4iJJmhiCM2Q2ScBJQhwKKVecuuaV7tWj7h5RZn2BtEm GlJIUGWqo30a4S1vBc9tZb2N5SArYBoN9RZFPa+NkXMFUaaXnqd7qtWyQkD6NgMbXAToddj/4h0l kaOrsF1HeiQGZXf85Fxw/NZA0jcJgnBofIkgrJoUwreUtTCadsWrSM2s1zNjmKRxPVlKT9YSP6WJ IctynCIQsrH5JGpEGCSKihKasHS2aMa2qPGND20V5cBAR+yFhimdkzqyBFmVsQtYXNyC6UvXpXbu MGPDJigPSixUPWx7G22GB5tCvWG6IMOoQzZSGpXCkMNstl6ZydzhaM4h18uccAwx4lLKKLIgdOSW bM6g20i4zR8ZW9Sjnq0bKdBBRoSuhaERje2ohDK9nKKnc77yIyCbpRpZg2V9kayk1/pXyQnDJS13 N7Gd1ga38QGXlYnJ5QmBDEAQIVwzcX1h/zWneeAXHmkzoYcSvflHQjn8pvESm+W3zfs9a9MNreBx lEGTN9scJ46iSbkVHVGNK8uJL3ZGBbD6fqMamV5S7fzpMN3V5Zzw+LM+ML6e3Cb4fIzB2d3w+NyO wPWZ1du1XgV5Zi7cGs0YTjNy8+rXaOlphiCmTHUdaV0rlA8UPIkPJnw3tAHPA23uCKpxqk2La3d8 7bmAwqKjtl6mPgcazJBn/6RBnWRko0ji8Iaq7qtpJHV6qwt89158h/gB53REXreJfMIEqPz8CZmr webQ6QoagR8dzWq+da6NLtcV7rGQrq561XH4yMcdmDBUfrZOB8wejUNF7Wyv/SvYAIOQH/9js1T0 ytztrrotrrKAbQHokbqDMPDc5dPsEPBepGwxIvIqcubz4IKDdcMG32xCLDGcr3vddM8P/K5xEGkd 4HB+OJQ//Jvn8EqriSxtChv1G3rNTH8ILnsH7/VDCbutZNsbyIF2r0B7tmeAqBBKSwV3nFVPv0d3 /fJU+7R34FBkqEUwSAYFqqVf7SYP54FLDpNGkCVWzsZdcCRxdkZsJWQZprEsdQJSnFdX52d+elUH ndd0R5d50RR1KkUywOZlykN/NYFnx+N420UYkEUJmEQPRKRLUiaAG3eAUXgLWJB7uZc/YLEVXdFe JqdF2NEMEqhybdF3xqcwr8UqApUwFwf/XhY3ahkTRMcWScp2YiemEoWQPHhkQglHYSzkeQJHB+UX B+QnUnbgG4K4fpp3a2I2J9kjdTTkYNo3E8eDYvMRN1hGLlgyFIzyCbyBUOJVHAPoCgUohQfoWUoV cju2Xr5HcvIFDZ8lQEJGDW/hBN4QMGFTRnLRX+mQhufBX2jEDraVLvmwHvtnaooBQolwJtkXXS5V LZsxZhkRcBohg4IoiIPYfuvXfrmWMtqDUcC1OGjCIahXKHGDZ5RYZQABFOYiGGgEamdwHKDoIpY1 ivOYCnAQNVUYNZ4lA1k4cs4BWijnDPIlfMVXfK3yT0gyRhzYDuNRc/+3iWEFGD2VKADR/wngNExk AigkhDdg1izKND3J5YfrJ4N/SAc1CIjmR5IEp2t11VdwgkI+6GqPWFiMQYSVgAZytH9sk4mLEmUN aSVmZxXwqAqiSI9rJwXcRkr5I0X82F7+I194lzoCJFVaEw5GcovGZ4ZSQEsOA2AHNQVKyAkGRoL/ MC798CFzuGraty1f5lLXNFy41n4laYjWmJJ2QJLnh5drVlfQ1GvbyJE11GB1FBvjaGpuow/mYhR/ oUtGk3HEIZSsII9FKZn2WIVWuFndRkrPwRwBJF/aAA3kRpArR4ZgE0vlUDsExVUGRXbmpIRiNRgI FnEgRGzIYyHZ51Ys9ZZwAHpNl5ckef+XhGiXwKlXhJiS4qcRuwlSimQg8tcfL5EzwFKWcpQ+e/Z6 sPd6fyZbuQSUVPGYsBCZkkmP22aKCihKPFZKkuY/8JVypEUwtHhfWtUkchEl/kUlAZZGCdU24+Qh 26VixvhbIVN6zxVcublrSzecgkicwmmX5QecZ3aSeilIYOBXcDYaxRJdqpEQdVRTIkIJPmSYizIP meA7aYNOnwiF4EmPlLlUVug/cmdK55k1n7lKqIIq7RlGt7RpcSEPt/MJThZqm6gbwINTtMFzEtVN y/MnbLmcKqRSuWZX5yec04Z+LOIbUrqg1kic2ShIoBd1y7kmLzU+FyKJF1mJs4ET8zb/FOo4Zbyz mvdQB455oig6ijkWNZvFBJaZilX0HM4xKvpCctUwlVszi0mCadzhDbGkDvvFi17JF7uxhH02b9zV Qfh2N9m3GiuhSMAWV7oJoTZopdNGksBpkqB6iOuHjZrXQrJWoVRHecl4Jo5zExNpieioD94FGMAY Mc2nF4JWFd0pKd8ppwd4j8OqY04AA1rYe3bnXtBBlevZT1hlqMbHQA8TS1qZHovKjolXVpQEEOXD czM1m9gCZtDzUUg3pcB5koAYnAxKpQ1aqsYJjS50QgKCODUjQpbqOAjhrSdGH9u1Xe8ggvUAYxdn BnA6e8AarLX3Btx2hZYpSpnZgFnh/ymayTp/2qygWXyyMwYvJyviUVBtWg/wADwG5oY9kVOTiH3b txDLmCyvJmYsOX4OemYNuqDBOQpVGpzoV5w4qHnGhUJ60jwxqRIY0hCEaW9nxV2XsDaud3jn9Ame yJ1xmrC2RwNvh49L5Sn11CnzREDyJZCrdB0Co2mkmVUKs3wzh1Ahi5g8lYncyg9COCZbxmrH5I3P UmH/hmbvCqV/aLMMOm2EWAfsSpynioM+e0LPgywLV1GsYV08c12VCDRcAhhQ5osS5FXuGJRSO7Vr BwcgJ0qfy3sLiDXtFSTMQB2f4gyqJLZhOJqsgjvlgTvU2qNp83/A6A9a8qjTZ4SJRf9MGWozerSk evg3tRaX5ReqVRoHdlCDo5C8wHmlgzuDTMepIHUgFeKIMFVsBQFE5eMI/TqR/cdTmBQKLuaTErSd s6e5m8txVLBoVgtyS3WFVbSFWDNf1uEMMrp31oANSCIGr4SQWcVk+5WoZNeEYUU5mABH+3pnjlM3 SeqyisSMzJQR0pO3MkuzDFoKf/u8d1WD1IiDhTtXL0OvEuZqyYgIdaZvwBJRs7oPGbMeYbVGasir UuGrSoGw6ottM4CPlUlKooSs/NhjVDMdPYKxrFuVhroWyicesOIOZ0Oi2SkYmCSW08d4cWOkkRRJ hsCyhcRHuWmg01izfxtUb+q8yPv/h9N4a0b3lgFCejW0ahUVmDu0CMGUfxpjOaFwOZnwxGnIMJl7 sOWFwxyHFVUIv3XKFaKUrC96v9ERfKrzXvm7umqxKocqrd3QKkwGD6pZFI4lMZfgRm9jjBepfSTk wF8WZssUjedaiO6KCnxLqsUJiB9srsIVZhKiPN1yfVU2kUAzonBkMbqhJblDK+cLI+kbyDcmng67 gOPJWabzp6tzv9E8VUbSDO15VdJaOwX1Khzok2n0CRoECkYxxWY5b+Uzptl7UV/6GXySmwZnoIP4 qc47bck7z8d7pTdoV2p8PTyYEdEFvLZZEDoUh5AjCYqhPnx2c+sxsE3bo7DSmDRs/8zHfF7ESsiX uXtTw153N7GmlEX5OzA02jXeUbYMUxdbeQ9daSXssx4550sHvEFF6nBqSRnR9TwEciAh7KTpiqV8 e7Om8Le+WYjRK8uG+2ErGCEjdsIoiLK0UZE/hEmSxTZselBoOwW9GtESfVlcsMN1arVLBXKJ/G3U oC/NEB1nQV/9FDtpfZXr5g7pdrYgSHOOIrk9NX3y0XUfxGAycSH5wZweBTi79nTjl2aCW5Ia/Mon GaWH2GHLJSec0ScWGsevQZPFI53AdMeAhqtU4m56MQbE/C5XjdVGFUqV6dWmWDp5ul70G1XAN0Cl lR1qEQVJbIHhoV8MY8ko7ZVgSf9EuAvOtZF/lK1ljcScpOdvcEmDQS246WoHGEySD+qgBLdhg5Nw euInwo08OmQoN7lY2+UPO5V4OgmCi5mGFhS1fxzaiKY/VsvVV8uwVeQcncLI0yBVYWvEVQl4Z+gk U1DSPLo7uEoxzKa7ehZMPYeMlvof2LQ3oSFSgdR5xovY07a8zV3YWQq4N9hhTRotc1JCNmN/i+FD iiEmPAFEjLUluMKJ8RYPl/sE5S0cN3ze7zTIlWmForRUYiG//eh7p0TWROyFaNG/xgd4rJUOZUQO nTbAYPV8A7ZQw2hWD0XHakVHxwTBLEGvGNGRB9ep72rGDOq3bxrUoxqzymVcfYP/IMuYSDiUIYcV G7sVOT4xFC4Glm2btlN9NBBt3i9+XjdQmdzG1dxWrE0JgVgDkPNd36lyfEm2kG89JZ72fEnO5G7j dfFxk7ABPoygkceyBlTngph3gzK4fu5KBxIuuOonsxaugx7WPEFbdQ5h6Q6XZfeBbE2Ojp5MD+XU jj06u3oBBQ8tHKCN506kw3v+dnealEx5p/pYcqAFlUIiTx59DW3BckdcUIdaeB5rNO42MbBnLiJK NMTIWxpSPMljUZP3ZSuYQos4vTCYkjVoz8dbnCIViH0Y3V3MINQ9f5Yq2WFSllhmsuTCNlqix9n5 xPX5DlNRw6VAlL/eNJRJ0Q2//2hfzY9hzdH+skUCVF+uZDAhvSScLVAk3Ys01+jtYTk+sUHCs8A0 ITIHMWeHI7wuyIcYpth/iNzu/umkLtizDNgLMk0k4402w0OuDjkEXZis9xNcghtRrR4n/V9dBSWe vUS+rvD0k2NWW4WkZPVyh/W/91liDSQpV25d1DWoNa3dsJW0hK1Ibp0iH7npY4x4fQg4dFHWSxmp 7mbNBJIwv7PQu8p0+cE96352wiAYwc5y38AoTCbXJzmTcJMTx0sE9lOA5pPNZw4PRAYzTClQH/Wf o+fE2vB3asjHmtqcKQ355I/Bp0rRnlrS7k+0ROSxMp9oKEEEZi6jJmX+elM7Uf+RIJ69tlkZJtQg 85oyTKdmic33MT+lF7abc+JhrOqIDbc8jKTmj2fF+nmYaWS7jpK2AAZBCWMFdt7igJz5nnSPIED1 9+i58Yv+W4FF+9MczRBVnun11ECBScIWByNLWhkXC5m23uzobhup9QYIamtqgoWDb1dqb2uMjIuI j1dvk3Brb3CXcJqZmpp0nZ+ecJ90caSjpqiqoaGdmK+vb2yTs5NrlY+WjoxujYyFiYODwWdqU4TF VmrFx2dWZ2lnxWdS1NJmU9ja2dxmT9RSY1NjduXm5+jp6nZI6+7v7Dwc8PT19vf4+fr7/P3rXDBg xAg4UCATgQZhNDE48IlCGU3/IEJ04vCJkxgWmzzZSJGixY0gQXqTsjEcyTEkvY2TQqbak2zVwnXr 9qxZtWdnqkh7ZgzZskI+gxkStqaXFl25FlXChWlWLC5w5miSCkqUHU1XP9WBk3WUKK9go2raEuqS 2VhLH+FCqovXISvCgA5yRojQsTXMfpph5gzbNDNW/G7by1KKtm8mufpD127xOSTyHEueTLmyZclX EGoeWJAJ54cwHDKZMbr0kxgXLaJ+MsMJadYaPz4Rs3GME5K1a6d8YhLlk5EozUAxE3NwtzPalu3l Oe1nsUHNhAITBPeNoF1sZdm6ZAltJk5Vv4I9Ferq+PCtvm96dcvS9rWQGila/3OUqCG4y4SdwSuo +TTm0EijRjVTIHdcTC1hgxI13lCzRmWNTQbZPJdVaOGFGC52AwwfFPQZQgN5dlAMnkEU2kMRpZia E02w+FFHIXEE0hgcATfjFLwhhtgZv43jo3CEGajNGdwoVyBgzTUj13OExCXMFb0cssYV2anVXXdn rQdLK+fFsYonXrLiCizrnWXWG1xoh4sk2UlynZSGAJVIXWoo8xNzzklhjDXUqOGXNTEBCqg4I50B IYSR2dEFFz5sAVWGkEYq6WUFaUaQQpcOtNCmJzrUImoqzhCRak8wARKMHskYTkgpnWTSb7DGFNxM QWbTlzMGOrcMnrpSt1+cbv8Fm5QuaWKJppmwUOXKKec128qzoGR51i3aJTUsW5YIIpR0g6iBhrf5 JfMfX8v8t5c1Qx4IZGHU7HgoZZCVYIcP9F5xBRf4wlHHpPz26+87dSAEQqaaceqZQE7AQBqJqIE6 0WsryuhijGKcVBKsvvkmnEktrdSxgoESWCth5eq050/5HaPGFcXICewhVC6SnS6YWOIUtU8lOyZ6 X0HbiXrgmZkmJtqlOcvMh1wX5XzT/Wqnnf7pSmQathaoE66BajNcN7ASh5JikkUYNg9JXOHDDmb7 AAcYa0PFxb9wxy1pZpsFRPClIjKc8BMSpVjRik28JuqLsp2aW44Z79abYVD/GIaYNi0xWGCfREpz tX88qdxct5yv3Mt1gny+yBZIRUI0U9L+3HNYXDZ7HifIVmvzdjOTLvOU1jkJbF3ffiuuXbsuJ+AU 0fhlmKDFZYMYN+KEA7ZjYkOvhBL07uDDFY5CtSjbUIEh9/fgT5bZwB3e/dlCqAlkoqcoumaqwx+1 WHiMHnnzRBRP0Liqq7BOIcVwMiEOjyQnGFtVAzDCMwbVevWrbnlLGU4qSiJklouZ1Qx13kFLmXYm itapbkuwuMQWMmgl2uViPp+jUi+Egh9BTMGByOCPf6ZBtXMVaEAGQlc3tua1lZjkCvBC1BauYD16 qY0Li4JD95SoxH2F74lQ/6zHDC51t4WIiCGY6lRo+naRjoiKIq15gkZYhCoahcSM/FOJxn4TwMIY J0h6OtLkkEO5nyipJ874llxeBoxdDOsRtFCKmtRDpvV48Ctv4BLQhjatpWCJZpZgE1Ko5AjQ6Q4o y2CZGqiADOY8AyfMqCGfDGiNx3nMMIVZUBDhxQMsVM9s96LDEpPIti6s7XlRzGUuZxCDDwikfHb7 zIc2ZaKFeKo0pFmYalwEoxgZzgwU4R+sYiUOlCToJQ3qEaFoNbWc4KpcAhoXylb2kzXgRyhvqE62 2hIfW+DCLCNEFiagYpZPZEIqiQzhz+hwibJs0EyUgKQJ2/KL3OlOKGhQxv+vfKIrJUHjGNWQhk1w GDICxsQljPPGKiXEAyFc4QZGdJQSu5BEknLBlUr0wi11ydIncshSHyqIFTlzsIg0rIuBM1WpSGWR wRHOIxQxY/5k45tYtYQ3KAEgoZI3GCFVzho4VMYdmbSflnVuKJZURMyQcrQ3kG4tJNSglnb2rKDN M4PUohYbtvAI283MOo8oBCLi1KS6PqNbdJnh5cygQKeSckjf+M1wAouNWOGyH9FbDGSoV6/rcYF7 a6PlFVDAAkY5SqXea6lm/YUFhPjSQ1T0kIhkQKJiarFUyfzbTikiAzEaLiQeUVz+dtM1HBWWQVtb ag4JFI1q4PAvu9rJf5r/VAxN6i5pFFwZBbk6iYBqB2epA1pYNxhW7pjFPTf7YyOEMqVfHBeC+Qmu HccrXJwUKDByRJ5FGbQ4bxyWH4n1B2SGeDZ6bcGWSMQvHVT6BSvgAAco+MEt3ebEzRoYQ5kpXy/r xrC6oc8ze0MRF1eDmhnsVH6pmk1JzCjUjCF1N14zCQC1wa6sFSiivs3GyVr2u2TI5ZxvgouUasdV 95wlntMFD5kIGbtY1AITVyDaW9nkpqSEbjpxARfUChE1GkqjtwGCo5CywUPEJBUbhfnNg8KGKFei 7XpJ4AIdaMlEMJzNCmjeQhzETNJbduHAcL7MFAb2UgYH8yCcekhDJKwi/wpTpEUWTlUzZbQR/CVu mjLhzVElV01acXOBdMSJ1MoZrvDWVXekE4RBtUuJICMFg9KiZ+rQMkISOsW6NZPdtWQWJRlnVRh3 JW5/xCve81ZuT7yVholJ3K7DvIpHVpAQojxqxEblK79KPLYQdrCDLYCBpLasZbTfG+dq42OKveTM Z4MJoksZbGE4nQj8RkPGjejUcEG1CBov5hseLS6VbQSSDvfCjRw+g6/Z+CTmWkYdcHEOP94VRiTe Wjr29JgSB9dnwicR5ECmldPYKQqcqITJbvGkTvz+lkP5ihw/2aqAb1QeNba5IDZ6AxvCZiWjrGev JMChC5AVM75EyoUrCP9BE9DOuS29wDZr+zwfM9h2aDczoisOBNwkArffIJIRvomxtRnJMKtmNNuN 2G8khP0floEEE0Hlm957wXc4k+QTcxZDj4Tg7ueyRTrvQvy5gsTFqf+5Hhz3WK2CVHUktMMmVidt u3s0p34GP16p1WTFzdDJiXVNjcgZBibBsXLjfpNyjsKyiPea9rPxy4Xs2bLNbKvly7vwiTAokQ4/ T/07AkK+BcMUbzTFlN6Sjsxwj0p+sgHqiziMP8RRU+sfjjyjqTwkFD+USHvRiSeb06u0L/S4oKug LmxXC+w2dw3xRBOWqhtWap3pgoLEvnuwJX5HqDCCdK2TT3iCJ1w1Ixr/yEFvkKSsDa01CKMj4ZgU Kj82xl7P2Eq0Zi+HRFwAUjWHL/iyc7ckbZ+nUl1QYKoXgV3geqDVbcKURbO3PlrUIoHzZ2DkgWNE dbyRKt6wbvpDIyfHGzyiPBsjQI9XfJWjJ0gyDXX0TSqTUOByaQDnatkyQfPBFrZjOmmFOqgmQt7B SGmhfbLwVW3FXG+laViVO3U1J4PwLVUYQ+TlJ+USR9JwK4tXUUxVGIXREi3hG9SWD/GFWDywBdfD ci63eaKHLyhgAibQAz7QeQgIc3DgBV0QB9I2ZoAIFRAYgdYGEDBAPr9kKQhxMAFBTJgCYbR3GrbX WqYyKoSme0OlKogW/yuB5W73V0rqdUC2UjnYUEPlMmkoY1X8pjuLcB0ys1UWNH7u5HCncyVmkV0/ lnepphTWt2p+pGlPch0tJAwq0xM+0WR7whwIlEMwiCBjGEA6Qhw54l5cxkpKkDZmI1KfZ1KyZAU7 wAJ0CFJDhICzpIc593Jj9oCE6HMJZjd0BloViD5Y5BBI10WvwXSpAXUwEhtSdxscJhKI5hv6BxzJ QyihGH9d2Az6tis/wUn9AUHDGCdqt07LpV2p5h6VsAW1cGrV9326SDOqNmStmGmNABdrdx8whBcW 9y0KtXzKsQwRRTxHgl7z1nUvyBv3J1gjsWWKJUSNVTb5hURuBgfWw/9sO7ACdIgCZZM9+CJLfvhy cGB6YOCAK7WOcEYFHQJMC7aVBBMiMtWIJ5IiyGQq+KgR7yMxr5WJ4YA/9mN1g2USv8YuOllRUEUg 8cdxvoWMDDlrKrmDcCIfkcROkQRIn6aLgQRIsdAeGulOj5QUXSWYbYFCgLk7LuRAZzdpuPJQuAaT jPdX3SArIudGOolUT8CT8oUojEJE13Nz07ZzYLByqnk2PXACJoAC18OUTCSVUDlmYBAHtmR6Vmlg V+BLHMKVdpYQJIIp4MZnE5FTfDMqrdURsVE4tkFoILE4VjeaLGgSgvJG6OJNEuUcwkVrVYVJdYF+ g7AFP6gImrZVj3D/NG7FVlUyLeFHNJcgCdZiCW41cBXUC6/YR9RxVd3yQurHYngknh0XnlAVcoSS W7IiBYlGkE+gBtXIUfQFZpnXPUvEKDhgPTdglMxGh7V5PVjAlNoTlXu4gKMnZsHJUhtCZ58ldJWy EBaIKTZVGjeVo8ykERwYRhOTYTRygqyCEkmFndTgoFy3TcbjhaIUR9FAa3qUVwBHTnzkdthRkWwh d7yICViwdxlJmI8JB24FH4MZmeskDFFyksfVMlF6J1FzDHC6JzpBMiKjXrwmBSvhI6+yMSgxBRXa f0aUjdqzc7KkRHOIAjtghyBVlD4goibAAvfClIsCiH3INrqpUqjX/6JQNEWHmIgDIaMWiGcwUFPF tD6mMRrPGZ2BBltoGU2p0hshQZBKhUpu1HVNVTXnAiDilRd5xWRWoEewJgxHAYXoJCUys59vBUiz 0FVp0ZHDgqzSF1eBmU7ehWSFYCdzUhe/0jIOVQxh5ydE8ls6VJMld3IrkYLu1m5/Cj08UHM+YAX0 ggWPNVJO+Zo+gAL4igI30APWcwJG6QNIOYcmcJtug4Bs4wWFanqk5wWPoqngMwMw6lkxdWdDR6PG dFoVZiqhcWEeuFPO5HtEep2R93uIQYaPtyC7Vm9UQ0e8dUNRE15WxTt1tTvnhwgzRnADlZ85a4uP 6YuLECVsglX2Ef8XELStm5RJuxpcK9sTkwN2pHQ8TGWTJeeJH9Yj66pY7fp/bKiNsjRtXABgtUlZ +sqvOLACHQpSdGgBI2psbgOVvSlL6Vh6LOqwcRN0xXm33NZtCMEpC7GctIcao/EpFBEardGB6EY4 1RkjJYgbRgWha5RRzuidEaV4Wjh2B3pHDjUIwwhwETRji3AUtxMfpdN3yeoepPt2klRJBsU0EkdO nWOZMJSK7fcTEZV83WQNjpakWdZrirYb47ARVytfa2g2X3YvdQAVDmhS94qvtVmbALYDHcoCzCa9 tVkBEUCHjoWbQomwe8g2W4FEg0i3kZKIMdqpxvkZjOiVCgOJyCT/uJK4U2EEaFKXiRtRBvXLbnv6 YY43QHiKst35hddQOflWgyhzDMBqJ4FnCEtjH8HQCBU0OoIJHz2Ls9iSur2gnr6wwIInkcSFHwol QweamaCkQAWCqweCWy7Iaz3CRkSaRsGrhowSqCL1bNKmRMubr/i6AihwAj3QAx96tj2QlBWAAhVQ m1egBORYqAj7m2tjCrYkvvzyAVn5qa9XN4vYYDPFnCkibs9ZbhODYYTzsUUlYo+rMdzpRjx0HLgb DSYTTgr5ss4hQxtsrfThFkYGJX6Ux0lBuovZJg8smK3YFisUoJS5R5eJRwolNdEQGIERrsuRHE+L PEASWI6Tgv+T/78vDF/tai//l3lQOaliNgQ/ALA4XMosgAP1VZTV27zYiz0GCxWmt19dC21zC8UY EhC+VD6+NDAVqCl6WyIXexEQ1mdkNCqFu6rzS3X7Y0YlWLXuZrI/0iN3KiSNbJfUTIOFhyvmVBct 9BzgdVzcBYxnymmnS8HHKphrJzMBCidSuMHdgoNAoYrOkTldWM+NPIohRxhAAkAsiCNHip1Flcn7 ABkxvAMeJQRu05sHuzY8hy/3qsPMG9E9gAP8mso3MIdqK7D0godMBBVjNgrR5pukZ8sXAgK7zHqW QmeK+JXqO3vCnEwa28UhqFNg3Ew2nSMblkYfZhJcJ0Df4IK75f+tMvkXKuZQqfgTvkNXx4WeuWNQ mXY7uOPAedwWbYelbiLVVtDUrTu0ezSMzaFJvfqyEPVbvhUoJkwcjufTINPCLTxNGgU9qNnJjoWi 2rNfYlYHYBAGeM0op4yvAIavJ4AC/wW91sOvOyCwAmsCqGyisLyHH62wT0zSloHLd3vSXVkwe2sQ C8NnodG+rjEqq+EaIDGd+ZNuzYyCIqs4ZUhlqFRNYKheo0i55GKDcWwnZjezG0yFoiN4RKHVdfzH uVDOkHmz7VySXB0MEZmDyTAXx3i5xVAN8DcNeoK7cDQYzpggjVNY0piujZMxZ3gPaajJNbdssJQv U5mODB0GCBv/Bl0QBrI0BD7AAoear49K0T7wofWlwzrMyrZporekm6AXlZJNGR8wMIjIlSrNbbGX nAyeMLSXTKFiKuUmRl4cxox7nTnNzC8hkMChpyS2v6IYaYLBmR53is0xu3WicQLquobQ1NUxFOsk mVLNCLBIrXDVCL1QHVetplO6Rw7punnBkGQ3QxDFJ3Ua4qK4LsRxrvqrOIf23fYQ3gOdtdiI0Oi9 ofs1lXo9lWCw13zdA6VcmxPtAx3ahgBbtnN4vQRLji/nh27OPZk64P5QZ1mJ0gShYFR0xcoJiS8d 06mBqhJROPOLifarlhsWfCvBI8TBEj1tq7nbmRxHg3hyRziI/3ZM9rp07LoCN86+UGRQCFfibB3n B4xCy9VJts2yxm9sipl9YTVCzZkdRysK8pkmu8/SmL9V9xtv05MqB0tgpj1sRqheoN7sPezew3Nh 8GwOXcr5arbV867PftgmEAFzeIcj1JSzNHptJuf9kMsHTpzZZj5Y9JXfNpavERqg8md/w4+5dzgi O1viwIl72jgJAqH3B+KMV5fL4OrEI04MhIVMwuLQN7TIvU5H0QtA69u6MBShW1DQh8EvdoX8UVd3 IU607R9/MrkHGSg6CXn+gxIy0cJvOU1QXg9Srg8EbXPYmID7NXpKrOVazgXsPfOP9ZpCIAQ40Nc4 fAKofDZmA/+v1kPEKHC9dpg9I/XmI0VScc7t91DnnVq+eb7gYEmjMSADo4EpntJFq0GWkhhGaHlG FuEqTqA/pNm48U4c5tqJL5i7Q41iJv5Nkq4rmnRXdoJ24dzAogOFAecLNxsMgyytgjCsPFjHNLtH 3AwdR31xcG8k1sATZc14xhcyJLYxI+cS7vYSVdfMv1Hy9HDyaNiubLia99I2TRyU+MJzXjDswy7z MBcGNb898Q3mLHADp3zKdviuHrUFX0abElABI9DfbF5Lx7btTG8PL4WInWq+oGrFDJE3fQ7TXS8/ OkVusVHTsEX2Q0VbvxfvI9d1VnbCxnd8D4UN4IoTifw7OUj/CMBqnnHBXeiJwW4wQXFx48FCHYFM 6uHsznY1F4mQ1A+k3ICgdiZIOHVmNThodnYmxejYeDa16OhoBmUmReb41DgmNTb1+QRaOjpGmvoE Z9fq+gob64okW2v7isTTdeXDy8sFBgcXBhfcRcc1ZfXD5RXmBebM9RxdDTZ9PeTTg9LNgrLjIy5+ FcTrg2NiYcLus7XFFV8MJ99VXHebr7/P3+9v+wFGwA8xCAqMASMhQhgLGzKJ8fAhjIcyIMZwAnEG kycwOHpkMuOJxidPnJA0STLlSZUkRz1BJeWJGZIzY86sOfOMzEmTNFU6Y4YnpUeSEh1iJCgRIkKD mKqxIgjq/5k1aq6oUUM1a1WsXNe40QpWzZs1VtZQtWoW69isWru6bUuV66C4V6k2HTSlkNMzaRhV kaRmSt8zf4MO/Yk46Cefk0jprDmq5suXMVn9i0Xrsq1cXdyJ2+KDCz1iXewF4+JjSjgfQ5o9o+YM mpdpwIJdE5KkBw4WOFD4WC1uhxAr4kygYHfjRi94ouPRKW0Pn+bp1Kv/O0gwoMCEIGB0N8hQoXiG EpvAaCLjvAzzHNE3cYL+Y8kYT0DWL4kf5RMxNE+OignTJ5g8IYoUokwhk4GffNKIYUJJElQjgvQl hRqOqGFGVInoFdhVVk3lVl1Q0QVWWVuxJdZZKJr1FVZWdf/VYlphofUUVWXNJZUaaCy11F09amhI YIksYggkhkSImE6R7GSYTATeRKCAp5SSknWtZGbllTyYcIUvvYh2WjCk7bLDFSiwIM4QSnDRGhdL uDnNm2HEc02dW2iDDm/j7DkOCzccZ8IOgpbZnGlwdCFdloouOt1A23VXUELjNRQeQuaFV5567nWE EUb1hWSfDPiNyhKpKMXUkpOgkLKgTQk+htgmQAk1iSR98VQUI2kYkhcjPzK1xoZMIWJXXHC9lZWJ Yb3RVVZfJasiVsqaGCKJgtB17VU7boiXIBnyVasjVixS2CTjhjtrJpc0mZMpMT3GKoCoripGllja uyVo5Aj/sYU9XtBxqD3E9KJNOCwAh+YQrQ1RjWxGAAMxGLeNg8M454Szmw8mnMDxDSt47I48c9LB aMkm7+NdQN9tV1CkLo8X3nkTIdReRUxo2hFIOj+xHnxP0LdREyW9VxIqKaHiBCqSORlvlKUMqCSr PT2GriXhYkhYURlO4lSvHRJyxSAj1kX2i2iNHRZYaUu7trHVcnWVjtnmddVUdAvLbVJLGXJUYEQy gq6DhmHS07pTSHFJJQO6uqqrMD1hL6O5mCDEFWV+yQUy0JWGTGhKjLPCmSewgCY4aIojRGtvRsz6 xNvsBvtxPvxwXO3GsePbPIeezHvvrwwUaXcrI0RpzBBV/4rpQux1xLx8OYfkhElOQL/SSiahytLj C/YXU4EJgiJUJ4jTKviRReraK1595+213ErN1ZS1Ns7P1dlnsf2Wsl1R25b9HmZ7iLp1aH17IwSR +jIUMyAiE+CKRGJ6IqsEhaJVkVHVKUiCKlREblGTu0ISPuMOOHhhHvYAExa28LnQ9cBPLBwdb0jH gh6kSQg/WFidInaNO32jG92oGBeMg4ITBNE4EqgACuIABiRaxndMLNkMQOAoRzEEeAGhFPHIIzOI rId5m/JIR9bDs/fQpyNE8xmpRpU0UvBHXhisIJQyQbhWNahAkXDQrCLRwKL8hS+A0wve6mYssdlF bnBzW//b3oLI+/VPWoX8Y9zQQAhCdotbiEjfAIUUIQdqshKyQhzinvS9TTgJQZegDKtUBTkr3UuV +fLSFZRAD+gUQ4k+EII4VsCCE/TACjdgwQpwsILR4XI3pFvhnhQWD4axCRhbAANogNlDLnTDONzo wQnYcQIuILE0TezmomYgkOy0LDvGY5mkFhIz81gkIV3U1Eg4RR+UiKoJM0AJ0VJVqsn055Q+cYwF DXQTTCTJakEZzF+45ojB/AgwwuoVj5ryoxetIS9uY2QhEem/i8YNW8GKpLQgWZUN/chr7wPKhB70 EwUKro6T6GROnlSgA40CXpJpnEo+sUFFTU5fvagcMYz/URrRdCYcoftYL1Rzgl6Orpcfm8IUerkD GEa1hmBQ5sOKwIUvSGwLtgwND6fZDW74YB5I9KZZrUMDckpRO+QsJ/Ey5ZCLWGSLn9oIGUW1kYuU sXr5wY8UTIKKKDCNaZBZFSnjWIkmeYJ8mqxV+vJCpKDsZaEChCSI6DKXR9aIbPsTEdwuyj/+EdJE VPBoIsjio8ki5ShBSkSvkESUTTowFAx0UiZaJcGYyCtApuxETvFlAtRcoXIhNFTmlOhLEwRzBb3w ARV2oBwfcCyXN9DEFuBgJhbuZoVDeNPDqsoFWwqBC0rYAhbo4IOvglWISQSDPc4KX83cYCDfaZl3 znnf/5hNip1ZlEjN2llXnt1nBu8RGnz0c9OWYG+fM/nnTRgnSqqVz46WgJAm14chh1JybnHrFiRz VFptle0qaOOsscYGN5CGWMSRDNZSBHgtSm4ooSZNkmQjy1ifCE58QWEMKUQZr8fxkyT8mcJvWWkC fflCCV3InBegk7kusIAduTzBZy7XJV927AZTIBkvXIjLFfYgCQvjghFsuQMrs+AHaxoCaHb4VRwc A0zxrXM/prAdtbKsrW4Vz/HeCgON4MyLn4LPSEYiz5RIr68oQcn2MgggUkDhae1S1/jaRdvAPagw g7DaroyyIZK+uG+RhKS1BPEhrIBIo/eTS1xCjK0dEf/CRk1R9SW9hmu9AYZvWfNbjjdpOAa5642l mIkoTtngyaBKDUe2zuS4YLlx9KuEJLSHdFeg3ECRI7yh8QG2WUADE0jhCnCYwhU+xsJeooCXVzjC MrktqBjOTgjOnN02eDgNONSBC4mys79l4YMPCPxR92UrQrrTZ4kgJCKWCvTN/uup5nVKJBvZyNDy meDs6daUuC0sFCZISqFMGFdGspCvGKGIvFSIoXuZNYc1pKFTi/gQLu4oIaVV66PYHOelviTMuaUr WwU9a+ZbBEtHbphLP2nSm1hXKnTyH+1hz2hraHZ1nk2O4V4BOs8ZxqHAYDkTTHk1V2gNOXJ5JgNJ AQ7/dHCqUn2JghXI8AqoaY0RFHan3/wmUOEQ1A9+MLseiKYO7/234WNxhYKvrIoGAc/L8Eseh0R+ 0M3bCBhzJhKSdMR6+RnD9ZL2V5cojUBMo1JQvveJpGc604bJWmMpYXJEGCUpftRQtyKZ2bi8Tw0r 3jmLed/iy8YN+HehCkkvGWpBHFTX5wPKAoskCIKGywwRpNpiUv90VM5kSimpiUmqrkrJbQna5PAB FuYxm9PYgx44EFRqLEd3b39wBRnwQSrs4IUrWKFLYg9ULpMAD1fAAqnDJkOQOqnDVRojBEJQAuFA ZszwHMjQb4dneFwQRQUXKeDheAoheQ1nHhohVw+B/xE7U3nQMxIWZxIWh3H55BJOMlM/5ipK4hMg V2nk8yAmVSsoV1CG8BdC0iO/siETJUAO1RZ18yKq5mK/ZxdQwRRhI0BicxdP6EeuNSESsgi7En2z kmFIdyAMpHSZEEEFEnWqwEajgGBvYHXU8Wy8sAOgAQ+GokTtZQeWs0tOZQWq0Q7K5ScyAQU78AA3 0CVcYFQaI3ZdMgSrMQR3F14GWFVBUEt88gPwEAelMQz9IAxr8AbCQIElEwcCJ3AFEUUIATzcsV9X NB6XchEOJ1edMkbz4TOiglfUsxGLNir88RKC1TSpUEHgc31S4BOJRT4T1ghC4TfjInuuZVKzt3vH F/9iUcgtg+RQmsWEpGZZORJJqbaMPycYhjAYj6U1kFV0Nph0OtEYOsEJjeEuthVkg3U0+rREVyd+ wQUa5/CGJXQNShQPWNBVN8BLzyV236YBKKBbNDAFVGBuqFEmAhhMIIQm42WACtMlllMCpzNvs8MF x6BE+rAGxdZ8avCOm1gdKkNwi3dFG6hfHthfFiGCGSGCYtQp8VFgJyE0pQJYGJRxlDF66lgKmzAg YAg+ATWOKxUJjsUIO/gtQmIhP9c1UkhIdNOMnOU+lQVIUcFi65N8eaOMhcBHXFNQFvYgmqYYU/OT OrYTo1AgA9JbqAIlpNBoOhWPqJF1STAPSXQoYAL/bf3ChjjAS3ioXBagARkwAjMwAzZABVdgIFyQ G/GgMdjmbYuZMArDAjNABk4Vbz5wOgt4kfMQBrewBlITCXtxBh8JkpcxAwMxcFQkivklilYEeX9G EakIYB2hV/UUH/UUT4xWPY3WYFRik6UnSjixEwlCR4lFOK0HUOazhcfIK+RycuqDfEtJag3VclhB N18TQFhpfHWzUAVkK+DYQIKRK155GOkiclPDJL8YCqNUWHy4Kts3dYCFKm7JQVuCXc0VMvRAD7YR B80Bl6KxBfoHTIFiAhmAAH/5AAEQADdgAyIwA10SGqgRdyewAti2VMylBC6gAVzGZdgVVV0lDk7m /3W2oGCtRwhMmCOjSR2lKZJ6xnikWE7Is04Lp5I00zzPY3lC0zNlRB/3QZP6VDT4sT2FFRmTFgrF 1pMFIjg2hlJ3pFIYYntYQ1m5hpVUeQggVaVPMaVWehV0c3xY2SMldXJGdysZ4gjl8mlIF0fDOUGI I1BuxE9Cxn2qYBJmIJ86tSVg9xtatzlCRUJ0Bwf8wgXMkDngMAU4gAAWYAEXkAEWQAAPIACNagLE AW1CwA4WwDHY9m3h0AIZMGk3AAVXYAdb0Euo4wOwRBokEwtwcD3ic3shQggoKl8pc5qjiHDggXDF 82cTkUUwYDMgOIIa8U4BVhIE1lf3QYvVA2m9mf9sjUNBUnCkTCJTnCBb5ZNhd5SD4jJ0KzdJStml TrGUSbit7FN7JIUXi4AhCwQkf8NS5MmF4/iLp2dsfFgTv9kfLZgStmg0RpaG0/FsSvYlp+F10UAP 5gYHX5IEgVoHTWUCh5oCKIAAiqoBFrCoLPBU41ABDxABJrANRWUcQZABGmADUGAu2GUDURUOQoAF YrI7sAAHqWJHzcIWuger/3AFpxk8eXYQ5qSafsaz5tEEErGSOrOK9AQf69EzYcRXinZTCDYZUocK 3vMuCSI+nyCGSmqc4ulA0RcYfeEtedFah2Cu29qlL5ZruEdZBDSl6+O1gyEknWZhK/cXkPAT4ij/ Cg0ytUjak5yQCf9kSvOSk2WgEigBfuE3nyVgB/Y5XPhpDKLxHFtwOHa4BtcVDKlhBSiAqCjQApaL ABKAAJ1rAT1wAxPJAhGAsSvQCoupXEKQAYBZSlcQBj5QAjogQyfrdccQCyo4PrWGFZjIuyaSCDPb D1gQTuGEmuR0s30mHj57Tis5EcBqV4RGmxRHEnmVgqZyRjPhBBvnEqb3TwJ1t8Tpk+2KK0wKOJIF FETHtkeRtme7nV46pbn2td4iCF5Lpr6yCLIHCYbxfENxdD4xR2w6Pum5npIhejbFEquSEmi4r5qR C4bbXPMoVFwXVG/AZY/rVOKgBNB1AyZgAJd7/wGWe7mXewNRlQEVMAIVEAGZcwXZxlwKoAEmMAOZ MAOsoQL+54hJIDAr6wrUUwrJaBaYeAVvMBZr0SGDC7z5IHBQVHA4m7Mxc6v4dTyVIoLh4UXL4zyF hqPFikb4lDSOhk+lBxM9SaT9dFv+e2lduKQRolIkV63Yij5g+8bcOSzuq1pzjHyyRwjisjUmdb9+ Ub54pMeyNVBz9AlN5717G1Dgo46o1LRRYDRbvAp1ii8cMIflR3eLGzDFgAVSAF17aQU2UAEmwI83 YAGbm6gWgAINmwIW0LAWgBofWwEo3AGZQwXssAJRtQARG5gi8ACtscG3/BtCMGeV6AprsHmUUf8U NSLEwiAMQpwW84uqR3wLGRhOBVFfevbE+8UQC3EzxDOCKum8hGYfO5NX02vOkJxPrsJgfauTL2W3 TmcY4su/e1Qr3pJH8/tpBoQUQRK/Yxuuz7lafOR6ScHP6qvGXHMk54Jj46l0jdB0EORJPPlSpgcF Nrkq/6ESjhy4qbTAl5ELlExczXWRlLg5cCCqU2ADT4XSU8AOGmwCnHuoiIrKM20BEhBeGdACRRQB FcAMHsMOqpvLBoqxkPkA2hYOpZGRrnCbGPSZu5uJmcjMvNth0pwPKvoB3+EoK5NfLprN3BwDKCkz Rrs87tEzeiUqAjY0Z820jUYSgPsEbt19+7T/W91TyL64GJsgljLIejaYLnWECI6wnCZnFHF7FGyr YXhc0LRnlUhJv7KHx2XKRxVWIdzINz+hScLovzw2CVATtWXMOG4Kp6mCwD9KChwkfpTMC8QBGs1R DIbSZFeQHAqqoYICbUqAAgfAuTV9AR6sub6UAS9QAR2csQ9AAeyAASygARpwqAlgAQ9QAQXoARTg fjtgG4ciHVcAEkLTw/GzzGzn3UKMFhBC1bdQs6ZJcFlNil3NswuXTpHnX5pS1gHGBAWm1jM5iyt4 NE7QYMsaIGOsKniNfY8xaV7YIEcnWyTnx58GIduIcgTtN/aMNd6CxxJyJD7YnN8CxyaXFLmC/wiy F1lZQ1ALztDuCs+Hg32K7HT9JHXc83lKuxJG7GynHaqW7BwRTA/IIA9c8J+pAV3iAAY+EAE1HdMy fcoGMKEKsKlBfgARsNPKVQGlfKidiwAHYAHM8AO5pALu52TPIR0/c9/CNhVlAQeZGAd2ADBwINVb CuPj7QrlrcRQVLw5qx3qDaMzg0XOS1fn4by0KSq2OTQmUU9Ku2i2yLQqYQpNAyXcmzjG5pOG3K7r Op4QkpQ6aIxdqT57A7ayl89BJ78ZYq69Ap5wzBO7QiHnC9lqLOJV40CdZMjjs5OZzb2xrj3t6KO1 /gSgKsmshNoWE0IjveXNQQf7tgV2oJjB5f8DcbAFwR3cpiwBNY2oCEA6GrABLWABTI7CoRzLRN7s FtDBLaAwwVECQbAD/BYwqJoQo5K7dYGJwhDszEzERSkFbF4Ls/ooobhnC0HnCiczcCUzvlqCz3uj 0musM7nRkwF6OKkSu/k45rgJRVrXlaZj5XjGmC0hfS23rsdrC45AkTAYs5dQhlBJQgLyfS3qtody FH7QsiXIdQS+lUBbAmV6UUslvIXAM/+ejCaaaijjlYNl8mAMsRRU+sYFOKDj5KUCoWEHb3AFT97s m+u5CGAA0M4CLdACL0DtS77TFVACpYzKH4youf13eLcDtywapIEPXCAzKjFHgzDEbBcHAOP/zLQ2 CfIuC8SrxFSUZ5Hiorja3lJMHiAotIQmm4Z2YIE+PYJ+Rqu6xbzpnqY0wK6Cjpugtzyx1yNHng2U 8hQy6fOrtiCOlIAhpkF3K4VgdIFzLmdKFOCp6gPl6Jq9IOgYbM4KGU3DrKdUPWLwVxgnOTLuQSA0 bUH18/GQ42GABeWlXCOsBW6wAkWEAEHu9LltHL2BuSxQ7bHMDk6PqB+824laQ3hnBWT/HKZhB3h2 EfiRExCFiVDdzGi+BUyBODnP5jdw9+E0/8KTEMa799rccDJzKRyhMxoBCE0yTU4xToJPTDOJTzGM h0+QT5NOk5STY1JPY5ZmlpqZT55SoZ5T/2NTpKRTZlJkUmasUK2xrWe1Z1K5u6y9ZmdWv8FnrMS3 vWm3u2lTZ2pn0LFqv1NqzVXGxbXWZ9hqutPNscdmw7W9u7rqZ0+557aq7k+6ovPzmaVQoJOelvb1 /vxVcjLFjsGDCBMqXIhkocOHCJHw4GBni48rF30ogcOFC5wuH+GA4VKhxA0rPnxs4eJjxY0bU7S4 cbMDRQQLERBIsIDggAQSJHDg8IEiBQsWFlKsMFEBgQELFlBALWqBBZEfQzruKLElDkgwcezMiAEj BpNPsJqtUbNmzZu3cN6yVfOs1xqIePPq3evwyoe/H0DA+DBYMOHDZGHAMJy4sWKyZJlAlv+suElZ RUxgCNo8qNAhGYlmDJxBaFGk05VOc7pkb3W9UJukQMk0q168J6zarcoUCxUqeLve8XqHToo1ar+M WYEmDlm1cdOOQWP2bPm45LqGN9eOS1d3crVm7daUS1RtWLXZkW9tu1M9J64rjRkY8C7fvA3v45VI EWNKjCvR0QUXYHAEEhcrTKHgFCVQUIEJNtxggxUzzaSFFTtUIEEFTxlQAQ04oIBDDkKhYKJQO5jA 01NQWXABVCkMgdUQQuygA4EifSQWDIqkFlsuz7B1xRtutdUWXc2NcYV+TDa5Vxx/DTZYlB/EQJhg jBGW2GKPdUlZZIkJYtYMlHFmWWhnwfD/BCKbncbImwHRtxonlfSjyT2ajEJbnueN4mcqr9Sizivp kFNMdohCk902rJizTDN1SbfLct0Q84t3zTBT6S7LAHldcYWuI8oUupkxCyvq8KaPJ+rhWUpsrakS kCbyxYkaHE46lF+uCfFnBxdCXLEDgAYa2AUdHV1xkhRWTGECBS5FGJMbbbghhxtvuGHFCSaYcMMO N5BQg4hC/SCUUDBxuGKLLV4l4xBDcAVHGB91YcdkZk0SDzF0sbXGkGtdEaSgavBq8MF/gZDwlAwf xqWUgjlW1sQTh3kZmJ6ZZcjGhURiSGkg03eJyAJRcicmsc0JSp6vsmPqy6fc1ps6xNXs/8uhhRbj yzA4GyfNOJgqU4x1zST6jaKFfrfO0u+0EiipnsTiCiy4Rd2Oq/pyYifKUoixCSZSpObjJQf3WvZB vm7hH4BcfPVR2xxtYQVMMIGb4BRcXEFhhRVeK5MbadBAwg3nnutDiDVUoaIBCPC0kwU7vYtVEirF UaAXdIilpchTmxHkWnP1C8wuk9h39ul73XDY6lZW6bqVg1mZmJZaKtZlZZdNrMjFGXesppqKPKHm IZWoichZa47sJikoi6HJyc9zsjKeeKqiCqHoOZ195zcLtw4u2ODCyxmaHv3pL5qWA2Q65nd/c6jp XCoooaOikhZvUNcTs234yKYKbMyDjf++WGOr1BQEdbsqm6+UgBGMJOEKHenCgEJSIJZYwQYKksIN VrADH3ABCzJpQ7WuxTdqVeEGNRjBuM5FIhyMawptuIGGGOcUBDTOB5IbgkbogLm2icUxXBvfcvpl jWfE7wmmQ50SH+IXwFDJYQ6DXewmVqUuQUYzVsyMZcwiA41h5mOd+dhnmiCaJrhJbG7yx3xmhTJ8 wEpWmXiFeVYxx1boDzi6IZ2g3AG/RBUKG0nT2aWcoQtBIo1TnyIHpzDlvUKVSh268Q09tKcKVlGP eSfzxGru5Lw5WUJOPjpEEhWIwIn8KiMN9IgqR1KvjNANQyYYlg92kK0SzqRabVBDGkz/QAMUgCgo IhLR4G5QrSp4QEONc0oFdvAuHLKAC3WgoB1u8BjM+GMVyeEGNI6TG0vgaongXAgcnLiYK5mTS1cq SxRvR7ErZgZfksFMF7/Yuxh0hkxPAA2ZSNOZ5NFnbHIa4CdQ1p7/5UkUdKyFeaKGKvw5zWaDXJql ihYcihYDkN/r2SJ3ET5QSfSjuSADLXrxG5qlgjZ2VE8oEsqPlNkjgAFBTXw+SYlvni6BB/MVF7bQ QR8EC0cVRBZIfHADLlzwBldIQgk8mDcfzCQL1aIW37KQhhuMAEQjcOG5gjK4NNxybiaIQAS6hRKs tACHQ4gDHcDCBTtgITC4cxP+0qI+/4p2bhKZC6deETKDJz5RSumUEpdgR9jbXdEs7fwSEwRBz4+F 5rFnOQtAY4qar11ijXri3z3ao6f8dRY9VEsH9nqDqj4GcpCNLCQunFPR1LbWffPbniyilr2FVq0e rUAFbjeLSVhtsjXyOVka01iJJeLUYL6CA+WukEoDeUSCXKADA9V2g5X4oAQ9wMhObYlLaqWhCuBK IQ6ymtXB1YAGN/BqhbJgBStUob0Y+YF8h/BMZOXIIISZmPDSGA/vwGKSAdmrgA2iOnIuzHWGiV0V 8ysxiVHmYpSRTCEGgcX9YqaMYcznmjC8pkpINqZRsOzJXPOPfvQjZnLUkxTuqj31BP9qe+44RfdM u44ZM9IXE0WO+2isSFhgL8a8uV9uypNbqu1vFHJ8VW+zholK3AmNNKWEGQ+IwFJSpA4X6aBFIujc evknJXC4gg00qISVDKGW3c3CTNTQhjTowAo0EFwvazA4cZlgClWIqle7q7YrsOAHL5DvD+hFL3vZ 4S9bwqclpIcPQMmKeQQZsIC5ECWFuW5KDkvwFGFXxXZWLHcWIxMW99nYQvRov5+JhBlJhsbJiril nIBNZqPHp6nRUT2sCi1CXSZjW4xKaRHlI0hrBj9i31h+vT5Vi389i1XNg9dXO6isRgGQfoTCjZOI gmvWaNnKqpoSbDCule2A5f9cZAv/IvHISKLbEbVdpAtWmMEUxgwTCEr1llKlKoa04Kxe0oC8NQiX DdKgXqmmQSbM3YKghQAvONRBgt9s4sTO5KPeqrjbT7CppMPZV78iOp3pTHAVEyMYTycWixqD8MYu nKY1qWm/jwUNGYnXYVvRVD4VB5tlNTmPFO+WtvZrdFrqRzPxxBge7zi2aSFq4z6SVlB77O/L/vsb hOJ2atFO8vRidU3XCNfbBXwCOI/LK1/VQW2yZOqBQMIROvhnWFu4wQykYAMo2GAGNiiBmrVQLTbP JA1tVsFMbkCDgJMAqwGXwntx6XevwqG6wGrBDyRPhxwZ+tBSsthwPVmy4m58rwUG/wxg/xrFBU/R 5I65IhY1M4gumprU+ByeIVBNiFWXTHmT8FpLB3jtO0m7fwWVY25yI7WoGf1+S3sF/Yo9bNji+NjO L2kufiOeV/zmyLIxlZGj7TL+Ta/30gMbnSzhtdToXnk0bwSVq3xTU5Y7JRZBN44IBHEf2GAHU/AB fCVkAwzOwAQ6wDdt5l0HZwJ8py1WhVUvoS2A53ciRC1dsRJxIHnvMi/3RWBwVTGeMVw2pxlt9Xl6 NU5OlDDnhCXopBi1Q0UNFmFgwiMpF0+/sxm/gyak4QT89AQYRgiO4GG3d0YoMzb7wDxcJ0m7pQrp UTVTg1J3dXQmpSpJx4SGgmxI1/89nXN8TwMPV9hfgYJQ1kc11EZr3gcQdyJAd9IPGDdcPkIIT/AG YzdudoARsgRBAzKHHCESyvItNzBLQ7IFa9AsEnIDWcBmgFcFt6QGOvAAO3BvatBeezMTVUCIXpUG gegG86JWXPADPvBnPuAFIhEHH2gQmGY7ZHEmw1NZh7BPYgeCe7U6DcOKUCQ76FRYqPdpKacxFEYm Kwd7kYVPxGNGoOEmZgR2YzN+QshzvudGB7VbUFMbKlYKUhAzUxcozJgeTHN8UXeNpUVX7ZBr8TNk k8SMjqYb5+FiK4ZS94Bi38ceATSGtUJcwjgJamiDk1AHbdh+FGEHGZESKqFKxuL/EUJQAjYAIX8I d1uwBW+wBXnnXVRVTFVQAhUQgNQiQlHFN1VAcG6QZ464U1fwA0KAQ5PnA3TgFSKBEF3wcRYDRpvR OxKmigIWek5kaeUUkyL3MI3BYIaFO7rTgjK4XzPIMZuxT5BgTfQRjJM1NlHmUgO1GltjNdYTdLNF dJDkDiZlfLmmUOwQUvQwfbOVbMSRCbzmlVKXCi6DTbu2UNPmKgfVe68BPQRlD/BBQLdHMomwfux3 Nr5SESkhS/I3IMjyXFzwEi9hEiZQAiJgEkOiBcKiA3lGcG2GISjRXg94bxXSZpA4gG6gBUmwXEnQ AyxwVi0QXRWUEBLXaY5hJhRG/xYax5JLRGmVBkWuCDsll1+McZMUYxmg5oK/QxnCcybWpCZgpGqg ITY1iHtG+QS65zxfI1xWs1L5wJzL2JTleFIAppWNVpUkFTNSKZVJB3Wl9WuT5Au6gY5eGUnP6Ixz pFumwFt4AgViiJSaoG3X9IM++G0WFgmfqERklyt3CYcNtBKqFF18KSzfEiECaRIloC1zMyxSoJgV SYjMZQV6owXqRYgT2V4NWHAQtFNKAAYrMHmYyImFphBNRCW1+WlbBAOpqZpL1HEjCBhZAliyc2mK UXIll3qJNYoo93os55OgcWGM4FjyiDy2R5wxhVnxqTVM9nsH5QlypFLlSR7WI/819gMzCBVbLtNs DCVJ1oed44GVYJlro9KU0nmEZ2lQu+VSZahGGKd7cnmUZ7QIepWfTnKXwaKPPoAFz1VBfomHEfKH 3zIkKHEDhSmoeSchVnAhcGcF39VmA1gtWvAGFdkGhHiZJYAFb3gFcbADQ5GJ7IYsC8GaC2NyFAMD KjpgI5ppmEYlnGY7tEObWzJxXWKbL+hFuohPjqUm/TQIb8JqlHUaXvN11lZivqUJPqcJMZMPtPUK u+FZ2IRN+vClpZKNDjWV0UpbskCWM0OEuZYJBsWMm8UOLQU9sZY1YeMPZUBZ/wSPHrYIZ0EIVBCn bogFenhuHaFK9tURCfot4GL/Et+CIX1KmCUQsN/Sh/16ISLQf2P2iFWwBo+qBhUJeG5gA/vYEQcp oEUVTSCRVwrRcaFYoyj4rqU6YC1KTlmCqib4MB5Li7FaTRhjT18kYaZ5PJNgPGKzg8GIPKYYJ6uh e+HXntW2Wcf6PF1IR+PhhVOjUsSXKtn3jdyoa1SZfc92NZQUdE96tOs5Cs/6PE8gR9SDpGa4Wddk lOUXUySDPDboBCl6U27obj0FQUKlSl1QIPq3AxjyElshIVegAwN6A4QpAiJwElawBVrwEu1lAiLg AA/wAA5wsFqwiP5qA++1A1pgkG/BBQf5BuCyBXVQB21Djw7xeCMYijcQshvH/6Kid7qVdoKy+Rit KjEmJ6uKNYqtR4posl8ck0+IcBrxCJdNFidsSWKalKbDipY9t6RCuwrQSWQy5p3cSgvTiVDqEFrb Y4S5RXwxY2vA14xLijVLpnOX9ZarAWW4d7OiMbNrQpf46YYsYW7+2Y91CC5/ugN0i4dyg4cvEZAS iyHCAi47ECF967cPgFTtZQMekLgPYAIQepCVNwcaeQMm0BUFIiB5kTcvgV5XkLakG06gujrmlE4h YLIzenoNdpsnmnK7+TtjUmooWTw1p4ORYBq76m1QFr6cEGIA4R6a9T/2YDXGNx6dRXRxlCeygpWv MI7PBrVXKW0vIx7aZwqvwv+UxWuO/QCuZrg1wLeWAhVKNpez5jsQSwKv9mgQFiEsGfGfxVJB8Nu/ dtuveCi/8uuYdAtfdOvGEAKQ/euvO+C3i0uYHgChlVe/fItUPGRfGVzIEGG6JMjB5wRFKEgWlyaL qnebq2cIrGcZZgI8sYdqN8iDkXUJwUi28WGGwPsP/3Bt9tAqpKKktrGFo2BrudaFCNU/Y8nDQUt9 tFWmoUCOUnsesEI9P7t7auoj3EZ+N/dJNzsJH0ZGZyFgctokd9lU+dgRfSlUEmQHa2AD1nUFHCQs jglfc/OnV6A2jzkseoMhs6Sv/dqnEmKgbByYEpIEPWQ5hjzPIjqyU/Kir5P/z45Mm6OqejiKRVv0 Tk5QyTNY0B02e76pYTjYalwMl2NjBsK8jgOUjsF7Hrkchk6qrM5IjrkBWvRDNZA0CuQoSehJPRfH lNhmYgNUxaLgZF9jlFpczG5yFmVURk7wxWBsl6Z0SmR8bhzxn6r0KzYQbnYAB4PpLbGUh26sLImK mMwVznqjf9ysN/3aQXWbxoApv3YLknFwgfT81SLocanaMIAFo2btaSf5TpMsGaepo/ukgyyMyY9g Ru0qCRwovotmw97Le8wTvMObD492ntcTPVDDrLjlrZWkD06Ky89DW9HGnOoJQLIGzDfMRrkXCeF7 lKu2aosACT26CBistmH8/yv8mRL12nbqhitx94FgsBUl4C0dRMHc7ANv8QbhLDdQPSxxmGUPKiz7 i85a3c1XgCzRFAZffdzTFLoGJpMgRxY0SjGzOYuIBaujxtakSLu/GTxn0Xoapk8DYXt4DXbGScw8 J1C8pWSMRrxIRtjo7T9EiLyxvL1Ts6X602gtpWJkENkro5QChaTBTCfzIVyuJjKVUHsahjxMgL7i NtossTYqUYf1Sof00lQpYtr12hE3EMDDAgdq0+FlduEXvhJbUKfkPCzdPM5ItQNJYIEFgtxgPbKJ TKKqml+ml7IjbKIop0UAHYOzmzEWJho2ywgGbrZEeXMk9pa0wkbjaoZCmP/ecCQb2WvSgg3LdoTf xtoyl9TewfdSWN6enCdcneQEX+em3iaklVC+ZfTCiBDaoq3T90gH+ogSE8tuddgFPHUCS6ERIN5u lIO4EbKvPjAg9aoEeaMEZYaneHrh+/ugWRao3+wD0QSiLv7VLrncrhMYIFcYEMO6nG6jJvcluSNq pLZy9Qk8+4WKwbkIv+iOURbTwPyrpCyE0fNSyblST2DR+aPKsrKlUW5JYMjD53jYKm1tI3aMtL4P vRzMDs3qQxmUOKgIapiKzOyGYMBc7GvG83fUGXrhZZaZVzAEV/C/AHsFWCAE8lru357oO6U2SWAR O7ACAhu4evOg8rsCHYr/OV496YW8wX4Fk64pRZ32yDbZz7j5aTCIi1gkYSkMe5wx15Bg6mxC4CVD YmzabWs0rpsFG7E261j8s0eWtegJhoEN7ERbG6eg3zecWdSGjOMa4ON92adRrjMFUMe80DbfTz0S A2ze5gq00/gIhxeRBB3x08bSEnveQHqeLIYbsAGp4luABYR+9EQlbw1CAa89AyLwjA9w23erAibA Aj4AFmKv7/Rc6cp9YCLHaSVHkyKssl50MTnOMQuv8J5hRrg6c7OHfv4E3p3Xq3o90b91Sckphv49 a4ymtSr9P8toJyWtw5jk5LUehLzXq8KV5OzR9zItNkOuaDSNPBvXzExy/5dvqI/+kW6m/1yoXXlt MxITXq9EpdvMZeiunyIcNG8zcPt09wCvbQMHu2KIe7+DqQMp8gOWExJkP89bYM+Wfhhp38irK6rS XU1lMdA4amo8CtcfY6txvWE07ep4PRDcppTFyXmDz9LCWuvn/cumslmML7yJr5ZqWYzit9K+VSvb xhptmkab7TGW8IvbPXOA0CTTtGVneIiYqLjIaIjUCNmIxMNxuOVj5YN5xcUF1wkH1slF59nVRQrX BUfXRRfXSgdXtwqmilqqubODaTW1M+V7U2IzM2MDNcXwYFNitVKiYrLiwxVnGxapvc3d7f29TfMx Tk4OAzKOfv4Bww7S/v8Rw34OAyNvPx9jXx/DtN8Po0k9gf36zQgoA8YThAIXOmQyg8kTGU8gVnwy w8mTixclctS48QnIkBtBjhyjcUyUJ1I2ShnT8mVImBvNPKFJ0+YTmy1p7mSJU2bPl0N/GtU5hqXS oEmVOl1KUszTlSJLWiWpMetGiSabVB3kpImTGRUzCtoILq0jtYwmVTK05UqPK5qEjBr1Cc4nUJ64 nEIVh4soOF5IeaFzOHGoUNdUXYOlty+XuHF33PBx5coOaCt2/LCFGA7b0aRLs91SLvW4dvDavVv9 ml67e/r22a6N+x8Tfbth7P5tcLeTGMPDgiV+ViLYsxO9Xq0KHfpIkjf/nbScmXKmS58+i15HOjTp d6Uydd7sqVTnd/Q8XW4/nzT+0us3Nzatr73q9KsaLVIUu5FCEWEkkUJMcGEaN48kaIdbhyihC2Y+ 5CXZXVtMpsRdn9jSmC2rnLJYK4SJGMZiXSQWSxyizVIHHXXUsVcpnTxmC4M23mjjDaqxo5o6sLEW Wzz1zObOkLkBxFtuAkUUgwzEBcdkcU8WJ0gTA5o14FgaEceRRyaFpJVU0zlxn0sgyWTfdfKpKRRQ 14UHVH1v5gTVTz61V1N9TdFH3hNSRaefVVpphVVVXoUF5qEzJFeWclY+gSMkCybooCFc0IWJJlvs NRgpk2GxBRZKXBFX/ycfeuLhX6UgZo2HJsJymImhqOoFHCWG8Qpojf0Vaa++esPFjuasRo48PN4T T7Ky3cYsP84G5Js+SPZWJUMKKYScQ8llGeATAG5VKH/UUUcmSxrZVC519NGk5lNowueUd0nZhFOc LalX5rwhxYQfutXtm5QT5o1LsFbfgkSRRFh6BNFYEiHnBIK/JjKpaZXawYUPvGjCCV97UXgXKosJ 9kmtqVpDCi6KlehqGDSqCKMrtYzIBS2uHObJxDrvnIiOwqbDIzzI0jNP0cjqw86R/zArELQCDRet DML149C1D10JkZcxlCWSWSJ9C6aggIatXRkbSeWTfXHCtGd3+t6n3v979L3bNlEAq20u3tiR6++f g0IHtkQSASgWlxopNFxZxkHB8yEVl3YxGHThkIkPm17IF16oflLKJzPfjJgs2Myyl+Z/fW6rrV00 VmLou+pVYh2Nz+4rHDu2Ro6P4xhLpDy+P/vOs8/2hqQ9vUE7ZXBPZj2g1VRShHjXg3+5EYAj7Rco fiLxGTbbT5FE97h255m299u1S5J87pUr3nvhYj/2c2FpRNZYE5VkpUVZEzigxI0/TpqL1SFTmrBC hiRjC1R5zC+dkFFfVoGqxjAGDKJTReZC1goNxe5DqQMDzkRDuxDiyAc/K4dreHSsoBmtSM4SktKW 5o/aEAQ40FpIlY7/Q6WrXSQii0LYobbGlXBB509kyw5I/qQT6kmFJ3BzDxNJMrA07csoUzRKS6zj JzlZBSVVWUl2wkYoMHqrP4lK2EUUAhZtDeI4UwghAEcjQExtbFMkqxDnGNg5kaFMRqjQY2ESSJgJ hq6CeJFFiVI2wRFxrguyE6EjTQMHEfwMHsR6TdDegcl6JK1IQnLWCwkSrd70Zo0AiRKUmLc/A22F LBbRyMHG+JEiRgd+z2lK+56TvlyGj17tKpNNdOI3WxaMYOSKX6AQBTaHYWSVBFrltubHJRG+kS0X s4PGLuODy3ACcxeUDCpQhQu/sIKDoIFgJzDHzbs0UJ2GSd3MFHOY/0fKkzRXKCGxULgO3qkQabnZ R/CExyxp7UMgTavWQlCJnDV6xWpOMk5HMpKRJ3DJI9LB5djIpBGqXEUKJ8GbGNp0HvDdMj9zyuUU sfgvjgpTJAH7VzHDKLazfKtAVWkYcQaUta1d6wrStFE1L4WZHWBKQpTZwoU2RKFSQNBzIgMDiMLg icOcjoOS4VzqVkU6W6SOZaooxTy/ypYZ2PMD6LgnkHqnQqLdY2lL00dBQzlQ5PXGhlaz2v5wej+L KGSMh0oUov4qtsCmb0z1ycp1NGrEkPjtbHnjKGPF9YSVrFQj6IMp9f6GFQBRFCR6hc7+yiIWHjpq EJDqKYOqeYgXff/iQqSSEFEzMxl2hqIvpQiMiVKlilCYLHUwKpFUa8UyWLXMVo0Eq3G/0QVJpoaS rSmrsYbFmmQhzTb7yMez+inQ4jFpEHVtCEPW+LDEQQRAiNuaMgVUUViSTVxjKlNU9FYV9EBlXXi7 oi3f9aUyWdaYw/RSSGRKEf0s6j8Z4ZLVDAoRELrRp5TwhigydIUkWM4HQsgMqUgVqnTO9hYcHp07 EykzvZwMRMU9ronT4rOx4jN46sjkPIIn3aQ160j+gJYoAfLWU5oycXY1C2kb5hWvBFhh/gXXl64n xEC5Fzr34eIs7UPYPaXXvTC16DH1o9mwnYWzPl7oGY2TvzM2KiL/bXTkNNWCWm5M5gqjGpUm3izh 1l54CB1L5yjsbDq/hKHEJ+4zaeogVntS8p74TCE+1tpC7Aa0rcS7FnGs5d3Cgfl5Qv4aRWTgykw3 k0tf6zQuj1wozEJWbYkNiUbXK8vpOHk/VZafVbacP6+5MmERZWXzJCqlxMnzzGlJ8zY+lWEfmOAG JrDMDW5wgh3gYGOu5UTpPCdiVijYz9TG0RWUqxp4hICTZCWSWoPGjxjPeEigvHEMQ1kQ5OV6eaJt 93DCK5ZYa0m9ZOSPc8KIZGK62iqOHdcXxURqQBE2vfudn7e+lum+iku03aoSkBUKcUGsYdcMfss3 LiUEUNHFMicw/8E0brACZB/bMsregRKqjXJHpljFhMbdWdXBGtsET2mK3seN67EQJvmDrlW7mqQd krg0xhtLDnVILBGl3if/DSROTq8YUY3LlhYW6qEGV2BD27WeTwlADMfhDb/+7jI/ktfg8LU2uDCq LfzgEicgtrHbXmwU7KAHdFd2IVKO99lh+3bF6ns+lRW038WmNjIekiflKi1zIwlqX2fIusV76+IM WHHOCSJnn470VqM6XU+HckWRjO/1Lp0kr/QIgP4DWIR3a0CkdV5CJV2QsXyV7N8weySAzeZsDtvj Hb8BC0a+7GXPJe/E31mwWI5CExLLd2mtx+APL9BmNS3xuPkNk/980+6pTfr1RkdcX6+0JaMLvdMF z575z4/+JIt+8wcn4+U3wiVZb1ryjDIQD8PCwypJKacTnyftvWF7kMAFSXAFQjAqOzBsIZeAxOZ7 yLYLy5YExSeBv7JywgIPPoIsrxEkgicb/MQaNRd9OMYPv+Ek0fJuy8NuqDRgsAdmFAExA3IwivJK B8cVzqF0Vdd5YkMooraD+INkCsd1QeQRg5AlslYlzZE4Ldh4OxYDYkdxp9Vg4HApoVKAOOBxV3iF DLgDJ2CFWxiBEwiGODIDDKBigzYslxRdMadW18WGtdFoiRdXguBWTmJ9U5M1YDdR96d/zdE1yiR/ XGI4meVKnnb/flWmeRclcFZXU1fBFfWzEQGWLVkBRM3RZbSWSo3yetxVWrNXceBQB1uQBARYYZax e8PAgCYAdyU3F3z2DS/CQH5xCi8Shnl3fCx3VrtDLGjFfIlWeP3EVjkWLQMRNQKhUN2lUDyGa16h Pys4FvEmEvFncEDXQ7FUUV7SV5tlfqN3EYNoZPcGLn2FOGSBUzA4bwrlY42ChDo1ZsJhUDUEA9P2 hJQShdtQB+q0BUoAKnGmMW/GC8z2ZtuEBaDAiopwCiHTR33ETgbJSLI4i/NUT8i3XLDRbWm1SR1Y kS+UXSNoPMjjNDbWJARVjD2ngsyDf0qIeli3V3/FHKTVESSB/42JYnWE42kUhWVINj0l4Yh89YNm xCWaZWssqH+vBzVVUy08ZVz/1w0BiAixxVoZdimTYTl0IZUckymZkXEXgpV4YQgvUpCjACIJFE6n 40BemZDstJAD2ZA4cgNkyHcolIGFpotp6IH40Cx1OX0wVDwL8ZHYZ4dMmGuSdkPeMmQFpnpJSBaF CX4XMWSw5F+XRXDUSHkYQT81aJjPmGuCKWbHeFP7kzzD0Y50FRH24IScCIUWBwlwQIVPyQlslmFp V4CvWSp4xmG3YioK1Fu6dQpSdTqSoZsZpEffVJvAWZZ/wZBpWRqBZk/bdobJwpxp6GKaRBvQaSRt qBscaTxJ0v+X1mJDmmh/l0hTzENe/BNa0ESJMSiZYxRRATY/QYYoptee6jU4FIEo8vkRj0JGe/Ut aySYQnaExwiYx8EEEYcQ1vcE8Oh/nXh2oNKUSsBadBYqGVeWeOEKdlCQ3+ROiAEGgcEyJjNVX9kF LAOL63QKotAFtgCWnhKhaKcEK8qiIfMixWmcjZBcEJkOuMMjrzE0mTQkM+d84+YsjdaRiHedfal9 OjZex8h6P6c/fCh0kgh0saSMmHme8kkWYFE/V8ocrhRRQ/eMNbUoEWVTKkml0/N62WdKPIcQBeEk BXpiSKkg89gI9XhOo7CawMaUfZFbtxmcvBUaHtRBNBMaJTL/VbtVKx36F6bAQBVakEpVR3c2p7GV IRfCoi06Cmg5i1wgAmxZQjZKVjcaXYaGVj3aSeMWgsF4neoGLTBwELshNcqTU395HESpTAmlRuHp glrBQz1HEVv6njoJk6nnPOhpaWOGcFYyPysIoGYqOMrKhNfyqlTQZ266DUrpqE+ZTnamCoL6TYCR od16CojxrSgCXKGDIlwQXCbqBSP6lbVSRxs6W11ZkJ6TkBlCrwdEqZjDopfgPzFqBxVYhoWmLBu4 Tx/YozUHfXFFXaBEV+l2UNmXiXiYjlRyrCVpXgCydeQHLspxP81oP8l4acbaQ+ZlmT0kU/ZDU/o5 XrOahEFZ/xbd9W6m5A/VgmOjeZQIyghMGZD2SCGkA1Wm0q3XQAe3MkEv061bNSLi2gq/FTqr4K4e BK4JhDO7BZYlqkApGluOGqlQmWw/wK+IoCOaOkk7ojtumULTdTRGYl1sRV1KkqrT8mjb6arbBZJB SZ725xBC2XPeN7IqyIfOaEZMYD8q6VBkVLHztplIOI3bQlNgpqxE2VDBoaoQoW76QLM1C4UlkAgv ckjchJpc8AZ42hdgQKGb06eNYTJES7R18BhBa7RC67pGW7RFCyNekCqtkJuGWiGPyk1Zi3a9m00s sIX7yq+ABpHGgiwTKbDRFZ2cxFafVJ3ZFUPnlm5ydS0OJ/9aKchw3Rl5PUlrZ7FXQ3go/Ak96Mmx scaHyEhrkIcoCkG3QvmwUnM1dmhDOZVT0MJd/QAFdEBt0np21WAHXHmoaKdxmrM5TnULplKQCdSt S9u6s+A6YMCVLbK6h4G6o/O63XoYtzJVi+FUUyUKVpuQGsMCPaBsKyC8w6tcYCssyhmRl7RPFdlJ 0mI0wlOqCSuMBRG9yjOUafqqp9SZW9d6uIYcWWJgiItKXXo4Opkl4ekokam9gzvEKfvD+IdQL3st cruRdLUkBnpc/BsJspMYh/pNFzYZWVmbe2GhDGQy6cpUqgM6ruC6ufIyrIsrhyHBGUqueVyuu0Ku GHwLh1r/OuyEZxpTd4V8wvyKqciHO8aigWSbhkLCvPrAo2pLYxjJkcRDLfbwskVaxUAMdnR7t1Q8 IHm4fUm4NVYKnvZTXooDiP1xa5d4YERIpD8sHAOaPG37BEa5vzbyIku7mxnTAwR4BaBypwnpVAr0 xxlKMuQUB0xrtHaAx3XsItdAodegubYixz+rzTTSQayTMof6wVa7j3NHyHTXA13QtYqABR+gwoqc i4BHD885eGk7qmzINML4VpnsrKG5eLGnw8hRV2PWnSI5IPE7ylviyg/nZaG1P4E50FbzJHmLjtcC ZtVbjJEmpOn2G7q8y7wsOy7zs4e6okPwZjjwZhJyBcAp/6/XAIuz0kG0y6Gx0MAlYge38gp18LMu orqiKxp4vLqve8HN/BcJVLXsJAT72AM+QMKEzAuWGqMP2c5t+QEsXFaeSpFmu0nRSQ81XKo0Z3Nu FYd0uKowy4QjeWt2JdF3RVPlJbFCyXBHLMWUJtfv2xBG6s+tGrl0SIdxFQMc3dEJ0kd2oL8vKjsZ WseMYY90ZhejMBiDscEtDRqtAlwz0yIowluiCwvXLM2xs9kOjCJv3CGmKxjqFM6XgNTkTHdKrQlO HaMktKnZ9s76pIHeBsnTJaq14aOHZxu/cckyNII4rA8L4awouMk6BXsSrb3tezhHGMvxS9DtC1qU FnEhyf+XOne9JphuM4TD9mAFeefFkvIDJqAIjSQ7xTXYgu0yDCmhsFihG8I6hFG0rmAYeexO0BwH MJLTquUyQQsrdJw69r1BOE0jq2PAKOo5pr0xzJbg+5jOjXAFbBnVwlLVZpWLODqw/1Qb76DVGUlu zfvbN8zbq/okk1vcm+xo7ybRdPt1PQer0I0tDnXEAS3j7ehdRAkDUNMbUpKqM8Q0letn3y0JcMoI fEbe/ys7eLY5ghEYfWQiG3yu3WwLlc26Ar7AFOzTdPzAM/2ntFubosCPEYLU+6gJX9jgi7ADE26L leQaQhPb8Ax4tu2LB8uRYH2qxwPcG1ktPE7WqdR42/n/dRDH53Mt6J8Z435u0Z9ZvTz8JNyl3dSL nU1YfEDeFkKuFnKqIexkoqpgC7TLwaHtIXocOr0lxy4i2J4u6rBgzYRttDfzFwc8zicN67F+cmXO CK4d4ctpgRPpDlctGzAmwx1oD77YT3eJsKA0pHB4EHJIghidPLNc4lXSbl/HrGY9kilo7cUNHIxH h9ltPHvN7dLi439tMZSuFh0zW6OdWwkp30INIropqCliotwcO8JmAj2gBIxkCA8MtJ/dy1J+GBgM VLEu5nVBYQR/yLRuCDeQwmnuwi4XsLT9gZ0Uw7NBnaTatnh+8Zn8VnpJLRdN3X1+6D1cHHaFvZ3c w9Ru/+1rdOIdyV3XsuPCeJ1SMIGSvghK2Q0JKa9TOzLqdAseBsFcUBir3qe2sgU38AAQEAAAoPQP cAJJkCE6/b+sIFWgvjqtYNpHXYCYUWFb/5pajykHj/B1sHK3rmKM7HIWPjQspCxwbs8hKL3S+9s3 Zy1z+GgiyM8n/885ddGJLqtxe/Iwi4L0y13AQUOCcKqNnm7IHu7VRvOKYPPcwLmMjUDyigsyc8x3 ETqe0Aqjc/mAhCsw0gmaIAJKT/oC8AD1Xg2vQKFQfg1doAsVVvBZ7wMShvVCkARH/WZgj/D9unc0 2nL3pE/KKyQslmh0idvCrttwWDw3fMmhSVCO1qpESv/Red88DcGdWvy4CPX3nBwRep34O9wkmazR vi1QxLP4jG+zpHFAmHOiuxmWiWoiovO5qGDf+B0YSD7aCALHV3ACD+D//g8IEACDAA92cGFwdXBg jHA+Wz4+SUJXlFeVmVdDkJKedXahoqOkpaanqKmqq6s3IAwfH7CxtLWxMLcfILe7HzC7uL+4Mb6+ wcPBvjEwzMsfy8sw0dPMzdbUTDHZzE3N29Lc0tnbT+LiMTLa6N0w5e3gTjHxTDPj9ffZ8U4w3eXl TTK61UO3bVu3gzDwLSuojok5dfy8wfj2hAqrixgzpkKiURUSHhw6nuKyhYvJk1zgcAGTMiVLl3C6 uOT/EoelF0Z0UnbpAuaLES45t9zYAankSR9XUt60s6gRnZpcrvgwYcJOo0SJvOT0tCWJDyFJwlLC IoQsJklnfYhcy7ZtKisibMmd+yFEsVy8aOHyBUJY377G+hIbpoxZYXCIoUkE122awYgREUKGmC1g QnsRB45rN04bv4CWD4aO+O9zt3wRtc14B3DdxIXLEEZj17iaZ8UJLbrdzZYj71AfQ/I+qbIlcZRd YnKRmRzMzeWMkms9uTNOTi5KktQxKXWHVEwk6WhNJJOkykZdcsK5iV78lrNht/zAhMksWK+evqr9 zb+/Kh+0zELXgLEAkwsxzxSTTDB/GZaYMs8w01di/xTiRg014ECU4WOpMfQaagLRk1o8oEEE0Dva pBPPazJsI09s75QGTmfnTBZZhsw8duETV/jno0f9BfdbFyUZRRJKSLJ0nkznMaKTSWDU5IhzQV3x 0k5QcieJd0og6aVMVzKJXyeVDLFJfWVJkglaSfzo5o9XxBUggXfdtdcvteyF4GANGhNhgtIUFiGF 11hToUMwQnYOooiu6GFjiHYI40CvQVYORCsiRClA5DDmjYnhTLaZY6lV+FqPb6Yqim+/CflbUic1 YlJQThan5HLoVaekrMl1IeWRScTR61PqxQrVFZFI8p6RJhXXbBdCdGJmdlsoUeZZyeLHBViqdrtb nP8C0ikug3bykgwxgwEazGDRCFZYNIReWGiNOMIm6Yj20hZqa/k0tBpCl86j2o0R6bgPO6De9mmk 9s7GzAxceKsqq7y5ytsQJ73h5UvHNbucx8thiUh0KSWCnVFRriQsHV0sInLH2fngXVFdlsQSUpBc MkQSm8iXrLKSkORDxBIXLdINssQSLp24GKgLXnseqKC67iL2J46GxmubNS7uWynCXteo76aLYi0b ZN8oTONtDJdqo4ZYL5TYDGwY/SbFu1m8m0nMblGcSoDfmhNLza2kUuFK5eQeFz5sd15NySUSZSNU podccVgkQZQPSqgUSbQ+J7FFWT9H61USSlQ7tN3/rGM0gy1Li5vLXoBNrSBgDC7I59bFLDMhhvIC X2/WnoFtI4f6ikowbIjqq2ONEDU0o2MKQ+PQ8OBM0bqbeLult1t1MMvxSxxnGTh0HyspecjJcdeI HeWhJB4jwjLCHhwsk4ySkZ34/IP/nrCEsqyFBUls74CquAIsGNCLAsluL3qBWizQ1TtAJcgZ6wIU NIwhPEIZCngM65piIAWqDTkMeozSEMK6tsIZIQZsaUubRKwnPO0h0D/da8v33NIlkB3JKCVxRPpa IpOc9Ko8zTlPSa7QBTt4oGX4s46zQgaG5sSBJs55BEkWkRTP8awS1uoZV/SDCSWYsQfauaEaSxGn /zk90BYNfNqdIji1wRAGg8jgoDD+1EHFkApDtXnI9eBFyFGVqoWJglEiQ2gOSG3IhIXq49xQtcZW BQkk/SHSkUAGOC918lZF/BjLdrIT5TCuDnRQApaYkx6mKGeK+YsSJMjihZLsBBL/+58ZS5efkykB jZUMpii4ICelyc4WuAhBMhxIGEDhThfHuGAG7RgorWHtg9gU3ginJ0MYWs9TD6mU8gLpRxsZr5DW BMcM4CBMS/Jnh25hHOqKxLd6HsmIoLwSUNJXHCwxyyTNkUkcqhIGOtThoC5DkhKkspykJCcTovtf EtCYn0hsiyw4UEI721kHpAkodnSBIDLrVCc9+f+JGBPii4MCZcfdedBC2NwaTGX6wmtEqlQuitQ3 akPOGM4LpuSMqWKmwM6N5u2SwunPdpTAlZMY5TrHuVWtoMMcyjkrJk+pInIMeridiCerWP2YSZLA nHnOkxNqkkpYUkcWzhl1o208JoGaRgvAAAalyXgmYViqLgl9EELEy+Y1/+jCC3XTVJAsp7ygh5iu zctUGJrBFUDxVu8hVVVeYJwkROclIx4OlCuBCfuO1AgvNKIp1pEJ6sA0MpW59m8eu5aZGKeJr1TL Wj0gWmWFScyk+faYIl1mSYvxzN1NzTAUdIZL2YWMDiI2eOmEKdvsNb1q1MaxhBwsYrCXzXXu9qj/ 78SkxFSrrCCiRFYkU86uOsk4oERuZFmM0iHCgIWxdi4MdogVImIVlW0lRQhROd3QzMhUHxT1u+28 gQg+KteQ1gJBuTCQXhuU0pUOal3NzeB2MfRcmlLjnD8VbHazG7cQa9NQMyAqgi0b3qQaTSYFtK1x ADqTI1KRJEm5ieTSoxX4pscRdghDVDhnkkV4TCVgqRbpNvsVLJREEl5YsVG58DoGA7cWvUiXBRek Ur1eMEIpRReGMTyNwyyWxLh5aUwjueHHztSaaJ4XCCAmZRa3SrwH3E6MhfDPGr+yPCXJXyKkJLn6 mVZKkbPDU7CTuqF97ApmTAJJfjBAkqCVDnU2/yocFNzgAYkUyxMsEAT36uXcnSt36WopYOHV5jZD d3jlFCpk2QznwPpVxZnuzWUruR0u4Me8SOLJPl0COTpMDr51AANqj40rQvdziQDumUWHsIUY57qy PojLAo35xjzNbrgWrKBfxq3S3WEwu79rxrtkTeI1s/uxat5arcHBR19I9to63PVGt6KsWXkpYu9l j5QWkYg6+IpyNZFSaZ10EiGk7n++hnhSWEBJfG+0o3ICaafn0rQ7AaMXXNaduDXcJ3ULg6/CaGk1 Oow9DgeWw2eWdTXTfAOL57vFCM5ssmBVLIAi4qsEh6/CEf1V9rxs0tU6Uuq4MIQdaNTmlY2rb/81 znE6IgjkeFnQx0ltamda2HdjntB2wZFu58ZZsCWWJKEmdFeTP+PeUF9LDnuD5xVv52eBRqXH0oMV +k0u4aVV3E1CSZLUURsL1MbOFXIb9+9y+rcbH6lIPx5q2+3x8m0v99UQI3bcUbAaXufjyWEu87Gr ne0x9TwMbNh4kcxd7nXPNXmJbB2TnQTojlj2yHYcPzNCmtFcwAILdNv6t1LZjVRvsJaz/rQEHXfL Kj1uusJcGLGDXe3VRD1zB5VulvoV84ZCvYKmEQI6F9/1+oZ6ZpvaxEV3tQ59j9Io58ckMCRlC9Tu ocyaeP7vxknbkUdScrFHovZ80GQg5LZHn0f/ffSGXCrlV1eDO93HattXZid3coNigXokU8UAd/3X Ea/nerHHG5QlCpR1UExRgiX4G9tBaf1WUL9CbMcmOU7SBYYHK8kSZR/4XXVwBR8AgMnnaXgBR5PX ceWCJyF3NV53amHmgCYnL6EnZjOHDJxXKEsIdl0WDDMgWQe2gxkRgiA4grsBADYIATsBAZwDAQ/g Az2ghjIBAFXxIwanWURmUHr3LDw2Py2ROvrnA5jmhQiGcbXAQEHINEO4TBAkgbeThebiJyl3O9XE fdGULlQYU4LihJKoIFaTR9U0DDNwA10IiBgBhhoBT21RB3BoAhDABap4Aj3gAT3QAQ+QBGt4/wKy SHxyOHuSxk7iISsAJWwlkXhotIKiuFuPUEwBKIQNtHXM9G11dC7QBImOGIHqdm7UGH0YuEHW8IDe V26oplKShYvFeBGk+IVieIoAMFEQ0IYQ0AGv+IqzuIZquI4v5mueMCuoNEWF90tKQIzjuFtcoGAh MAvbFnmfZjsRZITMWDuXF3rjJoF7BYmnRjV+RYnm5oTjpmHH8Ini+I+sUI6jeI5tEQDb8QDY4QEn wAUPMIs9sJI+0AGM0wH+6C3bIRWS8APLQQfOsgU98HQeWWdX8HjJOIBE+WlzVC4MWUfPlzuO6C7K dXnKFRgOAnZcZkcV9mV+8YlY8JPoh3MSg/+CTBGWwTSHbNhvPoADHcmV3wUHOyACD6A0AzmUdFRX zYSEWZZ1u4BXkEhh0EiJz+cMDJiAEIKFqQZYCvKJoaiW5Jh+ipkKY4U6jYlvcEAFyAh5yRhHVWcn lHeUSPhtEZk7fOllhekgJTd+2HhXz2ADVJCYkbkKIEmOIllZ+NWatHkRPegK4VKIhlguxEULEMaZ lWeXJsV1S1lBoyluxgl9DQkDNnAFcVCbpciY3zUVJoACktAyMwmd0LlpAMhtuymAcoF1oyZH0ZiU c4Qgc4SaCoiNpwl+S6meviACU/Cc2hmdXillLBABJlABFbCf+2mdQ6OD9amdPjADlSmXtSD/A3MV jcwnRw3Ucc/Em37plx7Xl9H3TB44oF8onbtFFRZAFf35of7Zn9XJAqqUnRr6jwEJhEN5kMTlos7n fIgoo3qxmQyJdQkCn8vpjByZol15Zy6GYBGwkhHQnyjwnybwoSQ6otW5Oj6qlgH5g26EoLFgF0c4 l3hSgOWCnocoNUkZYZpZeTFwAxX3pBt6nwjWBRVAAIQgAA3wAEV6pNW5nx96pCLKn9UpabNppsUY lHGRcQEIowvqjM73oOVJalcaoUboCzIAAjJApnyqa2j6XVwQAQxACJg6CAQAp0tKohVwpCjAnxUA px5gAj7wAygaqVBHB1hwAzYAAiHQC7rp/2BC6EC2Gly8CZ5HeaPhFgMi8IlbQJ+q+qMVE5vt1AMV kKnKOggBIABwGgGg2p/92QENEKJMugI4marDem1RIQLeKhdW2mlH6W0k5TTNB3J3mYjjOkfl94lJ IazbSqx5Y6zCtJ/Leq+Y6qwPQBVH6qlUoZ9KagL6yQKNo63xumIq4QMKJgKYSaVEKYBcNoTRZ6t8 8YNbSAUpcbDgBaQdAQdvsAZwwJpvYgIPgK8mm6+FEAH6Gaqhup8jIK0C65/WmZYaW2fcsbAHKq5X 9p0JGQIxMAM2QKYZW7MVw6GnMAVm8ARmIAVnwLRmcAZr0C1cUAENcLJWm6nNSqrVCbNcu/+fRWqq LUO0FmdkQbmwcimodGGuD/qrNyC0NCG2QWK0pHAGSsu0U3AGZ6AGZ2AFaqC3UfsmQ2ACVzu49xoA zxqzFvCyMVsBL/u1+wG3+LYIMVG2v5qzdcWzvLkXPruFNzAFXaQIkPsjr/mRxgoHT/AEUgAFZoC0 e5u3feu6Z/AmU0G4tHuv+vq1TKqfjNufoVt8kosFZdu2Bmqg4co0lcu5Q3EDKYE/Btu7G1usQUoK a/AETpC0q+u6fbsGarAGfKu3aiCybiGwtTu+JisAQ/qyFaC7JkAAzeu8cRcHoIBQYYlQ8Ru/7otA o+uaInkFp3u6q/u0fru9azDAA/y6f8j/H3UwquS7wCYbAG/6AIz7AO17vxRcwaaQvx5xjqbrBHXb tHnLtwO8BWvwsdvLt3jrH11Asgy8wvgaAEVqCBYcwzLsmkY7Axx8umPAtN47wB/7Bj78sQWct/3h A8nKwkacqQRAsnE4w0zcxMDBoVTABP17vTrMw28Qsh47wtprwuDbEUd6xGA8CPtKAI/rxGZswRi8 EWLYDjfcwSU8wleMxVm8va3LH+kbxmBcpA1As2fcx2KbxqiwQ1dAD02AutfruiOMxToZskD8umZw wKeownhsxP3Jvn58yc4LyKewQ8tAvf2bw2owBQJ8xXaok28gwq87BX8bT1Q7ySwMAQIL/8OYPMt/ LJ0T8clMW8VqEMe8yMgFbAVnsLS88QOC68orDMH7SsvKXLOafMGxdwXSEBBOIAVKe7d5y8Mhu8hX /AZ0HMpjwBv2aswMrJ8C4JPLfM6R2syl8D1ToA1N0MZLu7fbewU+LMdArL2hvLpdfBHiK84LXAEe QAD8h84E/aTqTArfsxrM0L/VDMDb+7Eem8UkDMzBLAWrvBZcgAIO4M/kGwCxXNAg7aMHPQrfAw3+ oLTVjLfZq8U9zL1668EWHU8owNHkKwAk2wEhndP1OdKrEnuI4cmnKwVIC8zdq8VXsL3ee7fUHLtt QcQ0Pb4PgAJkrNNUTZs8DRyxpwz5gP/DUjAG1ozUINy3SW0GSzsGZerFxfzUVxsAANABo/oDVR3X innVdpDQzSDNXL20h7wGsJvPTUsG1HzRHVEHkqzWax3Bcp3YP0nX33MDnsLQUgDYeFsFeSvKZ2DN SCsFXf0E+6wKGc2mhn21DMCfsqzYpu2FjP3MxhAj8CzUT8u0l/3aZqC6/dvZqUDElxraVovMKHDa vr2DqR2kcABNsQHPKA3T/5vZqNu/bvHFum21+vkA5vzb1A11wV0Kt3DX79y/1EzN8SwFS4vSYxDU 4RsBz2216UsAfFzd7I1g100KU3BB/XLD4520QT3eDO3Jto0KCVyy522yAovT7T3g1/b/3qNQB9nN DQEB1Pc9xad7w0wg0wPw3/iKzEtM4Bju3hyKNBFiPQvexvndv/Rw1hoxFQJA4fe6rxAwBBne4t9l 4KSQJ9bgD1LMwTZOvVLcDrsRziiurHo80C4e5MIE46OABeYCIwCR5E9AD9lwKUwwwaiAAh7ArD2O qelb2kKe5WpE5KPA4au9NY0xD6uRDSSuEazo31VOCANAshWg5W6+5XJrBxyelxSSU+BQ5hrxAyyQ 5pkKp2v45oC+PVxOCj5YUi63DPu9CrPL54Twwiwe6JBeNINOClxQoxrmOzPQH6HK6IRAAUMa6aDu LZNeCr1FlN6FwIXN59UaAR4Q6q5+/zdxbgpbQAVtK7Q/ktFozuc2ncyv3utxO6mVtOicjsyP7utq icWhO+oIVJ2cLsajCuTG3n86uQZIi9LfXdF4O8IHq+wHdMecHgDpe+HR3npwQLc53NBIq9TBbM12 +7Rn8Aaqyu2tUwcokOtpPgAjENXj3npvMAVBvbSA/b8e/LR3awbArLcG37p5m+hqKe+sw4oTPuxD ut77/l3T679KCwXgne4Cf7dpYNnBfPAqfb1mINja6fB2Y+LNjsx7WvGZRrccbL0d/AQDf7dTkAYq Lc95u/Oh7L15W/IaivJGs+nNrrIU4PK5dvFPkMPnvro5XPPB/NIi7716a8KvS9TBbP/ykSn0RWMC HhAAbM3oMYv0Uma6ntzdNA/eqsu61nzwlu29Jty9fe3z3svwqB3rDz+no3riYU/hEDCqZUz2b0UF xs30Xc3xrEvZZkD3co/U2vv4jV/1Kl2bXE+TKLACKMACOMACJEsAff/cyEzxgo9ADH7fqfu/TmvN lf26r/v4SA21fYsGYN3Xlg3JDY/3D48C+jmnKHACAgvauq2yFQDlo180cNDGMb/0/l7WuYy3N//2 8uz4bwz5rv/4ouzzZ2D3xVf5RTMED7CpRsqvsQz2aj2q4l78a7QGM1DIHIzf3t38bI/zVC/9R/34 9l/9SC3Wqx/M8D7XuF80gMA1xGX/V+gTQQDxUIFiwmLSGPEAEABgeYmZqbmZCWHy8FMoOkpaanqK mqq6ytrq+gobKztLG3v15IT7tCs11isFZfZ0JkV8dmZ1pqY8pbbm7Hz1vPZ25Ua9lr1mlQ2t9o18 tlZLXj6LZC6KxMORbu4jwCBAMMJSV8fl82ACyW9S0a/CAwKVOBk8aAmCJELuGjp8CDGixImF4DB5 0iTXLl6+fBkz00yZMjXcoGm79uYNNmxapk3jJnLZsilvKNqEhc7dunY3WQ0kMBCCgAcPWCjhUiEp CkaQAPqTRACh1EyLHoTpiTWr1q1cRcGZwWSGRlzCfA2TAhLkMZAylT2Tdm2lypTY/+Y6m6bmyrdk aY7V7Lo1Z7qdgEkhbUCgwcCBiAUAaMDPqdNGFhzxkwSh4FSDiyIU/gw6tOhScGA8ubhrrJQnwqSQ KVYsTTOZeLvVpTu3bl2Ty9YwmwlnNEXB5gh/zicJAAQCQ4ECBTCgaSOASfuZ+KHkh49/mDVvvkRA 0gnh5MubjzjjdPqxY550nJIW/pmQI0s+yz2XzRs4+/vjlqaNN+D0ZcZ5DxFXjnFd5VPBclU9IIAD Qw11yT6QLNWICRFUUJkJKwwyHXeZfWeJA5L4YGCKKq6oyhRMxJALarmstpowac1nxm9qoGFSXVvw xx8X+63Bn366uaHXNjsuk8wUx/+wmGBDCmrFBQoDAfBABBp28AljAzQAAHOVDMVPI1YCwECWGv7z zwgVePAmUZRMlaVVUN6Jp3lYMCFDE32KtRFr7kkxxRjwHdqWFSZVk59KQO73KBf84RbgMyHJJMU4 ecaCIDlT9sSFhg4AZaWDG1oIVWLOOWDJUNR1EBV0WVYwApu03irQA95tUtWmvv7aFQx+ZqTLLu09 gRZrsB3DpFvfSKPGXCnBASS11Q4Jx254fSOTfGfQAWwrndby6URdbLdYBG4Sxe4DEOT6ZgQluIvY YgMAIEAAZmo4CSWzulnBhuoGXEEHEHIikAnhLswwRC6C9YRpTaS2izDDnGVMMSP/3eWMtGxUa23I j/Knm0kxTSHbGQ2nMi4t5ULkhQ8CDbWhBwSFxx0Fjg1VwlCL/ANh0O7u88i+HSw3AgWSJJ10BSLE qzQFEGqm0AMorox11rCUFkNYF8lQrKBooeVtX+D0mBvIcNCxNttsU9sfNlu85YyiIh1TTHBaj9Ly OexQxAULBgMFUARfLuJmYgIZ3C/NQbdJ1DwOAmQmCix4wGYESmeptAeau9mB5gbnW+cQe5+OeilP dN21WBOHbSwwZhCqVjJqzJbkXI++zTu1b/dHMjbOKGO7FMsUk7odfcvycjpcrCAJzVa6eyqcD6xb b5aJVDKAJO4SnCtiiBHglM1a/zqluSQdzIzlA0pLkqvSdSRPv9ZwxAADWDNkBKh7goLkkRw5SSa8 yY2QQsa2e9gBDnV4G9ywkJtt+WYZOCKG3k63PE79zSF1+AG/CJAmoBAlVwL7xABGmJw6ea8SWYLA 0SJwPndBoAEDCE+/HrOI6ZxKhvgKgCI4JwmF1W+IDZsC/l7kBBi9rlirOQtIilGFY9jOJWnbz9vs AC5w1WFt10pJbgQUjpQhD3UZxMkG01GH7QgEKPwQ4amS8jOlBUxoAoHACb0HFBa2K3RwTMyXvhSV MVmojRHgQhJ6AKsAJMJnLCCiI8MFA2GZxjRO6N+gfNEaMuQoRwTMy12uMC1Icf9xfnHAYnB8B6Rs qCQvbxkJM3JUDHBhUEpnJEcaCZYlgyGCTXJSjMAeV5UIDWQEQanTYgRwQhESRUtQiVAiosIqfLWQ KCbgQhfiEKrIEeBqj+zmna6AP0kOywkTG8tG4lMMJ9lOHNCoorUWiEWvODCVX3wGOJKBN2Joam9l fEXzXpEP7qwvaelbZmdMoEyl/YM5VUGEg+pkKqIkBkJA8d7PVtiAOuZLOc4hABsZEgYuCKGU3izp iiLWOq89wZIdSdaNjMdJRd0FP9VyGzy5aK1QqgRa9kQDPmUDS2KQkZY8mUUXWHAqeaWvYEtlF1TO R8MIdKBWA0mT93w2kAj8cB//Va1qRdmFSx9YCYQiHEq9mNMBH8zPpGxVUTjxByMl6kI1F1vWfNqy DSoCz1p0iENf/4rTbOXmGp48m5MyZoYLZq2frvinKqrERxEI7FbXU1oH+NhQsKLAZiecFQXqhdDF 1AkoPguYIhEzKmPuI1dCGYAA6lWAoFWUAl5oq23Lw4VIdk1Yfaokai6prIwRoy3fmAZNrYhKt+V0 P3NTiW2IewYzWCEtwdjnYokaCw8WzGkBowBBDRaw0G1OEppTIbsuk4g6NegBijFBhLC0IQgIJQDU NNzO0gVWfikychJdjCMYctsAf2YKMHgrEmG0Ebr+Tz6HLYlJQLmGA4oSlTmF/5tgqcGb3zgpqISa pU5qqQovBG4R6xOY5ywb3vVdNn2bE0iu+hsBD4z1q+zCWSKwBJAHuBYABltXq3QMw/yGbnDzUIwA LIcCASsZMAaOKzlPU6yyFANjsYnJGZIUF91Bap6/I1lukkSSs0XXSbAZg8r4iV1W4KMLWIDeVJVW gg1917JA1OV4iRLbGhMlEnYMj9R0RV73MiBMoEMmfbl6MPraEKxJoyGYAGK6JC950lnRbYFfNMkn gC1QyDLLS+cTjuLeRTeTAhnwqBFBb/gGn1E0hrKe4OHBgPgUXVgrGLxwLg3JscRPk2p3ydviERoU EXqmQCSYAxSbTWKZAqmEif/+QUOaba5fDO1v0HwAYGxTets2+UA4L60/GemiPb8IRjrNQNxndew2 I9OpkOQCDb2cbMzx8YViV8ZYcc3aFIFTqx24EAZ8VCnO4t3QZVccNamqd7SMcWN/MfeJIlMAoaxa eFRQ+AAJtctdllAVfbVtBxEHjgtr5bbJG1IaSx9RiRDbSC94IQxiqMV4oVa1KtcA4VIPKTdz86Q9 iXvuQiXr3g3LNyscKwoucCGI+kAByUO6nV37On0ILy8e2atM0eJRS0DbmZauRA9jYkkAL3aVY7CE JZDXwQtbyMcPrHnyuDsPBiDQ7Yv61Nu5utwXr1GLWmJiT7hAmFJbMFIEV4n/l99UMC2wYY118Z1m VcCBC1vQUJgGYgIs3JoLHix41elc3sUok7zW1vM+CHC0G68rAIdbxFYHIhAGAPIBThcFC7I0BEYk geRy730t4PABS0eyCbwd1kaO1ZozsEY+UQyJ7UStDd3gR3jPtVuicAQf16zm8UWP/GMFcYiGDyUJ Xfj380ZQYu9atqBzHLZoGf5VoSikSxcXNnMU0ZywU/RdWLjKv3UVIQLgAdhWcr5ngABVYJZGfOGm d7wwKMt3I+jGLEtSG861EjinDWD2czwSDsUwOzIXDJ1mBWj2YUW1Cti0BUmwHd5TAIqAAreGD4+Q VAnnfu7jfg4XZEChCIuE/znsoxgEIALpxTnLRg8jVQhdUAET4gBFcQVKd4BPCFDBV3cJWHx/Im7I BwW/QAxkFg7IsBfQwA1IYlzRQoZ4YQU8cjttUUHa9wvDQIKyZoKsIGJYIAQ+cAJJET37QHL4kAQm MFDB9mLkA0N/xnB4dFYyJBREcYfLgSV85D310gO8VwcsMFYMQAAm4ANHAWBQyImpkFvBZ2DFpxHm 1IYA5IGHJYEygYa10SO8oRfccjewER+zYyiCwn0MY3SrgHS01gVcoAQ+0AP/EDDMUQE4EAZdIGKb JTCh01AFQGwVVVGD834/uBj4R1+fIAndsznhsQJesFZDoCUWcG3YxnudaP+OqAB8MRB8CYg/xBcx 70gxgSIM2WcMzZeG9SFqJqEodAOLzZKGMweCbfgEt7gwuagKu4gK2KR0KsgdecgChKB020FQ70OI pQcr7eIcDfeD9TJflNMuJnAUheAFPWMCFhAwmHgUtXWOK8lvMACKkcSOSSSTUBY7nsYa5lZBzBIS HLiPYfZzysCTsXgM9PgLZmEWf3FdJWhLvRiRanQqZKcEISUEKthdzEh6+HVMWPd+6ZUIy4F/GrcI P1B+dlAHJtAqTuEDgzCWLMmWpPABwedt7MgEkoQRm5YLGmGTZPOBxqMx6SYS9nRlG3MpeHM8rkYM ryEou0B0uOh9tSBy+eD/lBnZA7UVkVbiYk5lenpmZIzRcBu3TA+5VvrAHJQACeS4lm2JmnYghTDJ jplmGr/FaWaQha9hKAB5BvZ4KYN5T8wCatO1hjKHLIn5cotZkI25lEqnHcEoCQVAX4XkjV3wiwKh OXnmPc/YXyLkHIohellVTWv1AxBydsa2e3CXmuVpB3W3mt/2IkjUBIByl8LpCziJFth3Bn0hRVZ2 j92iDALEeMTgEWJzLLD2hsWxb+UABpP3izIIFUTBAqEQkfxydRPFXzWmne8XREPQBVeRTTWUQz4w nqdpnm05A2/pkm8VTu/4mpxWMRWzGsrXn8aAMsdwV4c1lMYAVIdSb1P2/3KBkguxRqBx2BCbZ0g+ AD0REFuu4gOUGTifsGjWKVulV51c4AVahALhgSUosAI4IARKB6Ih2pZXsJovCQOYNixgg2DvuaJi 46I4yqZAVZ8oE6O3w5/yoX2zIzb/swtT4KMJUqDusEVK94voYqUeZQJDEFKcd3sWtUxZh5lZolbP gwXgKJ2QwAI+0IS15qUhCnxw+VYJuJ4Q82Q8yhGlSJRjZgwwOqf8uSxjU4sWE6C6QJzFqZQ30QVM WYf/0BwCAAEo8nZHwQJrxF/EFlvEpiWmYwKVwH4scAI90IQBl6mZCgIfgJ50p3JjGldeg6btcSwt 2mlCN4ts+ml6mX032f+GZrEaozhUs4oVIqcEh6QhhMMFdDClb8d5h2BRiho6QmAHtVYvSYWJ2IZr z/qsU/CWq0mFcIVEENNyGrEa7dEanuatsihcq+qiF6N85dqwPAoF6QqHXMGU7bqCOHM1SjcIQ7CC mBkBPhAGwcF5cgRDEbACmUieApupmzqt6+ipMdAnptEnYcOwxtKt82gofEc7Y9N3C/YLGKuiGkGQ jKmuHguoPoADAlEABOB0dRAH9yClJosCcmRN8+MFeEgwmPh2mEqzAisCLpmeB2utSfQ1xJJg5NZp o/oLtNgLQne32gegwRmg7fGeGZE6BskyfdoTdcCU+aCcD1AA/zo/hqv/dAAniYn6RiiwpfF6tmcL pgVbouvIOuCmUqDKadtqlDUCBciCmDHXadz6cjvaRD77BHrKsT86GtZ0FHY4OAylBCLphHZgr7+G Aj7Qdl16uZlasOrIuTC5clVILMRiTvK4oqX4unlJbnILtGMRI2CRPIKLCgiJFWsXtSxATB4lAFuK DyH3az/jA1saB8I7vF6auSQardTaqcTnjl5jSdnqgM4LoBm7o0ArqrkAMbAbu3wKpKFBB0zpA+gS NIwAPZ2hJZWqdAXYvmdbsCTKqcJXYG4LMSplTuyBp/l7fK3bv2iKCxPjNfSjvafAvVzhuFxwBT7A AkEIIb9UAZWKBV87/8ETzAUWHKbzO3wZrLMTIzEk3LzH5z9m4T/xaL1QFm5XgMLGWR6HCpmfgCXG Zqk4nMM5PKJvGb8X3JqTNE4IBjblVCz4CzujKKq64CfvGBYCmr1QbB4tnMAJTK+bmMU5rLnwG0lT mLyXllJKBDa/1cGuO8hoTE6BjKKxijUpbAorLBqPaU1cAAZ3TMn/VsE8vMcqh2kRU6YZEQOalhFk vMT/uwsXERbDoj/DAgNOXD+MXAqOPBr3IMGVnMU3cMnoqY7C18fuqLwymcrkZMjLS05isR6efMgv 4sZP/LS0zMybssUV7JLUKqYI246ZplJKVEmgjHdrDCPh1gR3p8qsk//MytyxzWzOmyICeSytcEmt VKjLZDpJMqlEr7nBEEPPlSTPBwYDj+TKpADL5wzQn5HO0Cyt0dzOcGWtP7yzTXCt4ebQ9us1rINp OxsDijygBBzQGc0iA03QdAeK02xpmLZyO8vJJF184uTHCV3R3dTPfEO4Gg3ToMHRlxzNH/3FCJuz dlfNnesn4UR8KT3ORNTS6vDSMW3UXWHLBB2t3vaW+HO8Prxyc7lbUy3VCd2aM2BSQ10I/3zUXT0R 70vQ7ByXOPttrYnQZ53TCB1JrFxSWq08Re3VcX0TdTDTedzFdYfXJerOZf1tfe3O+WPR5Cy7ck3Y hQHWYV3TkTTWN83/tl/MjmzNVm7N1QxDMtRS2AaY1Jdcwcaby2EazVPY2DZNA7JkW5IN11hzBTaC o35x2XJXB5kd1nDJ1J9dYOs4rbgczTQQ2I5k2gV8OsrnEX0ZameAlK1tcj5Q15pdsF3s2TdLd1Mw y6UNx1kDB7xgV89HXMYtd1wA2+pc0zws29R6A3asZL1NP9W9YK6kj+BwZtodd3DgAzOQ3HYNl9E6 Az6w221l3qlT3RpxIyNRG92wDO59gEo3BTdwAzMwAzQgAjdgA1TQhAe436iDGntJPNFQT9ZH4Bv+ KxO+N2HjEbQhLagm4OLA4Sd+Jx6eNWuQHrwAo6MmSl9kO6SN4jVu/x4qjjVI5D8fyC2oZmoC3gw2 LuTlgeMNwwZ5hyygVlyi9DZb4FwU1N5DLuWfUeQMsz+bVrcDhHMp4VcLBDcCnilTLuaAUeULE0kY MSMyOlO+s0Bss0r4JFRjLudZUebAwjW/hUnNsI+Q4lfUshLfAB9zLug3Uee/QgVj2j/aB+COglN0 AQ6Hkt+DLumcMt3AcgN06T9kwyyodmo79ehjUNyTLupRsswNk4A0ebfoto9bTimPbgaz07SjLuuN Vem/8m2WpOkjYYEq4WB4AwVqMOuiIcuGW6u9eLiP+7jGXuzDLrCF7isJGMosOmbQh3PQAGq08wTA HuzdC8lDsAU/8P/tSSDu2qGCKkjuSXDuPqAdHmruQgDu2KGJXxvdUOjsnzE/8koH804KaZuA/UNu Sj4b/agGHrh92y4RAsd5KSjuKkjH7F7u7K7uQvDC2lGHFH8FP1Du4v7C4u6hDZ8EQ9CESud/9F7r PUEHkUx5IJ8PInXDj6vvhTAD0K4an0ZcIXEogxLrBh8LAofxHK/uHa+CWODwHf8DFS/x6p4EEv8D V6D06Tv05P7zC8/x657ASXAUZtt79e6n5ufChpQEdAioXNDyyP64J4/1pQCmCsgeua5OMkrwFhPp Oo8K+GCyDM/xd9/uEC/1Qe+hFB/1SD/ueM/xIB/1C9/3Fw/0apn/9SVPC37Vi0ch8SrfdmSP7Cd/ oH11oP/mA7UKB+y7w6duGi7nRKfIeHO7C3JPDvW68YY/+Hp/7lB/9+mL+FsQ8UAP9LBf7lNp9xwv 8RU/x1bPvuXN+K6A8thm9W039mR/wHBwoA0Ucn0VUkrgh9S0A9Z0oCM/CiR65pSU6cENriGYGqhP CyDr7rHf85b687TP+ubu8OgO8Utf+IKP9PM/9USP7gt/8eWuBC9/W1p/CisLCF1cXElcV1xbg4qD dFxddHV1dnVdkl1KST4nIgEAnp8AIiajPl1wXHB2qqsxHzEwr01OT7S0Uk9muLpSY7W0U6vBwsPE xcbHyMnKy8zN/87P0NHGXD5YPkmZP9fY1z/YSdrc2T5b4dfbPj9C2+LpmdjrV+vhP1vp6+/n89dd 0v7/AJshCbgKCQ8Oz+osUnRKkRJFdLzQibOqThwwl0x4eAABlMdPA0aJ7MEF46NgVz58gMESFown s570knmLly1as1IR3Mmzp8+fQJNxGYLuW75M+Lh54yZEW1Oj6NRF9TEvWzZ5575VY5fuyjcuQcOK FTZwp0GEyxai4tKImg8WO0zE7bfKhw8TJSI4+PipUycHDzo8oDDigYdRKG6cOIGFrRedqlS2isEk hhPLMGvdmokz85OxoEOLHs3z1BCt78A1dVfUrjVsV7KySxIbm//T19xiS91qDl46dEOU0CVN/F9Z gmeZGWJEaQuOFSJvoDhhAoeJBxw78g3wgAEACIZ7aDSR2IMoER1G7Tix4vmNJF26gKGoKuXKlk1k NHnp2VfmJk/AAFlxBBZo4GiD1OPNOV6lds89+SzFGj3ipMbNadxgsY4QWoXzjRIP0XfgiMocF1By y1wixBVDXPFDeyYsxsKMKJgAHSgDfNKACXetYE1TW2CRyQ12+dADC6McNsoJ7qHQnmN0rKISCDBQ CQsTM2ApS2azOJEfllCQKOaYZP4jyCAaevigi7HNVhRqbx5l1zjdZCUEFiA6IkmZfJLFE4rKEIJF OVtcIZ4JM8b/CB11OzQAQAkP4ODBCT1cw6YPSgyaxIpStenDDSakF+MNlZIz6CB1wBFGKnWotNIr Lu2HZWWXzTrDfn3mquuuwURyJoiZNsWhhL+N46Ca2ixl1KZYtPiQIhfxyquJAAGqTCZXKOEDNdCB ioMPLB4iSFcttnjnii1ycWewSnhVZKmFcHFRJBaBEUkqq0Zih30quRQrDPntFyBlAkpr8MF93num WnmWo26zW4D4AyJcALuQRPoibDC1xh3UDDeCVqMIGGo1sgVt5WYLbDlY1YZNIoOoCkdEkMQx0Xx1 0GzzqvW5CsOrLcEqNEsDamz00UgnrbQdHPtjLTJ1oAzuEImQ/0zItooIopCG7bbbYmpBDgIGHBJ1 YTPGqk6UM8ZqpxrG2ZDYwYWrK7ni79AxFL303nz37fdoTUvzNDKwEZXtIRXb9VBDcMgHh1OYIo5K FxhfZPnYYUyUeRz0SuL5nqpEaVGUk8zgc79WwnrD36y37vrrTv/pMTMKtpxuSSOfQnIcj8Qs0arz gRHRI5ZHKZHNk3g+ySIVWaSKvRKpwoXpdP+s0g0iwq799ty/Hng0gx8ztYssUz157mWP/TscqUYy 0fvHk17RRYvErYok8qttcxw8S3/FFDe4wRX01r0CGvCACPseNMJnjHAlgWWcWtwj4BA8ssmMYqqw 3KrCkLH4qP9lGJQgRwbrxb+b2YF9oEOgClfIwmnJDi3KiBqLqsEhawRJCI54TNkeYYpVESIRKRSG EjK2ikZY41Pb4l/a6HUzzk3iiS2MohSnWCAFPoOBxfiGPAxFDh+Ui4KPeAzO5hMRaqDCGFuIjxIq FRcTVIoLRExFKo7Xq0ncjH1UzKMe92iWFzJDhi2qh5Hs0qAr9JCCF2EfzSihhDAcI2uVEIb7oqe8 SZDxkBu0w3D4yMlOerIYVnQGFokRrkDahUiGGwIWMOK2VOBskZBRHr2IIQnkPVFVJwRe42jmQy4M 6hCfVKESPOCBaNRBCScg5qTAEswDhlIgs4shtjYVmx5QqmX/d9IZGS13r3yx75uR2B8YJmGzOoxT IqiYTzovOIhSim1ezeweF0RAAAAwgADP6EIHAsDPBgzAn/70QTy790xmjHIY4EqCKT/FAvL9wCuo 2Nx8NgeJztHLkeV8oiQo+JjJVYItDmHRsyb3PpkNFHZdMAFA/wmBADjDB/98QCGS8IB//pM7J9Ve QZdx0F6di3xGog7K4NGYVLxvXl44YedUoRNHrmUQpuiCPeDSGBYxT5E7k1kFHZnTv9UhAOnh5z0D wIBm4AAADaCAMExAVgLcc3Vdbd1OSxRNZegmoXZJDIdo89B1cGGDxYuWHWBpNUi25WrvgGpU6YDI 4BVPZv2L/2vruGBTfzJDCQ4YQACYGQwKABSnkv3bXJPR04okQQkna5EP1nOCvmpISA6732CPB9WF ULAhLMvTs267VXlh7raU6MKqaBZa130nAJZdhgDu2YBitPSfAi1u30aLjNLeTxzu0sQJHPhAbRQq ZmoB7yAgiLiIjG1sjkAFOhPZ2G9usHEyi6R0/bZSlyoDs26FgDE0wdn5Lo26x7CuKsD10NOwiEhD hQ047AKzRUTMHrSpmCMSmd5TeJAOHvSgqkyhTpo1NpGZ82/fkPvPsiqjA8slwANEzD0AG0PAdvDi FrGhIRrShoYa0g2IVkSVbMWMZBwWm4VBGh/d3bZ3Ebkt8P/Mdl6ZBZHFR7snAwKAT2W41a0rhjLs XAzKukKNNuBgVkLvdFp0YaVS8mhMegVBssY5IqqOQO+FufAYH4LhMYJI8thATLZGPFnLGgtAZZch ZRUD2nt+ZEY6INwmouQ4CULia2zCC1XdLaLNRcb0OksC3986toJl492hk3blKS+j1FketWgTHUNw zSY2afbi+DhEDkorojEws3R8OLzrIntBfSC97Q61msg/q3oss3wGiZObDAA4QACAMSYR/zFtaSRb 2rQ0Ngi1bTQuEwPGVLnxOcoxvpN1NzYj7XEXT5trTjuiIR0VhO6CnOT37s7T8Dw2aLhggpby898d iK4yCm3/X2JoxQcCWPZskqDtK1TgnvYEgFs9oIR89vvfAYBAByrejDDc4AFulTgDIHCCTUKtBw8A rSpS2oB/Q6AHxOjCCfzNTw+Y/GjeHoaA6+DqRRcp1krQRqQzoQh7SC5ra941p8+b53cXOdONO6T6 KJjO7On7J1zwdwMeEJeUr7S/xuAnBBgggGJ89d8MqKxmMb5ZgwcA2gIowXTGTgB+PoDbwch6P7FT 6HsmQRlweLjIsUNlKT/g5r2i6b+3vgoP8HMAfSdAf9kq1lITQOBIyzlZvIwMdBByK0jZ4opyY+uG OKIt8n7zrk9BdY7e9q9aPQXweEcJAl6dID5wK3dSSNnP/4KdGM8OvjFYoBjxWP4GxCd+yYdhAmiD VRg++GzBj3ECsf99FV3oju5N0Hm4myCFuR8rAeAqDH0u3qYrpgPcgw93KXuupgC1/JQRfzDNB2Pn 57hLUbwiJAWRu9YOphYNwWu4A14mIQjydmdHtmvohF5jIx+39xNdUGi/5wNSNgCpFnbrtwxtxQAZ mEUBIHzMF4LQdgLIsE8e+GRccFzQdn3E0AMkiHkVMXbeB0InMAjwF1NC0HImAEeapFKVZQJd0HIP cAWekwQrxXhJY38FwXni0yY30B48lgmKQ2BGNzEUsxANhjtnUmRxZgrv9oBy1msLeBFi9BgR6BMm cFPTF/8MV9ZyeJdf/LQM7PeBxPAAAAUAMcd++mUMJjBWXDUMAPVsfTgMSfBsAVBMxQAHBBB8AQBz xbAFSZiIT7YC9QUBA/B7YFBfeKcrTKgK+McNz4EDPZAbo0dNSNFgz7KF7gZG85Z6GLFm6/SAqpeA UXdbadgTLWdTxZByadcA43QMggZQy3Bc0XYMZwdtdqgKaMWLxaAEhYcDxvBcxAhCb+cADBCIxOAD LOgAv6cKXvAdUiaDwdCBBDACfrhsW7CErKYM+ecDKLAeDGYODyUheLIIIyVeCBhnprd6D9gIvYaA AAlGTbdrucgTD5dfxTACAwABCUd/q7BsbWgMdZgMLfX/bNxHDKU2kasAcmQXjMTABQ0QfBm5VnC3 jMIwiAKAknZgU+BxDBupbRZoUyjAjmbhhPvlFfIgHTuAAj+XCfZwihEzXgGYO7LoOED2ZmvRCG72 elQXBx61Tge5E3UAAf70jXbgAVIGARCpCsMIecUIUCy5ClzwdndXDH1XDCt4Tw6ADGBgF99YB84G bSVpDCcwVg4AjLQkZQKgVsbwAOunbVxQaiaYee2YDLKRBD0JKjtQY7XhInNiawshH/yolKwXhmtB MhgmCGbIW3kmEUk1laChBB5Zd11pByMJd8uwUmO5DD7AfhxpB3+IZf7wmnBHjsPABbCJm3YQfC/5 l3AX/wCC+VmFiXOHiQyUkg+r1QPxiAIusg6PFmFZ2GDtdj6WRnWxeG9Pl4DrBJpURw1XIJphMUxo p3unKXJuVYwtpYTQoHjrB229eGUi4A+AGXxYoAzvWQK01IzsSQwdwH7a1gXHNQDSaJg3CUPXwiNt Yg1R+ByW8iF2gUPPsoq2ZTVAlmFrAYbcCYtudlhIhDXi6RP8JnIdwAWelXEBcJp5eVOriX7PoAT7 xE89uJHFwJ+tiQyQ51YCIATKoH1ThpLB2QHHQE/uZwxdEIQ2iRw4WQzgwiNFkgnWUXwOUg1HJ5lP NYAl4UGxCJCzCJUVkwmUgilncgohuhNX8IYCx5AABf+SxXCN8KkMx+WBzQCDZPUAHGcHBNemwVdl 0bB+DMCbwoBiwbeMXzWox+CjBBCg4kgAdakxn8g0S7qN62ACRFIkQWVNrnZjm8IwRSc2auE46fRu b7ZLXnA1iwGXS3cKStAIZQoQWZdfMpiQ84cMjhibw1BoNzpgN/UAYEejxLBseigNn8WoynACFUkM lTWWsiqc00CYSXoikYpQ21ABJfAtRdKTO+Am0jmUrChebYF6++ip6uID1rEDPYBDR6ZelnZGrSoN dMoAFfBkjhd8oRl2bqqeynhiANWoqpCExaB2WKkMHbiSyoADSApC3+FPQvqXLeVWAVpoxdltxyk+ DHL/HU6aCTvwLcqJDRKmhZ0aXqZHMeQaIzhwBW1WZxYWZKIaH+0aDTuQYoVokoh4mpVlq8JwkQSL DBHwi345DLAZn1KmiMmwGMJQmtioDEDoTy4oDMl6DDure8N5UxHrqBObk/rgA9hRqYOEV+gmmd1a dERxSkjECGFwJuhFZAzhA1bTOC2bT2LHAFhZAut3mmkpsCTWmjAFUMa2UiY2DD1AcKc5CQGwtDHG l5KXDPBHVmbXgT17h3THrMXQBY+3I89aLdEKfVnRJqFyApY6pZKDWhSTj+NlD6uVGBEqNpWAXq9H i76UCOMyMgHbtsVgAlcGAMa2rKe5fjbrhoaHDPX5/6YayX6Rq3vIdaMpF0R1wLdC+5dSVgEUeZLH sKyCCW3+NLUJVLVM2rlFYgIiwAJ4VSE4NJRq4S5thAPZOijyJghYgK2N8YBgSAgcC16JYHqy2ww+ CgHG5nhrigzmqJ5U1pok+GzGQHYieIcZZ1P8GgxslcBs5ZDPxm1fBXdYGcHPNp8MW3gByk90Wbkd g6CI2SbvoLk8gi2WYinj+ykicb61Nb7UcQPouo+YAJQMcYDUkAj1ywyl+YjEQAe/m6KrcKfB8LPJ UAft15rPJmVATJYOkF/Bujx5J38d8GRh0B2QK0k46wDLOwwoQJLHsH5jiYc3JZj/9GzWW3/Yu42W Kv8b+scVScC5VHgXS/JG6UVphwVkFoE7RzQ1JzxI7HrDxcqX3igMPQAAzvds0dUBZeymbSkUdQuc e5pCdcBWKXZPYNEFEJDEbJWEIaFmSdABzMWjz+imf2p2vWsMdHBchvaXlcWmwlCWhZfAG3PG0vp5 P2cXPVAb6BDHN2Clkpm+iGAXIkEdIiEKo+C94hJ1gevHcvOeAdCD/NZygsF+DnBxN9cFGxm7qtB8 jhi7eXtTDUASQqBSAGACS7yVf4i/wyACatdygmZPdRcAZRwMSUBwkNgrIKdyTMp+DKBtuguoa9gA 9xSzVHugc5rGJDwkhjNNkoM1tgYzW9gQPrAChdH/EWQ1xh3gAUTCFqkSJWEQqoigzEhrjlMmaC8X Y5MswZKUdX1np39GCeT8nhDgA9XWkRd4UwQ8BHYAxqxpbGwVeQ0AAbAaKBBQh6WgEDA4ZbB8XQKg khTggxXBBZ6so8/GcJIEg3wrhJ1YJo8KbmmcmJ9SIZHJBTtAlGT90ON1FynHT98RGA9ACg8RPAG5 CFhAElYH0rOryQ3QAfRRlS55lsGgdWqXcHMYDMs1AJMs1f/GmwkJ0FdWklzwnkktPYDZd5DXAclc F3xbT83blf+WWf7Ufs2czQT8ng7wb5ZgT6Qt2IM70ErqwZ3X1XNyDj1wAw+VGoegLbwcMcDcUs4G /x7YMQoZ/WNNWYBBAjMyLT92fQxvaR48oo2TMB5xqS9L9TkgpFHSTd3T0AMUcBhUnXfciwKX/Zbc WwEm8ANZHXN3MQIUQB5OjYzXnTzw3SsWZVGSRN/XZsYErWjZaqkgXBs8gg/nMAg4kIUUEy48hgKQ AgDYERgjUAIMlk4EuDBVVVuNUNTJfeGhtdWXGwx2Yb4GzSA+4AE4QLrkgFqYQpRccwja8J8/LQKH sQOnVVv7uDAs0mC0eCZbIFgYvuMDpeGufQzVBNvoYA+Ikl0PMdb5KAhJ0G+AYSMMvTBPpQgPhDhu JmdCRgjYzONaTkU+/lIZu98GnQnWUK3X0Bjaov9mp7AFm/AA1RovbrYI33kyaSaL4GWL6WWydb3l es7lskwMP7CYaQzC3SUXm8oFODCpgtHWQkA5hcUQDsFXSnlYRGahFeYIPhA9e57pedTlz1C6YB7b 04TW1wF/bd0DIWJr63AyWyi+jADn68RmHnQFEaHptC5FnP4M8eiktcxXdyK2Rhleqg4u4RVUztyP VIehp7BK1IDptd7sCHTrzsAFwvzh2MIpDf3GXiG6i7Ba4GK2Uf7tH+sDs67pIGKIHCtE2CAcwtDd dhDD2CDPd8rugvQDiKctMn0M7g52XWAUxrYsdBE1XyFEdgHJ8LEKhNsFdmFyBQ9CcGlw10Dwhpj/ 5bkC7c5wBZSq66BeDi9T4Hax31fwtWQNLQU4ZJMe8mYEB9uC3HrOAlNbBz4pBNMRDD1QivxVEScA OuT6FMEwHXtyA4HYk9rCuYJMEvAokyigLT4ZDFjgvd7Q70mAAqXITHTgk7G1CixA9DdfRFB/PxEr 1j+ATECMAr8n7YWQ9MHAudSQ9eBovVtvoK1tbcCstXjlaqXyodrusUU5w3rfTpiwEFjjA7iU6ZGM A5tUB8U51qvQAz+gCn9+9jjPAsTQk9HFApBRilzPWdJeF4BaKatwAneqBOSHDDuw+KvgBTtQrz9M fnZR+j0JFoavwMyU+auA+IJ8fVMvP6uvCmY//1g1mXc9ed5a3edQw28YL+bcQEMM3dC8/KloQiiX dgqNUAi0XmOYZ/h7svuWr0nFaf2Jj5s+mfU+b/UumPsxJnCy/4LjX89KAPkFC8qho/bBMPqrsPRF xLkw5/Jk2fu6z1liL0nwL/+AYGd3wiVoR9dl2HViKIgz1FPYOElZaXmJmUmJpNlpiMTD4ZnJZbLj g+pzJZSUdMUl5IPDxbWlREu7hburW7sLhwtcu9qqdOsrTOtDFzfq/AwdLT1N3bnC1cXSWHfiZdd1 bdiTZFfng9J4Umfoc5K6LrjDhWrHAmeIQy6ohC6IIlmOkSV6grho2+cOVaJLJ3408pLQh0N/AP8n eVkR5xo3Q0p2NNox0Y68SYsaERy0kJIXj+nqKOlRLaY0TjIFgRIlsxSqKz6E/OCZxAeWHT16+TKK dBeuXmBwCbmS5IePJFiM7gIDzEfFmly7ev0KDcU6FPcE1WFxA23IejtQnOgBL2BcWcaUNEKR6ESX G2EMrdBnhwtLkXbNqhvowxCXG4pBGktZCcWWRnRY+DAGcGSljVxwlNzXz5EQQ/8mcREoiCC3RCja oq5jotHpb6jB2rZDs+ZNrotRBV2lat5LLreOKd1l/PgVnr5VCalKPJhSOnFvW7+OXZqStKZCrj4B OLXW2oIOpz44aSQqFHTEhTyJojDtSz0SC5L/yjG2NSwPb1T3J18dAGUkiAntNJZOZltxE5dlpBVS hzkwCdJFaHac49pW2cWUm0y7cZWKb1T1RAsOVi2F4nFKbMFciCJe8cNzK+LSRXsb3ohjjpVYBkcd P6xgCIMQQTaOHfVtY56R9k2ClyA3rOCNIEUCaIgQE154JSVT4TNaQRZigkOXZpnwH5bsXBmGQFys EFodTcr1ICWlOZnSST5cSUdtknlBx0k6TtMhh6F01UV9Ux16xTE7DJFLcsfp0iIOqLS1Q0SXHRPh n5puemMdfJnln2HrJIGekQ5xU1GSsoARBxgfLXSOjUrWUWiWdpjAHz+QTVKfF4UCyZFGZU7S/xCS XPAZV4WTnQYQHKHhAGxqcBW6pEg+RBjXFniZUyqzAs5pB0SKRMvFl5yOEmg1H4KYiitD+GCLEsHx gmJVPx3qwykmeGBKUNiUdW7AAttWbiMsFOYmPJKKo89p8DDIDgor4EAmaSntEKWRJ2wcniBhtBXO JRiCN4kSJ+CwsXyRTWYIHGixWW25Jpygch3kfukDzJOw4JY7jWxxwsSUdMYmy4LkyQ4OjYQ8cCfp UrNuTVtI2hyMtPRwzCu32DvPFq7EgsoNJhjYBXEoQFBt02qvzXbbbr/t9tOADtqVTu22ogtISFU1 xBVbYOFD31LdgDUXAkb1QwcCOOAB3I4/Dv955JJPjoncM9HdVb4uvsJF4cUhBwsWzPXQV2A4WPbD ED+YIAAEDwxLeeyyz0577ep2FTVXP9yQChZCGDPVcUqxooSrgrDwg1Q/xEFH8idA4Drstk9PffXW Q255NLlzFVQqnOsdnS+0JFrRDyhgkXwhXHhw/hAoPAD9rtfPT3/99m+YPTTbsztVEsCfuAvImCN1 PyiEF5LwAAAAwATJ88ED4Key+0lwghSsoNNwhzlLwOENa4ADwEaRil70oIAnqoRE0mc6ApTgAQ4Q AAOTFwHoRdCCNKyhDa+Xv2fszw5TMMMTzCCFMwTRDGdYwyjqwKIf3GJe8mOHACqABQj9oAL/DyiB CFj4gAGMIHlDGAH80nbDMIpxjI7LoTO2d4YfBnEKZziDGs5gBTW80YidEBAXkoGJOsDvAVoJjAke IIIVlmCQDmBhBCQyBBNATz9kbKQjH7kpM6Irg3B4whOkAAUz9BCObpRjJ8/QFeWhoI9h8EEEqjiB QO5glTa4YiFxUEAWPPB1kKylLW/pFUl6Yl1reIITfKjJTspxDWpYQxzfqIYPSmMeySugN7Dwx0Fa UQU3KMEKbLADFazQdShoZgceqCFcinOc5NwEBnFyBUtaUpNEnGMx1wBPeHpSVtFo5hCiGBhZVjGQ JVjlDgrZzxvooASFhMALf+CBB86wnAxt/ygkdem0QVXSCWoUohvjCM8trIGDxYxjG6XhhRPesy9K OKUrTdBPf4oApTvQAStZ2IAK/AALiXwgeRyK05zaEKKa2M0MKGrJMQQRmfDk4BuOykF5uhEaiWPg sRDxxyoCoIr9dKlLW1rNEpjApTZgIQMigLxyPaADJdCpWc9KQZ5mAhQloAIT1BnMoRb1DR7c4EaJ 6VFl5rGBEeACHUJqUgoUcgcrrOIqrbDKsWmVsC1d4StT58BThhOtlK1s7NRaOR6YgAk/hatcrbBR utbVrsXkpCccmDou9GV1BCikA1bqUis+gLGr1II/b+DPVRJUAA/oJk2ryEfLCne4ksPsJf+Q0IMb vLUJlwxmJzdaVzrUNameNAM9LZGEqDoTBw9owAMYMNaU5rYEYruqbncAgUH604oDeMBBTRCBDtxU E2KorxgMcV9B5Ne+9cVvf/37XzvkV8D6tW8jDKzfBCu4wJTg7375C2D8SrjA/x0wgC0sYAsPGMEU xrCDF+xhDkP4wgQ+cIZFXOERn1jDAabwgVUcYRJ3uMMb5nCJJ7xgHK94Ei3e8YsDjGEQfxjGucSd D2IAg84GVQpqmMI76UqdOkj3DRr15BToeIk6eOAEhZUKFR0AUMZeVQdb7edsEbsDKwwSkDvA7Q66 2sIXlqIDHfBAEy2hYRCbGMf73fOG9Xz/4z5nGNBBvrGhCS3oPHt4zyX+c6BznGceC5rPhDaxo4Ps aENHOtON1jGPJ7xpSus40odedKYvPWpGT1rCmNa0bYxrCST4AAZNAKpQLVpMNYj2HtK1K17PAMRM OBAFJuiA65JnAgI8oJpVdDOatVpFbO7AtkEQW2630FIRtLADzfRBnYPbiVBDmtGpfrS5Wz3oTmOC 1J5O96rvu2hQV2LV4253hT+tYFTLm9M5Lne+8SxvgOP734CuN6sb/OlT99vg50Z4vNmNO9zhAAac fasUfshGNxbVg72m6xtK2+QxZEKR7i32sX2AW5eiVJv+RKwVqu3PKwThCrTdgSmskC+C/7oOkQ4s tgekV25Oh1joiAYywgkM73z3WNMjbnXSXR1vgiOY3q6+cJ+fLmMfV53pU583uWsc9Qfb+NBVhzG7 0T3wc4vYxVvXethFvXDd4O4GMIjBWz0Lx2Je4aijTSoxm6xJvTZibPAjfCF/0ILxig2baG5zEMa2 yiuUYAtaoLkp/GlbCjyAt77togc80AFbHZ3gbfez6aVub6UzfPVkf/C4o65u1Kcd4o2GPelJTftC n330DRf410nfdrR/vekFj33pS018fxeZK0iYAa1h4Mt1bnKYHNygXTlqhTYCEcuV6AG/4MevU/JR Ki1dZZhtO+02X1UFO5C5zFeJW2wrNv+LvU3f2PY136ArX9+3r7TsjU52x6dv93Zwv9d/vcd6rkdu /ld8aEd0AVd27SZq4mZuCeh1E4iBDCd8jwZ7heYhuFN30Ad9P4RxbTRMd2VUxvRGFiUF3FcJ+4JS AgBtxyYpaNZsK4BbtvVyO4CD+bIFVvAUqwQvK0ABJkABFWBNm4cKvrI6Y/Nzl2B2PTZ0P8ZiCsd2 scdivrdiYAd3TeeFUoh7LUZkH1aBC3dqNlaFQCaGkiaGYJiGmNaGAFiGWreANJZwozZ0treFeWhg RBZxzAcCMCCI0WdJUtBD2XdMd3UFueZGbHRxoJRHHhABxRYAI7BNDyAV+YJYMLcCp4D/c21mfg+A bZQHLzxYH524AyyAUgMQAf/gKwc0Nh0AdMRFi7V4G7BWCUggiDFgd+okVGOQccOEUXKETD0ERGNw BZoAG3XWAaz4Rw5AAA0Ef21GXrW1XlpVAlZgCtjWiSuQLyzAg0VYhD/QBV6ADXVgjifQAbbIju1o Hbi4CTMQiEwgAzFga1IARGcQjJ8EeEJEBhfngpagZcwIXn+0c1IRBKu0AuKVZkLwiaewA9y4Aqco BKeQM1qFAihgjuXoK7TgBT0geu4okiOpP7jjfEjWi+okBcBIRNnXZG+UcT0kBSv5BIJHCWXzR6Cn bH8UAOPnA0GAWCbgZj4Ykf5UkaYA/47euAMusAOxYBkssJFeAAYhZQI80xl3RpJZqZXmxHw48AEh +ATQB1RqhI8WpY9EhI+ZpE42qRi1cAs5mUDfpmyZ+HJupl4sEnlC8CTdmDOa0xNt4YrlWDbQ9APa Ejj5t5WJqZXwOAmy9pW7eHfr9ARpxILsJJOXpE6Z8BSqAC+l8ABe1JMJxQAQ0EBa4ANa8EcstY08 yJdKuQJCwAJB4ANWWTZRyQUPEBR/5AUV0wgKBAC96ZuG8Ju9KQi+OZx2cJy/aZzHiZzAyZzIGZzF GZ3QOZ3TaQnVaZzSqUDFOQnKqZ3diZ3bqZ3iaZ3dKZzCGZ3LSZ3kaZ3ZiZ7kSZzUef+dzRmf7rme 7yme8jme+Gmezjmf9Vmd50mf6nmf+zmeyZmf18GYjeCYH/ABSJZkTDCWF3dx+YiPFfoEY1CIl6AE QtkDp5AouvBHmjdVf6Rs6OMDQKhmIqCJR9mJSZkzsWCRo+QFr9gF5TiVCPRNJpAR1ZKc3Cmg+Qmf QPqjQHqeRVqkRBqklJCkTLqk/TmgTzqcTTqlTyqg9MmkVYqlWNqkRqqlSnqkVvqc3CmkX2qmRnql 3immYeqllVCmWzqlWsqcVNqmW1qnCopBNPCYSNYEMsBcFKWhPlSIGqpOlkRRggcb+bIDoZcK8uKZ DzRV3wReqkNzW6CoMmcC3fiiPJj/M6l4Dj5gjthgjl4AB6MaGF5QB2FAMfHJqgOKoHWapM+pplyK pmdqp7fqpk4KpbbKq/VppWh6nXLKql1Kq3Baq1EKrE76psWKpLp6pchKq8QKnuhprNAJpncKrV/6 rNmxoJ+gWR8AAnsqgoQ4qHBlqJbEBJVwm38EkSJgkX6zIlHVAABAZw9AACKgOhW5SthWAazZA615 CrCJAkMwqr6CozJjAk/VKtzVqsfanN4Zp0KapsMKqwBapuGZCeHJnhILps0apBobsZcAsQ7Lpe5J oHN6rLP6nbk6shGLoBd7sQ5rn7GaoMTZsr6qpigrsyD7nviDQR1wA18JoXzqp+Ra/6iFylnJaBqb 5wABAAERaQIVgFtT4TvQ9EADQK+b90Do435GmKlJmYqc6o0ZeSyCWbbHYiDn0A2sEgZ/FBdjqrM3 e6ux6pxDCq3IKq3b+p9wm7JrWq22mquBa7fFOre/qq3KqbJ6+7CLq63XOqY266slW564erNxK50k a7mEG7h4ynyD4qDgKojPF5ZP8FYUZbq+9FbQNwncAHosJABTFZE3QAF+uQpdEFUAEAAlYGwE0FdS UUV/tAJIKbazSaN39A1c4ExlEwGWanNcEAdhAAfJBjAeq6QjW7jY6rF0yqzO+rgVu6tsirfP2qsU K7iHO7Hf+7eQ67gsy7jJSr0Tm/+52YqtYWq9HWu+Mvur8/tq52QHW+CguwjAfSrApDsDTQB9fFod pWBzCQUBuNuTFXkDETC1PtAMtwKpWQsBDtC7mWqErOmNL3oOXDCVhfADAEAATlWO8HUCKNAAItwq IxAAkNGeARq+Waqzdoq4skrDroqxmMCzmhu3NTuzH5ueNUu+BeqlJjvDCWqyFjufwnq9PByzBhqt /Tm5HUvF7zunO+yyL+uznYsTQfu5KBnAg0hr9cgEMKC0AbHCPXACrRsAvikCFalVJtAD9HS7MvhA AuAByIsC1lQC/MKaGUmOo0oLriOUEqFacOAD/DIEcRAhSpBFGaOYlZyV3WoTmCP/xl8ptIJowHYH oZ+8xrZLKRtTbN9FAAyAtSKwBX8ERloGqV+FRb0rBA/ktSbQTbhgm7bsAxWAvMeCLVIWBnEgSwJw XZaMzOyIybiRQVfwuTAgriEozTAAMO3QA5IxD/vyTakMAAIQx8ZmNKv7TQk0VvbqACbgBeYzNhWQ y4Y8quWYOHXWGcjzyGwLybcJXsmsz/fTvdzKv7IRrg4artAsiIFYdzMQFwbSGq3hBfISVQ0cx1P1 AFhZDtscqd1FACPABUPQAhIRqscC0lEJBjQVBydgywW0Dq1iBzhAAQu0zy99Pf3sz2CsriLwuQLN yTOwFT1gICfQFgnrfd8EAVjr/zrRgglcsE2R6gDcpBTuXLah6gVhgAX6JJQsgAXQ2xdbAD8BAEYw 7dVmtcw7JAhbQAU3YAM38AqXYApu0RrX0qFZ1ACuwx+eEAd0BgEB0AERUEiYGNIeKaq0sMIM1AUC skJ2bAKPfAi72QEAAAEyrLF1C6w5PMUEisQza9n9XJ5desNIXKtGzJ+U65+Rva1XLKuEe8XrKdmH m52lHbKfXdmX7cOjbaClXaBe3LA0PMTJ+hVhnUHU0AUeUCmmPEoJFdcT/QxJQGdO+0CL1NfuXCE+ AF89wCfmeEoGwifQW2y42zjkq8Xee8SbPb5H/N2uSq1ker6Lq7kUy7e8+qronf/e3g243OusUVyl 3b296Kusl6vfP0rb/Q2/56uycarby6cbvU0NpWDKOLgv0GPUztADdCbRrtMAoHosqwNWIN3HQ7AD Gl2jf+WREULMxsbYHUO99+vefDvf8du4uNqw5m2t+n3i/83i6p3fc9vesyrT9323Iqu3m12xKL6+ UczjAr7f4HutRw6+6w2gA/6HBY4TNQHdpnwCp7xQo/B5dw0/BGBQoVoB0B0BSmCOJZdQhhPM5dAe Jg3RdgaeMCu+rXqym/u3P6yf892mcoukXLyybpqe6Bugciu5/ynFtg3ob46f47vDUlzoPbu5lTvb VsyxQL7iAW7eOf6BNN0VUz7/Mz43i8pIiVMFPQ9AsNBtqb1Vjj4wAA1wwq3yvHAwzOh4uz0peiiu vSSruOAd5IDe4upp500suUKM6zhsn9XLuME+4Dje4zzuvi0e45GLxUxOuavdvjhsxdO+5oPr4vaL Hbz95FzRAYQXktGgBN8UxwGwOKCKAh0gFO6FjuiY1sNcDhECBt7GQgrkXrEu39VK63dq6zp+3txN v+hd4nWuuNJO48Jev/GtvjqO2cde61V85OHd7/9tvbSdv+Hdq5nr2QTuIQYeE12gUF3x4AmEuwAA RbepbA7wA9P9V9B73axutZunQBDgAR2T7Ens64me58DOsYGu6HreuEOauMbO/9oZr/OZPedy2t9E j++CvuhKvJzt6cSufec9DKVFvuO6Ltorm/RTT7ec6+RgYThfIdS+2QAvNDY/EAaCOd2pGgddkAQJ 9V2+OVYU/dV171DaLjkez0IR/QCH9ANAQCM4GgfZ7Drw45vKPVl2r/gNhfeSI8kwr0BNC16TiMsm 4EUJBD0NfPjKJgKJv/ifP06N7/izNAAR7cCpLAADMNQNUPoKFNGp/ABqDvqzf/f/PDlc4ABxzfoj //TLOe4t5F60L/yMb/uTUwcVwADKdte8H9Hj7sDAj5ueMGQJl3xIp2JRmId26HbDB4dqGIdYl2Bk eGLaT4dj129Td/3fn3X8Zv/+yHdp3t9fZHiGD0iFYuf9GTj+dbj9Zmh0Q+aH7wgIdoKDhIWGh0g8 HIeMjY6PkJBJDwANAw8BlgwCDgIMBJsOBA8PXZGCYoapqKyFYqurdrGyhLCDs7O0rrettLa9vb+6 uLrDqrzAxMW5qbHOxcjGyM/G1NC+0bbWy6q/1M+5ycetr+TBvMy1qMLn3MCn8I9I8ZCJi/T4+fRC EQ8MAwICCAwwwNIDCA0e1IkX7lu3duKuRXvnDhzFbO2UNZt4UZk5RhvfNRz3UVpIieg4Yju0bV1J jOGgjXTlreM1jewkWoupj968nobsAR1K9FAXJUiR+vBgqQEFfK+iZoyqzV3/RFnlamXFKpWrQ3Jb b3X1OnEb1ZxXl4W12vWsWLPrtp50tnan3Li74mbdiFbYTL19VwZOW7Xh3WBUi8L7qVio4seQBYEx oSRfzLnjDqfdPPNbYnWgQcPdjNKjTq1jUzZiV5OV27yAM8O2Om3w69Cn8+6leFsm2NUQeUZGBNnx 8OPIH12m/ZswxJskW6+EDpt12ejXp2WXNh2j74rgr/p1vb3zeO5/c5uUfj4irHQlWyYPWlzR/Pv4 vZp+vZNm2NQ3feZQOgCqR9d/qMmFYIKo4TbMXp9xxeBUui1Ym2fw6RfcXRkmE+FYX0lInV7eNbhh gfMxVpRx+bXo4oswxijj/4w01mijjCoSxeKNPPbo449ABinkkPjlONSORCap5JJMNunkk/kYCRSS UFZp5ZVYZqllY/Xds+WXYIYp5phKStkTlWSmqeaabLaJj5n6oOnmnHTWaWeWcEZp3512wPHGGnDA weeghBZaY55v7knnFWY8YcYUj5pxxhlvGGrppZg+hqhPirZ5xhNjSHGGqGeocYYVpVKa6aqsttrI pvHIGSYcTzwhhaikoqrGrqmq4eqvwGIK62Kdpkmro45OUaqpaqzRrBW8nhHstNTWOewpsm5JqxO1 Rjrprs6Gu4azplZr7rljXhtJtloy0S2upUK7xhV//vkss+jmq6+V6tZTrP+YT3Bba6i9rlHvwePy usa+DDdMZL+GrjFDrbaOesYUzY77RqB+GuysrnQ4LPLINkJcKBMxcDuGo6Lu2uwbG28c6J/kYkzy zTi3aPKgbMjQhMCiKguuzHDQEegWNJs6ac5MNx3ZznzO0IQMtUoR6qOlzgtzHCFznLQaUizs9Nhk v3kuDDA88XPF32ocaNdG24vqpFKUbffdjkBtJxwwxODuwFI8qoa8MnMdqMc1m4H34ozboXedVMDA xAxAk9Hyy4AWPbO9pkI6haCNM80DD4OMPjqRp+Np7g0wNJE2qLZinTXMMcPh8RW8TjFGpaHnnLrp qQsZ/JWP09l32n9bDen/4BnTC7PHuZthRti9+066HcMPmX2Vxc8ZA9owUE5x4MouS7PHVpBLNxS+ Vl/l8NcLAjwh8WNvOv3015///fKTDnz8/yvE/PZXv9Pxj3+MGKD9tNQ9Nx3vZ0141xkE16zmVfBi o4LUE9qXnP/pDxIKNIQHgRLAQ3jwhNtzRAlVuEL8BA+BCoShDAH4QfuV0IADPGHpVjjC/s2vhQT8 XQ2f1MA2iQBt3xMf7IJWKoy5jFlgm6AUniC246AwhQlEYBCBGIkrivCKXMyiDk3oRRfS8Ixn3OEL 1/jF/PXvjXCE4wGvN0c6CtGOZMTjAlVXrRk8UGCxg5TFmNXEzj0KVNRD/w4YhyjAEKoRhfFYZCMX icVJQvKLZbzP77AnRzpyco+b1GMjcihKAsbRjTuMIxvbyEosFZFNV/gAElsHyKuVT1lzs9j0GvUE 0A2HkiDkIjBPQckCFpORj8ykD5XZQf85E5TPxOEbpYnFMQpxi6VMpTZXucdGkpGBQqpDHbpAzi6I cyEz4oIsv/eE11XtCaOa3gQ9Nz1braxWigxhGJOZvRbuE5Nr1OIoHSnGgMJPnwT9ZTSfuUBq4tGh edTjNZfZyW9uk4ba9GYrifejLnAhCT4IqUhDmoQkIIUL5hRniz4gS7S1M2BLJJgU6AkpKPAyYPnc XkL5qT+C7hSgluyiQP8H2k8t+nSoVvwkJwuoVP/hD4BK1WhFu3nQU2YUmhlNoVaRyaQGotMOXw3r INAZ1i6AtAc+QKtIQQrSkZLUpCilgxfGSldBiNWudQUrXWPwge99b20UsxWyGtUoqwX2CVNo5gd/ esn9ATWYW60kRYUaWWMuFqkKTaMaN8tZG2aRsxOl6h07aUdRctOxWOVjjeqghJCyYKRC+EFJk/CD 2M62pD5oK0m3oAQunPMxsWzpLGEKO0Ta850w9aWLdvpDzEaUsjX8qQ0la8rHPkK6j5khaj3bWaOW 9oamHeN0DcrN8qIxtNQVUvHuqle8unesZu2BfEU6hCv8YAs+qG8SriD/BNwOIb8+qO0PcuvW+qJU pe5lr4JZyle/pSxlxBXsPWvFLYHFiLF35OojiYlU6WK3ukG9rnMVelVVXrbEBk3tQaW5YRCLNquW xahVuxojsnIhrSPdgmxvW1Lb0rakV9ivkGc7YLeStLd0+Go8ggu+1vnsdYAMLLciCAPlzke8j/Vw D6H73IJGssOYxbL77OTVvLJXEPEd6Y+FgIXY6ni2V6hvf2kb2zmDtL8jfa2RQ9rbMITsvexlKQhg MOi+TW5ya6twwKY2OSgs958xHPGWuWzdSkM2umH+55jb9Ep43Nitbv5BnINcUh3r2LZt9kGb7Ztf +86WwHsu8ki54Fsl/xuiDixd5yxdd+gHH1pqMHhRY7c7XRZO2tiYruSHXdxigC5702J6pYLHSgdZ h/S+2D41tum8ajm3uaS1DbIP2DzuHetWwOPOLQpMcAK15vfAhwguS4/3QCe7rp1+q/KMgCjQZ2u6 2cwGOKVDjGwNQztMjyNrJD490mxjm82n7rZ934xt/rb54aoet33rDFL8YiEJPSCFyE1gghvM1we0 VulC5A0DXc+S3t/TN4142O8RW1LDCWWuzS09WRHv/OBf6nR7h87aAo+6vkiP836RDm42CyHOrf7v xSfe6nCL2twhFbnWSVEBdveABTd4NzrVmeuW+/XlfrWyjCJ9zIETNf/ZcMdHzn9ebKBzOj9HIXC4 kf7mpPt94g5n82wlHmofvDkJT49t1kXej60/wAMiBbsJ0FrrGZR93oWO+Q16xPZiut3LPK/7lyvL 4fTaHZxEUfh7P0rgpw+hzVxwuKll7/elH73qgi/pf/krW9lewQdbp4DWO/D43LaVBSdI/gl8YAou WD7Xssz1DeIgbDCTV5KiD3jo5256goOY+wY/vSvnw9o7D/j1Tm8zFoYw+4iHuv21vfjsnR5/w8t2 1UIA/gMq0AHiN57xsNZWycduJMcFg8AFVzAFN3ADV6B2+cFvnTdMEPhzjqRz3ed92TeBF6hC8mNC HLh20GV6MgaCPSL/dOhkVuBmcUmxgoKHdOqXfu8nezI4f99GW/pHfI5HCh1gfAQGcidgAsg3gECy Zf/Wc8tEXqWHhKEXgsm0RU1YFJ4kQh94YSImhdfVgTUSfvmxXu9lBx+lexbHBewXe1zAZn/ndy+Y hjDIY6W2ba3mAxXwADgohzoocjzIVj6gfD/4g5QxhMPkc5eFfQLneUvoYoTIU8fWE1HoWWhUOgAX Q9zVcwx1P42IhR7YbM6UYdsFiTg0RDDkIyaoBEmgX6PYZkqwfldQhi/IBbB3X+infkwng2qIBa2W fj4gfCLXf463VgGWfz6AAitgAiiwA8JYAkMQJIIIiBElZtl3hIlo/4Sgh4jWN2xDEYUyxlSfhI3a CFVRZVrbhD9NZUBYqI2WSI4duI1yZIXZCIqRAQfsJ2pulhRcwFtK8HqmFntbYI/ohxQwiAWzN4oW R25DAJAA+V8e8AAjkIMi91oCln+/N4zDKIzBGAFXIDzUiGwFFUbgB2k7d1TMKI2QYY3gaI7mOI7g KECW2I0p6VTluIgjmZIveZLrWI7q6IglWBQLUQdiCHhbsH5ckBRDwIpmKJRCiYpIsX5qKINOl1tH 93ElJQJa5wEjgIsidwKkRmq1lYd6mHweQAFYoD1FiIFOGI3OpoxmWZaAuIHEZJI22UPftUltKZM5 JJcrOZNx2WIuWf93PRWTTVWTMHkoj6GK9PeTPymPrtiT+YiAQUmPfLeCSbCTZ+gDcfaCUGcC+2eZ DyB8jUd8JpCV/4VbWtluQEhyIlABPiB+WSKSd4mSUWWTbEmTr6mSKumS3NiXdmmbe7matemavFky itEFP1CYvUVrSiAEtFaYOvaTQ7CCp7icK4iKzhlnSOF3qvaO7YcCpJABGRCHD2ACIoCDJrBfonZb v7gDwIgDytcBEVACp4maT8KNtPmXt8mb8Smb2BibLFmSJEmfMKmfvdmaAEojDdQFR2aAYAUGcUCc sddbJ8WgvcVm84gFYkiPQCmd0tlaJgWD2eYDLGACB/kAMzAFU1D/At2pahyHW2AHdsDIlQ9QAhHQ nu7ZJPDZknV5m/Wpn/UJSk9Fo7apoz0Kl0vFl7sJm1pYJIrBBTvAAjiwAhKKYOIEB2BwnMLpoMpZ jz3pnMx5ikspoUkAi5OZfjoWUutmmSaQX234aua5AjegoibQARVQmjAao0zyiT4Uji/0iHTakvk5 SXYKn53Ip6pZp5olerVZqHd6k0XBBSYwlSRHUrQ2V3hFB+R0nCc1hr0Fe/6Ij/g4nXFmasupof/I dyAVf09Hqr94AimafCuwf9+5g3IKdMhUpMJypCYwCgDwAANAcss3brQWB2FgV3UQB1FKa1iwgoWJ pVaKirSVnAZ2/6y/x3SmFmCj9nAb5wM4YJ7maQLZ2qIREIdx+qpjplOyOquJagIO8AAJcau32p0m gAPjJqEo1V7BOqwOWq+sWI83toJbQGs/MJzHmWrm5opHF2T1FVIrAJHm+YP9N5UiAAA9AK5294zm woU/0AEQgKvo+gCjMAoDsJ4o4HSEyQXCOlZhgFLEeVJCcFIot4Lr5gEkOnn+6lHzGHhK54bDuKTD qLAdQAHr2Q/fCrFAOy0NpAQW+wACgLEXmxB0WKYpW6xBKaVhICgLIawyS5jql5hYEIwE2HXLJ6W8 JaVqaFKutaaouqY3wH8dMJVT+QCVEbRuK7SKkQRFGwAZq3UQQP98HtADpkhriSml5YSg5zSpxxmU PkByXmetZUpr+aUE6/ZuxFlxBdsDZtsDK7CklrmzatsBHmBrb9u5mdJAQ3AQmICxo7B1eWtSP4AC AQavUkpr5ISgsEu15HQFhouqaJV//FoCJ/BpJddahkedX+cDlZuilhkBaUsBa+sBnru8rNJAPmCx EEC3CXGuo3CxxWdSLIAC2Zu9P/C0HvW9XOAFclUHcgUHYaAELOABhytS2EkK1guE7joE8uVwIGW2 KXoDKFACHaC/PFuaD3ACzBvAlzK0Ine0l7B1xGeaPqAEqYsCLaC9KBDBPwC+XgCl4ptSUauo7MaL lkkBlnm0pOD/AJQBcoj3gmg1vPZ7kOp5vJr7AD8rwDBMJ0NLfA5wCQlRvVHZAyY1kD9gARDMAiwQ nCjVBWDQBeIrvsMYvnTwiyR1XyYAAHg7ALcaAbjYVqyIdNZauSjcoazKsy7qv20bw2Isw7+Jgwlx CdZbhwpcrPtKrA+svR4VpRXMBeVLAAAAACZQsjuQVmjlAQKgvgeptAzwABEAAWW6j63VA8unpCyw Az3Qptx6vKzaAQY6xpbMJgNKfKBgtKK7dSUnBM7ZujJrxFBqvkZMB1wgAAAQAABggD6wnhrLrh7A nRRAfBAgwswnpSAnX5KrxSjQf+rJvyOwv1R8yca8Jl5lmZ/w/wDnmsZ06AGvBYut6wVcEKXk5AVd YL7mS6IAQABw4AVKQHIX651v6gEuGwGlSXwowMD0eGOqO7zy9YNy2H8UIAL94KIdYAKce8z8rFo9 kZOWWbpH68xy2K7v2s7HGaXfDAZQKqwOrbhb4IUeSgD+a7ePJ3wdsLuD+3u1q8U4cLn9h87858Ud gAP9fNJB9xjAFwAXS71ad8+vJZ1Pe5zfXM0V7AWxWwdgYAdzxQXBSAoJWRBSfMeVUAEJ6QPDepyF i7zIu6i4yNT+W5oicJAsUMkofdVQUkTPK9Ad4ACFTArCZ9D1xaCty9Di61va7GcOXW0TbQJSrMpE DQCXMABQ+f8DcNC6heuhJsCzuKiemdmzTB0BJlCRWF3YRPQY4Uy3zNwBICx8CQnNkomlfhu+UUq1 UXvZXBMGj0x8IiAQcX3HR9vNJFeyUprX5jwCmPkAIlDPb8qqsGwCvuUmdJdTRTrb9GDb1aiWpTct uF0cgfnI/yeHEFDIYR12BhaU/qrQRyxXzC2+YZCgJEeHn83KtywAUiyHPgClSt116ksBHvB/xtt/ HpDOJfqrsq3b2YXbvb3bLbLekMXb6M0lilEHBvuhuYiQj/da9fh7jssFC/23a/3c5MsF8jwCdvzZ 3XzHCSkAJWAC1EzNN2a46jsCJDrPpOCiTP2/Vs0m7g2Fut3/4T73aONKWfA94vINFDYmUtGtwpnZ ncatdD5g3K5bThWM2WCgUkMQ3RTQAAge17h6qxWwBVWb1ybQdfwnctFLxWrbnUPggGkC4iSE3lDu I1OeRyUuoJChk0UmXx1KpvktmVT6mSZ7wc2dZA9NcrrY4wiO3YLb5RKe2gShthjdAwa6z2NS5TCC 5zei58TmKnzuE8OBygPGy193A8IYUqF8nHE2xNccuwgaMjpJcgdJAaus5kT9eCcAvh8t6R5q36Tw 3S76v0pg508e31lo6n5o4iEeLH8eK8ghqayHYyNVrP5qstXs31Hr6Dx9TkVuAg1gAp5t6beqvjit uIZ77KTQ/w9yXnymUCfOpWkfeXNy132ZZlnOJuWk5InP1udJaHD7VEeS9ozgLu2RiJZPQ37jFOuN nF9tfJzXbMrk5NCw2ydgVbgkGoeVTtQMoO8UTXJwILMdyoeSDtZuKtUPQOekXupwp5EXCZLwQHfV 3ufMdGmUKK7RLka33fDOOFQVz4zJyIgIFUDTGJaunh/pznAoZ7KTuvKvGwcpldaR3nXdCQE0n+8C 4QAXO8t5bLKKfLDH3njLPtjm3YVqwvFgdHPifvTs/d5W3lnjJbHLKGYfb2yj1/Aff4gbr4EhP/FT PyUvIk7UzMCOSmtyjMryfsTnVAfma+ge2p0gzMoFXbze6f8DckVr2XoDWouZ3r22icsnNVdUKcZs FQjx1F5NKzaIFOhdit9ThK+Fgw/4jL9ikC9wGeiRMRb5mK8pLcK5qCyGIuXu5UROzH3Z5uuFe7jX qZ2LVCzpQ1BOGnzsaM6toQ7bSpbwYfL3TV/uTq/7dUrivo9JmxhZv4+nybb0TM+n3F7u3Lf7Tr/8 GGh9mi8jZCWsimt8vXXN5XvZar8QQ4ADStqmey2HyNt1aE7n5vuTLPB1Al+85syZP7DTRM/hkt9l y/bsIlj42m7t0Dh6Xcb7zJ/7gGAnOEhox3NYSHjIM7jImOjYiJhoOElZuKhoqfmImSm5Cdp5SZqI VIqamlj/J8h6WcfF5bOC4iMUCwcWp0sXthu35eOT1ONhcox8XHGiVNfF1aWEs3KDcsJyUjFC0eHx QOHDRemqWm5+jk75KbgOOenY7j7qOX8ZT3rPvrkOH6qaX6kTwID//NkzqE8gQoIJD9aTt88gwHYD B6I7lQ4dq42rKMXyceIYi3DQwsAxGYaOFy5JhGARgkPbsRIRTPi4EqaLzi4wWexgceNEyAceRjzo gIILnYxMmzotRXEhv34SqVIt+FAdwqijrGbVmnWq10ipLHIaa6li2q1VrXIC6/Bt3KeCMNJFVaeH TTCtUMV5hsWH3mM3fPxQ6qVOHV2xlMQSIuyHkCtcTOqE/4ZlBQ6g145REFGBgs0ucQqRu4s6NT25 cEX1o4f2K2tUEyPOG4t1bsDYubHybqi79m20s0HpZtiarl3ViXzcuHHMx2k7rqbbAfNMiQ8WLJDV 2gKNrxc6scrHGu8F+2WYPn5Ou6GNwggPPcQNmm6duf50XPG1hVccU2YZlxxysJEFFVsKyWbOgMD1 lpxwZ5HVnzzHqcWgOcvtZwcXJjxnwggmoJBEF69Q4ksswbSHDA7CKNGFF/cJ0gsc0DxDxw82CbMD Csc8AJoJzXBIpID+VFggWGtlCCFtCgYIEYMSPuiUgwY6+ZVYweWDJJQGYojahvp5YYIxJXh2TH35 zWjaeP+x/CAMLdEN4xg0uKS30jNJmMDFSlx4sIIJNXmQRBhsUldkov7Vw9VDFD6ZEJNYljPlg5U6 5OiSkiYoKYJYZrrklmHZpmSBnooSZqJKnBmfUcqMhmisaxKiGHaOXVEnZMIYVp6Nz3QBEhfYcWHN NvQpVcqsiup3TzxcamoqpJM2iSqBuyWJraeXLtqgtFdSWemzpGbrbFupialaGCGaQFQFx3Qgggkh oTBkOdbVkZKMcTjzzIq7DlGeYLXsesyxpcWK8LIKRxrgqdqWa1vElC4E24GzOTzgw412ZaWVu3Ec CsbjWsiwayBjOmHFZ51bJBcdmECBMUQ9cExIPplQX0f/sp7DShw5cTFEEsKMtGsP7QHlLhZ8kaLs wszhFuVrE151INVlxQbya13+djXUJkvdNXFTg/21yBdy/W3Zp35MtnJE1lFmUex64MGgHpyAgwkV gJQER/rREUd5V+wKFAs49OjD0jvr7HSRbmEKYNRrR9o2p2JTHkmXbE++aOZHetUt2phzDvpq0V6l edWMiFv5U+imNlMFD8xsE00nrGDMdifknGxfi4+zShjmvZRELI0fbznFlH+qPNvoYM0ogqk7z9+j o3LeuddVh339cZhba1bkGDaf0et31fGDNx50s/4xBDygVwQ+vDDiCsxU53sqTVOiUi+7MJ0/5Alw gAQs/6ABD4jAA5oPNUIQFM244Q0ImAAHovFBBnBWsx6YyDT5I8dp8JewQ50ohAFMoAlPiMIUqnCF C1vgXbhwhUAJ6mXdCIkJsIEzut1NXlzYn0ZYCMQgCnGIRCyiU1x4l5UMpRvIoBkKeqS3E3RAdzYh oRGviMUsanGLV0Ti+WRRMM/ALxk4OJMPRBSoHoCQi2xsoxvfCMf9eBE1YMhME/XyABuywAPWAMeI QmKfEsZxkIQspCG5OEfUBM4H3qHZCkbwSBMEKm/GgGIgD4nJTGpykyZMJGqcsZ1k6M0EZ5oGYbqD xy34kJOsbKUrX6kh5C0yGSJ4QC0o4KNQCqUDD4jAGv/j2Czy3cVjXeMiMVE4FVgS0ZOqgYUQBlMz Y8AHOoRi1+yUgEmzLeuYnNrmpp4nTBV+gpvKFCAzmbNIGyLDXT0Ahw94SbMeHjJyVCoiOcH5zXPc E4HjDGc5CXhO/TyDkaKMjjXjmU2NZXGfoeMQOddGT4JoTEvAyQTY6GnR1SFCZCGL6D8pEVD9/Iyg 8prgQW1iqHliVFOykRr0FsTSjbE0eY9wi0snKpWLYo96o1Pb6GoaKomK76aes5pRrfZRUyQQFkMA yTECNbt4wiGhGgWqVUmHOuj1dHPvoBpSx1ZV3nj1qz/dKkQYUtSrVrSrViVQPxXiVrG09VrWq2dS BxH/UiLZaAh5cyDNfJBSlVa1IWklmVDZ2lYt1bWwFGVNRtmK1lC99axFtZZjwQfZtX5uQZot1ZeC StGd3tUOeS0SeZpKSndhM5OTfaxlt9fYx2pNsrQlq8mQ41quhjVLtW2duOLK2eVhdq4Qm+xwLTXT 0YJ0hXt90cGoetvGghW3vQWQYqs7OZvW9qdXNRdhH2e68Br3s7HNbH/GS925ktefriztsuoQOMVB 93vSLVlu05u263I2Y63dbtpcY9j7dpMdx8WvykKb2ciq18D1vZZyCeHeBw8zYmF1sFwqi9wKH9Y4 jEWvZgf7XbVu+FsdTvDK3qphBBMXsZ1tMZJQ7GAP/ys3whJ+SnHNClYQM5iowB2qR7mLX+sS9cdc xfH2vlbgx5UOxbtFb3lXymMFt1eIq2xjMGHKW689OajplR72uAbjj00te8ntXJQcG9MTJ9h6g30x hY8s5f8eksY1rrOd7/xROuN5z3zuMyH17OdAC3rQQwQ0oQ+N6EQP0NCKbrSjH60aRkN60pSuNCok belMa3rSmN60pz896E6DetSkrrOoS43qVJfz1KputaszCWgk8IADr661rf8c6Vnfete83mKsdd3r YAs7iL+m9bCPjewEFjvZzG428pbt7EIAYNrUBgAsrc2Uak9bFdi2w7YH2O1gQzvagwi3IMy9SXRz G//d6pb2uQ3YbluPm9zeTkS3q11ub1ub2oTAd737fW5+v/vb/Rb4vwGOcH/Xm9/+Vri+702KcCt8 3wJ3uMEfDvFtX7zgEB/2vMnN7nfnW98BF7nEDz7whKv75Jcw975Vnu+Om3zk99b4zGkucpRju+Ms /7bP7Y1zj+fa2PRG+c2PzvOEB/3opYj3wXeu9Ji3POc5rznVg95uqLt76TIfOcKF/fFoa5vgY6/6 0v/Nc21fXdob3zra1a5zo0/853KnesOvfne3o93rIdd7r8Pu7K4b3exMz7jXvw70tbtb8HaP+9pf 7vinY/3rWkd85Rnfd7APveiNPzzfz254xWcd8ZT/gPzg4971kFd+752/fNQtT/jBZ17cm+e8yw/v +sLD/uyUd3rndS9zui+86rknOeufnvuef97tq/977Yue+YkvH+N+l37LbX56vBv85BXH/sNprnGC Bxzyq2d4ucVvfckTn/G7BjznA+1037+/ce6ff5/FX3L7I7D++udz2fu/f88HgAMIgPxHgAfobAaI gAt4bArIgA/Iaw4IgRP4ahJIgReIahaIgRv4aRrIgR9oacWGBCNIgiVogieIgimogivIgi3ogi8I gzEogzNIgzVogzeIgzmogzvIgz3ogz8IhC74NC9FhEVohEeIhEmohEvIhE3ohE8IhVEohVNIhVVo Y4VIqB8coIVbyIVd6IVfCIZhKIZjSIZlaIZniIZpqIZryIZt6IZvCIdxKIdzSId1aId3aIYgqId7 yId96Id/CIiBKIiDSIiFaIiHiIiJqIiLyIiN6IiPCImRKImTSImVeIiBAAA7 ------=_NextPart_000_01BC2B74.89D1CCC0-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 28 11:39:19 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08979 for ; Wed, 28 May 2003 11:39:18 -0400 (EDT) Received: (qmail 29578 invoked by uid 605); 28 May 2003 15:39:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29571 invoked from network); 28 May 2003 15:39:08 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 28 May 2003 15:39:08 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4SFcpLv029317; Wed, 28 May 2003 08:38:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SFcoNg009760; Wed, 28 May 2003 09:38:50 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h4SFa8Qx019258; Wed, 28 May 2003 08:36:08 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h4SFa8jG019257; Wed, 28 May 2003 08:36:08 -0700 (PDT) Date: Wed, 28 May 2003 08:36:08 -0700 From: Nicolas Williams To: Chris Lonvick Cc: ietf-ssh@netbsd.org Subject: Re: Pulling it all together - New Section 11 on Security Considerations Message-ID: <20030528083608.A19253@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from clonvick@cisco.com on Wed, May 21, 2003 at 12:36:49PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list I like it. But I've one nit about the MITM section: it speaks of two MITM possibilities, describes a "first" case and *two* "second" cases! Cheers, Nico On Wed, May 21, 2003 at 12:36:49PM -0700, Chris Lonvick wrote: > Hi Folks, > > Below is the latest version of the Security Considerations section. This > reflects all of the discussions on the lists on the various parts of this > over the past few weeks. I appreciate all of the feedback and help. > > I've also put together an html document of the changes from the previous > version; red strike outs for deletions and green text for insertions. > I'll put it on a web server and send around a pointer rsn. [The server > isn't doing so well today but I think it will be fixed in the next day > or so.] If you'd like to see that sooner rather than later, please email > me directly and I'll send it to you. > > If you would like to suggest any changes, please call out the relevent > section in the Subject line of your email. Also, please remove the > non-related sections from your reply as this thing is getting a bit long. > > Thanks, > Chris > > ========================================================================== > > > 11. Security Considerations > > In order to make the entire body of Security Considerations more > accessible, Security Considerations for the transport, authentication, > and connection documents have been gathered here. > > The transport protocol [SSH-TRANS] provides a confidential channel > over an insecure network. It performs server host authentication, key > exchange, encryption, and integrity protection. It also derives a > unique session id that may be used by higher-level protocols. > > The authentication protocol [SSH-USERAUTH] provides a suite of > mechanisms which can be used to authenticatethe client user to the > server. Individual mechanisms specified in the in authentication > protocol use the session id provided by the transport protocol and/or > depend on the security and integrity guarantees of the transport > protocol. > > The connection protocol [SSH-CONNECT] specifies a mechanism to > multiplex multiple streams (channels) of data over the confidential > and authenticated transport. It also specifies channels for accessing > an interactive shell, for 'proxy-forwarding' various external > protocols over the secure transport (including arbitrary TCP/IP > protocols), and for accessing secure 'subsystems' on the server host. > > > 11.1 PRNG > > This protocol binds each session key to the session by including > random, session specific data in the hash used to produce session > keys. Special care should be taken to ensure that all of the random > numbers are of good quality. If the random data here (e.g., DH > parameters) are pseudo-random then the pseudo-random number generator > should be cryptographically secure (i.e., its next output not easily > guessed even when knowing all previous outputs) and, furthermore, > proper entropy needs to be added to the pseudo-random number > generator. RFC 1750 [RFC1750] offers suggestions for sources of > random numbers and entropy. Implementors should note the importance > of entropy and the well-meant, anecdotal warning about the difficulty > in properly implementing pseudo-random number generating functions. > > The amount of entropy available to a given client or server may > sometimes be less than what is required. In this case one must either > resort to pseudo-random number generation regardless of insufficient > entropy or refuse to run the protocol. The latter is preferable. > > > 11.2 Transport > > > 11.2.1 Confidentiality > > It is beyond the scope of this document and the Secure Shell Working > Group to analyze or recommend specific ciphers other than the ones > which have been established and accepted within the industry. At the > time of this writing, ciphers commonly in use include 3DES, ARCFOUR, > twofish, serpent and blowfish. AES has been accepted by The US Federal > Information Processing Standards [FIPS-197] and the cryptographic > community as being acceptable for this purpose as well. As always, > implementors and users should check current literature to ensure that > no recent vulnerabilities have been found in ciphers used within > products. Implementors should also check to see which ciphers are > considered to be relatively stronger than others and should recommend > their use to users over relatively weaker ciphers. It would be > considered good form for an implementation to politely and > unobtrusively notify a user that a stronger cipher is available and > should be used when a weaker one is actively chosen. > > The "none" cipher is provided for debugging and SHOULD NOT be used > except for that purpose. It's cryptographic properties are > sufficiently described in RFC 2410 [RFC2410], which will show that its > use does not meet the intent of this protocol. > > The relative merits of these and other ciphers may also be found in > current literature. Two references that may provide information on the > subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these > describe the CBC mode of operation of certain ciphers and the weakness > of this scheme. Essentially, this mode is theoretically vulnerable to > chosen cipher-text attacks because of the high predictability of the > start of packet sequence. However, this attack is still deemed > difficult and not considered fully practicable especially if relatively > longer block sizes are used. > > Additionally, another CBC mode attack may be mitigated through the > insertion of packets containing SSH_MSG_IGNORE. Without this > technique, a specific attack may be successful. For this attack > (commonly known as the Rogaway attack) to work, the attacker would > need to know the IV of the next block that is going to be encrypted. > In CBC mode that is the output of the encryption of the previous > block. If the attacker does not have any way to see the packet yet > (i.e it is in the internal buffers of the ssh implementation or even > in the kernel) then this attack will not work. If the last packet has > been sent out to the network (i.e the attacker has access to it) then > he can use the attack. > > In the optimal case an implementor would need to add an extra packet > only if the packet has been sent out onto the network and there are no > other packets waiting for transmission. Implementors may wish to check > to see if there are any unsent packets awaiting transmission, but > unfortunately it is not normally easy to obtain this information from > the kernel or buffers. If there are not, then a packet containing > SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream > every time the attacker knows the IV that is supposed to be used for > the next packet, then the attacker will not be able to guess the > correct IV, thus the attack will never be successfull. > > As an example, consider the following case: > > Client Server > ------ ------ > TCP(seq=x, len=500) -> > contains Record 1 > > [500 ms passes, no ACK] > > TCP(seq=x, len=1000) -> > contains Records 1,2 > > <- ACK > > > (1) The Nagle algorithm + TCP retransmits mean that the two > records get coalesced into a single TCP segment > (2) Record 2 is *not* at the beginning of the TCP segment > and never will be, since it gets ACKed. > (3) Yet, the attack is possible because Record 1 has already > been seen. > > As this example indicates, it's totally unsafe to use the existence > of unflushed data in the TCP buffers proper as a guide to whether > you need an empty packet, since when you do the second write(), > the buffers will contain the un-ACKed Record 1. > > On the other hand, it's perfectly safe to have the following > situation: > > Client Server > ------ ------ > TCP(seq=x, len=500) -> > contains SSH_MSG_IGNORE > > TCP(seq=y, len=500) -> > contains Data > > Provided that the IV for second SSH Record is fixed after the data for > the Data packet is determined -i.e. you do: > read from user > encrypt null packet > encrypt data packet > > > 11.2.2 Data Integrity > > This protocol does allow the Data Integrity mechanism to be disabled. > Implementors SHOULD be wary of exposing this feature for any purpose > other than debugging. Users and administrators SHOULD be explicitly > warned anytime the "none" MAC is enabled. > > So long as the "none" MAC is not used, this protocol > provides data integrity. > > Because MACs use a 32 bit sequence number, they might start to leak > information after 2**32 packets have been sent. However, following > the rekeying recommendations should prevent this attack. The > transport protocol [1] recommends rekeying after one gigabyte of data, > and the smallest possible packet is 16 bytes. Therefore, rekeying > SHOULD happen after 2**28 packets at the very most. > > > 11.2.3 Replay > > The use of a MAC other than 'none' provides integrity and > authentication. In addition, the transport protocol provides a unique > session identifier (bound in part to pseudo-random data that is part > of the algorithm and key exchange process) that can be used by higher > level protocols to bind data to a given session and prevent replay of > data from prior sessions. For example, the authentication protocol uses > this to prevent replay of signatures from previous sessions. Because > public key authentication exchanges are cryptographically bound to the > session (i.e., to the initial key exchange) they cannot be successfully > replayed in other sessions. Note that the session ID can be made > public without harming the security of the protocol. > > If two session happen to have the same session ID [hash of key > exchanges] then packets from one can be replayed against the other. > It must be stressed that the chances of such an occurrence are, > needless to say, minimal when using modern cryptographic methods. > This is all the more so true when specifying larger hash function > outputs and DH parameters. > > Replay detection using monotonically increasing sequence numbers as > input to the MAC, or HMAC in some cases, is described in RFC 2085 > [RFC2085], RFC 2246 [RFC2246], RFC 2743 [RFC2743], RFC 1964 [RFC1964], > RFC 2025 [RFC2025], and RFC 1510 [RFC1510]. The underlying construct > is discussed in RFC 2104 [RFC2104]. Essentially a different sequence > number in each packet ensures that at least this one input to the MAC > function will be unique and will provide a nonrecurring MAC output > that is not predictable to an attacker. If the session stays active > long enough, however, this sequence number will wrap. This event may > provide an attacker an opportunity to replay a previously recorded > packet with an identical sequence number but only if the peers have > not rekeyed since the transmission of the first packet with that > sequence number. If the peers have rekeyed, then the replay will be > detected as the MAC check will fail. For this reason, it must be > emphasized that peers MUST rekey before a wrap of the sequence > numbers. Naturally, if an attacker does attempt to replay a captured > packet before the peers have rekeyed, then the receiver of the > duplicate packet will not be able to validate the MAC and it will be > discarded. The reason that the MAC will fail is because the receiver > will formulate a MAC based upon the packet contents, the shared > secret, and the expected sequence number. Since the replayed packet > will not be using that expected sequence number (the sequence number > of the replayed packet will have already been passed by the receiver) > then the calculated MAC will not match the MAC received with the > packet. > > > 11.2.4 Man-in-the-middle > > This protocol makes no assumptions nor provisions for an > infrastructure or means for distributing the public keys of hosts. It > is expected that this protocol will sometimes be used without first > verifying the association between the server host key and the server > host name. Such usage is vulnerable to man-in-the-middle attacks. > This section describes this and encourages administrators and users to > understand the importance of verifying this association before any > session is initiated. > > There are two cases of man-in-the-middle attacks to consider. The > first is where an attacker places a device between the client and the > server before the session is initiated. In this case, the attack > device is trying to mimic the legitimate server and will offer its > public key to the client when the client initiates a session. If it > were to offer the public key of the server, then it would not be able > to decrypt or sign the transmissions between the legitimate server and > the client unless it also had access to the private-key of the host. > The attack device will also, simultaneously to this, initiate a > session to the legitimate server masquerading itself as the client. > If the public key of the server had been securely distributed to the > client prior to that session initiation, the key offered to the client > by the attack device will not match the key stored on the client. In > that case, the user SHOULD be given a warning that the offered host > key does not match the host key cached on the client. As described in > Section 3.1 of [SSH-ARCH], the user may be free to accept the new key > and continue the session. It is RECOMMENDED that the warning provide > sufficient information to the user of the client device so they may > make an informed decision. If the user chooses to continue the > session with the stored public-key of the server (not the public-key > offered at the start of the session), then the session specific data > between the attacker and server will be different between the > client-to-attacker session and the attacker-to-server sessions due to > the randomness discussed above. From this, the attacker will not be > able to make this attack work since the attacker will not be able to > correctly sign packets containing this session specific data from the > server since he does not have the private key of that server. > > Insecure distribution of server public keys allows a second type of > man-in-the-middle attack that should also be considered in this case; > one with suitable but incorrect host keys. If the server public keys > are not securely distributed then the client cannot know if it is > talking to the intended server. An attacker may use social > engineering techniques to pass off server keys to unsuspecting users > and may then place a man-in-the-middle attack device between the > legitimate server and the clients. If this is allowed to happen then > the clients will form client-to-attacker sessions and the attacker > will form attacker-to-server sessions and will be able to monitor and > manipulate all of the traffic between the clients and the legitimate > servers. Server administrators are encouraged to make host key > fingerprints available for checking by some means whose security does > not rely on the integrity of the actual host keys. Possible > mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also > include secured Web pages, physical pieces of paper, etc. > Implementors SHOULD provide recommendations on how best to do this > with their implementation. Because the protocol is extensible, future > extensions to the protocol may provide better mechanisms for dealing > with the need to know the server's host key before connecting. For > example, making the host key fingerprint available through a secure > DNS lookup, or using kerberos over gssapi during key exchange to > authenticate the server are possibilities. > > As a second man-in-the-middle case, attackers may attempt to > manipulate packets in transit between peers after the session has been > established. As described in the Replay part of this section, a > successful attack of this nature is very improbable. As in the Replay > section, this reasoning does assume that the MAC is secure and that it > is infeasible to construct inputs to a MAC algorithm to give a known > output. This is discussed in much greater detail in Section 6 of RFC > 2104. If the MAC algorithm has a vulnerability or is weak enough, > then the attacker may be able to specify certain inputs to yield a > known MAC. With that they may be able to alter the contents of a > packet in transit. Alternatively the attacker may be able to exploit > the algorithm vulnerability or weakness to find the shared secret by > reviewing the MACs from captured packets. In either of those cases, > an attacker could construct a packet or packets that could be inserted > into an SSH stream. To prevent that, implementors are encouraged to > utilize commonly accepted MAC algorithms and administrators are > encouraged to watch current literature and discussions of cryptography > to ensure that they are not using a MAC algorithm that has a recently > found vulnerability or weakness. > > In summary, the use of this protocol without a reliable association of > the binding between a host and its host keys is inherently insecure > and is NOT RECOMMENDED. It may however be necessary in non-security > critical environments, and will still provide protection against > passive attacks. Implementors of protocols and applications running > on top of this protocol should keep this possibility in mind. > > > 11.2.5 Denial-of-service > > This protocol is designed to be used over a reliable transport. If > transmission errors or message manipulation occur, the connection is > closed. The connection SHOULD be re-established if this occurs. > Denial of service attacks of this type ("wire cutter") are almost > impossible to avoid. > > In addition, this protocol is vulnerable to Denial of Service > attacks because an attacker can force the server to go through > the CPU and memory intensive tasks of connection setup and > key exchange without authenticating. Implementors SHOULD provide > features that make this more difficult. For example, only allowing > connections from a subset of IPs known to have valid users. > > > 11.2.6 Covert Channels > > The protocol was not designed to eliminate covert channels. For > example, the padding, SSH_MSG_IGNORE messages, and several other > places in the protocol can be used to pass covert information, and > the recipient has no reliable way to verify whether such information > is being sent. > > > 11.2.7 Forward Secrecy > > It should be noted that the Diffie-Hellman key exchanges may provide > perfect forward secrecy (PFS). PFS is essentially defined as the > cryptographic property of a key-establishment protocol in which the > compromise of a session key or long-term private key after a given > session does not cause the compromise of any earlier session. > [ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using > diffie-hellman-group1-sha1 are secure even if private > keying/authentication material is later revealed, but not if the > session keys are revealed. So, given this definition of PFS, SSHv2 > does have PFS. It is hoped that all other key exchange mechanisms > proposed and used in the future will also provide PFS. This property > is not commuted to any of the applications or protocols using SSH as a > transport however. The transport layer of SSH provides > confidentiality for password authentication and other methods that > rely on secret data. > > Of course, if the DH private parameters for the client and server are > revealed then the session key is revealed, but these items can be > thrown away after the key exchange completes. It's worth pointing out > that these items should not be allowed to end up on swap space and > that they should be erased from memory as soon as the key exchange > completes. > > > 11.3 Authentication Protocol > > The purpose of this protocol is to perform client user authentication. > It assumes that this run over a secure transport layer protocol, which > has already authenticated the server machine, established an encrypted > communications channel, and computed a unique session identifier for > this session. > > Several authentication methods with different security characteristics > are allowed. It is up to the server's local policy to decide which > methods (or combinations of methods) it is willing to accept for each > user. Authentication is no stronger than the weakest combination > allowed. > > The server may go into a "sleep" period after repeated unsuccessful > authentication attempts to make key search more difficult for > attackers. Care should be taken so that this doesn't become a > self-denial of service vector. > > > 11.3.1 Weak Transport > > If the transport layer does not provide confidentiality, > authentication methods that rely on secret data SHOULD be disabled. > If it does not provide strong integrity protection, requests to change > authentication data (e.g. a password change) SHOULD be disabled to > prevent an attacker from modifying the ciphertext without being > noticed, or rendering the new authentication data unusable (denial > of service). > > The assumption as stated above that the Authentication Protocol only > run over a secure transport that has previously authenticated the > server is very important to note. People deploying SSH are reminded > of the consequences of man-in-the-middle attacks if the client does > not have a very strong a priori association of the server with the > host key of that server. Specifically for the case of the > Authentication Protocol the client may form a session to a > man-in-the-middle attack device and divulge user credentials such as > their username and password. Even in the cases of authentication > where no user credentials are divulged, an attacker may still gain > information they shouldn't have by capturing key-strokes in much the > same way that a honeypot works. > > > 11.3.2 Debug messages > > Special care should be taken when designing debug messages. These > messages may reveal surprising amounts of information about the host > if not properly designed. Debug messages can be disabled (during > user authentication phase) if high security is required. > > > 11.3.3 Local security policy > > Implementer MUST ensure that the credentials provided validate the > professed user and also MUST ensure that the local policy of the > server permits the user the access requested. In particular, > because of the flexible nature of the SSH connection protocol, it may > not be possible to determine the local security policy, if any, that > should apply at the time of authentication because the kind of service > being requested is not clear at that instant. For example, local > policy might allow a user to access files on the server, but not start > an interactive shell. However, during the authentication protocol, it > is not known whether the user will be accessing files or attempting to > use an interactive shell, or even both. In any event, where local > security policy for the server host exists, it MUST be applied and > enforced correctly. > > Implementors are encouraged to provide a default local policy and > make its parameters known to administrators and users. At the > discretion of the implementors, this default policy may be along the > lines of 'anything goes' where there are no restrictions placed upon > users, or it may be along the lines of 'excessively restrictive' in > which case the administrators will have to actively make changes to > this policy to meet their needs. Alternatively, it may be some > attempt at providing something practical and immediately useful to the > administrators of the system so they don't have to put in much effort > to get SSH working. Whatever choice is made MUST be applied and > enforced as required above. > > > 11.3.4 Public key authentication > > The use of public-key authentication assumes that the client host has > not been compromised. > > This risk can be mitigated by the use of passphrases on private keys; > however, this is not an enforceable policy. The use of smartcards, or > other technology to make passphrases an enforceable policy is > suggested. > > The server could require both password and public-key authentication, > however, this requires the client to expose its password to the server > (see section on password authentication below.) > > > 11.3.5 Password authentication > > The password mechanism as specified in the authentication protocol > assumes that the server has not been compromised. If the server has > been compromised, using password authentication will reveal a valid > username / password combination to the attacker, which may lead to > further compromises. > > This vulnerability can be mitigated by using an alternative form of > authentication. For example, public-key authentication makes no > assumptions about security on the server. > > > 11.3.6 Host based authentication > > Host based authentication assumes that the client has not been > compromised. There are no mitigating strategies, other than to use > host based authentication in combination with another authentication > method. > > > 11.4 Connection protocol > > > 11.4.1 End point security > > End point security is assumed by the connection protocol. If the > server has been compromised, any terminal sessions, port forwarding, > or systems accessed on the host are compromised. There are no > mitigating factors for this. > > If the client end point has been compromised, and the server fails to > stop the attacker at the authentication protocol, all services exposed > (either as subsystems or through forwarding) will be vulnerable to > attack. Implementors SHOULD provide mechanisms for administrators to > control which services are exposed to limit the vulnerability of other > services. > > These controls might include controlling which machines and ports can > be target in 'port-forwarding' operations, which users are allowed to > use interactive shell facilities, or which users are allowed to use > exposed subsystems. > > > 11.4.2 Proxy forwarding > > The SSH connection protocol allows for proxy forwarding of other > protocols such as SNMP, POP3, and HTTP. This may be a concern for > network administrators who wish to control the access of certain > applications by users located outside of their physical location. > Essentially, the forwarding of these protocols may violate site > specific security policies as they may be undetectably tunneled > through a firewall. Implementors SHOULD provide an administrative > mechanism to control the proxy forwarding functionality so that > site specific security policies may be upheld. > > In addition, a reverse proxy forwarding functionality > is available, which again can be used to bypass firewall > controls. > > As indicated above, end-point security is assumed during > proxy forwarding operations. Failure of end-point security > will compromise all data passed over proxy forwarding. > > > 11.4.3 X11 forwarding > > Another form of proxy forwarding provided by the ssh connection > protocol is the forwarding of the X11 protocol. If end-point security > has been compromised, X11 forwarding may allow attacks against the X11 > server. Users and administrators should, as a matter of course, use > appropriate X11 security mechanisms to prevent unauthorized use of the > X11 server. Implementors, administrators and users who wish to > further explore the security mechanisms of X11 are invited to read > [SCHEIFLER] and analyze previously reported problems with the > interactions between SSH forwarding and X11 in CERT vulnerabilities > VU#363181 and VU#118892 [CERT]. > > X11 display forwarding with SSH, by itself, is not sufficient to > correct well known problems with X11 security [VENEMA]. However, X11 > display forwarding in SSHv2 (or other, secure protocols), combined > with actual and pseudo-displays which accept connections only over > local IPC mechanisms authorized by permissions or ACLs, does correct > many X11 security problems as long as the "none" MAC is not used. It > is RECOMMENDED that X11 display implementations default to allowing > display opens only over local IPC. It is RECOMMENDED that SSHv2 > server implementations that support X11 forwarding default to allowing > display opens only over local IPC. On single-user systems it might be > reasonable to default to allowing local display opens over TCP/IP. > > Implementors of the X11 forwarding protocol SHOULD implement the magic > cookie access checking spoofing mechanism as described in [ssh-connect] > as an additional mechanism to prevent unauthorized use of the proxy. > > > References from this section: > > [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication > Service (V5)", RFC 1510, September 1993. > > [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", > RFC 1964, June 1996. > > [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness > Recommendations for Security", RFC 1750, December 1994. > > [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism > (SPKM)", RFC 2025, October 1996. > > [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay > Prevention", RFC 2085, February 1997. > > [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: > Keyed-Hashing for Message Authentication", RFC 2104, > February 1997. > > [RFC2246] Diercks, T. and C. Allen, "The TLS Protocol Version > 1.0", RFC 2246, January 1999. > > [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its > Use With IPsec", RFC 2410, November 1998 > > [RFC2743] Linn, J., "Generic Security Service Application Program > Interface Version 2, Update 1", RFC 2743, January 2000. > > [SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley > and Sons Publisher, 1996 > > [KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in > a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner, > Prentice Hall Publisher, 1995 > > [FIPS-197] National Institute of Standards and Technology, > "Specification for the Advanced Encryption Standard (AES)" > FIPS 197. November 26, 2001. > > [ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom > Glossary 2000", American National Standards Institute, Inc., > Approved February 28, 2001. > > > [SCHEIFLER] Scheifler, R., "X Window System : The Complete > Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd > edition.", Digital Press ISBN 1555580882, Feburary > 1992. > > [CERT] The CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > U.S.A. > ( http://www.cert.org/nav/index_red.html ) > > [VENEMA] Wietse Venema, "Murphy's Law and Computer Security", Proceedings > of 6th USENIX Security Symposium, San Jose, CA, July 1996. > http://www.usenix.org/publications/library/proceedings/sec96/venema.html > > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 28 12:16:47 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10604 for ; Wed, 28 May 2003 12:16:45 -0400 (EDT) Received: (qmail 20844 invoked by uid 605); 28 May 2003 16:16:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20836 invoked from network); 28 May 2003 16:16:28 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by mail.netbsd.org with SMTP; 28 May 2003 16:16:28 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h4SGGMNb000535; Wed, 28 May 2003 09:16:22 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA28107; Wed, 28 May 2003 09:16:22 -0700 (PDT) Date: Wed, 28 May 2003 09:16:22 -0700 (PDT) From: Chris Lonvick To: Nicolas Williams cc: ietf-ssh@netbsd.org Subject: Re: Pulling it all together - New Section 11 on Security Considerations In-Reply-To: <20030528083608.A19253@binky.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi Nico, I agree it's awkward. It was suppsed to be two "types" within the "first case". For those that may not have yet gotten to that section, the first case is an active mitm with the first type being on the first connection attempt when the client has not previously seen the key of the host, and the second type just noting the subversion of the distribution of the host keys prior to the first connection attempt. I'll rework it to make it clear and get that back out. I appreciate the review. Thanks, Chris On Wed, 28 May 2003, Nicolas Williams wrote: > I like it. But I've one nit about the MITM section: it speaks of two > MITM possibilities, describes a "first" case and *two* "second" cases! > > Cheers, > > Nico > > > On Wed, May 21, 2003 at 12:36:49PM -0700, Chris Lonvick wrote: > > Hi Folks, > > > > Below is the latest version of the Security Considerations section. This > > reflects all of the discussions on the lists on the various parts of this > > over the past few weeks. I appreciate all of the feedback and help. > > > > I've also put together an html document of the changes from the previous > > version; red strike outs for deletions and green text for insertions. > > I'll put it on a web server and send around a pointer rsn. [The server > > isn't doing so well today but I think it will be fixed in the next day > > or so.] If you'd like to see that sooner rather than later, please email > > me directly and I'll send it to you. > > > > If you would like to suggest any changes, please call out the relevent > > section in the Subject line of your email. Also, please remove the > > non-related sections from your reply as this thing is getting a bit long. > > > > Thanks, > > Chris > > > > ========================================================================== > > > > > > 11. Security Considerations > > > > In order to make the entire body of Security Considerations more > > accessible, Security Considerations for the transport, authentication, > > and connection documents have been gathered here. > > > > The transport protocol [SSH-TRANS] provides a confidential channel > > over an insecure network. It performs server host authentication, key > > exchange, encryption, and integrity protection. It also derives a > > unique session id that may be used by higher-level protocols. > > > > The authentication protocol [SSH-USERAUTH] provides a suite of > > mechanisms which can be used to authenticatethe client user to the > > server. Individual mechanisms specified in the in authentication > > protocol use the session id provided by the transport protocol and/or > > depend on the security and integrity guarantees of the transport > > protocol. > > > > The connection protocol [SSH-CONNECT] specifies a mechanism to > > multiplex multiple streams (channels) of data over the confidential > > and authenticated transport. It also specifies channels for accessing > > an interactive shell, for 'proxy-forwarding' various external > > protocols over the secure transport (including arbitrary TCP/IP > > protocols), and for accessing secure 'subsystems' on the server host. > > > > > > 11.1 PRNG > > > > This protocol binds each session key to the session by including > > random, session specific data in the hash used to produce session > > keys. Special care should be taken to ensure that all of the random > > numbers are of good quality. If the random data here (e.g., DH > > parameters) are pseudo-random then the pseudo-random number generator > > should be cryptographically secure (i.e., its next output not easily > > guessed even when knowing all previous outputs) and, furthermore, > > proper entropy needs to be added to the pseudo-random number > > generator. RFC 1750 [RFC1750] offers suggestions for sources of > > random numbers and entropy. Implementors should note the importance > > of entropy and the well-meant, anecdotal warning about the difficulty > > in properly implementing pseudo-random number generating functions. > > > > The amount of entropy available to a given client or server may > > sometimes be less than what is required. In this case one must either > > resort to pseudo-random number generation regardless of insufficient > > entropy or refuse to run the protocol. The latter is preferable. > > > > > > 11.2 Transport > > > > > > 11.2.1 Confidentiality > > > > It is beyond the scope of this document and the Secure Shell Working > > Group to analyze or recommend specific ciphers other than the ones > > which have been established and accepted within the industry. At the > > time of this writing, ciphers commonly in use include 3DES, ARCFOUR, > > twofish, serpent and blowfish. AES has been accepted by The US Federal > > Information Processing Standards [FIPS-197] and the cryptographic > > community as being acceptable for this purpose as well. As always, > > implementors and users should check current literature to ensure that > > no recent vulnerabilities have been found in ciphers used within > > products. Implementors should also check to see which ciphers are > > considered to be relatively stronger than others and should recommend > > their use to users over relatively weaker ciphers. It would be > > considered good form for an implementation to politely and > > unobtrusively notify a user that a stronger cipher is available and > > should be used when a weaker one is actively chosen. > > > > The "none" cipher is provided for debugging and SHOULD NOT be used > > except for that purpose. It's cryptographic properties are > > sufficiently described in RFC 2410 [RFC2410], which will show that its > > use does not meet the intent of this protocol. > > > > The relative merits of these and other ciphers may also be found in > > current literature. Two references that may provide information on the > > subject are [SCHNEIER] and [KAUFMAN,PERLMAN,SPECINER]. Both of these > > describe the CBC mode of operation of certain ciphers and the weakness > > of this scheme. Essentially, this mode is theoretically vulnerable to > > chosen cipher-text attacks because of the high predictability of the > > start of packet sequence. However, this attack is still deemed > > difficult and not considered fully practicable especially if relatively > > longer block sizes are used. > > > > Additionally, another CBC mode attack may be mitigated through the > > insertion of packets containing SSH_MSG_IGNORE. Without this > > technique, a specific attack may be successful. For this attack > > (commonly known as the Rogaway attack) to work, the attacker would > > need to know the IV of the next block that is going to be encrypted. > > In CBC mode that is the output of the encryption of the previous > > block. If the attacker does not have any way to see the packet yet > > (i.e it is in the internal buffers of the ssh implementation or even > > in the kernel) then this attack will not work. If the last packet has > > been sent out to the network (i.e the attacker has access to it) then > > he can use the attack. > > > > In the optimal case an implementor would need to add an extra packet > > only if the packet has been sent out onto the network and there are no > > other packets waiting for transmission. Implementors may wish to check > > to see if there are any unsent packets awaiting transmission, but > > unfortunately it is not normally easy to obtain this information from > > the kernel or buffers. If there are not, then a packet containing > > SSH_MSG_IGNORE SHOULD be sent. If a new packet is added to the stream > > every time the attacker knows the IV that is supposed to be used for > > the next packet, then the attacker will not be able to guess the > > correct IV, thus the attack will never be successfull. > > > > As an example, consider the following case: > > > > Client Server > > ------ ------ > > TCP(seq=x, len=500) -> > > contains Record 1 > > > > [500 ms passes, no ACK] > > > > TCP(seq=x, len=1000) -> > > contains Records 1,2 > > > > <- ACK > > > > > > (1) The Nagle algorithm + TCP retransmits mean that the two > > records get coalesced into a single TCP segment > > (2) Record 2 is *not* at the beginning of the TCP segment > > and never will be, since it gets ACKed. > > (3) Yet, the attack is possible because Record 1 has already > > been seen. > > > > As this example indicates, it's totally unsafe to use the existence > > of unflushed data in the TCP buffers proper as a guide to whether > > you need an empty packet, since when you do the second write(), > > the buffers will contain the un-ACKed Record 1. > > > > On the other hand, it's perfectly safe to have the following > > situation: > > > > Client Server > > ------ ------ > > TCP(seq=x, len=500) -> > > contains SSH_MSG_IGNORE > > > > TCP(seq=y, len=500) -> > > contains Data > > > > Provided that the IV for second SSH Record is fixed after the data for > > the Data packet is determined -i.e. you do: > > read from user > > encrypt null packet > > encrypt data packet > > > > > > 11.2.2 Data Integrity > > > > This protocol does allow the Data Integrity mechanism to be disabled. > > Implementors SHOULD be wary of exposing this feature for any purpose > > other than debugging. Users and administrators SHOULD be explicitly > > warned anytime the "none" MAC is enabled. > > > > So long as the "none" MAC is not used, this protocol > > provides data integrity. > > > > Because MACs use a 32 bit sequence number, they might start to leak > > information after 2**32 packets have been sent. However, following > > the rekeying recommendations should prevent this attack. The > > transport protocol [1] recommends rekeying after one gigabyte of data, > > and the smallest possible packet is 16 bytes. Therefore, rekeying > > SHOULD happen after 2**28 packets at the very most. > > > > > > 11.2.3 Replay > > > > The use of a MAC other than 'none' provides integrity and > > authentication. In addition, the transport protocol provides a unique > > session identifier (bound in part to pseudo-random data that is part > > of the algorithm and key exchange process) that can be used by higher > > level protocols to bind data to a given session and prevent replay of > > data from prior sessions. For example, the authentication protocol uses > > this to prevent replay of signatures from previous sessions. Because > > public key authentication exchanges are cryptographically bound to the > > session (i.e., to the initial key exchange) they cannot be successfully > > replayed in other sessions. Note that the session ID can be made > > public without harming the security of the protocol. > > > > If two session happen to have the same session ID [hash of key > > exchanges] then packets from one can be replayed against the other. > > It must be stressed that the chances of such an occurrence are, > > needless to say, minimal when using modern cryptographic methods. > > This is all the more so true when specifying larger hash function > > outputs and DH parameters. > > > > Replay detection using monotonically increasing sequence numbers as > > input to the MAC, or HMAC in some cases, is described in RFC 2085 > > [RFC2085], RFC 2246 [RFC2246], RFC 2743 [RFC2743], RFC 1964 [RFC1964], > > RFC 2025 [RFC2025], and RFC 1510 [RFC1510]. The underlying construct > > is discussed in RFC 2104 [RFC2104]. Essentially a different sequence > > number in each packet ensures that at least this one input to the MAC > > function will be unique and will provide a nonrecurring MAC output > > that is not predictable to an attacker. If the session stays active > > long enough, however, this sequence number will wrap. This event may > > provide an attacker an opportunity to replay a previously recorded > > packet with an identical sequence number but only if the peers have > > not rekeyed since the transmission of the first packet with that > > sequence number. If the peers have rekeyed, then the replay will be > > detected as the MAC check will fail. For this reason, it must be > > emphasized that peers MUST rekey before a wrap of the sequence > > numbers. Naturally, if an attacker does attempt to replay a captured > > packet before the peers have rekeyed, then the receiver of the > > duplicate packet will not be able to validate the MAC and it will be > > discarded. The reason that the MAC will fail is because the receiver > > will formulate a MAC based upon the packet contents, the shared > > secret, and the expected sequence number. Since the replayed packet > > will not be using that expected sequence number (the sequence number > > of the replayed packet will have already been passed by the receiver) > > then the calculated MAC will not match the MAC received with the > > packet. > > > > > > 11.2.4 Man-in-the-middle > > > > This protocol makes no assumptions nor provisions for an > > infrastructure or means for distributing the public keys of hosts. It > > is expected that this protocol will sometimes be used without first > > verifying the association between the server host key and the server > > host name. Such usage is vulnerable to man-in-the-middle attacks. > > This section describes this and encourages administrators and users to > > understand the importance of verifying this association before any > > session is initiated. > > > > There are two cases of man-in-the-middle attacks to consider. The > > first is where an attacker places a device between the client and the > > server before the session is initiated. In this case, the attack > > device is trying to mimic the legitimate server and will offer its > > public key to the client when the client initiates a session. If it > > were to offer the public key of the server, then it would not be able > > to decrypt or sign the transmissions between the legitimate server and > > the client unless it also had access to the private-key of the host. > > The attack device will also, simultaneously to this, initiate a > > session to the legitimate server masquerading itself as the client. > > If the public key of the server had been securely distributed to the > > client prior to that session initiation, the key offered to the client > > by the attack device will not match the key stored on the client. In > > that case, the user SHOULD be given a warning that the offered host > > key does not match the host key cached on the client. As described in > > Section 3.1 of [SSH-ARCH], the user may be free to accept the new key > > and continue the session. It is RECOMMENDED that the warning provide > > sufficient information to the user of the client device so they may > > make an informed decision. If the user chooses to continue the > > session with the stored public-key of the server (not the public-key > > offered at the start of the session), then the session specific data > > between the attacker and server will be different between the > > client-to-attacker session and the attacker-to-server sessions due to > > the randomness discussed above. From this, the attacker will not be > > able to make this attack work since the attacker will not be able to > > correctly sign packets containing this session specific data from the > > server since he does not have the private key of that server. > > > > Insecure distribution of server public keys allows a second type of > > man-in-the-middle attack that should also be considered in this case; > > one with suitable but incorrect host keys. If the server public keys > > are not securely distributed then the client cannot know if it is > > talking to the intended server. An attacker may use social > > engineering techniques to pass off server keys to unsuspecting users > > and may then place a man-in-the-middle attack device between the > > legitimate server and the clients. If this is allowed to happen then > > the clients will form client-to-attacker sessions and the attacker > > will form attacker-to-server sessions and will be able to monitor and > > manipulate all of the traffic between the clients and the legitimate > > servers. Server administrators are encouraged to make host key > > fingerprints available for checking by some means whose security does > > not rely on the integrity of the actual host keys. Possible > > mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also > > include secured Web pages, physical pieces of paper, etc. > > Implementors SHOULD provide recommendations on how best to do this > > with their implementation. Because the protocol is extensible, future > > extensions to the protocol may provide better mechanisms for dealing > > with the need to know the server's host key before connecting. For > > example, making the host key fingerprint available through a secure > > DNS lookup, or using kerberos over gssapi during key exchange to > > authenticate the server are possibilities. > > > > As a second man-in-the-middle case, attackers may attempt to > > manipulate packets in transit between peers after the session has been > > established. As described in the Replay part of this section, a > > successful attack of this nature is very improbable. As in the Replay > > section, this reasoning does assume that the MAC is secure and that it > > is infeasible to construct inputs to a MAC algorithm to give a known > > output. This is discussed in much greater detail in Section 6 of RFC > > 2104. If the MAC algorithm has a vulnerability or is weak enough, > > then the attacker may be able to specify certain inputs to yield a > > known MAC. With that they may be able to alter the contents of a > > packet in transit. Alternatively the attacker may be able to exploit > > the algorithm vulnerability or weakness to find the shared secret by > > reviewing the MACs from captured packets. In either of those cases, > > an attacker could construct a packet or packets that could be inserted > > into an SSH stream. To prevent that, implementors are encouraged to > > utilize commonly accepted MAC algorithms and administrators are > > encouraged to watch current literature and discussions of cryptography > > to ensure that they are not using a MAC algorithm that has a recently > > found vulnerability or weakness. > > > > In summary, the use of this protocol without a reliable association of > > the binding between a host and its host keys is inherently insecure > > and is NOT RECOMMENDED. It may however be necessary in non-security > > critical environments, and will still provide protection against > > passive attacks. Implementors of protocols and applications running > > on top of this protocol should keep this possibility in mind. > > > > > > 11.2.5 Denial-of-service > > > > This protocol is designed to be used over a reliable transport. If > > transmission errors or message manipulation occur, the connection is > > closed. The connection SHOULD be re-established if this occurs. > > Denial of service attacks of this type ("wire cutter") are almost > > impossible to avoid. > > > > In addition, this protocol is vulnerable to Denial of Service > > attacks because an attacker can force the server to go through > > the CPU and memory intensive tasks of connection setup and > > key exchange without authenticating. Implementors SHOULD provide > > features that make this more difficult. For example, only allowing > > connections from a subset of IPs known to have valid users. > > > > > > 11.2.6 Covert Channels > > > > The protocol was not designed to eliminate covert channels. For > > example, the padding, SSH_MSG_IGNORE messages, and several other > > places in the protocol can be used to pass covert information, and > > the recipient has no reliable way to verify whether such information > > is being sent. > > > > > > 11.2.7 Forward Secrecy > > > > It should be noted that the Diffie-Hellman key exchanges may provide > > perfect forward secrecy (PFS). PFS is essentially defined as the > > cryptographic property of a key-establishment protocol in which the > > compromise of a session key or long-term private key after a given > > session does not cause the compromise of any earlier session. > > [ANSI T1.523-2001] SSHv2 sessions resulting from a key exchange using > > diffie-hellman-group1-sha1 are secure even if private > > keying/authentication material is later revealed, but not if the > > session keys are revealed. So, given this definition of PFS, SSHv2 > > does have PFS. It is hoped that all other key exchange mechanisms > > proposed and used in the future will also provide PFS. This property > > is not commuted to any of the applications or protocols using SSH as a > > transport however. The transport layer of SSH provides > > confidentiality for password authentication and other methods that > > rely on secret data. > > > > Of course, if the DH private parameters for the client and server are > > revealed then the session key is revealed, but these items can be > > thrown away after the key exchange completes. It's worth pointing out > > that these items should not be allowed to end up on swap space and > > that they should be erased from memory as soon as the key exchange > > completes. > > > > > > 11.3 Authentication Protocol > > > > The purpose of this protocol is to perform client user authentication. > > It assumes that this run over a secure transport layer protocol, which > > has already authenticated the server machine, established an encrypted > > communications channel, and computed a unique session identifier for > > this session. > > > > Several authentication methods with different security characteristics > > are allowed. It is up to the server's local policy to decide which > > methods (or combinations of methods) it is willing to accept for each > > user. Authentication is no stronger than the weakest combination > > allowed. > > > > The server may go into a "sleep" period after repeated unsuccessful > > authentication attempts to make key search more difficult for > > attackers. Care should be taken so that this doesn't become a > > self-denial of service vector. > > > > > > 11.3.1 Weak Transport > > > > If the transport layer does not provide confidentiality, > > authentication methods that rely on secret data SHOULD be disabled. > > If it does not provide strong integrity protection, requests to change > > authentication data (e.g. a password change) SHOULD be disabled to > > prevent an attacker from modifying the ciphertext without being > > noticed, or rendering the new authentication data unusable (denial > > of service). > > > > The assumption as stated above that the Authentication Protocol only > > run over a secure transport that has previously authenticated the > > server is very important to note. People deploying SSH are reminded > > of the consequences of man-in-the-middle attacks if the client does > > not have a very strong a priori association of the server with the > > host key of that server. Specifically for the case of the > > Authentication Protocol the client may form a session to a > > man-in-the-middle attack device and divulge user credentials such as > > their username and password. Even in the cases of authentication > > where no user credentials are divulged, an attacker may still gain > > information they shouldn't have by capturing key-strokes in much the > > same way that a honeypot works. > > > > > > 11.3.2 Debug messages > > > > Special care should be taken when designing debug messages. These > > messages may reveal surprising amounts of information about the host > > if not properly designed. Debug messages can be disabled (during > > user authentication phase) if high security is required. > > > > > > 11.3.3 Local security policy > > > > Implementer MUST ensure that the credentials provided validate the > > professed user and also MUST ensure that the local policy of the > > server permits the user the access requested. In particular, > > because of the flexible nature of the SSH connection protocol, it may > > not be possible to determine the local security policy, if any, that > > should apply at the time of authentication because the kind of service > > being requested is not clear at that instant. For example, local > > policy might allow a user to access files on the server, but not start > > an interactive shell. However, during the authentication protocol, it > > is not known whether the user will be accessing files or attempting to > > use an interactive shell, or even both. In any event, where local > > security policy for the server host exists, it MUST be applied and > > enforced correctly. > > > > Implementors are encouraged to provide a default local policy and > > make its parameters known to administrators and users. At the > > discretion of the implementors, this default policy may be along the > > lines of 'anything goes' where there are no restrictions placed upon > > users, or it may be along the lines of 'excessively restrictive' in > > which case the administrators will have to actively make changes to > > this policy to meet their needs. Alternatively, it may be some > > attempt at providing something practical and immediately useful to the > > administrators of the system so they don't have to put in much effort > > to get SSH working. Whatever choice is made MUST be applied and > > enforced as required above. > > > > > > 11.3.4 Public key authentication > > > > The use of public-key authentication assumes that the client host has > > not been compromised. > > > > This risk can be mitigated by the use of passphrases on private keys; > > however, this is not an enforceable policy. The use of smartcards, or > > other technology to make passphrases an enforceable policy is > > suggested. > > > > The server could require both password and public-key authentication, > > however, this requires the client to expose its password to the server > > (see section on password authentication below.) > > > > > > 11.3.5 Password authentication > > > > The password mechanism as specified in the authentication protocol > > assumes that the server has not been compromised. If the server has > > been compromised, using password authentication will reveal a valid > > username / password combination to the attacker, which may lead to > > further compromises. > > > > This vulnerability can be mitigated by using an alternative form of > > authentication. For example, public-key authentication makes no > > assumptions about security on the server. > > > > > > 11.3.6 Host based authentication > > > > Host based authentication assumes that the client has not been > > compromised. There are no mitigating strategies, other than to use > > host based authentication in combination with another authentication > > method. > > > > > > 11.4 Connection protocol > > > > > > 11.4.1 End point security > > > > End point security is assumed by the connection protocol. If the > > server has been compromised, any terminal sessions, port forwarding, > > or systems accessed on the host are compromised. There are no > > mitigating factors for this. > > > > If the client end point has been compromised, and the server fails to > > stop the attacker at the authentication protocol, all services exposed > > (either as subsystems or through forwarding) will be vulnerable to > > attack. Implementors SHOULD provide mechanisms for administrators to > > control which services are exposed to limit the vulnerability of other > > services. > > > > These controls might include controlling which machines and ports can > > be target in 'port-forwarding' operations, which users are allowed to > > use interactive shell facilities, or which users are allowed to use > > exposed subsystems. > > > > > > 11.4.2 Proxy forwarding > > > > The SSH connection protocol allows for proxy forwarding of other > > protocols such as SNMP, POP3, and HTTP. This may be a concern for > > network administrators who wish to control the access of certain > > applications by users located outside of their physical location. > > Essentially, the forwarding of these protocols may violate site > > specific security policies as they may be undetectably tunneled > > through a firewall. Implementors SHOULD provide an administrative > > mechanism to control the proxy forwarding functionality so that > > site specific security policies may be upheld. > > > > In addition, a reverse proxy forwarding functionality > > is available, which again can be used to bypass firewall > > controls. > > > > As indicated above, end-point security is assumed during > > proxy forwarding operations. Failure of end-point security > > will compromise all data passed over proxy forwarding. > > > > > > 11.4.3 X11 forwarding > > > > Another form of proxy forwarding provided by the ssh connection > > protocol is the forwarding of the X11 protocol. If end-point security > > has been compromised, X11 forwarding may allow attacks against the X11 > > server. Users and administrators should, as a matter of course, use > > appropriate X11 security mechanisms to prevent unauthorized use of the > > X11 server. Implementors, administrators and users who wish to > > further explore the security mechanisms of X11 are invited to read > > [SCHEIFLER] and analyze previously reported problems with the > > interactions between SSH forwarding and X11 in CERT vulnerabilities > > VU#363181 and VU#118892 [CERT]. > > > > X11 display forwarding with SSH, by itself, is not sufficient to > > correct well known problems with X11 security [VENEMA]. However, X11 > > display forwarding in SSHv2 (or other, secure protocols), combined > > with actual and pseudo-displays which accept connections only over > > local IPC mechanisms authorized by permissions or ACLs, does correct > > many X11 security problems as long as the "none" MAC is not used. It > > is RECOMMENDED that X11 display implementations default to allowing > > display opens only over local IPC. It is RECOMMENDED that SSHv2 > > server implementations that support X11 forwarding default to allowing > > display opens only over local IPC. On single-user systems it might be > > reasonable to default to allowing local display opens over TCP/IP. > > > > Implementors of the X11 forwarding protocol SHOULD implement the magic > > cookie access checking spoofing mechanism as described in [ssh-connect] > > as an additional mechanism to prevent unauthorized use of the proxy. > > > > > > References from this section: > > > > [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication > > Service (V5)", RFC 1510, September 1993. > > > > [RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", > > RFC 1964, June 1996. > > > > [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness > > Recommendations for Security", RFC 1750, December 1994. > > > > [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism > > (SPKM)", RFC 2025, October 1996. > > > > [RFC2085] Oehler, M. and R. Glenn, "HMAC-MD5 IP Authentication with Replay > > Prevention", RFC 2085, February 1997. > > > > [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: > > Keyed-Hashing for Message Authentication", RFC 2104, > > February 1997. > > > > [RFC2246] Diercks, T. and C. Allen, "The TLS Protocol Version > > 1.0", RFC 2246, January 1999. > > > > [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its > > Use With IPsec", RFC 2410, November 1998 > > > > [RFC2743] Linn, J., "Generic Security Service Application Program > > Interface Version 2, Update 1", RFC 2743, January 2000. > > > > [SCHNEIER] Applied Cryptography, Second Edition, Bruce Schneier, Wiley > > and Sons Publisher, 1996 > > > > [KAUFMAN,PERLMAN,SPECINER] Network Security; PRIVATE Communication in > > a PUBLIC World, Charlie Kaufman, Radia Perlman, Mike Speciner, > > Prentice Hall Publisher, 1995 > > > > [FIPS-197] National Institute of Standards and Technology, > > "Specification for the Advanced Encryption Standard (AES)" > > FIPS 197. November 26, 2001. > > > > [ANSI T1.523-2001] American National Standard T1.523-2001, "Telecom > > Glossary 2000", American National Standards Institute, Inc., > > Approved February 28, 2001. > > > > > > [SCHEIFLER] Scheifler, R., "X Window System : The Complete > > Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd > > edition.", Digital Press ISBN 1555580882, Feburary > > 1992. > > > > [CERT] The CERT Coordination Center > > Software Engineering Institute > > Carnegie Mellon University > > Pittsburgh, PA 15213-3890 > > U.S.A. > > ( http://www.cert.org/nav/index_red.html ) > > > > [VENEMA] Wietse Venema, "Murphy's Law and Computer Security", Proceedings > > of 6th USENIX Security Symposium, San Jose, CA, July 1996. > > http://www.usenix.org/publications/library/proceedings/sec96/venema.html > > > > > > > > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 28 13:52:21 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13419 for ; Wed, 28 May 2003 13:52:20 -0400 (EDT) Received: (qmail 16529 invoked by uid 605); 28 May 2003 17:51:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15513 invoked from network); 28 May 2003 17:50:41 -0000 Received: from sj-core-1.cisco.com (171.71.177.237) by mail.netbsd.org with SMTP; 28 May 2003 17:50:41 -0000 Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4SHodFW003532 for ; Wed, 28 May 2003 10:50:40 -0700 (PDT) Received: from localhost (clonvick@localhost) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA11975 for ; Wed, 28 May 2003 10:50:38 -0700 (PDT) Date: Wed, 28 May 2003 10:50:38 -0700 (PDT) From: Chris Lonvick To: ietf-ssh@netbsd.org Subject: New Section 11.2.4 Man-in-the-middle In-Reply-To: <20030528083608.A19253@binky.central.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, (Meetings are great places to get work done. :-) I've made some modifications to the MITM section to separate the attacks into 3 cases (rather than subsets of 2): - getting incorrect host keys during the first session attempt - noting the case where an attacker may usurp secure key distribution - attempts at modifying packets after the session has been established Please review this and provide feedback. The "diffs" are at http://www.employees.org/~lonvick/newssh9.html Thanks, Chris ======================================================================== 11.1.4 Man-in-the-middle This protocol makes no assumptions nor provisions for an infrastructure or means for distributing the public keys of hosts. It is expected that this protocol will sometimes be used without first verifying the association between the server host key and the server host name. Such usage is vulnerable to man-in-the-middle attacks. This section describes this and encourages administrators and users to understand the importance of verifying this association before any session is initiated. There are three cases of man-in-the-middle attacks to consider. The first is where an attacker places a device between the client and the server before the session is initiated. In this case, the attack device is trying to mimic the legitimate server and will offer its public key to the client when the client initiates a session. If it were to offer the public key of the server, then it would not be able to decrypt or sign the transmissions between the legitimate server and the client unless it also had access to the private-key of the host. The attack device will also, simultaneously to this, initiate a session to the legitimate server masquerading itself as the client. If the public key of the server had been securely distributed to the client prior to that session initiation, the key offered to the client by the attack device will not match the key stored on the client. In that case, the user SHOULD be given a warning that the offered host key does not match the host key cached on the client. As described in Section 3.1 of [ARCH], the user may be free to accept the new key and continue the session. It is RECOMMENDED that the warning provide sufficient information to the user of the client device so they may make an informed decision. If the user chooses to continue the session with the stored public-key of the server (not the public-key offered at the start of the session), then the session specific data between the attacker and server will be different between the client-to-attacker session and the attacker-to-server sessions due to the randomness discussed above. From this, the attacker will not be able to make this attack work since the attacker will not be able to correctly sign packets containing this session specific data from the server since he does not have the private key of that server. The second case that should be considered is similar to the first case in that it also happens at the time of connection but this case points out the need for the secure distribution of server public keys. If the server public keys are not securely distributed then the client cannot know if it is talking to the intended server. An attacker may use social engineering techniques to pass off server keys to unsuspecting users and may then place a man-in-the-middle attack device between the legitimate server and the clients. If this is allowed to happen then the clients will form client-to-attacker sessions and the attacker will form attacker-to-server sessions and will be able to monitor and manipulate all of the traffic between the clients and the legitimate servers. Server administrators are encouraged to make host key fingerprints available for checking by some means whose security does not rely on the integrity of the actual host keys. Possible mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also include secured Web pages, physical pieces of paper, etc. Implementors SHOULD provide recommendations on how best to do this with their implementation. Because the protocol is extensible, future extensions to the protocol may provide better mechanisms for dealing with the need to know the server's host key before connecting. For example, making the host key fingerprint available through a secure DNS lookup, or using kerberos over gssapi during key exchange to authenticate the server are possibilities. In the third man-in-the-middle case, attackers may attempt to manipulate packets in transit between peers after the session has been established. As described in the Replay part of this section, a successful attack of this nature is very improbable. As in the Replay section, this reasoning does assume that the MAC is secure and that it is infeasible to construct inputs to a MAC algorithm to give a known output. This is discussed in much greater detail in Section 6 of RFC 2104. If the MAC algorithm has a vulnerability or is weak enough, then the attacker may be able to specify certain inputs to yield a known MAC. With that they may be able to alter the contents of a packet in transit. Alternatively the attacker may be able to exploit the algorithm vulnerability or weakness to find the shared secret by reviewing the MACs from captured packets. In either of those cases, an attacker could construct a packet or packets that could be inserted into an SSH stream. To prevent that, implementors are encouraged to utilize commonly accepted MAC algorithms and administrators are encouraged to watch current literature and discussions of cryptography to ensure that they are not using a MAC algorithm that has a recently found vulnerability or weakness. In summary, the use of this protocol without a reliable association of the binding between a host and its host keys is inherently insecure and is NOT RECOMMENDED. It may however be necessary in non-security critical environments, and will still provide protection against passive attacks. Implementors of protocols and applications running on top of this protocol should keep this possibility in mind. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed May 28 14:11:26 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14358 for ; Wed, 28 May 2003 14:11:25 -0400 (EDT) Received: (qmail 27039 invoked by uid 605); 28 May 2003 18:11:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27032 invoked from network); 28 May 2003 18:11:21 -0000 Received: from mailout.cgi.com (HELO whms0073.cwshs.com) (66.110.7.6) by mail.netbsd.org with SMTP; 28 May 2003 18:11:21 -0000 Received: from whml0344.cgi.com ([10.254.251.20]) by whms0073.cwshs.com (Netscape Messaging Server 4.15 whms0073 Jan 17 2002 00:23:08) with SMTP id HFLZUR02.2N4 for ; Wed, 28 May 2003 14:11:15 -0400 Received: from whms0335.wshs(10.254.245.207) by whml0344.cgi.com via csmap id 27425; Wed, 28 May 2003 14:12:06 -0400 (EDT) Received: from RWANNER ([10.165.13.17]) by whms0335.cwshs.com (Netscape Messaging Server 4.15 whms0335 Jan 17 2002 00:23:08) with SMTP id HFLZUR00.QHW; Wed, 28 May 2003 14:11:15 -0400 From: "Richard Wanner" To: "Chris Lonvick" , Subject: RE: New Section 11.2.4 Man-in-the-middle Date: Wed, 28 May 2003 14:09:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Looks great to me! One minor nit (which you may choose to ignore); I would probably switch the order of case 1 and case 2 just because case 2 is the most likely, and most preventable attack. Case 1: No keys distributed. Case 2: Keys distributed, but attack possible due to user intervention. Case 3: More high-tech attack. The attacks get more complex as they go. And the cases follow from each other. My opinion. YMMV Richard (Rick) Wanner B.Sc. GCFW Consultant Security Engineering & Evaluation Group InfoSec Centre of Expertise (COE) CGI Information Systems & Management Consultants Inc. Ottawa, Canada http://www.infosec.cgi.com/ Email: richard.wanner@cgi.com Tel: (613) 234-2155 Cell: (613) 220-2045 Fax: (613) 234-6934 Confidentiality Notice: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. > -----Original Message----- > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On > Behalf Of Chris Lonvick > Sent: Wednesday, May 28, 2003 1:51 PM > To: ietf-ssh@netbsd.org > Subject: New Section 11.2.4 Man-in-the-middle > > > Hi, > > (Meetings are great places to get work done. :-) > > I've made some modifications to the MITM section to separate the attacks > into 3 cases (rather than subsets of 2): > - getting incorrect host keys during the first session attempt > - noting the case where an attacker may usurp secure key distribution > - attempts at modifying packets after the session has been established > > Please review this and provide feedback. The "diffs" are at > http://www.employees.org/~lonvick/newssh9.html > > Thanks, > Chris > > > ======================================================================== > > 11.1.4 Man-in-the-middle > > This protocol makes no assumptions nor provisions for an > infrastructure or means for distributing the public keys of hosts. It > is expected that this protocol will sometimes be used without first > verifying the association between the server host key and the server > host name. Such usage is vulnerable to man-in-the-middle attacks. > This section describes this and encourages administrators and users to > understand the importance of verifying this association before any > session is initiated. > > There are three cases of man-in-the-middle attacks to consider. The > first is where an attacker places a device between the client and the > server before the session is initiated. In this case, the attack > device is trying to mimic the legitimate server and will offer its > public key to the client when the client initiates a session. If it > were to offer the public key of the server, then it would not be able > to decrypt or sign the transmissions between the legitimate server and > the client unless it also had access to the private-key of the host. > The attack device will also, simultaneously to this, initiate a > session to the legitimate server masquerading itself as the client. > If the public key of the server had been securely distributed to the > client prior to that session initiation, the key offered to the client > by the attack device will not match the key stored on the client. In > that case, the user SHOULD be given a warning that the offered host > key does not match the host key cached on the client. As described in > Section 3.1 of [ARCH], the user may be free to accept the new key and > continue the session. It is RECOMMENDED that the warning provide > sufficient information to the user of the client device so they may > make an informed decision. If the user chooses to continue the > session with the stored public-key of the server (not the public-key > offered at the start of the session), then the session specific data > between the attacker and server will be different between the > client-to-attacker session and the attacker-to-server sessions due to > the randomness discussed above. From this, the attacker will not be > able to make this attack work since the attacker will not be able to > correctly sign packets containing this session specific data from the > server since he does not have the private key of that server. > > The second case that should be considered is similar to the first case > in that it also happens at the time of connection but this case points > out the need for the secure distribution of server public keys. If the > server public keys are not securely distributed then the client cannot > know if it is talking to the intended server. An attacker may use > social engineering techniques to pass off server keys to unsuspecting > users and may then place a man-in-the-middle attack device between the > legitimate server and the clients. If this is allowed to happen then > the clients will form client-to-attacker sessions and the attacker > will form attacker-to-server sessions and will be able to monitor and > manipulate all of the traffic between the clients and the legitimate > servers. Server administrators are encouraged to make host key > fingerprints available for checking by some means whose security does > not rely on the integrity of the actual host keys. Possible > mechanisms are discussed in Section 3.1 of [SSH-ARCH] and may also > include secured Web pages, physical pieces of paper, etc. > Implementors SHOULD provide recommendations on how best to do this > with their implementation. Because the protocol is extensible, future > extensions to the protocol may provide better mechanisms for dealing > with the need to know the server's host key before connecting. For > example, making the host key fingerprint available through a secure > DNS lookup, or using kerberos over gssapi during key exchange to > authenticate the server are possibilities. > > In the third man-in-the-middle case, attackers may attempt to > manipulate packets in transit between peers after the session has been > established. As described in the Replay part of this section, a > successful attack of this nature is very improbable. As in the Replay > section, this reasoning does assume that the MAC is secure and that it > is infeasible to construct inputs to a MAC algorithm to give a known > output. This is discussed in much greater detail in Section 6 of RFC > 2104. If the MAC algorithm has a vulnerability or is weak enough, > then the attacker may be able to specify certain inputs to yield a > known MAC. With that they may be able to alter the contents of a > packet in transit. Alternatively the attacker may be able to exploit > the algorithm vulnerability or weakness to find the shared secret by > reviewing the MACs from captured packets. In either of those cases, > an attacker could construct a packet or packets that could be inserted > into an SSH stream. To prevent that, implementors are encouraged to > utilize commonly accepted MAC algorithms and administrators are > encouraged to watch current literature and discussions of cryptography > to ensure that they are not using a MAC algorithm that has a recently > found vulnerability or weakness. > > In summary, the use of this protocol without a reliable association of > the binding between a host and its host keys is inherently insecure > and is NOT RECOMMENDED. It may however be necessary in non-security > critical environments, and will still provide protection against > passive attacks. Implementors of protocols and applications running > on top of this protocol should keep this possibility in mind. > > > > >