From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 1 18:41: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 SAA19612 for ; Tue, 1 Jul 2003 18:41:44 -0400 (EDT) Received: (qmail 16008 invoked by uid 605); 1 Jul 2003 22:41:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16001 invoked from network); 1 Jul 2003 22:41:38 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 1 Jul 2003 22:41:38 -0000 Received: by xanthine.gratuitous.org with local; Tue, 01 Jul 2003 18:41:21 -0400 From: "Joel N. Weber II" To: Nicolas Williams , ietf-ssh@netbsd.org In-reply-to: (ietf-secsh@joelweber.com) Subject: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt References: <200306241056.GAA10873@ietf.org> <20030624074458.A9718@binky.central.sun.com> <20030624142613.J3522@binky.central.sun.com> <20030625080941.A11084@binky.central.sun.com> Message-Id: Date: Tue, 01 Jul 2003 18:41:21 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list So, I think I've been a bit confused about the subtlies of this. Having read the documents more carefully, my current understanding is this: SSH_MSG_KEXGSS_HOSTKEY has this format: byte SSH_MSG_KEXGSS_HOSTKEY string server public host key and certificates (K_S) K_S has this format: Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data The format identifier is something like ``ssh-rsa'', which means that a host can send a public host key in a SSH_MSG_KEXGSS_HOSTKEY and the client will be able to figure out which host key format it got. I do think that if SSH_MSG_KEXGSS_HOSTKEY is to be prefered over a public key algorithm of none, it should probably be defined to also be usable when using non-GSS key exchange with certificates that can expire. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 1 22:30: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 WAA25180 for ; Tue, 1 Jul 2003 22:30:26 -0400 (EDT) Received: (qmail 11476 invoked by uid 605); 2 Jul 2003 02:30:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11469 invoked from network); 2 Jul 2003 02:30:13 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 2 Jul 2003 02:30:13 -0000 Received: by xanthine.gratuitous.org with local; Tue, 01 Jul 2003 22:30:13 -0400 From: "Joel N. Weber II" To: ietf-ssh@netbsd.org In-reply-to: (ietf-secsh@joelweber.com) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: <200306241056.GAA10873@ietf.org> <20030624074458.A9718@binky.central.sun.com> <20030624142613.J3522@binky.central.sun.com> <20030625080941.A11084@binky.central.sun.com> Message-Id: Date: Tue, 01 Jul 2003 22:30:13 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Looking at the January 2002 mailing list archive, it becomes clear that while the public key types defined in the transport draft have this encoding: string certificate or public key format identifier byte[n] key/certificate data there is no requirement that public key types defined elsewhere will have that encoding. Perhaps the gsskeyex draft should explicitly say that SSH_MSG_KEXGSS_HOSTKEY only works with ssh-dss and ssh-rsa keys, or that it only works with types that start out with the type identifier as a string. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jul 3 17:09: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 RAA06749 for ; Thu, 3 Jul 2003 17:09:24 -0400 (EDT) Received: (qmail 13497 invoked by uid 605); 3 Jul 2003 21:09:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13490 invoked from network); 3 Jul 2003 21:09:13 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 3 Jul 2003 21:09:13 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h63L9CfU025057 for ; Thu, 3 Jul 2003 14:09:13 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h63L9C27014811 for ; Thu, 3 Jul 2003 17:09:12 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h63L9Bq3014495 for ; Thu, 3 Jul 2003 17:09:12 -0400 (EDT) Message-Id: <200307032109.h63L9Bq3014495@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: Send me agenda items for Vienna. Reply-to: sommerfeld@east.sun.com Date: Thu, 03 Jul 2003 17:09:11 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list We will be meeting during the wednesday morning session in Vienna. Please send me any updates or requested areas of discussion for inclusion in the agenda. thank you. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sun Jul 6 07:09: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 HAA11397 for ; Sun, 6 Jul 2003 07:09:43 -0400 (EDT) Received: (qmail 25232 invoked by uid 605); 6 Jul 2003 11:09:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25225 invoked from network); 6 Jul 2003 11:09:41 -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; 6 Jul 2003 11:09:41 -0000 Received: from latte.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 h66B9MST026302 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Sun, 6 Jul 2003 13:09:24 +0200 To: ietf-ssh@netbsd.org Subject: Comment on draft-ietf-secsh-gsskeyex-06 From: Simon Josefsson X-Payment: hashcash 1.2 0:030706:ietf-ssh@netbsd.org:9562b5447fb7a3a8 X-Hashcash: 0:030706:ietf-ssh@netbsd.org:9562b5447fb7a3a8 Date: Sun, 06 Jul 2003 13:09:22 +0200 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.5 required=5.0 tests=USER_AGENT_GNUS_UA version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@netbsd.org Precedence: list The document says: The client SHOULD NOT send more then one gssapi mechanism OID unless there are no non-GSSAPI authentication methods between the GSSAPI mechanisms in the order of preference, otherwise, authentication methods may be executed out of order. Besides having four (!) negations, I think some hints on how different GSSAPI mechanisms should be handled instead would be useful. E.g.: The client SHOULD send more than one mechanism OIDs only when all of the mechanisms are of the same priority, compared to non-GSSAPI authentication methods. Otherwise, authentication methods may be executed out of order. Thus, the client could first send a SSH_MSG_USERAUTH_REQUEST for one GSSAPI mechanism, then try public key authentication, and then try another GSSAPI mechanism. FWIW, another implementation of the GSSAPI user authentication part of the specification is available. Patches (experimental!) for LSH using GSSLib, Heimdal or MIT Kerberos 5, are available from . Thanks, Simon From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 00:01: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 AAA25921 for ; Tue, 8 Jul 2003 00:01:43 -0400 (EDT) Received: (qmail 3031 invoked by uid 605); 8 Jul 2003 04:01:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3021 invoked from network); 8 Jul 2003 04:01:36 -0000 Received: from softdnserror (HELO hermes.cs.auckland.ac.nz) (130.216.35.151) by mail.netbsd.org with SMTP; 8 Jul 2003 04:01:36 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h68411XX014334 for ; Tue, 8 Jul 2003 16:01:01 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h68412200867 for ietf-ssh@netbsd.org; Tue, 8 Jul 2003 16:01:02 +1200 Date: Tue, 8 Jul 2003 16:01:02 +1200 Message-Id: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@netbsd.org Subject: Why SFTP performance sucks, and how to fix it Sender: ietf-ssh-owner@netbsd.org Precedence: list Now that I've got your attention... :-). The following is a section of the (not-yet-published) paper "Performance Characteristics of Application-level Security Protocols", which looks at, well, performance characteristics of application-level security protocols. One of these is SSH (the rest are SSL, PGP, and S/MIME, in case anyone cares). The paper hasn't been published yet (it's still a work in progress), since it probably won't be published for awhile (I'm probably submitting it to Usenix Security next year) and since the information in this section could be useful to SSH developers, I'm posting it here. If people find it of any use, I might later post it to one or two general crypto lists to let other crypto developers know, since it describes the SFTP performance problem and how to fix it. -- Snip -- 6.3 The SSHv2 and SFTP Performance Handbrake In 1977, Ward Christensen created the Xmodem data transfer protocol [Christensen 1977]. Coming in an era of 300bps modems and unreliable links, Xmodem divided data into 128-byte packets and required an Ack to be sent for each packet before the next one could be transmitted. As modems became faster and links more reliable, the need to Ack each Xmodem packet became more and more of a performance handbrake, since no matter how fast or reliable the link, no more than 128 bytes of data could be sent without waiting 1 RTT for the Ack. The solution to the problem was to increase the packet size (Ymodem, Xmodem-1K), and drop the requirement to Ack each packet (Ymodem-g, Zmodem) [Forsberg 1988]. The latter was perfectly acceptable, since by then modems included their own error correction and flow control mechanism. Unfortunately this performance handbrake was reinvented in the SSHv2 protocol. Like Ymodem-g and Zmodem running over modern modems, TCP/IP provides a reliable, flow-controlled transport layer for the SSH protocol. SSHv2 however introduced an additional form of flow control that, like Xmodem, requires the receiver to Ack each packet before more can be sent (the details aren't quite as straightforward as this since the SSHv2 specification describes things in terms of packets and data windows, but effectively it's the Xmodem per-packet Ack). Most implementations seem to use packet sizes of 16K or occasionally 32K, with some going as low as 4K. What this means is that no matter how fast the link, every (say) 16K the transmission stops for 1 RTT until the other side has sent its Ack (referred to as a window adjust in SSHv2 terminology). Consider for example the effect of this on a T1 international link with a half-second RTT. With the handbrake in operation, the link can run at only 17% of its total capacity. This performance hit is so noticeable that it is mentioned in the FAQs of some SSH implementations [PuttyFAQ]. In addition to the protocol-level handbrake, the SFTP protocol that runs on top of SSH contains its own handbrake. This protocol recommends that reads and writes consist of no more than 32K of data, even though it's running over the reliable SSH transport which is in turn running over the reliable TCP/IP transport. One common implementation limits SFTP packets to 4K bytes, resulting in a mere 4% link utilisation in the previously-presented scenario. The fix for this problem is obvious: Remove the handbrake. This is no good reason for the per-packet Ack, and certainly other protocols such as SSHv1 and SSL/TLS function perfectly without it (the absence of the handbrake in SSHv1 is why SSH FAQs observe that the SSHv1 scp is so much faster than the SSHv2 SFTP, even though SFTP is overall a better design). The effect of running without the handbrake on were investigated using cryptlib with a fairly rudimentary implementation of SFTP running over the built-in SSHv2. cryptlib's SSH implementation has always set the window size to INT_MAX (some implementations have problems with UINT_MAX as the window size), which effectively disables the SSH-level handbrake. The SFTP implementation followed suit, requesting a read/write of the entire file at once rather than breaking it up into little packets at the SFTP level (packetisation is already handled at the SSH and TCP/IP layers). Run over an international link (pretty much a given when you're in New Zealand), this SFTP implementation was around five times faster than the Putty implementation of SFTP talking to OpenSSH, which sends data in 4K SFTP packets and (by extension) 4K SSH packets. Even over a low-latency link, the difference was impressive: cryptlib was an order of magnitude faster than Putty on the loopback interface (latency being relative in this case). The SSH-level handbrake can therefore be provisionally removed by having implementations set the window size to INT_MAX, and permanently removed by deprecating the Ack/window-based flow control and perhaps optionally providing Xon/Xoff-style flow control if absolutely necessary (as was mentioned earlier, both SSHv1 and SSL/TLS function fine without requiring this). The SFTP-level handbrake can be removed by eliminating the maximum packet-size wording of the SFTP specification, and recommending that implementations read and write all data at once rather than engaging in additional redundant packetisation at the SFTP level. Most of this can be effected through a simple code change, however implementors should be aware that many implementations will still stop and wait for an Ack after a certain amount of data has been transmitted, even with an effectively infinite-sized windows. On the sender side things aren't quite so bad, experimentation has shown that it's fairly safe to ignore the receiver's window size and send data at the maximum rate possible, discarding any window adjusts that arrive (the only slight complication is that it's occasionally necessary to stop sending for a moment and clear the read channel of the accumulation of Acks that have arrived while sending). Since most implementations include a facility for checking the peer's software version to identify and work around implementation bugs, detecting pre-handbrake-fix implementations and providing the appropriate slower interpretation of the protocol should be relatively straightforward. In addition, FAQs about the poor performance of SFTP will need to be updated. [Christensen 1977] "MODEM.ASM", Ward Christensen, August 1977 (the Xmodem protocol was defined in terms of "What this program does" rather than being formally documented, the author described it in a Compuserve post some years later as "a quick hack I threw together"). [Forsberg 1988] "Xmodem/Ymodem Protocol Reference: A compendium of documents describing the Xmodem and Ymodem File Transfer Protocols", Chuck Forsberg, October 1988. [PuttyFAQ] "PuTTY FAQ", Simon Tatham, 2003, http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html, question A.6.8, "PSFTP transfers files much slower than PSCP". -- Snip -- While I'm pointing out things that should be fixed in the spec, my other big gripe is the way the initial message is handled. Currently the spec describes a rather messy mechanism where both sides start by shouting at each other and then engage in a complex dance to sort out what's what afterwards (the "guessing" stuff). This leads to really messy implementations when one of the partners doesn't get the dance steps right. There is no good reason for this complication in the protocol. I don't buy the RTT argument given in the SSH-transport draft, the guessing stuff saves one whole RTT, but then the incredibly chatty authentication protocol ("Would you like to authenticate then?" - "Yes I'd like to authenticate" - "How would you like to authenticate?" - "Well, would the following suit you?" - "That looks about right, let's do it" - "Right, I'm about to start" - etc etc etc) more than makes up for any miniscule savings during the initial handshake. The way to fix this is simple: Replace all the guessing stuff and the complex rules that go with it with: Key exchange begins by each side sending lists of supported algorithms. The server sends its list of supported algorithms first, the client chooses which ones it prefers that it also supports and sends back its choice in the reply. That removes all of the handshake-dance complexity, and vastly simplifies implementations. Oh yes, in case anyone finds the SFTP info above useful and wants to reference it for some reason, please cite it as '"Performance Characteristics of Application-level Security Protocols", Peter Gutmann, to appear', since it's not officially published yet. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 00:22: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 AAA26289 for ; Tue, 8 Jul 2003 00:22:26 -0400 (EDT) Received: (qmail 12033 invoked by uid 605); 8 Jul 2003 04:22:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11991 invoked from network); 8 Jul 2003 04:22:13 -0000 Received: from sngrel5.hp.com (192.6.86.210) by mail.netbsd.org with SMTP; 8 Jul 2003 04:22:13 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel5.hp.com (Postfix) with SMTP id 38B5B518 for ; Tue, 8 Jul 2003 12:22:05 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 08 Jul 2003 14:21:58 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id N1P3082D; Tue, 8 Jul 2003 14:21:57 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 08 Jul 2003 14:21:57 +1000 Received: from mbp by vexed with local (Exim 3.36 #1 (Debian)) id 19Zjy9-0002kZ-00; Tue, 08 Jul 2003 14:20:45 +1000 Date: Tue, 8 Jul 2003 14:20:45 +1000 From: Martin Pool To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708042032.GT16531@vexed.ozlabs.hp.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B User-Agent: Mutt/1.5.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On 8 Jul 2003, Peter Gutmann wrote: > In addition to the protocol-level handbrake, the SFTP protocol that runs on > top of SSH contains its own handbrake. This protocol recommends that reads > and writes consist of no more than 32K of data, even though it's running over > the reliable SSH transport which is in turn running over the reliable TCP/IP > transport. One common implementation limits SFTP packets to 4K bytes, > resulting in a mere 4% link utilisation in the previously-presented > scenario. This reminds me of a problem in rsync: A fundamental protocol design isssue is whether the recipient of a message should be able to interrupt it during receipt to indicate an error. The simplest and cleanest solution is to require errors be sent after the request is received, as SFTP does. If the requests are very large, this causes a problem when, for example, a destination file cannot be written to because of an out-of-space error. A simple server implementation will need to read in the whole request before it is able to notify the client of the error. It is entirely realistic to have a file that takes many minutes to transfer, and possibly incurs a significant traffic cost. It is annoying to have all that time or money be wasted when the server discards the request. Alternatively the server can drop the connection, or send an out-of-band error (e.g. over ssh stderr), but both of these introduce other problems. Similar issues can be seen to a lesser extent in HTTP. I think writing a file as a series of IO chunks is a reasonable and clean solution but it requires that the length be chosen properly, and ideally for pipelining to be used. Of course I agree that 4k or even 32k is too small for most modern networks. But I did want to point out that going too far in the opposite direction can be a problem too. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 01:16: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 BAA27297 for ; Tue, 8 Jul 2003 01:16:51 -0400 (EDT) Received: (qmail 6075 invoked by uid 605); 8 Jul 2003 05:16:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6068 invoked from network); 8 Jul 2003 05:16:48 -0000 Received: from softdnserror (HELO hermes.cs.auckland.ac.nz) (130.216.35.151) by mail.netbsd.org with SMTP; 8 Jul 2003 05:16:48 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h685ErXX016659; Tue, 8 Jul 2003 17:14:53 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h685EsG03449; Tue, 8 Jul 2003 17:14:54 +1200 Date: Tue, 8 Jul 2003 17:14:54 +1200 Message-Id: <200307080514.h685EsG03449@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: mbp@samba.org, pgut001@cs.auckland.ac.nz Subject: Re: Why SFTP performance sucks, and how to fix it Cc: ietf-ssh@netbsd.org Sender: ietf-ssh-owner@netbsd.org Precedence: list Martin Pool writes: >Of course I agree that 4k or even 32k is too small for most modern networks. >But I did want to point out that going too far in the opposite direction can >be a problem too. Fair enough. I guess the XON/XOFF thing (to replace the Ack) would do this, or perhaps a channel close depending on the seriousness of the error. I think it'd need some experimentation/going through usage cases to see where/how it's useful: - Typical usage: SSHv1 and SSL/TLS don't seem to need any flow control, which would imply that in most cases you don't have to worry about it. - Out of disk space: Probably a channel close, since it's a fatal error and you want the sender to stop permanently ("Please wait while the sysadmin hot-plugs some more RAID storage" probably won't work :-). - Temporary resource problem (can't think of a good example at the moment but I'm sure there's something): Send XOFF, perhaps with an optional timeout indication, if the sender doesn't get an XON in that time they can consider it a long-term/fatal error as above. Another thing to keep in mind here is that if you signal a read/write of the entire file at once, the receiver knows how much disk space it needs and can lock the space before starting the receive - it allows far better data transfer management then sending an arbitrary number of tiny little bits that the receiver has to take care of on the fly. I'd really prefer to know before I start that a transfer is going to fail, rather than write 2GB and then get the out-of-disk error. If you follow this stragegy you never need to signal out-of-disk during a transfer, only at the start. Even better would be to require (or at least recommend) that clients include the file size in the FXP_OPEN *before* any data transfer is about to take place, so the receiver can respond to the open request with not-enough-disk-space error. This is perfectly feasible in most cases where SFTP is used, since you're sending files of a known size (I haven't played with this too much, but it doesn't appear that implementations indicate the size at open much, which would require a code update). You can really optimise the transfer management by following a few simple rules in which the sender transmits information required to ease data processing in advance. If it's of any use to people, I could write a small informational appendix or whatever for the draft indicating how to use the protocol in a manner that makes data transfer management easier. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 01:40: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 BAA27673 for ; Tue, 8 Jul 2003 01:40:20 -0400 (EDT) Received: (qmail 17828 invoked by uid 605); 8 Jul 2003 05:40:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17820 invoked from network); 8 Jul 2003 05:40:16 -0000 Received: from sngrel7.hp.com (192.6.86.111) by mail.netbsd.org with SMTP; 8 Jul 2003 05:40:16 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel7.hp.com (Postfix) with SMTP id 1290E360 for ; Tue, 8 Jul 2003 13:40:08 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 08 Jul 2003 15:40:00 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id N1PPAA2D; Tue, 8 Jul 2003 15:40:00 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Tue, 08 Jul 2003 15:40:00 +1000 Received: from mbp by vexed with local (Exim 3.36 #1 (Debian)) id 19ZlBg-0001b3-00; Tue, 08 Jul 2003 15:38:48 +1000 Date: Tue, 8 Jul 2003 15:38:48 +1000 From: Martin Pool To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708053846.GV16531@vexed.ozlabs.hp.com> References: <200307080514.h685EsG03449@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307080514.h685EsG03449@medusa01.cs.auckland.ac.nz> X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B User-Agent: Mutt/1.5.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On 8 Jul 2003, Peter Gutmann wrote: > Martin Pool writes: > > >Of course I agree that 4k or even 32k is too small for most modern networks. > >But I did want to point out that going too far in the opposite direction can > >be a problem too. > > Fair enough. I guess the XON/XOFF thing (to replace the Ack) would do this, > or perhaps a channel close depending on the seriousness of the > error. Channel close is a terrible error handling method. To start with, it gives no indication of what in particular went wrong. > I think it'd need some experimentation/going through usage cases to > see where/how it's useful: > > - Typical usage: SSHv1 and SSL/TLS don't seem to need any flow control, which > would imply that in most cases you don't have to worry about it. > > - Out of disk space: Probably a channel close, since it's a fatal error and > you want the sender to stop permanently ("Please wait while the sysadmin > hot-plugs some more RAID storage" probably won't work :-). Well, out of disk space was only an example of the kind of error that can occur at any point. There are others. A more common one for rsync is some kind of permission problem. SECSH, unlike rsync, can probably trap that in the OPEN operation before starting to send bulk data, but the general problem remains. User quotas are another quite realistic possibility where an interactive user might very well want to stay connected and delete some files. > - Temporary resource problem (can't think of a good example at the moment but > I'm sure there's something): Send XOFF, perhaps with an optional timeout > indication, if the sender doesn't get an XON in that time they can consider > it a long-term/fatal error as above. > > Another thing to keep in mind here is that if you signal a read/write of the > entire file at once, the receiver knows how much disk space it needs and can > lock the space before starting the receive I don't know of a means for a Unix or Windows server to "lock" disk space in that way. I suppose the server might zero-fill the blocks between getting the start of the request and reading the bulk of it, but that seems highly contrived. > I'd really prefer to know before I start that a transfer is going to > fail, rather than write 2GB and then get the out-of-disk error. The general problem I'm talking about here is that in a protocol like SECSH, the size of the request blocks is the amount of data "at risk" at any point: if something goes wrong, as it unavoidably may, then you might have wasted your time and money transmitting it. Here's another example, taken from experience with Samba: if you're going to send chunks of 2GB at a time they presumably have to be "streamed" from disk and not built in a temporary buffer. (Indeed, people may well want to transfer files larger than their VM - 6GB files on a 32bit machine.) There are unavoidable errors where you can in fact send less data than you originally thought, if e.g. somebody else truncates the file while you're reading it. That means that the header of the request ("write 6G") is impossible to fulfil, so you need to either drop the connection or write nulls, both of which are deeply undesirable. I suspect that sending a block-at-a-time can give good performance if you choose a good block size and pipeline transmissions, and if problems with the underlying transport are addressed. Perhaps IOs should be roughly proportional to the amount of data in flight? I think the request/response model in SECSH is a great thing for simplicity and robustness and it shouldn't be lightly cast aside. > If you follow this stragegy you never need to signal out-of-disk during a > transfer, only at the start. Even better would be to require (or at least > recommend) that clients include the file size in the FXP_OPEN *before* any > data transfer is about to take place, so the receiver can respond to the open > request with not-enough-disk-space error. This is perfectly feasible in most > cases where SFTP is used, since you're sending files of a known size (I > haven't played with this too much, but it doesn't appear that implementations > indicate the size at open much, which would require a code update). You can > really optimise the transfer management by following a few simple rules in > which the sender transmits information required to ease data processing in > advance. > > If it's of any use to people, I could write a small informational appendix or > whatever for the draft indicating how to use the protocol in a manner that > makes data transfer management easier. > > Peter. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 03:59:31 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13331 for ; Tue, 8 Jul 2003 03:59:30 -0400 (EDT) Received: (qmail 23169 invoked by uid 605); 8 Jul 2003 07:59:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23162 invoked from network); 8 Jul 2003 07:59:21 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 8 Jul 2003 07:59:21 -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 h687xD6O016837; Tue, 8 Jul 2003 09:59:14 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 994462D003; Tue, 8 Jul 2003 09:12:16 +0200 (CEST) Date: Tue, 8 Jul 2003 09:12:16 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708071216.GA14517@folly> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 04:01:02PM +1200, Peter Gutmann wrote: > TCP/IP provides a > reliable, flow-controlled transport layer for the SSH protocol. when multiplexing multiple ssh channels over one connection and one of the consumers is very slow, then the tcp flow control will not help. AFAIK, this is one of the reasons why there's an additional per-channel flowcontrol. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 04:51: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 EAA14518 for ; Tue, 8 Jul 2003 04:51:02 -0400 (EDT) Received: (qmail 17247 invoked by uid 605); 8 Jul 2003 08:51:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17240 invoked from network); 8 Jul 2003 08:51:00 -0000 Received: from highlandsun.propagation.net (66.221.212.168) by mail.netbsd.org with SMTP; 8 Jul 2003 08:51:00 -0000 Received: from CELLO (highlandsun.com [66.221.212.169]) by highlandsun.propagation.net (8.12.9/8.12.9) with SMTP id h688oKTj030964; Tue, 8 Jul 2003 03:50:20 -0500 From: "Howard Chu" To: "'Martin Pool'" , "'Peter Gutmann'" Cc: Subject: RE: Why SFTP performance sucks, and how to fix it Date: Tue, 8 Jul 2003 01:47:14 -0700 Message-ID: <005e01c3452d$f3ab4ac0$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.2800.1106 In-Reply-To: <20030708053846.GV16531@vexed.ozlabs.hp.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 Martin Pool > On 8 Jul 2003, Peter Gutmann wrote: > > Another thing to keep in mind here is that if you signal a > > read/write of the > > entire file at once, the receiver knows how much disk space > > it needs and can > > lock the space before starting the receive > > I don't know of a means for a Unix or Windows server to "lock" disk > space in that way. I suppose the server might zero-fill the blocks > between getting the start of the request and reading the bulk of it, > but that seems highly contrived. The FTP protocol has an ALLO command for allocating space in advance. On some FTP servers I've seen, they do exactly this - zero-fill that much space. It is a pretty foolproof way of accomplishing the task, even if it seems contrived. > > I'd really prefer to know before I start that a transfer is going to > > fail, rather than write 2GB and then get the out-of-disk error. Definitely. -- 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 Jul 8 04:56: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 EAA14636 for ; Tue, 8 Jul 2003 04:56:11 -0400 (EDT) Received: (qmail 20454 invoked by uid 605); 8 Jul 2003 08:56:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20447 invoked from network); 8 Jul 2003 08:56:09 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 8 Jul 2003 08:56:09 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19ZoGP-0006xR-00; Tue, 08 Jul 2003 09:55:53 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> Subject: Re: Why SFTP performance sucks, and how to fix it Message-Id: Date: Tue, 08 Jul 2003 09:55:53 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Peter Gutmann wrote: > The SSH-level handbrake can therefore be provisionally removed by > having implementations set the window size to INT_MAX, and > permanently removed by deprecating the Ack/window-based flow control > and perhaps optionally providing Xon/Xoff-style flow control if > absolutely necessary (as was mentioned earlier, both SSHv1 and > SSL/TLS function fine without requiring this). The SFTP-level > handbrake can be removed by eliminating the maximum packet-size > wording of the SFTP specification, and recommending that > implementations read and write all data at once rather than engaging > in additional redundant packetisation at the SFTP level. I'm unconvinced by this, since what you're throwing away here is error reporting and controllability. The useful effect of breaking down reads and writes into individual packets is that you get back intermediate success and failure reports from each one. If the server suddenly stops accepting data half way through writing a 200Mb file - perhaps the disk has filled up - then ideally you want that information communicated back to the client in a timely manner, and not to already be committed to spewing another 100Mb of data down a network connection whose other end can do nothing useful with it. Similarly, if _your_ disk fills up half way through receiving a 200Mb file, you want to be able to ask the server to stop sending you data you can't use. This is a _problem_ with SCP, which SFTP has fixed; don't throw out the baby with the bathwater. I still think a better solution to the SFTP-level `handbrake' would be to use the Kermit approach: simply queue k multiple requests at a time, and every time the nth ack comes in, submit the (n+k)th data packet. Adjust k appropriately (my vague plan is to stop sending data packets as soon as my TCP layer reports that sent data is being queued locally). This is what I plan to do to PSFTP in the reasonably near future. At the SSH level: I'm sure I remember trying to set packet sizes to INT_MAX in an early version of PuTTY. This did cause me trouble, although I don't recall the precise details. I wouldn't be too surprised, though, if some implementation tried to allocate a buffer the size of the window, to avoid fiddly memory allocations going on all the time during channel operation. In which case your `ignore window adjusts and send as fast as you can' strategy might well run into trouble! As Markus observes, the per-channel windows are vital for flow-controlling multiplexed connections running at different rates, so I doubt _unconditionally_ upping window sizes would be a useful change to a general SSH implementation. I might give it a try in PSFTP and PSCP only, however, and see if anyone's implementation still barfs on the idea of a window that big. Do you have any way to fix the SSH level for SFTP uploads? An SSH client which knows it's being used for SFTP can change its own maximum window size, so that the server can send arbitrary quantities of data with no constraint beyond the TCP-level acks. But for uploading, you'd have to persuade the SSH _server_ to change its window size depending on the use the client planned to put the connection to. (Having the server unconditionally set all window sizes to INT_MAX is a silly idea, for multiplexing reasons.) > While I'm pointing out things that should be fixed in the spec, my > other big gripe is the way the initial message is handled. [...] > The way to fix this is simple: Replace all the guessing stuff and > the complex rules that go with it with: > > Key exchange begins by each side sending lists of supported > algorithms. The server sends its list of supported algorithms > first, the client chooses which ones it prefers that it also > supports and sends back its choice in the reply. Well, no problem there. All you have to do to get this fixed is to point it out three years ago, _before_ the draft RFCs were in last call and a large number of fairly polished implementation existed! :-) -- Simon Tatham "Every person has a thinking part that wonders what the part that isn't thinking isn't thinking about." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 05:00: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 FAA14778 for ; Tue, 8 Jul 2003 05:00:09 -0400 (EDT) Received: (qmail 22497 invoked by uid 605); 8 Jul 2003 09:00:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22412 invoked from network); 8 Jul 2003 09:00:04 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 8 Jul 2003 09:00:04 -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 h689006O019542; Tue, 8 Jul 2003 11:00:00 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 3D28C2D041; Tue, 8 Jul 2003 11:00:48 +0200 (CEST) Date: Tue, 8 Jul 2003 11:00:48 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708090047.GA32354@folly> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 04:01:02PM +1200, Peter Gutmann wrote: > In addition to the protocol-level handbrake, the SFTP protocol that runs on > top of SSH contains its own handbrake. This protocol recommends that reads > and writes consist of no more than 32K of data, even though it's running over > the reliable SSH transport which is in turn running over the reliable TCP/IP > transport. One common implementation limits SFTP packets to 4K bytes, > resulting in a mere 4% link utilisation in the previously-presented scenario. OpenSSH's SFTP client sends multiple read-requests before waiting for a reply, so I don't think that the 32K limit is a big problem (you can try to experiment with sftp(1)'s -B and -R option). From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 05:02: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 FAA14828 for ; Tue, 8 Jul 2003 05:02:02 -0400 (EDT) Received: (qmail 23717 invoked by uid 605); 8 Jul 2003 09:02:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23707 invoked from network); 8 Jul 2003 09:01:59 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 8 Jul 2003 09:01:59 -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 h6891s6O019617; Tue, 8 Jul 2003 11:01:54 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 9B3BE2D041; Tue, 8 Jul 2003 11:02:42 +0200 (CEST) Date: Tue, 8 Jul 2003 11:02:42 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708090242.GB32354@folly> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708071216.GA14517@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030708071216.GA14517@folly> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 09:12:16AM +0200, Markus Friedl wrote: > On Tue, Jul 08, 2003 at 04:01:02PM +1200, Peter Gutmann wrote: > > TCP/IP provides a > > reliable, flow-controlled transport layer for the SSH protocol. > > when multiplexing multiple ssh channels over one connection and one > of the consumers is very slow, then the tcp flow control will not > help. AFAIK, this is one of the reasons why there's an additional > per-channel flowcontrol. I'd like to add that ssh/sshd act as a 'distributed' TCP-proxy, so they break end-to-end TCP flow control for forwarded TCP connections. From this point of view, the channel flow control mechanism makes very much sense. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 05:54:31 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16194 for ; Tue, 8 Jul 2003 05:54:30 -0400 (EDT) Received: (qmail 20140 invoked by uid 605); 8 Jul 2003 09:54:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20111 invoked from network); 8 Jul 2003 09:54:27 -0000 Received: from marlborough.concentric.net (HELO marlborough.cnchost.com) (207.155.248.14) by mail.netbsd.org with SMTP; 8 Jul 2003 09:54:27 -0000 Received: from Nucleus (AS-96-199.dial-up.siol.net [212.30.66.199]) by marlborough.cnchost.com id FAA03966; Tue, 8 Jul 2003 05:54:23 -0400 (EDT) [ConcentricHost SMTP Relay 1.15] From: "denis bider" To: "'Peter Gutmann'" , Subject: RE: Why SFTP performance sucks, and how to fix it Date: Tue, 8 Jul 2003 11:54:19 +0200 Message-ID: <000001c34536$e800c160$4700a8c0@Nucleus> 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.2627 Importance: Normal In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Peter, I totally agree that the SSH protocol in some places is more complicated than it needs to be; however, the protocol does not impede performance if properly implemented. According to our experience, it is quite possible to develop a fast SSH implementation if only one invests some thought and care into its design. The ssh.com implementation as well as ours are proof that speeds of several MB per second can be obtained. Further, there are now dozens of implementations that would be broken by your suggestions unnecessarily. While your proposals would make it easier for a naive developer to put together a fast implementation, they remove functionality that makes the protocol complete - making a so-so protocol out of a sophisticated one. The protocol provides you with the means to control the flow of the session, but it doesn't tell you how to do it efficiently. If you want to resolve this, the solution is to write a document describing how to use the control elements for best performance; not to remove them altogether. The protocol is fine. Regards, denis > -----Original Message----- > From: ietf-ssh-owner@netbsd.org > [mailto:ietf-ssh-owner@netbsd.org] On Behalf Of Peter Gutmann > Sent: Tuesday, July 08, 2003 06:01 > To: ietf-ssh@netbsd.org > Subject: Why SFTP performance sucks, and how to fix it > > > Now that I've got your attention... :-). > > The following is a section of the (not-yet-published) paper > "Performance > Characteristics of Application-level Security Protocols", > which looks at, > well, performance characteristics of application-level > security protocols. > One of these is SSH (the rest are SSL, PGP, and S/MIME, in > case anyone cares). > The paper hasn't been published yet (it's still a work in > progress), since it > probably won't be published for awhile (I'm probably > submitting it to Usenix > Security next year) and since the information in this section > could be useful > to SSH developers, I'm posting it here. If people find it of > any use, I might > later post it to one or two general crypto lists to let other crypto > developers know, since it describes the SFTP performance > problem and how to > fix it. > > -- Snip -- > > 6.3 The SSHv2 and SFTP Performance Handbrake > > In 1977, Ward Christensen created the Xmodem data transfer protocol > [Christensen 1977]. Coming in an era of 300bps modems and > unreliable links, > Xmodem divided data into 128-byte packets and required an Ack > to be sent for > each packet before the next one could be transmitted. As > modems became faster > and links more reliable, the need to Ack each Xmodem packet > became more and > more of a performance handbrake, since no matter how fast or > reliable the > link, no more than 128 bytes of data could be sent without > waiting 1 RTT for > the Ack. The solution to the problem was to increase the > packet size (Ymodem, > Xmodem-1K), and drop the requirement to Ack each packet > (Ymodem-g, Zmodem) > [Forsberg 1988]. The latter was perfectly acceptable, since > by then modems > included their own error correction and flow control mechanism. > > Unfortunately this performance handbrake was reinvented in > the SSHv2 protocol. > Like Ymodem-g and Zmodem running over modern modems, TCP/IP provides a > reliable, flow-controlled transport layer for the SSH > protocol. SSHv2 however > introduced an additional form of flow control that, like > Xmodem, requires the > receiver to Ack each packet before more can be sent (the > details aren't quite > as straightforward as this since the SSHv2 specification > describes things in > terms of packets and data windows, but effectively it's the > Xmodem per-packet > Ack). Most implementations seem to use packet sizes of 16K > or occasionally > 32K, with some going as low as 4K. What this means is that > no matter how fast > the link, every (say) 16K the transmission stops for 1 RTT > until the other > side has sent its Ack (referred to as a window adjust in > SSHv2 terminology). > Consider for example the effect of this on a T1 international > link with a > half-second RTT. With the handbrake in operation, the link > can run at only > 17% of its total capacity. This performance hit is so > noticeable that it is > mentioned in the FAQs of some SSH implementations [PuttyFAQ]. > > In addition to the protocol-level handbrake, the SFTP > protocol that runs on > top of SSH contains its own handbrake. This protocol > recommends that reads > and writes consist of no more than 32K of data, even though > it's running over > the reliable SSH transport which is in turn running over the > reliable TCP/IP > transport. One common implementation limits SFTP packets to 4K bytes, > resulting in a mere 4% link utilisation in the > previously-presented scenario. > > The fix for this problem is obvious: Remove the handbrake. > This is no good > reason for the per-packet Ack, and certainly other protocols > such as SSHv1 and > SSL/TLS function perfectly without it (the absence of the > handbrake in SSHv1 > is why SSH FAQs observe that the SSHv1 scp is so much faster > than the SSHv2 > SFTP, even though SFTP is overall a better design). The > effect of running > without the handbrake on were investigated using cryptlib > with a fairly > rudimentary implementation of SFTP running over the built-in SSHv2. > cryptlib's SSH implementation has always set the window size > to INT_MAX (some > implementations have problems with UINT_MAX as the window size), which > effectively disables the SSH-level handbrake. The SFTP implementation > followed suit, requesting a read/write of the entire file at > once rather than > breaking it up into little packets at the SFTP level > (packetisation is already > handled at the SSH and TCP/IP layers). Run over an > international link (pretty > much a given when you're in New Zealand), this SFTP > implementation was around > five times faster than the Putty implementation of SFTP > talking to OpenSSH, > which sends data in 4K SFTP packets and (by extension) 4K SSH > packets. Even > over a low-latency link, the difference was impressive: > cryptlib was an order > of magnitude faster than Putty on the loopback interface > (latency being > relative in this case). > > The SSH-level handbrake can therefore be provisionally > removed by having > implementations set the window size to INT_MAX, and > permanently removed by > deprecating the Ack/window-based flow control and perhaps > optionally providing > Xon/Xoff-style flow control if absolutely necessary (as was > mentioned earlier, > both SSHv1 and SSL/TLS function fine without requiring this). > The SFTP-level > handbrake can be removed by eliminating the maximum > packet-size wording of the > SFTP specification, and recommending that implementations > read and write all > data at once rather than engaging in additional redundant > packetisation at the > SFTP level. > > Most of this can be effected through a simple code change, however > implementors should be aware that many implementations will > still stop and > wait for an Ack after a certain amount of data has been > transmitted, even with > an effectively infinite-sized windows. On the sender side > things aren't quite > so bad, experimentation has shown that it's fairly safe to ignore the > receiver's window size and send data at the maximum rate > possible, discarding > any window adjusts that arrive (the only slight complication > is that it's > occasionally necessary to stop sending for a moment and clear > the read channel > of the accumulation of Acks that have arrived while sending). > Since most > implementations include a facility for checking the peer's > software version to > identify and work around implementation bugs, detecting > pre-handbrake-fix > implementations and providing the appropriate slower > interpretation of the > protocol should be relatively straightforward. In addition, > FAQs about the > poor performance of SFTP will need to be updated. > > [Christensen 1977] "MODEM.ASM", Ward Christensen, August 1977 > (the Xmodem > protocol was defined in terms of "What this program does" > rather than being > formally documented, the author described it in a Compuserve > post some years > later as "a quick hack I threw together"). > > [Forsberg 1988] "Xmodem/Ymodem Protocol Reference: A > compendium of documents > describing the Xmodem and Ymodem File Transfer Protocols", > Chuck Forsberg, > October 1988. > > [PuttyFAQ] "PuTTY FAQ", Simon Tatham, 2003, > http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html, > question A.6.8, > "PSFTP transfers files much slower than PSCP". > > -- Snip -- > > While I'm pointing out things that should be fixed in the > spec, my other big > gripe is the way the initial message is handled. Currently > the spec describes > a rather messy mechanism where both sides start by shouting > at each other and > then engage in a complex dance to sort out what's what afterwards (the > "guessing" stuff). This leads to really messy > implementations when one of the > partners doesn't get the dance steps right. > > There is no good reason for this complication in the > protocol. I don't buy > the RTT argument given in the SSH-transport draft, the > guessing stuff saves > one whole RTT, but then the incredibly chatty authentication > protocol ("Would > you like to authenticate then?" - "Yes I'd like to > authenticate" - "How would > you like to authenticate?" - "Well, would the following suit > you?" - "That > looks about right, let's do it" - "Right, I'm about to start" > - etc etc etc) > more than makes up for any miniscule savings during the > initial handshake. > > The way to fix this is simple: Replace all the guessing stuff > and the complex > rules that go with it with: > > Key exchange begins by each side sending lists of supported > algorithms. The > server sends its list of supported algorithms first, the > client chooses > which ones it prefers that it also supports and sends back > its choice in the > reply. > > That removes all of the handshake-dance complexity, and > vastly simplifies > implementations. > > Oh yes, in case anyone finds the SFTP info above useful and > wants to reference > it for some reason, please cite it as '"Performance Characteristics of > Application-level Security Protocols", Peter Gutmann, to > appear', since it's > not officially published yet. > > Peter. > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 08:58:11 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 IAA20090 for ; Tue, 8 Jul 2003 08:58:11 -0400 (EDT) Received: (qmail 24164 invoked by uid 605); 8 Jul 2003 12:58:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24156 invoked from network); 8 Jul 2003 12:58:06 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 8 Jul 2003 12:58:06 -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 h68Cw06O002293; Tue, 8 Jul 2003 14:58:00 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 161C62D041; Tue, 8 Jul 2003 14:58:48 +0200 (CEST) Date: Tue, 8 Jul 2003 14:58:48 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708125847.GA27655@folly> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 04:01:02PM +1200, Peter Gutmann wrote: > While I'm pointing out things that should be fixed in the spec, my other big > gripe is the way the initial message is handled. Currently the spec describes > a rather messy mechanism where both sides start by shouting at each other and > then engage in a complex dance to sort out what's what afterwards (the > "guessing" stuff). This leads to really messy implementations when one of the > partners doesn't get the dance steps right. I think that the 'guessing" stuff' is ugly, but it's not very hard to skip the first kex packet in case the 'guess' is wrong. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 10:25:04 2003 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24257 for ; Tue, 8 Jul 2003 10:25:03 -0400 (EDT) Received: (qmail 6675 invoked by uid 605); 8 Jul 2003 14:24:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6654 invoked from network); 8 Jul 2003 14:24:28 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 8 Jul 2003 14:24:28 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h68EOO1J019492; Tue, 8 Jul 2003 08:24:24 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h68EOO27007063; Tue, 8 Jul 2003 10:24:24 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h68EOOq3007787; Tue, 8 Jul 2003 10:24:24 -0400 (EDT) Message-Id: <200307081424.h68EOOq3007787@thunk.east.sun.com> From: Bill Sommerfeld To: Markus Friedl cc: Peter Gutmann , ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it In-Reply-To: Your message of "Tue, 08 Jul 2003 09:12:16 +0200." <20030708071216.GA14517@folly> Reply-to: sommerfeld@east.sun.com Date: Tue, 08 Jul 2003 10:24:24 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list I believe I may have been responsible for demonstrating to one of the sshv1 implementors why the omission of per-channel flow control was a mistake. I don't recall exactly *which* test case I used to demonstrate it but it either involved regular connection forwarding or X11 forwarding. In short, if you pause an entity reading off a channel, you either need infinite buffering in the ssh receiver point (to allow the receiver to read and buffer arbitrary amounts of data for the paused channel), or else you will end up flow-controlling the ssh connection, possibly leading to a deadlock (because the only way to unpause the channel is by sending data over another channel..) example: stopping an X client using either UNIX job control or a debugger. the X client will keep receiving events from the X server while stopped; eventually enough will build up to begin to require flow control backpressure.. If the main ssh pipe is blocked, you can't send the "continue".. Now, I think the trick for good performance is to ensure that the ssh windows are large enough that when the applications are *not* flow controlled you can keep the the TCP pipe filled more often than not. I suspect this means "somewhat larger than the TCP window". But some experimentation is likely in order.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 11:03: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 LAA25474 for ; Tue, 8 Jul 2003 11:03:37 -0400 (EDT) Received: (qmail 25979 invoked by uid 605); 8 Jul 2003 15:03:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25971 invoked from network); 8 Jul 2003 15:03:31 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 8 Jul 2003 15:03:31 -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 h68F3Q1J012588; Tue, 8 Jul 2003 09:03:26 -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 h68F3QQf025337; Tue, 8 Jul 2003 09:03:26 -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 h68F0KQx018743; Tue, 8 Jul 2003 08:00:20 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h68F0Jfv018742; Tue, 8 Jul 2003 08:00:19 -0700 (PDT) Date: Tue, 8 Jul 2003 08:00:19 -0700 From: Nicolas Williams To: Martin Pool Cc: Peter Gutmann , ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708080015.A18719@binky.central.sun.com> References: <200307080514.h685EsG03449@medusa01.cs.auckland.ac.nz> <20030708053846.GV16531@vexed.ozlabs.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20030708053846.GV16531@vexed.ozlabs.hp.com>; from mbp@samba.org on Tue, Jul 08, 2003 at 03:38:48PM +1000 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 03:38:48PM +1000, Martin Pool wrote: > On 8 Jul 2003, Peter Gutmann wrote: > > Martin Pool writes: > > > > Fair enough. I guess the XON/XOFF thing (to replace the Ack) would do this, > > or perhaps a channel close depending on the seriousness of the > > error. > > Channel close is a terrible error handling method. To start with, it > gives no indication of what in particular went wrong. Indeed. SFTP is not like FTP where there's separate channels for control data and data - closing the channel means killing the session with no useful error indication. > I don't know of a means for a Unix or Windows server to "lock" disk > space in that way. I suppose the server might zero-fill the blocks > between getting the start of the request and reading the bulk of it, > but that seems highly contrived. And inefficient. > I suspect that sending a block-at-a-time can give good performance if > you choose a good block size and pipeline transmissions, and if > problems with the underlying transport are addressed. Perhaps IOs > should be roughly proportional to the amount of data in flight? I > think the request/response model in SECSH is a great thing for > simplicity and robustness and it shouldn't be lightly cast aside. The SFTP protocol is, in some ways, more like a remote filesystem protocol than like a file transfer protocol (my observation - I'm not saying it should be). Thus a client can interleave read/write requests relating to multiple files over the same channel. But note that the client is not required to wait for SFTP "Acks" before proceeding with other requests. SFTP clients are allowed[1] to issue reads/writes for entire files before handling a single reply to any of them. Doing so may not be wise for very large file transfers, as Martin points out. The fact is that SFTP does not have an Ack "handbrake" - it has Acks, but no Ack handbrake. Implementations may, but not the specification. [1] Or, rather, such client behaviour is not forbidden by the text of the I-D. Pipelining block-at-a-time requests is not disallowed; perhaps it should be encouraged. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 11:23: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 LAA26483 for ; Tue, 8 Jul 2003 11:23:32 -0400 (EDT) Received: (qmail 5023 invoked by uid 605); 8 Jul 2003 15:23:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5016 invoked from network); 8 Jul 2003 15:23:31 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 8 Jul 2003 15:23:31 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h68FMvfU027108; Tue, 8 Jul 2003 08:22:57 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h68FMv27021250; Tue, 8 Jul 2003 11:22:57 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h68FMuq3008057; Tue, 8 Jul 2003 11:22:56 -0400 (EDT) Message-Id: <200307081522.h68FMuq3008057@thunk.east.sun.com> From: Bill Sommerfeld To: agenda@ietf.org cc: ietf-ssh@netbsd.org Subject: Secure Shell (SECSH) Agenda for IETF 57 (Vienna) Reply-to: sommerfeld@east.sun.com Date: Tue, 08 Jul 2003 11:22:56 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list Secure Shell Working Group (secsh) WEDNESDAY, July 16th, 2003 at 0900-1130 CHAIR: Bill Sommerfeld AGENDA: initialization vector/agenda bashing 5 minutes status of core drafts 10 minutes draft-ietf-secsh-assignednumbers draft-ietf-secsh-architecture draft-ietf-secsh-connect draft-ietf-secsh-transport draft-ietf-secsh-userauth status of extensions draft 10 minutes Open issues and discussions 60 minutes From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 11:49: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 LAA27835 for ; Tue, 8 Jul 2003 11:49:35 -0400 (EDT) Received: (qmail 17011 invoked by uid 605); 8 Jul 2003 15:49:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17003 invoked from network); 8 Jul 2003 15:49:19 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 8 Jul 2003 15:49:19 -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 h68FnH1J011499; Tue, 8 Jul 2003 09:49:17 -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 h68FnGQf010595; Tue, 8 Jul 2003 09:49:16 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h68FkBQx018786; Tue, 8 Jul 2003 08:46:11 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h68FkBO5018785; Tue, 8 Jul 2003 08:46:11 -0700 (PDT) Date: Tue, 8 Jul 2003 08:46:10 -0700 From: Nicolas Williams To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708084607.A18772@binky.central.sun.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz>; from pgut001@cs.auckland.ac.nz on Tue, Jul 08, 2003 at 04:01:02PM +1200 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 04:01:02PM +1200, Peter Gutmann wrote: > [...] Good write up! Implementations could start with small SECSH channel window sizes and grow them as needed so as to maximize throughout without creating bottlenecks. A slow-start for SSHv2, so to speak. Consider an implementation such as OpenSSH where the SECSH protocol and the SFTP protocol are implemented in separate processes communicating over IPC. With such an implementation one might, in some situations, end up having a bottleneck in the IPC connection, rather than in the client-server TCP connection, and under such circumstances one might like the SECSH channel flow control mechanism to work as advertised. But when there is no bottleneck flow control does become a "handbrake." And I've already pointed out that SFTP has no Ack handbrake. > -- Snip -- > > While I'm pointing out things that should be fixed in the spec, my other big > gripe is the way the initial message is handled. Currently the spec describes > a rather messy mechanism where both sides start by shouting at each other and > then engage in a complex dance to sort out what's what afterwards (the > "guessing" stuff). This leads to really messy implementations when one of the > partners doesn't get the dance steps right. I don't think the optimistic key exchange concept is difficult to implement. I am, however, bothered that only one kex attempt can be made per-connection (whereas many authentication attempts can be made per-connection). I also think that the kex negotiation is a bit clumsy in some ways - see the recent threads started by Joel N. Webber II. On the other hand, the key exchange negotiation part of the protocol and how it factors into the session ID generation is a crucial aspect of the protocol's security, and so keeping it simple/stupid is actually quite a reasonable thing to do. > There is no good reason for this complication in the protocol. I don't buy > the RTT argument given in the SSH-transport draft, the guessing stuff saves > one whole RTT, but then the incredibly chatty authentication protocol ("Would > you like to authenticate then?" - "Yes I'd like to authenticate" - "How would > you like to authenticate?" - "Well, would the following suit you?" - "That > looks about right, let's do it" - "Right, I'm about to start" - etc etc etc) > more than makes up for any miniscule savings during the initial handshake. > > The way to fix this is simple: Replace all the guessing stuff and the complex > rules that go with it with: > > Key exchange begins by each side sending lists of supported algorithms. The > server sends its list of supported algorithms first, the client chooses > which ones it prefers that it also supports and sends back its choice in the > reply. We've recently seen that exchanging lists of algorithms is not good enough. > That removes all of the handshake-dance complexity, and vastly simplifies > implementations. Of course, it's really too late to consider modifying the key exchange protocol. Perhaps for version 2.1 of the protocol... Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 12:03: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 MAA28715 for ; Tue, 8 Jul 2003 12:02:49 -0400 (EDT) Received: (qmail 24558 invoked by uid 605); 8 Jul 2003 16:02:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24551 invoked from network); 8 Jul 2003 16:02:44 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 8 Jul 2003 16:02:44 -0000 Received: from extremenetworks.com (unknown [10.18.3.105]) by gnat.inet.org (Postfix) with ESMTP id B4D6667105 for ; Tue, 8 Jul 2003 12:29:03 -0400 (EDT) Date: Tue, 8 Jul 2003 12:02:27 -0400 Subject: Re: Why SFTP performance sucks, and how to fix it Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: ietf-ssh@netbsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <20030708084607.A18772@binky.central.sun.com> Message-Id: <925627D9-B15D-11D7-9B88-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit An Informational RFC describing the issues here, including why we are where we are with the spec, but also discussing the other implications and possible future directions to consider, would seem useful. Starting with an Informational RFC (rather than discussing immediate changes to specifications that are long overdue) would avoid de-railing the current effort to get the specifications out as RFCs, document the issues clearly for the benefit of both implementers and operators, and help focus discussion in the WG on possible paths forward. IMHO, Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 12:04: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 MAA28917 for ; Tue, 8 Jul 2003 12:04:47 -0400 (EDT) Received: (qmail 25601 invoked by uid 605); 8 Jul 2003 16:04:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25593 invoked from network); 8 Jul 2003 16:04:45 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 8 Jul 2003 16:04:45 -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 h68G4c6O016223; Tue, 8 Jul 2003 18:04:39 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id AACF72D041; Tue, 8 Jul 2003 18:05:25 +0200 (CEST) Date: Tue, 8 Jul 2003 18:05:25 +0200 From: Markus Friedl To: Nicolas Williams Cc: Peter Gutmann , ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708160525.GA260@folly> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030708084607.A18772@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 08:46:10AM -0700, Nicolas Williams wrote: > Consider an implementation such as OpenSSH where the SECSH protocol and > the SFTP protocol are implemented in separate processes communicating > over IPC. With such an implementation one might, in some situations, > end up having a bottleneck in the IPC connection, rather than in the > client-server TCP connection, and under such circumstances one might > like the SECSH channel flow control mechanism to work as advertised. feel free to send patches.... From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 12:19: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 MAA29302 for ; Tue, 8 Jul 2003 12:19:29 -0400 (EDT) Received: (qmail 4421 invoked by uid 605); 8 Jul 2003 16:19:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4414 invoked from network); 8 Jul 2003 16:19:15 -0000 Received: from marionberry.cc.columbia.edu (128.59.59.100) by mail.netbsd.org with SMTP; 8 Jul 2003 16:19:15 -0000 Received: from columbia.edu (66-108-138-151.nyc.rr.com [66.108.138.151]) (user=jaltman mech=PLAIN bits=0) by marionberry.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h68GJAUO023468 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 8 Jul 2003 12:19:11 -0400 (EDT) Message-ID: <3F0AEEF6.5000100@columbia.edu> Date: Tue, 08 Jul 2003 12:19:02 -0400 From: Jeffrey Altman Reply-To: ietf-ssh@netbsd.org Organization: Columbia University in the City of New York User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> In-Reply-To: <20030708084607.A18772@binky.central.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit If someone wants to experiment, feel free to take a look at the SKERMIT (Secure shell Kermit) subsystem which is available for use with OpenSSH. http://www.kermit-project.org/skermit.html This is simply C-Kermit 8.0 running as an SSH subsystem just like SFTP. You can control from the C-Kermit or Kermit 95 client whether or not you wish to use Streaming Kermit transfers (the default) or traditional Sliding-windows Kermit with slow start. When slow start is used the packet size starts small and grows to the maximum implemented 9024 bytes (Kermit protocol allows packets up to 866,304 bytes but no one has ever required it.) It might give you a better idea of the performance characters. Jeffrey Altman Nicolas Williams wrote: > On Tue, Jul 08, 2003 at 04:01:02PM +1200, Peter Gutmann wrote: > >>[...] > > Good write up! > > Implementations could start with small SECSH channel window sizes and > grow them as needed so as to maximize throughout without creating > bottlenecks. A slow-start for SSHv2, so to speak. > > Consider an implementation such as OpenSSH where the SECSH protocol and > the SFTP protocol are implemented in separate processes communicating > over IPC. With such an implementation one might, in some situations, > end up having a bottleneck in the IPC connection, rather than in the > client-server TCP connection, and under such circumstances one might > like the SECSH channel flow control mechanism to work as advertised. > > But when there is no bottleneck flow control does become a "handbrake." > > And I've already pointed out that SFTP has no Ack handbrake. > > >>-- Snip -- >> >>While I'm pointing out things that should be fixed in the spec, my other big >>gripe is the way the initial message is handled. Currently the spec describes >>a rather messy mechanism where both sides start by shouting at each other and >>then engage in a complex dance to sort out what's what afterwards (the >>"guessing" stuff). This leads to really messy implementations when one of the >>partners doesn't get the dance steps right. > > > I don't think the optimistic key exchange concept is difficult to > implement. I am, however, bothered that only one kex attempt can be > made per-connection (whereas many authentication attempts can be made > per-connection). > > I also think that the kex negotiation is a bit clumsy in some ways - see > the recent threads started by Joel N. Webber II. > > On the other hand, the key exchange negotiation part of the protocol and > how it factors into the session ID generation is a crucial aspect of the > protocol's security, and so keeping it simple/stupid is actually quite a > reasonable thing to do. > > >>There is no good reason for this complication in the protocol. I don't buy >>the RTT argument given in the SSH-transport draft, the guessing stuff saves >>one whole RTT, but then the incredibly chatty authentication protocol ("Would >>you like to authenticate then?" - "Yes I'd like to authenticate" - "How would >>you like to authenticate?" - "Well, would the following suit you?" - "That >>looks about right, let's do it" - "Right, I'm about to start" - etc etc etc) >>more than makes up for any miniscule savings during the initial handshake. >> >>The way to fix this is simple: Replace all the guessing stuff and the complex >>rules that go with it with: >> >> Key exchange begins by each side sending lists of supported algorithms. The >> server sends its list of supported algorithms first, the client chooses >> which ones it prefers that it also supports and sends back its choice in the >> reply. > > > We've recently seen that exchanging lists of algorithms is not good > enough. > > >>That removes all of the handshake-dance complexity, and vastly simplifies >>implementations. > > > Of course, it's really too late to consider modifying the key exchange > protocol. Perhaps for version 2.1 of the protocol... > > Cheers, > > Nico From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 14:04: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 OAA02369 for ; Tue, 8 Jul 2003 14:04:38 -0400 (EDT) Received: (qmail 27741 invoked by uid 605); 8 Jul 2003 18:04:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27726 invoked from network); 8 Jul 2003 18:04:23 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 8 Jul 2003 18:04:23 -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 h68I4JKo022064; Tue, 8 Jul 2003 11:04:19 -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 h68I4IlI006600; Tue, 8 Jul 2003 12:04:18 -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 h68I1CQx028551; Tue, 8 Jul 2003 11:01:12 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h68I1BvH028550; Tue, 8 Jul 2003 11:01:11 -0700 (PDT) Date: Tue, 8 Jul 2003 11:01:11 -0700 From: Nicolas Williams To: Markus Friedl Cc: Peter Gutmann , ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708180111.GB20390@binky.central.sun.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> <20030708160525.GA260@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030708160525.GA260@folly> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 06:05:25PM +0200, Markus Friedl wrote: > On Tue, Jul 08, 2003 at 08:46:10AM -0700, Nicolas Williams wrote: > > Consider an implementation such as OpenSSH where the SECSH protocol and > > the SFTP protocol are implemented in separate processes communicating > > over IPC. With such an implementation one might, in some situations, > > end up having a bottleneck in the IPC connection, rather than in the > > client-server TCP connection, and under such circumstances one might > > like the SECSH channel flow control mechanism to work as advertised. > > feel free to send patches.... Before we talk about patches I'd like to get a few more details straightened out. OpenSSH has a per-channel max window size that controls the max value for the actual window size. I think a way slow-start (and slow-stop) could be implemented would be to adjust the per-channel max window size according to the status of the per-channel data sink when data is received: - Slow-start When data is received on a channel and the channel's sink is writable, increase the channel's max window size by some amount. - Slow-stop When data is received on a channel and the channel's sink is not writable, reduce the channel's max window size by some amount, but don't allow the channel's max window size to become lower than the actual window size. The question is: what should this "some amount" be? It could a constant, or the size of the data received that triggered the max window size adjustment. Or maybe the max window size adjustments algorithm could be more aggressive so that slow-starts/stops aren't that slow... Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 14:33: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 OAA03297 for ; Tue, 8 Jul 2003 14:33:03 -0400 (EDT) Received: (qmail 12975 invoked by uid 605); 8 Jul 2003 18:33:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12968 invoked from network); 8 Jul 2003 18:32:59 -0000 Received: from mail-in-03.arcor-online.net (151.189.21.43) by mail.netbsd.org with SMTP; 8 Jul 2003 18:32:59 -0000 Received: from localhost.arcor.net (dsl-213-023-019-113.arcor-ip.net [213.23.19.113]) by mail-in-03.arcor-online.net (Postfix) with ESMTP id 72C6A3F568; Tue, 8 Jul 2003 20:32:57 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id 6BBD42D041; Tue, 8 Jul 2003 20:33:42 +0200 (CEST) Date: Tue, 8 Jul 2003 20:33:42 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708183342.GB9880@folly> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jul 08, 2003 at 04:01:02PM +1200, Peter Gutmann wrote: > What this means is that no matter how fast > the link, every (say) 16K the transmission stops for 1 RTT until the other > side has sent its Ack (referred to as a window adjust in SSHv2 terminology). Well, the problem here is the window size, not the packet size. > In addition to the protocol-level handbrake, the SFTP protocol that runs on > top of SSH contains its own handbrake. That's not true. While early SFTP implementations did wait for the per-packet ACK, most recent implemenations (both ssh.com and OpenSSH) send multiple concurrent requests. For example, when running with 2 concurrent requests (sftp -R 2) the throughput improves from ~600K/s to ~1.9M/s for simple tests. > The fix for this problem is obvious: Remove the handbrake. This is no good > reason for the per-packet Ack, and certainly other protocols such as SSHv1 and > SSL/TLS function perfectly without it (the absence of the handbrake in SSHv1 SSL/TLS does not do port-forwarding, and SSHv1's lack of flow control can cause problems when multiplexing different channels over SSH. > is why SSH FAQs observe that the SSHv1 scp is so much faster than the SSHv2 > SFTP, even though SFTP is overall a better design). With OpenSSH's default (16 concurrent requests) I almost get scp(1) like performance in sftp(1), so I doubt it's a SFTP protocol issue. > The SSH-level handbrake can therefore be provisionally removed by having > implementations set the window size to INT_MAX, and permanently removed by This would mean that the implementatios have to buffer up to INT_MAX bytes per channel. > deprecating the Ack/window-based flow control and perhaps optionally providing > Xon/Xoff-style flow control if absolutely necessary SSH is more than just a file transfer protocol. > (as was mentioned earlier, > both SSHv1 and SSL/TLS function fine without requiring this). Again SSHv1 does not function fine :) > The SFTP-level > handbrake can be removed by eliminating the maximum packet-size wording of the > SFTP specification, and recommending that implementations read and write all > data at once rather than engaging in additional redundant packetisation at the > SFTP level. Interleaving requests could be mentioned in the SFTP spec in an implementation hint section. > experimentation has shown that it's fairly safe to ignore the > receiver's window size and send data at the maximum rate possible, discarding > any window adjusts that arrive I hope there are not many SSH implementations out there doing this :) -markus From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 16:18: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 QAA08812 for ; Tue, 8 Jul 2003 16:18:00 -0400 (EDT) Received: (qmail 5016 invoked by uid 605); 8 Jul 2003 20:17:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5008 invoked from network); 8 Jul 2003 20:17:57 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 8 Jul 2003 20:17:57 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h68KHs6j038991 for ; Tue, 8 Jul 2003 14:17:55 -0600 (MDT) Message-ID: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: Subject: Publickey subsystem draft posted Date: Tue, 8 Jul 2003 14:16:32 -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 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=10.0 tests=none version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit We've refreshed the individual draft of the "Secure Shell Public-Key Subsystem". The new draft is available here: http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-subsystem-01.txt The public-key subsystem is a mechanism that allows authenticated clients to upload/manage their public keys through an implementation-independent interface. In the past, we've felt that there has been some interest in pursuing this draft as a working group document. I'd be happy to hear whatever feedback you have on what steps might help move the document in that direction. thanks, Brent McClure bdm@vandyke.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 18:13: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 SAA13564 for ; Tue, 8 Jul 2003 18:13:48 -0400 (EDT) Received: (qmail 8009 invoked by uid 605); 8 Jul 2003 22:13:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8000 invoked from network); 8 Jul 2003 22:13:43 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 8 Jul 2003 22:13:43 -0000 Received: by xanthine.gratuitous.org with local; Tue, 08 Jul 2003 18:13:29 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: Peter Gutmann , ietf-ssh@netbsd.org In-reply-to: <20030708084607.A18772@binky.central.sun.com> (message from Nicolas Williams on Tue, 8 Jul 2003 08:46:10 -0700) Subject: Re: Why SFTP performance sucks, and how to fix it References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> Message-Id: Date: Tue, 08 Jul 2003 18:13:29 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I don't think the optimistic key exchange concept is difficult to > implement. I am, however, bothered that only one kex attempt can be > made per-connection (whereas many authentication attempts can be made > per-connection). In looking at the transport draft for the word ``disconnect'', it seems that the places where disconnection is explicitly a MUST related to key exchange are places where there are no algorithms in common at all, the idea apparently being that you list all the algorithms that are supported, because you either support a particular key exchange algorithm, or you don't, and you either are willing to use a particular host key algorithm, or you aren't, etc. But I don't see any reason why we would need to define a different protocol version number if we wanted to offer the option of trying a second round of key exchange when doing initial keying. A Secure Shell implementation that wants to do this could simply use SSH_MSG_DEBUG rather than SSH_MSG_DISCONNECT for error reporting, and then assume that doing another round of key exchange will work. Any implementation that follows the current draft will presumably decide that it's got a fatal error when it sees a key exchange message in the wrong place, and will fall back to the old behavior of simply terminating the connection. And when rekeying, you could simply keep using the old keys if rekeying fails, and rekey early enough that you'll be able to retry a few times before your keys actually need to expire. > On the other hand, the key exchange negotiation part of the protocol and > how it factors into the session ID generation is a crucial aspect of the > protocol's security, and so keeping it simple/stupid is actually quite a > reasonable thing to do. Unless you can get into a state where the server thinks that key exchange was successful and the client thinks it was unsuccessful, or vice versa, I'm not sure why this actually becomes a problem. The places key exchange can fail when both sides support the same algorithm, assuming the connection doesn't break and you don't have a man in the middle: 1) GSSAPI failures, which generally are going to happen early in the process, before you successfully transfer your large numbers (since the public diffie-hellman numbers get encrypted with GSSAPI). 2) The client deciding that it doesn't trust a particular public key. This is more annoying in some ways, since the public key is sent at the end of the process, and the server has already done all the computation it is going to do for key exchange by the time the client is able to figure out that there is a problem. In particular, I think a server could send SSH_MSG_NEWKEYS right after it sends the message containing its public key and the signature, at which point, if the client decides it doesn't trust that key, you have a random untrusted encryption key encrypting one direction of the second attempt at initial key exchange. However, if the rule is that the session ID used for the session by the userauth protocol is taken from the first key exchange which resulted in both the client and the server sending SSH_MSG_NEWKEYS, I don't see where this is a problem. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 18:25: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 SAA13966 for ; Tue, 8 Jul 2003 18:25:41 -0400 (EDT) Received: (qmail 14909 invoked by uid 605); 8 Jul 2003 22:25:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14901 invoked from network); 8 Jul 2003 22:25:41 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 8 Jul 2003 22:25:41 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h68MPaKo023346; Tue, 8 Jul 2003 15:25:36 -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 h68MPaQf014501; Tue, 8 Jul 2003 16:25: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 h68MMWQx000162; Tue, 8 Jul 2003 15:22:32 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h68MMVHC000161; Tue, 8 Jul 2003 15:22:31 -0700 (PDT) Date: Tue, 8 Jul 2003 15:22:31 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Peter Gutmann , ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030708222231.GG20390@binky.central.sun.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list [OT] On Tue, Jul 08, 2003 at 06:13:29PM -0400, Joel N. Weber II wrote: > Unless you can get into a state where the server thinks that key > exchange was successful and the client thinks it was unsuccessful, or > vice versa, I'm not sure why this actually becomes a problem. > > The places key exchange can fail when both sides support the same > algorithm, assuming the connection doesn't break and you don't have a > man in the middle: > > 1) GSSAPI failures, which generally are going to happen early in the > process, before you successfully transfer your large numbers (since > the public diffie-hellman numbers get encrypted with GSSAPI). I've experienced this one enough times (for a variety of reasons) that I've wished that the client could then re-try w/o gss keyex. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jul 8 18:35: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 SAA14242 for ; Tue, 8 Jul 2003 18:35:46 -0400 (EDT) Received: (qmail 21722 invoked by uid 605); 8 Jul 2003 22:35:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21712 invoked from network); 8 Jul 2003 22:35:44 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 8 Jul 2003 22:35:44 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1667970; Tue, 08 Jul 2003 16:35:43 -0600 Message-ID: <3F0B473F.8070203@vandyke.com> Date: Tue, 08 Jul 2003 16:35:43 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Simon Tatham CC: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it 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 >Do you have any way to fix the SSH level for SFTP uploads? An SSH >client which knows it's being used for SFTP can change its own >maximum window size, so that the server can send arbitrary >quantities of data with no constraint beyond the TCP-level acks. But >for uploading, you'd have to persuade the SSH _server_ to change its >window size depending on the use the client planned to put the >connection to. (Having the server unconditionally set all window >sizes to INT_MAX is a silly idea, for multiplexing reasons.) > > Well, the problem is that subsystems take a channel of type a and turn it into a channel of type b. If the server knew up front what you wanted, it could pick appropriate values. I've always thought subsystems were a bad idea. That said, the server could notice when you make a sftp-subsystem request and send you a window adjust message for window you haven't consumed. (I don't believe anything in the drafts prohibits this.) This would essentially increase your total available window. Unfortunately, there is nothing that can be done about the maximum packet size on the channel (which also plays into this whole mess.) Well, we could introduct a channel request to notify the remote pee that the per channel max packet size has been changed could be sent. If that channel request succeeds, then larger packets could be sent. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jul 9 01:14: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 BAA22459 for ; Wed, 9 Jul 2003 01:14:36 -0400 (EDT) Received: (qmail 5642 invoked by uid 605); 9 Jul 2003 05:14:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5634 invoked from network); 9 Jul 2003 05:14:31 -0000 Received: from sngrel5.hp.com (192.6.86.210) by mail.netbsd.org with SMTP; 9 Jul 2003 05:14:31 -0000 Received: from XAUBRG2.AUS.HP.COM (xaubrg2.aus.hp.com [15.23.69.43]) by sngrel5.hp.com (Postfix) with SMTP id 104919A2 for ; Wed, 9 Jul 2003 13:14:23 +0800 (SGP) Received: from 15.23.69.43 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Wed, 09 Jul 2003 15:14:04 +1000 Received: from XAUBRG2.AUS.HP.COM (localhost [127.0.0.1]) by XAUBRG2.AUS.HP.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id N1PPAZP4; Wed, 9 Jul 2003 15:14:04 +1000 Received: from 16.176.65.78 by XAUBRG2.AUS.HP.COM (InterScan E-Mail VirusWall NT); Wed, 09 Jul 2003 15:14:03 +1000 Received: from mbp by vexed with local (Exim 3.36 #1 (Debian)) id 19a7G5-00005U-00; Wed, 09 Jul 2003 15:12:49 +1000 Date: Wed, 9 Jul 2003 15:12:49 +1000 From: "'Martin Pool'" To: Howard Chu Cc: "'Peter Gutmann'" , ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030709051248.GK26082@vexed.ozlabs.hp.com> References: <20030708053846.GV16531@vexed.ozlabs.hp.com> <005e01c3452d$f3ab4ac0$0e01a8c0@CELLO> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005e01c3452d$f3ab4ac0$0e01a8c0@CELLO> X-GPG: 1024D/A0B3E88B: AFAC578F 1841EE6B FD95E143 3C63CA3F A0B3E88B User-Agent: Mutt/1.5.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On 8 Jul 2003, Howard Chu wrote: > > From: ietf-ssh-owner@netbsd.org [mailto:ietf-ssh-owner@netbsd.org]On Behalf > Of Martin Pool > > > On 8 Jul 2003, Peter Gutmann wrote: > > > Another thing to keep in mind here is that if you signal a > > > read/write of the > > > entire file at once, the receiver knows how much disk space > > > it needs and can > > > lock the space before starting the receive > > > > I don't know of a means for a Unix or Windows server to "lock" disk > > space in that way. I suppose the server might zero-fill the blocks > > between getting the start of the request and reading the bulk of it, > > but that seems highly contrived. > > The FTP protocol has an ALLO command for allocating space in advance. On some > FTP servers I've seen, they do exactly this - zero-fill that much space. It > is a pretty foolproof way of accomplishing the task, even if it seems > contrived. There are realistic cases where it might fail: compressed filesystems might be able to store 2G of zeros, but not 2G of real data; versioned filesystems may run out of space when rewriting an existing file; or the user might be in a grace period for disk quotas that expires during the transfer. It would give some assurance that there is enough space, but it's not foolproof. But my main point is that it is *unavoidable* that disk operations can fail during writing. Out of space is only one possibility; hardware errors are another. A protocol that relies on writing the whole file in one operation can only handle this by either wasting time and bandwidth on an operation that is known to have failed, or by dropping the connection without (inline) explanation. Another advantage of course is that the client can reconnect and resume a transfer. > > > I'd really prefer to know before I start that a transfer is going to > > > fail, rather than write 2GB and then get the out-of-disk error. > > Definitely. I suppose you could usefully add a preallocation operation as an extension command, but it won't be a guarantee. -- Martin From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jul 9 13:26: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 NAA11115 for ; Wed, 9 Jul 2003 13:26:13 -0400 (EDT) Received: (qmail 18393 invoked by uid 605); 9 Jul 2003 17:26:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18380 invoked from network); 9 Jul 2003 17:26:07 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Jul 2003 17:26:07 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1670094; Wed, 09 Jul 2003 11:26:06 -0600 Message-ID: <3F0C502E.4020709@vandyke.com> Date: Wed, 09 Jul 2003 11:26:06 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: "'Martin Pool'" CC: Howard Chu , "'Peter Gutmann'" , ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it References: <20030708053846.GV16531@vexed.ozlabs.hp.com> <005e01c3452d$f3ab4ac0$0e01a8c0@CELLO> <20030709051248.GK26082@vexed.ozlabs.hp.com> In-Reply-To: <20030709051248.GK26082@vexed.ozlabs.hp.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 'Martin Pool' wrote: >I suppose you could usefully add a preallocation operation as an >extension command, but it won't be a guarantee. > > The current draft specifies that if file size in the attrs field is present during file creation, it should be considered a hint as to the file's eventual size. (Section 5.3) I'm not sure if this is good enough or not though. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jul 9 13:48: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 NAA11876 for ; Wed, 9 Jul 2003 13:48:55 -0400 (EDT) Received: (qmail 29175 invoked by uid 605); 9 Jul 2003 17:48:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29165 invoked from network); 9 Jul 2003 17:48:48 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 9 Jul 2003 17:48:48 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jul 2003 13:50:01 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86051AC109@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , "'Martin Pool'" Cc: Howard Chu , "'Peter Gutmann'" , ietf-ssh@netbsd.org Subject: RE: Why SFTP performance sucks, and how to fix it Date: Wed, 9 Jul 2003 13:50:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list I believe that passing the size attribute with the open is sufficient to do pre-allocation if it is desired. In Process Software's implementation of SFTP when both sides are VMS the size and many other attributes are passed at file open time in order to preserve file format information. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Wednesday, July 09, 2003 1:26 PM To: 'Martin Pool' Cc: Howard Chu; 'Peter Gutmann'; ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it 'Martin Pool' wrote: >I suppose you could usefully add a preallocation operation as an >extension command, but it won't be a guarantee. > > The current draft specifies that if file size in the attrs field is present during file creation, it should be considered a hint as to the file's eventual size. (Section 5.3) I'm not sure if this is good enough or not though. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jul 9 18:19: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 SAA26562 for ; Wed, 9 Jul 2003 18:19:55 -0400 (EDT) Received: (qmail 1303 invoked by uid 605); 9 Jul 2003 22:19:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1295 invoked from network); 9 Jul 2003 22:19:52 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 9 Jul 2003 22:19:52 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1670739; Wed, 09 Jul 2003 16:19:51 -0600 Message-ID: <3F0C9507.70805@vandyke.com> Date: Wed, 09 Jul 2003 16:19:51 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Peter Gutmann CC: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> In-Reply-To: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> 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 >Unfortunately this performance handbrake was reinvented in the SSHv2 protocol. >Like Ymodem-g and Zmodem running over modern modems, TCP/IP provides a >reliable, flow-controlled transport layer for the SSH protocol. SSHv2 however >introduced an additional form of flow control that, like Xmodem, requires the >receiver to Ack each packet before more can be sent (the details aren't quite >as straightforward as this since the SSHv2 specification describes things in >terms of packets and data windows, but effectively it's the Xmodem per-packet >Ack). Most implementations seem to use packet sizes of 16K or occasionally >32K, with some going as low as 4K. What this means is that no matter how fast >the link, every (say) 16K the transmission stops for 1 RTT until the other >side has sent its Ack (referred to as a window adjust in SSHv2 terminology). > The ack (a window adjust message) can be sent for any amount of data at any time. There is not one-to-one correspondane between adjust messages and packets. In addition, if the the window size is greater than the packet size, one could easily send acks in a timely fashion such that the remote side should never run out of window. I.e., if the max packet size on a channel is 16K, but the windows size is 128K, 8 packets must be sent before the window is exhausted and the sender must halt and wait for an adjust message. If the reciever sends adjust messages after receiving 32 K of data, additional window should become available to the sender before it exhausts its window, and no throttling should ever occur. >In addition to the protocol-level handbrake, the SFTP protocol that runs on >top of SSH contains its own handbrake. This protocol recommends that reads >and writes consist of no more than 32K of data, even though it's running over >the reliable SSH transport which is in turn running over the reliable TCP/IP >transport. One common implementation limits SFTP packets to 4K bytes, >resulting in a mere 4% link utilisation in the previously-presented scenario. > Because reads and writes do not have to be synchronous, this is only a 'hand-brake' if implementations choose to make it so. In other words, even if my writes must consist of no more than 32K packets, I need not wait for the status of that packet before sending the next. I'm free to send 32K packets out as fast as I can (limitted by the channel window, but as stated above, that shouldn't be an issue as long as the server can actually process the data as fast as I send it.) The results of those operations will then come back in their own due time. Similarly, I can send as many read requests, each for 32K, to the server as I want. The server should then process them, streaming data to me in 32K packets. If I give it another read request as soon as it completes one, it should be continually processing 32K read requests until the file is finished. Since the packet length must be determined before the packet can be sent, it might be burdensome for implementations to be required to read huge chunks of data and send it. What if I issue a read request for 4 gigabytes? Sure, I could send the packet header, claiming 4 gig of data and begin reading data out of the file in reasonable sized chunks and sending it down the wire. But what if the file is truncated to 2 gig after I've read and sent one gig of it? What if the file is on a server and that server fails after 2 gig have been read. They are corner cases, but if the protocol is incapable of handling such things, the protocol is flawed. However, in order to facilitate writing higher performing SFTP clients, I have considered that it might make sense to add a second read command to SFTP, which allowed reads of any size, but which can result in multiple data packets, culminating in a final status packet. I.E. Client: SSH_FXP_MULTI_READ: req-id=243, offset=0, bytes=4,000,0000 Server: SSH_FXP_DATA: req-id=243, 64K Server: SSH_FXP_DATA: req-id=243, 64K Server: SSH_FXP_DATA: req-id=243, 64K ... Server: SSH_FXP_DATA: req-id=243, 64K Server: SSH_FXP_STATUS: req-id=243, SUCCESS or Server: SSH_FXP_DATA: req-id=243, 64K Server: SSH_FXP_DATA: req-id=243, 64K Server: SSH_FXP_STATUS: req-id=243, EOF This would allow a client to request the entire file in a single read operation without requiring the server to allocate huge buffers or being vulnerable to corner cases (such as mid-read truncation.) >The fix for this problem is obvious: Remove the handbrake. This is no good >reason for the per-packet Ack, and certainly other protocols such as SSHv1 and >SSL/TLS function perfectly without it (the absence of the handbrake in SSHv1 >is why SSH FAQs observe that the SSHv1 scp is so much faster than the SSHv2 >SFTP, even though SFTP is overall a better design). > I believe others have noted that SSHv1's through-put is throttled by the slowest channel. Try the following with SSHv1: write a simple socket server that never reads the socket. Write a simple socket client that sends data. Connect the client to the server through a port forward. Eventually your entire connection will stall. You can no longer type at the shell prompt. Other port forwards no longer pass data. Any protocol which can transfer multiple streams of independant data has to have a per stream flow control mechanism. Otherwise, the entire protocol has to be stalled for the slowest stream. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jul 9 18:41: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 SAA27229 for ; Wed, 9 Jul 2003 18:41:46 -0400 (EDT) Received: (qmail 10562 invoked by uid 605); 9 Jul 2003 22:41:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10555 invoked from network); 9 Jul 2003 22:41:44 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 9 Jul 2003 22:41:44 -0000 Received: by xanthine.gratuitous.org with local; Wed, 09 Jul 2003 18:41:43 -0400 From: "Joel N. Weber II" To: Nicolas Williams cc: ietf-ssh@netbsd.org In-reply-to: (ietf-secsh@joelweber.com) Subject: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> Message-Id: Date: Wed, 09 Jul 2003 18:41:43 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list So, thinking a bit more about what I said yesterday, I think if we want to support multiple attempts at key exchange, the correct sematics are: If you fail trying to do GSSAPI key exchange, use the messages already defined for GSSAPI key exchange error reporting, but don't disconnect. If you send the last message in a key exchange sequence, wait to see if SSH_MSG_NEWKEYS comes. If it does, your peer accepted what you sent in that last message, and you can send SSH_MSG_NEWKEYS too. (This avoids having only one side use keys from a key exchange: you get either both or neither, which simplifies the session identifier question a bit.) If you need to try again, just send SSH_MSG_KEXINIT again. I'm willing to write up an internet-draft along these lines after IETF if people think it's a good idea. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jul 9 18:56: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 SAA27820 for ; Wed, 9 Jul 2003 18:56:37 -0400 (EDT) Received: (qmail 18201 invoked by uid 605); 9 Jul 2003 22:56:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18194 invoked from network); 9 Jul 2003 22:56:36 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 9 Jul 2003 22:56:36 -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 h69MuX1J000045; Wed, 9 Jul 2003 16:56:33 -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 h69MuWQf026568; Wed, 9 Jul 2003 16:56:32 -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 h69MrSQx001085; Wed, 9 Jul 2003 15:53:28 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h69MrRZx001084; Wed, 9 Jul 2003 15:53:27 -0700 (PDT) Date: Wed, 9 Jul 2003 15:53:27 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) Message-ID: <20030709225327.GN380@binky.central.sun.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Jul 09, 2003 at 06:41:43PM -0400, Joel N. Weber II wrote: > So, thinking a bit more about what I said yesterday, I think if we > want to support multiple attempts at key exchange, the correct > sematics are: > > If you fail trying to do GSSAPI key exchange, use the messages already > defined for GSSAPI key exchange error reporting, but don't disconnect. > > If you send the last message in a key exchange sequence, wait to see > if SSH_MSG_NEWKEYS comes. If it does, your peer accepted what you > sent in that last message, and you can send SSH_MSG_NEWKEYS too. > (This avoids having only one side use keys from a key exchange: you > get either both or neither, which simplifies the session identifier > question a bit.) If the client got an error from the peer then it knows that the SSH_MSG_NEWKEYS won't come and so it can just try again immediately. > If you need to try again, just send SSH_MSG_KEXINIT again. > > I'm willing to write up an internet-draft along these lines after IETF > if people think it's a good idea. There's a problem though, and I'm not sure how it could be surmounted: The session ID needs to be derived from all messages involved in the key exchange, even for the failed exechanges so as to avoid downgrade attacks. But the session ID computation is kex-type specific so you'd have to modify the formula for the session ID for each of the three(?) existing kex methods. This is most unfortunate. Perhaps the session ID computation should be respecified to be as follows: H = hash(V_C || V_S || KEX_C1 || KEX_S1 || KEX_C2 || KEX_S2 || ... || KEX_Cn || KEX_Sn || ) where KEX_Cx and KEX_Sx are the key exchange messages sent by the client and server, respectively and where is the (K_S || e || f || K) part of the existing kexes. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jul 9 20:12: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 UAA00323 for ; Wed, 9 Jul 2003 20:12:58 -0400 (EDT) Received: (qmail 19937 invoked by uid 605); 10 Jul 2003 00:12:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19930 invoked from network); 10 Jul 2003 00:12:53 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 10 Jul 2003 00:12:53 -0000 Received: by xanthine.gratuitous.org with local; Wed, 09 Jul 2003 20:12:52 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: ietf-ssh@netbsd.org In-reply-to: <20030709225327.GN380@binky.central.sun.com> (message from Nicolas Williams on Wed, 9 Jul 2003 15:53:27 -0700) Subject: Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> <20030709225327.GN380@binky.central.sun.com> Message-Id: Date: Wed, 09 Jul 2003 20:12:52 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list > > If you send the last message in a key exchange sequence, wait to see > > if SSH_MSG_NEWKEYS comes. If it does, your peer accepted what you > > sent in that last message, and you can send SSH_MSG_NEWKEYS too. > > (This avoids having only one side use keys from a key exchange: you > > get either both or neither, which simplifies the session identifier > > question a bit.) > > If the client got an error from the peer then it knows that the > SSH_MSG_NEWKEYS won't come and so it can just try again immediately. True. The case I was thinking of, though, is the case where the client decides it doesn't trust the certificate presented by the server, and that it wants to try another method. For example, a common problem is that your average web browser doesn't recognize the X.509 CA that issues certificates for most HTTPS web servers in the mit.edu domain. And with OpenPGP, everyone has their own set of trust values, and there's no chance you could ever predict whether a client will trust a host key without feeding the client the host key and asking whether it trusts it. Since the host key is sent in the last message of the public key key exchange algorithms, the client doesn't realize that it doesn't trust the key until key exchange would appear to have finished judging from the messages being passed back and forth. > > If you need to try again, just send SSH_MSG_KEXINIT again. > > > > I'm willing to write up an internet-draft along these lines after IETF > > if people think it's a good idea. > > There's a problem though, and I'm not sure how it could be surmounted: > > The session ID needs to be derived from all messages involved in the key > exchange, even for the failed exechanges so as to avoid downgrade > attacks. You're right; it makes perfect sense, but I hadn't realized that. (Tangentially, if an attacker can intercept the messages between your application server and your Kerberos KDC, there is probably a downgrade attack there, unless your GSSAPI implementation is really clever. We may want to say that a GSSAPI implementation MUST abort if an error happens which indicates that communication with the KDC failed. Except that, like, KDC isn't a GSSAPI term.) > But the session ID computation is kex-type specific so you'd have to > modify the formula for the session ID for each of the three(?) existing > kex methods. Every kex method, I believe, has a V_C and a V_S input for data that needs to be in the hash that came before the key exchange algorithm started running. I think all we have to do is define that for the first attempt at initial keyex, and for any rekeying (yes, ugh about the ``for any rekeying, but that's where we are now), they are what they are now, and for attempts at initial keyex after the first, V_C and V_S somehow end up being a hash of initial V_C and V_S plus the previous attempts at keyex. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jul 9 20:22: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 UAA00527 for ; Wed, 9 Jul 2003 20:22:16 -0400 (EDT) Received: (qmail 24939 invoked by uid 605); 10 Jul 2003 00:22:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24926 invoked from network); 10 Jul 2003 00:22:13 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 10 Jul 2003 00:22:13 -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 h6A0MBBq016426; Wed, 9 Jul 2003 17:22:11 -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 h6A0MAQf022511; Wed, 9 Jul 2003 18:22:11 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6A0J6Qx001150; Wed, 9 Jul 2003 17:19:06 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6A0J6w5001149; Wed, 9 Jul 2003 17:19:06 -0700 (PDT) Date: Wed, 9 Jul 2003 17:19:06 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@netbsd.org Subject: Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) Message-ID: <20030710001906.GQ380@binky.central.sun.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> <20030709225327.GN380@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Jul 09, 2003 at 08:12:52PM -0400, Joel N. Weber II wrote: > > > If you need to try again, just send SSH_MSG_KEXINIT again. > > > > > > I'm willing to write up an internet-draft along these lines after IETF > > > if people think it's a good idea. > > > > There's a problem though, and I'm not sure how it could be surmounted: > > > > The session ID needs to be derived from all messages involved in the key > > exchange, even for the failed exechanges so as to avoid downgrade > > attacks. > > You're right; it makes perfect sense, but I hadn't realized that. > > (Tangentially, if an attacker can intercept the messages between your > application server and your Kerberos KDC, there is probably a > downgrade attack there, unless your GSSAPI implementation is really > clever. We may want to say that a GSSAPI implementation MUST abort if > an error happens which indicates that communication with the KDC > failed. Except that, like, KDC isn't a GSSAPI term.) Well, no. While what you say about Kerberos is true, the client would fail to acquire GSS-API credentials in such cases and so would not even propose gsskeyex. (Incidentally, that is one problem that we'll try to address with the Kerberos extensions work.) > > But the session ID computation is kex-type specific so you'd have to > > modify the formula for the session ID for each of the three(?) existing > > kex methods. > > Every kex method, I believe, has a V_C and a V_S input for data that > needs to be in the hash that came before the key exchange algorithm > started running. I think all we have to do is define that for the > first attempt at initial keyex, and for any rekeying (yes, ugh about > the ``for any rekeying, but that's where we are now), they are what > they are now, and for attempts at initial keyex after the first, V_C > and V_S somehow end up being a hash of initial V_C and V_S plus the > previous attempts at keyex. The problem is that we're talking about modifying existing kex methods that are defined in multiple different documents; although we're modifying them to take into account a mode of operation not currently available, we would be partially obsoleting these docs, and in terms of IETF process I think that'll mean re-spinning the RFCs (don't even think of getting this into the I-Ds now - or, rather, you can try, but I think you'll be told by all that it's too late). Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jul 10 12:48: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 MAA11711 for ; Thu, 10 Jul 2003 12:48:47 -0400 (EDT) Received: (qmail 15284 invoked by uid 605); 10 Jul 2003 16:48:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15277 invoked from network); 10 Jul 2003 16:48:45 -0000 Received: from softdnserror (HELO hermes.cs.auckland.ac.nz) (130.216.35.151) by mail.netbsd.org with SMTP; 10 Jul 2003 16:48:45 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6AGlcYM020462; Fri, 11 Jul 2003 04:47:38 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6AGlc318909; Fri, 11 Jul 2003 04:47:38 +1200 Date: Fri, 11 Jul 2003 04:47:38 +1200 Message-Id: <200307101647.h6AGlc318909@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: mbp@samba.org, pgut001@cs.auckland.ac.nz Subject: Re: Why SFTP performance sucks, and how to fix it Cc: ietf-ssh@netbsd.org Sender: ietf-ssh-owner@netbsd.org Precedence: list Martin Pool writes: >On 8 Jul 2003, Peter Gutmann wrote: >>Another thing to keep in mind here is that if you signal a read/write of the >>entire file at once, the receiver knows how much disk space it needs and can >>lock the space before starting the receive > >I don't know of a means for a Unix or Windows server to "lock" disk space in >that way. I suppose the server might zero-fill the blocks between getting >the start of the request and reading the bulk of it, but that seems highly >contrived. It's going to be system-specific, but is available on many systems. For example under Windows you can do something called "ghost locking" (which dates back to early MSDOS days, it may have other names but that's what I heard database developers call it) where you seek past the end of file and drop some bytes there, which locks that amount of disk space. The DOS-compatibility may be why under Windows you have to explicitly ask for sparse files, and they can only exist under NTFS5 (if you copy one of these things to a non-NTFS5 volume, it expands out to its full size). Various Unix systems can do this too (either with a simple lseek or with an lssek and write), or have some equivalent way to do it, even if it means shelling out to mkfile to do the job. In any event you don't *have* to do this, but if I'm copying a large amount of data to an OS that can easily do the check and it doesn't, and then fails halfway through the transfer, I won't be too happy with the software (or its author :-). Same with other user-friendliness options, if the client and server can exchange hints at the start and the server can tell me in advance of problems, I'll be a lot happier than having it fail at the end of a 500MB transfer. >Here's another example, taken from experience with Samba: if you're going to >send chunks of 2GB at a time they presumably have to be "streamed" from disk >and not built in a temporary buffer. Hmm, I think you're confusing window size and packet size. In my tests I sent multimegabyte files with an infinite window size (to get rid of all the Acks == window adjusts), but used 8K packets built up on the fly. No need to buffer any more than you want to. The transmission model I'm proposing is exactly what's used in Zmodem (since I'm using old modem-transfer protocols as analogies), whose flow control is "Keep sending data until I cry uncle". In other words when everything is going fine (as it is most of the time), you transfer data at the maximum rate the link can take. If there's a problem, you can stop on a dime. This gives you maximum transfer rate *and* the same control as minimum-size windows with vast numbers of Acks sent. >I suspect that sending a block-at-a-time can give good performance if you >choose a good block size and pipeline transmissions, and if problems with the >underlying transport are addressed. This has historically been *very* hard to get right. Look at the infinite number of enhanced-flow-control protocols that followed after the X/Y/Zmodems, all with their own weird quirks and all of which were extremely difficult to write compatible (and high-performance) implementations for because they required extensive tuning to get them going just right, and no two implementors could agree on how to do it, which resulted in either poor performance or non-interoperability. You can certainly think up ways to make it go well in theory, but long experience has shown that it's extremely difficult to reduce into practice. OTOH the "Keep sending data until I cry uncle" model is pretty trivial to get right (I'm actually tempted to hack OpenSSH for this just to get the 4-5x faster transmission to one server I use in the US - sorry guys :-), and the model has been heavily tested in Zmodem over many years and found to be very workable (I hacked it together in no time at all for an SFTP implementation that could politely be described as "embarrasingly crude"). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jul 10 13:04: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 NAA12504 for ; Thu, 10 Jul 2003 13:04:13 -0400 (EDT) Received: (qmail 23791 invoked by uid 605); 10 Jul 2003 17:04:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23784 invoked from network); 10 Jul 2003 17:04:13 -0000 Received: from softdnserror (HELO hermes.cs.auckland.ac.nz) (130.216.35.151) by mail.netbsd.org with SMTP; 10 Jul 2003 17:04:13 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6AH1UYM020651; Fri, 11 Jul 2003 05:01:30 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6AH1Vn19012; Fri, 11 Jul 2003 05:01:31 +1200 Date: Fri, 11 Jul 2003 05:01:31 +1200 Message-Id: <200307101701.h6AH1Vn19012@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: markus@openbsd.org, pgut001@cs.auckland.ac.nz Subject: Re: Why SFTP performance sucks, and how to fix it Cc: ietf-ssh@netbsd.org Sender: ietf-ssh-owner@netbsd.org Precedence: list Markus Friedl writes: >when multiplexing multiple ssh channels over one connection and one of the >consumers is very slow, then the tcp flow control will not help. AFAIK, this >is one of the reasons why there's an additional per-channel flowcontrol. Ahh, that makes sense. Thanks. Still, it just shows that there are different situations where the Ack-based flow control is appropriate, since the converse says that when not muxing multiple channels, TCP flow control should do. Specifically, if I'm using SFTP as just a secure FTP (without anything fancy like SSH port forwarding, just a dumb copy), it's just an updated form of rcp/scp: Open a connection, blast data across as quickly as possible, close the connection, either with a successful close or an unsuccessful disconnect on error, just as rcp does. All I want at that point is the fastest possible transfer, if there's a flow-control problem TCP flow control will handle it, and if there's a fatal error then all you can do is close the session, just like standard rcp. Since it's situation-specific, software could either enable it when there's no need for Ack-based flow control (e.g. the example I gave above), or when requested by users. As a command-line option, I think -u (for "ludicrous speed") would be the only viable candiate (-l is taken, and so is -p for "plaid"). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jul 10 13:23: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 NAA13114 for ; Thu, 10 Jul 2003 13:22:59 -0400 (EDT) Received: (qmail 3550 invoked by uid 605); 10 Jul 2003 17:22:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3543 invoked from network); 10 Jul 2003 17:22:56 -0000 Received: from softdnserror (HELO hermes.cs.auckland.ac.nz) (130.216.35.151) by mail.netbsd.org with SMTP; 10 Jul 2003 17:22:56 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6AHKNYM021024; Fri, 11 Jul 2003 05:20:23 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6AHKMm19060; Fri, 11 Jul 2003 05:20:22 +1200 Date: Fri, 11 Jul 2003 05:20:22 +1200 Message-Id: <200307101720.h6AHKMm19060@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@denisbider.com, ietf-ssh@netbsd.org, pgut001@cs.auckland.ac.nz Subject: RE: Why SFTP performance sucks, and how to fix it Sender: ietf-ssh-owner@netbsd.org Precedence: list "denis bider" writes: >I totally agree that the SSH protocol in some places is more complicated than >it needs to be; however, the protocol does not impede performance if properly >implemented. That's the magic phrase: "If properly implemented". The problem is that the current design makes it extremely tricky to get good performance, borne out by the fact that after five(?) years of existence of the spec and work on the code, there are a large number of handbrake-enabled implementations around with poor performance that is often noticeable enough for it to be an FAQ. >The protocol provides you with the means to control the flow of the session, >but it doesn't tell you how to do it efficiently. If you want to resolve >this, the solution is to write a document describing how to use the control >elements for best performance; not to remove them altogether. The protocol is >fine. I disagree, again based on the modem-protocol experience. You can make it simple and straightforward, with good performance, and get good interoperability (Zmodem) or make it really hard to get right, get OK performance if you can manage to tune it sufficiently, and get poor interoperability because no-one can quite get it right (most of Zmodem's successors). The fact that I did a truly ghastly (but high-performance) SFTP implementation in a few hours that outperformed ones that have had years of ongoing development indicates that waiting for people to tune something that is inherently difficult to get good performance out of isn't a viable option. (Before people start reaching for cream pies: The point I'm trying to make there isn't to bash other people's software (my experimental code is definitely far worse than anything else out there), but to say that the current flow-control model is inherently difficult to get good performance out of, a claim that would seem to be strongly supported by the performance of various existing implementations). Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jul 10 15:56: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 PAA19355 for ; Thu, 10 Jul 2003 15:56:36 -0400 (EDT) Received: (qmail 19681 invoked by uid 605); 10 Jul 2003 19:56:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19674 invoked from network); 10 Jul 2003 19:56:27 -0000 Received: from mail-in-01.arcor-online.net (151.189.21.41) by mail.netbsd.org with SMTP; 10 Jul 2003 19:56:27 -0000 Received: from localhost.arcor.net (dsl-213-023-027-198.arcor-ip.net [213.23.27.198]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id A9E2F21BD8; Thu, 10 Jul 2003 21:56:22 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id B71E72D041; Thu, 10 Jul 2003 21:57:05 +0200 (CEST) Date: Thu, 10 Jul 2003 21:57:05 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030710195705.GA32654@folly> References: <200307101701.h6AH1Vn19012@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307101701.h6AH1Vn19012@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Jul 11, 2003 at 05:01:31AM +1200, Peter Gutmann wrote: > Markus Friedl writes: > > >when multiplexing multiple ssh channels over one connection and one of the > >consumers is very slow, then the tcp flow control will not help. AFAIK, this > >is one of the reasons why there's an additional per-channel flowcontrol. > > Ahh, that makes sense. Thanks. Still, it just shows that there are different > situations where the Ack-based flow control is appropriate, since the converse > says that when not muxing multiple channels, TCP flow control should do. > Specifically, if I'm using SFTP as just a secure FTP (without anything fancy > like SSH port forwarding, just a dumb copy), it's just an updated form of > rcp/scp: Open a connection, blast data across as quickly as possible, close > the connection, either with a successful close or an unsuccessful disconnect > on error, just as rcp does. All I want at that point is the fastest possible > transfer, if there's a flow-control problem TCP flow control will handle it, > and if there's a fatal error then all you can do is close the session, just > like standard rcp. But then all you need to do is to announce a big window size. E.g. the client can announce big window sizes if no pty allocation is involved. Recent OpenSSH's do this. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jul 10 16:03: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 QAA19621 for ; Thu, 10 Jul 2003 16:03:57 -0400 (EDT) Received: (qmail 24695 invoked by uid 605); 10 Jul 2003 20:03:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24686 invoked from network); 10 Jul 2003 20:03:55 -0000 Received: from mail-in-04.arcor-online.net (151.189.21.44) by mail.netbsd.org with SMTP; 10 Jul 2003 20:03:55 -0000 Received: from localhost.arcor.net (dsl-213-023-027-198.arcor-ip.net [213.23.27.198]) by mail-in-04.arcor-online.net (Postfix) with ESMTP id 933E81E699; Thu, 10 Jul 2003 22:03:53 +0200 (CEST) Received: by localhost.arcor.net (Postfix, from userid 31451) id DD8D22D041; Thu, 10 Jul 2003 22:04:36 +0200 (CEST) Date: Thu, 10 Jul 2003 22:04:36 +0200 From: Markus Friedl To: Peter Gutmann Cc: ietf-ssh@denisbider.com, ietf-ssh@netbsd.org Subject: Re: Why SFTP performance sucks, and how to fix it Message-ID: <20030710200436.GB32654@folly> References: <200307101720.h6AHKMm19060@medusa01.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307101720.h6AHKMm19060@medusa01.cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Jul 11, 2003 at 05:20:22AM +1200, Peter Gutmann wrote: > (Before people start reaching for cream pies: The point I'm trying to make > there isn't to bash other people's software (my experimental code is > definitely far worse than anything else out there), but to say that the > current flow-control model is inherently difficult to get good performance > out of, a claim that would seem to be strongly supported by the performance > of various existing implementations). But for SFTP it's due to the fact that the early implementations used to send only one request at a time. E.g., when sending multiple 'read' requests, I see not much different in performance between scp and sftp (For a window size that's only 4 times the packet size). -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 14 12:37:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02938 for ; Mon, 14 Jul 2003 12:37:03 -0400 (EDT) Received: (qmail 993 invoked by uid 605); 14 Jul 2003 16:10:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16821 invoked from network); 14 Jul 2003 15:53:01 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 14 Jul 2003 15:53:01 -0000 Received: by xanthine.gratuitous.org with local; Mon, 14 Jul 2003 11:52:52 -0400 From: "Joel N. Weber II" To: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-gsskeyex-06.txt security considerations Message-Id: Date: Mon, 14 Jul 2003 11:52:52 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'd like to propose adding the following text to draft-ietf-secsh-gsskeyex-06.txt after the end of the paragraph in the security considerations section that starts with ``The key exchange method described in section 1'': However, the security of the key exchange does not require that the GSSAPI mechanism provide any replay detection. I also notice that the key exchange mechanism is actually discussed in section 2 and not section 1. And it seems somewhat asymetrical that security considerations talks about the required properties of a GSSAPI mechanism used for key exchange, but says nothing about user authentication. However, it also might be cleaner, if some security considerations are sprinkled throughout the document, to move all security considerations to the body of the document. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 14 21:44:16 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17382 for ; Mon, 14 Jul 2003 21:44:16 -0400 (EDT) Received: (qmail 13133 invoked by uid 605); 15 Jul 2003 01:44:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13126 invoked from network); 15 Jul 2003 01:44:15 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 Jul 2003 01:44:15 -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 h6F1iD2a010407; Mon, 14 Jul 2003 18:44: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 h6F1iCQf000134; Mon, 14 Jul 2003 19:44: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 h6F1f4Qx004096; Mon, 14 Jul 2003 18:41:04 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6F1f3PK004095; Mon, 14 Jul 2003 18:41:03 -0700 (PDT) Date: Mon, 14 Jul 2003 18:41:03 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gsskeyex-06.txt security considerations Message-ID: <20030714184059.A3998@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 Mon, Jul 14, 2003 at 11:52:52AM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jul 14, 2003 at 11:52:52AM -0400, Joel N. Weber II wrote: > I'd like to propose adding the following text to > draft-ietf-secsh-gsskeyex-06.txt after the end of the paragraph in the > security considerations section that starts with ``The key exchange > method described in section 1'': > > However, the security of the key exchange does not require that the > GSSAPI mechanism provide any replay detection. > > I also notice that the key exchange mechanism is actually discussed in > section 2 and not section 1. > > And it seems somewhat asymetrical that security considerations talks > about the required properties of a GSSAPI mechanism used for key > exchange, but says nothing about user authentication. As with the lack of reference to replay [and out-of-sequence] detection, the text you requests is likely absent because none is needed. In the case of replay detection it is not needed since one and not more than one non-context token GSS-API message token is to be exchanged! In the case of GSS-API userauth, per-message integrity services are not needed because no non-context GSS-API tokens are exchanged! This leaves the use of mutual authentication during GSS-API userauth as an interesting case. Since the server is authenticated during the key exchange phase of the protocol mutual authentication during the userauth phase of the protocol is not needed - it neither helps security nor hurts it in this particular case. Perhaps the fact that and reasons why GSS-API replay and out-of-sequence detection are not needed at all here and why GSS-API mutual authentication and per-message integrity services are not needed in the userauth case ought to be stated. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 01:16:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04696 for ; Tue, 15 Jul 2003 01:16:09 -0400 (EDT) Received: (qmail 28610 invoked by uid 605); 15 Jul 2003 05:16:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28602 invoked from network); 15 Jul 2003 05:16:02 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 15 Jul 2003 05:16:02 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6F5FVeR026484; Mon, 14 Jul 2003 22:15:31 -0700 (PDT) Received: from islay (vpn-129-150-17-202.SFBay.Sun.COM [129.150.17.202]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6F5FTtf189004; Mon, 14 Jul 2003 22:15:29 -0700 (PDT) Date: Mon, 14 Jul 2003 22:15:51 -0700 (PDT) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-assignednumbers-03.txt Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1903590565-1058246151=:895" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1903590565-1058246151=:895 Content-Type: TEXT/PLAIN; charset=US-ASCII -- Darren J Moffat ---559023410-1903590565-1058246151=:895 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-ietf-secsh-assignednumbers-03.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-ietf-secsh-assignednumbers-03.txt" Content-Transfer-Encoding: BASE64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBTLiBMZWh0aW5lbg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgIFNTSCBDb21tdW5pY2F0aW9u cyBTZWN1cml0eSBDb3JwDQpFeHBpcmVzOiBKYW51YXJ5IDEyLCAyMDA0ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBELiBNb2ZmYXQN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgU3VuIE1pY3Jvc3lzdGVtcw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBK dWx5IDE0LCAyMDAzDQoNCg0KICAgICAgICAgICAgICAgICAgICAgU1NIIFBy b3RvY29sIEFzc2lnbmVkIE51bWJlcnMNCiAgICAgICAgICAgICAgICBkcmFm dC1pZXRmLXNlY3NoLWFzc2lnbmVkbnVtYmVycy0wMy50eHQNCg0KU3RhdHVz IG9mIHRoaXMgTWVtbw0KDQogICAgICBUaGlzIGRvY3VtZW50IGlzIGFuIElu dGVybmV0LURyYWZ0IGFuZCBpcyBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGgN CiAgICAgIGFsbCBwcm92aXNpb25zIG9mIFNlY3Rpb24gMTAgb2YgUkZDMjAy Ni4NCg0KICAgICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgICAgIFRhc2sg Rm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91 cHMuICBOb3RlIHRoYXQNCiAgICAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBk aXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQ0KICAg ICAgRHJhZnRzLg0KDQogICAgICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0 IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeA0KICAgICAg bW9udGhzIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29s ZXRlZCBieSBvdGhlcg0KICAgICAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiAg SXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzDQog ICAgICBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90 aGVyIHRoYW4gYXMgIndvcmsgaW4NCiAgICAgIHByb2dyZXNzLiINCg0KICAg ICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJl IGFjY2Vzc2VkIGF0DQogICAgICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYv MWlkLWFic3RyYWN0cy50eHQuDQoNCiAgICAgIFRoZSBsaXN0IG9mIEludGVy bmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQg YXQNCiAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoN CiAgICAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSmFu dWFyeSAxMiwgMjAwNC4NCg0KQ29weXJpZ2h0IE5vdGljZQ0KDQogICAgICBD b3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDAzKS4gIEFs bCBSaWdodHMgUmVzZXJ2ZWQuDQoNCkFic3RyYWN0DQoNCiAgICAgIFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyB0aGUgaW5pdGlhbCBzdGF0ZSBvZiB0aGUgSUFO QSBhc3NpZ25lZA0KICAgICAgbnVtYmVycyBmb3IgdGhlIFNTSCBwcm90b2Nv bCBhcyBkZWZpbmVkIGluIFtTU0gtQVJDSF0sIFtTU0gtDQogICAgICBUUkFO U10sIFtTU0gtQ09OTkVDVF0sIFtTU0gtVVNFUkFVVEhdLiAgVGhpcyBkb2N1 bWVudCBkb2VzIG5vdA0KICAgICAgZGVmaW5lIGFueSBuZXcgcHJvdG9jb2xz IG9yIGFueSBudW1iZXIgcmFuZ2VzIG5vdCBhbHJlYWR5IGRlZmluZWQNCiAg ICAgIGluIHRoZSBhYm92ZSByZWZlcmVuY2VkIGRvY3VtZW50cy4gIEl0IGlz IGludGVuZGVkIG9ubHkgZm9yDQogICAgICBpbml0YWxpemF0aW9uIG9mIHRo ZSBJQU5BIGRhdGFiYXNlcyByZWZlcmVuY2VkIGluIHRob3NlIGRvY3VtZW50 cy4NCg0KDQoNCg0KDQoNCkxlaHRpbmVuICYgTW9mZmF0ICAgICAgIEV4cGly ZXMgSmFudWFyeSAxMiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxXQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFNTSCBQcm90b2NvbCBBc3NpZ25l ZCBOdW1iZXJzICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KVGFibGUgb2Yg Q29udGVudHMNCg0KICAgMS4gICAgTWVzc2FnZSBOdW1iZXJzICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAx LjEgICBEaXNjb25uZWN0IENvZGVzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDIuICAgIFNlcnZpY2UgTmFt ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgNQ0KICAgMi4xICAgQXV0aGVudGljYXRpb24gTWV0aG9kIE5hbWVz ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA1DQogICAyLjIg ICBDb25uZWN0aW9uIFByb3RvY29sIEFzc2lnbmVkIE5hbWVzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgIDIuMi4xIENvbm5lY3Rpb24gUHJv dG9jb2wgQ2hhbm5lbCBUeXBlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNg0KICAgMi4yLjIgQ29ubmVjdGlvbiBQcm90b2NvbCBHbG9iYWwgUmVx dWVzdCBOYW1lcyAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAyLjIuMyBD b25uZWN0aW9uIFByb3RvY29sIENoYW5uZWwgUmVxdWVzdCBOYW1lcyAgLiAu IC4gLiAuIC4gLiAuIC4gIDYNCiAgIDMuICAgIEtleSBFeGNoYW5nZSBNZXRo b2QgTmFtZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg Nw0KICAgNC4gICAgQXNzaWduZWQgQWxnb3JpdGhtIE5hbWVzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICA0LjEgICBFbmNy eXB0aW9uIEFsZ29yaXRobSBOYW1lcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDcNCiAgIDQuMiAgIE1BQyBBbGdvcml0aG0gTmFtZXMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0K ICAgNC4zICAgUHVibGljIEtleSBBbGdvcml0aG0gTmFtZXMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgICAgICBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gIDgNCiAgICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAg ICAgICAgRnVsbCBDb3B5cmlnaHQgU3RhdGVtZW50IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEwDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpMZWh0aW5lbiAmIE1vZmZhdCAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIs IDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICBTU0ggUHJvdG9jb2wgQXNzaWduZWQgTnVtYmVycyAgICAg ICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgIDEuIE1lc3NhZ2UgTnVtYmVycw0K DQogICAgICBUaGUgTWVzc2FnZSBOdW1iZXIgaXMgYW4gOC1iaXQgdmFsdWUs IHdoaWNoIGRlc2NyaWJlcyB0aGUgcGF5bG9hZA0KICAgICAgb2YgYSBwYWNr ZXQuDQoNCiAgICAgIFByb3RvY29sIHBhY2tldHMgaGF2ZSBtZXNzYWdlIG51 bWJlcnMgaW4gdGhlIHJhbmdlIDEgdG8gMjU1Lg0KICAgICAgVGhlc2UgbnVt YmVycyBoYXZlIGJlZW4gYWxsb2NhdGVkIGFzIGZvbGxvd3MgaW4gW1NTSC1B UkNIXToNCg0KICAgICBUcmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2w6DQoNCiAg ICAgICAxIHRvIDE5ICAgIFRyYW5zcG9ydCBsYXllciBnZW5lcmljIChlLmcu IGRpc2Nvbm5lY3QsIGlnbm9yZSwgZGVidWcsIGV0Yy4pDQogICAgICAgMjAg dG8gMjkgICBBbGdvcml0aG0gbmVnb3RpYXRpb24NCiAgICAgICAzMCB0byA0 OSAgIEtleSBleGNoYW5nZSBtZXRob2Qgc3BlY2lmaWMgKG51bWJlcnMgY2Fu IGJlIHJldXNlZCBmb3INCiAgICAgICAgICAgICAgICAgIGRpZmZlcmVudCBh dXRoZW50aWNhdGlvbiBtZXRob2RzKQ0KDQogICAgIFVzZXIgYXV0aGVudGlj YXRpb24gcHJvdG9jb2w6DQoNCiAgICAgICA1MCB0byA1OSAgIFVzZXIgYXV0 aGVudGljYXRpb24gZ2VuZXJpYw0KICAgICAgIDYwIHRvIDc5ICAgVXNlciBh dXRoZW50aWNhdGlvbiBtZXRob2Qgc3BlY2lmaWMgKG51bWJlcnMgY2FuIGJl DQogICAgICAgICAgICAgICAgICByZXVzZWQgZm9yIGRpZmZlcmVudCBhdXRo ZW50aWNhdGlvbiBtZXRob2RzKQ0KDQogICAgIENvbm5lY3Rpb24gcHJvdG9j b2w6DQoNCiAgICAgICA4MCB0byA4OSAgIENvbm5lY3Rpb24gcHJvdG9jb2wg Z2VuZXJpYw0KICAgICAgIDkwIHRvIDEyNyAgQ2hhbm5lbCByZWxhdGVkIG1l c3NhZ2VzDQoNCiAgICAgUmVzZXJ2ZWQgZm9yIGNsaWVudCBwcm90b2NvbHM6 DQoNCiAgICAgICAxMjggdG8gMTkxIFJlc2VydmVkDQoNCiAgICAgTG9jYWwg ZXh0ZW5zaW9uczoNCg0KICAgICAgIDE5MiB0byAyNTUgTG9jYWwgZXh0ZW5z aW9ucw0KDQoNCiAgICAgIFJlcXVlc3RzIGZvciBhc3NpZ25tZW50cyBvZiBu ZXcgbWVzc2FnZSBudW1iZXJzIG11c3QgYmUNCiAgICAgIGFjY29tcGFuaWVk IGJ5IGFuIFJGQyB3aGljaCBkZXNjcmliZXMgdGhlIG5ldyBwYWNrZXQgdHlw ZS4gIElmIHRoZQ0KICAgICAgUkZDIGlzIG5vdCBvbiB0aGUgc3RhbmRhcmRz LXRyYWNrIChpLmUuICBpdCBpcyBhbiBpbmZvcm1hdGlvbmFsIG9yDQogICAg ICBleHBlcmltZW50YWwgUkZDKSwgaXQgbXVzdCBiZSBleHBsaWNpdGx5IHJl dmlld2VkIGFuZCBhcHByb3ZlZCBieQ0KICAgICAgdGhlIElFU0cgYmVmb3Jl IHRoZSBSRkMgaXMgcHVibGlzaGVkIGFuZCB0aGUgbWVzc2FnZSBudW1iZXIg aXMNCiAgICAgIGFzc2lnbmVkLg0KDQogICBNZXNzYWdlIElEICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFZhbHVlICAgIFJlZmVyZW5jZQ0KICAgLS0t LS0tLS0tLS0gICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0tLSAgICAt LS0tLS0tLS0NCiAgIFNTSF9NU0dfRElTQ09OTkVDVCAgICAgICAgICAgICAg ICAgICAgICAgMSAgICAgW1NTSC1UUkFOU10NCiAgIFNTSF9NU0dfSUdOT1JF ICAgICAgICAgICAgICAgICAgICAgICAgICAgMiAgICAgW1NTSC1UUkFOU10N CiAgIFNTSF9NU0dfVU5JTVBMRU1FTlRFRCAgICAgICAgICAgICAgICAgICAg MyAgICAgW1NTSC1UUkFOU10NCiAgIFNTSF9NU0dfREVCVUcgICAgICAgICAg ICAgICAgICAgICAgICAgICAgNCAgICAgW1NTSC1UUkFOU10NCg0KDQoNCkxl aHRpbmVuICYgTW9mZmF0ICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAw NCAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgIFNTSCBQcm90b2NvbCBBc3NpZ25lZCBOdW1iZXJzICAgICAgICAg ICAgSnVseSAyMDAzDQoNCg0KICAgU1NIX01TR19TRVJWSUNFX1JFUVVFU1Qg ICAgICAgICAgICAgICAgICA1ICAgICBbU1NILVRSQU5TXQ0KICAgU1NIX01T R19TRVJWSUNFX0FDQ0VQVCAgICAgICAgICAgICAgICAgICA2ICAgICBbU1NI LVRSQU5TXQ0KICAgU1NIX01TR19LRVhJTklUICAgICAgICAgICAgICAgICAg ICAgICAgIDIwICAgICBbU1NILVRSQU5TXQ0KICAgU1NIX01TR19ORVdLRVlT ICAgICAgICAgICAgICAgICAgICAgICAgIDIxICAgICBbU1NILVRSQU5TXQ0K ICAgU1NIX01TR19LRVhESF9JTklUICAgICAgICAgICAgICAgICAgICAgIDMw ICAgICBbU1NILVRSQU5TXQ0KICAgU1NIX01TR19LRVhESF9SRVBMWSAgICAg ICAgICAgICAgICAgICAgIDMxICAgICBbU1NILVRSQU5TXQ0KICAgU1NIX01T R19VU0VSQVVUSF9SRVFVRVNUICAgICAgICAgICAgICAgIDUwICAgICBbU1NI LVVTRVJBVVRIXQ0KICAgU1NIX01TR19VU0VSQVVUSF9GQUlMVVJFICAgICAg ICAgICAgICAgIDUxICAgICBbU1NILVVTRVJBVVRIXQ0KICAgU1NIX01TR19V U0VSQVVUSF9TVUNDRVNTICAgICAgICAgICAgICAgIDUyICAgICBbU1NILVVT RVJBVVRIXQ0KICAgU1NIX01TR19VU0VSQVVUSF9CQU5ORVIgICAgICAgICAg ICAgICAgIDUzICAgICBbU1NILVVTRVJBVVRIXQ0KICAgU1NIX01TR19VU0VS QVVUSF9QS19PSyAgICAgICAgICAgICAgICAgIDYwICAgICBbU1NILVVTRVJB VVRIXQ0KICAgU1NIX01TR19HTE9CQUxfUkVRVUVTVCAgICAgICAgICAgICAg ICAgIDgwICAgICBbU1NILUNPTk5FQ1RdDQogICBTU0hfTVNHX1JFUVVFU1Rf U1VDQ0VTUyAgICAgICAgICAgICAgICAgODEgICAgIFtTU0gtQ09OTkVDVF0N CiAgIFNTSF9NU0dfUkVRVUVTVF9GQUlMVVJFICAgICAgICAgICAgICAgICA4 MiAgICAgW1NTSC1DT05ORUNUXQ0KICAgU1NIX01TR19DSEFOTkVMX09QRU4g ICAgICAgICAgICAgICAgICAgIDkwICAgICBbU1NILUNPTk5FQ1RdDQogICBT U0hfTVNHX0NIQU5ORUxfT1BFTl9DT05GSVJNQVRJT04gICAgICAgOTEgICAg IFtTU0gtQ09OTkVDVF0NCiAgIFNTSF9NU0dfQ0hBTk5FTF9PUEVOX0ZBSUxV UkUgICAgICAgICAgICA5MiAgICAgW1NTSC1DT05ORUNUXQ0KICAgU1NIX01T R19DSEFOTkVMX1dJTkRPV19BREpVU1QgICAgICAgICAgIDkzICAgICBbU1NI LUNPTk5FQ1RdDQogICBTU0hfTVNHX0NIQU5ORUxfREFUQSAgICAgICAgICAg ICAgICAgICAgOTQgICAgIFtTU0gtQ09OTkVDVF0NCiAgIFNTSF9NU0dfQ0hB Tk5FTF9FWFRFTkRFRF9EQVRBICAgICAgICAgICA5NSAgICAgW1NTSC1DT05O RUNUXQ0KICAgU1NIX01TR19DSEFOTkVMX0VPRiAgICAgICAgICAgICAgICAg ICAgIDk2ICAgICBbU1NILUNPTk5FQ1RdDQogICBTU0hfTVNHX0NIQU5ORUxf Q0xPU0UgICAgICAgICAgICAgICAgICAgOTcgICAgIFtTU0gtQ09OTkVDVF0N CiAgIFNTSF9NU0dfQ0hBTk5FTF9SRVFVRVNUICAgICAgICAgICAgICAgICA5 OCAgICAgW1NTSC1DT05ORUNUXQ0KICAgU1NIX01TR19DSEFOTkVMX1NVQ0NF U1MgICAgICAgICAgICAgICAgIDk5ICAgICBbU1NILUNPTk5FQ1RdDQogICBT U0hfTVNHX0NIQU5ORUxfRkFJTFVSRSAgICAgICAgICAgICAgICAxMDAgICAg IFtTU0gtQ09OTkVDVF0NCg0KDQogICAxLjEgRGlzY29ubmVjdCBDb2Rlcw0K DQogICAgICBUaGUgRGlzY29ubmVjdCBjb2RlIGlzIGFuIDgtYml0IHZhbHVl LCB3aGljaCBkZXNjcmliZXMgdGhlDQogICAgICBkaXNjb25uZWN0IHJlYXNv bi4gIFJlcXVlc3RzIGZvciBhc3NpZ25tZW50cyBvZiBuZXcgZGlzY29ubmVj dA0KICAgICAgY29kZXMgbXVzdCBiZSBhY2NvbXBhbmllZCBieSBhbiBSRkMg d2hpY2ggZGVzY3JpYmVzIHRoZSBuZXcNCiAgICAgIGRpc2Nvbm5lY3QgcmVh c29uIGNvZGUuDQoNCg0KICAgRGlzY29ubmVjdCBjb2RlICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgVmFsdWUgIFJlZmVyZW5jZQ0KICAgLS0t LS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg LS0tLS0gIC0tLS0tLS0tLQ0KICAgU1NIX0RJU0NPTk5FQ1RfSE9TVF9OT1Rf QUxMT1dFRF9UT19DT05ORUNUICAgICAgICAxICAgIFtTU0gtVFJBTlNdDQog ICBTU0hfRElTQ09OTkVDVF9QUk9UT0NPTF9FUlJPUiAgICAgICAgICAgICAg ICAgICAgIDIgICAgW1NTSC1UUkFOU10NCiAgIFNTSF9ESVNDT05ORUNUX0tF WV9FWENIQU5HRV9GQUlMRUQgICAgICAgICAgICAgICAgMyAgICBbU1NILVRS QU5TXQ0KICAgU1NIX0RJU0NPTk5FQ1RfUkVTRVJWRUQgICAgICAgICAgICAg ICAgICAgICAgICAgICA0ICAgIFtTU0gtVFJBTlNdDQogICBTU0hfRElTQ09O TkVDVF9NQUNfRVJST1IgICAgICAgICAgICAgICAgICAgICAgICAgIDUgICAg W1NTSC1UUkFOU10NCiAgIFNTSF9ESVNDT05ORUNUX0NPTVBSRVNTSU9OX0VS Uk9SICAgICAgICAgICAgICAgICAgNiAgICBbU1NILVRSQU5TXQ0KICAgU1NI X0RJU0NPTk5FQ1RfU0VSVklDRV9OT1RfQVZBSUxBQkxFICAgICAgICAgICAg ICA3ICAgIFtTU0gtVFJBTlNdDQogICBTU0hfRElTQ09OTkVDVF9QUk9UT0NP TF9WRVJTSU9OX05PVF9TVVBQT1JURUQgICAgIDggICAgW1NTSC1UUkFOU10N CiAgIFNTSF9ESVNDT05ORUNUX0hPU1RfS0VZX05PVF9WRVJJRklBQkxFICAg ICAgICAgICAgOSAgICBbU1NILVRSQU5TXQ0KICAgU1NIX0RJU0NPTk5FQ1Rf Q09OTkVDVElPTl9MT1NUICAgICAgICAgICAgICAgICAgIDEwICAgIFtTU0gt VFJBTlNdDQogICBTU0hfRElTQ09OTkVDVF9CWV9BUFBMSUNBVElPTiAgICAg ICAgICAgICAgICAgICAgMTEgICAgW1NTSC1UUkFOU10NCg0KDQoNCkxlaHRp bmVuICYgTW9mZmF0ICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNCAg ICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg ICAgIFNTSCBQcm90b2NvbCBBc3NpZ25lZCBOdW1iZXJzICAgICAgICAgICAg SnVseSAyMDAzDQoNCg0KICAgU1NIX0RJU0NPTk5FQ1RfVE9PX01BTllfQ09O TkVDVElPTlMgICAgICAgICAgICAgIDEyICAgIFtTU0gtVFJBTlNdDQogICBT U0hfRElTQ09OTkVDVF9BVVRIX0NBTkNFTExFRF9CWV9VU0VSICAgICAgICAg ICAgMTMgICAgW1NTSC1UUkFOU10NCiAgIFNTSF9ESVNDT05ORUNUX05PX01P UkVfQVVUSF9NRVRIT0RTX0FWQUlMQUJMRSAgICAxNCAgICBbU1NILVRSQU5T XQ0KICAgU1NIX0RJU0NPTk5FQ1RfSUxMRUdBTF9VU0VSX05BTUUgICAgICAg ICAgICAgICAgIDE1ICAgIFtTU0gtVFJBTlNdDQoNCg0KICAgMi4gU2Vydmlj ZSBOYW1lcw0KDQogICAgICBUaGUgU2VydmljZSBOYW1lIGlzIHVzZWQgdG8g ZGVzY3JpYmUgYSBwcm90b2NvbCBsYXllci4gIFRoZXNlDQogICAgICBuYW1l cyBNVVNUIGJlIHByaW50YWJsZSBVUy1BU0NJSSBzdHJpbmdzLCBhbmQgTVVT VCBOT1QgY29udGFpbiB0aGUNCiAgICAgIGNoYXJhY3RlcnMgYXQtc2lnbiAo J0AnKSwgY29tbWEgKCcsJyksIG9yIHdoaXRlc3BhY2Ugb3IgY29udHJvbA0K ICAgICAgY2hhcmFjdGVycyAoQVNDSUkgY29kZXMgMzIgb3IgbGVzcykuICBO YW1lcyBhcmUgY2FzZS1zZW5zaXRpdmUsDQogICAgICBhbmQgTVVTVCBOT1Qg YmUgbG9uZ2VyIHRoYW4gNjQgY2hhcmFjdGVycy4NCg0KICAgICAgUmVxdWVz dHMgZm9yIGFzc2lnbm1lbnRzIG9mIG5ldyBzZXJ2aWNlIG5hbWVzIG11c3Qg YmUgYWNjb21wYW5pZWQNCiAgICAgIGJ5IGFuIFJGQyB3aGljaCBkZXNjcmli ZXMgdGhlIGludGVycHJldGF0aW9uIGZvciB0aGUgc2VydmljZSBuYW1lLg0K ICAgICAgSWYgdGhlIFJGQyBpcyBub3Qgb24gdGhlIHN0YW5kYXJkcy10cmFj ayAoaS5lLiAgaXQgaXMgYW4NCiAgICAgIGluZm9ybWF0aW9uYWwgb3IgZXhw ZXJpbWVudGFsIFJGQyksIGl0IG11c3QgYmUgZXhwbGljaXRseSByZXZpZXdl ZA0KICAgICAgYW5kIGFwcHJvdmVkIGJ5IHRoZSBJRVNHIGJlZm9yZSB0aGUg UkZDIGlzIHB1Ymxpc2hlZCBhbmQgdGhlDQogICAgICBzZXJ2aWNlIG5hbWUg aXMgYXNzaWduZWQuDQoNCiAgIFNlcnZpY2UgbmFtZSAgICAgICAgICAgICAg ICAgIFJlZmVyZW5jZQ0KICAgLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAg ICAgLS0tLS0tLS0tDQogICBzc2gtdXNlcmF1dGggICAgICAgICAgICAgICAg ICBbU1NILVVTRVJBVVRIXQ0KICAgc3NoLWNvbm5lY3Rpb24gICAgICAgICAg ICAgICAgW1NTSC1DT05ORUNUXQ0KDQoNCiAgIDIuMSBBdXRoZW50aWNhdGlv biBNZXRob2QgTmFtZXMNCg0KICAgICAgVGhlIEF1dGhlbnRpY2F0aW9uIE1l dGhvZCBOYW1lIGlzIHVzZWQgdG8gZGVzY3JpYmUgYW4NCiAgICAgIGF1dGhl bnRpY2F0aW9uIG1ldGhvZCBmb3IgdGhlICJzc2gtdXNlcmF1dGgiIHNlcnZp Y2UgW1NTSC0NCiAgICAgIFVTRVJBVVRIXS4gIFRoZXNlIG5hbWVzIE1VU1Qg YmUgcHJpbnRhYmxlIFVTLUFTQ0lJIHN0cmluZ3MsIGFuZA0KICAgICAgTVVT VCBOT1QgY29udGFpbiB0aGUgY2hhcmFjdGVycyBhdC1zaWduICgnQCcpLCBj b21tYSAoJywnKSwgb3INCiAgICAgIHdoaXRlc3BhY2Ugb3IgY29udHJvbCBj aGFyYWN0ZXJzIChBU0NJSSBjb2RlcyAzMiBvciBsZXNzKS4gIE5hbWVzDQog ICAgICBhcmUgY2FzZS1zZW5zaXRpdmUsIGFuZCBNVVNUIE5PVCBiZSBsb25n ZXIgdGhhbiA2NCBjaGFyYWN0ZXJzLg0KDQogICAgICBSZXF1ZXN0cyBmb3Ig YXNzaWdubWVudHMgb2YgbmV3IGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBuYW1l cyBtdXN0DQogICAgICBiZSBhY2NvbXBhbmllZCBieSBhbiBSRkMgd2hpY2gg ZGVzY3JpYmVzIHRoZSBpbnRlcnByZXRhdGlvbiBmb3INCiAgICAgIHRoZSBh dXRoZW50aWNhdGlvbiBtZXRob2QuDQoNCiAgIE1ldGhvZCBuYW1lICAgICAg ICAgICAgICAgICAgIFJlZmVyZW5jZQ0KICAgLS0tLS0tLS0tLS0tICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tDQogICBwdWJsaWNrZXkgICAgICAgICAg ICAgICAgICAgICBbU1NILVVTRVJBVVRILCBTZWN0aW9uIDRdDQogICBwYXNz d29yZCAgICAgICAgICAgICAgICAgICAgICBbU1NILVVTRVJBVVRILCBTZWN0 aW9uIDVdDQogICBob3N0YmFzZWQgICAgICAgICAgICAgICAgICAgICBbU1NI LVVTRVJBVVRILCBTZWN0aW9uIDZdDQogICBub25lICAgICAgICAgICAgICAg ICAgICAgICAgICBbU1NILVVTRVJBVVRILCBTZWN0aW9uIDIuM10NCg0KDQoN Cg0KDQpMZWh0aW5lbiAmIE1vZmZhdCAgICAgICBFeHBpcmVzIEphbnVhcnkg MTIsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICBTU0ggUHJvdG9jb2wgQXNzaWduZWQgTnVtYmVycyAg ICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgIDIuMiBDb25uZWN0aW9uIFBy b3RvY29sIEFzc2lnbmVkIE5hbWVzDQoNCiAgICAgIFRoZSBmb2xsb3dpbmcg cmVxdWVzdCBhbmQgdHlwZSBuYW1lcyBNVVNUIGJlIHByaW50YWJsZSBVUy1B U0NJSQ0KICAgICAgc3RyaW5ncywgYW5kIE1VU1QgTk9UIGNvbnRhaW4gdGhl IGNoYXJhY3RlcnMgYXQtc2lnbiAoJ0AnKSwgY29tbWENCiAgICAgICgnLCcp LCBvciB3aGl0ZXNwYWNlIG9yIGNvbnRyb2wgY2hhcmFjdGVycyAoQVNDSUkg Y29kZXMgMzIgb3INCiAgICAgIGxlc3MpLiAgTmFtZXMgYXJlIGNhc2Utc2Vu c2l0aXZlLCBhbmQgTVVTVCBOT1QgYmUgbG9uZ2VyIHRoYW4gNjQNCiAgICAg IGNoYXJhY3RlcnMuDQoNCiAgICAgIFJlcXVlc3RzIGZvciBhc3NpZ25tZW50 cyBvZiBuZXcgYXNzaWduZWQgbmFtZXMgbXVzdCBiZSBhY2NvbXBhbmllZA0K ICAgICAgYnkgYW4gUkZDIHdoaWNoIGRlc2NyaWJlcyB0aGUgaW50ZXJwcmV0 YXRpb24gZm9yIHRoZSB0eXBlIG9yDQogICAgICByZXF1ZXN0Lg0KDQogICAy LjIuMSBDb25uZWN0aW9uIFByb3RvY29sIENoYW5uZWwgVHlwZXMNCg0KICAg Q2hhbm5lbCB0eXBlICAgICAgICAgICAgICAgICAgUmVmZXJlbmNlDQogICAt LS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgICAtLS0tLS0tLS0NCiAgIHNl c3Npb24gICAgICAgICAgICAgICAgICAgICAgIFtTU0gtQ09OTkVDVCwgU2Vj dGlvbiA0LjFdDQogICB4MTEgICAgICAgICAgICAgICAgICAgICAgICAgICBb U1NILUNPTk5FQ1QsIFNlY3Rpb24gNC4zLjJdDQogICBmb3J3YXJkZWQtdGNw aXAgICAgICAgICAgICAgICBbU1NILUNPTk5FQ1QsIFNlY3Rpb24gNS4yXQ0K ICAgZGlyZWN0LXRjcGlwICAgICAgICAgICAgICAgICAgW1NTSC1DT05ORUNU LCBTZWN0aW9uIDUuMl0NCg0KDQogICAyLjIuMiBDb25uZWN0aW9uIFByb3Rv Y29sIEdsb2JhbCBSZXF1ZXN0IE5hbWVzDQoNCiAgIFJlcXVlc3QgdHlwZSAg ICAgICAgICAgICAgICAgIFJlZmVyZW5jZQ0KICAgLS0tLS0tLS0tLS0tICAg ICAgICAgICAgICAgICAgLS0tLS0tLS0tDQogICB0Y3BpcC1mb3J3YXJkICAg ICAgICAgICAgICAgICBbU1NILUNPTk5FQ1QsIFNlY3Rpb24gNS4xXQ0KICAg Y2FuY2VsLXRjcGlwLWZvcndhcmQgICAgICAgICAgW1NTSC1DT05ORUNULCBT ZWN0aW9uIDUuMV0NCg0KDQogICAyLjIuMyBDb25uZWN0aW9uIFByb3RvY29s IENoYW5uZWwgUmVxdWVzdCBOYW1lcw0KDQogICBSZXF1ZXN0IHR5cGUgICAg ICAgICAgICAgICAgICBSZWZlcmVuY2UNCiAgIC0tLS0tLS0tLS0tLSAgICAg ICAgICAgICAgICAgIC0tLS0tLS0tLQ0KICAgcHR5LXJlcSAgICAgICAgICAg ICAgICAgICAgICAgW1NTSC1DT05ORUNULCBTZWN0aW9uIDQuMl0NCiAgIHgx MS1yZXEgICAgICAgICAgICAgICAgICAgICAgIFtTU0gtQ09OTkVDVCwgU2Vj dGlvbiA0LjMuMV0NCiAgIGVudiAgICAgICAgICAgICAgICAgICAgICAgICAg IFtTU0gtQ09OTkVDVCwgU2VjdGlvbiA0LjRdDQogICBzaGVsbCAgICAgICAg ICAgICAgICAgICAgICAgICBbU1NILUNPTk5FQ1QsIFNlY3Rpb24gNC41XQ0K ICAgZXhlYyAgICAgICAgICAgICAgICAgICAgICAgICAgW1NTSC1DT05ORUNU LCBTZWN0aW9uIDQuNV0NCiAgIHN1YnN5c3RlbSAgICAgICAgICAgICAgICAg ICAgIFtTU0gtQ09OTkVDVCwgU2VjdGlvbiA0LjVdDQogICB3aW5kb3ctY2hh bmdlICAgICAgICAgICAgICAgICBbU1NILUNPTk5FQ1QsIFNlY3Rpb24gNC43 XQ0KICAgeG9uLXhvZmYgICAgICAgICAgICAgICAgICAgICAgW1NTSC1DT05O RUNULCBTZWN0aW9uIDQuOF0NCiAgIHNpZ25hbCAgICAgICAgICAgICAgICAg ICAgICAgIFtTU0gtQ09OTkVDVCwgU2VjdGlvbiA0LjldDQogICBleGl0LXN0 YXR1cyAgICAgICAgICAgICAgICAgICBbU1NILUNPTk5FQ1QsIFNlY3Rpb24g NC4xMF0NCiAgIGV4aXQtc2lnbmFsICAgICAgICAgICAgICAgICAgIFtTU0gt Q09OTkVDVCwgU2VjdGlvbiA0LjEwXQ0KDQoNCg0KDQoNCg0KTGVodGluZW4g JiBNb2ZmYXQgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAg ICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg U1NIIFByb3RvY29sIEFzc2lnbmVkIE51bWJlcnMgICAgICAgICAgICBKdWx5 IDIwMDMNCg0KDQogICAzLiBLZXkgRXhjaGFuZ2UgTWV0aG9kIE5hbWVzDQoN CiAgICAgIFRoZSBLZXkgRXhjaGFuZ2UgTWV0aG9kIE5hbWUgZGVzY3JpYmVz IGEga2V5LWV4Y2hhbmdlIG1ldGhvZCBmb3INCiAgICAgIHRoZSBwcm90b2Nv bCBbU1NILVRSQU5TXS4gIFRoZSBuYW1lcyBNVVNUIGJlIHByaW50YWJsZSBV Uy1BU0NJSQ0KICAgICAgc3RyaW5ncywgYW5kIE1VU1QgTk9UIGNvbnRhaW4g dGhlIGNoYXJhY3RlcnMgYXQtc2lnbiAoJ0AnKSwgY29tbWENCiAgICAgICgn LCcpLCBvciB3aGl0ZXNwYWNlIG9yIGNvbnRyb2wgY2hhcmFjdGVycyAoQVND SUkgY29kZXMgMzIgb3INCiAgICAgIGxlc3MpLiAgTmFtZXMgYXJlIGNhc2Ut c2Vuc2l0aXZlLCBhbmQgTVVTVCBOT1QgYmUgbG9uZ2VyIHRoYW4gNjQNCiAg ICAgIGNoYXJhY3RlcnMuDQoNCiAgICAgIFJlcXVlc3RzIGZvciBhc3NpZ25t ZW50IG9mIG5ldyBrZXktZXhjaGFuZ2UgbWV0aG9kIG5hbWVzIG11c3QgYmUN CiAgICAgIGFjY29tcGFuaWVkIGJ5IGEgcmVmZXJlbmNlIHRvIGEgc3RhbmRh cmRzLXRyYWNrIG9yIEluZm9ybWF0aW9uYWwNCiAgICAgIFJGQyB3aGljaCBk ZXNjcmliZXMgdGhpcyBtZXRob2QuDQoNCiAgIE1ldGhvZCBuYW1lICAgICAg ICAgICAgICAgICAgIFJlZmVyZW5jZQ0KICAgLS0tLS0tLS0tLS0tICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tDQogICBkaWZmaWUtaGVsbG1hbi1ncm91 cDEtc2hhMSAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuNV0NCg0KDQogICA0 LiBBc3NpZ25lZCBBbGdvcml0aG0gTmFtZXMNCg0KICAgICAgVGhlIGZvbGxv d2luZyBpZGVudGlmaWVycyAobmFtZXMpIE1VU1QgYmUgcHJpbnRhYmxlIFVT LUFTQ0lJDQogICAgICBzdHJpbmdzLCBhbmQgTVVTVCBOT1QgY29udGFpbiB0 aGUgY2hhcmFjdGVycyBhdC1zaWduICgnQCcpLCBjb21tYQ0KICAgICAgKCcs JyksIG9yIHdoaXRlc3BhY2Ugb3IgY29udHJvbCBjaGFyYWN0ZXJzIChBU0NJ SSBjb2RlcyAzMiBvcg0KICAgICAgbGVzcykuICBOYW1lcyBhcmUgY2FzZS1z ZW5zaXRpdmUsIGFuZCBNVVNUIE5PVCBiZSBsb25nZXIgdGhhbiA2NA0KICAg ICAgY2hhcmFjdGVycy4NCg0KICAgICAgUmVxdWVzdHMgZm9yIGFzc2lnbm1l bnQgb2YgbmV3IGFsZ29yaXRobSBuYW1lcyBtdXN0IGJlIGFjY29tcGFuaWVk DQogICAgICBieSBhIHJlZmVyZW5jZSB0byBhIHN0YW5kYXJkcy10cmFjayBv ciBJbmZvcm1hdGlvbmFsIFJGQyBvciBhDQogICAgICByZWZlcmVuY2UgdG8g cHVibGlzaGVkIGNyeXB0b2dyYXBoaWMgbGl0ZXJhdHVyZSB3aGljaCBkZXNj cmliZXMNCiAgICAgIHRoZSBhbGdvcml0aG0uDQoNCiAgIDQuMSBFbmNyeXB0 aW9uIEFsZ29yaXRobSBOYW1lcw0KDQogICBDaXBoZXIgbmFtZSAgICAgICAg ICAgICAgICAgICBSZWZlcmVuY2UNCiAgIC0tLS0tLS0tLS0tLSAgICAgICAg ICAgICAgICAgIC0tLS0tLS0tLQ0KICAgM2Rlcy1jYmMgICAgICAgICAgICAg ICAgICAgICAgW1NTSC1UUkFOUywgU2VjdGlvbiA0LjNdDQogICBibG93Zmlz aC1jYmMgICAgICAgICAgICAgICAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQu M10NCiAgIHR3b2Zpc2gyNTYtY2JjICAgICAgICAgICAgICAgIFtTU0gtVFJB TlMsIFNlY3Rpb24gNC4zXQ0KICAgdHdvZmlzaC1jYmMgICAgICAgICAgICAg ICAgICAgW1NTSC1UUkFOUywgU2VjdGlvbiA0LjNdDQogICB0d29maXNoMTky LWNiYyAgICAgICAgICAgICAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuM10N CiAgIHR3b2Zpc2gxMjgtY2JjICAgICAgICAgICAgICAgIFtTU0gtVFJBTlMs IFNlY3Rpb24gNC4zXQ0KICAgYWVzMjU2LWNiYyAgICAgICAgICAgICAgICAg ICAgW1NTSC1UUkFOUywgU2VjdGlvbiA0LjNdDQogICBhZXMxOTItY2JjICAg ICAgICAgICAgICAgICAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuM10NCiAg IGFlczEyOC1jYmMgICAgICAgICAgICAgICAgICAgIFtTU0gtVFJBTlMsIFNl Y3Rpb24gNC4zXQ0KICAgc2VycGVudDI1Ni1jYmMgICAgICAgICAgICAgICAg W1NTSC1UUkFOUywgU2VjdGlvbiA0LjNdDQogICBzZXJwZW50MTkyLWNiYyAg ICAgICAgICAgICAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuM10NCiAgIHNl cnBlbnQxMjgtY2JjICAgICAgICAgICAgICAgIFtTU0gtVFJBTlMsIFNlY3Rp b24gNC4zXQ0KICAgYXJjZm91ciAgICAgICAgICAgICAgICAgICAgICAgW1NT SC1UUkFOUywgU2VjdGlvbiA0LjNdDQoNCg0KDQpMZWh0aW5lbiAmIE1vZmZh dCAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAg ICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBTU0ggUHJv dG9jb2wgQXNzaWduZWQgTnVtYmVycyAgICAgICAgICAgIEp1bHkgMjAwMw0K DQoNCiAgIGlkZWEtY2JjICAgICAgICAgICAgICAgICAgICAgIFtTU0gtVFJB TlMsIFNlY3Rpb24gNC4zXQ0KICAgY2FzdDEyOC1jYmMgICAgICAgICAgICAg ICAgICAgW1NTSC1UUkFOUywgU2VjdGlvbiA0LjNdDQogICBub25lICAgICAg ICAgICAgICAgICAgICAgICAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuM10N CiAgIGRlcy1jYmMgICAgICAgICAgICAgICAgICAgICAgIFtGSVBTLTQ2LTNd IEhJU1RPUklDOyBTZWUgcGFnZSA0IG9mIFtGSVBTIDQ2LTNdDQoNCg0KICAg NC4yIE1BQyBBbGdvcml0aG0gTmFtZXMNCg0KDQoNCiAgIE1BQyBuYW1lICAg ICAgICAgICAgICAgICAgICAgIFJlZmVyZW5jZQ0KICAgLS0tLS0tLS0tICAg ICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tDQogICBobWFjLXNoYTEgICAg ICAgICAgICAgICAgICAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuNF0NCiAg IGhtYWMtc2hhMS05NiAgICAgICAgICAgICAgICAgIFtTU0gtVFJBTlMsIFNl Y3Rpb24gNC40XQ0KICAgaG1hYy1tZDUgICAgICAgICAgICAgICAgICAgICAg W1NTSC1UUkFOUywgU2VjdGlvbiA0LjRdDQogICBobWFjLW1kNS05NiAgICAg ICAgICAgICAgICAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuNF0NCiAgIG5v bmUgICAgICAgICAgICAgICAgICAgICAgICAgIFtTU0gtVFJBTlMsIFNlY3Rp b24gNC40XQ0KDQoNCiAgIDQuMyBQdWJsaWMgS2V5IEFsZ29yaXRobSBOYW1l cw0KDQogICBBbGdvcml0aG0gbmFtZSAgICAgICAgICAgICAgICBSZWZlcmVu Y2UNCiAgIC0tLS0tLS0tLS0tLS0tLSAgICAgICAgICAgICAgIC0tLS0tLS0t LQ0KICAgc3NoLWRzcyAgICAgICAgICAgICAgICAgICAgICAgW1NTSC1UUkFO UywgU2VjdGlvbiA0LjZdDQogICBzc2gtcnNhICAgICAgICAgICAgICAgICAg ICAgICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuNl0NCiAgIHg1MDl2My1zaWdu LXJzYSAgICAgICAgICAgICAgIFtTU0gtVFJBTlMsIFNlY3Rpb24gNC42XQ0K ICAgeDUwOXYzLXNpZ24tZHNzICAgICAgICAgICAgICAgW1NTSC1UUkFOUywg U2VjdGlvbiA0LjZdDQogICBzcGtpLXNpZ24tcnNhICAgICAgICAgICAgICAg ICBbU1NILVRSQU5TLCBTZWN0aW9uIDQuNl0NCiAgIHNwa2ktc2lnbi1kc3Mg ICAgICAgICAgICAgICAgIFtTU0gtVFJBTlMsIFNlY3Rpb24gNC42XQ0KICAg cGdwLXNpZ24tcnNhICAgICAgICAgICAgICAgICAgW1NTSC1UUkFOUywgU2Vj dGlvbiA0LjZdDQogICBwZ3Atc2lnbi1kc3MgICAgICAgICAgICAgICAgICBb U1NILVRSQU5TLCBTZWN0aW9uIDQuNl0NCg0KUmVmZXJlbmNlcw0KDQogICAg ICBbU1NILUFSQ0hdICAgICAgWWxvbmVuLCBULiwgIlNTSCBQcm90b2NvbCBB cmNoaXRlY3R1cmUiLCBJLUQNCiAgICAgICAgICAgICAgICAgICAgICBkcmFm dC1pZXRmLWFyY2hpdGVjdHVyZS0xNC50eHQsIEp1bHkgMjAwMy4NCg0KICAg ICAgW1NTSC1UUkFOU10gICAgIFlsb25lbiwgVC4sICJTU0ggVHJhbnNwb3J0 IExheWVyIFByb3RvY29sIiwgSS1EDQogICAgICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi10cmFuc3BvcnQtMTYudHh0LCBKdWx5IDIwMDMuDQoNCiAg ICAgIFtTU0gtVVNFUkFVVEhdICBZbG9uZW4sIFQuLCAiU1NIIEF1dGhlbnRp Y2F0aW9uIFByb3RvY29sIiwgSS1EDQogICAgICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi11c2VyYXV0aC0xNy50eHQsIEp1bHkgMjAwMy4NCg0KICAg ICAgW1NTSC1DT05ORUNUXSAgIFlsb25lbiwgVC4sICJTU0ggQ29ubmVjdGlv biBQcm90b2NvbCIsIEktRCBkcmFmdC0NCiAgICAgICAgICAgICAgICAgICAg ICBpZXRmLWNvbm5lY3QtMTcudHh0LCBKdWx5IDIwMDMuDQoNCiAgICAgIFtT U0gtTlVNQkVSU10gICBMZWh0aW5lbiwgUy4gYW5kIEQuIE1vZmZhdCwgIlNT SCBQcm90b2NvbCBBc3NpZ25lZA0KICAgICAgICAgICAgICAgICAgICAgIE51 bWJlcnMiLCBJLUQgZHJhZnQtaWV0Zi1zZWNzaC1hc3NpZ25lZG51bWJlcnMt DQoNCg0KDQpMZWh0aW5lbiAmIE1vZmZhdCAgICAgICBFeHBpcmVzIEphbnVh cnkgMTIsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICBTU0ggUHJvdG9jb2wgQXNzaWduZWQgTnVtYmVy cyAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgICAgICAgICAgICAg ICAgICAwMy50eHQsIEp1bHkgMjAwMy4NCg0KICAgICAgW0ZJUFMtNDYtM10g ICAgIFUuUy4gRGVwdC4gb2YgQ29tbWVyY2UsIC4sICJGSVBTIFBVQiA0Ni0z LCBEYXRhDQogICAgICAgICAgICAgICAgICAgICAgRW5jcnlwdGlvbiBTdGFu ZGFyZCAoREVTKSIsIE9jdG9iZXIgMTk5OS4NCg0KDQpBdXRob3JzJyBBZGRy ZXNzZXMNCg0KICAgU2FtaSBMZWh0aW5lbg0KICAgU1NIIENvbW11bmljYXRp b25zIFNlY3VyaXR5IENvcnANCiAgIEZyZWRyaWtpbmthdHUgNDINCiAgIEhF TFNJTktJICBGSU4tMDAxMDANCiAgIEZpbmxhbmQNCg0KICAgRU1haWw6IHNq bEBzc2guY29tDQoNCg0KICAgRGFycmVuIEogTW9mZmF0DQogICBTdW4gTWlj cm9zeXN0ZW1zDQogICA5MDEgU2FuIEFudG9uaW8gUm9hZA0KICAgUGFsbyBB bHRvICA5NDMwMw0KICAgVVNBDQoNCiAgIEVNYWlsOiBEYXJyZW4uTW9mZmF0 QFN1bi5DT00NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCkxlaHRpbmVuICYgTW9mZmF0ICAgICAgIEV4 cGlyZXMgSmFudWFyeSAxMiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSA5 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFNTSCBQcm90b2NvbCBBc3Np Z25lZCBOdW1iZXJzICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KRnVsbCBD b3B5cmlnaHQgU3RhdGVtZW50DQoNCiAgICAgIENvcHlyaWdodCAoQykgVGhl IEludGVybmV0IFNvY2lldHkgKDIwMDMpLiAgQWxsIFJpZ2h0cyBSZXNlcnZl ZC4NCg0KICAgICAgVGhpcyBkb2N1bWVudCBhbmQgdHJhbnNsYXRpb25zIG9m IGl0IG1heSBiZSBjb3BpZWQgYW5kIGZ1cm5pc2hlZA0KICAgICAgdG8gb3Ro ZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0IGNvbW1lbnQgb24gb3Ig b3RoZXJ3aXNlDQogICAgICBleHBsYWluIGl0IG9yIGFzc2lzdCBpbiBpdHMg aW1wbGVtZW50YXRpb24gbWF5IGJlIHByZXBhcmVkLA0KICAgICAgY29waWVk LCBwdWJsaXNoZWQgYW5kIGRpc3RyaWJ1dGVkLCBpbiB3aG9sZSBvciBpbiBw YXJ0LCB3aXRob3V0DQogICAgICByZXN0cmljdGlvbiBvZiBhbnkga2luZCwg cHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZQ0KICAg ICAgYW5kIHRoaXMgcGFyYWdyYXBoIGFyZSBpbmNsdWRlZCBvbiBhbGwgc3Vj aCBjb3BpZXMgYW5kIGRlcml2YXRpdmUNCiAgICAgIHdvcmtzLiAgSG93ZXZl ciwgdGhpcyBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBp biBhbnkNCiAgICAgIHdheSwgc3VjaCBhcyBieSByZW1vdmluZyB0aGUgY29w eXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRvIHRoZQ0KICAgICAgSW50 ZXJuZXQgU29jaWV0eSBvciBvdGhlciBJbnRlcm5ldCBvcmdhbml6YXRpb25z LCBleGNlcHQgYXMgbmVlZGVkDQogICAgICBmb3IgdGhlIHB1cnBvc2Ugb2Yg ZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0 aGUNCiAgICAgIHByb2NlZHVyZXMgZm9yIGNvcHlyaWdodHMgZGVmaW5lZCBp biB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzDQogICAgICBwcm9jZXNzIG11c3Qg YmUgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBp bnRvDQogICAgICBsYW5ndWFnZXMgb3RoZXIgdGhhbiBFbmdsaXNoLg0KDQog ICAgICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFy ZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90DQogICAgICBiZSByZXZva2VkIGJ5 IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFz c2lnbnMuDQoNCiAgICAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uDQogICAgICBh biAiQVMgSVMiIGJhc2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQg VEhFIElOVEVSTkVUDQogICAgICBFTkdJTkVFUklORyBUQVNLIEZPUkNFIERJ U0NMQUlNUyBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUg0KICAgICAgSU1Q TElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFO VFkgVEhBVCBUSEUgVVNFIE9GDQogICAgICBUSEUgSU5GT1JNQVRJT04gSEVS RUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJ RUQNCiAgICAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJ VE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFLg0KDQpBY2tub3dsZWRn ZW1lbnQNCg0KICAgICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVu Y3Rpb24gaXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQ0KICAgICAgSW50 ZXJuZXQgU29jaWV0eS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KTGVodGluZW4gJiBNb2ZmYXQgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQo= ---559023410-1903590565-1058246151=:895-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 01:16:24 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04745 for ; Tue, 15 Jul 2003 01:16:22 -0400 (EDT) Received: (qmail 28957 invoked by uid 605); 15 Jul 2003 05:16:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28791 invoked from network); 15 Jul 2003 05:16:09 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 Jul 2003 05:16:09 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6F5G6O5011878; Mon, 14 Jul 2003 23:16:06 -0600 (MDT) Received: from islay (vpn-129-150-17-202.SFBay.Sun.COM [129.150.17.202]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6F5G1tf189057; Mon, 14 Jul 2003 22:16:01 -0700 (PDT) Date: Mon, 14 Jul 2003 22:16:24 -0700 (PDT) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-connect-17.txt Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-33463914-1058246184=:895" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-33463914-1058246184=:895 Content-Type: TEXT/PLAIN; charset=US-ASCII -- Darren J Moffat ---559023410-33463914-1058246184=:895 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-ietf-secsh-connect-17.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-ietf-secsh-connect-17.txt" Content-Transfer-Encoding: BASE64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFQuIFlsb25lbg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBULiBLaXZpbmVuDQpFeHBpcmVzOiBKYW51YXJ5IDEyLCAyMDA0ICAg ICAgICAgICAgICAgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5IENvcnAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNLiBTYWFyaW5lbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVuaXZlcnNpdHkg b2YgSnl2YXNreWxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gUmlubmUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTLiBMZWh0aW5lbg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFNTSCBDb21tdW5pY2F0aW9ucyBTZWN1 cml0eSBDb3JwDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMTQsIDIwMDMNCg0KDQog ICAgICAgICAgICAgICAgICAgICAgICBTU0ggQ29ubmVjdGlvbiBQcm90b2Nv bA0KICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXNlY3NoLWNvbm5l Y3QtMTcudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgICAgVGhp cyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVs bCBjb25mb3JtYW5jZSB3aXRoDQogICAgICBhbGwgcHJvdmlzaW9ucyBvZiBT ZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgICAgIEludGVybmV0LURyYWZ0 cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nDQogICAgICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBh bmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICAgICBvdGhl ciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50 cyBhcyBJbnRlcm5ldC0NCiAgICAgIERyYWZ0cy4NCg0KICAgICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4 aW11bSBvZiBzaXgNCiAgICAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0ZWQs IHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXINCiAgICAgIGRvY3Vt ZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNl IEludGVybmV0LURyYWZ0cw0KICAgICAgYXMgcmVmZXJlbmNlIG1hdGVyaWFs IG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluDQogICAg ICBwcm9ncmVzcy4iDQoNCiAgICAgIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgICAgaHR0cDov L3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICAg ICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3Jp ZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICAgICBodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sLg0KDQogICAgICBUaGlzIEludGVybmV0LURyYWZ0 IHdpbGwgZXhwaXJlIG9uIEphbnVhcnkgMTIsIDIwMDQuDQoNCkNvcHlyaWdo dCBOb3RpY2UNCg0KICAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwMykuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQpBYnN0 cmFjdA0KDQogICAgICBTU0ggaXMgYSBwcm90b2NvbCBmb3Igc2VjdXJlIHJl bW90ZSBsb2dpbiBhbmQgb3RoZXIgc2VjdXJlIG5ldHdvcmsNCiAgICAgIHNl cnZpY2VzIG92ZXIgYW4gaW5zZWN1cmUgbmV0d29yay4NCg0KICAgICAgVGhp cyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIFNTSCBDb25uZWN0aW9uIFByb3Rv Y29sLiAgSXQgcHJvdmlkZXMNCiAgICAgIGludGVyYWN0aXZlIGxvZ2luIHNl c3Npb25zLCByZW1vdGUgZXhlY3V0aW9uIG9mIGNvbW1hbmRzLA0KDQoNCg0K WWxvbmVuLCBldC4gYWwuICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAy MDA0ICAgICAgICAgICAgICAgIFtQYWdlIDFdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgICAgU1NIIENvbm5lY3Rpb24gUHJvdG9jb2wgICAgICAgICAg ICAgICBKdWx5IDIwMDMNCg0KDQogICAgICBmb3J3YXJkZWQgVENQL0lQIGNv bm5lY3Rpb25zLCBhbmQgZm9yd2FyZGVkIFgxMSBjb25uZWN0aW9ucy4gIEFs bA0KICAgICAgb2YgdGhlc2UgY2hhbm5lbHMgYXJlIG11bHRpcGxleGVkIGlu dG8gYSBzaW5nbGUgZW5jcnlwdGVkIHR1bm5lbC4NCg0KICAgICAgVGhlIFNT SCBDb25uZWN0aW9uIFByb3RvY29sIGhhcyBiZWVuIGRlc2lnbmVkIHRvIHJ1 biBvbiB0b3Agb2YgdGhlDQogICAgICBTU0ggdHJhbnNwb3J0IGxheWVyIGFu ZCB1c2VyIGF1dGhlbnRpY2F0aW9uIHByb3RvY29scy4NCg0KVGFibGUgb2Yg Q29udGVudHMNCg0KICAgMS4gICAgSW50cm9kdWN0aW9uIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAy LiAgICBHbG9iYWwgUmVxdWVzdHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDMNCiAgIDMuICAgIENoYW5uZWwgTWVj aGFuaXNtICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgMw0KICAgMy4xICAgT3BlbmluZyBhIENoYW5uZWwgIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA0DQogICAzLjIg ICBEYXRhIFRyYW5zZmVyICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gIDUNCiAgIDMuMyAgIENsb3NpbmcgYSBDaGFu bmVsICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNg0KICAgMy40ICAgQ2hhbm5lbC1TcGVjaWZpYyBSZXF1ZXN0cyAgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA3DQogICA0LiAgICBJ bnRlcmFjdGl2ZSBTZXNzaW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDgNCiAgIDQuMSAgIE9wZW5pbmcgYSBTZXNzaW9u ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg OA0KICAgNC4yICAgUmVxdWVzdGluZyBhIFBzZXVkby1UZXJtaW5hbCAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICA0LjMgICBYMTEg Rm9yd2FyZGluZyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDkNCiAgIDQuMy4xIFJlcXVlc3RpbmcgWDExIEZvcndh cmRpbmcgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0K ICAgNC4zLjIgWDExIENoYW5uZWxzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICA0LjQgICBFbnZpcm9u bWVudCBWYXJpYWJsZSBQYXNzaW5nIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMTANCiAgIDQuNSAgIFN0YXJ0aW5nIGEgU2hlbGwgb3IgYSBD b21tYW5kICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAg NC42ICAgU2Vzc2lvbiBEYXRhIFRyYW5zZmVyICAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIDExDQogICA0LjcgICBXaW5kb3cgRGlt ZW5zaW9uIENoYW5nZSBNZXNzYWdlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gMTENCiAgIDQuOCAgIExvY2FsIEZsb3cgQ29udHJvbCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KICAgNC45 ICAgU2lnbmFscyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDEyDQogICA0LjEwICBSZXR1cm5pbmcgRXhp dCBTdGF0dXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gMTINCiAgIDUuICAgIFRDUC9JUCBQb3J0IEZvcndhcmRpbmcgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgNS4xICAg UmVxdWVzdGluZyBQb3J0IEZvcndhcmRpbmcgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDE0DQogICA1LjIgICBUQ1AvSVAgRm9yd2FyZGlu ZyBDaGFubmVscyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g MTUNCiAgIDYuICAgIEVuY29kaW5nIG9mIFRlcm1pbmFsIE1vZGVzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxNg0KICAgNy4gICAgU3Vt bWFyeSBvZiBNZXNzYWdlIE51bWJlcnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDE4DQogICA4LiAgICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTgN CiAgIDkuICAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxOA0KICAgMTAuICAgQWRkaXRp b25hbCBJbmZvcm1hdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIDE5DQogICAgICAgICBSZWZlcmVuY2VzIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTkNCiAg ICAgICAgIEF1dGhvcnMnIEFkZHJlc3NlcyAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMA0KICAgICAgICAgRnVsbCBDb3B5 cmlnaHQgU3RhdGVtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDIyDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpZbG9uZW4sIGV0 LiBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAg ICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg ICBTU0ggQ29ubmVjdGlvbiBQcm90b2NvbCAgICAgICAgICAgICAgIEp1bHkg MjAwMw0KDQoNCiAgIDEuIEludHJvZHVjdGlvbg0KDQogICAgICBUaGUgU1NI IENvbm5lY3Rpb24gUHJvdG9jb2wgaGFzIGJlZW4gZGVzaWduZWQgdG8gcnVu IG9uIHRvcCBvZiB0aGUNCiAgICAgIFNTSCB0cmFuc3BvcnQgbGF5ZXIgYW5k IHVzZXIgYXV0aGVudGljYXRpb24gcHJvdG9jb2xzLiAgSXQNCiAgICAgIHBy b3ZpZGVzIGludGVyYWN0aXZlIGxvZ2luIHNlc3Npb25zLCByZW1vdGUgZXhl Y3V0aW9uIG9mIGNvbW1hbmRzLA0KICAgICAgZm9yd2FyZGVkIFRDUC9JUCBj b25uZWN0aW9ucywgYW5kIGZvcndhcmRlZCBYMTEgY29ubmVjdGlvbnMuICBU aGUNCiAgICAgIHNlcnZpY2UgbmFtZSBmb3IgdGhpcyBwcm90b2NvbCAoYWZ0 ZXIgdXNlciBhdXRoZW50aWNhdGlvbikgaXMNCiAgICAgICJzc2gtY29ubmVj dGlvbiIuDQoNCiAgICAgIFRoaXMgZG9jdW1lbnQgc2hvdWxkIGJlIHJlYWQg b25seSBhZnRlciByZWFkaW5nIHRoZSBTU0gNCiAgICAgIGFyY2hpdGVjdHVy ZSBkb2N1bWVudCBbU1NILUFSQ0hdLiAgVGhpcyBkb2N1bWVudCBmcmVlbHkg dXNlcw0KICAgICAgdGVybWlub2xvZ3kgYW5kIG5vdGF0aW9uIGZyb20gdGhl IGFyY2hpdGVjdHVyZSBkb2N1bWVudCB3aXRob3V0DQogICAgICByZWZlcmVu Y2Ugb3IgZnVydGhlciBleHBsYW5hdGlvbi4NCg0KICAgMi4gR2xvYmFsIFJl cXVlc3RzDQoNCiAgICAgIFRoZXJlIGFyZSBzZXZlcmFsIGtpbmRzIG9mIHJl cXVlc3RzIHRoYXQgYWZmZWN0IHRoZSBzdGF0ZSBvZiB0aGUNCiAgICAgIHJl bW90ZSBlbmQgImdsb2JhbGx5IiwgaW5kZXBlbmRlbnQgb2YgYW55IGNoYW5u ZWxzLiAgQW4gZXhhbXBsZSBpcw0KICAgICAgYSByZXF1ZXN0IHRvIHN0YXJ0 IFRDUC9JUCBmb3J3YXJkaW5nIGZvciBhIHNwZWNpZmljIHBvcnQuICBBbGwN CiAgICAgIHN1Y2ggcmVxdWVzdHMgdXNlIHRoZSBmb2xsb3dpbmcgZm9ybWF0 Lg0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNHX0dMT0JBTF9SRVFVRVNUDQog ICAgIHN0cmluZyAgICByZXF1ZXN0IG5hbWUgKHJlc3RyaWN0ZWQgdG8gVVMt QVNDSUkpDQogICAgIGJvb2xlYW4gICB3YW50IHJlcGx5DQogICAgIC4uLiBy ZXF1ZXN0LXNwZWNpZmljIGRhdGEgZm9sbG93cw0KDQogICAgICBSZXF1ZXN0 IG5hbWVzIGZvbGxvdyB0aGUgRE5TIGV4dGVuc2liaWxpdHkgbmFtaW5nIGNv bnZlbnRpb24NCiAgICAgIG91dGxpbmVkIGluIFtTU0gtQVJDSF0uDQoNCiAg ICAgIFRoZSByZWNpcGllbnQgd2lsbCByZXNwb25kIHRvIHRoaXMgbWVzc2Fn ZSB3aXRoDQogICAgICBTU0hfTVNHX1JFUVVFU1RfU1VDQ0VTUyBvciBTU0hf TVNHX1JFUVVFU1RfRkFJTFVSRSBpZiBgd2FudCByZXBseScNCiAgICAgIGlz IFRSVUUuDQoNCiAgICAgYnl0ZSAgICAgIFNTSF9NU0dfUkVRVUVTVF9TVUND RVNTDQogICAgIC4uLi4uICAgICByZXNwb25zZSBzcGVjaWZpYyBkYXRhDQoN CiAgIFVzdWFsbHkgdGhlIHJlc3BvbnNlIHNwZWNpZmljIGRhdGEgaXMgbm9u LWV4aXN0ZW50Lg0KDQogICAgICBJZiB0aGUgcmVjaXBpZW50IGRvZXMgbm90 IHJlY29nbml6ZSBvciBzdXBwb3J0IHRoZSByZXF1ZXN0LCBpdA0KICAgICAg c2ltcGx5IHJlc3BvbmRzIHdpdGggU1NIX01TR19SRVFVRVNUX0ZBSUxVUkUu DQoNCiAgICAgYnl0ZSAgICAgIFNTSF9NU0dfUkVRVUVTVF9GQUlMVVJFDQoN Cg0KICAgMy4gQ2hhbm5lbCBNZWNoYW5pc20NCg0KICAgICAgQWxsIHRlcm1p bmFsIHNlc3Npb25zLCBmb3J3YXJkZWQgY29ubmVjdGlvbnMsIGV0Yy4gIGFy ZSBjaGFubmVscy4NCiAgICAgIEVpdGhlciBzaWRlIG1heSBvcGVuIGEgY2hh bm5lbC4gIE11bHRpcGxlIGNoYW5uZWxzIGFyZSBtdWx0aXBsZXhlZA0KDQoN Cg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEy LCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgU1NIIENvbm5lY3Rpb24gUHJvdG9jb2wgICAgICAg ICAgICAgICBKdWx5IDIwMDMNCg0KDQogICAgICBpbnRvIGEgc2luZ2xlIGNv bm5lY3Rpb24uDQoNCiAgICAgIENoYW5uZWxzIGFyZSBpZGVudGlmaWVkIGJ5 IG51bWJlcnMgYXQgZWFjaCBlbmQuICBUaGUgbnVtYmVyDQogICAgICByZWZl cnJpbmcgdG8gYSBjaGFubmVsIG1heSBiZSBkaWZmZXJlbnQgb24gZWFjaCBz aWRlLiAgUmVxdWVzdHMgdG8NCiAgICAgIG9wZW4gYSBjaGFubmVsIGNvbnRh aW4gdGhlIHNlbmRlcidzIGNoYW5uZWwgbnVtYmVyLiAgQW55IG90aGVyDQog ICAgICBjaGFubmVsLXJlbGF0ZWQgbWVzc2FnZXMgY29udGFpbiB0aGUgcmVj aXBpZW50J3MgY2hhbm5lbCBudW1iZXINCiAgICAgIGZvciB0aGUgY2hhbm5l bC4NCg0KICAgICAgQ2hhbm5lbHMgYXJlIGZsb3ctY29udHJvbGxlZC4gIE5v IGRhdGEgbWF5IGJlIHNlbnQgdG8gYSBjaGFubmVsDQogICAgICB1bnRpbCBh IG1lc3NhZ2UgaXMgcmVjZWl2ZWQgdG8gaW5kaWNhdGUgdGhhdCB3aW5kb3cg c3BhY2UgaXMNCiAgICAgIGF2YWlsYWJsZS4NCg0KICAgMy4xIE9wZW5pbmcg YSBDaGFubmVsDQoNCiAgICAgIFdoZW4gZWl0aGVyIHNpZGUgd2lzaGVzIHRv IG9wZW4gYSBuZXcgY2hhbm5lbCwgaXQgYWxsb2NhdGVzIGENCiAgICAgIGxv Y2FsIG51bWJlciBmb3IgdGhlIGNoYW5uZWwuICBJdCB0aGVuIHNlbmRzIHRo ZSBmb2xsb3dpbmcgbWVzc2FnZQ0KICAgICAgdG8gdGhlIG90aGVyIHNpZGUs IGFuZCBpbmNsdWRlcyB0aGUgbG9jYWwgY2hhbm5lbCBudW1iZXIgYW5kDQog ICAgICBpbml0aWFsIHdpbmRvdyBzaXplIGluIHRoZSBtZXNzYWdlLg0KDQog ICAgIGJ5dGUgICAgICBTU0hfTVNHX0NIQU5ORUxfT1BFTg0KICAgICBzdHJp bmcgICAgY2hhbm5lbCB0eXBlIChyZXN0cmljdGVkIHRvIFVTLUFTQ0lJKQ0K ICAgICB1aW50MzIgICAgc2VuZGVyIGNoYW5uZWwNCiAgICAgdWludDMyICAg IGluaXRpYWwgd2luZG93IHNpemUNCiAgICAgdWludDMyICAgIG1heGltdW0g cGFja2V0IHNpemUNCiAgICAgLi4uIGNoYW5uZWwgdHlwZSBzcGVjaWZpYyBk YXRhIGZvbGxvd3MNCg0KICAgICAgVGhlIGNoYW5uZWwgdHlwZSBpcyBhIG5h bWUgYXMgZGVzY3JpYmVkIGluIHRoZSBTU0ggYXJjaGl0ZWN0dXJlDQogICAg ICBkb2N1bWVudCwgd2l0aCBzaW1pbGFyIGV4dGVuc2lvbiBtZWNoYW5pc21z LiAgYHNlbmRlciBjaGFubmVsJyBpcw0KICAgICAgYSBsb2NhbCBpZGVudGlm aWVyIGZvciB0aGUgY2hhbm5lbCB1c2VkIGJ5IHRoZSBzZW5kZXIgb2YgdGhp cw0KICAgICAgbWVzc2FnZS4gIGBpbml0aWFsIHdpbmRvdyBzaXplJyBzcGVj aWZpZXMgaG93IG1hbnkgYnl0ZXMgb2YNCiAgICAgIGNoYW5uZWwgZGF0YSBj YW4gYmUgc2VudCB0byB0aGUgc2VuZGVyIG9mIHRoaXMgbWVzc2FnZSB3aXRo b3V0DQogICAgICBhZGp1c3RpbmcgdGhlIHdpbmRvdy4gIGBNYXhpbXVtIHBh Y2tldCBzaXplJyBzcGVjaWZpZXMgdGhlIG1heGltdW0NCiAgICAgIHNpemUg b2YgYW4gaW5kaXZpZHVhbCBkYXRhIHBhY2tldCB0aGF0IGNhbiBiZSBzZW50 IHRvIHRoZSBzZW5kZXINCiAgICAgIChmb3IgZXhhbXBsZSwgb25lIG1pZ2h0 IHdhbnQgdG8gdXNlIHNtYWxsZXIgcGFja2V0cyBmb3INCiAgICAgIGludGVy YWN0aXZlIGNvbm5lY3Rpb25zIHRvIGdldCBiZXR0ZXIgaW50ZXJhY3RpdmUg cmVzcG9uc2Ugb24gc2xvdw0KICAgICAgbGlua3MpLg0KDQogICAgICBUaGUg cmVtb3RlIHNpZGUgdGhlbiBkZWNpZGVzIHdoZXRoZXIgaXQgY2FuIG9wZW4g dGhlIGNoYW5uZWwsIGFuZA0KICAgICAgcmVzcG9uZHMgd2l0aCBlaXRoZXIN Cg0KICAgICBieXRlICAgICAgU1NIX01TR19DSEFOTkVMX09QRU5fQ09ORklS TUFUSU9ODQogICAgIHVpbnQzMiAgICByZWNpcGllbnQgY2hhbm5lbA0KICAg ICB1aW50MzIgICAgc2VuZGVyIGNoYW5uZWwNCiAgICAgdWludDMyICAgIGlu aXRpYWwgd2luZG93IHNpemUNCiAgICAgdWludDMyICAgIG1heGltdW0gcGFj a2V0IHNpemUNCiAgICAgLi4uIGNoYW5uZWwgdHlwZSBzcGVjaWZpYyBkYXRh IGZvbGxvd3MNCg0KICAgICAgd2hlcmUgYHJlY2lwaWVudCBjaGFubmVsJyBp cyB0aGUgY2hhbm5lbCBudW1iZXIgZ2l2ZW4gaW4gdGhlDQoNCg0KDQpZbG9u ZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDQg ICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCkludGVybmV0LURyYWZ0ICAg ICAgICAgICBTU0ggQ29ubmVjdGlvbiBQcm90b2NvbCAgICAgICAgICAgICAg IEp1bHkgMjAwMw0KDQoNCiAgICAgIG9yaWdpbmFsIG9wZW4gcmVxdWVzdCwg YW5kIGBzZW5kZXIgY2hhbm5lbCcgaXMgdGhlIGNoYW5uZWwgbnVtYmVyDQog ICAgICBhbGxvY2F0ZWQgYnkgdGhlIG90aGVyIHNpZGUsIG9yDQoNCiAgICAg Ynl0ZSAgICAgIFNTSF9NU0dfQ0hBTk5FTF9PUEVOX0ZBSUxVUkUNCiAgICAg dWludDMyICAgIHJlY2lwaWVudCBjaGFubmVsDQogICAgIHVpbnQzMiAgICBy ZWFzb24gY29kZQ0KICAgICBzdHJpbmcgICAgYWRkaXRpb25hbCB0ZXh0dWFs IGluZm9ybWF0aW9uIChJU08tMTA2NDYgVVRGLTggW1JGQzIyNzldKQ0KICAg ICBzdHJpbmcgICAgbGFuZ3VhZ2UgdGFnIChhcyBkZWZpbmVkIGluIFtSRkMx NzY2XSkNCg0KICAgICAgSWYgdGhlIHJlY2lwaWVudCBvZiB0aGUgU1NIX01T R19DSEFOTkVMX09QRU4gbWVzc2FnZSBkb2VzIG5vdA0KICAgICAgc3VwcG9y dCB0aGUgc3BlY2lmaWVkIGNoYW5uZWwgdHlwZSwgaXQgc2ltcGx5IHJlc3Bv bmRzIHdpdGgNCiAgICAgIFNTSF9NU0dfQ0hBTk5FTF9PUEVOX0ZBSUxVUkUu ICBUaGUgY2xpZW50IE1BWSBzaG93IHRoZSBhZGRpdGlvbmFsDQogICAgICBp bmZvcm1hdGlvbiB0byB0aGUgdXNlci4gIElmIHRoaXMgaXMgZG9uZSwgdGhl IGNsaWVudCBzb2Z0d2FyZQ0KICAgICAgc2hvdWxkIHRha2UgdGhlIHByZWNh dXRpb25zIGRpc2N1c3NlZCBpbiBbU1NILUFSQ0hdLg0KDQogICAgICBUaGUg Zm9sbG93aW5nIHJlYXNvbiBjb2RlcyBhcmUgZGVmaW5lZDoNCg0KICAgICAj ZGVmaW5lIFNTSF9PUEVOX0FETUlOSVNUUkFUSVZFTFlfUFJPSElCSVRFRCAg ICAxDQogICAgICNkZWZpbmUgU1NIX09QRU5fQ09OTkVDVF9GQUlMRUQgICAg ICAgICAgICAgICAgIDINCiAgICAgI2RlZmluZSBTU0hfT1BFTl9VTktOT1dO X0NIQU5ORUxfVFlQRSAgICAgICAgICAgMw0KICAgICAjZGVmaW5lIFNTSF9P UEVOX1JFU09VUkNFX1NIT1JUQUdFICAgICAgICAgICAgICA0DQoNCg0KICAg My4yIERhdGEgVHJhbnNmZXINCg0KICAgICAgVGhlIHdpbmRvdyBzaXplIHNw ZWNpZmllcyBob3cgbWFueSBieXRlcyB0aGUgb3RoZXIgcGFydHkgY2FuIHNl bmQNCiAgICAgIGJlZm9yZSBpdCBtdXN0IHdhaXQgZm9yIHRoZSB3aW5kb3cg dG8gYmUgYWRqdXN0ZWQuICBCb3RoIHBhcnRpZXMNCiAgICAgIHVzZSB0aGUg Zm9sbG93aW5nIG1lc3NhZ2UgdG8gYWRqdXN0IHRoZSB3aW5kb3cuDQoNCiAg ICAgYnl0ZSAgICAgIFNTSF9NU0dfQ0hBTk5FTF9XSU5ET1dfQURKVVNUDQog ICAgIHVpbnQzMiAgICByZWNpcGllbnQgY2hhbm5lbA0KICAgICB1aW50MzIg ICAgYnl0ZXMgdG8gYWRkDQoNCiAgICAgIEFmdGVyIHJlY2VpdmluZyB0aGlz IG1lc3NhZ2UsIHRoZSByZWNpcGllbnQgTUFZIHNlbmQgdGhlIGdpdmVuDQog ICAgICBudW1iZXIgb2YgYnl0ZXMgbW9yZSB0aGFuIGl0IHdhcyBwcmV2aW91 c2x5IGFsbG93ZWQgdG8gc2VuZDsgdGhlDQogICAgICB3aW5kb3cgc2l6ZSBp cyBpbmNyZW1lbnRlZC4NCg0KICAgICAgRGF0YSB0cmFuc2ZlciBpcyBkb25l IHdpdGggbWVzc2FnZXMgb2YgdGhlIGZvbGxvd2luZyB0eXBlLg0KDQogICAg IGJ5dGUgICAgICBTU0hfTVNHX0NIQU5ORUxfREFUQQ0KICAgICB1aW50MzIg ICAgcmVjaXBpZW50IGNoYW5uZWwNCiAgICAgc3RyaW5nICAgIGRhdGENCg0K ICAgICAgVGhlIG1heGltdW0gYW1vdW50IG9mIGRhdGEgYWxsb3dlZCBpcyB0 aGUgY3VycmVudCB3aW5kb3cgc2l6ZS4NCiAgICAgIFRoZSB3aW5kb3cgc2l6 ZSBpcyBkZWNyZW1lbnRlZCBieSB0aGUgYW1vdW50IG9mIGRhdGEgc2VudC4g IEJvdGgNCiAgICAgIHBhcnRpZXMgTUFZIGlnbm9yZSBhbGwgZXh0cmEgZGF0 YSBzZW50IGFmdGVyIHRoZSBhbGxvd2VkIHdpbmRvdyBpcw0KICAgICAgZW1w dHkuDQoNCg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGlyZXMg SmFudWFyeSAxMiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0K SW50ZXJuZXQtRHJhZnQgICAgICAgICAgIFNTSCBDb25uZWN0aW9uIFByb3Rv Y29sICAgICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KICAgICAgQWRkaXRp b25hbGx5LCBzb21lIGNoYW5uZWxzIGNhbiB0cmFuc2ZlciBzZXZlcmFsIHR5 cGVzIG9mIGRhdGEuDQogICAgICBBbiBleGFtcGxlIG9mIHRoaXMgaXMgc3Rk ZXJyIGRhdGEgZnJvbSBpbnRlcmFjdGl2ZSBzZXNzaW9ucy4gIFN1Y2gNCiAg ICAgIGRhdGEgY2FuIGJlIHBhc3NlZCB3aXRoIFNTSF9NU0dfQ0hBTk5FTF9F WFRFTkRFRF9EQVRBIG1lc3NhZ2VzLA0KICAgICAgd2hlcmUgYSBzZXBhcmF0 ZSBpbnRlZ2VyIHNwZWNpZmllcyB0aGUgdHlwZSBvZiB0aGUgZGF0YS4gIFRo ZQ0KICAgICAgYXZhaWxhYmxlIHR5cGVzIGFuZCB0aGVpciBpbnRlcnByZXRh dGlvbiBkZXBlbmQgb24gdGhlIHR5cGUgb2YgdGhlDQogICAgICBjaGFubmVs Lg0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNHX0NIQU5ORUxfRVhURU5ERURf REFUQQ0KICAgICB1aW50MzIgICAgcmVjaXBpZW50X2NoYW5uZWwNCiAgICAg dWludDMyICAgIGRhdGFfdHlwZV9jb2RlDQogICAgIHN0cmluZyAgICBkYXRh DQoNCiAgICAgIERhdGEgc2VudCB3aXRoIHRoZXNlIG1lc3NhZ2VzIGNvbnN1 bWVzIHRoZSBzYW1lIHdpbmRvdyBhcyBvcmRpbmFyeQ0KICAgICAgZGF0YS4N Cg0KICAgICAgQ3VycmVudGx5LCBvbmx5IHRoZSBmb2xsb3dpbmcgdHlwZSBp cyBkZWZpbmVkLg0KDQogICAjZGVmaW5lIFNTSF9FWFRFTkRFRF9EQVRBX1NU REVSUiAgICAgICAgICAgICAgICAxDQoNCg0KICAgMy4zIENsb3NpbmcgYSBD aGFubmVsDQoNCiAgICAgIFdoZW4gYSBwYXJ0eSB3aWxsIG5vIGxvbmdlciBz ZW5kIG1vcmUgZGF0YSB0byBhIGNoYW5uZWwsIGl0IFNIT1VMRA0KICAgICAg c2VuZCBTU0hfTVNHX0NIQU5ORUxfRU9GLg0KDQogICAgIGJ5dGUgICAgICBT U0hfTVNHX0NIQU5ORUxfRU9GDQogICAgIHVpbnQzMiAgICByZWNpcGllbnRf Y2hhbm5lbA0KDQogICAgICBObyBleHBsaWNpdCByZXNwb25zZSBpcyBzZW50 IHRvIHRoaXMgbWVzc2FnZTsgaG93ZXZlciwgdGhlDQogICAgICBhcHBsaWNh dGlvbiBtYXkgc2VuZCBFT0YgdG8gd2hhdGV2ZXIgaXMgYXQgdGhlIG90aGVy IGVuZCBvZiB0aGUNCiAgICAgIGNoYW5uZWwuICBOb3RlIHRoYXQgdGhlIGNo YW5uZWwgcmVtYWlucyBvcGVuIGFmdGVyIHRoaXMgbWVzc2FnZSwNCiAgICAg IGFuZCBtb3JlIGRhdGEgbWF5IHN0aWxsIGJlIHNlbnQgaW4gdGhlIG90aGVy IGRpcmVjdGlvbi4gIFRoaXMNCiAgICAgIG1lc3NhZ2UgZG9lcyBub3QgY29u c3VtZSB3aW5kb3cgc3BhY2UgYW5kIGNhbiBiZSBzZW50IGV2ZW4gaWYgbm8N CiAgICAgIHdpbmRvdyBzcGFjZSBpcyBhdmFpbGFibGUuDQoNCiAgICAgIFdo ZW4gZWl0aGVyIHBhcnR5IHdpc2hlcyB0byB0ZXJtaW5hdGUgdGhlIGNoYW5u ZWwsIGl0IHNlbmRzDQogICAgICBTU0hfTVNHX0NIQU5ORUxfQ0xPU0UuICBV cG9uIHJlY2VpdmluZyB0aGlzIG1lc3NhZ2UsIGEgcGFydHkgTVVTVA0KICAg ICAgc2VuZCBiYWNrIGEgU1NIX01TR19DSEFOTkVMX0NMT1NFIHVubGVzcyBp dCBoYXMgYWxyZWFkeSBzZW50IHRoaXMNCiAgICAgIG1lc3NhZ2UgZm9yIHRo ZSBjaGFubmVsLiAgVGhlIGNoYW5uZWwgaXMgY29uc2lkZXJlZCBjbG9zZWQg Zm9yIGENCiAgICAgIHBhcnR5IHdoZW4gaXQgaGFzIGJvdGggc2VudCBhbmQg cmVjZWl2ZWQgU1NIX01TR19DSEFOTkVMX0NMT1NFLA0KICAgICAgYW5kIHRo ZSBwYXJ0eSBtYXkgdGhlbiByZXVzZSB0aGUgY2hhbm5lbCBudW1iZXIuICBB IHBhcnR5IE1BWSBzZW5kDQogICAgICBTU0hfTVNHX0NIQU5ORUxfQ0xPU0Ug d2l0aG91dCBoYXZpbmcgc2VudCBvciByZWNlaXZlZA0KICAgICAgU1NIX01T R19DSEFOTkVMX0VPRi4NCg0KICAgICBieXRlICAgICAgU1NIX01TR19DSEFO TkVMX0NMT1NFDQogICAgIHVpbnQzMiAgICByZWNpcGllbnRfY2hhbm5lbA0K DQogICAgICBUaGlzIG1lc3NhZ2UgZG9lcyBub3QgY29uc3VtZSB3aW5kb3cg c3BhY2UgYW5kIGNhbiBiZSBzZW50IGV2ZW4gaWYNCg0KDQoNCllsb25lbiwg ZXQuIGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNCAgICAg ICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgIFNTSCBDb25uZWN0aW9uIFByb3RvY29sICAgICAgICAgICAgICAgSnVs eSAyMDAzDQoNCg0KICAgICAgbm8gd2luZG93IHNwYWNlIGlzIGF2YWlsYWJs ZS4NCg0KICAgICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCBhbnkgZGF0YSBz ZW50IGJlZm9yZSB0aGlzIG1lc3NhZ2UgaXMNCiAgICAgIGRlbGl2ZXJlZCB0 byB0aGUgYWN0dWFsIGRlc3RpbmF0aW9uLCBpZiBwb3NzaWJsZS4NCg0KICAg My40IENoYW5uZWwtU3BlY2lmaWMgUmVxdWVzdHMNCg0KICAgICAgTWFueSBj aGFubmVsIHR5cGVzIGhhdmUgZXh0ZW5zaW9ucyB0aGF0IGFyZSBzcGVjaWZp YyB0byB0aGF0DQogICAgICBwYXJ0aWN1bGFyIGNoYW5uZWwgdHlwZS4gIEFu IGV4YW1wbGUgaXMgcmVxdWVzdGluZyBhIHB0eSAocHNldWRvDQogICAgICB0 ZXJtaW5hbCkgZm9yIGFuIGludGVyYWN0aXZlIHNlc3Npb24uDQoNCiAgICAg IEFsbCBjaGFubmVsLXNwZWNpZmljIHJlcXVlc3RzIHVzZSB0aGUgZm9sbG93 aW5nIGZvcm1hdC4NCg0KICAgICBieXRlICAgICAgU1NIX01TR19DSEFOTkVM X1JFUVVFU1QNCiAgICAgdWludDMyICAgIHJlY2lwaWVudCBjaGFubmVsDQog ICAgIHN0cmluZyAgICByZXF1ZXN0IHR5cGUgKHJlc3RyaWN0ZWQgdG8gVVMt QVNDSUkpDQogICAgIGJvb2xlYW4gICB3YW50IHJlcGx5DQogICAgIC4uLiB0 eXBlLXNwZWNpZmljIGRhdGENCg0KICAgICAgSWYgd2FudCByZXBseSBpcyBG QUxTRSwgbm8gcmVzcG9uc2Ugd2lsbCBiZSBzZW50IHRvIHRoZSByZXF1ZXN0 Lg0KICAgICAgT3RoZXJ3aXNlLCB0aGUgcmVjaXBpZW50IHJlc3BvbmRzIHdp dGggZWl0aGVyDQogICAgICBTU0hfTVNHX0NIQU5ORUxfU1VDQ0VTUyBvciBT U0hfTVNHX0NIQU5ORUxfRkFJTFVSRSwgb3IgcmVxdWVzdC0NCiAgICAgIHNw ZWNpZmljIGNvbnRpbnVhdGlvbiBtZXNzYWdlcy4gIElmIHRoZSByZXF1ZXN0 IGlzIG5vdCByZWNvZ25pemVkDQogICAgICBvciBpcyBub3Qgc3VwcG9ydGVk IGZvciB0aGUgY2hhbm5lbCwgU1NIX01TR19DSEFOTkVMX0ZBSUxVUkUgaXMN CiAgICAgIHJldHVybmVkLg0KDQogICAgICBUaGlzIG1lc3NhZ2UgZG9lcyBu b3QgY29uc3VtZSB3aW5kb3cgc3BhY2UgYW5kIGNhbiBiZSBzZW50IGV2ZW4g aWYNCiAgICAgIG5vIHdpbmRvdyBzcGFjZSBpcyBhdmFpbGFibGUuICBSZXF1 ZXN0IHR5cGVzIGFyZSBsb2NhbCB0byBlYWNoDQogICAgICBjaGFubmVsIHR5 cGUuDQoNCiAgICAgIFRoZSBjbGllbnQgaXMgYWxsb3dlZCB0byBzZW5kIGZ1 cnRoZXIgbWVzc2FnZXMgd2l0aG91dCB3YWl0aW5nIGZvcg0KICAgICAgdGhl IHJlc3BvbnNlIHRvIHRoZSByZXF1ZXN0Lg0KDQogICAgICByZXF1ZXN0IHR5 cGUgbmFtZXMgZm9sbG93IHRoZSBETlMgZXh0ZW5zaWJpbGl0eSBuYW1pbmcg Y29udmVudGlvbg0KICAgICAgb3V0bGluZWQgaW4gW1NTSC1BUkNIXQ0KDQog ICAgIGJ5dGUgICAgICBTU0hfTVNHX0NIQU5ORUxfU1VDQ0VTUw0KICAgICB1 aW50MzIgICAgcmVjaXBpZW50X2NoYW5uZWwNCg0KDQogICAgIGJ5dGUgICAg ICBTU0hfTVNHX0NIQU5ORUxfRkFJTFVSRQ0KICAgICB1aW50MzIgICAgcmVj aXBpZW50X2NoYW5uZWwNCg0KICAgICAgVGhlc2UgbWVzc2FnZXMgZG8gbm90 IGNvbnN1bWUgd2luZG93IHNwYWNlIGFuZCBjYW4gYmUgc2VudCBldmVuIGlm DQogICAgICBubyB3aW5kb3cgc3BhY2UgaXMgYXZhaWxhYmxlLg0KDQoNCg0K DQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgRXhwaXJlcyBKYW51YXJ5 IDEyLCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgU1NIIENvbm5lY3Rpb24gUHJvdG9jb2wgICAg ICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQogICA0LiBJbnRlcmFjdGl2ZSBT ZXNzaW9ucw0KDQogICAgICBBIHNlc3Npb24gaXMgYSByZW1vdGUgZXhlY3V0 aW9uIG9mIGEgcHJvZ3JhbS4gIFRoZSBwcm9ncmFtIG1heSBiZQ0KICAgICAg YSBzaGVsbCwgYW4gYXBwbGljYXRpb24sIGEgc3lzdGVtIGNvbW1hbmQsIG9y IHNvbWUgYnVpbHQtaW4NCiAgICAgIHN1YnN5c3RlbS4gIEl0IG1heSBvciBt YXkgbm90IGhhdmUgYSB0dHksIGFuZCBtYXkgb3IgbWF5IG5vdA0KICAgICAg aW52b2x2ZSBYMTEgZm9yd2FyZGluZy4gIE11bHRpcGxlIHNlc3Npb25zIGNh biBiZSBhY3RpdmUNCiAgICAgIHNpbXVsdGFuZW91c2x5Lg0KDQogICA0LjEg T3BlbmluZyBhIFNlc3Npb24NCg0KICAgICAgQSBzZXNzaW9uIGlzIHN0YXJ0 ZWQgYnkgc2VuZGluZyB0aGUgZm9sbG93aW5nIG1lc3NhZ2UuDQoNCiAgICAg Ynl0ZSAgICAgIFNTSF9NU0dfQ0hBTk5FTF9PUEVODQogICAgIHN0cmluZyAg ICAic2Vzc2lvbiINCiAgICAgdWludDMyICAgIHNlbmRlciBjaGFubmVsDQog ICAgIHVpbnQzMiAgICBpbml0aWFsIHdpbmRvdyBzaXplDQogICAgIHVpbnQz MiAgICBtYXhpbXVtIHBhY2tldCBzaXplDQoNCiAgICAgIENsaWVudCBpbXBs ZW1lbnRhdGlvbnMgU0hPVUxEIHJlamVjdCBhbnkgc2Vzc2lvbiBjaGFubmVs IG9wZW4NCiAgICAgIHJlcXVlc3RzIHRvIG1ha2UgaXQgbW9yZSBkaWZmaWN1 bHQgZm9yIGEgY29ycnVwdCBzZXJ2ZXIgdG8gYXR0YWNrDQogICAgICB0aGUg Y2xpZW50Lg0KDQogICA0LjIgUmVxdWVzdGluZyBhIFBzZXVkby1UZXJtaW5h bA0KDQogICAgICBBIHBzZXVkby10ZXJtaW5hbCBjYW4gYmUgYWxsb2NhdGVk IGZvciB0aGUgc2Vzc2lvbiBieSBzZW5kaW5nIHRoZQ0KICAgICAgZm9sbG93 aW5nIG1lc3NhZ2UuDQoNCiAgICAgYnl0ZSAgICAgIFNTSF9NU0dfQ0hBTk5F TF9SRVFVRVNUDQogICAgIHVpbnQzMiAgICByZWNpcGllbnRfY2hhbm5lbA0K ICAgICBzdHJpbmcgICAgInB0eS1yZXEiDQogICAgIGJvb2xlYW4gICB3YW50 X3JlcGx5DQogICAgIHN0cmluZyAgICBURVJNIGVudmlyb25tZW50IHZhcmlh YmxlIHZhbHVlIChlLmcuLCB2dDEwMCkNCiAgICAgdWludDMyICAgIHRlcm1p bmFsIHdpZHRoLCBjaGFyYWN0ZXJzIChlLmcuLCA4MCkNCiAgICAgdWludDMy ICAgIHRlcm1pbmFsIGhlaWdodCwgcm93cyAoZS5nLiwgMjQpDQogICAgIHVp bnQzMiAgICB0ZXJtaW5hbCB3aWR0aCwgcGl4ZWxzIChlLmcuLCA2NDApDQog ICAgIHVpbnQzMiAgICB0ZXJtaW5hbCBoZWlnaHQsIHBpeGVscyAoZS5nLiwg NDgwKQ0KICAgICBzdHJpbmcgICAgZW5jb2RlZCB0ZXJtaW5hbCBtb2Rlcw0K DQogICAgICBUaGUgZW5jb2Rpbmcgb2YgdGVybWluYWwgbW9kZXMgaXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gRW5jb2Rpbmcgb2YNCiAgICAgIFRlcm1pbmFs IE1vZGVzIChTZWN0aW9uIDYpLiAgWmVybyBkaW1lbnNpb24gcGFyYW1ldGVy cyBNVVNUIGJlDQogICAgICBpZ25vcmVkLiAgVGhlIGNoYXJhY3Rlci9yb3cg ZGltZW5zaW9ucyBvdmVycmlkZSB0aGUgcGl4ZWwNCiAgICAgIGRpbWVuc2lv bnMgKHdoZW4gbm9uemVybykuICBQaXhlbCBkaW1lbnNpb25zIHJlZmVyIHRv IHRoZSBkcmF3YWJsZQ0KICAgICAgYXJlYSBvZiB0aGUgd2luZG93Lg0KDQog ICAgICBUaGUgZGltZW5zaW9uIHBhcmFtZXRlcnMgYXJlIG9ubHkgaW5mb3Jt YXRpb25hbC4NCg0KICAgICAgVGhlIGNsaWVudCBTSE9VTEQgaWdub3JlIHB0 eSByZXF1ZXN0cy4NCg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdl IDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgU1NIIENvbm5lY3Rp b24gUHJvdG9jb2wgICAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQogICA0 LjMgWDExIEZvcndhcmRpbmcNCg0KICAgNC4zLjEgUmVxdWVzdGluZyBYMTEg Rm9yd2FyZGluZw0KDQogICAgICBYMTEgZm9yd2FyZGluZyBtYXkgYmUgcmVx dWVzdGVkIGZvciBhIHNlc3Npb24gYnkgc2VuZGluZw0KDQogICAgIGJ5dGUg ICAgICBTU0hfTVNHX0NIQU5ORUxfUkVRVUVTVA0KICAgICB1aW50MzIgICAg cmVjaXBpZW50IGNoYW5uZWwNCiAgICAgc3RyaW5nICAgICJ4MTEtcmVxIg0K ICAgICBib29sZWFuICAgd2FudCByZXBseQ0KICAgICBib29sZWFuICAgc2lu Z2xlIGNvbm5lY3Rpb24NCiAgICAgc3RyaW5nICAgIHgxMSBhdXRoZW50aWNh dGlvbiBwcm90b2NvbA0KICAgICBzdHJpbmcgICAgeDExIGF1dGhlbnRpY2F0 aW9uIGNvb2tpZQ0KICAgICB1aW50MzIgICAgeDExIHNjcmVlbiBudW1iZXIN Cg0KICAgICAgSXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgYXV0aGVudGlj YXRpb24gY29va2llIHRoYXQgaXMgc2VudCBiZSBhDQogICAgICBmYWtlLCBy YW5kb20gY29va2llLCBhbmQgdGhhdCB0aGUgY29va2llIGlzIGNoZWNrZWQg YW5kIHJlcGxhY2VkDQogICAgICBieSB0aGUgcmVhbCBjb29raWUgd2hlbiBh IGNvbm5lY3Rpb24gcmVxdWVzdCBpcyByZWNlaXZlZC4NCg0KICAgICAgWDEx IGNvbm5lY3Rpb24gZm9yd2FyZGluZyBzaG91bGQgc3RvcCB3aGVuIHRoZSBz ZXNzaW9uIGNoYW5uZWwgaXMNCiAgICAgIGNsb3NlZDsgaG93ZXZlciwgYWxy ZWFkeSBvcGVuZWQgZm9yd2FyZGluZ3Mgc2hvdWxkIG5vdCBiZQ0KICAgICAg YXV0b21hdGljYWxseSBjbG9zZWQgd2hlbiB0aGUgc2Vzc2lvbiBjaGFubmVs IGlzIGNsb3NlZC4NCg0KICAgICAgSWYgYHNpbmdsZSBjb25uZWN0aW9uJyBp cyBUUlVFLCBvbmx5IGEgc2luZ2xlIGNvbm5lY3Rpb24gc2hvdWxkIGJlDQog ICAgICBmb3J3YXJkZWQuICBObyBtb3JlIGNvbm5lY3Rpb25zIHdpbGwgYmUg Zm9yd2FyZGVkIGFmdGVyIHRoZSBmaXJzdCwNCiAgICAgIG9yIGFmdGVyIHRo ZSBzZXNzaW9uIGNoYW5uZWwgaGFzIGJlZW4gY2xvc2VkLg0KDQogICAgICBU aGUgYHgxMSBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCcgaXMgdGhlIG5hbWUg b2YgdGhlIFgxMQ0KICAgICAgYXV0aGVudGljYXRpb24gbWV0aG9kIHVzZWQs IGUuZy4gICJNSVQtTUFHSUMtQ09PS0lFLTEiLg0KDQogICAgICBUaGUgeDEx IGF1dGhlbnRpY2F0aW9uIGNvb2tpZSBNVVNUIGJlIGhleGFkZWNpbWFsIGVu Y29kZWQuDQoNCiAgICAgIFggUHJvdG9jb2wgaXMgZG9jdW1lbnRlZCBpbiBb U0NIRUlGTEVSXS4NCg0KICAgNC4zLjIgWDExIENoYW5uZWxzDQoNCiAgICAg IFgxMSBjaGFubmVscyBhcmUgb3BlbmVkIHdpdGggYSBjaGFubmVsIG9wZW4g cmVxdWVzdC4gIFRoZQ0KICAgICAgcmVzdWx0aW5nIGNoYW5uZWxzIGFyZSBp bmRlcGVuZGVudCBvZiB0aGUgc2Vzc2lvbiwgYW5kIGNsb3NpbmcgdGhlDQog ICAgICBzZXNzaW9uIGNoYW5uZWwgZG9lcyBub3QgY2xvc2UgdGhlIGZvcndh cmRlZCBYMTEgY2hhbm5lbHMuDQoNCiAgICAgYnl0ZSAgICAgIFNTSF9NU0df Q0hBTk5FTF9PUEVODQogICAgIHN0cmluZyAgICAieDExIg0KICAgICB1aW50 MzIgICAgc2VuZGVyIGNoYW5uZWwNCiAgICAgdWludDMyICAgIGluaXRpYWwg d2luZG93IHNpemUNCiAgICAgdWludDMyICAgIG1heGltdW0gcGFja2V0IHNp emUNCiAgICAgc3RyaW5nICAgIG9yaWdpbmF0b3IgYWRkcmVzcyAoZS5nLiAi MTkyLjE2OC43LjM4IikNCiAgICAgdWludDMyICAgIG9yaWdpbmF0b3IgcG9y dA0KDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEph bnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICAgICBTU0ggQ29ubmVjdGlvbiBQcm90b2Nv bCAgICAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgIFRoZSByZWNp cGllbnQgc2hvdWxkIHJlc3BvbmQgd2l0aA0KICAgICAgU1NIX01TR19DSEFO TkVMX09QRU5fQ09ORklSTUFUSU9OIG9yIFNTSF9NU0dfQ0hBTk5FTF9PUEVO X0ZBSUxVUkUuDQoNCiAgICAgIEltcGxlbWVudGF0aW9ucyBNVVNUIHJlamVj dCBhbnkgWDExIGNoYW5uZWwgb3BlbiByZXF1ZXN0cyBpZiB0aGV5DQogICAg ICBoYXZlIG5vdCByZXF1ZXN0ZWQgWDExIGZvcndhcmRpbmcuDQoNCiAgIDQu NCBFbnZpcm9ubWVudCBWYXJpYWJsZSBQYXNzaW5nDQoNCiAgICAgIEVudmly b25tZW50IHZhcmlhYmxlcyBtYXkgYmUgcGFzc2VkIHRvIHRoZSBzaGVsbC9j b21tYW5kIHRvIGJlDQogICAgICBzdGFydGVkIGxhdGVyLiAgVW5jb250cm9s bGVkIHNldHRpbmcgb2YgZW52aXJvbm1lbnQgdmFyaWFibGVzIGluIGENCiAg ICAgIHByaXZpbGVnZWQgcHJvY2VzcyBjYW4gYmUgYSBzZWN1cml0eSBoYXph cmQuICBJdCBpcyByZWNvbW1lbmRlZA0KICAgICAgdGhhdCBpbXBsZW1lbnRh dGlvbnMgZWl0aGVyIG1haW50YWluIGEgbGlzdCBvZiBhbGxvd2FibGUgdmFy aWFibGUNCiAgICAgIG5hbWVzIG9yIG9ubHkgc2V0IGVudmlyb25tZW50IHZh cmlhYmxlcyBhZnRlciB0aGUgc2VydmVyIHByb2Nlc3MNCiAgICAgIGhhcyBk cm9wcGVkIHN1ZmZpY2llbnQgcHJpdmlsZWdlcy4NCg0KICAgICBieXRlICAg ICAgU1NIX01TR19DSEFOTkVMX1JFUVVFU1QNCiAgICAgdWludDMyICAgIHJl Y2lwaWVudCBjaGFubmVsDQogICAgIHN0cmluZyAgICAiZW52Ig0KICAgICBi b29sZWFuICAgd2FudCByZXBseQ0KICAgICBzdHJpbmcgICAgdmFyaWFibGUg bmFtZQ0KICAgICBzdHJpbmcgICAgdmFyaWFibGUgdmFsdWUNCg0KDQogICA0 LjUgU3RhcnRpbmcgYSBTaGVsbCBvciBhIENvbW1hbmQNCg0KICAgICAgT25j ZSB0aGUgc2Vzc2lvbiBoYXMgYmVlbiBzZXQgdXAsIGEgcHJvZ3JhbSBpcyBz dGFydGVkIGF0IHRoZQ0KICAgICAgcmVtb3RlIGVuZC4gIFRoZSBwcm9ncmFt IGNhbiBiZSBhIHNoZWxsLCBhbiBhcHBsaWNhdGlvbiBwcm9ncmFtIG9yDQog ICAgICBhIHN1YnN5c3RlbSB3aXRoIGEgaG9zdC1pbmRlcGVuZGVudCBuYW1l LiAgT25seSBvbmUgb2YgdGhlc2UNCiAgICAgIHJlcXVlc3RzIGNhbiBzdWNj ZWVkIHBlciBjaGFubmVsLg0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNHX0NI QU5ORUxfUkVRVUVTVA0KICAgICB1aW50MzIgICAgcmVjaXBpZW50IGNoYW5u ZWwNCiAgICAgc3RyaW5nICAgICJzaGVsbCINCiAgICAgYm9vbGVhbiAgIHdh bnQgcmVwbHkNCg0KICAgICAgVGhpcyBtZXNzYWdlIHdpbGwgcmVxdWVzdCB0 aGUgdXNlcidzIGRlZmF1bHQgc2hlbGwgKHR5cGljYWxseQ0KICAgICAgZGVm aW5lZCBpbiAvZXRjL3Bhc3N3ZCBpbiBVTklYIHN5c3RlbXMpIHRvIGJlIHN0 YXJ0ZWQgYXQgdGhlIG90aGVyDQogICAgICBlbmQuDQoNCiAgICAgYnl0ZSAg ICAgIFNTSF9NU0dfQ0hBTk5FTF9SRVFVRVNUDQogICAgIHVpbnQzMiAgICBy ZWNpcGllbnQgY2hhbm5lbA0KICAgICBzdHJpbmcgICAgImV4ZWMiDQogICAg IGJvb2xlYW4gICB3YW50IHJlcGx5DQogICAgIHN0cmluZyAgICBjb21tYW5k DQoNCiAgICAgIFRoaXMgbWVzc2FnZSB3aWxsIHJlcXVlc3QgdGhlIHNlcnZl ciB0byBzdGFydCB0aGUgZXhlY3V0aW9uIG9mIHRoZQ0KICAgICAgZ2l2ZW4g Y29tbWFuZC4gIFRoZSBjb21tYW5kIHN0cmluZyBtYXkgY29udGFpbiBhIHBh dGguICBOb3JtYWwNCiAgICAgIHByZWNhdXRpb25zIE1VU1QgYmUgdGFrZW4g dG8gcHJldmVudCB0aGUgZXhlY3V0aW9uIG9mIHVuYXV0aG9yaXplZA0KDQoN Cg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEy LCAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgU1NIIENvbm5lY3Rpb24gUHJvdG9jb2wgICAgICAg ICAgICAgICBKdWx5IDIwMDMNCg0KDQogICAgICBjb21tYW5kcy4NCg0KICAg ICBieXRlICAgICAgU1NIX01TR19DSEFOTkVMX1JFUVVFU1QNCiAgICAgdWlu dDMyICAgIHJlY2lwaWVudCBjaGFubmVsDQogICAgIHN0cmluZyAgICAic3Vi c3lzdGVtIg0KICAgICBib29sZWFuICAgd2FudCByZXBseQ0KICAgICBzdHJp bmcgICAgc3Vic3lzdGVtIG5hbWUNCg0KICAgICAgVGhpcyBsYXN0IGZvcm0g ZXhlY3V0ZXMgYSBwcmVkZWZpbmVkIHN1YnN5c3RlbS4gIEl0IGlzIGV4cGVj dGVkDQogICAgICB0aGF0IHRoZXNlIHdpbGwgaW5jbHVkZSBhIGdlbmVyYWwg ZmlsZSB0cmFuc2ZlciBtZWNoYW5pc20sIGFuZA0KICAgICAgcG9zc2libHkg b3RoZXIgZmVhdHVyZXMuICBJbXBsZW1lbnRhdGlvbnMgbWF5IGFsc28gYWxs b3cNCiAgICAgIGNvbmZpZ3VyaW5nIG1vcmUgc3VjaCBtZWNoYW5pc21zLiAg QXMgdGhlIHVzZXIncyBzaGVsbCBpcyB1c3VhbGx5DQogICAgICB1c2VkIHRv IGV4ZWN1dGUgdGhlIHN1YnN5c3RlbSwgaXQgaXMgYWR2aXNhYmxlIGZvciB0 aGUgc3Vic3lzdGVtDQogICAgICBwcm90b2NvbCB0byBoYXZlIGEgIm1hZ2lj IGNvb2tpZSIgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgcHJvdG9jb2wNCiAg ICAgIHRyYW5zYWN0aW9uIHRvIGRpc3Rpbmd1aXNoIGl0IGZyb20gYXJiaXRy YXJ5IG91dHB1dCBnZW5lcmF0ZWQgYnkNCiAgICAgIHNoZWxsIGluaXRpYWxp emF0aW9uIHNjcmlwdHMgZXRjLiAgVGhpcyBzcHVyaW91cyBvdXRwdXQgZnJv bSB0aGUNCiAgICAgIHNoZWxsIG1heSBiZSBmaWx0ZXJlZCBvdXQgZWl0aGVy IGF0IHRoZSBzZXJ2ZXIgb3IgYXQgdGhlIGNsaWVudC4NCg0KICAgICAgVGhl IHNlcnZlciBTSE9VTEQgbm90IGhhbHQgdGhlIGV4ZWN1dGlvbiBvZiB0aGUg cHJvdG9jb2wgc3RhY2sNCiAgICAgIHdoZW4gc3RhcnRpbmcgYSBzaGVsbCBv ciBhIHByb2dyYW0uICBBbGwgaW5wdXQgYW5kIG91dHB1dCBmcm9tDQogICAg ICB0aGVzZSBTSE9VTEQgYmUgcmVkaXJlY3RlZCB0byB0aGUgY2hhbm5lbCBv ciB0byB0aGUgZW5jcnlwdGVkDQogICAgICB0dW5uZWwuDQoNCiAgICAgIEl0 IGlzIFJFQ09NTUVOREVEIHRvIHJlcXVlc3QgYW5kIGNoZWNrIHRoZSByZXBs eSBmb3IgdGhlc2UNCiAgICAgIG1lc3NhZ2VzLiAgVGhlIGNsaWVudCBTSE9V TEQgaWdub3JlIHRoZXNlIG1lc3NhZ2VzLg0KDQogICAgICBTdWJzeXN0ZW0g bmFtZXMgZm9sbG93IHRoZSBETlMgZXh0ZW5zaWJpbGl0eSBuYW1pbmcgY29u dmVudGlvbg0KICAgICAgb3V0bGluZWQgaW4gW1NTSC1BUkNIXS4NCg0KICAg NC42IFNlc3Npb24gRGF0YSBUcmFuc2Zlcg0KDQogICAgICBEYXRhIHRyYW5z ZmVyIGZvciBhIHNlc3Npb24gaXMgZG9uZSB1c2luZyBTU0hfTVNHX0NIQU5O RUxfREFUQSBhbmQNCiAgICAgIFNTSF9NU0dfQ0hBTk5FTF9FWFRFTkRFRF9E QVRBIHBhY2tldHMgYW5kIHRoZSB3aW5kb3cgbWVjaGFuaXNtLg0KICAgICAg VGhlIGV4dGVuZGVkIGRhdGEgdHlwZSBTU0hfRVhURU5ERURfREFUQV9TVERF UlIgaGFzIGJlZW4gZGVmaW5lZA0KICAgICAgZm9yIHN0ZGVyciBkYXRhLg0K DQogICA0LjcgV2luZG93IERpbWVuc2lvbiBDaGFuZ2UgTWVzc2FnZQ0KDQog ICAgICBXaGVuIHRoZSB3aW5kb3cgKHRlcm1pbmFsKSBzaXplIGNoYW5nZXMg b24gdGhlIGNsaWVudCBzaWRlLCBpdCBNQVkNCiAgICAgIHNlbmQgYSBtZXNz YWdlIHRvIHRoZSBvdGhlciBzaWRlIHRvIGluZm9ybSBpdCBvZiB0aGUgbmV3 DQogICAgICBkaW1lbnNpb25zLg0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNH X0NIQU5ORUxfUkVRVUVTVA0KICAgICB1aW50MzIgICAgcmVjaXBpZW50X2No YW5uZWwNCiAgICAgc3RyaW5nICAgICJ3aW5kb3ctY2hhbmdlIg0KICAgICBi b29sZWFuICAgRkFMU0UNCiAgICAgdWludDMyICAgIHRlcm1pbmFsIHdpZHRo LCBjb2x1bW5zDQogICAgIHVpbnQzMiAgICB0ZXJtaW5hbCBoZWlnaHQsIHJv d3MNCg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGlyZXMgSmFu dWFyeSAxMiwgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50 ZXJuZXQtRHJhZnQgICAgICAgICAgIFNTSCBDb25uZWN0aW9uIFByb3RvY29s ICAgICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KICAgICB1aW50MzIgICAg dGVybWluYWwgd2lkdGgsIHBpeGVscw0KICAgICB1aW50MzIgICAgdGVybWlu YWwgaGVpZ2h0LCBwaXhlbHMNCg0KICAgICAgIE5vIHJlc3BvbnNlIFNIT1VM RCBiZSBzZW50IHRvIHRoaXMgbWVzc2FnZS4NCg0KICAgNC44IExvY2FsIEZs b3cgQ29udHJvbA0KDQogICAgICBPbiBtYW55IHN5c3RlbXMsIGl0IGlzIHBv c3NpYmxlIHRvIGRldGVybWluZSBpZiBhIHBzZXVkby10ZXJtaW5hbA0KICAg ICAgaXMgdXNpbmcgY29udHJvbC1TL2NvbnRyb2wtUSBmbG93IGNvbnRyb2wu ICBXaGVuIGZsb3cgY29udHJvbCBpcw0KICAgICAgYWxsb3dlZCwgaXQgaXMg b2Z0ZW4gZGVzaXJhYmxlIHRvIGRvIHRoZSBmbG93IGNvbnRyb2wgYXQgdGhl DQogICAgICBjbGllbnQgZW5kIHRvIHNwZWVkIHVwIHJlc3BvbnNlcyB0byB1 c2VyIHJlcXVlc3RzLiAgVGhpcyBpcw0KICAgICAgZmFjaWxpdGF0ZWQgYnkg dGhlIGZvbGxvd2luZyBub3RpZmljYXRpb24uICBJbml0aWFsbHksIHRoZSBz ZXJ2ZXINCiAgICAgIGlzIHJlc3BvbnNpYmxlIGZvciBmbG93IGNvbnRyb2wu ICAoSGVyZSwgYWdhaW4sIGNsaWVudCBtZWFucyB0aGUNCiAgICAgIHNpZGUg b3JpZ2luYXRpbmcgdGhlIHNlc3Npb24sIGFuZCBzZXJ2ZXIgbWVhbnMgdGhl IG90aGVyIHNpZGUuKQ0KDQogICAgICBUaGUgbWVzc2FnZSBiZWxvdyBpcyB1 c2VkIGJ5IHRoZSBzZXJ2ZXIgdG8gaW5mb3JtIHRoZSBjbGllbnQgd2hlbg0K ICAgICAgaXQgY2FuIG9yIGNhbm5vdCBwZXJmb3JtIGZsb3cgY29udHJvbCAo Y29udHJvbC1TL2NvbnRyb2wtUQ0KICAgICAgcHJvY2Vzc2luZykuICBJZiBg Y2xpZW50IGNhbiBkbycgaXMgVFJVRSwgdGhlIGNsaWVudCBpcyBhbGxvd2Vk IHRvDQogICAgICBkbyBmbG93IGNvbnRyb2wgdXNpbmcgY29udHJvbC1TIGFu ZCBjb250cm9sLVEuICBUaGUgY2xpZW50IE1BWQ0KICAgICAgaWdub3JlIHRo aXMgbWVzc2FnZS4NCg0KICAgICBieXRlICAgICAgU1NIX01TR19DSEFOTkVM X1JFUVVFU1QNCiAgICAgdWludDMyICAgIHJlY2lwaWVudCBjaGFubmVsDQog ICAgIHN0cmluZyAgICAieG9uLXhvZmYiDQogICAgIGJvb2xlYW4gICBGQUxT RQ0KICAgICBib29sZWFuICAgY2xpZW50IGNhbiBkbw0KDQogICAgICBObyBy ZXNwb25zZSBpcyBzZW50IHRvIHRoaXMgbWVzc2FnZS4NCg0KICAgNC45IFNp Z25hbHMNCg0KICAgICAgQSBzaWduYWwgY2FuIGJlIGRlbGl2ZXJlZCB0byB0 aGUgcmVtb3RlIHByb2Nlc3Mvc2VydmljZSB1c2luZyB0aGUNCiAgICAgIGZv bGxvd2luZyBtZXNzYWdlLiAgU29tZSBzeXN0ZW1zIG1heSBub3QgaW1wbGVt ZW50IHNpZ25hbHMsIGluDQogICAgICB3aGljaCBjYXNlIHRoZXkgU0hPVUxE IGlnbm9yZSB0aGlzIG1lc3NhZ2UuDQoNCiAgICAgYnl0ZSAgICAgIFNTSF9N U0dfQ0hBTk5FTF9SRVFVRVNUDQogICAgIHVpbnQzMiAgICByZWNpcGllbnQg Y2hhbm5lbA0KICAgICBzdHJpbmcgICAgInNpZ25hbCINCiAgICAgYm9vbGVh biAgIEZBTFNFDQogICAgIHN0cmluZyAgICBzaWduYWwgbmFtZSB3aXRob3V0 IHRoZSAiU0lHIiBwcmVmaXguDQoNCiAgICAgIFNpZ25hbCBuYW1lcyB3aWxs IGJlIGVuY29kZWQgYXMgZGlzY3Vzc2VkIGluIHRoZSAiZXhpdC1zaWduYWwi DQogICAgICBTU0hfTVNHX0NIQU5ORUxfUkVRVUVTVC4NCg0KICAgNC4xMCBS ZXR1cm5pbmcgRXhpdCBTdGF0dXMNCg0KICAgICAgV2hlbiB0aGUgY29tbWFu ZCBydW5uaW5nIGF0IHRoZSBvdGhlciBlbmQgdGVybWluYXRlcywgdGhlDQog ICAgICBmb2xsb3dpbmcgbWVzc2FnZSBjYW4gYmUgc2VudCB0byByZXR1cm4g dGhlIGV4aXQgc3RhdHVzIG9mIHRoZQ0KDQoNCg0KWWxvbmVuLCBldC4gYWwu ICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAg ICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgU1NI IENvbm5lY3Rpb24gUHJvdG9jb2wgICAgICAgICAgICAgICBKdWx5IDIwMDMN Cg0KDQogICAgICBjb21tYW5kLiAgUmV0dXJuaW5nIHRoZSBzdGF0dXMgaXMg UkVDT01NRU5ERUQuICBObyBhY2tub3dsZWRnbWVudA0KICAgICAgaXMgc2Vu dCBmb3IgdGhpcyBtZXNzYWdlLiAgVGhlIGNoYW5uZWwgbmVlZHMgdG8gYmUg Y2xvc2VkIHdpdGgNCiAgICAgIFNTSF9NU0dfQ0hBTk5FTF9DTE9TRSBhZnRl ciB0aGlzIG1lc3NhZ2UuDQoNCiAgICAgIFRoZSBjbGllbnQgTUFZIGlnbm9y ZSB0aGVzZSBtZXNzYWdlcy4NCg0KICAgICBieXRlICAgICAgU1NIX01TR19D SEFOTkVMX1JFUVVFU1QNCiAgICAgdWludDMyICAgIHJlY2lwaWVudF9jaGFu bmVsDQogICAgIHN0cmluZyAgICAiZXhpdC1zdGF0dXMiDQogICAgIGJvb2xl YW4gICBGQUxTRQ0KICAgICB1aW50MzIgICAgZXhpdF9zdGF0dXMNCg0KICAg ICAgVGhlIHJlbW90ZSBjb21tYW5kIG1heSBhbHNvIHRlcm1pbmF0ZSB2aW9s ZW50bHkgZHVlIHRvIGEgc2lnbmFsLg0KICAgICAgU3VjaCBhIGNvbmRpdGlv biBjYW4gYmUgaW5kaWNhdGVkIGJ5IHRoZSBmb2xsb3dpbmcgbWVzc2FnZS4g IEENCiAgICAgIHplcm8gZXhpdF9zdGF0dXMgdXN1YWxseSBtZWFucyB0aGF0 IHRoZSBjb21tYW5kIHRlcm1pbmF0ZWQNCiAgICAgIHN1Y2Nlc3NmdWxseS4N Cg0KICAgICBieXRlICAgICAgU1NIX01TR19DSEFOTkVMX1JFUVVFU1QNCiAg ICAgdWludDMyICAgIHJlY2lwaWVudCBjaGFubmVsDQogICAgIHN0cmluZyAg ICAiZXhpdC1zaWduYWwiDQogICAgIGJvb2xlYW4gICBGQUxTRQ0KICAgICBz dHJpbmcgICAgc2lnbmFsIG5hbWUgd2l0aG91dCB0aGUgIlNJRyIgcHJlZml4 Lg0KICAgICBib29sZWFuICAgY29yZSBkdW1wZWQNCiAgICAgc3RyaW5nICAg IGVycm9yIG1lc3NhZ2UgKElTTy0xMDY0NiBVVEYtOCkNCiAgICAgc3RyaW5n ICAgIGxhbmd1YWdlIHRhZyAoYXMgZGVmaW5lZCBpbiBbUkZDMTc2Nl0pDQoN CiAgICAgIFRoZSBzaWduYWwgbmFtZSBpcyBvbmUgb2YgdGhlIGZvbGxvd2lu ZyAodGhlc2UgYXJlIGZyb20gW1BPU0lYXSkNCg0KICAgICBBQlJUDQogICAg IEFMUk0NCiAgICAgRlBFDQogICAgIEhVUA0KICAgICBJTEwNCiAgICAgSU5U DQogICAgIEtJTEwNCiAgICAgUElQRQ0KICAgICBRVUlUDQogICAgIFNFR1YN CiAgICAgVEVSTQ0KICAgICBVU1IxDQogICAgIFVTUjINCg0KICAgICAgQWRk aXRpb25hbCBzaWduYWwgbmFtZXMgTUFZIGJlIHNlbnQgaW4gdGhlIGZvcm1h dCAic2lnLW5hbWVAeHl6IiwNCiAgICAgIHdoZXJlIGBzaWctbmFtZScgYW5k IGB4eXonIG1heSBiZSBhbnl0aGluZyBhIHBhcnRpY3VsYXINCiAgICAgIGlt cGxlbWVudG9yIHdhbnRzIChleGNlcHQgdGhlIGBAJyBzaWduKS4gIEhvd2V2 ZXIsIGl0IGlzIHN1Z2dlc3RlZA0KICAgICAgdGhhdCBpZiBhIGBjb25maWd1 cmUnIHNjcmlwdCBpcyB1c2VkLCB0aGUgbm9uLXN0YW5kYXJkIHNpZ25hbA0K ICAgICAgbmFtZXMgaXQgZmluZHMgYmUgZW5jb2RlZCBhcyAiU0lHQHh5ei5j b25maWcuZ3Vlc3MiLCB3aGVyZSBgU0lHJw0KICAgICAgaXMgdGhlIHNpZ25h bCBuYW1lIHdpdGhvdXQgdGhlICJTSUciIHByZWZpeCwgYW5kIGB4eXonIGJl IHRoZSBob3N0DQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBp cmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxM10N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgICBTU0ggQ29ubmVjdGlvbiBQ cm90b2NvbCAgICAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgIHR5 cGUsIGFzIGRldGVybWluZWQgYnkgYGNvbmZpZy5ndWVzcycuDQoNCiAgICAg IFRoZSBgZXJyb3IgbWVzc2FnZScgY29udGFpbnMgYW4gYWRkaXRpb25hbCBl eHBsYW5hdGlvbiBvZiB0aGUNCiAgICAgIGVycm9yIG1lc3NhZ2UuICBUaGUg bWVzc2FnZSBtYXkgY29uc2lzdCBvZiBtdWx0aXBsZSBsaW5lcy4gIFRoZQ0K ICAgICAgY2xpZW50IHNvZnR3YXJlIE1BWSBkaXNwbGF5IHRoaXMgbWVzc2Fn ZSB0byB0aGUgdXNlci4gIElmIHRoaXMgaXMNCiAgICAgIGRvbmUsIHRoZSBj bGllbnQgc29mdHdhcmUgc2hvdWxkIHRha2UgdGhlIHByZWNhdXRpb25zIGRp c2N1c3NlZCBpbg0KICAgICAgW1NTSC1BUkNIXS4NCg0KICAgNS4gVENQL0lQ IFBvcnQgRm9yd2FyZGluZw0KDQogICA1LjEgUmVxdWVzdGluZyBQb3J0IEZv cndhcmRpbmcNCg0KICAgICAgQSBwYXJ0eSBuZWVkIG5vdCBleHBsaWNpdGx5 IHJlcXVlc3QgZm9yd2FyZGluZ3MgZnJvbSBpdHMgb3duIGVuZA0KICAgICAg dG8gdGhlIG90aGVyIGRpcmVjdGlvbi4gIEhvd2V2ZXIsIGlmIGl0IHdpc2hl cyB0aGF0IGNvbm5lY3Rpb25zIHRvDQogICAgICBhIHBvcnQgb24gdGhlIG90 aGVyIHNpZGUgYmUgZm9yd2FyZGVkIHRvIHRoZSBsb2NhbCBzaWRlLCBpdCBt dXN0DQogICAgICBleHBsaWNpdGx5IHJlcXVlc3QgdGhpcy4NCg0KDQogICAg IGJ5dGUgICAgICBTU0hfTVNHX0dMT0JBTF9SRVFVRVNUDQogICAgIHN0cmlu ZyAgICAidGNwaXAtZm9yd2FyZCINCiAgICAgYm9vbGVhbiAgIHdhbnQgcmVw bHkNCiAgICAgc3RyaW5nICAgIGFkZHJlc3MgdG8gYmluZCAoZS5nLiAiMC4w LjAuMCIpDQogICAgIHVpbnQzMiAgICBwb3J0IG51bWJlciB0byBiaW5kDQoN CiAgICAgIGBBZGRyZXNzIHRvIGJpbmQnIGFuZCBgcG9ydCBudW1iZXIgdG8g YmluZCcgc3BlY2lmeSB0aGUgSVAgYWRkcmVzcw0KICAgICAgYW5kIHBvcnQg dG8gd2hpY2ggdGhlIHNvY2tldCB0byBiZSBsaXN0ZW5lZCBpcyBib3VuZC4g IFRoZSBhZGRyZXNzDQogICAgICBzaG91bGQgYmUgIjAuMC4wLjAiIGlmIGNv bm5lY3Rpb25zIGFyZSBhbGxvd2VkIGZyb20gYW55d2hlcmUuDQogICAgICAo Tm90ZSB0aGF0IHRoZSBjbGllbnQgY2FuIHN0aWxsIGZpbHRlciBjb25uZWN0 aW9ucyBiYXNlZCBvbg0KICAgICAgaW5mb3JtYXRpb24gcGFzc2VkIGluIHRo ZSBvcGVuIHJlcXVlc3QuKQ0KDQogICAgICBJbXBsZW1lbnRhdGlvbnMgc2hv dWxkIG9ubHkgYWxsb3cgZm9yd2FyZGluZyBwcml2aWxlZ2VkIHBvcnRzIGlm DQogICAgICB0aGUgdXNlciBoYXMgYmVlbiBhdXRoZW50aWNhdGVkIGFzIGEg cHJpdmlsZWdlZCB1c2VyLg0KDQogICAgICBDbGllbnQgaW1wbGVtZW50YXRp b25zIFNIT1VMRCByZWplY3QgdGhlc2UgbWVzc2FnZXM7IHRoZXkgYXJlDQog ICAgICBub3JtYWxseSBvbmx5IHNlbnQgYnkgdGhlIGNsaWVudC4NCg0KDQog ICAgICBJZiBhIGNsaWVudCBwYXNzZXMgMCBhcyBwb3J0IG51bWJlciB0byBi aW5kIGFuZCBoYXMgd2FudCByZXBseQ0KICAgICAgVFJVRSB0aGVuIHRoZSBz ZXJ2ZXIgYWxsb2NhdGVzIHRoZSBuZXh0IGF2YWlsYWJsZSB1bnByaXZpbGVn ZWQNCiAgICAgIHBvcnQgbnVtYmVyIGFuZCByZXBsaWVzIHdpdGggdGhlIGZv bGxvd2luZyBtZXNzYWdlLCBvdGhlcndpc2UNCiAgICAgIHRoZXJlIGlzIG5v IHJlc3BvbnNlIHNwZWNpZmljIGRhdGEuDQoNCg0KICAgICBieXRlICAgICBT U0hfTVNHX0dMT0JBTF9SRVFVRVNUX1NVQ0NFU1MNCiAgICAgdWludDMyICAg cG9ydCB0aGF0IHdhcyBib3VuZCBvbiB0aGUgc2VydmVyDQoNCiAgICAgIEEg cG9ydCBmb3J3YXJkaW5nIGNhbiBiZSBjYW5jZWxsZWQgd2l0aCB0aGUgZm9s bG93aW5nIG1lc3NhZ2UuDQogICAgICBOb3RlIHRoYXQgY2hhbm5lbCBvcGVu IHJlcXVlc3RzIG1heSBiZSByZWNlaXZlZCB1bnRpbCBhIHJlcGx5IHRvDQoN Cg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkg MTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxNF0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBTU0ggQ29ubmVjdGlvbiBQcm90b2NvbCAgICAg ICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgIHRoaXMgbWVzc2FnZSBp cyByZWNlaXZlZC4NCg0KICAgICBieXRlICAgICAgU1NIX01TR19HTE9CQUxf UkVRVUVTVA0KICAgICBzdHJpbmcgICAgImNhbmNlbC10Y3BpcC1mb3J3YXJk Ig0KICAgICBib29sZWFuICAgd2FudCByZXBseQ0KICAgICBzdHJpbmcgICAg YWRkcmVzc190b19iaW5kIChlLmcuICIxMjcuMC4wLjEiKQ0KICAgICB1aW50 MzIgICAgcG9ydCBudW1iZXIgdG8gYmluZA0KDQogICAgICBDbGllbnQgaW1w bGVtZW50YXRpb25zIFNIT1VMRCByZWplY3QgdGhlc2UgbWVzc2FnZXM7IHRo ZXkgYXJlDQogICAgICBub3JtYWxseSBvbmx5IHNlbnQgYnkgdGhlIGNsaWVu dC4NCg0KICAgNS4yIFRDUC9JUCBGb3J3YXJkaW5nIENoYW5uZWxzDQoNCiAg ICAgIFdoZW4gYSBjb25uZWN0aW9uIGNvbWVzIHRvIGEgcG9ydCBmb3Igd2hp Y2ggcmVtb3RlIGZvcndhcmRpbmcgaGFzDQogICAgICBiZWVuIHJlcXVlc3Rl ZCwgYSBjaGFubmVsIGlzIG9wZW5lZCB0byBmb3J3YXJkIHRoZSBwb3J0IHRv IHRoZQ0KICAgICAgb3RoZXIgc2lkZS4NCg0KICAgICBieXRlICAgICAgU1NI X01TR19DSEFOTkVMX09QRU4NCiAgICAgc3RyaW5nICAgICJmb3J3YXJkZWQt dGNwaXAiDQogICAgIHVpbnQzMiAgICBzZW5kZXIgY2hhbm5lbA0KICAgICB1 aW50MzIgICAgaW5pdGlhbCB3aW5kb3cgc2l6ZQ0KICAgICB1aW50MzIgICAg bWF4aW11bSBwYWNrZXQgc2l6ZQ0KICAgICBzdHJpbmcgICAgYWRkcmVzcyB0 aGF0IHdhcyBjb25uZWN0ZWQNCiAgICAgdWludDMyICAgIHBvcnQgdGhhdCB3 YXMgY29ubmVjdGVkDQogICAgIHN0cmluZyAgICBvcmlnaW5hdG9yIElQIGFk ZHJlc3MNCiAgICAgdWludDMyICAgIG9yaWdpbmF0b3IgcG9ydA0KDQogICAg ICBJbXBsZW1lbnRhdGlvbnMgTVVTVCByZWplY3QgdGhlc2UgbWVzc2FnZXMg dW5sZXNzIHRoZXkgaGF2ZQ0KICAgICAgcHJldmlvdXNseSByZXF1ZXN0ZWQg YSByZW1vdGUgVENQL0lQIHBvcnQgZm9yd2FyZGluZyB3aXRoIHRoZQ0KICAg ICAgZ2l2ZW4gcG9ydCBudW1iZXIuDQoNCiAgICAgIFdoZW4gYSBjb25uZWN0 aW9uIGNvbWVzIHRvIGEgbG9jYWxseSBmb3J3YXJkZWQgVENQL0lQIHBvcnQs IHRoZQ0KICAgICAgZm9sbG93aW5nIHBhY2tldCBpcyBzZW50IHRvIHRoZSBv dGhlciBzaWRlLiAgTm90ZSB0aGF0IHRoZXNlDQogICAgICBtZXNzYWdlcyBN QVkgYmUgc2VudCBhbHNvIGZvciBwb3J0cyBmb3Igd2hpY2ggbm8gZm9yd2Fy ZGluZyBoYXMNCiAgICAgIGJlZW4gZXhwbGljaXRseSByZXF1ZXN0ZWQuICBU aGUgcmVjZWl2aW5nIHNpZGUgbXVzdCBkZWNpZGUgd2hldGhlcg0KICAgICAg dG8gYWxsb3cgdGhlIGZvcndhcmRpbmcuDQoNCiAgICAgYnl0ZSAgICAgIFNT SF9NU0dfQ0hBTk5FTF9PUEVODQogICAgIHN0cmluZyAgICAiZGlyZWN0LXRj cGlwIg0KICAgICB1aW50MzIgICAgc2VuZGVyIGNoYW5uZWwNCiAgICAgdWlu dDMyICAgIGluaXRpYWwgd2luZG93IHNpemUNCiAgICAgdWludDMyICAgIG1h eGltdW0gcGFja2V0IHNpemUNCiAgICAgc3RyaW5nICAgIGhvc3QgdG8gY29u bmVjdA0KICAgICB1aW50MzIgICAgcG9ydCB0byBjb25uZWN0DQogICAgIHN0 cmluZyAgICBvcmlnaW5hdG9yIElQIGFkZHJlc3MNCiAgICAgdWludDMyICAg IG9yaWdpbmF0b3IgcG9ydA0KDQogICAgICBgSG9zdCB0byBjb25uZWN0JyBh bmQgYHBvcnQgdG8gY29ubmVjdCcgc3BlY2lmeSB0aGUgVENQL0lQIGhvc3QN Cg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFy eSAxMiwgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDE1XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgIFNTSCBDb25uZWN0aW9uIFByb3RvY29sICAg ICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KICAgICAgYW5kIHBvcnQgd2hl cmUgdGhlIHJlY2lwaWVudCBzaG91bGQgY29ubmVjdCB0aGUgY2hhbm5lbC4g IGBIb3N0IHRvDQogICAgICBjb25uZWN0JyBtYXkgYmUgZWl0aGVyIGEgZG9t YWluIG5hbWUgb3IgYSBudW1lcmljIElQIGFkZHJlc3MuDQoNCiAgICAgIGBP cmlnaW5hdG9yIElQIGFkZHJlc3MnIGlzIHRoZSBudW1lcmljIElQIGFkZHJl c3Mgb2YgdGhlIG1hY2hpbmUNCiAgICAgIHdoZXJlIHRoZSBjb25uZWN0aW9u IHJlcXVlc3QgY29tZXMgZnJvbSwgYW5kIGBvcmlnaW5hdG9yIHBvcnQnIGlz DQogICAgICB0aGUgcG9ydCBvbiB0aGUgb3JpZ2luYXRvciBob3N0IGZyb20g d2hlcmUgdGhlIGNvbm5lY3Rpb24gY2FtZQ0KICAgICAgZnJvbS4NCg0KICAg ICAgRm9yd2FyZGVkIFRDUC9JUCBjaGFubmVscyBhcmUgaW5kZXBlbmRlbnQg b2YgYW55IHNlc3Npb25zLCBhbmQNCiAgICAgIGNsb3NpbmcgYSBzZXNzaW9u IGNoYW5uZWwgZG9lcyBub3QgaW4gYW55IHdheSBpbXBseSB0aGF0IGZvcndh cmRlZA0KICAgICAgY29ubmVjdGlvbnMgc2hvdWxkIGJlIGNsb3NlZC4NCg0K ICAgICAgQ2xpZW50IGltcGxlbWVudGF0aW9ucyBTSE9VTEQgcmVqZWN0IGRp cmVjdCBUQ1AvSVAgb3BlbiByZXF1ZXN0cw0KICAgICAgZm9yIHNlY3VyaXR5 IHJlYXNvbnMuDQoNCiAgIDYuIEVuY29kaW5nIG9mIFRlcm1pbmFsIE1vZGVz DQoNCiAgICAgIFRlcm1pbmFsIG1vZGVzIChhcyBwYXNzZWQgaW4gYSBwdHkg cmVxdWVzdCkgYXJlIGVuY29kZWQgaW50byBhDQogICAgICBieXRlIHN0cmVh bS4gIEl0IGlzIGludGVuZGVkIHRoYXQgdGhlIGNvZGluZyBiZSBwb3J0YWJs ZSBhY3Jvc3MNCiAgICAgIGRpZmZlcmVudCBlbnZpcm9ubWVudHMuDQoNCiAg ICAgIFRoZSB0dHkgbW9kZSBkZXNjcmlwdGlvbiBpcyBhIHN0cmVhbSBvZiBi eXRlcy4gIFRoZSBzdHJlYW0NCiAgICAgIGNvbnNpc3RzIG9mIG9wY29kZS1h cmd1bWVudCBwYWlycy4gIEl0IGlzIHRlcm1pbmF0ZWQgYnkgb3Bjb2RlDQog ICAgICBUVFlfT1BfRU5EICgwKS4gIE9wY29kZXMgMSB0byAxNTkgaGF2ZSBh IHNpbmdsZSB1aW50MzIgYXJndW1lbnQuDQogICAgICBPcGNvZGVzIDE2MCB0 byAyNTUgYXJlIG5vdCB5ZXQgZGVmaW5lZCwgYW5kIGNhdXNlIHBhcnNpbmcg dG8gc3RvcA0KICAgICAgKHRoZXkgc2hvdWxkIG9ubHkgYmUgdXNlZCBhZnRl ciBhbnkgb3RoZXIgZGF0YSkuDQoNCiAgICAgIFRoZSBjbGllbnQgU0hPVUxE IHB1dCBpbiB0aGUgc3RyZWFtIGFueSBtb2RlcyBpdCBrbm93cyBhYm91dCwg YW5kDQogICAgICB0aGUgc2VydmVyIE1BWSBpZ25vcmUgYW55IG1vZGVzIGl0 IGRvZXMgbm90IGtub3cgYWJvdXQuICBUaGlzDQogICAgICBhbGxvd3Mgc29t ZSBkZWdyZWUgb2YgbWFjaGluZS1pbmRlcGVuZGVuY2UsIGF0IGxlYXN0IGJl dHdlZW4NCiAgICAgIHN5c3RlbXMgdGhhdCB1c2UgYSBQT1NJWC1saWtlIHR0 eSBpbnRlcmZhY2UuICBUaGUgcHJvdG9jb2wgY2FuDQogICAgICBzdXBwb3J0 IG90aGVyIHN5c3RlbXMgYXMgd2VsbCwgYnV0IHRoZSBjbGllbnQgbWF5IG5l ZWQgdG8gZmlsbA0KICAgICAgcmVhc29uYWJsZSB2YWx1ZXMgZm9yIGEgbnVt YmVyIG9mIHBhcmFtZXRlcnMgc28gdGhlIHNlcnZlciBwdHkNCiAgICAgIGdl dHMgc2V0IHRvIGEgcmVhc29uYWJsZSBtb2RlICh0aGUgc2VydmVyIGxlYXZl cyBhbGwgdW5zcGVjaWZpZWQNCiAgICAgIG1vZGUgYml0cyBpbiB0aGVpciBk ZWZhdWx0IHZhbHVlcywgYW5kIG9ubHkgc29tZSBjb21iaW5hdGlvbnMgbWFr ZQ0KICAgICAgc2Vuc2UpLg0KDQogICAgICBUaGUgZm9sbG93aW5nIG9wY29k ZXMgaGF2ZSBiZWVuIGRlZmluZWQuICBUaGUgbmFtaW5nIG9mIG9wY29kZXMN CiAgICAgIG1vc3RseSBmb2xsb3dzIHRoZSBQT1NJWCB0ZXJtaW5hbCBtb2Rl IGZsYWdzLg0KDQogICAwICAgVFRZX09QX0VORCAgICAgSW5kaWNhdGVzIGVu ZCBvZiBvcHRpb25zLg0KICAgMSAgIFZJTlRSICAgICAgICAgIEludGVycnVw dCBjaGFyYWN0ZXI7IDI1NSBpZiBub25lLiAgU2ltaWxhcmx5IGZvciB0aGUN CiAgICAgICAgICAgICAgICAgICAgICBvdGhlciBjaGFyYWN0ZXJzLiBOb3Qg YWxsIG9mIHRoZXNlIGNoYXJhY3RlcnMgYXJlDQogICAgICAgICAgICAgICAg ICAgICAgc3VwcG9ydGVkIG9uIGFsbCBzeXN0ZW1zLg0KICAgMiAgIFZRVUlU ICAgICAgICAgIFRoZSBxdWl0IGNoYXJhY3RlciAoc2VuZHMgU0lHUVVJVCBz aWduYWwgb24gUE9TSVgNCiAgICAgICAgICAgICAgICAgICAgICBzeXN0ZW1z KS4NCiAgIDMgICBWRVJBU0UgICAgICAgICBFcmFzZSB0aGUgY2hhcmFjdGVy IHRvIGxlZnQgb2YgdGhlIGN1cnNvci4NCiAgIDQgICBWS0lMTCAgICAgICAg ICBLaWxsIHRoZSBjdXJyZW50IGlucHV0IGxpbmUuDQoNCg0KDQpZbG9uZW4s IGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDQgICAg ICAgICAgICAgICBbUGFnZSAxNl0NCgwNCkludGVybmV0LURyYWZ0ICAgICAg ICAgICBTU0ggQ29ubmVjdGlvbiBQcm90b2NvbCAgICAgICAgICAgICAgIEp1 bHkgMjAwMw0KDQoNCiAgIDUgICBWRU9GICAgICAgICAgICBFbmQtb2YtZmls ZSBjaGFyYWN0ZXIgKHNlbmRzIEVPRiBmcm9tIHRoZSB0ZXJtaW5hbCkuDQog ICA2ICAgVkVPTCAgICAgICAgICAgRW5kLW9mLWxpbmUgY2hhcmFjdGVyIGlu IGFkZGl0aW9uIHRvIGNhcnJpYWdlIHJldHVybg0KICAgICAgICAgICAgICAg ICAgICAgIGFuZC9vciBsaW5lZmVlZC4NCiAgIDcgICBWRU9MMiAgICAgICAg ICBBZGRpdGlvbmFsIGVuZC1vZi1saW5lIGNoYXJhY3Rlci4NCiAgIDggICBW U1RBUlQgICAgICAgICBDb250aW51ZXMgcGF1c2VkIG91dHB1dCAobm9ybWFs bHkgY29udHJvbC1RKS4NCiAgIDkgICBWU1RPUCAgICAgICAgICBQYXVzZXMg b3V0cHV0IChub3JtYWxseSBjb250cm9sLVMpLg0KICAgMTAgIFZTVVNQICAg ICAgICAgIFN1c3BlbmRzIHRoZSBjdXJyZW50IHByb2dyYW0uDQogICAxMSAg VkRTVVNQICAgICAgICAgQW5vdGhlciBzdXNwZW5kIGNoYXJhY3Rlci4NCiAg IDEyICBWUkVQUklOVCAgICAgICBSZXByaW50cyB0aGUgY3VycmVudCBpbnB1 dCBsaW5lLg0KICAgMTMgIFZXRVJBU0UgICAgICAgIEVyYXNlcyBhIHdvcmQg bGVmdCBvZiBjdXJzb3IuDQogICAxNCAgVkxORVhUICAgICAgICAgRW50ZXIg dGhlIG5leHQgY2hhcmFjdGVyIHR5cGVkIGxpdGVyYWxseSwgZXZlbiBpZiBp dA0KICAgICAgICAgICAgICAgICAgICAgIGlzIGEgc3BlY2lhbCBjaGFyYWN0 ZXINCiAgIDE1ICBWRkxVU0ggICAgICAgICBDaGFyYWN0ZXIgdG8gZmx1c2gg b3V0cHV0Lg0KICAgMTYgIFZTV1RDSCAgICAgICAgIFN3aXRjaCB0byBhIGRp ZmZlcmVudCBzaGVsbCBsYXllci4NCiAgIDE3ICBWU1RBVFVTICAgICAgICBQ cmludHMgc3lzdGVtIHN0YXR1cyBsaW5lIChsb2FkLCBjb21tYW5kLCBwaWQg ZXRjKS4NCiAgIDE4ICBWRElTQ0FSRCAgICAgICBUb2dnbGVzIHRoZSBmbHVz aGluZyBvZiB0ZXJtaW5hbCBvdXRwdXQuDQogICAzMCAgSUdOUEFSICAgICAg ICAgVGhlIGlnbm9yZSBwYXJpdHkgZmxhZy4gIFRoZSBwYXJhbWV0ZXIgU0hP VUxEIGJlIDAgaWYNCiAgICAgICAgICAgICAgICAgICAgICB0aGlzIGZsYWcg aXMgRkFMU0Ugc2V0LCBhbmQgMSBpZiBpdCBpcyBUUlVFLg0KICAgMzEgIFBB Uk1SSyAgICAgICAgIE1hcmsgcGFyaXR5IGFuZCBmcmFtaW5nIGVycm9ycy4N CiAgIDMyICBJTlBDSyAgICAgICAgICBFbmFibGUgY2hlY2tpbmcgb2YgcGFy aXR5IGVycm9ycy4NCiAgIDMzICBJU1RSSVAgICAgICAgICBTdHJpcCA4dGgg Yml0IG9mZiBjaGFyYWN0ZXJzLg0KICAgMzQgIElOTENSICAgICAgICAgIE1h cCBOTCBpbnRvIENSIG9uIGlucHV0Lg0KICAgMzUgIElHTkNSICAgICAgICAg IElnbm9yZSBDUiBvbiBpbnB1dC4NCiAgIDM2ICBJQ1JOTCAgICAgICAgICBN YXAgQ1IgdG8gTkwgb24gaW5wdXQuDQogICAzNyAgSVVDTEMgICAgICAgICAg VHJhbnNsYXRlIHVwcGVyY2FzZSBjaGFyYWN0ZXJzIHRvIGxvd2VyY2FzZS4N CiAgIDM4ICBJWE9OICAgICAgICAgICBFbmFibGUgb3V0cHV0IGZsb3cgY29u dHJvbC4NCiAgIDM5ICBJWEFOWSAgICAgICAgICBBbnkgY2hhciB3aWxsIHJl c3RhcnQgYWZ0ZXIgc3RvcC4NCiAgIDQwICBJWE9GRiAgICAgICAgICBFbmFi bGUgaW5wdXQgZmxvdyBjb250cm9sLg0KICAgNDEgIElNQVhCRUwgICAgICAg IFJpbmcgYmVsbCBvbiBpbnB1dCBxdWV1ZSBmdWxsLg0KICAgNTAgIElTSUcg ICAgICAgICAgIEVuYWJsZSBzaWduYWxzIElOVFIsIFFVSVQsIFtEXVNVU1Au DQogICA1MSAgSUNBTk9OICAgICAgICAgQ2Fub25pY2FsaXplIGlucHV0IGxp bmVzLg0KICAgNTIgIFhDQVNFICAgICAgICAgIEVuYWJsZSBpbnB1dCBhbmQg b3V0cHV0IG9mIHVwcGVyY2FzZSBjaGFyYWN0ZXJzIGJ5DQogICAgICAgICAg ICAgICAgICAgICAgcHJlY2VkaW5nIHRoZWlyIGxvd2VyY2FzZSBlcXVpdmFs ZW50cyB3aXRoIGBcJy4NCiAgIDUzICBFQ0hPICAgICAgICAgICBFbmFibGUg ZWNob2luZy4NCiAgIDU0ICBFQ0hPRSAgICAgICAgICBWaXN1YWxseSBlcmFz ZSBjaGFycy4NCiAgIDU1ICBFQ0hPSyAgICAgICAgICBLaWxsIGNoYXJhY3Rl ciBkaXNjYXJkcyBjdXJyZW50IGxpbmUuDQogICA1NiAgRUNIT05MICAgICAg ICAgRWNobyBOTCBldmVuIGlmIEVDSE8gaXMgb2ZmLg0KICAgNTcgIE5PRkxT SCAgICAgICAgIERvbid0IGZsdXNoIGFmdGVyIGludGVycnVwdC4NCiAgIDU4 ICBUT1NUT1AgICAgICAgICBTdG9wIGJhY2tncm91bmQgam9icyBmcm9tIG91 dHB1dC4NCiAgIDU5ICBJRVhURU4gICAgICAgICBFbmFibGUgZXh0ZW5zaW9u cy4NCiAgIDYwICBFQ0hPQ1RMICAgICAgICBFY2hvIGNvbnRyb2wgY2hhcmFj dGVycyBhcyBeKENoYXIpLg0KICAgNjEgIEVDSE9LRSAgICAgICAgIFZpc3Vh bCBlcmFzZSBmb3IgbGluZSBraWxsLg0KICAgNjIgIFBFTkRJTiAgICAgICAg IFJldHlwZSBwZW5kaW5nIGlucHV0Lg0KICAgNzAgIE9QT1NUICAgICAgICAg IEVuYWJsZSBvdXRwdXQgcHJvY2Vzc2luZy4NCiAgIDcxICBPTENVQyAgICAg ICAgICBDb252ZXJ0IGxvd2VyY2FzZSB0byB1cHBlcmNhc2UuDQogICA3MiAg T05MQ1IgICAgICAgICAgTWFwIE5MIHRvIENSLU5MLg0KICAgNzMgIE9DUk5M ICAgICAgICAgIFRyYW5zbGF0ZSBjYXJyaWFnZSByZXR1cm4gdG8gbmV3bGlu ZSAob3V0cHV0KS4NCiAgIDc0ICBPTk9DUiAgICAgICAgICBUcmFuc2xhdGUg bmV3bGluZSB0byBjYXJyaWFnZSByZXR1cm4tbmV3bGluZQ0KDQoNCg0KWWxv bmVuLCBldC4gYWwuICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0 ICAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgICAgU1NIIENvbm5lY3Rpb24gUHJvdG9jb2wgICAgICAgICAgICAg ICBKdWx5IDIwMDMNCg0KDQogICAgICAgICAgICAgICAgICAgICAgKG91dHB1 dCkuDQogICA3NSAgT05MUkVUICAgICAgICAgTmV3bGluZSBwZXJmb3JtcyBh IGNhcnJpYWdlIHJldHVybiAob3V0cHV0KS4NCiAgIDkwICBDUzcgICAgICAg ICAgICA3IGJpdCBtb2RlLg0KICAgOTEgIENTOCAgICAgICAgICAgIDggYml0 IG1vZGUuDQogICA5MiAgUEFSRU5CICAgICAgICAgUGFyaXR5IGVuYWJsZS4N CiAgIDkzICBQQVJPREQgICAgICAgICBPZGQgcGFyaXR5LCBlbHNlIGV2ZW4u DQoNCiAgIDEyOCBUVFlfT1BfSVNQRUVEICBTcGVjaWZpZXMgdGhlIGlucHV0 IGJhdWQgcmF0ZSBpbiBiaXRzIHBlciBzZWNvbmQuDQogICAxMjkgVFRZX09Q X09TUEVFRCAgU3BlY2lmaWVzIHRoZSBvdXRwdXQgYmF1ZCByYXRlIGluIGJp dHMgcGVyIHNlY29uZC4NCg0KDQogICA3LiBTdW1tYXJ5IG9mIE1lc3NhZ2Ug TnVtYmVycw0KDQogICAgICNkZWZpbmUgU1NIX01TR19HTE9CQUxfUkVRVUVT VCAgICAgICAgICAgICAgICAgIDgwDQogICAgICNkZWZpbmUgU1NIX01TR19S RVFVRVNUX1NVQ0NFU1MgICAgICAgICAgICAgICAgIDgxDQogICAgICNkZWZp bmUgU1NIX01TR19SRVFVRVNUX0ZBSUxVUkUgICAgICAgICAgICAgICAgIDgy DQogICAgICNkZWZpbmUgU1NIX01TR19DSEFOTkVMX09QRU4gICAgICAgICAg ICAgICAgICAgIDkwDQogICAgICNkZWZpbmUgU1NIX01TR19DSEFOTkVMX09Q RU5fQ09ORklSTUFUSU9OICAgICAgIDkxDQogICAgICNkZWZpbmUgU1NIX01T R19DSEFOTkVMX09QRU5fRkFJTFVSRSAgICAgICAgICAgIDkyDQogICAgICNk ZWZpbmUgU1NIX01TR19DSEFOTkVMX1dJTkRPV19BREpVU1QgICAgICAgICAg IDkzDQogICAgICNkZWZpbmUgU1NIX01TR19DSEFOTkVMX0RBVEEgICAgICAg ICAgICAgICAgICAgIDk0DQogICAgICNkZWZpbmUgU1NIX01TR19DSEFOTkVM X0VYVEVOREVEX0RBVEEgICAgICAgICAgIDk1DQogICAgICNkZWZpbmUgU1NI X01TR19DSEFOTkVMX0VPRiAgICAgICAgICAgICAgICAgICAgIDk2DQogICAg ICNkZWZpbmUgU1NIX01TR19DSEFOTkVMX0NMT1NFICAgICAgICAgICAgICAg ICAgIDk3DQogICAgICNkZWZpbmUgU1NIX01TR19DSEFOTkVMX1JFUVVFU1Qg ICAgICAgICAgICAgICAgIDk4DQogICAgICNkZWZpbmUgU1NIX01TR19DSEFO TkVMX1NVQ0NFU1MgICAgICAgICAgICAgICAgIDk5DQogICAgICNkZWZpbmUg U1NIX01TR19DSEFOTkVMX0ZBSUxVUkUgICAgICAgICAgICAgICAgIDEwMA0K DQoNCiAgIDguIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCiAgICAgIFRo aXMgcHJvdG9jb2wgaXMgYXNzdW1lZCB0byBydW4gb24gdG9wIG9mIGEgc2Vj dXJlLCBhdXRoZW50aWNhdGVkDQogICAgICB0cmFuc3BvcnQuICBVc2VyIGF1 dGhlbnRpY2F0aW9uIGFuZCBwcm90ZWN0aW9uIGFnYWluc3QgbmV0d29yay0N CiAgICAgIGxldmVsIGF0dGFja3MgYXJlIGFzc3VtZWQgdG8gYmUgcHJvdmlk ZWQgYnkgdGhlIHVuZGVybHlpbmcNCiAgICAgIHByb3RvY29scy4NCg0KICAg ICAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdCBpbXBsZW1lbnRhdGlvbnMgZGlz YWJsZSBhbGwgdGhlIHBvdGVudGlhbGx5DQogICAgICBkYW5nZXJvdXMgZmVh dHVyZXMgKGUuZy4gIGFnZW50IGZvcndhcmRpbmcsIFgxMSBmb3J3YXJkaW5n LCBhbmQNCiAgICAgIFRDUC9JUCBmb3J3YXJkaW5nKSBpZiB0aGUgaG9zdCBr ZXkgaGFzIGNoYW5nZWQuDQoNCiAgICAgIEZ1bGwgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgZm9yIHRoaXMgcHJvdG9jb2wgYXJlIHByb3ZpZGVkIGluDQog ICAgICBTZWN0aW9uIDggb2YgW1NTSC1BUkNIXQ0KDQogICA5LiBJbnRlbGxl Y3R1YWwgUHJvcGVydHkNCg0KICAgICAgVGhlIElFVEYgdGFrZXMgbm8gcG9z aXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkN CiAgICAgIGludGVsbGVjdHVhbCBwcm9wZXJ0eSBvciBvdGhlciByaWdodHMg dGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvDQogICAgICBwZXJ0YWluIHRvIHRo ZSBpbXBsZW1lbnRhdGlvbiBvciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVz Y3JpYmVkDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVz IEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxOF0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgICBTU0ggQ29ubmVjdGlvbiBQcm90 b2NvbCAgICAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgIGluIHRo aXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5z ZSB1bmRlciBzdWNoDQogICAgICByaWdodHMgbWlnaHQgb3IgbWlnaHQgbm90 IGJlIGF2YWlsYWJsZTsgbmVpdGhlciBkb2VzIGl0IHJlcHJlc2VudA0KICAg ICAgdGhhdCBpdCBoYXMgbWFkZSBhbnkgZWZmb3J0IHRvIGlkZW50aWZ5IGFu eSBzdWNoIHJpZ2h0cy4NCiAgICAgIEluZm9ybWF0aW9uIG9uIHRoZSBJRVRG J3MgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRzIGluDQogICAg ICBzdGFuZGFyZHMtdHJhY2sgYW5kIHN0YW5kYXJkcy1yZWxhdGVkIGRvY3Vt ZW50YXRpb24gY2FuIGJlIGZvdW5kDQogICAgICBpbiBCQ1AtMTEuICBDb3Bp ZXMgb2YgY2xhaW1zIG9mIHJpZ2h0cyBtYWRlIGF2YWlsYWJsZSBmb3INCiAg ICAgIHB1YmxpY2F0aW9uIGFuZCBhbnkgYXNzdXJhbmNlcyBvZiBsaWNlbnNl cyB0byBiZSBtYWRlIGF2YWlsYWJsZSwNCiAgICAgIG9yIHRoZSByZXN1bHQg b2YgYW4gYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5z ZSBvcg0KICAgICAgcGVybWlzc2lvbiBmb3IgdGhlIHVzZSBvZiBzdWNoIHBy b3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRlcnMNCiAgICAgIG9yIHVz ZXJzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJv bSB0aGUgSUVURg0KICAgICAgU2VjcmV0YXJpYXQuDQoNCiAgICAgIFRoZSBJ RVRGIGhhcyBiZWVuIG5vdGlmaWVkIG9mIGludGVsbGVjdHVhbCBwcm9wZXJ0 eSByaWdodHMgY2xhaW1lZA0KICAgICAgaW4gcmVnYXJkIHRvIHNvbWUgb3Ig YWxsIG9mIHRoZSBzcGVjaWZpY2F0aW9uIGNvbnRhaW5lZCBpbiB0aGlzDQog ICAgICBkb2N1bWVudC4gIEZvciBtb3JlIGluZm9ybWF0aW9uIGNvbnN1bHQg dGhlIG9ubGluZSBsaXN0IG9mIGNsYWltZWQNCiAgICAgIHJpZ2h0cy4NCg0K ICAgMTAuIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24NCg0KICAgICAgVGhlIGN1 cnJlbnQgZG9jdW1lbnQgZWRpdG9yIGlzOiBEYXJyZW4uTW9mZmF0QFN1bi5D T00uICBDb21tZW50cw0KICAgICAgb24gdGhpcyBpbnRlcm5ldCBkcmFmdCBz aG91bGQgYmUgc2VudCB0byB0aGUgSUVURiBTRUNTSCB3b3JraW5nDQogICAg ICBncm91cCwgZGV0YWlscyBhdDogaHR0cDovL2lldGYub3JnL2h0bWwuY2hh cnRlcnMvc2Vjc2gtDQogICAgICBjaGFydGVyLmh0bWwNCg0KUmVmZXJlbmNl cw0KDQogICAgICBbUkZDMTc2Nl0gICAgICAgQWx2ZXN0cmFuZCwgSC4sICJU YWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2YNCiAgICAgICAgICAgICAg ICAgICAgICBMYW5ndWFnZXMiLCBSRkMgMTc2NiwgTWFyY2ggMTk5NS4NCg0K ICAgICAgW1JGQzE4ODRdICAgICAgIEhpbmRlbiwgUi4sIERlZXJpbmcsIFMu IGFuZCBFZGl0b3JzLCAiSVAgVmVyc2lvbiA2DQogICAgICAgICAgICAgICAg ICAgICAgQWRkcmVzc2luZyBBcmNoaXRlY3R1cmUiLCBSRkMgMTg4NCwgRGVj ZW1iZXIgMTk5NS4NCg0KICAgICAgW1JGQzIyNzldICAgICAgIFllcmdlYXUs IEYuLCAiVVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mDQogICAg ICAgICAgICAgICAgICAgICAgSVNPIDEwNjQ2IiwgUkZDIDIyNzksIEphbnVh cnkgMTk5OC4NCg0KICAgICAgW1NDSEVJRkxFUl0gICAgIFNjaGVpZmxlciwg Ui4sICJYIFdpbmRvdyBTeXN0ZW0gOiBUaGUgQ29tcGxldGUNCiAgICAgICAg ICAgICAgICAgICAgICBSZWZlcmVuY2UgdG8gWGxpYiwgWCBQcm90b2NvbCwg SWNjY20sIFhsZmQsIDNyZA0KICAgICAgICAgICAgICAgICAgICAgIGVkaXRp b24uIiwgRGlnaXRhbCBQcmVzcyBJU0JOIDE1NTU1ODA4ODIsIEZlYnVyYXJ5 DQogICAgICAgICAgICAgICAgICAgICAgMTk5Mi4NCg0KICAgICAgW1BPU0lY XSAgICAgICAgIElTTy9JRUMsIDk5NDUtMS4sICJJbmZvcm1hdGlvbiB0ZWNo bm9sb2d5IC0tDQogICAgICAgICAgICAgICAgICAgICAgUG9ydGFibGUgT3Bl cmF0aW5nIFN5c3RlbSBJbnRlcmZhY2UgIChQT1NJWCktUGFydA0KICAgICAg ICAgICAgICAgICAgICAgIDE6IFN5c3RlbSBBcHBsaWNhdGlvbiBQcm9ncmFt IEludGVyZmFjZSAoQVBJKSBDDQogICAgICAgICAgICAgICAgICAgICAgTGFu Z3VhZ2UiLCBBTlNJL0lFRSBTdGQgMTAwMy4xLCBKdWx5IDE5OTYuDQoNCiAg ICAgIFtTU0gtQVJDSF0gICAgICBZbG9uZW4sIFQuLCAiU1NIIFByb3RvY29s IEFyY2hpdGVjdHVyZSIsIEktRA0KICAgICAgICAgICAgICAgICAgICAgIGRy YWZ0LWlldGYtYXJjaGl0ZWN0dXJlLTE0LnR4dCwgSnVseSAyMDAzLg0KDQoN Cg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkg MTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxOV0NCgwNCkludGVybmV0 LURyYWZ0ICAgICAgICAgICBTU0ggQ29ubmVjdGlvbiBQcm90b2NvbCAgICAg ICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgIFtTU0gtVFJBTlNdICAg ICBZbG9uZW4sIFQuLCAiU1NIIFRyYW5zcG9ydCBMYXllciBQcm90b2NvbCIs IEktRA0KICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtdHJhbnNw b3J0LTE2LnR4dCwgSnVseSAyMDAzLg0KDQogICAgICBbU1NILVVTRVJBVVRI XSAgWWxvbmVuLCBULiwgIlNTSCBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCIs IEktRA0KICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtdXNlcmF1 dGgtMTcudHh0LCBKdWx5IDIwMDMuDQoNCiAgICAgIFtTU0gtQ09OTkVDVF0g ICBZbG9uZW4sIFQuLCAiU1NIIENvbm5lY3Rpb24gUHJvdG9jb2wiLCBJLUQg ZHJhZnQtDQogICAgICAgICAgICAgICAgICAgICAgaWV0Zi1jb25uZWN0LTE3 LnR4dCwgSnVseSAyMDAzLg0KDQogICAgICBbU1NILU5VTUJFUlNdICAgTGVo dGluZW4sIFMuIGFuZCBELiBNb2ZmYXQsICJTU0ggUHJvdG9jb2wgQXNzaWdu ZWQNCiAgICAgICAgICAgICAgICAgICAgICBOdW1iZXJzIiwgSS1EIGRyYWZ0 LWlldGYtc2Vjc2gtYXNzaWduZWRudW1iZXJzLQ0KICAgICAgICAgICAgICAg ICAgICAgIDAzLnR4dCwgSnVseSAyMDAzLg0KDQoNCkF1dGhvcnMnIEFkZHJl c3Nlcw0KDQogICBUYXR1IFlsb25lbg0KICAgU1NIIENvbW11bmljYXRpb25z IFNlY3VyaXR5IENvcnANCiAgIEZyZWRyaWtpbmthdHUgNDINCiAgIEhFTFNJ TktJICBGSU4tMDAxMDANCiAgIEZpbmxhbmQNCg0KICAgRU1haWw6IHlsb0Bz c2guY29tDQoNCg0KICAgVGVybyBLaXZpbmVuDQogICBTU0ggQ29tbXVuaWNh dGlvbnMgU2VjdXJpdHkgQ29ycA0KICAgRnJlZHJpa2lua2F0dSA0Mg0KICAg SEVMU0lOS0kgIEZJTi0wMDEwMA0KICAgRmlubGFuZA0KDQogICBFTWFpbDog a2l2aW5lbkBzc2guY29tDQoNCg0KICAgTWFya2t1LUp1aGFuaSBPLiBTYWFy aW5lbg0KICAgVW5pdmVyc2l0eSBvZiBKeXZhc2t5bGENCg0KDQogICBUaW1v IEouIFJpbm5lDQogICBTU0ggQ29tbXVuaWNhdGlvbnMgU2VjdXJpdHkgQ29y cA0KICAgRnJlZHJpa2lua2F0dSA0Mg0KICAgSEVMU0lOS0kgIEZJTi0wMDEw MA0KICAgRmlubGFuZA0KDQogICBFTWFpbDogdHJpQHNzaC5jb20NCg0KDQoN Cg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFy eSAxMiwgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDIwXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgIFNTSCBDb25uZWN0aW9uIFByb3RvY29sICAg ICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KICAgU2FtaSBMZWh0aW5lbg0K ICAgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5IENvcnANCiAgIEZyZWRy aWtpbmthdHUgNDINCiAgIEhFTFNJTktJICBGSU4tMDAxMDANCiAgIEZpbmxh bmQNCg0KICAgRU1haWw6IHNqbEBzc2guY29tDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAg W1BhZ2UgMjFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgU1NIIENv bm5lY3Rpb24gUHJvdG9jb2wgICAgICAgICAgICAgICBKdWx5IDIwMDMNCg0K DQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgICAgQ29weXJpZ2h0 IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuICBBbGwgUmlnaHRz IFJlc2VydmVkLg0KDQogICAgICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xh dGlvbnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkDQogICAg ICB0byBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVu dCBvbiBvciBvdGhlcndpc2UNCiAgICAgIGV4cGxhaW4gaXQgb3IgYXNzaXN0 IGluIGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsDQogICAg ICBjb3BpZWQsIHB1Ymxpc2hlZCBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xl IG9yIGluIHBhcnQsIHdpdGhvdXQNCiAgICAgIHJlc3RyaWN0aW9uIG9mIGFu eSBraW5kLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90 aWNlDQogICAgICBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9u IGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZQ0KICAgICAgd29ya3Mu ICBIb3dldmVyLCB0aGlzIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1v ZGlmaWVkIGluIGFueQ0KICAgICAgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5n IHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlDQog ICAgICBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2Fu aXphdGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQNCiAgICAgIGZvciB0aGUgcHVy cG9zZSBvZiBkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGlj aCBjYXNlIHRoZQ0KICAgICAgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBk ZWZpbmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMNCiAgICAgIHByb2Nl c3MgbXVzdCBiZSBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNs YXRlIGl0IGludG8NCiAgICAgIGxhbmd1YWdlcyBvdGhlciB0aGFuIEVuZ2xp c2guDQoNCiAgICAgIFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQg YWJvdmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3QNCiAgICAgIGJlIHJl dm9rZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3Nv cnMgb3IgYXNzaWducy4NCg0KICAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24N CiAgICAgIGFuICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJ RVRZIEFORCBUSEUgSU5URVJORVQNCiAgICAgIEVOR0lORUVSSU5HIFRBU0sg Rk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SDQog ICAgICBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFO WSBXQVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YNCiAgICAgIFRIRSBJTkZPUk1B VElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBB TlkgSU1QTElFRA0KICAgICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJ VFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCkFj a25vd2xlZGdlbWVudA0KDQogICAgICBGdW5kaW5nIGZvciB0aGUgUkZDIEVk aXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQog ICAgICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBp cmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAyMl0N CgwNCg== ---559023410-33463914-1058246184=:895-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 01:18:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04989 for ; Tue, 15 Jul 2003 01:18:09 -0400 (EDT) Received: (qmail 523 invoked by uid 605); 15 Jul 2003 05:18:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 507 invoked from network); 15 Jul 2003 05:18:01 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 Jul 2003 05:18:01 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6F5HU2a000993; Mon, 14 Jul 2003 22:17:30 -0700 (PDT) Received: from islay (vpn-129-150-17-202.SFBay.Sun.COM [129.150.17.202]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6F5HOtf189288; Mon, 14 Jul 2003 22:17:24 -0700 (PDT) Date: Mon, 14 Jul 2003 22:17:46 -0700 (PDT) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-transport-16.txt Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-342241519-1058246266=:895" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-342241519-1058246266=:895 Content-Type: TEXT/PLAIN; charset=US-ASCII -- Darren J Moffat ---559023410-342241519-1058246266=:895 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-ietf-secsh-transport-16.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-ietf-secsh-transport-16.txt" Content-Transfer-Encoding: BASE64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFQuIFlsb25lbg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBULiBLaXZpbmVuDQpFeHBpcmVzOiBKYW51YXJ5IDEyLCAyMDA0ICAg ICAgICAgICAgICAgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5IENvcnAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNLiBTYWFyaW5lbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVuaXZlcnNpdHkg b2YgSnl2YXNreWxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gUmlubmUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTLiBMZWh0aW5lbg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFNTSCBDb21tdW5pY2F0aW9ucyBTZWN1 cml0eSBDb3JwDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEp1bHkgMTQsIDIwMDMNCg0KDQog ICAgICAgICAgICAgICAgICAgICAgU1NIIFRyYW5zcG9ydCBMYXllciBQcm90 b2NvbA0KICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtc2Vjc2gtdHJh bnNwb3J0LTE2LnR4dA0KDQpTdGF0dXMgb2YgdGhpcyBNZW1vDQoNCiAgICAg IFRoaXMgZG9jdW1lbnQgaXMgYW4gSW50ZXJuZXQtRHJhZnQgYW5kIGlzIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aA0KICAgICAgYWxsIHByb3Zpc2lvbnMg b2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2Lg0KDQogICAgICBJbnRlcm5ldC1E cmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBF bmdpbmVlcmluZw0KICAgICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVh cywgYW5kIGl0cyB3b3JraW5nIGdyb3Vwcy4gIE5vdGUgdGhhdA0KICAgICAg b3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtDQogICAgICBEcmFmdHMuDQoNCiAgICAgIElu dGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4DQogICAgICBtb250aHMgYW5kIG1heSBiZSB1cGRh dGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyDQogICAgICBk b2N1bWVudHMgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMNCiAgICAgIGFzIHJlZmVyZW5jZSBtYXRl cmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbg0K ICAgICAgcHJvZ3Jlc3MuIg0KDQogICAgICBUaGUgbGlzdCBvZiBjdXJyZW50 IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgICAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0K ICAgICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj dG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9zaGFkb3cuaHRtbC4NCg0KICAgICAgVGhpcyBJbnRlcm5ldC1E cmFmdCB3aWxsIGV4cGlyZSBvbiBKYW51YXJ5IDEyLCAyMDA0Lg0KDQpDb3B5 cmlnaHQgTm90aWNlDQoNCiAgICAgIENvcHlyaWdodCAoQykgVGhlIEludGVy bmV0IFNvY2lldHkgKDIwMDMpLiAgQWxsIFJpZ2h0cyBSZXNlcnZlZC4NCg0K QWJzdHJhY3QNCg0KICAgICAgU1NIIGlzIGEgcHJvdG9jb2wgZm9yIHNlY3Vy ZSByZW1vdGUgbG9naW4gYW5kIG90aGVyIHNlY3VyZSBuZXR3b3JrDQogICAg ICBzZXJ2aWNlcyBvdmVyIGFuIGluc2VjdXJlIG5ldHdvcmsuDQoNCiAgICAg IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBTU0ggdHJhbnNwb3J0IGxh eWVyIHByb3RvY29sIHdoaWNoDQogICAgICB0eXBpY2FsbHkgcnVucyBvbiB0 b3Agb2YgVENQL0lQLiAgVGhlIHByb3RvY29sIGNhbiBiZSB1c2VkIGFzIGEN Cg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFy eSAxMiwgMjAwNCAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgIFNTSCBUcmFuc3BvcnQgTGF5ZXIgUHJvdG9jb2wg ICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KICAgICAgYmFzaXMgZm9yIGEg bnVtYmVyIG9mIHNlY3VyZSBuZXR3b3JrIHNlcnZpY2VzLiAgSXQgcHJvdmlk ZXMgc3Ryb25nDQogICAgICBlbmNyeXB0aW9uLCBzZXJ2ZXIgYXV0aGVudGlj YXRpb24sIGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4gIEl0DQogICAgICBt YXkgYWxzbyBwcm92aWRlIGNvbXByZXNzaW9uLg0KDQogICAgICBLZXkgZXhj aGFuZ2UgbWV0aG9kLCBwdWJsaWMga2V5IGFsZ29yaXRobSwgc3ltbWV0cmlj IGVuY3J5cHRpb24NCiAgICAgIGFsZ29yaXRobSwgbWVzc2FnZSBhdXRoZW50 aWNhdGlvbiBhbGdvcml0aG0sIGFuZCBoYXNoIGFsZ29yaXRobQ0KICAgICAg YXJlIGFsbCBuZWdvdGlhdGVkLg0KDQogICAgICBUaGlzIGRvY3VtZW50IGFs c28gZGVzY3JpYmVzIHRoZSBEaWZmaWUtSGVsbG1hbiBrZXkgZXhjaGFuZ2UN CiAgICAgIG1ldGhvZCBhbmQgdGhlIG1pbmltYWwgc2V0IG9mIGFsZ29yaXRo bXMgdGhhdCBhcmUgbmVlZGVkIHRvDQogICAgICBpbXBsZW1lbnQgdGhlIFNT SCB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2wuDQoNClRhYmxlIG9mIENvbnRl bnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMi4gIENv bnZlbnRpb25zIFVzZWQgaW4gVGhpcyBEb2N1bWVudCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICA0DQogICAzLiAgQ29ubmVjdGlvbiBTZXR1cCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQNCiAgIDMuMSBVc2Ugb3ZlciBUQ1AvSVAgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNA0KICAgMy4yIFByb3Rv Y29sIFZlcnNpb24gRXhjaGFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICA0DQogICAzLjMgQ29tcGF0aWJpbGl0eSBXaXRoIE9s ZCBTU0ggVmVyc2lvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDUN CiAgIDMuNCBPbGQgQ2xpZW50LCBOZXcgU2VydmVyIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgMy41IE5ldyBDbGll bnQsIE9sZCBTZXJ2ZXIgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA2DQogICA0LiAgQmluYXJ5IFBhY2tldCBQcm90b2NvbCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAg IDQuMSBNYXhpbXVtIFBhY2tldCBMZW5ndGggIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgNw0KICAgNC4yIENvbXByZXNzaW9u ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICA3DQogICA0LjMgRW5jcnlwdGlvbiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIDQu NCBEYXRhIEludGVncml0eSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgNC41IEtleSBFeGNoYW5nZSBN ZXRob2RzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIDExDQogICA0LjYgUHVibGljIEtleSBBbGdvcml0aG1zICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTENCiAgIDUuICBL ZXkgRXhjaGFuZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgNS4xIEFsZ29yaXRobSBOZWdvdGlh dGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IDE0DQogICA1LjIgT3V0cHV0IGZyb20gS2V5IEV4Y2hhbmdlIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTcNCiAgIDUuMyBUYWtp bmcgS2V5cyBJbnRvIFVzZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxOA0KICAgNi4gIERpZmZpZS1IZWxsbWFuIEtleSBF eGNoYW5nZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE5 DQogICA2LjEgZGlmZmllLWhlbGxtYW4tZ3JvdXAxLXNoYTEgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjANCiAgIDcuICBLZXkgUmUt RXhjaGFuZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAyMQ0KICAgOC4gIFNlcnZpY2UgUmVxdWVzdCAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIyDQog ICA5LiAgQWRkaXRpb25hbCBNZXNzYWdlcyAgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINCiAgIDkuMSBEaXNjb25uZWN0 aW9uIE1lc3NhZ2UgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAyMw0KICAgOS4yIElnbm9yZWQgRGF0YSBNZXNzYWdlIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIzDQogICA5 LjMgRGVidWcgTWVzc2FnZSAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gMjQNCiAgIDkuNCBSZXNlcnZlZCBNZXNz YWdlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAyNA0KICAgMTAuIFN1bW1hcnkgb2YgTWVzc2FnZSBOdW1iZXJzIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI0DQogICAxMS4g U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gMjUNCiAgIDEyLiBJbnRlbGxlY3R1YWwgUHJv cGVydHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyNQ0KICAgMTMuIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDI1DQogICAgICAgUmVm ZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gMjYNCiAgICAgICBBdXRob3JzJyBBZGRyZXNzZXMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAy Nw0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgRXhwaXJlcyBKYW51 YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJbnRl cm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5zcG9ydCBMYXllciBQcm90b2Nv bCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQogICAgICAgRnVsbCBDb3B5 cmlnaHQgU3RhdGVtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gMjkNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAg ICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICAgW1Bh Z2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBTU0ggVHJhbnNwb3J0 IExheWVyIFByb3RvY29sICAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAg IDEuIEludHJvZHVjdGlvbg0KDQogICAgICBUaGUgU1NIIHRyYW5zcG9ydCBs YXllciBpcyBhIHNlY3VyZSBsb3cgbGV2ZWwgdHJhbnNwb3J0IHByb3RvY29s Lg0KICAgICAgSXQgcHJvdmlkZXMgc3Ryb25nIGVuY3J5cHRpb24sIGNyeXB0 b2dyYXBoaWMgaG9zdCBhdXRoZW50aWNhdGlvbiwNCiAgICAgIGFuZCBpbnRl Z3JpdHkgcHJvdGVjdGlvbi4NCg0KICAgICAgQXV0aGVudGljYXRpb24gaW4g dGhpcyBwcm90b2NvbCBsZXZlbCBpcyBob3N0LWJhc2VkOyB0aGlzIHByb3Rv Y29sDQogICAgICBkb2VzIG5vdCBwZXJmb3JtIHVzZXIgYXV0aGVudGljYXRp b24uICBBIGhpZ2hlciBsZXZlbCBwcm90b2NvbCBmb3INCiAgICAgIHVzZXIg YXV0aGVudGljYXRpb24gY2FuIGJlIGRlc2lnbmVkIG9uIHRvcCBvZiB0aGlz IHByb3RvY29sLg0KDQogICAgICBUaGUgcHJvdG9jb2wgaGFzIGJlZW4gZGVz aWduZWQgdG8gYmUgc2ltcGxlLCBmbGV4aWJsZSwgdG8gYWxsb3cNCiAgICAg IHBhcmFtZXRlciBuZWdvdGlhdGlvbiwgYW5kIHRvIG1pbmltaXplIHRoZSBu dW1iZXIgb2Ygcm91bmQtdHJpcHMuDQogICAgICBLZXkgZXhjaGFuZ2UgbWV0 aG9kLCBwdWJsaWMga2V5IGFsZ29yaXRobSwgc3ltbWV0cmljIGVuY3J5cHRp b24NCiAgICAgIGFsZ29yaXRobSwgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBh bGdvcml0aG0sIGFuZCBoYXNoIGFsZ29yaXRobQ0KICAgICAgYXJlIGFsbCBu ZWdvdGlhdGVkLiAgSXQgaXMgZXhwZWN0ZWQgdGhhdCBpbiBtb3N0IGVudmly b25tZW50cywNCiAgICAgIG9ubHkgMiByb3VuZC10cmlwcyB3aWxsIGJlIG5l ZWRlZCBmb3IgZnVsbCBrZXkgZXhjaGFuZ2UsIHNlcnZlcg0KICAgICAgYXV0 aGVudGljYXRpb24sIHNlcnZpY2UgcmVxdWVzdCwgYW5kIGFjY2VwdGFuY2Ug bm90aWZpY2F0aW9uIG9mDQogICAgICBzZXJ2aWNlIHJlcXVlc3QuICBUaGUg d29yc3QgY2FzZSBpcyAzIHJvdW5kLXRyaXBzLg0KDQogICAyLiBDb252ZW50 aW9ucyBVc2VkIGluIFRoaXMgRG9jdW1lbnQNCg0KICAgICAgVGhlIGtleXdv cmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIT1VMRCIs ICJTSE9VTEQNCiAgICAgIE5PVCIsIGFuZCAiTUFZIiB0aGF0IGFwcGVhciBp biB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZA0KICAgICAg YXMgZGVzY3JpYmVkIGluIFtSRkMyMTE5XQ0KDQogICAgICBUaGUgdXNlZCBk YXRhIHR5cGVzIGFuZCB0ZXJtaW5vbG9neSBhcmUgc3BlY2lmaWVkIGluIHRo ZQ0KICAgICAgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IFtTU0gtQVJDSF0NCg0K ICAgICAgVGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBhbHNvIGRpc2N1c3Nl cyB0aGUgYWxnb3JpdGhtIG5hbWluZw0KICAgICAgY29udmVudGlvbnMgdGhh dCBNVVNUIGJlIHVzZWQgd2l0aCB0aGUgU1NIIHByb3RvY29scy4NCg0KICAg My4gQ29ubmVjdGlvbiBTZXR1cA0KDQogICAgICBTU0ggd29ya3Mgb3ZlciBh bnkgOC1iaXQgY2xlYW4sIGJpbmFyeS10cmFuc3BhcmVudCB0cmFuc3BvcnQu ICBUaGUNCiAgICAgIHVuZGVybHlpbmcgdHJhbnNwb3J0IFNIT1VMRCBwcm90 ZWN0IGFnYWluc3QgdHJhbnNtaXNzaW9uIGVycm9ycyBhcw0KICAgICAgc3Vj aCBlcnJvcnMgY2F1c2UgdGhlIFNTSCBjb25uZWN0aW9uIHRvIHRlcm1pbmF0 ZS4NCg0KICAgICAgVGhlIGNsaWVudCBpbml0aWF0ZXMgdGhlIGNvbm5lY3Rp b24uDQoNCiAgIDMuMSBVc2Ugb3ZlciBUQ1AvSVANCg0KICAgICAgV2hlbiB1 c2VkIG92ZXIgVENQL0lQLCB0aGUgc2VydmVyIG5vcm1hbGx5IGxpc3RlbnMg Zm9yIGNvbm5lY3Rpb25zDQogICAgICBvbiBwb3J0IDIyLiAgVGhpcyBwb3J0 IG51bWJlciBoYXMgYmVlbiByZWdpc3RlcmVkIHdpdGggdGhlIElBTkEsDQog ICAgICBhbmQgaGFzIGJlZW4gb2ZmaWNpYWxseSBhc3NpZ25lZCBmb3IgU1NI Lg0KDQogICAzLjIgUHJvdG9jb2wgVmVyc2lvbiBFeGNoYW5nZQ0KDQogICAg ICBXaGVuIHRoZSBjb25uZWN0aW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkLCBi b3RoIHNpZGVzIE1VU1Qgc2VuZCBhbg0KDQoNCg0KWWxvbmVuLCBldC4gYWwu ICAgICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAg ICAgIFtQYWdlIDRdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRy YW5zcG9ydCBMYXllciBQcm90b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMN Cg0KDQogICAgICBpZGVudGlmaWNhdGlvbiBzdHJpbmcgb2YgdGhlIGZvcm0g IlNTSC1wcm90b3ZlcnNpb24tDQogICAgICBzb2Z0d2FyZXZlcnNpb24gY29t bWVudHMiLCBmb2xsb3dlZCBieSBjYXJyaWFnZSByZXR1cm4gYW5kIG5ld2xp bmUNCiAgICAgIGNoYXJhY3RlcnMgKEFTQ0lJIDEzIGFuZCAxMCwgcmVzcGVj dGl2ZWx5KS4gIEJvdGggc2lkZXMgTVVTVCBiZQ0KICAgICAgYWJsZSB0byBw cm9jZXNzIGlkZW50aWZpY2F0aW9uIHN0cmluZ3Mgd2l0aG91dCBjYXJyaWFn ZSByZXR1cm4NCiAgICAgIGNoYXJhY3Rlci4gIE5vIG51bGwgY2hhcmFjdGVy IGlzIHNlbnQuICBUaGUgbWF4aW11bSBsZW5ndGggb2YgdGhlDQogICAgICBz dHJpbmcgaXMgMjU1IGNoYXJhY3RlcnMsIGluY2x1ZGluZyB0aGUgY2Fycmlh Z2UgcmV0dXJuIGFuZA0KICAgICAgbmV3bGluZS4NCg0KICAgICAgVGhlIHBh cnQgb2YgdGhlIGlkZW50aWZpY2F0aW9uIHN0cmluZyBwcmVjZWRpbmcgY2Fy cmlhZ2UgcmV0dXJuDQogICAgICBhbmQgbmV3bGluZSBpcyB1c2VkIGluIHRo ZSBEaWZmaWUtSGVsbG1hbiBrZXkgZXhjaGFuZ2UgKHNlZQ0KICAgICAgU2Vj dGlvbiBTZWN0aW9uIDYpLg0KDQogICAgICBUaGUgc2VydmVyIE1BWSBzZW5k IG90aGVyIGxpbmVzIG9mIGRhdGEgYmVmb3JlIHNlbmRpbmcgdGhlIHZlcnNp b24NCiAgICAgIHN0cmluZy4gIEVhY2ggbGluZSBTSE9VTEQgYmUgdGVybWlu YXRlZCBieSBhIGNhcnJpYWdlIHJldHVybiBhbmQNCiAgICAgIG5ld2xpbmUu ICBTdWNoIGxpbmVzIE1VU1QgTk9UIGJlZ2luIHdpdGggIlNTSC0iLCBhbmQg U0hPVUxEIGJlDQogICAgICBlbmNvZGVkIGluIElTTy0xMDY0NiBVVEYtOCBb UkZDMjI3OV0gKGxhbmd1YWdlIGlzIG5vdCBzcGVjaWZpZWQpLg0KICAgICAg Q2xpZW50cyBNVVNUIGJlIGFibGUgdG8gcHJvY2VzcyBzdWNoIGxpbmVzOyB0 aGV5IE1BWSBiZSBzaWxlbnRseQ0KICAgICAgaWdub3JlZCwgb3IgTUFZIGJl IGRpc3BsYXllZCB0byB0aGUgY2xpZW50IHVzZXI7IGlmIHRoZXkgYXJlDQog ICAgICBkaXNwbGF5ZWQsIGNvbnRyb2wgY2hhcmFjdGVyIGZpbHRlcmluZyBk aXNjdXNzZWQgaW4gW1NTSC1BUkNIXQ0KICAgICAgU0hPVUxEIGJlIHVzZWQu ICBUaGUgcHJpbWFyeSB1c2Ugb2YgdGhpcyBmZWF0dXJlIGlzIHRvIGFsbG93 IFRDUC0NCiAgICAgIHdyYXBwZXJzIHRvIGRpc3BsYXkgYW4gZXJyb3IgbWVz c2FnZSBiZWZvcmUgZGlzY29ubmVjdGluZy4NCg0KICAgICAgVmVyc2lvbiBz dHJpbmdzIE1VU1QgY29uc2lzdCBvZiBwcmludGFibGUgVVMtQVNDSUkgY2hh cmFjdGVycywgbm90DQogICAgICBpbmNsdWRpbmcgd2hpdGVzcGFjZXMgb3Ig YSBtaW51cyBzaWduICgtKS4gIFRoZSB2ZXJzaW9uIHN0cmluZyBpcw0KICAg ICAgcHJpbWFyaWx5IHVzZWQgdG8gdHJpZ2dlciBjb21wYXRpYmlsaXR5IGV4 dGVuc2lvbnMgYW5kIHRvIGluZGljYXRlDQogICAgICB0aGUgY2FwYWJpbGl0 aWVzIG9mIGFuIGltcGxlbWVudGF0aW9uLiAgVGhlIGNvbW1lbnQgc3RyaW5n IHNob3VsZA0KICAgICAgY29udGFpbiBhZGRpdGlvbmFsIGluZm9ybWF0aW9u IHRoYXQgbWlnaHQgYmUgdXNlZnVsIGluIHNvbHZpbmcNCiAgICAgIHVzZXIg cHJvYmxlbXMuDQoNCiAgICAgIFRoZSBwcm90b2NvbCB2ZXJzaW9uIGRlc2Ny aWJlZCBpbiB0aGlzIGRvY3VtZW50IGlzIDIuMC4NCg0KICAgICAgS2V5IGV4 Y2hhbmdlIHdpbGwgYmVnaW4gaW1tZWRpYXRlbHkgYWZ0ZXIgc2VuZGluZyB0 aGlzIGlkZW50aWZpZXIuDQogICAgICBBbGwgcGFja2V0cyBmb2xsb3dpbmcg dGhlIGlkZW50aWZpY2F0aW9uIHN0cmluZyBTSEFMTCB1c2UgdGhlDQogICAg ICBiaW5hcnkgcGFja2V0IHByb3RvY29sLCB0byBiZSBkZXNjcmliZWQgYmVs b3cuDQoNCiAgIDMuMyBDb21wYXRpYmlsaXR5IFdpdGggT2xkIFNTSCBWZXJz aW9ucw0KDQogICAgICBEdXJpbmcgdGhlIHRyYW5zaXRpb24gcGVyaW9kLCBp dCBpcyBpbXBvcnRhbnQgdG8gYmUgYWJsZSB0byB3b3JrDQogICAgICBpbiBh IHdheSB0aGF0IGlzIGNvbXBhdGlibGUgd2l0aCB0aGUgaW5zdGFsbGVkIFNT SCBjbGllbnRzIGFuZA0KICAgICAgc2VydmVycyB0aGF0IHVzZSBhbiBvbGRl ciB2ZXJzaW9uIG9mIHRoZSBwcm90b2NvbC4gIEluZm9ybWF0aW9uIGluDQog ICAgICB0aGlzIHNlY3Rpb24gaXMgb25seSByZWxldmFudCBmb3IgaW1wbGVt ZW50YXRpb25zIHN1cHBvcnRpbmcNCiAgICAgIGNvbXBhdGliaWxpdHkgd2l0 aCBTU0ggdmVyc2lvbnMgMS54Lg0KDQogICAzLjQgT2xkIENsaWVudCwgTmV3 IFNlcnZlcg0KDQogICAgICBTZXJ2ZXIgaW1wbGVtZW50YXRpb25zIE1BWSBz dXBwb3J0IGEgY29uZmlndXJhYmxlICJjb21wYXRpYmlsaXR5Ig0KICAgICAg ZmxhZyB0aGF0IGVuYWJsZXMgY29tcGF0aWJpbGl0eSB3aXRoIG9sZCB2ZXJz aW9ucy4gIFdoZW4gdGhpcyBmbGFnDQogICAgICBpcyBvbiwgdGhlIHNlcnZl ciBTSE9VTEQgaWRlbnRpZnkgaXRzIHByb3RvY29sIHZlcnNpb24gYXMgIjEu OTkiLg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5zcG9ydCBMYXllciBQcm90 b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQogICAgICBDbGllbnRz IHVzaW5nIHByb3RvY29sIDIuMCBNVVNUIGJlIGFibGUgdG8gaWRlbnRpZnkg dGhpcyBhcw0KICAgICAgaWRlbnRpY2FsIHRvICIyLjAiLiAgSW4gdGhpcyBt b2RlIHRoZSBzZXJ2ZXIgU0hPVUxEIE5PVCBzZW5kIHRoZQ0KICAgICAgY2Fy cmlhZ2UgcmV0dXJuIGNoYXJhY3RlciAoQVNDSUkgMTMpIGFmdGVyIHRoZSB2 ZXJzaW9uDQogICAgICBpZGVudGlmaWNhdGlvbiBzdHJpbmcuDQoNCiAgICAg IEluIHRoZSBjb21wYXRpYmlsaXR5IG1vZGUgdGhlIHNlcnZlciBTSE9VTEQg Tk9UIHNlbmQgYW55IGZ1cnRoZXINCiAgICAgIGRhdGEgYWZ0ZXIgaXRzIGlu aXRpYWxpemF0aW9uIHN0cmluZyB1bnRpbCBpdCBoYXMgcmVjZWl2ZWQgYW4N CiAgICAgIGlkZW50aWZpY2F0aW9uIHN0cmluZyBmcm9tIHRoZSBjbGllbnQu ICBUaGUgc2VydmVyIGNhbiB0aGVuDQogICAgICBkZXRlcm1pbmUgd2hldGhl ciB0aGUgY2xpZW50IGlzIHVzaW5nIGFuIG9sZCBwcm90b2NvbCwgYW5kIGNh bg0KICAgICAgcmV2ZXJ0IHRvIHRoZSBvbGQgcHJvdG9jb2wgaWYgcmVxdWly ZWQuICBJbiB0aGUgY29tcGF0aWJpbGl0eQ0KICAgICAgbW9kZSwgdGhlIHNl cnZlciBNVVNUIE5PVCBzZW5kIGFkZGl0aW9uYWwgZGF0YSBiZWZvcmUgdGhl IHZlcnNpb24NCiAgICAgIHN0cmluZy4NCg0KICAgICAgV2hlbiBjb21wYXRp YmlsaXR5IHdpdGggb2xkIGNsaWVudHMgaXMgbm90IG5lZWRlZCwgdGhlIHNl cnZlciBNQVkNCiAgICAgIHNlbmQgaXRzIGluaXRpYWwga2V5IGV4Y2hhbmdl IGRhdGEgaW1tZWRpYXRlbHkgYWZ0ZXIgdGhlDQogICAgICBpZGVudGlmaWNh dGlvbiBzdHJpbmcuDQoNCiAgIDMuNSBOZXcgQ2xpZW50LCBPbGQgU2VydmVy DQoNCiAgICAgIFNpbmNlIHRoZSBuZXcgY2xpZW50IE1BWSBpbW1lZGlhdGVs eSBzZW5kIGFkZGl0aW9uYWwgZGF0YSBhZnRlcg0KICAgICAgaXRzIGlkZW50 aWZpY2F0aW9uIHN0cmluZyAoYmVmb3JlIHJlY2VpdmluZyBzZXJ2ZXIncw0K ICAgICAgaWRlbnRpZmljYXRpb24pLCB0aGUgb2xkIHByb3RvY29sIG1heSBh bHJlYWR5IGhhdmUgYmVlbiBjb3JydXB0ZWQNCiAgICAgIHdoZW4gdGhlIGNs aWVudCBsZWFybnMgdGhhdCB0aGUgc2VydmVyIGlzIG9sZC4gIFdoZW4gdGhp cyBoYXBwZW5zLA0KICAgICAgdGhlIGNsaWVudCBTSE9VTEQgY2xvc2UgdGhl IGNvbm5lY3Rpb24gdG8gdGhlIHNlcnZlciwgYW5kDQogICAgICByZWNvbm5l Y3QgdXNpbmcgdGhlIG9sZCBwcm90b2NvbC4NCg0KICAgNC4gQmluYXJ5IFBh Y2tldCBQcm90b2NvbA0KDQogICBFYWNoIHBhY2tldCBpcyBpbiB0aGUgZm9s bG93aW5nIGZvcm1hdDoNCg0KICAgICB1aW50MzIgICAgcGFja2V0X2xlbmd0 aA0KICAgICBieXRlICAgICAgcGFkZGluZ19sZW5ndGgNCiAgICAgYnl0ZVtu MV0gIHBheWxvYWQ7IG4xID0gcGFja2V0X2xlbmd0aCAtIHBhZGRpbmdfbGVu Z3RoIC0gMQ0KICAgICBieXRlW24yXSAgcmFuZG9tIHBhZGRpbmc7IG4yID0g cGFkZGluZ19sZW5ndGgNCiAgICAgYnl0ZVttXSAgIG1hYyAobWVzc2FnZSBh dXRoZW50aWNhdGlvbiBjb2RlKTsgbSA9IG1hY19sZW5ndGgNCg0KICAgICAg ICAgcGFja2V0X2xlbmd0aA0KICAgICAgICAgICAgVGhlIGxlbmd0aCBvZiB0 aGUgcGFja2V0IChieXRlcyksIG5vdCBpbmNsdWRpbmcgTUFDIG9yIHRoZQ0K ICAgICAgICAgICAgcGFja2V0X2xlbmd0aCBmaWVsZCBpdHNlbGYuDQoNCiAg ICAgICAgIHBhZGRpbmdfbGVuZ3RoDQogICAgICAgICAgICBMZW5ndGggb2Yg cGFkZGluZyAoYnl0ZXMpLg0KDQogICAgICAgICBwYXlsb2FkDQogICAgICAg ICAgICBUaGUgdXNlZnVsIGNvbnRlbnRzIG9mIHRoZSBwYWNrZXQuICBJZiBj b21wcmVzc2lvbiBoYXMgYmVlbg0KICAgICAgICAgICAgbmVnb3RpYXRlZCwg dGhpcyBmaWVsZCBpcyBjb21wcmVzc2VkLiAgSW5pdGlhbGx5LA0KICAgICAg ICAgICAgY29tcHJlc3Npb24gTVVTVCBiZSAibm9uZSIuDQoNCg0KDQoNClls b25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAw NCAgICAgICAgICAgICAgICBbUGFnZSA2XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgIFNTSCBUcmFuc3BvcnQgTGF5ZXIgUHJvdG9jb2wgICAgICAgICAg ICAgSnVseSAyMDAzDQoNCg0KICAgICAgICAgcmFuZG9tIHBhZGRpbmcNCiAg ICAgICAgICAgIEFyYml0cmFyeS1sZW5ndGggcGFkZGluZywgc3VjaCB0aGF0 IHRoZSB0b3RhbCBsZW5ndGggb2YNCiAgICAgICAgICAgIChwYWNrZXRfbGVu Z3RoIHx8IHBhZGRpbmdfbGVuZ3RoIHx8IHBheWxvYWQgfHwgcGFkZGluZykg aXMgYQ0KICAgICAgICAgICAgbXVsdGlwbGUgb2YgdGhlIGNpcGhlciBibG9j ayBzaXplIG9yIDgsIHdoaWNoZXZlciBpcyBsYXJnZXIuDQogICAgICAgICAg ICBUaGVyZSBNVVNUIGJlIGF0IGxlYXN0IGZvdXIgYnl0ZXMgb2YgcGFkZGlu Zy4gIFRoZSBwYWRkaW5nDQogICAgICAgICAgICBTSE9VTEQgY29uc2lzdCBv ZiByYW5kb20gYnl0ZXMuICBUaGUgbWF4aW11bSBhbW91bnQgb2YNCiAgICAg ICAgICAgIHBhZGRpbmcgaXMgMjU1IGJ5dGVzLg0KDQogICAgICAgICBtYWMN CiAgICAgICAgICAgIE1lc3NhZ2UgYXV0aGVudGljYXRpb24gY29kZS4gIElm IG1lc3NhZ2UgYXV0aGVudGljYXRpb24gaGFzDQogICAgICAgICAgICBiZWVu IG5lZ290aWF0ZWQsIHRoaXMgZmllbGQgY29udGFpbnMgdGhlIE1BQyBieXRl cy4NCiAgICAgICAgICAgIEluaXRpYWxseSwgdGhlIE1BQyBhbGdvcml0aG0g TVVTVCBiZSAibm9uZSIuDQoNCg0KICAgICAgTm90ZSB0aGF0IGxlbmd0aCBv ZiB0aGUgY29uY2F0ZW5hdGlvbiBvZiBwYWNrZXQgbGVuZ3RoLCBwYWRkaW5n DQogICAgICBsZW5ndGgsIHBheWxvYWQsIGFuZCBwYWRkaW5nIE1VU1QgYmUg YSBtdWx0aXBsZSBvZiB0aGUgY2lwaGVyDQogICAgICBibG9jayBzaXplIG9y IDgsIHdoaWNoZXZlciBpcyBsYXJnZXIuICBUaGlzIGNvbnN0cmFpbnQgTVVT VCBiZQ0KICAgICAgZW5mb3JjZWQgZXZlbiB3aGVuIHVzaW5nIHN0cmVhbSBj aXBoZXJzLiAgTm90ZSB0aGF0IHRoZSBwYWNrZXQNCiAgICAgIGxlbmd0aCBm aWVsZCBpcyBhbHNvIGVuY3J5cHRlZCwgYW5kIHByb2Nlc3NpbmcgaXQgcmVx dWlyZXMgc3BlY2lhbA0KICAgICAgY2FyZSB3aGVuIHNlbmRpbmcgb3IgcmVj ZWl2aW5nIHBhY2tldHMuDQoNCiAgICAgIFRoZSBtaW5pbXVtIHNpemUgb2Yg YSBwYWNrZXQgaXMgMTYgKG9yIHRoZSBjaXBoZXIgYmxvY2sgc2l6ZSwNCiAg ICAgIHdoaWNoZXZlciBpcyBsYXJnZXIpIGJ5dGVzIChwbHVzIE1BQyk7IGlt cGxlbWVudGF0aW9ucyBTSE9VTEQNCiAgICAgIGRlY3J5cHQgdGhlIGxlbmd0 aCBhZnRlciByZWNlaXZpbmcgdGhlIGZpcnN0IDggKG9yIGNpcGhlciBibG9j aw0KICAgICAgc2l6ZSwgd2hpY2hldmVyIGlzIGxhcmdlcikgYnl0ZXMgb2Yg YSBwYWNrZXQuDQoNCiAgIDQuMSBNYXhpbXVtIFBhY2tldCBMZW5ndGgNCg0K ICAgICAgQWxsIGltcGxlbWVudGF0aW9ucyBNVVNUIGJlIGFibGUgdG8gcHJv Y2VzcyBwYWNrZXRzIHdpdGgNCiAgICAgIHVuY29tcHJlc3NlZCBwYXlsb2Fk IGxlbmd0aCBvZiAzMjc2OCBieXRlcyBvciBsZXNzIGFuZCB0b3RhbA0KICAg ICAgcGFja2V0IHNpemUgb2YgMzUwMDAgYnl0ZXMgb3IgbGVzcyAoaW5jbHVk aW5nIGxlbmd0aCwgcGFkZGluZw0KICAgICAgbGVuZ3RoLCBwYXlsb2FkLCBw YWRkaW5nLCBhbmQgTUFDLikuICBUaGUgbWF4aW11bSBvZiAzNTAwMCBieXRl cw0KICAgICAgaXMgYW4gYXJiaXRyYXJ5IGNob3NlbiB2YWx1ZSBsYXJnZXIg dGhhbiB1bmNvbXByZXNzZWQgc2l6ZS4NCiAgICAgIEltcGxlbWVudGF0aW9u cyBTSE9VTEQgc3VwcG9ydCBsb25nZXIgcGFja2V0cywgd2hlcmUgdGhleSBt aWdodCBiZQ0KICAgICAgbmVlZGVkLCBlLmcuICBpZiBhbiBpbXBsZW1lbnRh dGlvbiB3YW50cyB0byBzZW5kIGEgdmVyeSBsYXJnZQ0KICAgICAgbnVtYmVy IG9mIGNlcnRpZmljYXRlcy4gIFN1Y2ggcGFja2V0cyBNQVkgYmUgc2VudCBp ZiB0aGUgdmVyc2lvbg0KICAgICAgc3RyaW5nIGluZGljYXRlcyB0aGF0IHRo ZSBvdGhlciBwYXJ0eSBpcyBhYmxlIHRvIHByb2Nlc3MgdGhlbS4NCiAgICAg IEhvd2V2ZXIsIGltcGxlbWVudGF0aW9ucyBTSE9VTEQgY2hlY2sgdGhhdCB0 aGUgcGFja2V0IGxlbmd0aCBpcw0KICAgICAgcmVhc29uYWJsZSBmb3IgdGhl IGltcGxlbWVudGF0aW9uIHRvIGF2b2lkIGRlbmlhbC1vZi1zZXJ2aWNlDQog ICAgICBhbmQvb3IgYnVmZmVyIG92ZXJmbG93IGF0dGFja3MuDQoNCiAgIDQu MiBDb21wcmVzc2lvbg0KDQogICAgICBJZiBjb21wcmVzc2lvbiBoYXMgYmVl biBuZWdvdGlhdGVkLCB0aGUgcGF5bG9hZCBmaWVsZCAoYW5kIG9ubHkNCiAg ICAgIGl0KSB3aWxsIGJlIGNvbXByZXNzZWQgdXNpbmcgdGhlIG5lZ290aWF0 ZWQgYWxnb3JpdGhtLiAgVGhlIGxlbmd0aA0KICAgICAgZmllbGQgYW5kIE1B QyB3aWxsIGJlIGNvbXB1dGVkIGZyb20gdGhlIGNvbXByZXNzZWQgcGF5bG9h ZC4NCiAgICAgIEVuY3J5cHRpb24gd2lsbCBiZSBkb25lIGFmdGVyIGNvbXBy ZXNzaW9uLg0KDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBp cmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgN10N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICBTU0ggVHJhbnNwb3J0IExheWVy IFByb3RvY29sICAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgIENv bXByZXNzaW9uIE1BWSBiZSBzdGF0ZWZ1bCwgZGVwZW5kaW5nIG9uIHRoZSBt ZXRob2QuICBDb21wcmVzc2lvbg0KICAgICAgTVVTVCBiZSBpbmRlcGVuZGVu dCBmb3IgZWFjaCBkaXJlY3Rpb24sIGFuZCBpbXBsZW1lbnRhdGlvbnMgTVVT VA0KICAgICAgYWxsb3cgaW5kZXBlbmRlbnRseSBjaG9vc2luZyB0aGUgYWxn b3JpdGhtIGZvciBlYWNoIGRpcmVjdGlvbi4NCg0KICAgVGhlIGZvbGxvd2lu ZyBjb21wcmVzc2lvbiBtZXRob2RzIGFyZSBjdXJyZW50bHkgZGVmaW5lZDoN Cg0KICAgICBub25lICAgICBSRVFVSVJFRCAgICAgICAgbm8gY29tcHJlc3Np b24NCiAgICAgemxpYiAgICAgT1BUSU9OQUwgICAgICAgIFpMSUIgKExaNzcp IGNvbXByZXNzaW9uDQoNCiAgICAgIFRoZSAiemxpYiIgY29tcHJlc3Npb24g aXMgZGVzY3JpYmVkIGluIFtSRkMxOTUwXSBhbmQgaW4gW1JGQzE5NTFdLg0K ICAgICAgVGhlIGNvbXByZXNzaW9uIGNvbnRleHQgaXMgaW5pdGlhbGl6ZWQg YWZ0ZXIgZWFjaCBrZXkgZXhjaGFuZ2UsDQogICAgICBhbmQgaXMgcGFzc2Vk IGZyb20gb25lIHBhY2tldCB0byB0aGUgbmV4dCB3aXRoIG9ubHkgYSBwYXJ0 aWFsDQogICAgICBmbHVzaCBiZWluZyBwZXJmb3JtZWQgYXQgdGhlIGVuZCBv ZiBlYWNoIHBhY2tldC4gIEEgcGFydGlhbCBmbHVzaA0KICAgICAgbWVhbnMg dGhhdCB0aGUgY3VycmVudCBjb21wcmVzc2VkIGJsb2NrIGlzIGVuZGVkIGFu ZCBhbGwgZGF0YSB3aWxsDQogICAgICBiZSBvdXRwdXQuICBJZiB0aGUgY3Vy cmVudCBibG9jayBpcyBub3QgYSBzdG9yZWQgYmxvY2ssIG9uZSBvcg0KICAg ICAgbW9yZSBlbXB0eSBibG9ja3MgYXJlIGFkZGVkIGFmdGVyIHRoZSBjdXJy ZW50IGJsb2NrIHRvIGVuc3VyZSB0aGF0DQogICAgICB0aGVyZSBhcmUgYXQg bGVhc3QgOCBiaXRzIGNvdW50aW5nIGZyb20gdGhlIHN0YXJ0IG9mIHRoZSBl bmQtb2YtDQogICAgICBibG9jayBjb2RlIG9mIHRoZSBjdXJyZW50IGJsb2Nr IHRvIHRoZSBlbmQgb2YgdGhlIHBhY2tldCBwYXlsb2FkLg0KDQogICAgICBB ZGRpdGlvbmFsIG1ldGhvZHMgbWF5IGJlIGRlZmluZWQgYXMgc3BlY2lmaWVk IGluIFtTU0gtQVJDSF0uDQoNCiAgIDQuMyBFbmNyeXB0aW9uDQoNCiAgICAg IEFuIGVuY3J5cHRpb24gYWxnb3JpdGhtIGFuZCBhIGtleSB3aWxsIGJlIG5l Z290aWF0ZWQgZHVyaW5nIHRoZQ0KICAgICAga2V5IGV4Y2hhbmdlLiAgV2hl biBlbmNyeXB0aW9uIGlzIGluIGVmZmVjdCwgdGhlIHBhY2tldCBsZW5ndGgs DQogICAgICBwYWRkaW5nIGxlbmd0aCwgcGF5bG9hZCBhbmQgcGFkZGluZyBm aWVsZHMgb2YgZWFjaCBwYWNrZXQgTVVTVCBiZQ0KICAgICAgZW5jcnlwdGVk IHdpdGggdGhlIGdpdmVuIGFsZ29yaXRobS4NCg0KICAgICAgVGhlIGVuY3J5 cHRlZCBkYXRhIGluIGFsbCBwYWNrZXRzIHNlbnQgaW4gb25lIGRpcmVjdGlv biBTSE9VTEQgYmUNCiAgICAgIGNvbnNpZGVyZWQgYSBzaW5nbGUgZGF0YSBz dHJlYW0uICBGb3IgZXhhbXBsZSwgaW5pdGlhbGl6YXRpb24NCiAgICAgIHZl Y3RvcnMgU0hPVUxEIGJlIHBhc3NlZCBmcm9tIHRoZSBlbmQgb2Ygb25lIHBh Y2tldCB0byB0aGUNCiAgICAgIGJlZ2lubmluZyBvZiB0aGUgbmV4dCBwYWNr ZXQuICBBbGwgY2lwaGVycyBTSE9VTEQgdXNlIGtleXMgd2l0aCBhbg0KICAg ICAgZWZmZWN0aXZlIGtleSBsZW5ndGggb2YgMTI4IGJpdHMgb3IgbW9yZS4N Cg0KICAgICAgVGhlIGNpcGhlcnMgaW4gZWFjaCBkaXJlY3Rpb24gTVVTVCBy dW4gaW5kZXBlbmRlbnRseSBvZiBlYWNoDQogICAgICBvdGhlciwgYW5kIGlt cGxlbWVudGF0aW9ucyBNVVNUIGFsbG93IGluZGVwZW5kZW50bHkgY2hvb3Np bmcgdGhlDQogICAgICBhbGdvcml0aG0gZm9yIGVhY2ggZGlyZWN0aW9uIChp ZiBtdWx0aXBsZSBhbGdvcml0aG1zIGFyZSBhbGxvd2VkDQogICAgICBieSBs b2NhbCBwb2xpY3kpLg0KDQogICBUaGUgZm9sbG93aW5nIGNpcGhlcnMgYXJl IGN1cnJlbnRseSBkZWZpbmVkOg0KDQogICAgIDNkZXMtY2JjICAgICAgICAg UkVRVUlSRUQgICAgICAgICAgdGhyZWUta2V5IDNERVMgaW4gQ0JDIG1vZGUN CiAgICAgYmxvd2Zpc2gtY2JjICAgICBSRUNPTU1FTkRFRCAgICAgICBCbG93 ZmlzaCBpbiBDQkMgbW9kZQ0KICAgICB0d29maXNoMjU2LWNiYyAgIE9QVElP TkFMICAgICAgICAgIFR3b2Zpc2ggaW4gQ0JDIG1vZGUsDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd2l0aCAyNTYtYml0IGtl eQ0KICAgICB0d29maXNoLWNiYyAgICAgIE9QVElPTkFMICAgICAgICAgIGFs aWFzIGZvciAidHdvZmlzaDI1Ni1jYmMiICh0aGlzDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgaXMgYmVpbmcgcmV0YWluZWQg Zm9yDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg aGlzdG9yaWNhbCByZWFzb25zKQ0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAg IFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5z cG9ydCBMYXllciBQcm90b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0K DQogICAgIHR3b2Zpc2gxOTItY2JjICAgT1BUSU9OQUwgICAgICAgICAgVHdv ZmlzaCB3aXRoIDE5Mi1iaXQga2V5DQogICAgIHR3b2Zpc2gxMjgtY2JjICAg UkVDT01NRU5ERUQgICAgICAgVHdvZmlzaCB3aXRoIDEyOC1iaXQga2V5DQog ICAgIGFlczI1Ni1jYmMgICAgICAgT1BUSU9OQUwgICAgICAgICAgQUVTIChS aWpuZGFlbCkgaW4gQ0JDIG1vZGUsDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgd2l0aCAyNTYtYml0IGtleQ0KICAgICBhZXMx OTItY2JjICAgICAgIE9QVElPTkFMICAgICAgICAgIEFFUyB3aXRoIDE5Mi1i aXQga2V5DQogICAgIGFlczEyOC1jYmMgICAgICAgUkVDT01NRU5ERUQgICAg ICAgQUVTIHdpdGggMTI4LWJpdCBrZXkNCiAgICAgc2VycGVudDI1Ni1jYmMg ICBPUFRJT05BTCAgICAgICAgICBTZXJwZW50IGluIENCQyBtb2RlLCB3aXRo DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjU2 LWJpdCBrZXkNCiAgICAgc2VycGVudDE5Mi1jYmMgICBPUFRJT05BTCAgICAg ICAgICBTZXJwZW50IHdpdGggMTkyLWJpdCBrZXkNCiAgICAgc2VycGVudDEy OC1jYmMgICBPUFRJT05BTCAgICAgICAgICBTZXJwZW50IHdpdGggMTI4LWJp dCBrZXkNCiAgICAgYXJjZm91ciAgICAgICAgICBPUFRJT05BTCAgICAgICAg ICB0aGUgQVJDRk9VUiBzdHJlYW0gY2lwaGVyDQogICAgIGlkZWEtY2JjICAg ICAgICAgT1BUSU9OQUwgICAgICAgICAgSURFQSBpbiBDQkMgbW9kZQ0KICAg ICBjYXN0MTI4LWNiYyAgICAgIE9QVElPTkFMICAgICAgICAgIENBU1QtMTI4 IGluIENCQyBtb2RlDQogICAgIG5vbmUgICAgICAgICAgICAgT1BUSU9OQUwg ICAgICAgICAgbm8gZW5jcnlwdGlvbjsgTk9UIFJFQ09NTUVOREVEDQoNCiAg ICAgIFRoZSAiM2Rlcy1jYmMiIGNpcGhlciBpcyB0aHJlZS1rZXkgdHJpcGxl LURFUyAoZW5jcnlwdC1kZWNyeXB0LQ0KICAgICAgZW5jcnlwdCksIHdoZXJl IHRoZSBmaXJzdCA4IGJ5dGVzIG9mIHRoZSBrZXkgYXJlIHVzZWQgZm9yIHRo ZQ0KICAgICAgZmlyc3QgZW5jcnlwdGlvbiwgdGhlIG5leHQgOCBieXRlcyBm b3IgdGhlIGRlY3J5cHRpb24sIGFuZCB0aGUNCiAgICAgIGZvbGxvd2luZyA4 IGJ5dGVzIGZvciB0aGUgZmluYWwgZW5jcnlwdGlvbi4gIFRoaXMgcmVxdWly ZXMgMjQNCiAgICAgIGJ5dGVzIG9mIGtleSBkYXRhIChvZiB3aGljaCAxNjgg Yml0cyBhcmUgYWN0dWFsbHkgdXNlZCkuICBUbw0KICAgICAgaW1wbGVtZW50 IENCQyBtb2RlLCBvdXRlciBjaGFpbmluZyBNVVNUIGJlIHVzZWQgKGkuZS4s IHRoZXJlIGlzDQogICAgICBvbmx5IG9uZSBpbml0aWFsaXphdGlvbiB2ZWN0 b3IpLiAgVGhpcyBpcyBhIGJsb2NrIGNpcGhlciB3aXRoIDgNCiAgICAgIGJ5 dGUgYmxvY2tzLiAgVGhpcyBhbGdvcml0aG0gaXMgZGVmaW5lZCBpbiBbU0NI TkVJRVJdDQoNCiAgICAgIFRoZSAiYmxvd2Zpc2gtY2JjIiBjaXBoZXIgaXMg Qmxvd2Zpc2ggaW4gQ0JDIG1vZGUsIHdpdGggMTI4IGJpdA0KICAgICAga2V5 cyBbU0NITkVJRVJdLiAgVGhpcyBpcyBhIGJsb2NrIGNpcGhlciB3aXRoIDgg Ynl0ZSBibG9ja3MuDQoNCiAgICAgIFRoZSAidHdvZmlzaC1jYmMiIG9yICJ0 d29maXNoMjU2LWNiYyIgY2lwaGVyIGlzIFR3b2Zpc2ggaW4gQ0JDDQogICAg ICBtb2RlLCB3aXRoIDI1NiBiaXQga2V5cyBhcyBkZXNjcmliZWQgW1RXT0ZJ U0hdLiAgVGhpcyBpcyBhIGJsb2NrDQogICAgICBjaXBoZXIgd2l0aCAxNiBi eXRlIGJsb2Nrcy4NCg0KICAgICAgVGhlICJ0d29maXNoMTkyLWNiYyIgY2lw aGVyLiAgU2FtZSBhcyBhYm92ZSBidXQgd2l0aCAxOTItYml0IGtleS4NCg0K ICAgICAgVGhlICJ0d29maXNoMTI4LWNiYyIgY2lwaGVyLiAgU2FtZSBhcyBh Ym92ZSBidXQgd2l0aCAxMjgtYml0IGtleS4NCg0KICAgICAgVGhlICJhZXMy NTYtY2JjIiBjaXBoZXIgaXMgQUVTIChBZHZhbmNlZCBFbmNyeXB0aW9uIFN0 YW5kYXJkKSwNCiAgICAgIGZvcm1lcmx5IFJpam5kYWVsLCBpbiBDQkMgbW9k ZS4gIFRoaXMgdmVyc2lvbiB1c2VzIDI1Ni1iaXQga2V5Lg0KDQogICAgICBU aGUgImFlczE5Mi1jYmMiIGNpcGhlci4gIFNhbWUgYXMgYWJvdmUgYnV0IHdp dGggMTkyLWJpdCBrZXkuDQoNCiAgICAgIFRoZSAiYWVzMTI4LWNiYyIgY2lw aGVyLiAgU2FtZSBhcyBhYm92ZSBidXQgd2l0aCAxMjgtYml0IGtleS4NCg0K ICAgICAgVGhlICJzZXJwZW50MjU2LWNiYyIgY2lwaGVyIGluIENCQyBtb2Rl LCB3aXRoIDI1Ni1iaXQga2V5IGFzDQogICAgICBkZXNjcmliZWQgaW4gdGhl IFNlcnBlbnQgQUVTIHN1Ym1pc3Npb24uDQoNCiAgICAgIFRoZSAic2VycGVu dDE5Mi1jYmMiIGNpcGhlci4gIFNhbWUgYXMgYWJvdmUgYnV0IHdpdGggMTky LWJpdCBrZXkuDQoNCiAgICAgIFRoZSAic2VycGVudDEyOC1jYmMiIGNpcGhl ci4gIFNhbWUgYXMgYWJvdmUgYnV0IHdpdGggMTI4LWJpdCBrZXkuDQoNCg0K DQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIs IDIwMDQgICAgICAgICAgICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICBTU0ggVHJhbnNwb3J0IExheWVyIFByb3RvY29sICAgICAg ICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgIFRoZSAiYXJjZm91ciIgaXMg dGhlIEFyY2ZvdXIgc3RyZWFtIGNpcGhlciB3aXRoIDEyOCBiaXQga2V5cy4g IFRoZQ0KICAgICAgQXJjZm91ciBjaXBoZXIgaXMgYmVsaWV2ZWQgdG8gYmUg Y29tcGF0aWJsZSB3aXRoIHRoZSBSQzQgY2lwaGVyDQogICAgICBbU0NITkVJ RVJdLiAgUkM0IGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgUlNBIERh dGEgU2VjdXJpdHkNCiAgICAgIEluYy4gIEFyY2ZvdXIgKGFuZCBSQzQpIGhh cyBwcm9ibGVtcyB3aXRoIHdlYWsga2V5cywgYW5kIHNob3VsZCBiZQ0KICAg ICAgdXNlZCB3aXRoIGNhdXRpb24uDQoNCiAgICAgIFRoZSAiaWRlYS1jYmMi IGNpcGhlciBpcyB0aGUgSURFQSBjaXBoZXIgaW4gQ0JDIG1vZGUgW1NDSE5F SUVSXS4NCiAgICAgIElERUEgaXMgcGF0ZW50ZWQgYnkgQXNjb20gQUcuDQoN CiAgICAgIFRoZSAiY2FzdDEyOC1jYmMiIGNpcGhlciBpcyB0aGUgQ0FTVC0x MjggY2lwaGVyIGluIENCQyBtb2RlDQogICAgICBbUkZDMjE0NF0uDQoNCiAg ICAgIFRoZSAibm9uZSIgYWxnb3JpdGhtIHNwZWNpZmllcyB0aGF0IG5vIGVu Y3J5cHRpb24gaXMgdG8gYmUgZG9uZS4NCiAgICAgIE5vdGUgdGhhdCB0aGlz IG1ldGhvZCBwcm92aWRlcyBubyBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlv biwgYW5kDQogICAgICBpdCBpcyBub3QgcmVjb21tZW5kZWQuICBTb21lIGZ1 bmN0aW9uYWxpdHkgKGUuZy4gIHBhc3N3b3JkDQogICAgICBhdXRoZW50aWNh dGlvbikgbWF5IGJlIGRpc2FibGVkIGZvciBzZWN1cml0eSByZWFzb25zIGlm IHRoaXMNCiAgICAgIGNpcGhlciBpcyBjaG9zZW4uDQoNCiAgICAgIEFkZGl0 aW9uYWwgbWV0aG9kcyBtYXkgYmUgZGVmaW5lZCBhcyBzcGVjaWZpZWQgaW4g W1NTSC1BUkNIXS4NCg0KICAgNC40IERhdGEgSW50ZWdyaXR5DQoNCiAgICAg IERhdGEgaW50ZWdyaXR5IGlzIHByb3RlY3RlZCBieSBpbmNsdWRpbmcgd2l0 aCBlYWNoIHBhY2tldCBhDQogICAgICBtZXNzYWdlIGF1dGhlbnRpY2F0aW9u IGNvZGUgKE1BQykgdGhhdCBpcyBjb21wdXRlZCBmcm9tIGEgc2hhcmVkDQog ICAgICBzZWNyZXQsIHBhY2tldCBzZXF1ZW5jZSBudW1iZXIsIGFuZCB0aGUg Y29udGVudHMgb2YgdGhlIHBhY2tldC4NCg0KICAgICAgVGhlIG1lc3NhZ2Ug YXV0aGVudGljYXRpb24gYWxnb3JpdGhtIGFuZCBrZXkgYXJlIG5lZ290aWF0 ZWQgZHVyaW5nDQogICAgICBrZXkgZXhjaGFuZ2UuICBJbml0aWFsbHksIG5v IE1BQyB3aWxsIGJlIGluIGVmZmVjdCwgYW5kIGl0cyBsZW5ndGgNCiAgICAg IE1VU1QgYmUgemVyby4gIEFmdGVyIGtleSBleGNoYW5nZSwgdGhlIHNlbGVj dGVkIE1BQyB3aWxsIGJlDQogICAgICBjb21wdXRlZCBiZWZvcmUgZW5jcnlw dGlvbiBmcm9tIHRoZSBjb25jYXRlbmF0aW9uIG9mIHBhY2tldCBkYXRhOg0K DQogICAgIG1hYyA9IE1BQyhrZXksIHNlcXVlbmNlX251bWJlciB8fCB1bmVu Y3J5cHRlZF9wYWNrZXQpDQoNCiAgICAgIHdoZXJlIHVuZW5jcnlwdGVkX3Bh Y2tldCBpcyB0aGUgZW50aXJlIHBhY2tldCB3aXRob3V0IE1BQyAodGhlDQog ICAgICBsZW5ndGggZmllbGRzLCBwYXlsb2FkIGFuZCBwYWRkaW5nKSwgYW5k IHNlcXVlbmNlX251bWJlciBpcyBhbg0KICAgICAgaW1wbGljaXQgcGFja2V0 IHNlcXVlbmNlIG51bWJlciByZXByZXNlbnRlZCBhcyB1aW50MzIuICBUaGUN CiAgICAgIHNlcXVlbmNlIG51bWJlciBpcyBpbml0aWFsaXplZCB0byB6ZXJv IGZvciB0aGUgZmlyc3QgcGFja2V0LCBhbmQNCiAgICAgIGlzIGluY3JlbWVu dGVkIGFmdGVyIGV2ZXJ5IHBhY2tldCAocmVnYXJkbGVzcyBvZiB3aGV0aGVy DQogICAgICBlbmNyeXB0aW9uIG9yIE1BQyBpcyBpbiB1c2UpLiAgSXQgaXMg bmV2ZXIgcmVzZXQsIGV2ZW4gaWYNCiAgICAgIGtleXMvYWxnb3JpdGhtcyBh cmUgcmVuZWdvdGlhdGVkIGxhdGVyLiAgSXQgd3JhcHMgYXJvdW5kIHRvIHpl cm8NCiAgICAgIGFmdGVyIGV2ZXJ5IDJeMzIgcGFja2V0cy4gIFRoZSBwYWNr ZXQgc2VxdWVuY2UgbnVtYmVyIGl0c2VsZiBpcw0KICAgICAgbm90IGluY2x1 ZGVkIGluIHRoZSBwYWNrZXQgc2VudCBvdmVyIHRoZSB3aXJlLg0KDQogICAg ICBUaGUgTUFDIGFsZ29yaXRobXMgZm9yIGVhY2ggZGlyZWN0aW9uIE1VU1Qg cnVuIGluZGVwZW5kZW50bHksIGFuZA0KICAgICAgaW1wbGVtZW50YXRpb25z IE1VU1QgYWxsb3cgY2hvb3NpbmcgdGhlIGFsZ29yaXRobSBpbmRlcGVuZGVu dGx5DQogICAgICBmb3IgYm90aCBkaXJlY3Rpb25zLg0KDQogICAgICBUaGUg TUFDIGJ5dGVzIHJlc3VsdGluZyBmcm9tIHRoZSBNQUMgYWxnb3JpdGhtIE1V U1QgYmUgdHJhbnNtaXR0ZWQNCg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAg ICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNCAgICAgICAgICAgICAgIFtQ YWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFNTSCBUcmFuc3Bv cnQgTGF5ZXIgUHJvdG9jb2wgICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0K ICAgICAgd2l0aG91dCBlbmNyeXB0aW9uIGFzIHRoZSBsYXN0IHBhcnQgb2Yg dGhlIHBhY2tldC4gIFRoZSBudW1iZXIgb2YNCiAgICAgIE1BQyBieXRlcyBk ZXBlbmRzIG9uIHRoZSBhbGdvcml0aG0gY2hvc2VuLg0KDQogICBUaGUgZm9s bG93aW5nIE1BQyBhbGdvcml0aG1zIGFyZSBjdXJyZW50bHkgZGVmaW5lZDoN Cg0KICAgICBobWFjLXNoYTEgICAgUkVRVUlSRUQgICAgICAgIEhNQUMtU0hB MSAoZGlnZXN0IGxlbmd0aCA9IGtleQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGxlbmd0aCA9IDIwKQ0KICAgICBobWFjLXNoYTEtOTYg UkVDT01NRU5ERUQgICAgIGZpcnN0IDk2IGJpdHMgb2YgSE1BQy1TSEExIChk aWdlc3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBsZW5n dGggPSAxMiwga2V5IGxlbmd0aCA9IDIwKQ0KICAgICBobWFjLW1kNSAgICAg T1BUSU9OQUwgICAgICAgIEhNQUMtTUQ1IChkaWdlc3QgbGVuZ3RoID0ga2V5 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGVuZ3RoID0g MTYpDQogICAgIGhtYWMtbWQ1LTk2ICBPUFRJT05BTCAgICAgICAgZmlyc3Qg OTYgYml0cyBvZiBITUFDLU1ENSAoZGlnZXN0DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbGVuZ3RoID0gMTIsIGtleSBsZW5ndGggPSAx NikNCiAgICAgbm9uZSAgICAgICAgIE9QVElPTkFMICAgICAgICBubyBNQUM7 IE5PVCBSRUNPTU1FTkRFRA0KDQogICAgICBUaGUgImhtYWMtKiIgYWxnb3Jp dGhtcyBhcmUgZGVzY3JpYmVkIGluIFtSRkMyMTA0XSBUaGUgIiotbiIgTUFD cw0KICAgICAgdXNlIG9ubHkgdGhlIGZpcnN0IG4gYml0cyBvZiB0aGUgcmVz dWx0aW5nIHZhbHVlLg0KDQogICAgICBUaGUgaGFzaCBhbGdvcml0aG1zIGFy ZSBkZXNjcmliZWQgaW4gW1NDSE5FSUVSXS4NCg0KICAgICAgQWRkaXRpb25h bCBtZXRob2RzIG1heSBiZSBkZWZpbmVkIGFzIHNwZWNpZmllZCBpbiBbU1NI LUFSQ0hdLg0KDQogICA0LjUgS2V5IEV4Y2hhbmdlIE1ldGhvZHMNCg0KICAg ICAgVGhlIGtleSBleGNoYW5nZSBtZXRob2Qgc3BlY2lmaWVzIGhvdyBvbmUt dGltZSBzZXNzaW9uIGtleXMgYXJlDQogICAgICBnZW5lcmF0ZWQgZm9yIGVu Y3J5cHRpb24gYW5kIGZvciBhdXRoZW50aWNhdGlvbiwgYW5kIGhvdyB0aGUN CiAgICAgIHNlcnZlciBhdXRoZW50aWNhdGlvbiBpcyBkb25lLg0KDQogICBP bmx5IG9uZSBSRVFVSVJFRCBrZXkgZXhjaGFuZ2UgbWV0aG9kIGhhcyBiZWVu IGRlZmluZWQ6DQoNCiAgICAgZGlmZmllLWhlbGxtYW4tZ3JvdXAxLXNoYTEg ICAgICAgUkVRVUlSRUQNCg0KICAgICAgVGhpcyBtZXRob2QgaXMgZGVzY3Jp YmVkIGxhdGVyIGluIHRoaXMgZG9jdW1lbnQuDQoNCiAgICAgIEFkZGl0aW9u YWwgbWV0aG9kcyBtYXkgYmUgZGVmaW5lZCBhcyBzcGVjaWZpZWQgaW4gW1NT SC1BUkNIXS4NCg0KICAgNC42IFB1YmxpYyBLZXkgQWxnb3JpdGhtcw0KDQog ICAgICBUaGlzIHByb3RvY29sIGhhcyBiZWVuIGRlc2lnbmVkIHRvIGJlIGFi bGUgdG8gb3BlcmF0ZSB3aXRoIGFsbW9zdA0KICAgICAgYW55IHB1YmxpYyBr ZXkgZm9ybWF0LCBlbmNvZGluZywgYW5kIGFsZ29yaXRobSAoc2lnbmF0dXJl IGFuZC9vcg0KICAgICAgZW5jcnlwdGlvbikuDQoNCiAgICAgIFRoZXJlIGFy ZSBzZXZlcmFsIGFzcGVjdHMgdGhhdCBkZWZpbmUgYSBwdWJsaWMga2V5IHR5 cGU6DQogICAgICBvICBLZXkgZm9ybWF0OiBob3cgaXMgdGhlIGtleSBlbmNv ZGVkIGFuZCBob3cgYXJlIGNlcnRpZmljYXRlcw0KICAgICAgICAgcmVwcmVz ZW50ZWQuICBUaGUga2V5IGJsb2JzIGluIHRoaXMgcHJvdG9jb2wgTUFZIGNv bnRhaW4NCiAgICAgICAgIGNlcnRpZmljYXRlcyBpbiBhZGRpdGlvbiB0byBr ZXlzLg0KICAgICAgbyAgU2lnbmF0dXJlIGFuZC9vciBlbmNyeXB0aW9uIGFs Z29yaXRobXMuICBTb21lIGtleSB0eXBlcyBtYXkgbm90DQogICAgICAgICBz dXBwb3J0IGJvdGggc2lnbmluZyBhbmQgZW5jcnlwdGlvbi4gIEtleSB1c2Fn ZSBtYXkgYWxzbyBiZQ0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAg RXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgW1BhZ2Ug MTFdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5zcG9ydCBM YXllciBQcm90b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQogICAg ICAgICByZXN0cmljdGVkIGJ5IHBvbGljeSBzdGF0ZW1lbnRzIGluIGUuZy4g IGNlcnRpZmljYXRlcy4gIEluIHRoaXMNCiAgICAgICAgIGNhc2UsIGRpZmZl cmVudCBrZXkgdHlwZXMgU0hPVUxEIGJlIGRlZmluZWQgZm9yIHRoZSBkaWZm ZXJlbnQNCiAgICAgICAgIHBvbGljeSBhbHRlcm5hdGl2ZXMuDQogICAgICBv ICBFbmNvZGluZyBvZiBzaWduYXR1cmVzIGFuZC9vciBlbmNyeXB0ZWQgZGF0 YS4gIFRoaXMgaW5jbHVkZXMNCiAgICAgICAgIGJ1dCBpcyBub3QgbGltaXRl ZCB0byBwYWRkaW5nLCBieXRlIG9yZGVyLCBhbmQgZGF0YSBmb3JtYXRzLg0K DQogICBUaGUgZm9sbG93aW5nIHB1YmxpYyBrZXkgYW5kL29yIGNlcnRpZmlj YXRlIGZvcm1hdHMgYXJlIGN1cnJlbnRseSBkZWZpbmVkOg0KDQogICBzc2gt ZHNzICAgICAgICAgICAgICBSRVFVSVJFRCAgICAgc2lnbiAgICBTaW1wbGUg RFNTDQogICBzc2gtcnNhICAgICAgICAgICAgICBSRUNPTU1FTkRFRCAgc2ln biAgICBTaW1wbGUgUlNBDQogICB4NTA5djMtc2lnbi1yc2EgICAgICBPUFRJ T05BTCAgICAgc2lnbiAgICBYLjUwOSBjZXJ0aWZpY2F0ZXMgKFJTQSBrZXkp DQogICB4NTA5djMtc2lnbi1kc3MgICAgICBPUFRJT05BTCAgICAgc2lnbiAg ICBYLjUwOSBjZXJ0aWZpY2F0ZXMgKERTUyBrZXkpDQogICBzcGtpLXNpZ24t cnNhICAgICAgICBPUFRJT05BTCAgICAgc2lnbiAgICBTUEtJIGNlcnRpZmlj YXRlcyAoUlNBIGtleSkNCiAgIHNwa2ktc2lnbi1kc3MgICAgICAgIE9QVElP TkFMICAgICBzaWduICAgIFNQS0kgY2VydGlmaWNhdGVzIChEU1Mga2V5KQ0K ICAgcGdwLXNpZ24tcnNhICAgICAgICAgT1BUSU9OQUwgICAgIHNpZ24gICAg T3BlblBHUCBjZXJ0aWZpY2F0ZXMgKFJTQSBrZXkpDQogICBwZ3Atc2lnbi1k c3MgICAgICAgICBPUFRJT05BTCAgICAgc2lnbiAgICBPcGVuUEdQIGNlcnRp ZmljYXRlcyAoRFNTIGtleSkNCg0KICAgICAgQWRkaXRpb25hbCBrZXkgdHlw ZXMgbWF5IGJlIGRlZmluZWQgYXMgc3BlY2lmaWVkIGluIFtTU0gtQVJDSF0u DQoNCiAgICAgIFRoZSBrZXkgdHlwZSBNVVNUIGFsd2F5cyBiZSBleHBsaWNp dGx5IGtub3duIChmcm9tIGFsZ29yaXRobQ0KICAgICAgbmVnb3RpYXRpb24g b3Igc29tZSBvdGhlciBzb3VyY2UpLiAgSXQgaXMgbm90IG5vcm1hbGx5IGlu Y2x1ZGVkIGluDQogICAgICB0aGUga2V5IGJsb2IuDQoNCiAgICAgIENlcnRp ZmljYXRlcyBhbmQgcHVibGljIGtleXMgYXJlIGVuY29kZWQgYXMgZm9sbG93 czoNCg0KICAgICBzdHJpbmcgICBjZXJ0aWZpY2F0ZSBvciBwdWJsaWMga2V5 IGZvcm1hdCBpZGVudGlmaWVyDQogICAgIGJ5dGVbbl0gIGtleS9jZXJ0aWZp Y2F0ZSBkYXRhDQoNCiAgICAgIFRoZSBjZXJ0aWZpY2F0ZSBwYXJ0IG1heSBo YXZlIGJlIGEgemVybyBsZW5ndGggc3RyaW5nLCBidXQgYQ0KICAgICAgcHVi bGljIGtleSBpcyByZXF1aXJlZC4gIFRoaXMgaXMgdGhlIHB1YmxpYyBrZXkg dGhhdCB3aWxsIGJlIHVzZWQNCiAgICAgIGZvciBhdXRoZW50aWNhdGlvbjsg dGhlIGNlcnRpZmljYXRlIHNlcXVlbmNlIGNvbnRhaW5lZCBpbiB0aGUNCiAg ICAgIGNlcnRpZmljYXRlIGJsb2IgY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSBh dXRob3JpemF0aW9uLg0KDQogICAgICBQdWJsaWMga2V5IC8gY2VydGlmY2F0 ZSBmb3JtYXRzIHRoYXQgZG8gbm90IGV4cGxpY2l0bHkgc3BlY2lmeSBhDQog ICAgICBzaWduYXR1cmUgZm9ybWF0IGlkZW50aWZpZXIgTVVTVCB1c2UgdGhl IHB1YmxpYyBrZXkgLyBjZXJ0aWZpY2F0ZQ0KICAgICAgZm9ybWF0IGlkZW50 aWZpZXIgYXMgdGhlIHNpZ25hdHVyZSBpZGVudGlmaWVyLg0KDQogICBTaWdu YXR1cmVzIGFyZSBlbmNvZGVkIGFzIGZvbGxvd3M6DQogICAgIHN0cmluZyAg ICBzaWduYXR1cmUgZm9ybWF0IGlkZW50aWZpZXIgKGFzIHNwZWNpZmllZCBi eSB0aGUNCiAgICAgICAgICAgICAgIHB1YmxpYyBrZXkgLyBjZXJ0IGZvcm1h dCkNCiAgICAgYnl0ZVtuXSAgIHNpZ25hdHVyZSBibG9iIGluIGZvcm1hdCBz cGVjaWZpYyBlbmNvZGluZy4NCg0KDQogICBUaGUgInNzaC1kc3MiIGtleSBm b3JtYXQgaGFzIHRoZSBmb2xsb3dpbmcgc3BlY2lmaWMgZW5jb2Rpbmc6DQoN CiAgICAgc3RyaW5nICAgICJzc2gtZHNzIg0KICAgICBtcGludCAgICAgcA0K ICAgICBtcGludCAgICAgcQ0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgW1Bh Z2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5zcG9y dCBMYXllciBQcm90b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQog ICAgIG1waW50ICAgICBnDQogICAgIG1waW50ICAgICB5DQoNCiAgIEhlcmUg dGhlIHAsIHEsIGcsIGFuZCB5IHBhcmFtZXRlcnMgZm9ybSB0aGUgc2lnbmF0 dXJlIGtleSBibG9iLg0KDQogICAgICBTaWduaW5nIGFuZCB2ZXJpZnlpbmcg dXNpbmcgdGhpcyBrZXkgZm9ybWF0IGlzIGRvbmUgYWNjb3JkaW5nIHRvDQog ICAgICB0aGUgRGlnaXRhbCBTaWduYXR1cmUgU3RhbmRhcmQgW0ZJUFMtMTg2 XSB1c2luZyB0aGUgU0hBLTEgaGFzaC4gIEENCiAgICAgIGRlc2NyaXB0aW9u IGNhbiBhbHNvIGJlIGZvdW5kIGluIFtTQ0hORUlFUl0uDQoNCiAgIFRoZSBy ZXN1bHRpbmcgc2lnbmF0dXJlIGlzIGVuY29kZWQgYXMgZm9sbG93czoNCg0K ICAgICBzdHJpbmcgICAgInNzaC1kc3MiDQogICAgIHN0cmluZyAgICBkc3Nf c2lnbmF0dXJlX2Jsb2INCg0KICAgICAgZHNzX3NpZ25hdHVyZV9ibG9iIGlz IGVuY29kZWQgYXMgYSBzdHJpbmcgY29udGFpbmluZyByIGZvbGxvd2VkIGJ5 DQogICAgICBzICh3aGljaCBhcmUgMTYwIGJpdHMgbG9uZyBpbnRlZ2Vycywg d2l0aG91dCBsZW5ndGhzIG9yIHBhZGRpbmcsDQogICAgICB1bnNpZ25lZCBh bmQgaW4gbmV0d29yayBieXRlIG9yZGVyKS4NCg0KICAgVGhlICJzc2gtcnNh IiBrZXkgZm9ybWF0IGhhcyB0aGUgZm9sbG93aW5nIHNwZWNpZmljIGVuY29k aW5nOg0KDQogICAgIHN0cmluZyAgICAic3NoLXJzYSINCiAgICAgbXBpbnQg ICAgIGUNCiAgICAgbXBpbnQgICAgIG4NCg0KICAgSGVyZSB0aGUgZSBhbmQg biBwYXJhbWV0ZXJzIGZvcm0gdGhlIHNpZ25hdHVyZSBrZXkgYmxvYi4NCg0K ICAgICAgU2lnbmluZyBhbmQgdmVyaWZ5aW5nIHVzaW5nIHRoaXMga2V5IGZv cm1hdCBpcyBkb25lIGFjY29yZGluZyB0bw0KICAgICAgW1NDSE5FSUVSXSBh bmQgW1BLQ1MxXSB1c2luZyB0aGUgU0hBLTEgaGFzaC4NCg0KICAgVGhlIHJl c3VsdGluZyBzaWduYXR1cmUgaXMgZW5jb2RlZCBhcyBmb2xsb3dzOg0KDQog ICAgIHN0cmluZyAgICAic3NoLXJzYSINCiAgICAgc3RyaW5nICAgIHJzYV9z aWduYXR1cmVfYmxvYg0KDQogICAgICByc2Ffc2lnbmF0dXJlX2Jsb2IgaXMg ZW5jb2RlZCBhcyBhIHN0cmluZyBjb250YWluaW5nIHMgKHdoaWNoIGlzDQog ICAgICBhbiBpbnRlZ2VyLCB3aXRob3V0IGxlbmd0aHMgb3IgcGFkZGluZywg dW5zaWduZWQgYW5kIGluIG5ldHdvcmsNCiAgICAgIGJ5dGUgb3JkZXIpLg0K DQogICAgICBUaGUgInNwa2ktc2lnbi1yc2EiIG1ldGhvZCBpbmRpY2F0ZXMg dGhhdCB0aGUgY2VydGlmaWNhdGUgYmxvYg0KICAgICAgY29udGFpbnMgYSBz ZXF1ZW5jZSBvZiBTUEtJIGNlcnRpZmljYXRlcy4gIFRoZSBmb3JtYXQgb2Yg U1BLSQ0KICAgICAgY2VydGlmaWNhdGVzIGlzIGRlc2NyaWJlZCBpbiBbUkZD MjY5M10uICBUaGlzIG1ldGhvZCBpbmRpY2F0ZXMNCiAgICAgIHRoYXQgdGhl IGtleSAob3Igb25lIG9mIHRoZSBrZXlzIGluIHRoZSBjZXJ0aWZpY2F0ZSkg aXMgYW4gUlNBLQ0KICAgICAga2V5Lg0KDQogICAgICBUaGUgInNwa2ktc2ln bi1kc3MiLiAgQXMgYWJvdmUsIGJ1dCBpbmRpY2F0ZXMgdGhhdCB0aGUga2V5 IChvciBvbmUNCiAgICAgIG9mIHRoZSBrZXlzIGluIHRoZSBjZXJ0aWZpY2F0 ZSkgaXMgYSBEU1Mta2V5Lg0KDQogICAgICBUaGUgInBncC1zaWduLXJzYSIg bWV0aG9kIGluZGljYXRlcyB0aGUgY2VydGlmaWNhdGVzLCB0aGUgcHVibGlj DQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEphbnVh cnkgMTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxM10NCgwNCkludGVy bmV0LURyYWZ0ICAgICAgICBTU0ggVHJhbnNwb3J0IExheWVyIFByb3RvY29s ICAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgIGtleSwgYW5kIHRo ZSBzaWduYXR1cmUgYXJlIGluIE9wZW5QR1AgY29tcGF0aWJsZSBiaW5hcnkg Zm9ybWF0DQogICAgICAoW1JGQzI0NDBdKS4gIFRoaXMgbWV0aG9kIGluZGlj YXRlcyB0aGF0IHRoZSBrZXkgaXMgYW4gUlNBLWtleS4NCg0KICAgICAgVGhl ICJwZ3Atc2lnbi1kc3MiLiAgQXMgYWJvdmUsIGJ1dCBpbmRpY2F0ZXMgdGhh dCB0aGUga2V5IGlzIGENCiAgICAgIERTUy1rZXkuDQoNCiAgIDUuIEtleSBF eGNoYW5nZQ0KDQogICAgICBLZXkgZXhjaGFuZ2UgYmVnaW5zIGJ5IGVhY2gg c2lkZSBzZW5kaW5nIGxpc3RzIG9mIHN1cHBvcnRlZA0KICAgICAgYWxnb3Jp dGhtcy4gIEVhY2ggc2lkZSBoYXMgYSBwcmVmZXJyZWQgYWxnb3JpdGhtIGlu IGVhY2ggY2F0ZWdvcnksDQogICAgICBhbmQgaXQgaXMgYXNzdW1lZCB0aGF0 IG1vc3QgaW1wbGVtZW50YXRpb25zIGF0IGFueSBnaXZlbiB0aW1lIHdpbGwN CiAgICAgIHVzZSB0aGUgc2FtZSBwcmVmZXJyZWQgYWxnb3JpdGhtLiAgRWFj aCBzaWRlIE1BWSBndWVzcyB3aGljaA0KICAgICAgYWxnb3JpdGhtIHRoZSBv dGhlciBzaWRlIGlzIHVzaW5nLCBhbmQgTUFZIHNlbmQgYW4gaW5pdGlhbCBr ZXkNCiAgICAgIGV4Y2hhbmdlIHBhY2tldCBhY2NvcmRpbmcgdG8gdGhlIGFs Z29yaXRobSBpZiBhcHByb3ByaWF0ZSBmb3IgdGhlDQogICAgICBwcmVmZXJy ZWQgbWV0aG9kLg0KDQogICAgICBHdWVzcyBpcyBjb25zaWRlcmVkIHdyb25n LCBpZjoNCiAgICAgIG8gIHRoZSBrZXggYWxnb3JpdGhtIGFuZC9vciB0aGUg aG9zdCBrZXkgYWxnb3JpdGhtIGlzIGd1ZXNzZWQNCiAgICAgICAgIHdyb25n IChzZXJ2ZXIgYW5kIGNsaWVudCBoYXZlIGRpZmZlcmVudCBwcmVmZXJyZWQg YWxnb3JpdGhtKSwNCiAgICAgICAgIG9yDQogICAgICBvICBpZiBhbnkgb2Yg dGhlIG90aGVyIGFsZ29yaXRobXMgY2Fubm90IGJlIGFncmVlZCB1cG9uICh0 aGUNCiAgICAgICAgIHByb2NlZHVyZSBpcyBkZWZpbmVkIGJlbG93IGluIFNl Y3Rpb24gU2VjdGlvbiA1LjEpLg0KDQogICAgICBPdGhlcndpc2UsIHRoZSBn dWVzcyBpcyBjb25zaWRlcmVkIHRvIGJlIHJpZ2h0IGFuZCB0aGUNCiAgICAg IG9wdGltaXN0aWNhbGx5IHNlbnQgcGFja2V0IE1VU1QgYmUgaGFuZGxlZCBh cyB0aGUgZmlyc3Qga2V5DQogICAgICBleGNoYW5nZSBwYWNrZXQuDQoNCiAg ICAgIEhvd2V2ZXIsIGlmIHRoZSBndWVzcyB3YXMgd3JvbmcsIGFuZCBhIHBh Y2tldCB3YXMgb3B0aW1pc3RpY2FsbHkNCiAgICAgIHNlbnQgYnkgb25lIG9y IGJvdGggcGFydGllcywgc3VjaCBwYWNrZXRzIE1VU1QgYmUgaWdub3JlZCAo ZXZlbiBpZg0KICAgICAgdGhlIGVycm9yIGluIHRoZSBndWVzcyB3b3VsZCBu b3QgYWZmZWN0IHRoZSBjb250ZW50cyBvZiB0aGUNCiAgICAgIGluaXRpYWwg cGFja2V0KHMpKSwgYW5kIHRoZSBhcHByb3ByaWF0ZSBzaWRlIE1VU1Qgc2Vu ZCB0aGUgY29ycmVjdA0KICAgICAgaW5pdGlhbCBwYWNrZXQuDQoNCiAgICAg IFNlcnZlciBhdXRoZW50aWNhdGlvbiBpbiB0aGUga2V5IGV4Y2hhbmdlIE1B WSBiZSBpbXBsaWNpdC4gIEFmdGVyDQogICAgICBhIGtleSBleGNoYW5nZSB3 aXRoIGltcGxpY2l0IHNlcnZlciBhdXRoZW50aWNhdGlvbiwgdGhlIGNsaWVu dA0KICAgICAgTVVTVCB3YWl0IGZvciByZXNwb25zZSB0byBpdHMgc2Vydmlj ZSByZXF1ZXN0IG1lc3NhZ2UgYmVmb3JlDQogICAgICBzZW5kaW5nIGFueSBm dXJ0aGVyIGRhdGEuDQoNCiAgIDUuMSBBbGdvcml0aG0gTmVnb3RpYXRpb24N Cg0KICAgS2V5IGV4Y2hhbmdlIGJlZ2lucyBieSBlYWNoIHNpZGUgc2VuZGlu ZyB0aGUgZm9sbG93aW5nIHBhY2tldDoNCg0KICAgICBieXRlICAgICAgU1NI X01TR19LRVhJTklUDQogICAgIGJ5dGVbMTZdICBjb29raWUgKHJhbmRvbSBi eXRlcykNCiAgICAgc3RyaW5nICAgIGtleF9hbGdvcml0aG1zDQogICAgIHN0 cmluZyAgICBzZXJ2ZXJfaG9zdF9rZXlfYWxnb3JpdGhtcw0KICAgICBzdHJp bmcgICAgZW5jcnlwdGlvbl9hbGdvcml0aG1zX2NsaWVudF90b19zZXJ2ZXIN CiAgICAgc3RyaW5nICAgIGVuY3J5cHRpb25fYWxnb3JpdGhtc19zZXJ2ZXJf dG9fY2xpZW50DQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBp cmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxNF0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICBTU0ggVHJhbnNwb3J0IExheWVy IFByb3RvY29sICAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgc3Ry aW5nICAgIG1hY19hbGdvcml0aG1zX2NsaWVudF90b19zZXJ2ZXINCiAgICAg c3RyaW5nICAgIG1hY19hbGdvcml0aG1zX3NlcnZlcl90b19jbGllbnQNCiAg ICAgc3RyaW5nICAgIGNvbXByZXNzaW9uX2FsZ29yaXRobXNfY2xpZW50X3Rv X3NlcnZlcg0KICAgICBzdHJpbmcgICAgY29tcHJlc3Npb25fYWxnb3JpdGht c19zZXJ2ZXJfdG9fY2xpZW50DQogICAgIHN0cmluZyAgICBsYW5ndWFnZXNf Y2xpZW50X3RvX3NlcnZlcg0KICAgICBzdHJpbmcgICAgbGFuZ3VhZ2VzX3Nl cnZlcl90b19jbGllbnQNCiAgICAgYm9vbGVhbiAgIGZpcnN0X2tleF9wYWNr ZXRfZm9sbG93cw0KICAgICB1aW50MzIgICAgMCAocmVzZXJ2ZWQgZm9yIGZ1 dHVyZSBleHRlbnNpb24pDQoNCiAgICAgIEVhY2ggb2YgdGhlIGFsZ29yaXRo bSBzdHJpbmdzIE1VU1QgYmUgYSBjb21tYS1zZXBhcmF0ZWQgbGlzdCBvZg0K ICAgICAgYWxnb3JpdGhtIG5hbWVzIChzZWUgJydBbGdvcml0aG0gTmFtaW5n JycgaW4gW1NTSC1BUkNIXSkuICBFYWNoDQogICAgICBzdXBwb3J0ZWQgKGFs bG93ZWQpIGFsZ29yaXRobSBNVVNUIGJlIGxpc3RlZCBpbiBvcmRlciBvZg0K ICAgICAgcHJlZmVyZW5jZS4NCg0KICAgICAgVGhlIGZpcnN0IGFsZ29yaXRo bSBpbiBlYWNoIGxpc3QgTVVTVCBiZSB0aGUgcHJlZmVycmVkIChndWVzc2Vk KQ0KICAgICAgYWxnb3JpdGhtLiAgRWFjaCBzdHJpbmcgTVVTVCBjb250YWlu IGF0IGxlYXN0IG9uZSBhbGdvcml0aG0gbmFtZS4NCg0KDQogICAgICAgICBj b29raWUNCiAgICAgICAgICAgIFRoZSBjb29raWUgTVVTVCBiZSBhIHJhbmRv bSB2YWx1ZSBnZW5lcmF0ZWQgYnkgdGhlIHNlbmRlci4NCiAgICAgICAgICAg IEl0cyBwdXJwb3NlIGlzIHRvIG1ha2UgaXQgaW1wb3NzaWJsZSBmb3IgZWl0 aGVyIHNpZGUgdG8NCiAgICAgICAgICAgIGZ1bGx5IGRldGVybWluZSB0aGUg a2V5cyBhbmQgdGhlIHNlc3Npb24gaWRlbnRpZmllci4NCg0KICAgICAgICAg a2V4X2FsZ29yaXRobXMNCiAgICAgICAgICAgIEtleSBleGNoYW5nZSBhbGdv cml0aG1zIHdlcmUgZGVmaW5lZCBhYm92ZS4gIFRoZSBmaXJzdA0KICAgICAg ICAgICAgYWxnb3JpdGhtIE1VU1QgYmUgdGhlIHByZWZlcnJlZCAoYW5kIGd1 ZXNzZWQpIGFsZ29yaXRobS4gIElmDQogICAgICAgICAgICBib3RoIHNpZGVz IG1ha2UgdGhlIHNhbWUgZ3Vlc3MsIHRoYXQgYWxnb3JpdGhtIE1VU1QgYmUg dXNlZC4NCiAgICAgICAgICAgIE90aGVyd2lzZSwgdGhlIGZvbGxvd2luZyBh bGdvcml0aG0gTVVTVCBiZSB1c2VkIHRvIGNob29zZSBhDQogICAgICAgICAg ICBrZXkgZXhjaGFuZ2UgbWV0aG9kOiBpdGVyYXRlIG92ZXIgY2xpZW50J3Mg a2V4IGFsZ29yaXRobXMsDQogICAgICAgICAgICBvbmUgYXQgYSB0aW1lLiAg Q2hvb3NlIHRoZSBmaXJzdCBhbGdvcml0aG0gdGhhdCBzYXRpc2ZpZXMNCiAg ICAgICAgICAgIHRoZSBmb2xsb3dpbmcgY29uZGl0aW9uczoNCiAgICAgICAg ICAgICsgIHRoZSBzZXJ2ZXIgYWxzbyBzdXBwb3J0cyB0aGUgYWxnb3JpdGht LA0KICAgICAgICAgICAgKyAgaWYgdGhlIGFsZ29yaXRobSByZXF1aXJlcyBh biBlbmNyeXB0aW9uLWNhcGFibGUgaG9zdCBrZXksDQogICAgICAgICAgICAg ICB0aGVyZSBpcyBhbiBlbmNyeXB0aW9uLWNhcGFibGUgYWxnb3JpdGhtIG9u IHRoZSBzZXJ2ZXIncw0KICAgICAgICAgICAgICAgc2VydmVyX2hvc3Rfa2V5 X2FsZ29yaXRobXMgdGhhdCBpcyBhbHNvIHN1cHBvcnRlZCBieSB0aGUNCiAg ICAgICAgICAgICAgIGNsaWVudCwgYW5kDQogICAgICAgICAgICArICBpZiB0 aGUgYWxnb3JpdGhtIHJlcXVpcmVzIGEgc2lnbmF0dXJlLWNhcGFibGUgaG9z dCBrZXksDQogICAgICAgICAgICAgICB0aGVyZSBpcyBhIHNpZ25hdHVyZS1j YXBhYmxlIGFsZ29yaXRobSBvbiB0aGUgc2VydmVyJ3MNCiAgICAgICAgICAg ICAgIHNlcnZlcl9ob3N0X2tleV9hbGdvcml0aG1zIHRoYXQgaXMgYWxzbyBz dXBwb3J0ZWQgYnkgdGhlDQogICAgICAgICAgICAgICBjbGllbnQuDQogICAg ICAgICAgICArICBJZiBubyBhbGdvcml0aG0gc2F0aXNmeWluZyBhbGwgdGhl c2UgY29uZGl0aW9ucyBjYW4gYmUNCiAgICAgICAgICAgICAgIGZvdW5kLCB0 aGUgY29ubmVjdGlvbiBmYWlscywgYW5kIGJvdGggc2lkZXMgTVVTVA0KICAg ICAgICAgICAgICAgZGlzY29ubmVjdC4NCg0KICAgICAgICAgc2VydmVyX2hv c3Rfa2V5X2FsZ29yaXRobXMNCiAgICAgICAgICAgIExpc3Qgb2YgdGhlIGFs Z29yaXRobXMgc3VwcG9ydGVkIGZvciB0aGUgc2VydmVyIGhvc3Qga2V5Lg0K ICAgICAgICAgICAgVGhlIHNlcnZlciBsaXN0cyB0aGUgYWxnb3JpdGhtcyBm b3Igd2hpY2ggaXQgaGFzIGhvc3Qga2V5czsNCiAgICAgICAgICAgIHRoZSBj bGllbnQgbGlzdHMgdGhlIGFsZ29yaXRobXMgdGhhdCBpdCBpcyB3aWxsaW5n IHRvDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEph bnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCklu dGVybmV0LURyYWZ0ICAgICAgICBTU0ggVHJhbnNwb3J0IExheWVyIFByb3Rv Y29sICAgICAgICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgICAgICAgICAgIGFj Y2VwdC4gIChUaGVyZSBNQVkgYmUgbXVsdGlwbGUgaG9zdCBrZXlzIGZvciBh IGhvc3QsDQogICAgICAgICAgICBwb3NzaWJseSB3aXRoIGRpZmZlcmVudCBh bGdvcml0aG1zLikNCg0KICAgICAgICAgICAgU29tZSBob3N0IGtleXMgbWF5 IG5vdCBzdXBwb3J0IGJvdGggc2lnbmF0dXJlcyBhbmQNCiAgICAgICAgICAg IGVuY3J5cHRpb24gKHRoaXMgY2FuIGJlIGRldGVybWluZWQgZnJvbSB0aGUg YWxnb3JpdGhtKSwgYW5kDQogICAgICAgICAgICB0aHVzIG5vdCBhbGwgaG9z dCBrZXlzIGFyZSB2YWxpZCBmb3IgYWxsIGtleSBleGNoYW5nZQ0KICAgICAg ICAgICAgbWV0aG9kcy4NCg0KICAgICAgICAgICAgQWxnb3JpdGhtIHNlbGVj dGlvbiBkZXBlbmRzIG9uIHdoZXRoZXIgdGhlIGNob3NlbiBrZXkNCiAgICAg ICAgICAgIGV4Y2hhbmdlIGFsZ29yaXRobSByZXF1aXJlcyBhIHNpZ25hdHVy ZSBvciBlbmNyeXB0aW9uDQogICAgICAgICAgICBjYXBhYmxlIGhvc3Qga2V5 LiAgSXQgTVVTVCBiZSBwb3NzaWJsZSB0byBkZXRlcm1pbmUgdGhpcw0KICAg ICAgICAgICAgZnJvbSB0aGUgcHVibGljIGtleSBhbGdvcml0aG0gbmFtZS4g IFRoZSBmaXJzdCBhbGdvcml0aG0gb24NCiAgICAgICAgICAgIHRoZSBjbGll bnQncyBsaXN0IHRoYXQgc2F0aXNmaWVzIHRoZSByZXF1aXJlbWVudHMgYW5k IGlzDQogICAgICAgICAgICBhbHNvIHN1cHBvcnRlZCBieSB0aGUgc2VydmVy IE1VU1QgYmUgY2hvc2VuLiAgSWYgdGhlcmUgaXMgbm8NCiAgICAgICAgICAg IHN1Y2ggYWxnb3JpdGhtLCBib3RoIHNpZGVzIE1VU1QgZGlzY29ubmVjdC4N Cg0KICAgICAgICAgZW5jcnlwdGlvbl9hbGdvcml0aG1zDQogICAgICAgICAg ICBMaXN0cyB0aGUgYWNjZXB0YWJsZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBh bGdvcml0aG1zIGluDQogICAgICAgICAgICBvcmRlciBvZiBwcmVmZXJlbmNl LiAgVGhlIGNob3NlbiBlbmNyeXB0aW9uIGFsZ29yaXRobSB0bw0KICAgICAg ICAgICAgZWFjaCBkaXJlY3Rpb24gTVVTVCBiZSB0aGUgZmlyc3QgYWxnb3Jp dGhtICBvbiB0aGUgY2xpZW50J3MNCiAgICAgICAgICAgIGxpc3QgdGhhdCBp cyBhbHNvIG9uIHRoZSBzZXJ2ZXIncyBsaXN0LiAgSWYgdGhlcmUgaXMgbm8g c3VjaA0KICAgICAgICAgICAgYWxnb3JpdGhtLCBib3RoIHNpZGVzIE1VU1Qg ZGlzY29ubmVjdC4NCg0KICAgICAgICAgICAgTm90ZSB0aGF0ICJub25lIiBt dXN0IGJlIGV4cGxpY2l0bHkgbGlzdGVkIGlmIGl0IGlzIHRvIGJlDQogICAg ICAgICAgICBhY2NlcHRhYmxlLiAgVGhlIGRlZmluZWQgYWxnb3JpdGhtIG5h bWVzIGFyZSBsaXN0ZWQgaW4NCiAgICAgICAgICAgIFNlY3Rpb24gU2VjdGlv biA0LjMuDQoNCiAgICAgICAgIG1hY19hbGdvcml0aG1zDQogICAgICAgICAg ICBMaXN0cyB0aGUgYWNjZXB0YWJsZSBNQUMgYWxnb3JpdGhtcyBpbiBvcmRl ciBvZiBwcmVmZXJlbmNlLg0KICAgICAgICAgICAgVGhlIGNob3NlbiBNQUMg YWxnb3JpdGhtIE1VU1QgYmUgdGhlIGZpcnN0IGFsZ29yaXRobSBvbiB0aGUN CiAgICAgICAgICAgIGNsaWVudCdzIGxpc3QgdGhhdCBpcyBhbHNvIG9uIHRo ZSBzZXJ2ZXIncyBsaXN0LiAgSWYgdGhlcmUNCiAgICAgICAgICAgIGlzIG5v IHN1Y2ggYWxnb3JpdGhtLCBib3RoIHNpZGVzIE1VU1QgZGlzY29ubmVjdC4N Cg0KICAgICAgICAgICAgTm90ZSB0aGF0ICJub25lIiBtdXN0IGJlIGV4cGxp Y2l0bHkgbGlzdGVkIGlmIGl0IGlzIHRvIGJlDQogICAgICAgICAgICBhY2Nl cHRhYmxlLiAgVGhlIE1BQyBhbGdvcml0aG0gbmFtZXMgYXJlIGxpc3RlZCBp biBTZWN0aW9uDQogICAgICAgICAgICBGaWd1cmUgMS4NCg0KICAgICAgICAg Y29tcHJlc3Npb25fYWxnb3JpdGhtcw0KICAgICAgICAgICAgTGlzdHMgdGhl IGFjY2VwdGFibGUgY29tcHJlc3Npb24gYWxnb3JpdGhtcyBpbiBvcmRlciBv Zg0KICAgICAgICAgICAgcHJlZmVyZW5jZS4gIFRoZSBjaG9zZW4gY29tcHJl c3Npb24gYWxnb3JpdGhtIE1VU1QgYmUgdGhlDQogICAgICAgICAgICBmaXJz dCBhbGdvcml0aG0gb24gdGhlIGNsaWVudCdzIGxpc3QgdGhhdCBpcyBhbHNv IG9uIHRoZQ0KICAgICAgICAgICAgc2VydmVyJ3MgbGlzdC4gIElmIHRoZXJl IGlzIG5vIHN1Y2ggYWxnb3JpdGhtLCBib3RoIHNpZGVzDQogICAgICAgICAg ICBNVVNUIGRpc2Nvbm5lY3QuDQoNCiAgICAgICAgICAgIE5vdGUgdGhhdCAi bm9uZSIgbXVzdCBiZSBleHBsaWNpdGx5IGxpc3RlZCBpZiBpdCBpcyB0byBi ZQ0KICAgICAgICAgICAgYWNjZXB0YWJsZS4gIFRoZSBjb21wcmVzc2lvbiBh bGdvcml0aG0gbmFtZXMgYXJlIGxpc3RlZCBpbg0KICAgICAgICAgICAgU2Vj dGlvbiBTZWN0aW9uIDQuMi4NCg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAg ICAgICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAg W1BhZ2UgMTZdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5z cG9ydCBMYXllciBQcm90b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0K DQogICAgICAgICBsYW5ndWFnZXMNCiAgICAgICAgICAgIFRoaXMgaXMgYSBj b21tYS1zZXBhcmF0ZWQgbGlzdCBvZiBsYW5ndWFnZSB0YWdzIGluIG9yZGVy IG9mDQogICAgICAgICAgICBwcmVmZXJlbmNlIFtSRkMxNzY2XS4gIEJvdGgg cGFydGllcyBNQVkgaWdub3JlIHRoaXMgbGlzdC4NCiAgICAgICAgICAgIElm IHRoZXJlIGFyZSBubyBsYW5ndWFnZSBwcmVmZXJlbmNlcywgdGhpcyBsaXN0 IFNIT1VMRCBiZQ0KICAgICAgICAgICAgZW1wdHkuDQoNCiAgICAgICAgIGZp cnN0X2tleF9wYWNrZXRfZm9sbG93cw0KICAgICAgICAgICAgSW5kaWNhdGVz IHdoZXRoZXIgYSBndWVzc2VkIGtleSBleGNoYW5nZSBwYWNrZXQgZm9sbG93 cy4gIElmDQogICAgICAgICAgICBhIGd1ZXNzZWQgcGFja2V0IHdpbGwgYmUg c2VudCwgdGhpcyBNVVNUIGJlIFRSVUUuICBJZiBubw0KICAgICAgICAgICAg Z3Vlc3NlZCBwYWNrZXQgd2lsbCBiZSBzZW50LCB0aGlzIE1VU1QgYmUgRkFM U0UuDQoNCiAgICAgICAgICAgIEFmdGVyIHJlY2VpdmluZyB0aGUgU1NIX01T R19LRVhJTklUIHBhY2tldCBmcm9tIHRoZSBvdGhlcg0KICAgICAgICAgICAg c2lkZSwgZWFjaCBwYXJ0eSB3aWxsIGtub3cgd2hldGhlciB0aGVpciBndWVz cyB3YXMgcmlnaHQuDQogICAgICAgICAgICBJZiB0aGUgb3RoZXIgcGFydHkn cyBndWVzcyB3YXMgd3JvbmcsIGFuZCB0aGlzIGZpZWxkIHdhcw0KICAgICAg ICAgICAgVFJVRSwgdGhlIG5leHQgcGFja2V0IE1VU1QgYmUgc2lsZW50bHkg aWdub3JlZCwgYW5kIGJvdGgNCiAgICAgICAgICAgIHNpZGVzIE1VU1QgdGhl biBhY3QgYXMgZGV0ZXJtaW5lZCBieSB0aGUgbmVnb3RpYXRlZCBrZXkNCiAg ICAgICAgICAgIGV4Y2hhbmdlIG1ldGhvZC4gIElmIHRoZSBndWVzcyB3YXMg cmlnaHQsIGtleSBleGNoYW5nZSBNVVNUDQogICAgICAgICAgICBjb250aW51 ZSB1c2luZyB0aGUgZ3Vlc3NlZCBwYWNrZXQuDQoNCiAgICAgIEFmdGVyIHRo ZSBLRVhJTklUIHBhY2tldCBleGNoYW5nZSwgdGhlIGtleSBleGNoYW5nZSBh bGdvcml0aG0gaXMNCiAgICAgIHJ1bi4gIEl0IG1heSBpbnZvbHZlIHNldmVy YWwgcGFja2V0IGV4Y2hhbmdlcywgYXMgc3BlY2lmaWVkIGJ5IHRoZQ0KICAg ICAga2V5IGV4Y2hhbmdlIG1ldGhvZC4NCg0KICAgNS4yIE91dHB1dCBmcm9t IEtleSBFeGNoYW5nZQ0KDQogICAgICBUaGUga2V5IGV4Y2hhbmdlIHByb2R1 Y2VzIHR3byB2YWx1ZXM6IGEgc2hhcmVkIHNlY3JldCBLLCBhbmQgYW4NCiAg ICAgIGV4Y2hhbmdlIGhhc2ggSC4gIEVuY3J5cHRpb24gYW5kIGF1dGhlbnRp Y2F0aW9uIGtleXMgYXJlIGRlcml2ZWQNCiAgICAgIGZyb20gdGhlc2UuICBU aGUgZXhjaGFuZ2UgaGFzaCBIIGZyb20gdGhlIGZpcnN0IGtleSBleGNoYW5n ZSBpcw0KICAgICAgYWRkaXRpb25hbGx5IHVzZWQgYXMgdGhlIHNlc3Npb24g aWRlbnRpZmllciwgd2hpY2ggaXMgYSB1bmlxdWUNCiAgICAgIGlkZW50aWZp ZXIgZm9yIHRoaXMgY29ubmVjdGlvbi4gIEl0IGlzIHVzZWQgYnkgYXV0aGVu dGljYXRpb24NCiAgICAgIG1ldGhvZHMgYXMgYSBwYXJ0IG9mIHRoZSBkYXRh IHRoYXQgaXMgc2lnbmVkIGFzIGEgcHJvb2Ygb2YNCiAgICAgIHBvc3Nlc3Np b24gb2YgYSBwcml2YXRlIGtleS4gIE9uY2UgY29tcHV0ZWQsIHRoZSBzZXNz aW9uDQogICAgICBpZGVudGlmaWVyIGlzIG5vdCBjaGFuZ2VkLCBldmVuIGlm IGtleXMgYXJlIGxhdGVyIHJlLWV4Y2hhbmdlZC4NCg0KDQogICAgICBFYWNo IGtleSBleGNoYW5nZSBtZXRob2Qgc3BlY2lmaWVzIGEgaGFzaCBmdW5jdGlv biB0aGF0IGlzIHVzZWQgaW4NCiAgICAgIHRoZSBrZXkgZXhjaGFuZ2UuICBU aGUgc2FtZSBoYXNoIGFsZ29yaXRobSBNVVNUIGJlIHVzZWQgaW4ga2V5DQog ICAgICBkZXJpdmF0aW9uLiAgSGVyZSwgd2UnbGwgY2FsbCBpdCBIQVNILg0K DQoNCiAgICAgIEVuY3J5cHRpb24ga2V5cyBNVVNUIGJlIGNvbXB1dGVkIGFz IEhBU0ggb2YgYSBrbm93biB2YWx1ZSBhbmQgSyBhcw0KICAgICAgZm9sbG93 czoNCiAgICAgIG8gIEluaXRpYWwgSVYgY2xpZW50IHRvIHNlcnZlcjogSEFT SChLIHx8IEggfHwgIkEiIHx8IHNlc3Npb25faWQpDQogICAgICAgICAoSGVy ZSBLIGlzIGVuY29kZWQgYXMgbXBpbnQgYW5kICJBIiBhcyBieXRlIGFuZCBz ZXNzaW9uX2lkIGFzDQogICAgICAgICByYXcgZGF0YS4iQSIgbWVhbnMgdGhl IHNpbmdsZSBjaGFyYWN0ZXIgQSwgQVNDSUkgNjUpLg0KICAgICAgbyAgSW5p dGlhbCBJViBzZXJ2ZXIgdG8gY2xpZW50OiBIQVNIKEsgfHwgSCB8fCAiQiIg fHwgc2Vzc2lvbl9pZCkNCiAgICAgIG8gIEVuY3J5cHRpb24ga2V5IGNsaWVu dCB0byBzZXJ2ZXI6IEhBU0goSyB8fCBIIHx8ICJDIiB8fA0KICAgICAgICAg c2Vzc2lvbl9pZCkNCg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgIEV4 cGlyZXMgSmFudWFyeSAxMiwgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDE3 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFNTSCBUcmFuc3BvcnQgTGF5 ZXIgUHJvdG9jb2wgICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KICAgICAg byAgRW5jcnlwdGlvbiBrZXkgc2VydmVyIHRvIGNsaWVudDogSEFTSChLIHx8 IEggfHwgIkQiIHx8DQogICAgICAgICBzZXNzaW9uX2lkKQ0KICAgICAgbyAg SW50ZWdyaXR5IGtleSBjbGllbnQgdG8gc2VydmVyOiBIQVNIKEsgfHwgSCB8 fCAiRSIgfHwNCiAgICAgICAgIHNlc3Npb25faWQpDQogICAgICBvICBJbnRl Z3JpdHkga2V5IHNlcnZlciB0byBjbGllbnQ6IEhBU0goSyB8fCBIIHx8ICJG IiB8fA0KICAgICAgICAgc2Vzc2lvbl9pZCkNCg0KICAgICAgS2V5IGRhdGEg TVVTVCBiZSB0YWtlbiBmcm9tIHRoZSBiZWdpbm5pbmcgb2YgdGhlIGhhc2gg b3V0cHV0LiAgMTI4DQogICAgICBiaXRzICgxNiBieXRlcykgU0hPVUxEIGJl IHVzZWQgZm9yIGFsZ29yaXRobXMgd2l0aCB2YXJpYWJsZS1sZW5ndGgNCiAg ICAgIGtleXMuICBGb3Igb3RoZXIgYWxnb3JpdGhtcywgYXMgbWFueSBieXRl cyBhcyBhcmUgbmVlZGVkIGFyZSB0YWtlbg0KICAgICAgZnJvbSB0aGUgYmVn aW5uaW5nIG9mIHRoZSBoYXNoIHZhbHVlLiAgSWYgdGhlIGtleSBsZW5ndGgg aW4gbG9uZ2VyDQogICAgICB0aGFuIHRoZSBvdXRwdXQgb2YgdGhlIEhBU0gs IHRoZSBrZXkgaXMgZXh0ZW5kZWQgYnkgY29tcHV0aW5nIEhBU0gNCiAgICAg IG9mIHRoZSBjb25jYXRlbmF0aW9uIG9mIEsgYW5kIEggYW5kIHRoZSBlbnRp cmUga2V5IHNvIGZhciwgYW5kDQogICAgICBhcHBlbmRpbmcgdGhlIHJlc3Vs dGluZyBieXRlcyAoYXMgbWFueSBhcyBIQVNIIGdlbmVyYXRlcykgdG8gdGhl DQogICAgICBrZXkuICBUaGlzIHByb2Nlc3MgaXMgcmVwZWF0ZWQgdW50aWwg ZW5vdWdoIGtleSBtYXRlcmlhbCBpcw0KICAgICAgYXZhaWxhYmxlOyB0aGUg a2V5IGlzIHRha2VuIGZyb20gdGhlIGJlZ2lubmluZyBvZiB0aGlzIHZhbHVl LiAgSW4NCiAgICAgIG90aGVyIHdvcmRzOg0KDQogICAgIEsxID0gSEFTSChL IHx8IEggfHwgWCB8fCBzZXNzaW9uX2lkKSAgIChYIGlzIGUuZy4gIkEiKQ0K ICAgICBLMiA9IEhBU0goSyB8fCBIIHx8IEsxKQ0KICAgICBLMyA9IEhBU0go SyB8fCBIIHx8IEsxIHx8IEsyKQ0KICAgICAuLi4NCiAgICAga2V5ID0gSzEg fHwgSzIgfHwgSzMgfHwgLi4uDQoNCiAgICAgIFRoaXMgcHJvY2VzcyB3aWxs IGxvc2UgZW50cm9weSBpZiB0aGUgYW1vdW50IG9mIGVudHJvcHkgaW4gSyBp cw0KICAgICAgbGFyZ2VyIHRoYW4gdGhlIGludGVybmFsIHN0YXRlIHNpemUg b2YgSEFTSC4NCg0KICAgNS4zIFRha2luZyBLZXlzIEludG8gVXNlDQoNCiAg ICAgIEtleSBleGNoYW5nZSBlbmRzIGJ5IGVhY2ggc2lkZSBzZW5kaW5nIGFu IFNTSF9NU0dfTkVXS0VZUyBtZXNzYWdlLg0KICAgICAgVGhpcyBtZXNzYWdl IGlzIHNlbnQgd2l0aCB0aGUgb2xkIGtleXMgYW5kIGFsZ29yaXRobXMuICBB bGwNCiAgICAgIG1lc3NhZ2VzIHNlbnQgYWZ0ZXIgdGhpcyBtZXNzYWdlIE1V U1QgdXNlIHRoZSBuZXcga2V5cyBhbmQNCiAgICAgIGFsZ29yaXRobXMuDQoN Cg0KICAgICAgV2hlbiB0aGlzIG1lc3NhZ2UgaXMgcmVjZWl2ZWQsIHRoZSBu ZXcga2V5cyBhbmQgYWxnb3JpdGhtcyBNVVNUIGJlDQogICAgICB0YWtlbiBp bnRvIHVzZSBmb3IgcmVjZWl2aW5nLg0KDQoNCiAgICAgIFRoaXMgbWVzc2Fn ZSBpcyB0aGUgb25seSB2YWxpZCBtZXNzYWdlIGFmdGVyIGtleSBleGNoYW5n ZSwgaW4NCiAgICAgIGFkZGl0aW9uIHRvIFNTSF9NU0dfREVCVUcsIFNTSF9N U0dfRElTQ09OTkVDVCBhbmQgU1NIX01TR19JR05PUkUNCiAgICAgIG1lc3Nh Z2VzLiAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBtZXNzYWdlIGlzIHRvIGVuc3Vy ZSB0aGF0IGEgcGFydHkNCiAgICAgIGlzIGFibGUgdG8gcmVzcG9uZCB3aXRo IGEgZGlzY29ubmVjdCBtZXNzYWdlIHRoYXQgdGhlIG90aGVyIHBhcnR5DQog ICAgICBjYW4gdW5kZXJzdGFuZCBpZiBzb21ldGhpbmcgZ29lcyB3cm9uZyB3 aXRoIHRoZSBrZXkgZXhjaGFuZ2UuDQogICAgICBJbXBsZW1lbnRhdGlvbnMg TVVTVCBOT1QgYWNjZXB0IGFueSBvdGhlciBtZXNzYWdlcyBhZnRlciBrZXkN CiAgICAgIGV4Y2hhbmdlIGJlZm9yZSByZWNlaXZpbmcgU1NIX01TR19ORVdL RVlTLg0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNHX05FV0tFWVMNCg0KDQoN Cllsb25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwg MjAwNCAgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KSW50ZXJuZXQtRHJh ZnQgICAgICAgIFNTSCBUcmFuc3BvcnQgTGF5ZXIgUHJvdG9jb2wgICAgICAg ICAgICAgSnVseSAyMDAzDQoNCg0KICAgNi4gRGlmZmllLUhlbGxtYW4gS2V5 IEV4Y2hhbmdlDQoNCiAgICAgIFRoZSBEaWZmaWUtSGVsbG1hbiBrZXkgZXhj aGFuZ2UgcHJvdmlkZXMgYSBzaGFyZWQgc2VjcmV0IHRoYXQgY2FuDQogICAg ICBub3QgYmUgZGV0ZXJtaW5lZCBieSBlaXRoZXIgcGFydHkgYWxvbmUuICBU aGUga2V5IGV4Y2hhbmdlIGlzDQogICAgICBjb21iaW5lZCB3aXRoIGEgc2ln bmF0dXJlIHdpdGggdGhlIGhvc3Qga2V5IHRvIHByb3ZpZGUgaG9zdA0KICAg ICAgYXV0aGVudGljYXRpb24uDQoNCg0KICAgICAgSW4gdGhlIGZvbGxvd2lu ZyBkZXNjcmlwdGlvbiAoQyBpcyB0aGUgY2xpZW50LCBTIGlzIHRoZSBzZXJ2 ZXI7IHANCiAgICAgIGlzIGEgbGFyZ2Ugc2FmZSBwcmltZSwgZyBpcyBhIGdl bmVyYXRvciBmb3IgYSBzdWJncm91cCBvZiBHRihwKSwNCiAgICAgIGFuZCBx IGlzIHRoZSBvcmRlciBvZiB0aGUgc3ViZ3JvdXA7IFZfUyBpcyBTJ3MgdmVy c2lvbiBzdHJpbmc7IFZfQw0KICAgICAgaXMgQydzIHZlcnNpb24gc3RyaW5n OyBLX1MgaXMgUydzIHB1YmxpYyBob3N0IGtleTsgSV9DIGlzIEMncw0KICAg ICAgS0VYSU5JVCAgbWVzc2FnZSBhbmQgSV9TIFMncyBLRVhJTklUIG1lc3Nh Z2Ugd2hpY2ggaGF2ZSBiZWVuDQogICAgICBleGNoYW5nZWQgYmVmb3JlIHRo aXMgcGFydCBiZWdpbnMpOg0KDQoNCiAgICAgIDEuICBDIGdlbmVyYXRlcyBh IHJhbmRvbSBudW1iZXIgeCAoMSA8IHggPCBxKSBhbmQgY29tcHV0ZXMgZSA9 IGdeeA0KICAgICAgICAgIG1vZCBwLiAgQyBzZW5kcyAiZSIgdG8gUy4NCg0K ICAgICAgMi4gIFMgZ2VuZXJhdGVzIGEgcmFuZG9tIG51bWJlciB5ICgwIDwg eSA8IHEpIGFuZCBjb21wdXRlcyBmID0gZ155DQogICAgICAgICAgbW9kIHAu ICBTIHJlY2VpdmVzICJlIi4gIEl0IGNvbXB1dGVzIEsgPSBlXnkgbW9kIHAs IEggPQ0KICAgICAgICAgIGhhc2goVl9DIHx8IFZfUyB8fCBJX0MgfHwgSV9T IHx8IEtfUyB8fCBlIHx8IGYgfHwgSykgKHRoZXNlDQogICAgICAgICAgZWxl bWVudHMgYXJlIGVuY29kZWQgYWNjb3JkaW5nIHRvIHRoZWlyIHR5cGVzOyBz ZWUgYmVsb3cpLCBhbmQNCiAgICAgICAgICBzaWduYXR1cmUgcyBvbiBIIHdp dGggaXRzIHByaXZhdGUgaG9zdCBrZXkuICBTIHNlbmRzICJLX1MgfHwgZg0K ICAgICAgICAgIHx8IHMiIHRvIEMuICBUaGUgc2lnbmluZyBvcGVyYXRpb24g bWF5IGludm9sdmUgYSBzZWNvbmQNCiAgICAgICAgICBoYXNoaW5nIG9wZXJh dGlvbi4NCg0KICAgICAgMy4gIEMgdmVyaWZpZXMgdGhhdCBLX1MgcmVhbGx5 IGlzIHRoZSBob3N0IGtleSBmb3IgUyAoZS5nLiAgdXNpbmcNCiAgICAgICAg ICBjZXJ0aWZpY2F0ZXMgb3IgYSBsb2NhbCBkYXRhYmFzZSkuICBDIGlzIGFs c28gYWxsb3dlZCB0bw0KICAgICAgICAgIGFjY2VwdCB0aGUga2V5IHdpdGhv dXQgdmVyaWZpY2F0aW9uOyBob3dldmVyLCBkb2luZyBzbyB3aWxsDQogICAg ICAgICAgcmVuZGVyIHRoZSBwcm90b2NvbCBpbnNlY3VyZSBhZ2FpbnN0IGFj dGl2ZSBhdHRhY2tzIChidXQgbWF5DQogICAgICAgICAgYmUgZGVzaXJhYmxl IGZvciBwcmFjdGljYWwgcmVhc29ucyBpbiB0aGUgc2hvcnQgdGVybSBpbiBt YW55DQogICAgICAgICAgZW52aXJvbm1lbnRzKS4gIEMgdGhlbiBjb21wdXRl cyBLID0gZl54IG1vZCBwLCBIID0gaGFzaChWX0MgfHwNCiAgICAgICAgICBW X1MgfHwgSV9DIHx8IElfUyB8fCBLX1MgfHwgZSB8fCBmIHx8IEspLCBhbmQg dmVyaWZpZXMgdGhlDQogICAgICAgICAgc2lnbmF0dXJlIHMgb24gSC4NCg0K ICAgICAgRWl0aGVyIHNpZGUgTVVTVCBOT1Qgc2VuZCBvciBhY2NlcHQgZSBv ciBmIHZhbHVlcyB0aGF0IGFyZSBub3QgaW4NCiAgICAgIHRoZSByYW5nZSBb MSwgcC0xXS4gIElmIHRoaXMgY29uZGl0aW9uIGlzIHZpb2xhdGVkLCB0aGUg a2V5DQogICAgICBleGNoYW5nZSBmYWlscy4NCg0KDQogICAgICBUaGlzIGlz IGltcGxlbWVudGVkIHdpdGggdGhlIGZvbGxvd2luZyBtZXNzYWdlcy4gIFRo ZSBoYXNoDQogICAgICBhbGdvcml0aG0gZm9yIGNvbXB1dGluZyB0aGUgZXhj aGFuZ2UgaGFzaCBpcyBkZWZpbmVkIGJ5IHRoZSBtZXRob2QNCiAgICAgIG5h bWUsIGFuZCBpcyBjYWxsZWQgSEFTSC4gIFRoZSBwdWJsaWMga2V5IGFsZ29y aXRobSBmb3Igc2lnbmluZyBpcw0KICAgICAgbmVnb3RpYXRlZCB3aXRoIHRo ZSBLRVhJTklUIG1lc3NhZ2VzLg0KDQogICBGaXJzdCwgdGhlIGNsaWVudCBz ZW5kcyB0aGUgZm9sbG93aW5nOg0KDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4g ICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAg ICBbUGFnZSAxOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBTU0ggVHJh bnNwb3J0IExheWVyIFByb3RvY29sICAgICAgICAgICAgIEp1bHkgMjAwMw0K DQoNCiAgICAgYnl0ZSAgICAgIFNTSF9NU0dfS0VYREhfSU5JVA0KICAgICBt cGludCAgICAgZQ0KDQoNCiAgIFRoZSBzZXJ2ZXIgcmVzcG9uZHMgd2l0aCB0 aGUgZm9sbG93aW5nOg0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNHX0tFWERI X1JFUExZDQogICAgIHN0cmluZyAgICBzZXJ2ZXIgcHVibGljIGhvc3Qga2V5 IGFuZCBjZXJ0aWZpY2F0ZXMgKEtfUykNCiAgICAgbXBpbnQgICAgIGYNCiAg ICAgc3RyaW5nICAgIHNpZ25hdHVyZSBvZiBIDQoNCiAgICAgIFRoZSBoYXNo IEggaXMgY29tcHV0ZWQgYXMgdGhlIEhBU0ggaGFzaCBvZiB0aGUgY29uY2F0 ZW5hdGlvbiBvZg0KICAgICAgdGhlIGZvbGxvd2luZzoNCg0KICAgICBzdHJp bmcgICAgVl9DLCB0aGUgY2xpZW50J3MgdmVyc2lvbiBzdHJpbmcgKENSIGFu ZCBOTCBleGNsdWRlZCkNCiAgICAgc3RyaW5nICAgIFZfUywgdGhlIHNlcnZl cidzIHZlcnNpb24gc3RyaW5nIChDUiBhbmQgTkwgZXhjbHVkZWQpDQogICAg IHN0cmluZyAgICBJX0MsIHRoZSBwYXlsb2FkIG9mIHRoZSBjbGllbnQncyBT U0hfTVNHX0tFWElOSVQNCiAgICAgc3RyaW5nICAgIElfUywgdGhlIHBheWxv YWQgb2YgdGhlIHNlcnZlcidzIFNTSF9NU0dfS0VYSU5JVA0KICAgICBzdHJp bmcgICAgS19TLCB0aGUgaG9zdCBrZXkNCiAgICAgbXBpbnQgICAgIGUsIGV4 Y2hhbmdlIHZhbHVlIHNlbnQgYnkgdGhlIGNsaWVudA0KICAgICBtcGludCAg ICAgZiwgZXhjaGFuZ2UgdmFsdWUgc2VudCBieSB0aGUgc2VydmVyDQogICAg IG1waW50ICAgICBLLCB0aGUgc2hhcmVkIHNlY3JldA0KDQogICAgICBUaGlz IHZhbHVlIGlzIGNhbGxlZCB0aGUgZXhjaGFuZ2UgaGFzaCwgYW5kIGl0IGlz IHVzZWQgdG8NCiAgICAgIGF1dGhlbnRpY2F0ZSB0aGUga2V5IGV4Y2hhbmdl LiAgVGhlIGV4Y2hhbmdlIGhhc2ggU0hPVUxEIGJlIGtlcHQNCiAgICAgIHNl Y3JldC4NCg0KDQogICAgICBUaGUgc2lnbmF0dXJlIGFsZ29yaXRobSBNVVNU IGJlIGFwcGxpZWQgb3ZlciBILCBub3QgdGhlIG9yaWdpbmFsDQogICAgICBk YXRhLiAgTW9zdCBzaWduYXR1cmUgYWxnb3JpdGhtcyBpbmNsdWRlIGhhc2hp bmcgYW5kIGFkZGl0aW9uYWwNCiAgICAgIHBhZGRpbmcuICBGb3IgZXhhbXBs ZSwgInNzaC1kc3MiIHNwZWNpZmllcyBTSEEtMSBoYXNoaW5nOyBpbiB0aGF0 DQogICAgICBjYXNlLCB0aGUgZGF0YSBpcyBmaXJzdCBoYXNoZWQgd2l0aCBI QVNIIHRvIGNvbXB1dGUgSCwgYW5kIEggaXMNCiAgICAgIHRoZW4gaGFzaGVk IHdpdGggU0hBLTEgYXMgcGFydCBvZiB0aGUgc2lnbmluZyBvcGVyYXRpb24u DQoNCiAgIDYuMSBkaWZmaWUtaGVsbG1hbi1ncm91cDEtc2hhMQ0KDQogICAg ICBUaGUgImRpZmZpZS1oZWxsbWFuLWdyb3VwMS1zaGExIiBtZXRob2Qgc3Bl Y2lmaWVzIERpZmZpZS1IZWxsbWFuDQogICAgICBrZXkgZXhjaGFuZ2Ugd2l0 aCBTSEEtMSBhcyBIQVNILCBhbmQgdGhlIGZvbGxvd2luZyBncm91cDoNCg0K ICAgICAgVGhlIHByaW1lIHAgaXMgZXF1YWwgdG8gMl4xMDI0IC0gMl45NjAg LSAxICsgMl42NCAqIGZsb29yKCAyXjg5NA0KICAgICAgUGkgKyAxMjkwOTMg KS4gIEl0cyBoZXhhZGVjaW1hbCB2YWx1ZSBpczoNCg0KICAgICAgICAgRkZG RkZGRkYgRkZGRkZGRkYgQzkwRkRBQTIgMjE2OEMyMzQgQzRDNjYyOEIgODBE QzFDRDENCiAgICAgICAgIDI5MDI0RTA4IDhBNjdDQzc0IDAyMEJCRUE2IDNC MTM5QjIyIDUxNEEwODc5IDhFMzQwNEREDQogICAgICAgICBFRjk1MTlCMyBD RDNBNDMxQiAzMDJCMEE2RCBGMjVGMTQzNyA0RkUxMzU2RCA2RDUxQzI0NQ0K ICAgICAgICAgRTQ4NUI1NzYgNjI1RTdFQzYgRjQ0QzQyRTkgQTYzN0VENkIg MEJGRjVDQjYgRjQwNkI3RUQNCiAgICAgICAgIEVFMzg2QkZCIDVBODk5RkE1 IEFFOUYyNDExIDdDNEIxRkU2IDQ5Mjg2NjUxIEVDRTY1MzgxDQogICAgICAg ICBGRkZGRkZGRiBGRkZGRkZGRi4NCg0KDQoNCllsb25lbiwgZXQuIGFsLiAg ICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAwNCAgICAgICAgICAgICAg IFtQYWdlIDIwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFNTSCBUcmFu c3BvcnQgTGF5ZXIgUHJvdG9jb2wgICAgICAgICAgICAgSnVseSAyMDAzDQoN Cg0KICAgICAgSW4gZGVjaW1hbCwgdGhpcyB2YWx1ZSBpczoNCg0KICAgICAg ICAgMTc5NzY5MzEzNDg2MjMxNTkwNzcwODM5MTU2NzkzNzg3NDUzMTk3ODYw Mjk2MDQ4NzU2MDExNzA2NDQ0DQogICAgICAgICA0MjM2ODQxOTcxODAyMTYx NTg1MTkzNjg5NDc4MzM3OTU4NjQ5MjU1NDE1MDIxODA1NjU0ODU5ODA1MDMN CiAgICAgICAgIDY0NjQ0MDU0ODE5OTIzOTEwMDA1MDc5Mjg3NzAwMzM1NTgx NjYzOTIyOTU1MzEzNjIzOTA3NjUwODczNQ0KICAgICAgICAgNzU5OTE0ODIy NTc0ODYyNTc1MDA3NDI1MzAyMDc3NDQ3NzEyNTg5NTUwOTU3OTM3Nzc4NDI0 NDQyNDI2DQogICAgICAgICA2MTczMzQ3Mjc2MjkyOTkzODc2Njg3MDkyMDU2 MDYwNTAyNzA4MTA4NDI5MDc2OTI5MzIwMTkxMjgxOTQNCiAgICAgICAgIDQ2 NzYyNzAwNy4NCg0KICAgICAgVGhlIGdlbmVyYXRvciB1c2VkIHdpdGggdGhp cyBwcmltZSBpcyBnID0gMi4gIFRoZSBncm91cCBvcmRlciBxIGlzDQogICAg ICAocCAtIDEpIC8gMi4NCg0KICAgICAgVGhpcyBncm91cCB3YXMgdGFrZW4g ZnJvbSB0aGUgSVNBS01QL09ha2xleSBzcGVjaWZpY2F0aW9uLCBhbmQgd2Fz DQogICAgICBvcmlnaW5hbGx5IGdlbmVyYXRlZCBieSBSaWNoYXJkIFNjaHJv ZXBwZWwgYXQgdGhlIFVuaXZlcnNpdHkgb2YNCiAgICAgIEFyaXpvbmEuICBQ cm9wZXJ0aWVzIG9mIHRoaXMgcHJpbWUgYXJlIGRlc2NyaWJlZCBpbiBbT3Jt OTZdLg0KDQogICA3LiBLZXkgUmUtRXhjaGFuZ2UNCg0KICAgICAgS2V5IHJl LWV4Y2hhbmdlIGlzIHN0YXJ0ZWQgYnkgc2VuZGluZyBhbiBTU0hfTVNHX0tF WElOSVQgcGFja2V0DQogICAgICB3aGVuIG5vdCBhbHJlYWR5IGRvaW5nIGEg a2V5IGV4Y2hhbmdlIChhcyBkZXNjcmliZWQgaW4gU2VjdGlvbg0KICAgICAg U2VjdGlvbiA1LjEpLiAgV2hlbiB0aGlzIG1lc3NhZ2UgaXMgcmVjZWl2ZWQs IGEgcGFydHkgTVVTVCByZXNwb25kDQogICAgICB3aXRoIGl0cyBvd24gU1NI X01TR19LRVhJTklUIG1lc3NhZ2UgZXhjZXB0IHdoZW4gdGhlIHJlY2VpdmVk DQogICAgICBTU0hfTVNHX0tFWElOSVQgYWxyZWFkeSB3YXMgYSByZXBseS4g IEVpdGhlciBwYXJ0eSBNQVkgaW5pdGlhdGUNCiAgICAgIHRoZSByZS1leGNo YW5nZSwgYnV0IHJvbGVzIE1VU1QgTk9UIGJlIGNoYW5nZWQgKGkuZS4sIHRo ZSBzZXJ2ZXINCiAgICAgIHJlbWFpbnMgdGhlIHNlcnZlciwgYW5kIHRoZSBj bGllbnQgcmVtYWlucyB0aGUgY2xpZW50KS4NCg0KDQogICAgICBLZXkgcmUt ZXhjaGFuZ2UgaXMgcGVyZm9ybWVkIHVzaW5nIHdoYXRldmVyIGVuY3J5cHRp b24gd2FzIGluDQogICAgICBlZmZlY3Qgd2hlbiB0aGUgZXhjaGFuZ2Ugd2Fz IHN0YXJ0ZWQuICBFbmNyeXB0aW9uLCBjb21wcmVzc2lvbiwNCiAgICAgIGFu ZCBNQUMgbWV0aG9kcyBhcmUgbm90IGNoYW5nZWQgYmVmb3JlIGEgbmV3IFNT SF9NU0dfTkVXS0VZUyBpcw0KICAgICAgc2VudCBhZnRlciB0aGUga2V5IGV4 Y2hhbmdlIChhcyBpbiB0aGUgaW5pdGlhbCBrZXkgZXhjaGFuZ2UpLiAgUmUt DQogICAgICBleGNoYW5nZSBpcyBwcm9jZXNzZWQgaWRlbnRpY2FsbHkgdG8g dGhlIGluaXRpYWwga2V5IGV4Y2hhbmdlLA0KICAgICAgZXhjZXB0IGZvciB0 aGUgc2Vzc2lvbiBpZGVudGlmaWVyIHRoYXQgd2lsbCByZW1haW4gdW5jaGFu Z2VkLiAgSXQNCiAgICAgIGlzIHBlcm1pc3NpYmxlIHRvIGNoYW5nZSBzb21l IG9yIGFsbCBvZiB0aGUgYWxnb3JpdGhtcyBkdXJpbmcgdGhlDQogICAgICBy ZS1leGNoYW5nZS4gIEhvc3Qga2V5cyBjYW4gYWxzbyBjaGFuZ2UuICBBbGwg a2V5cyBhbmQNCiAgICAgIGluaXRpYWxpemF0aW9uIHZlY3RvcnMgYXJlIHJl Y29tcHV0ZWQgYWZ0ZXIgdGhlIGV4Y2hhbmdlLg0KICAgICAgQ29tcHJlc3Np b24gYW5kIGVuY3J5cHRpb24gY29udGV4dHMgYXJlIHJlc2V0Lg0KDQoNCiAg ICAgIEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIGtleXMgYXJlIGNoYW5n ZWQgYWZ0ZXIgZWFjaCBnaWdhYnl0ZSBvZg0KICAgICAgdHJhbnNtaXR0ZWQg ZGF0YSBvciBhZnRlciBlYWNoIGhvdXIgb2YgY29ubmVjdGlvbiB0aW1lLCB3 aGljaGV2ZXINCiAgICAgIGNvbWVzIHNvb25lci4gIEhvd2V2ZXIsIHNpbmNl IHRoZSByZS1leGNoYW5nZSBpcyBhIHB1YmxpYyBrZXkNCiAgICAgIG9wZXJh dGlvbiwgaXQgcmVxdWlyZXMgYSBmYWlyIGFtb3VudCBvZiBwcm9jZXNzaW5n IHBvd2VyIGFuZA0KICAgICAgc2hvdWxkIG5vdCBiZSBwZXJmb3JtZWQgdG9v IG9mdGVuLg0KDQoNCiAgICAgIE1vcmUgYXBwbGljYXRpb24gZGF0YSBtYXkg YmUgc2VudCBhZnRlciB0aGUgU1NIX01TR19ORVdLRVlTIHBhY2tldA0KICAg ICAgaGFzIGJlZW4gc2VudDsga2V5IGV4Y2hhbmdlIGRvZXMgbm90IGFmZmVj dCB0aGUgcHJvdG9jb2xzIHRoYXQgbGllDQoNCg0KDQpZbG9uZW4sIGV0LiBh bC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAg ICAgICBbUGFnZSAyMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICBTU0gg VHJhbnNwb3J0IExheWVyIFByb3RvY29sICAgICAgICAgICAgIEp1bHkgMjAw Mw0KDQoNCiAgICAgIGFib3ZlIHRoZSBTU0ggdHJhbnNwb3J0IGxheWVyLg0K DQogICA4LiBTZXJ2aWNlIFJlcXVlc3QNCg0KICAgICAgQWZ0ZXIgdGhlIGtl eSBleGNoYW5nZSwgdGhlIGNsaWVudCByZXF1ZXN0cyBhIHNlcnZpY2UuICBU aGUNCiAgICAgIHNlcnZpY2UgaXMgaWRlbnRpZmllZCBieSBhIG5hbWUuICBU aGUgZm9ybWF0IG9mIG5hbWVzIGFuZA0KICAgICAgcHJvY2VkdXJlcyBmb3Ig ZGVmaW5pbmcgbmV3IG5hbWVzIGFyZSBkZWZpbmVkIGluIFtTU0gtQVJDSF0u DQoNCg0KICAgICAgQ3VycmVudGx5LCB0aGUgZm9sbG93aW5nIG5hbWVzIGhh dmUgYmVlbiByZXNlcnZlZDoNCg0KICAgICBzc2gtdXNlcmF1dGgNCiAgICAg c3NoLWNvbm5lY3Rpb24NCg0KICAgICAgU2ltaWxhciBsb2NhbCBuYW1pbmcg cG9saWN5IGlzIGFwcGxpZWQgdG8gdGhlIHNlcnZpY2UgbmFtZXMsIGFzIGlz DQogICAgICBhcHBsaWVkIHRvIHRoZSBhbGdvcml0aG0gbmFtZXM7IGEgbG9j YWwgc2VydmljZSBzaG91bGQgdXNlIHRoZQ0KICAgICAgInNlcnZpY2VuYW1l QGRvbWFpbiIgc3ludGF4Lg0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNHX1NF UlZJQ0VfUkVRVUVTVA0KICAgICBzdHJpbmcgICAgc2VydmljZSBuYW1lDQoN CiAgICAgIElmIHRoZSBzZXJ2ZXIgcmVqZWN0cyB0aGUgc2VydmljZSByZXF1 ZXN0LCBpdCBTSE9VTEQgc2VuZCBhbg0KICAgICAgYXBwcm9wcmlhdGUgU1NI X01TR19ESVNDT05ORUNUIG1lc3NhZ2UgYW5kIE1VU1QgZGlzY29ubmVjdC4N Cg0KDQogICAgICBXaGVuIHRoZSBzZXJ2aWNlIHN0YXJ0cywgaXQgbWF5IGhh dmUgYWNjZXNzIHRvIHRoZSBzZXNzaW9uDQogICAgICBpZGVudGlmaWVyIGdl bmVyYXRlZCBkdXJpbmcgdGhlIGtleSBleGNoYW5nZS4NCg0KDQogICAgICBJ ZiB0aGUgc2VydmVyIHN1cHBvcnRzIHRoZSBzZXJ2aWNlIChhbmQgcGVybWl0 cyB0aGUgY2xpZW50IHRvIHVzZQ0KICAgICAgaXQpLCBpdCBNVVNUIHJlc3Bv bmQgd2l0aCB0aGUgZm9sbG93aW5nOg0KDQogICAgIGJ5dGUgICAgICBTU0hf TVNHX1NFUlZJQ0VfQUNDRVBUDQogICAgIHN0cmluZyAgICBzZXJ2aWNlIG5h bWUNCg0KICAgICAgTWVzc2FnZSBudW1iZXJzIHVzZWQgYnkgc2VydmljZXMg c2hvdWxkIGJlIGluIHRoZSBhcmVhIHJlc2VydmVkDQogICAgICBmb3IgdGhl bSAoc2VlIFNlY3Rpb24gNiBpbiBbU1NILUFSQ0hdKS4gIFRoZSB0cmFuc3Bv cnQgbGV2ZWwgd2lsbA0KICAgICAgY29udGludWUgdG8gcHJvY2VzcyBpdHMg b3duIG1lc3NhZ2VzLg0KDQoNCiAgICAgIE5vdGUgdGhhdCBhZnRlciBhIGtl eSBleGNoYW5nZSB3aXRoIGltcGxpY2l0IHNlcnZlcg0KICAgICAgYXV0aGVu dGljYXRpb24sIHRoZSBjbGllbnQgTVVTVCB3YWl0IGZvciByZXNwb25zZSB0 byBpdHMgc2VydmljZQ0KICAgICAgcmVxdWVzdCBtZXNzYWdlIGJlZm9yZSBz ZW5kaW5nIGFueSBmdXJ0aGVyIGRhdGEuDQoNCiAgIDkuIEFkZGl0aW9uYWwg TWVzc2FnZXMNCg0KICAgICAgRWl0aGVyIHBhcnR5IG1heSBzZW5kIGFueSBv ZiB0aGUgZm9sbG93aW5nIG1lc3NhZ2VzIGF0IGFueSB0aW1lLg0KDQoNCg0K DQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVzIEphbnVhcnkgMTIs IDIwMDQgICAgICAgICAgICAgICBbUGFnZSAyMl0NCgwNCkludGVybmV0LURy YWZ0ICAgICAgICBTU0ggVHJhbnNwb3J0IExheWVyIFByb3RvY29sICAgICAg ICAgICAgIEp1bHkgMjAwMw0KDQoNCiAgIDkuMSBEaXNjb25uZWN0aW9uIE1l c3NhZ2UNCg0KICAgICBieXRlICAgICAgU1NIX01TR19ESVNDT05ORUNUDQog ICAgIHVpbnQzMiAgICByZWFzb24gY29kZQ0KICAgICBzdHJpbmcgICAgZGVz Y3JpcHRpb24gW1JGQzIyNzldDQogICAgIHN0cmluZyAgICBsYW5ndWFnZSB0 YWcgW1JGQzE3NjZdDQoNCiAgICAgIFRoaXMgbWVzc2FnZSBjYXVzZXMgaW1t ZWRpYXRlIHRlcm1pbmF0aW9uIG9mIHRoZSBjb25uZWN0aW9uLiAgQWxsDQog ICAgICBpbXBsZW1lbnRhdGlvbnMgTVVTVCBiZSBhYmxlIHRvIHByb2Nlc3Mg dGhpcyBtZXNzYWdlOyB0aGV5IFNIT1VMRA0KICAgICAgYmUgYWJsZSB0byBz ZW5kIHRoaXMgbWVzc2FnZS4NCg0KICAgICAgVGhlIHNlbmRlciBNVVNUIE5P VCBzZW5kIG9yIHJlY2VpdmUgYW55IGRhdGEgYWZ0ZXIgdGhpcyBtZXNzYWdl LA0KICAgICAgYW5kIHRoZSByZWNpcGllbnQgTVVTVCBOT1QgYWNjZXB0IGFu eSBkYXRhIGFmdGVyIHJlY2VpdmluZyB0aGlzDQogICAgICBtZXNzYWdlLiAg VGhlIGRlc2NyaXB0aW9uIGZpZWxkIGdpdmVzIGEgbW9yZSBzcGVjaWZpYyBl eHBsYW5hdGlvbg0KICAgICAgaW4gYSBodW1hbi1yZWFkYWJsZSBmb3JtLiAg VGhlIGVycm9yIGNvZGUgZ2l2ZXMgdGhlIHJlYXNvbiBpbiBhDQogICAgICBt b3JlIG1hY2hpbmUtcmVhZGFibGUgZm9ybWF0IChzdWl0YWJsZSBmb3IgbG9j YWxpemF0aW9uKSwgYW5kIGNhbg0KICAgICAgaGF2ZSB0aGUgZm9sbG93aW5n IHZhbHVlczoNCg0KICAgICAjZGVmaW5lIFNTSF9ESVNDT05ORUNUX0hPU1Rf Tk9UX0FMTE9XRURfVE9fQ09OTkVDVCAgICAgIDENCiAgICAgI2RlZmluZSBT U0hfRElTQ09OTkVDVF9QUk9UT0NPTF9FUlJPUiAgICAgICAgICAgICAgICAg ICAyDQogICAgICNkZWZpbmUgU1NIX0RJU0NPTk5FQ1RfS0VZX0VYQ0hBTkdF X0ZBSUxFRCAgICAgICAgICAgICAgMw0KICAgICAjZGVmaW5lIFNTSF9ESVND T05ORUNUX1JFU0VSVkVEICAgICAgICAgICAgICAgICAgICAgICAgIDQNCiAg ICAgI2RlZmluZSBTU0hfRElTQ09OTkVDVF9NQUNfRVJST1IgICAgICAgICAg ICAgICAgICAgICAgICA1DQogICAgICNkZWZpbmUgU1NIX0RJU0NPTk5FQ1Rf Q09NUFJFU1NJT05fRVJST1IgICAgICAgICAgICAgICAgNg0KICAgICAjZGVm aW5lIFNTSF9ESVNDT05ORUNUX1NFUlZJQ0VfTk9UX0FWQUlMQUJMRSAgICAg ICAgICAgIDcNCiAgICAgI2RlZmluZSBTU0hfRElTQ09OTkVDVF9QUk9UT0NP TF9WRVJTSU9OX05PVF9TVVBQT1JURUQgICA4DQogICAgICNkZWZpbmUgU1NI X0RJU0NPTk5FQ1RfSE9TVF9LRVlfTk9UX1ZFUklGSUFCTEUgICAgICAgICAg OQ0KICAgICAjZGVmaW5lIFNTSF9ESVNDT05ORUNUX0NPTk5FQ1RJT05fTE9T VCAgICAgICAgICAgICAgICAgMTANCiAgICAgI2RlZmluZSBTU0hfRElTQ09O TkVDVF9CWV9BUFBMSUNBVElPTiAgICAgICAgICAgICAgICAgIDExDQogICAg ICNkZWZpbmUgU1NIX0RJU0NPTk5FQ1RfVE9PX01BTllfQ09OTkVDVElPTlMg ICAgICAgICAgICAxMg0KICAgICAjZGVmaW5lIFNTSF9ESVNDT05ORUNUX0FV VEhfQ0FOQ0VMTEVEX0JZX1VTRVIgICAgICAgICAgMTMNCiAgICAgI2RlZmlu ZSBTU0hfRElTQ09OTkVDVF9OT19NT1JFX0FVVEhfTUVUSE9EU19BVkFJTEFC TEUgIDE0DQogICAgICNkZWZpbmUgU1NIX0RJU0NPTk5FQ1RfSUxMRUdBTF9V U0VSX05BTUUgICAgICAgICAgICAgICAxNQ0KDQogICAgICBJZiB0aGUgZGVz Y3JpcHRpb24gc3RyaW5nIGlzIGRpc3BsYXllZCwgY29udHJvbCBjaGFyYWN0 ZXINCiAgICAgIGZpbHRlcmluZyBkaXNjdXNzZWQgaW4gW1NTSC1BUkNIXSBz aG91bGQgYmUgdXNlZCB0byBhdm9pZCBhdHRhY2tzDQogICAgICBieSBzZW5k aW5nIHRlcm1pbmFsIGNvbnRyb2wgY2hhcmFjdGVycy4NCg0KICAgOS4yIEln bm9yZWQgRGF0YSBNZXNzYWdlDQoNCiAgICAgYnl0ZSAgICAgIFNTSF9NU0df SUdOT1JFDQogICAgIHN0cmluZyAgICBkYXRhDQoNCiAgICAgIEFsbCBpbXBs ZW1lbnRhdGlvbnMgTVVTVCB1bmRlcnN0YW5kIChhbmQgaWdub3JlKSB0aGlz IG1lc3NhZ2UgYXQNCiAgICAgIGFueSB0aW1lIChhZnRlciByZWNlaXZpbmcg dGhlIHByb3RvY29sIHZlcnNpb24pLiAgTm8NCiAgICAgIGltcGxlbWVudGF0 aW9uIGlzIHJlcXVpcmVkIHRvIHNlbmQgdGhlbS4gIFRoaXMgbWVzc2FnZSBj YW4gYmUgdXNlZA0KICAgICAgYXMgYW4gYWRkaXRpb25hbCBwcm90ZWN0aW9u IG1lYXN1cmUgYWdhaW5zdCBhZHZhbmNlZCB0cmFmZmljDQogICAgICBhbmFs eXNpcyB0ZWNobmlxdWVzLg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgW1Bh Z2UgMjNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5zcG9y dCBMYXllciBQcm90b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQog ICA5LjMgRGVidWcgTWVzc2FnZQ0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNH X0RFQlVHDQogICAgIGJvb2xlYW4gICBhbHdheXNfZGlzcGxheQ0KICAgICBz dHJpbmcgICAgbWVzc2FnZSBbUkZDMjI3OV0NCiAgICAgc3RyaW5nICAgIGxh bmd1YWdlIHRhZyBbUkZDMTc2Nl0NCg0KICAgICAgQWxsIGltcGxlbWVudGF0 aW9ucyBNVVNUIHVuZGVyc3RhbmQgdGhpcyBtZXNzYWdlLCBidXQgdGhleSBh cmUNCiAgICAgIGFsbG93ZWQgdG8gaWdub3JlIGl0LiAgVGhpcyBtZXNzYWdl IGlzIHVzZWQgdG8gcGFzcyB0aGUgb3RoZXIgc2lkZQ0KICAgICAgaW5mb3Jt YXRpb24gdGhhdCBtYXkgaGVscCBkZWJ1Z2dpbmcuICBJZiBhbHdheXNfZGlz cGxheSBpcyBUUlVFLA0KICAgICAgdGhlIG1lc3NhZ2UgU0hPVUxEIGJlIGRp c3BsYXllZC4gIE90aGVyd2lzZSwgaXQgU0hPVUxEIE5PVCBiZQ0KICAgICAg ZGlzcGxheWVkIHVubGVzcyBkZWJ1Z2dpbmcgaW5mb3JtYXRpb24gaGFzIGJl ZW4gZXhwbGljaXRseQ0KICAgICAgcmVxdWVzdGVkIGJ5IHRoZSB1c2VyLg0K DQoNCiAgICAgIFRoZSBtZXNzYWdlIGRvZXNuJ3QgbmVlZCB0byBjb250YWlu IGEgbmV3bGluZS4gIEl0IGlzLCBob3dldmVyLA0KICAgICAgYWxsb3dlZCB0 byBjb25zaXN0IG9mIG11bHRpcGxlIGxpbmVzIHNlcGFyYXRlZCBieSBDUkxG IChDYXJyaWFnZQ0KICAgICAgUmV0dXJuIC0gTGluZSBGZWVkKSBwYWlycy4N Cg0KDQogICAgICBJZiB0aGUgbWVzc2FnZSBzdHJpbmcgaXMgZGlzcGxheWVk LCB0ZXJtaW5hbCBjb250cm9sIGNoYXJhY3Rlcg0KICAgICAgZmlsdGVyaW5n IGRpc2N1c3NlZCBpbiBbU1NILUFSQ0hdIHNob3VsZCBiZSB1c2VkIHRvIGF2 b2lkIGF0dGFja3MNCiAgICAgIGJ5IHNlbmRpbmcgdGVybWluYWwgY29udHJv bCBjaGFyYWN0ZXJzLg0KDQogICA5LjQgUmVzZXJ2ZWQgTWVzc2FnZXMNCg0K ICAgICAgQW4gaW1wbGVtZW50YXRpb24gTVVTVCByZXNwb25kIHRvIGFsbCB1 bnJlY29nbml6ZWQgbWVzc2FnZXMgd2l0aA0KICAgICAgYW4gU1NIX01TR19V TklNUExFTUVOVEVEIG1lc3NhZ2UgaW4gdGhlIG9yZGVyIGluIHdoaWNoIHRo ZQ0KICAgICAgbWVzc2FnZXMgd2VyZSByZWNlaXZlZC4gIFN1Y2ggbWVzc2Fn ZXMgTVVTVCBiZSBvdGhlcndpc2UgaWdub3JlZC4NCiAgICAgIExhdGVyIHBy b3RvY29sIHZlcnNpb25zIG1heSBkZWZpbmUgb3RoZXIgbWVhbmluZ3MgZm9y IHRoZXNlDQogICAgICBtZXNzYWdlIHR5cGVzLg0KDQogICAgIGJ5dGUgICAg ICBTU0hfTVNHX1VOSU1QTEVNRU5URUQNCiAgICAgdWludDMyICAgIHBhY2tl dCBzZXF1ZW5jZSBudW1iZXIgb2YgcmVqZWN0ZWQgbWVzc2FnZQ0KDQoNCiAg IDEwLiBTdW1tYXJ5IG9mIE1lc3NhZ2UgTnVtYmVycw0KDQogICAgICBUaGUg Zm9sbG93aW5nIG1lc3NhZ2UgbnVtYmVycyBoYXZlIGJlZW4gZGVmaW5lZCBp biB0aGlzIHByb3RvY29sOg0KDQogICAgICNkZWZpbmUgU1NIX01TR19ESVND T05ORUNUICAgICAgICAgICAgIDENCiAgICAgI2RlZmluZSBTU0hfTVNHX0lH Tk9SRSAgICAgICAgICAgICAgICAgMg0KICAgICAjZGVmaW5lIFNTSF9NU0df VU5JTVBMRU1FTlRFRCAgICAgICAgICAzDQogICAgICNkZWZpbmUgU1NIX01T R19ERUJVRyAgICAgICAgICAgICAgICAgIDQNCiAgICAgI2RlZmluZSBTU0hf TVNHX1NFUlZJQ0VfUkVRVUVTVCAgICAgICAgNQ0KICAgICAjZGVmaW5lIFNT SF9NU0dfU0VSVklDRV9BQ0NFUFQgICAgICAgICA2DQoNCiAgICAgI2RlZmlu ZSBTU0hfTVNHX0tFWElOSVQgICAgICAgICAgICAgICAgMjANCg0KDQoNClls b25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGlyZXMgSmFudWFyeSAxMiwgMjAw NCAgICAgICAgICAgICAgIFtQYWdlIDI0XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgIFNTSCBUcmFuc3BvcnQgTGF5ZXIgUHJvdG9jb2wgICAgICAgICAg ICAgSnVseSAyMDAzDQoNCg0KICAgICAjZGVmaW5lIFNTSF9NU0dfTkVXS0VZ UyAgICAgICAgICAgICAgICAyMQ0KDQogICAgIC8qIE51bWJlcnMgMzAtNDkg dXNlZCBmb3Iga2V4IHBhY2tldHMuDQogICAgICAgIERpZmZlcmVudCBrZXgg bWV0aG9kcyBtYXkgcmV1c2UgbWVzc2FnZSBudW1iZXJzIGluDQogICAgICAg IHRoaXMgcmFuZ2UuICovDQoNCiAgICAgI2RlZmluZSBTU0hfTVNHX0tFWERI X0lOSVQgICAgICAgICAgICAgMzANCiAgICAgI2RlZmluZSBTU0hfTVNHX0tF WERIX1JFUExZICAgICAgICAgICAgMzENCg0KDQogICAxMS4gU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMNCg0KICAgICAgVGhpcyBwcm90b2NvbCBwcm92aWRl cyBhIHNlY3VyZSBlbmNyeXB0ZWQgY2hhbm5lbCBvdmVyIGFuIGluc2VjdXJl DQogICAgICBuZXR3b3JrLiAgSXQgcGVyZm9ybXMgc2VydmVyIGhvc3QgYXV0 aGVudGljYXRpb24sIGtleSBleGNoYW5nZSwNCiAgICAgIGVuY3J5cHRpb24s IGFuZCBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4gIEl0IGFsc28gZGVyaXZlcyBh IHVuaXF1ZQ0KICAgICAgc2Vzc2lvbiBpZCB0aGF0IG1heSBiZSB1c2VkIGJ5 IGhpZ2hlci1sZXZlbCBwcm90b2NvbHMuDQoNCiAgICAgIEZ1bGwgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgZm9yIHRoaXMgcHJvdG9jb2wgYXJlIHByb3Zp ZGVkIGluDQogICAgICBTZWN0aW9uIDggb2YgW1NTSC1BUkNIXQ0KDQogICAx Mi4gSW50ZWxsZWN0dWFsIFByb3BlcnR5DQoNCiAgICAgIFRoZSBJRVRGIHRh a2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2Nv cGUgb2YgYW55DQogICAgICBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3Ro ZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgICAgcGVy dGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNo bm9sb2d5IGRlc2NyaWJlZA0KICAgICAgaW4gdGhpcyBkb2N1bWVudCBvciB0 aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2gNCiAg ICAgIHJpZ2h0cyBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBu ZWl0aGVyIGRvZXMgaXQgcmVwcmVzZW50DQogICAgICB0aGF0IGl0IGhhcyBt YWRlIGFueSBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLg0K ICAgICAgSW5mb3JtYXRpb24gb24gdGhlIElFVEYncyBwcm9jZWR1cmVzIHdp dGggcmVzcGVjdCB0byByaWdodHMgaW4NCiAgICAgIHN0YW5kYXJkcy10cmFj ayBhbmQgc3RhbmRhcmRzLXJlbGF0ZWQgZG9jdW1lbnRhdGlvbiBjYW4gYmUg Zm91bmQNCiAgICAgIGluIEJDUC0xMS4gIENvcGllcyBvZiBjbGFpbXMgb2Yg cmlnaHRzIG1hZGUgYXZhaWxhYmxlIGZvcg0KICAgICAgcHVibGljYXRpb24g YW5kIGFueSBhc3N1cmFuY2VzIG9mIGxpY2Vuc2VzIHRvIGJlIG1hZGUgYXZh aWxhYmxlLA0KICAgICAgb3IgdGhlIHJlc3VsdCBvZiBhbiBhdHRlbXB0IG1h ZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yDQogICAgICBwZXJt aXNzaW9uIGZvciB0aGUgdXNlIG9mIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRz IGJ5IGltcGxlbWVudGVycw0KICAgICAgb3IgdXNlcnMgb2YgdGhpcyBzcGVj aWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGDQogICAg ICBTZWNyZXRhcmlhdC4NCg0KICAgICAgVGhlIElFVEYgaGFzIGJlZW4gbm90 aWZpZWQgb2YgaW50ZWxsZWN0dWFsIHByb3BlcnR5IHJpZ2h0cyBjbGFpbWVk DQogICAgICBpbiByZWdhcmQgdG8gc29tZSBvciBhbGwgb2YgdGhlIHNwZWNp ZmljYXRpb24gY29udGFpbmVkIGluIHRoaXMNCiAgICAgIGRvY3VtZW50LiAg Rm9yIG1vcmUgaW5mb3JtYXRpb24gY29uc3VsdCB0aGUgb25saW5lIGxpc3Qg b2YgY2xhaW1lZA0KICAgICAgcmlnaHRzLg0KDQogICAxMy4gQWRkaXRpb25h bCBJbmZvcm1hdGlvbg0KDQogICAgICBUaGUgY3VycmVudCBkb2N1bWVudCBl ZGl0b3IgaXM6IERhcnJlbi5Nb2ZmYXRAU3VuLkNPTS4gIENvbW1lbnRzDQog ICAgICBvbiB0aGlzIGludGVybmV0IGRyYWZ0IHNob3VsZCBiZSBzZW50IHRv IHRoZSBJRVRGIFNFQ1NIIHdvcmtpbmcNCiAgICAgIGdyb3VwLCBkZXRhaWxz IGF0OiBodHRwOi8vaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9zZWNzaC0NCiAg ICAgIGNoYXJ0ZXIuaHRtbA0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgW1Bh Z2UgMjVdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5zcG9y dCBMYXllciBQcm90b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQpS ZWZlcmVuY2VzDQoNCiAgICAgIFtGSVBTLTE4Nl0gICAgICBGZWRlcmFsIElu Zm9ybWF0aW9uIFByb2Nlc3NpbmcgU3RhbmRhcmRzDQogICAgICAgICAgICAg ICAgICAgICAgUHVibGljYXRpb24sIC4sICJGSVBTIFBVQiAxODYsIERpZ2l0 YWwgU2lnbmF0dXJlDQogICAgICAgICAgICAgICAgICAgICAgU3RhbmRhcmQi LCBNYXkgMTk5NC4NCg0KICAgICAgW09ybTk2XSAgICAgICAgIE9ybWFuLCBI LiwgIlRoZSBPa2FsZXkgS2V5IERldGVybWluYXRpb24gUHJvdGNvbA0KICAg ICAgICAgICAgICAgICAgICAgIHZlcnNpb24xLCBUUjk3LTkyIiwgMTk5Ni4N Cg0KICAgICAgW1JGQzI0NTldICAgICAgIEhvdXNsZXksIFIuLCBGb3JkLCBX LiwgUG9saywgVy4gYW5kIEQuIFNvbG8sDQogICAgICAgICAgICAgICAgICAg ICAgIkludGVybmV0IFguNTA5IFB1YmxpYyBLZXkgSW5mcmFzdHJ1Y3R1cmUN CiAgICAgICAgICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZSBhbmQgQ1JMIFBy b2ZpbGUiLCBSRkMgMjQ1OSwgSmFudWFyeQ0KICAgICAgICAgICAgICAgICAg ICAgIDE5OTkuDQoNCiAgICAgIFtSRkMxMDM0XSAgICAgICBNb2NrYXBldHJp cywgUC4sICJEb21haW4gbmFtZXMgLSBjb25jZXB0cyBhbmQNCiAgICAgICAg ICAgICAgICAgICAgICBmYWNpbGl0aWVzIiwgU1REIDEzLCBSRkMgMTAzNCwg Tm92IDE5ODcuDQoNCiAgICAgIFtSRkMxNzY2XSAgICAgICBBbHZlc3RyYW5k LCBILiwgIlRhZ3MgZm9yIHRoZSBJZGVudGlmaWNhdGlvbiBvZg0KICAgICAg ICAgICAgICAgICAgICAgIExhbmd1YWdlcyIsIFJGQyAxNzY2LCBNYXJjaCAx OTk1Lg0KDQogICAgICBbUkZDMTk1MF0gICAgICAgRGV1dHNjaCwgUC4gYW5k IEotTC4gR2FpbGx5LCAiWkxJQiBDb21wcmVzc2VkIERhdGENCiAgICAgICAg ICAgICAgICAgICAgICBGb3JtYXQgU3BlY2lmaWNhdGlvbiB2ZXJzaW9uIDMu MyIsIFJGQyAxOTUwLCBNYXkNCiAgICAgICAgICAgICAgICAgICAgICAxOTk2 Lg0KDQogICAgICBbUkZDMTk1MV0gICAgICAgRGV1dHNjaCwgUC4sICJERUZM QVRFIENvbXByZXNzZWQgRGF0YSBGb3JtYXQNCiAgICAgICAgICAgICAgICAg ICAgICBTcGVjaWZpY2F0aW9uIHZlcnNpb24gMS4zIiwgUkZDIDE5NTEsIE1h eSAxOTk2Lg0KDQogICAgICBbUkZDMjI3OV0gICAgICAgWWVyZ2VhdSwgRi4s ICJVVEYtOCwgYSB0cmFuc2Zvcm1hdGlvbiBmb3JtYXQgb2YNCiAgICAgICAg ICAgICAgICAgICAgICBJU08gMTA2NDYiLCBSRkMgMjI3OSwgSmFudWFyeSAx OTk4Lg0KDQogICAgICBbUkZDMjEwNF0gICAgICAgS3Jhd2N6eWssIEguLCBC ZWxsYXJlLCBNLiBhbmQgUi4gQ2FuZXR0aSwgIkhNQUM6DQogICAgICAgICAg ICAgICAgICAgICAgS2V5ZWQtSGFzaGluZyBmb3IgTWVzc2FnZSBBdXRoZW50 aWNhdGlvbiIsIFJGQw0KICAgICAgICAgICAgICAgICAgICAgIDIxMDQsIEZl YnJ1YXJ5IDE5OTcuDQoNCiAgICAgIFtSRkMyMTE5XSAgICAgICBCcmFkbmVy LCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8NCiAgICAgICAg ICAgICAgICAgICAgICBJbmRpY2F0ZSBSZXF1aXJlbWVudCBMZXZlbHMiLCBC Q1AgMTQsIFJGQyAyMTE5LA0KICAgICAgICAgICAgICAgICAgICAgIE1hcmNo IDE5OTcuDQoNCiAgICAgIFtSRkMyMTQ0XSAgICAgICBBZGFtcywgQy4sICJU aGUgQ0FTVC0xMjggRW5jcnlwdGlvbiBBbGdvcml0aG0iLA0KICAgICAgICAg ICAgICAgICAgICAgIFJGQyAyMTQ0LCBNYXkgMTk5Ny4NCg0KICAgICAgW1JG QzI0NDBdICAgICAgIENhbGxhcywgSi4sIERvbm5lcmhhY2tlLCBMLiwgRmlu bmV5LCBILiBhbmQgUi4NCiAgICAgICAgICAgICAgICAgICAgICBUaGF5ZXIs ICJPcGVuUEdQIE1lc3NhZ2UgRm9ybWF0IiwgUkZDIDI0NDAsDQogICAgICAg ICAgICAgICAgICAgICAgTm92ZW1iZXIgMTk5OC4NCg0KICAgICAgW1JGQzI2 OTNdICAgICAgIEVsbGlzb24sIEMuLCBGcmFudHosIEIuLCBMYW1wc29uLCBC LiwgUml2ZXN0LCBSLiwNCiAgICAgICAgICAgICAgICAgICAgICBUaG9tYXMs IEIuIGFuZCBULiBZbG9uZW4sICJTUEtJIENlcnRpZmljYXRlDQogICAgICAg ICAgICAgICAgICAgICAgVGhlb3J5IiwgUkZDIDI2OTMsIFNlcHRlbWJlciAx OTk5Lg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgRXhwaXJlcyBK YW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgW1BhZ2UgMjZdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5zcG9ydCBMYXllciBQcm90 b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQogICAgICBbU0NITkVJ RVJdICAgICAgU2NobmVpZXIsIEIuLCAiQXBwbGllZCBDcnlwdG9ncmFwaHkg U2Vjb25kDQogICAgICAgICAgICAgICAgICAgICAgRWRpdGlvbjogcHJvdG9j b2xzIGFsZ29yaXRobXMgYW5kIHNvdXJjZSBpbiBjb2RlDQogICAgICAgICAg ICAgICAgICAgICAgaW4gQyIsIDE5OTYuDQoNCiAgICAgIFtUV09GSVNIXSAg ICAgICBTY2huZWllciwgQi4sICJUaGUgVHdvZmlzaCBFbmNyeXB0aW9ucyBB bGdvcml0aG06DQogICAgICAgICAgICAgICAgICAgICAgQSAxMjgtQml0IEJs b2NrIENpcGhlciwgMXN0IEVkaXRpb24iLCBNYXJjaCAxOTk5Lg0KDQogICAg ICBbU1NILUFSQ0hdICAgICAgWWxvbmVuLCBULiwgIlNTSCBQcm90b2NvbCBB cmNoaXRlY3R1cmUiLCBJLUQNCiAgICAgICAgICAgICAgICAgICAgICBkcmFm dC1pZXRmLWFyY2hpdGVjdHVyZS0xNC50eHQsIEp1bHkgMjAwMy4NCg0KICAg ICAgW1NTSC1UUkFOU10gICAgIFlsb25lbiwgVC4sICJTU0ggVHJhbnNwb3J0 IExheWVyIFByb3RvY29sIiwgSS1EDQogICAgICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi10cmFuc3BvcnQtMTYudHh0LCBKdWx5IDIwMDMuDQoNCiAg ICAgIFtTU0gtVVNFUkFVVEhdICBZbG9uZW4sIFQuLCAiU1NIIEF1dGhlbnRp Y2F0aW9uIFByb3RvY29sIiwgSS1EDQogICAgICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi11c2VyYXV0aC0xNy50eHQsIEp1bHkgMjAwMy4NCg0KICAg ICAgW1NTSC1DT05ORUNUXSAgIFlsb25lbiwgVC4sICJTU0ggQ29ubmVjdGlv biBQcm90b2NvbCIsIEktRCBkcmFmdC0NCiAgICAgICAgICAgICAgICAgICAg ICBpZXRmLWNvbm5lY3QtMTcudHh0LCBKdWx5IDIwMDMuDQoNCiAgICAgIFtT U0gtTlVNQkVSU10gICBMZWh0aW5lbiwgUy4gYW5kIEQuIE1vZmZhdCwgIlNT SCBQcm90b2NvbCBBc3NpZ25lZA0KICAgICAgICAgICAgICAgICAgICAgIE51 bWJlcnMiLCBJLUQgZHJhZnQtaWV0Zi1zZWNzaC1hc3NpZ25lZG51bWJlcnMt DQogICAgICAgICAgICAgICAgICAgICAgMDMudHh0LCBKdWx5IDIwMDMuDQoN Cg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIFRhdHUgWWxvbmVuDQogICBT U0ggQ29tbXVuaWNhdGlvbnMgU2VjdXJpdHkgQ29ycA0KICAgRnJlZHJpa2lu a2F0dSA0Mg0KICAgSEVMU0lOS0kgIEZJTi0wMDEwMA0KICAgRmlubGFuZA0K DQogICBFTWFpbDogeWxvQHNzaC5jb20NCg0KDQogICBUZXJvIEtpdmluZW4N CiAgIFNTSCBDb21tdW5pY2F0aW9ucyBTZWN1cml0eSBDb3JwDQogICBGcmVk cmlraW5rYXR1IDQyDQogICBIRUxTSU5LSSAgRklOLTAwMTAwDQogICBGaW5s YW5kDQoNCiAgIEVNYWlsOiBraXZpbmVuQHNzaC5jb20NCg0KDQogICBNYXJr a3UtSnVoYW5pIE8uIFNhYXJpbmVuDQogICBVbml2ZXJzaXR5IG9mIEp5dmFz a3lsYQ0KDQoNCg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgIEV4cGly ZXMgSmFudWFyeSAxMiwgMjAwNCAgICAgICAgICAgICAgIFtQYWdlIDI3XQ0K DA0KSW50ZXJuZXQtRHJhZnQgICAgICAgIFNTSCBUcmFuc3BvcnQgTGF5ZXIg UHJvdG9jb2wgICAgICAgICAgICAgSnVseSAyMDAzDQoNCg0KICAgVGltbyBK LiBSaW5uZQ0KICAgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5IENvcnAN CiAgIEZyZWRyaWtpbmthdHUgNDINCiAgIEhFTFNJTktJICBGSU4tMDAxMDAN CiAgIEZpbmxhbmQNCg0KICAgRU1haWw6IHRyaUBzc2guY29tDQoNCg0KICAg U2FtaSBMZWh0aW5lbg0KICAgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5 IENvcnANCiAgIEZyZWRyaWtpbmthdHUgNDINCiAgIEhFTFNJTktJICBGSU4t MDAxMDANCiAgIEZpbmxhbmQNCg0KICAgRU1haWw6IHNqbEBzc2guY29tDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAg ICAgRXhwaXJlcyBKYW51YXJ5IDEyLCAyMDA0ICAgICAgICAgICAgICAgW1Bh Z2UgMjhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgU1NIIFRyYW5zcG9y dCBMYXllciBQcm90b2NvbCAgICAgICAgICAgICBKdWx5IDIwMDMNCg0KDQpG dWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgICAgQ29weXJpZ2h0IChD KSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMykuICBBbGwgUmlnaHRzIFJl c2VydmVkLg0KDQogICAgICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlv bnMgb2YgaXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkDQogICAgICB0 byBvdGhlcnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBv biBvciBvdGhlcndpc2UNCiAgICAgIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGlu IGl0cyBpbXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsDQogICAgICBj b3BpZWQsIHB1Ymxpc2hlZCBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9y IGluIHBhcnQsIHdpdGhvdXQNCiAgICAgIHJlc3RyaWN0aW9uIG9mIGFueSBr aW5kLCBwcm92aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNl DQogICAgICBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIGFs bCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZQ0KICAgICAgd29ya3MuICBI b3dldmVyLCB0aGlzIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlm aWVkIGluIGFueQ0KICAgICAgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nIHRo ZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlDQogICAg ICBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXph dGlvbnMsIGV4Y2VwdCBhcyBuZWVkZWQNCiAgICAgIGZvciB0aGUgcHVycG9z ZSBvZiBkZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBj YXNlIHRoZQ0KICAgICAgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBkZWZp bmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMNCiAgICAgIHByb2Nlc3Mg bXVzdCBiZSBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRl IGl0IGludG8NCiAgICAgIGxhbmd1YWdlcyBvdGhlciB0aGFuIEVuZ2xpc2gu DQoNCiAgICAgIFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJv dmUgYXJlIHBlcnBldHVhbCBhbmQgd2lsbCBub3QNCiAgICAgIGJlIHJldm9r ZWQgYnkgdGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3NvcnMg b3IgYXNzaWducy4NCg0KICAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24NCiAg ICAgIGFuICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZ IEFORCBUSEUgSU5URVJORVQNCiAgICAgIEVOR0lORUVSSU5HIFRBU0sgRk9S Q0UgRElTQ0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SDQogICAg ICBJTVBMSUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBX QVJSQU5UWSBUSEFUIFRIRSBVU0UgT0YNCiAgICAgIFRIRSBJTkZPUk1BVElP TiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkg SU1QTElFRA0KICAgICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkg T1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCkFja25v d2xlZGdlbWVudA0KDQogICAgICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRv ciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICAg ICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICBFeHBpcmVz IEphbnVhcnkgMTIsIDIwMDQgICAgICAgICAgICAgICBbUGFnZSAyOV0NCgwN Cg== ---559023410-342241519-1058246266=:895-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 01:18:40 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05069 for ; Tue, 15 Jul 2003 01:18:39 -0400 (EDT) Received: (qmail 1190 invoked by uid 605); 15 Jul 2003 05:18:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1183 invoked from network); 15 Jul 2003 05:18:35 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 Jul 2003 05:18:35 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6F5I42a001226; Mon, 14 Jul 2003 22:18:04 -0700 (PDT) Received: from islay (vpn-129-150-17-202.SFBay.Sun.COM [129.150.17.202]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6F5I0tf189346; Mon, 14 Jul 2003 22:18:00 -0700 (PDT) Date: Mon, 14 Jul 2003 22:18:23 -0700 (PDT) From: Darren J Moffat To: internet-drafts@ietf.org cc: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-userauth-17.txt Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1483920592-1058246303=:895" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. ---559023410-1483920592-1058246303=:895 Content-Type: TEXT/PLAIN; charset=US-ASCII -- Darren J Moffat ---559023410-1483920592-1058246303=:895 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="draft-ietf-secsh-userauth-17.txt" Content-ID: Content-Description: Content-Disposition: attachment; filename="draft-ietf-secsh-userauth-17.txt" Content-Transfer-Encoding: BASE64 DQoNCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFQuIFlsb25lbg0KSW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBULiBLaXZpbmVuDQpFeHBpcmVzOiBNYXJjaCAyLCAyMDAzICAgICAg ICAgICAgICAgICAgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5IENvcnAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNLiBTYWFyaW5lbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFVuaXZlcnNpdHkg b2YgSnl2YXNreWxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVC4gUmlubmUNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBTLiBMZWh0aW5lbg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFNTSCBDb21tdW5pY2F0aW9ucyBTZWN1 cml0eSBDb3JwDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU2VwdGVtYmVyIDIwMDINCg0KDQog ICAgICAgICAgICAgICAgICAgICAgU1NIIEF1dGhlbnRpY2F0aW9uIFByb3Rv Y29sDQogICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtc2Vjc2gtdXNl cmF1dGgtMTcudHh0DQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgICAg VGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4g ZnVsbCBjb25mb3JtYW5jZSB3aXRoDQogICAgICBhbGwgcHJvdmlzaW9ucyBv ZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgICAgIEludGVybmV0LURy YWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu Z2luZWVyaW5nDQogICAgICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFz LCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICAgICBv dGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3Vt ZW50cyBhcyBJbnRlcm5ldC0NCiAgICAgIERyYWZ0cy4NCg0KICAgICAgSW50 ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEg bWF4aW11bSBvZiBzaXgNCiAgICAgIG1vbnRocyBhbmQgbWF5IGJlIHVwZGF0 ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXINCiAgICAgIGRv Y3VtZW50cyBhdCBhbnkgdGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8g dXNlIEludGVybmV0LURyYWZ0cw0KICAgICAgYXMgcmVmZXJlbmNlIG1hdGVy aWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluDQog ICAgICBwcm9ncmVzcy4iDQoNCiAgICAgIFRoZSBsaXN0IG9mIGN1cnJlbnQg SW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQog ICAgICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0 b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICAgICBodHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sLg0KDQogICAgICBUaGlzIEludGVybmV0LURy YWZ0IHdpbGwgZXhwaXJlIG9uIE1hcmNoIDIsIDIwMDMuDQoNCkNvcHlyaWdo dCBOb3RpY2UNCg0KICAgICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQg U29jaWV0eSAoMjAwMikuICBBbGwgUmlnaHRzIFJlc2VydmVkLg0KDQpBYnN0 cmFjdA0KDQogICAgICBTU0ggaXMgYSBwcm90b2NvbCBmb3Igc2VjdXJlIHJl bW90ZSBsb2dpbiBhbmQgb3RoZXIgc2VjdXJlIG5ldHdvcmsNCiAgICAgIHNl cnZpY2VzIG92ZXIgYW4gaW5zZWN1cmUgbmV0d29yay4gIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIHRoZQ0KICAgICAgU1NIIGF1dGhlbnRpY2F0aW9uIHBy b3RvY29sIGZyYW1ld29yayBhbmQgcHVibGljIGtleSwgcGFzc3dvcmQsDQog ICAgICBhbmQgaG9zdC1iYXNlZCBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0 aG9kcy4gIEFkZGl0aW9uYWwNCiAgICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhv ZHMgYXJlIGRlc2NyaWJlZCBpbiBzZXBhcmF0ZSBkb2N1bWVudHMuICBUaGUN Cg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgICAgRXhwaXJlcyBNYXJj aCAyLCAyMDAzICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICBTU0ggQXV0aGVudGljYXRpb24gUHJvdG9jb2wg ICAgICAgIFNlcHRlbWJlciAyMDAyDQoNCg0KICAgICAgU1NIIGF1dGhlbnRp Y2F0aW9uIHByb3RvY29sIHJ1bnMgb24gdG9wIG9mIHRoZSBTU0ggdHJhbnNw b3J0IGxheWVyDQogICAgICBwcm90b2NvbCBhbmQgcHJvdmlkZXMgYSBzaW5n bGUgYXV0aGVudGljYXRlZCB0dW5uZWwgZm9yIHRoZSBTU0gNCiAgICAgIGNv bm5lY3Rpb24gcHJvdG9jb2wuDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAg IDEuICBJbnRyb2R1Y3Rpb24gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAgMi4gIFRoZSBBdXRoZW50 aWNhdGlvbiBQcm90b2NvbCBGcmFtZXdvcmsgIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAzDQogICAyLjEgQXV0aGVudGljYXRpb24gUmVxdWVzdHMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDIu MiBSZXNwb25zZXMgdG8gQXV0aGVudGljYXRpb24gUmVxdWVzdHMgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgNQ0KICAgMi4zIFRoZSAibm9uZSIgQXV0 aGVudGljYXRpb24gUmVxdWVzdCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA2DQogICAyLjQgQ29tcGxldGlvbiBvZiBVc2VyIEF1dGhlbnRpY2F0 aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgIDIuNSBC YW5uZXIgTWVzc2FnZSAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgMy4gIEF1dGhlbnRpY2F0aW9uIFBy b3RvY29sIE1lc3NhZ2UgTnVtYmVycyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICA3DQogICA0LiAgUHVibGljIEtleSBBdXRoZW50aWNhdGlvbiBNZXRob2Q6 IHB1YmxpY2tleSAgLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgIDUuICBQYXNz d29yZCBBdXRoZW50aWNhdGlvbiBNZXRob2Q6IHBhc3N3b3JkIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAgOQ0KICAgNi4gIEhvc3QtQmFzZWQgQXV0aGVudGlj YXRpb246IGhvc3RiYXNlZCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEx DQogICA3LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgIDguICBJbnRlbGxl Y3R1YWwgUHJvcGVydHkgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAxMg0KICAgOS4gIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQog ICAgICAgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTMNCiAgICAgICBBdXRob3JzJyBB ZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAxNA0KICAgICAgIEZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudCAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDE1DQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgICAgRXhwaXJlcyBNYXJj aCAyLCAyMDAzICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgICAgICBTU0ggQXV0aGVudGljYXRpb24gUHJvdG9jb2wg ICAgICAgIFNlcHRlbWJlciAyMDAyDQoNCg0KICAgMS4gSW50cm9kdWN0aW9u DQoNCiAgICAgIFRoZSBTU0ggYXV0aGVudGljYXRpb24gcHJvdG9jb2wgaXMg YSBnZW5lcmFsLXB1cnBvc2UgdXNlcg0KICAgICAgYXV0aGVudGljYXRpb24g cHJvdG9jb2wuICBJdCBpcyBpbnRlbmRlZCB0byBiZSBydW4gb3ZlciB0aGUg U1NIDQogICAgICB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2wgW1NTSC1UUkFO U10uICBUaGlzIHByb3RvY29sIGFzc3VtZXMgdGhhdA0KICAgICAgdGhlIHVu ZGVybHlpbmcgcHJvdG9jb2xzIHByb3ZpZGUgaW50ZWdyaXR5IGFuZCBjb25m aWRlbnRpYWxpdHkNCiAgICAgIHByb3RlY3Rpb24uDQoNCiAgICAgIFRoaXMg ZG9jdW1lbnQgc2hvdWxkIGJlIHJlYWQgb25seSBhZnRlciByZWFkaW5nIHRo ZSBTU0gNCiAgICAgIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBbU1NILUFSQ0hd LiAgVGhpcyBkb2N1bWVudCBmcmVlbHkgdXNlcw0KICAgICAgdGVybWlub2xv Z3kgYW5kIG5vdGF0aW9uIGZyb20gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVu dCB3aXRob3V0DQogICAgICByZWZlcmVuY2Ugb3IgZnVydGhlciBleHBsYW5h dGlvbi4NCg0KICAgICAgVGhlIHNlcnZpY2UgbmFtZSBmb3IgdGhpcyBwcm90 b2NvbCBpcyAic3NoLXVzZXJhdXRoIi4NCg0KICAgICAgV2hlbiB0aGlzIHBy b3RvY29sIHN0YXJ0cywgaXQgcmVjZWl2ZXMgdGhlIHNlc3Npb24gaWRlbnRp ZmllciBmcm9tDQogICAgICB0aGUgbG93ZXItbGV2ZWwgcHJvdG9jb2wgKHRo aXMgaXMgdGhlIGV4Y2hhbmdlIGhhc2ggSCBmcm9tIHRoZQ0KICAgICAgZmly c3Qga2V5IGV4Y2hhbmdlKS4gIFRoZSBzZXNzaW9uIGlkZW50aWZpZXIgdW5p cXVlbHkgaWRlbnRpZmllcw0KICAgICAgdGhpcyBzZXNzaW9uIGFuZCBpcyBz dWl0YWJsZSBmb3Igc2lnbmluZyBpbiBvcmRlciB0byBwcm92ZQ0KICAgICAg b3duZXJzaGlwIG9mIGEgcHJpdmF0ZSBrZXkuICBUaGlzIHByb3RvY29sIGFs c28gbmVlZHMgdG8ga25vdw0KICAgICAgd2hldGhlciB0aGUgbG93ZXItbGV2 ZWwgcHJvdG9jb2wgcHJvdmlkZXMgY29uZmlkZW50aWFsaXR5DQogICAgICBw cm90ZWN0aW9uLg0KDQogICAyLiBUaGUgQXV0aGVudGljYXRpb24gUHJvdG9j b2wgRnJhbWV3b3JrDQoNCiAgICAgIFRoZSBzZXJ2ZXIgZHJpdmVzIHRoZSBh dXRoZW50aWNhdGlvbiBieSB0ZWxsaW5nIHRoZSBjbGllbnQgd2hpY2gNCiAg ICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgY2FuIGJlIHVzZWQgdG8gY29u dGludWUgdGhlIGV4Y2hhbmdlIGF0IGFueQ0KICAgICAgZ2l2ZW4gdGltZS4g IFRoZSBjbGllbnQgaGFzIHRoZSBmcmVlZG9tIHRvIHRyeSB0aGUgbWV0aG9k cyBsaXN0ZWQNCiAgICAgIGJ5IHRoZSBzZXJ2ZXIgaW4gYW55IG9yZGVyLiAg VGhpcyBnaXZlcyB0aGUgc2VydmVyIGNvbXBsZXRlDQogICAgICBjb250cm9s IG92ZXIgdGhlIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3MgaWYgZGVzaXJlZCwg YnV0IGFsc28gZ2l2ZXMNCiAgICAgIGVub3VnaCBmbGV4aWJpbGl0eSBmb3Ig dGhlIGNsaWVudCB0byB1c2UgdGhlIG1ldGhvZHMgaXQgc3VwcG9ydHMNCiAg ICAgIG9yIHRoYXQgYXJlIG1vc3QgY29udmVuaWVudCBmb3IgdGhlIHVzZXIs IHdoZW4gbXVsdGlwbGUgbWV0aG9kcw0KICAgICAgYXJlIG9mZmVyZWQgYnkg dGhlIHNlcnZlci4NCg0KICAgICAgQXV0aGVudGljYXRpb24gbWV0aG9kcyBh cmUgaWRlbnRpZmllZCBieSB0aGVpciBuYW1lLCBhcyBkZWZpbmVkIGluDQog ICAgICBbU1NILUFSQ0hdLiAgVGhlICJub25lIiBtZXRob2QgaXMgcmVzZXJ2 ZWQsIGFuZCBNVVNUIE5PVCBiZSBsaXN0ZWQNCiAgICAgIGFzIHN1cHBvcnRl ZC4gIEhvd2V2ZXIsIGl0IE1BWSBiZSBzZW50IGJ5IHRoZSBjbGllbnQuICBU aGUgc2VydmVyDQogICAgICBNVVNUIGFsd2F5cyByZWplY3QgdGhpcyByZXF1 ZXN0LCB1bmxlc3MgdGhlIGNsaWVudCBpcyB0byBiZQ0KICAgICAgYWxsb3dl ZCBpbiB3aXRob3V0IGFueSBhdXRoZW50aWNhdGlvbiwgaW4gd2hpY2ggY2Fz ZSB0aGUgc2VydmVyDQogICAgICBNVVNUIGFjY2VwdCB0aGlzIHJlcXVlc3Qu ICBUaGUgbWFpbiBwdXJwb3NlIG9mIHNlbmRpbmcgdGhpcw0KICAgICAgcmVx dWVzdCBpcyB0byBnZXQgdGhlIGxpc3Qgb2Ygc3VwcG9ydGVkIG1ldGhvZHMg ZnJvbSB0aGUgc2VydmVyLg0KDQogICAgICBUaGUgc2VydmVyIFNIT1VMRCBo YXZlIGEgdGltZW91dCBmb3IgYXV0aGVudGljYXRpb24sIGFuZA0KICAgICAg ZGlzY29ubmVjdCBpZiB0aGUgYXV0aGVudGljYXRpb24gaGFzIG5vdCBiZWVu IGFjY2VwdGVkIHdpdGhpbiB0aGUNCiAgICAgIHRpbWVvdXQgcGVyaW9kLiAg VGhlIFJFQ09NTUVOREVEIHRpbWVvdXQgcGVyaW9kIGlzIDEwIG1pbnV0ZXMu DQogICAgICBBZGRpdGlvbmFsbHksIHRoZSBpbXBsZW1lbnRhdGlvbiBTSE9V TEQgbGltaXQgdGhlIG51bWJlciBvZiBmYWlsZWQNCiAgICAgIGF1dGhlbnRp Y2F0aW9uIGF0dGVtcHRzIGEgY2xpZW50IG1heSBwZXJmb3JtIGluIGEgc2lu Z2xlIHNlc3Npb24NCiAgICAgICh0aGUgUkVDT01NRU5ERUQgbGltaXQgaXMg MjAgYXR0ZW1wdHMpLiAgSWYgdGhlIHRocmVzaG9sZCBpcw0KDQoNCg0KWWxv bmVuLCBldC4gYWwuICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIsIDIwMDMg ICAgICAgICAgICAgICAgIFtQYWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgICAgIFNTSCBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAgICAgICAgU2Vw dGVtYmVyIDIwMDINCg0KDQogICAgICBleGNlZWRlZCwgdGhlIHNlcnZlciBT SE9VTEQgZGlzY29ubmVjdC4NCg0KICAgMi4xIEF1dGhlbnRpY2F0aW9uIFJl cXVlc3RzDQoNCiAgICAgIEFsbCBhdXRoZW50aWNhdGlvbiByZXF1ZXN0cyBN VVNUIHVzZSB0aGUgZm9sbG93aW5nIG1lc3NhZ2UgZm9ybWF0Lg0KICAgICAg T25seSB0aGUgZmlyc3QgZmV3IGZpZWxkcyBhcmUgZGVmaW5lZDsgdGhlIHJl bWFpbmluZyBmaWVsZHMgZGVwZW5kDQogICAgICBvbiB0aGUgYXV0aGVudGlj YXRpb24gbWV0aG9kLg0KDQogICAgIGJ5dGUgICAgICBTU0hfTVNHX1VTRVJB VVRIX1JFUVVFU1QNCiAgICAgc3RyaW5nICAgIHVzZXIgbmFtZSAoaW4gSVNP LTEwNjQ2IFVURi04IGVuY29kaW5nIFtSRkMyMjc5XSkNCiAgICAgc3RyaW5n ICAgIHNlcnZpY2UgbmFtZSAoaW4gVVMtQVNDSUkpDQogICAgIHN0cmluZyAg ICBtZXRob2QgbmFtZSAoVVMtQVNDSUkpDQogICAgIFRoZSByZXN0IG9mIHRo ZSBwYWNrZXQgaXMgbWV0aG9kLXNwZWNpZmljLg0KDQogICAgICBUaGUgdXNl ciBuYW1lIGFuZCBzZXJ2aWNlIGFyZSByZXBlYXRlZCBpbiBldmVyeSBuZXcg YXV0aGVudGljYXRpb24NCiAgICAgIGF0dGVtcHQsIGFuZCBNQVkgY2hhbmdl LiAgVGhlIHNlcnZlciBpbXBsZW1lbnRhdGlvbiBNVVNUIGNhcmVmdWxseQ0K ICAgICAgY2hlY2sgdGhlbSBpbiBldmVyeSBtZXNzYWdlLCBhbmQgTVVTVCBm bHVzaCBhbnkgYWNjdW11bGF0ZWQNCiAgICAgIGF1dGhlbnRpY2F0aW9uIHN0 YXRlcyBpZiB0aGV5IGNoYW5nZS4gIElmIGl0IGlzIHVuYWJsZSB0byBmbHVz aA0KICAgICAgc29tZSBhdXRoZW50aWNhdGlvbiBzdGF0ZSwgaXQgTVVTVCBk aXNjb25uZWN0IGlmIHRoZSB1c2VyIG9yDQogICAgICBzZXJ2aWNlIG5hbWUg Y2hhbmdlcy4NCg0KICAgICAgVGhlIHNlcnZpY2UgbmFtZSBzcGVjaWZpZXMg dGhlIHNlcnZpY2UgdG8gc3RhcnQgYWZ0ZXINCiAgICAgIGF1dGhlbnRpY2F0 aW9uLiAgVGhlcmUgbWF5IGJlIHNldmVyYWwgZGlmZmVyZW50IGF1dGhlbnRp Y2F0ZWQNCiAgICAgIHNlcnZpY2VzIHByb3ZpZGVkLiAgSWYgdGhlIHJlcXVl c3RlZCBzZXJ2aWNlIGlzIG5vdCBhdmFpbGFibGUsIHRoZQ0KICAgICAgc2Vy dmVyIE1BWSBkaXNjb25uZWN0IGltbWVkaWF0ZWx5IG9yIGF0IGFueSBsYXRl ciB0aW1lLiAgU2VuZGluZyBhDQogICAgICBwcm9wZXIgZGlzY29ubmVjdCBt ZXNzYWdlIGlzIFJFQ09NTUVOREVELiAgSW4gYW55IGNhc2UsIGlmIHRoZQ0K ICAgICAgc2VydmljZSBkb2VzIG5vdCBleGlzdCwgYXV0aGVudGljYXRpb24g TVVTVCBOT1QgYmUgYWNjZXB0ZWQuDQoNCiAgICAgIElmIHRoZSByZXF1ZXN0 ZWQgdXNlciBkb2VzIG5vdCBleGlzdCwgdGhlIHNlcnZlciBNQVkgZGlzY29u bmVjdCwNCiAgICAgIG9yIE1BWSBzZW5kIGEgYm9ndXMgbGlzdCBvZiBhY2Nl cHRhYmxlIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMsIGJ1dA0KICAgICAgbmV2 ZXIgYWNjZXB0IGFueS4gIFRoaXMgbWFrZXMgaXQgcG9zc2libGUgZm9yIHRo ZSBzZXJ2ZXIgdG8gYXZvaWQNCiAgICAgIGRpc2Nsb3NpbmcgaW5mb3JtYXRp b24gb24gd2hpY2ggYWNjb3VudHMgZXhpc3QuICBJbiBhbnkgY2FzZSwgaWYN CiAgICAgIHRoZSB1c2VyIGRvZXMgbm90IGV4aXN0LCB0aGUgYXV0aGVudGlj YXRpb24gcmVxdWVzdCBNVVNUIE5PVCBiZQ0KICAgICAgYWNjZXB0ZWQuDQoN CiAgICAgIFdoaWxlIHRoZXJlIGlzIHVzdWFsbHkgbGl0dGxlIHBvaW50IGZv ciBjbGllbnRzIHRvIHNlbmQgcmVxdWVzdHMNCiAgICAgIHRoYXQgdGhlIHNl cnZlciBkb2VzIG5vdCBsaXN0IGFzIGFjY2VwdGFibGUsIHNlbmRpbmcgc3Vj aCByZXF1ZXN0cw0KICAgICAgaXMgbm90IGFuIGVycm9yLCBhbmQgdGhlIHNl cnZlciBTSE9VTEQgc2ltcGx5IHJlamVjdCByZXF1ZXN0cyB0aGF0DQogICAg ICBpdCBkb2VzIG5vdCByZWNvZ25pemUuDQoNCiAgICAgIEFuIGF1dGhlbnRp Y2F0aW9uIHJlcXVlc3QgTUFZIHJlc3VsdCBpbiBhIGZ1cnRoZXIgZXhjaGFu Z2Ugb2YNCiAgICAgIG1lc3NhZ2VzLiAgQWxsIHN1Y2ggbWVzc2FnZXMgZGVw ZW5kIG9uIHRoZSBhdXRoZW50aWNhdGlvbiBtZXRob2QNCiAgICAgIHVzZWQs IGFuZCB0aGUgY2xpZW50IE1BWSBhdCBhbnkgdGltZSBjb250aW51ZSB3aXRo IGEgbmV3DQogICAgICBTU0hfTVNHX1VTRVJBVVRIX1JFUVVFU1QgbWVzc2Fn ZSwgaW4gd2hpY2ggY2FzZSB0aGUgc2VydmVyIE1VU1QNCiAgICAgIGFiYW5k b24gdGhlIHByZXZpb3VzIGF1dGhlbnRpY2F0aW9uIGF0dGVtcHQgYW5kIGNv bnRpbnVlIHdpdGggdGhlDQogICAgICBuZXcgb25lLg0KDQoNCg0KDQoNClls b25lbiwgZXQuIGFsLiAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAyLCAyMDAz ICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQg ICAgICAgICBTU0ggQXV0aGVudGljYXRpb24gUHJvdG9jb2wgICAgICAgIFNl cHRlbWJlciAyMDAyDQoNCg0KICAgMi4yIFJlc3BvbnNlcyB0byBBdXRoZW50 aWNhdGlvbiBSZXF1ZXN0cw0KDQogICAgICBJZiB0aGUgc2VydmVyIHJlamVj dHMgdGhlIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QsIGl0IE1VU1QgcmVzcG9u ZA0KICAgICAgd2l0aCB0aGUgZm9sbG93aW5nOg0KDQogICAgIGJ5dGUgICAg ICBTU0hfTVNHX1VTRVJBVVRIX0ZBSUxVUkUNCiAgICAgc3RyaW5nICAgIGF1 dGhlbnRpY2F0aW9ucyB0aGF0IGNhbiBjb250aW51ZQ0KICAgICBib29sZWFu ICAgcGFydGlhbCBzdWNjZXNzDQoNCiAgICAgICJBdXRoZW50aWNhdGlvbnMg dGhhdCBjYW4gY29udGludWUiIGlzIGEgY29tbWEtc2VwYXJhdGVkIGxpc3Qg b2YNCiAgICAgIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBuYW1lcyB0aGF0IG1h eSBwcm9kdWN0aXZlbHkgY29udGludWUgdGhlDQogICAgICBhdXRoZW50aWNh dGlvbiBkaWFsb2cuDQoNCiAgICAgIEl0IGlzIFJFQ09NTUVOREVEIHRoYXQg c2VydmVycyBvbmx5IGluY2x1ZGUgdGhvc2UgbWV0aG9kcyBpbiB0aGUNCiAg ICAgIGxpc3QgdGhhdCBhcmUgYWN0dWFsbHkgdXNlZnVsLiAgSG93ZXZlciwg aXQgaXMgbm90IGlsbGVnYWwgdG8NCiAgICAgIGluY2x1ZGUgbWV0aG9kcyB0 aGF0IGNhbm5vdCBiZSB1c2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUgdXNlci4N Cg0KICAgICAgQWxyZWFkeSBzdWNjZXNzZnVsbHkgY29tcGxldGVkIGF1dGhl bnRpY2F0aW9ucyBTSE9VTEQgTk9UIGJlDQogICAgICBpbmNsdWRlZCBpbiB0 aGUgbGlzdCwgdW5sZXNzIHRoZXkgcmVhbGx5IHNob3VsZCBiZSBwZXJmb3Jt ZWQgYWdhaW4NCiAgICAgIGZvciBzb21lIHJlYXNvbi4NCg0KICAgICAgIlBh cnRpYWwgc3VjY2VzcyIgTVVTVCBiZSBUUlVFIGlmIHRoZSBhdXRoZW50aWNh dGlvbiByZXF1ZXN0IHRvDQogICAgICB3aGljaCB0aGlzIGlzIGEgcmVzcG9u c2Ugd2FzIHN1Y2Nlc3NmdWwuICBJdCBNVVNUIGJlIEZBTFNFIGlmIHRoZQ0K ICAgICAgcmVxdWVzdCB3YXMgbm90IHN1Y2Nlc3NmdWxseSBwcm9jZXNzZWQu DQoNCiAgICAgIFdoZW4gdGhlIHNlcnZlciBhY2NlcHRzIGF1dGhlbnRpY2F0 aW9uLCBpdCBNVVNUIHJlc3BvbmQgd2l0aCB0aGUNCiAgICAgIGZvbGxvd2lu ZzoNCg0KICAgICBieXRlICAgICAgU1NIX01TR19VU0VSQVVUSF9TVUNDRVNT DQoNCiAgICAgIE5vdGUgdGhhdCB0aGlzIGlzIG5vdCBzZW50IGFmdGVyIGVh Y2ggc3RlcCBpbiBhIG11bHRpLW1ldGhvZA0KICAgICAgYXV0aGVudGljYXRp b24gc2VxdWVuY2UsIGJ1dCBvbmx5IHdoZW4gdGhlIGF1dGhlbnRpY2F0aW9u IGlzDQogICAgICBjb21wbGV0ZS4NCg0KICAgICAgVGhlIGNsaWVudCBNQVkg c2VuZCBzZXZlcmFsIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3RzIHdpdGhvdXQN CiAgICAgIHdhaXRpbmcgZm9yIHJlc3BvbnNlcyBmcm9tIHByZXZpb3VzIHJl cXVlc3RzLiAgVGhlIHNlcnZlciBNVVNUDQogICAgICBwcm9jZXNzIGVhY2gg cmVxdWVzdCBjb21wbGV0ZWx5IGFuZCBhY2tub3dsZWRnZSBhbnkgZmFpbGVk DQogICAgICByZXF1ZXN0cyB3aXRoIGEgU1NIX01TR19VU0VSQVVUSF9GQUlM VVJFIG1lc3NhZ2UgYmVmb3JlIHByb2Nlc3NpbmcNCiAgICAgIHRoZSBuZXh0 IHJlcXVlc3QuDQoNCiAgICAgIEEgcmVxdWVzdCB0aGF0IHJlc3VsdHMgaW4g ZnVydGhlciBleGNoYW5nZSBvZiBtZXNzYWdlcyB3aWxsIGJlDQogICAgICBh Ym9ydGVkIGJ5IGEgc2Vjb25kIHJlcXVlc3QuICBJdCBpcyBub3QgcG9zc2li bGUgdG8gc2VuZCBhIHNlY29uZA0KICAgICAgcmVxdWVzdCB3aXRob3V0IHdh aXRpbmcgZm9yIGEgcmVzcG9uc2UgZnJvbSB0aGUgc2VydmVyLCBpZiB0aGUN CiAgICAgIGZpcnN0IHJlcXVlc3Qgd2lsbCByZXN1bHQgaW4gZnVydGhlciBl eGNoYW5nZSBvZiBtZXNzYWdlcy4gIE5vDQogICAgICBTU0hfTVNHX1VTRVJB VVRIX0ZBSUxVUkUgbWVzc2FnZSB3aWxsIGJlIHNlbnQgZm9yIHRoZSBhYm9y dGVkDQogICAgICBtZXRob2QuDQoNCiAgICAgIFNTSF9NU0dfVVNFUkFVVEhf U1VDQ0VTUyBNVVNUIGJlIHNlbnQgb25seSBvbmNlLiAgV2hlbg0KDQoNCg0K WWxvbmVuLCBldC4gYWwuICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIsIDIw MDMgICAgICAgICAgICAgICAgIFtQYWdlIDVdDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgICAgIFNTSCBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAgICAgICAg U2VwdGVtYmVyIDIwMDINCg0KDQogICAgICBTU0hfTVNHX1VTRVJBVVRIX1NV Q0NFU1MgaGFzIGJlZW4gc2VudCwgYW55IGZ1cnRoZXIgYXV0aGVudGljYXRp b24NCiAgICAgIHJlcXVlc3RzIHJlY2VpdmVkIGFmdGVyIHRoYXQgU0hPVUxE IGJlIHNpbGVudGx5IGlnbm9yZWQuDQoNCiAgICAgIEFueSBub24tYXV0aGVu dGljYXRpb24gbWVzc2FnZXMgc2VudCBieSB0aGUgY2xpZW50IGFmdGVyIHRo ZQ0KICAgICAgcmVxdWVzdCB0aGF0IHJlc3VsdGVkIGluIFNTSF9NU0dfVVNF UkFVVEhfU1VDQ0VTUyBiZWluZyBzZW50IE1VU1QNCiAgICAgIGJlIHBhc3Nl ZCB0byB0aGUgc2VydmljZSBiZWluZyBydW4gb24gdG9wIG9mIHRoaXMgcHJv dG9jb2wuICBTdWNoDQogICAgICBtZXNzYWdlcyBjYW4gYmUgaWRlbnRpZmll ZCBieSB0aGVpciBtZXNzYWdlIG51bWJlcnMgKHNlZSBTZWN0aW9uDQogICAg ICBNZXNzYWdlIE51bWJlcnMgKFNlY3Rpb24gMykpLg0KDQogICAyLjMgVGhl ICJub25lIiBBdXRoZW50aWNhdGlvbiBSZXF1ZXN0DQoNCiAgICAgIEEgY2xp ZW50IG1heSByZXF1ZXN0IGEgbGlzdCBvZiBhdXRoZW50aWNhdGlvbiBtZXRo b2RzIHRoYXQgbWF5DQogICAgICBjb250aW51ZSBieSB1c2luZyB0aGUgIm5v bmUiIGF1dGhlbnRpY2F0aW9uIG1ldGhvZC4NCg0KICAgICAgSWYgbm8gYXV0 aGVudGljYXRpb24gYXQgYWxsIGlzIG5lZWRlZCBmb3IgdGhlIHVzZXIsIHRo ZSBzZXJ2ZXINCiAgICAgIE1VU1QgcmV0dXJuIFNTSF9NU0dfVVNFUkFVVEhf U1VDQ0VTUy4gIE90aGVyd2lzZSwgdGhlIHNlcnZlciBNVVNUDQogICAgICBy ZXR1cm4gU1NIX01TR19VU0VSQVVUSF9GQUlMVVJFIGFuZCBNQVkgcmV0dXJu IHdpdGggaXQgYSBsaXN0IG9mDQogICAgICBhdXRoZW50aWNhdGlvbiBtZXRo b2RzIHRoYXQgY2FuIGNvbnRpbnVlLg0KDQogICAgICBUaGlzIG1ldGhvZCBN VVNUIE5PVCBiZSBsaXN0ZWQgYXMgc3VwcG9ydGVkIGJ5IHRoZSBzZXJ2ZXIu DQoNCiAgIDIuNCBDb21wbGV0aW9uIG9mIFVzZXIgQXV0aGVudGljYXRpb24N Cg0KICAgICAgQXV0aGVudGljYXRpb24gaXMgY29tcGxldGUgd2hlbiB0aGUg c2VydmVyIGhhcyByZXNwb25kZWQgd2l0aA0KICAgICAgU1NIX01TR19VU0VS QVVUSF9TVUNDRVNTOyBhbGwgYXV0aGVudGljYXRpb24gcmVsYXRlZCBtZXNz YWdlcw0KICAgICAgcmVjZWl2ZWQgYWZ0ZXIgc2VuZGluZyB0aGlzIG1lc3Nh Z2UgU0hPVUxEIGJlIHNpbGVudGx5IGlnbm9yZWQuDQoNCiAgICAgIEFmdGVy IHNlbmRpbmcgU1NIX01TR19VU0VSQVVUSF9TVUNDRVNTLCB0aGUgc2VydmVy IHN0YXJ0cyB0aGUNCiAgICAgIHJlcXVlc3RlZCBzZXJ2aWNlLg0KDQogICAy LjUgQmFubmVyIE1lc3NhZ2UNCg0KICAgICAgSW4gc29tZSBqdXJpc2RpY3Rp b25zLCBzZW5kaW5nIGEgd2FybmluZyBtZXNzYWdlIGJlZm9yZQ0KICAgICAg YXV0aGVudGljYXRpb24gbWF5IGJlIHJlbGV2YW50IGZvciBnZXR0aW5nIGxl Z2FsIHByb3RlY3Rpb24uICBNYW55DQogICAgICBVTklYIG1hY2hpbmVzLCBm b3IgZXhhbXBsZSwgbm9ybWFsbHkgZGlzcGxheSB0ZXh0IGZyb20NCiAgICAg IGAvZXRjL2lzc3VlJywgb3IgdXNlICJ0Y3Agd3JhcHBlcnMiIG9yIHNpbWls YXIgc29mdHdhcmUgdG8gZGlzcGxheQ0KICAgICAgYSBiYW5uZXIgYmVmb3Jl IGlzc3VpbmcgYSBsb2dpbiBwcm9tcHQuDQoNCiAgICAgIFRoZSBTU0ggc2Vy dmVyIG1heSBzZW5kIGEgU1NIX01TR19VU0VSQVVUSF9CQU5ORVIgbWVzc2Fn ZSBhdCBhbnkNCiAgICAgIHRpbWUgYmVmb3JlIGF1dGhlbnRpY2F0aW9uIGlz IHN1Y2Nlc3NmdWwuICBUaGlzIG1lc3NhZ2UgY29udGFpbnMNCiAgICAgIHRl eHQgdG8gYmUgZGlzcGxheWVkIHRvIHRoZSBjbGllbnQgdXNlciBiZWZvcmUg YXV0aGVudGljYXRpb24gaXMNCiAgICAgIGF0dGVtcHRlZC4gIFRoZSBmb3Jt YXQgaXMgYXMgZm9sbG93czoNCg0KICAgICBieXRlICAgICAgU1NIX01TR19V U0VSQVVUSF9CQU5ORVINCiAgICAgc3RyaW5nICAgIG1lc3NhZ2UgKElTTy0x MDY0NiBVVEYtOCkNCiAgICAgc3RyaW5nICAgIGxhbmd1YWdlIHRhZyAoYXMg ZGVmaW5lZCBpbiBbUkZDMTc2Nl0pDQoNCiAgICAgIFRoZSBjbGllbnQgU0hP VUxEIGJ5IGRlZmF1bHQgZGlzcGxheSB0aGUgbWVzc2FnZSBvbiB0aGUgc2Ny ZWVuLg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgICBFeHBpcmVz IE1hcmNoIDIsIDIwMDMgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgICAgIFNTSCBBdXRoZW50aWNhdGlvbiBQcm90 b2NvbCAgICAgICAgU2VwdGVtYmVyIDIwMDINCg0KDQogICAgICBIb3dldmVy LCBzaW5jZSB0aGUgbWVzc2FnZSBpcyBsaWtlbHkgdG8gYmUgc2VudCBmb3Ig ZXZlcnkgbG9naW4NCiAgICAgIGF0dGVtcHQsIGFuZCBzaW5jZSBzb21lIGNs aWVudCBzb2Z0d2FyZSB3aWxsIG5lZWQgdG8gb3BlbiBhDQogICAgICBzZXBh cmF0ZSB3aW5kb3cgZm9yIHRoaXMgd2FybmluZywgdGhlIGNsaWVudCBzb2Z0 d2FyZSBtYXkgYWxsb3cNCiAgICAgIHRoZSB1c2VyIHRvIGV4cGxpY2l0bHkg ZGlzYWJsZSB0aGUgZGlzcGxheSBvZiBiYW5uZXJzIGZyb20gdGhlDQogICAg ICBzZXJ2ZXIuICBUaGUgbWVzc2FnZSBtYXkgY29uc2lzdCBvZiBtdWx0aXBs ZSBsaW5lcy4NCg0KICAgICAgSWYgdGhlIG1lc3NhZ2Ugc3RyaW5nIGlzIGRp c3BsYXllZCwgY29udHJvbCBjaGFyYWN0ZXIgZmlsdGVyaW5nDQogICAgICBk aXNjdXNzZWQgaW4gW1NTSC1BUkNIXSBTSE9VTEQgYmUgdXNlZCB0byBhdm9p ZCBhdHRhY2tzIGJ5IHNlbmRpbmcNCiAgICAgIHRlcm1pbmFsIGNvbnRyb2wg Y2hhcmFjdGVycy4NCg0KICAgMy4gQXV0aGVudGljYXRpb24gUHJvdG9jb2wg TWVzc2FnZSBOdW1iZXJzDQoNCiAgICAgIEFsbCBtZXNzYWdlIG51bWJlcnMg dXNlZCBieSB0aGlzIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIGFyZSBpbg0K ICAgICAgdGhlIHJhbmdlIGZyb20gNTAgdG8gNzksIHdoaWNoIGlzIHBhcnQg b2YgdGhlIHJhbmdlIHJlc2VydmVkIGZvcg0KICAgICAgcHJvdG9jb2xzIHJ1 bm5pbmcgb24gdG9wIG9mIHRoZSBTU0ggdHJhbnNwb3J0IGxheWVyIHByb3Rv Y29sLg0KDQogICAgICBNZXNzYWdlIG51bWJlcnMgb2YgODAgYW5kIGhpZ2hl ciBhcmUgcmVzZXJ2ZWQgZm9yIHByb3RvY29scw0KICAgICAgcnVubmluZyBh ZnRlciB0aGlzIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLCBzbyByZWNlaXZp bmcgb25lIG9mDQogICAgICB0aGVtIGJlZm9yZSBhdXRoZW50aWNhdGlvbiBp cyBjb21wbGV0ZSBpcyBhbiBlcnJvciwgdG8gd2hpY2ggdGhlDQogICAgICBz ZXJ2ZXIgTVVTVCByZXNwb25kIGJ5IGRpc2Nvbm5lY3RpbmcgKHByZWZlcmFi bHkgd2l0aCBhIHByb3Blcg0KICAgICAgZGlzY29ubmVjdCBtZXNzYWdlIHNl bnQgZmlyc3QgdG8gZWFzZSB0cm91Ymxlc2hvb3RpbmcpLg0KDQogICAgICBB ZnRlciBzdWNjZXNzZnVsIGF1dGhlbnRpY2F0aW9uLCBzdWNoIG1lc3NhZ2Vz IGFyZSBwYXNzZWQgdG8gdGhlDQogICAgICBoaWdoZXItbGV2ZWwgc2Vydmlj ZS4NCg0KICAgICAgVGhlc2UgYXJlIHRoZSBnZW5lcmFsIGF1dGhlbnRpY2F0 aW9uIG1lc3NhZ2UgY29kZXM6DQoNCiAgICAgI2RlZmluZSBTU0hfTVNHX1VT RVJBVVRIX1JFUVVFU1QgICAgICAgICAgICA1MA0KICAgICAjZGVmaW5lIFNT SF9NU0dfVVNFUkFVVEhfRkFJTFVSRSAgICAgICAgICAgIDUxDQogICAgICNk ZWZpbmUgU1NIX01TR19VU0VSQVVUSF9TVUNDRVNTICAgICAgICAgICAgNTIN CiAgICAgI2RlZmluZSBTU0hfTVNHX1VTRVJBVVRIX0JBTk5FUiAgICAgICAg ICAgICA1Mw0KDQogICAgICBJbiBhZGRpdGlvbiB0byB0aGUgYWJvdmUsIHRo ZXJlIGlzIGEgcmFuZ2Ugb2YgbWVzc2FnZSBudW1iZXJzDQogICAgICAoNjAu Ljc5KSByZXNlcnZlZCBmb3IgbWV0aG9kLXNwZWNpZmljIG1lc3NhZ2VzLiAg VGhlc2UgbWVzc2FnZXMNCiAgICAgIGFyZSBvbmx5IHNlbnQgYnkgdGhlIHNl cnZlciAoY2xpZW50IHNlbmRzIG9ubHkNCiAgICAgIFNTSF9NU0dfVVNFUkFV VEhfUkVRVUVTVCBtZXNzYWdlcykuICBEaWZmZXJlbnQgYXV0aGVudGljYXRp b24NCiAgICAgIG1ldGhvZHMgcmV1c2UgdGhlIHNhbWUgbWVzc2FnZSBudW1i ZXJzLg0KDQogICA0LiBQdWJsaWMgS2V5IEF1dGhlbnRpY2F0aW9uIE1ldGhv ZDogcHVibGlja2V5DQoNCiAgICAgIFRoZSBvbmx5IFJFUVVJUkVEIGF1dGhl bnRpY2F0aW9uIG1ldGhvZCBpcyBwdWJsaWMga2V5DQogICAgICBhdXRoZW50 aWNhdGlvbi4gIEFsbCBpbXBsZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IHRo aXMgbWV0aG9kOw0KICAgICAgaG93ZXZlciwgbm90IGFsbCB1c2VycyBuZWVk IHRvIGhhdmUgcHVibGljIGtleXMsIGFuZCBtb3N0IGxvY2FsDQogICAgICBw b2xpY2llcyBhcmUgbm90IGxpa2VseSB0byByZXF1aXJlIHB1YmxpYyBrZXkg YXV0aGVudGljYXRpb24gZm9yDQogICAgICBhbGwgdXNlcnMgaW4gdGhlIG5l YXIgZnV0dXJlLg0KDQogICAgICBXaXRoIHRoaXMgbWV0aG9kLCB0aGUgcG9z c2Vzc2lvbiBvZiBhIHByaXZhdGUga2V5IHNlcnZlcyBhcw0KICAgICAgYXV0 aGVudGljYXRpb24uICBUaGlzIG1ldGhvZCB3b3JrcyBieSBzZW5kaW5nIGEg c2lnbmF0dXJlIGNyZWF0ZWQNCg0KDQoNCllsb25lbiwgZXQuIGFsLiAgICAg ICAgICAgRXhwaXJlcyBNYXJjaCAyLCAyMDAzICAgICAgICAgICAgICAgICBb UGFnZSA3XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICBTU0ggQXV0aGVu dGljYXRpb24gUHJvdG9jb2wgICAgICAgIFNlcHRlbWJlciAyMDAyDQoNCg0K ICAgICAgd2l0aCBhIHByaXZhdGUga2V5IG9mIHRoZSB1c2VyLiAgVGhlIHNl cnZlciBNVVNUIGNoZWNrIHRoYXQgdGhlDQogICAgICBrZXkgaXMgYSB2YWxp ZCBhdXRoZW50aWNhdG9yIGZvciB0aGUgdXNlciwgYW5kIE1VU1QgY2hlY2sg dGhhdCB0aGUNCiAgICAgIHNpZ25hdHVyZSBpcyB2YWxpZC4gIElmIGJvdGgg aG9sZCwgdGhlIGF1dGhlbnRpY2F0aW9uIHJlcXVlc3QgTVVTVA0KICAgICAg YmUgYWNjZXB0ZWQ7IG90aGVyd2lzZSBpdCBNVVNUIGJlIHJlamVjdGVkLiAg KE5vdGUgdGhhdCB0aGUgc2VydmVyDQogICAgICBNQVkgcmVxdWlyZSBhZGRp dGlvbmFsIGF1dGhlbnRpY2F0aW9ucyBhZnRlciBzdWNjZXNzZnVsDQogICAg ICBhdXRoZW50aWNhdGlvbi4pDQoNCiAgICAgIFByaXZhdGUga2V5cyBhcmUg b2Z0ZW4gc3RvcmVkIGluIGFuIGVuY3J5cHRlZCBmb3JtIGF0IHRoZSBjbGll bnQNCiAgICAgIGhvc3QsIGFuZCB0aGUgdXNlciBtdXN0IHN1cHBseSBhIHBh c3NwaHJhc2UgYmVmb3JlIHRoZSBzaWduYXR1cmUNCiAgICAgIGNhbiBiZSBn ZW5lcmF0ZWQuICBFdmVuIGlmIHRoZXkgYXJlIG5vdCwgdGhlIHNpZ25pbmcg b3BlcmF0aW9uDQogICAgICBpbnZvbHZlcyBzb21lIGV4cGVuc2l2ZSBjb21w dXRhdGlvbi4gIFRvIGF2b2lkIHVubmVjZXNzYXJ5DQogICAgICBwcm9jZXNz aW5nIGFuZCB1c2VyIGludGVyYWN0aW9uLCB0aGUgZm9sbG93aW5nIG1lc3Nh Z2UgaXMgcHJvdmlkZWQNCiAgICAgIGZvciBxdWVyeWluZyB3aGV0aGVyIGF1 dGhlbnRpY2F0aW9uIHVzaW5nIHRoZSBrZXkgd291bGQgYmUNCiAgICAgIGFj Y2VwdGFibGUuDQoNCiAgICAgYnl0ZSAgICAgIFNTSF9NU0dfVVNFUkFVVEhf UkVRVUVTVA0KICAgICBzdHJpbmcgICAgdXNlciBuYW1lDQogICAgIHN0cmlu ZyAgICBzZXJ2aWNlDQogICAgIHN0cmluZyAgICAicHVibGlja2V5Ig0KICAg ICBib29sZWFuICAgRkFMU0UNCiAgICAgc3RyaW5nICAgIHB1YmxpYyBrZXkg YWxnb3JpdGhtIG5hbWUNCiAgICAgc3RyaW5nICAgIHB1YmxpYyBrZXkgYmxv Yg0KDQogICAgICBQdWJsaWMga2V5IGFsZ29yaXRobXMgYXJlIGRlZmluZWQg aW4gdGhlIHRyYW5zcG9ydCBsYXllcg0KICAgICAgc3BlY2lmaWNhdGlvbiBb U1NILVRSQU5TXS4gIFRoZSBwdWJsaWMga2V5IGJsb2IgbWF5IGNvbnRhaW4N CiAgICAgIGNlcnRpZmljYXRlcy4NCg0KICAgICAgQW55IHB1YmxpYyBrZXkg YWxnb3JpdGhtIG1heSBiZSBvZmZlcmVkIGZvciB1c2UgaW4gYXV0aGVudGlj YXRpb24uDQogICAgICBJbiBwYXJ0aWN1bGFyLCB0aGUgbGlzdCBpcyBub3Qg Y29uc3RyYWluZWQgYnkgd2hhdCB3YXMgbmVnb3RpYXRlZA0KICAgICAgZHVy aW5nIGtleSBleGNoYW5nZS4gIElmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc3Vw cG9ydCBzb21lDQogICAgICBhbGdvcml0aG0sIGl0IE1VU1Qgc2ltcGx5IHJl amVjdCB0aGUgcmVxdWVzdC4NCg0KICAgICAgVGhlIHNlcnZlciBNVVNUIHJl c3BvbmQgdG8gdGhpcyBtZXNzYWdlIHdpdGggZWl0aGVyDQogICAgICBTU0hf TVNHX1VTRVJBVVRIX0ZBSUxVUkUgb3Igd2l0aCB0aGUgZm9sbG93aW5nOg0K DQogICAgIGJ5dGUgICAgICBTU0hfTVNHX1VTRVJBVVRIX1BLX09LDQogICAg IHN0cmluZyAgICBwdWJsaWMga2V5IGFsZ29yaXRobSBuYW1lIGZyb20gdGhl IHJlcXVlc3QNCiAgICAgc3RyaW5nICAgIHB1YmxpYyBrZXkgYmxvYiBmcm9t IHRoZSByZXF1ZXN0DQoNCiAgICAgIFRvIHBlcmZvcm0gYWN0dWFsIGF1dGhl bnRpY2F0aW9uLCB0aGUgY2xpZW50IE1BWSB0aGVuIHNlbmQgYQ0KICAgICAg c2lnbmF0dXJlIGdlbmVyYXRlZCB1c2luZyB0aGUgcHJpdmF0ZSBrZXkuICBU aGUgY2xpZW50IE1BWSBzZW5kDQogICAgICB0aGUgc2lnbmF0dXJlIGRpcmVj dGx5IHdpdGhvdXQgZmlyc3QgdmVyaWZ5aW5nIHdoZXRoZXIgdGhlIGtleSBp cw0KICAgICAgYWNjZXB0YWJsZS4gIFRoZSBzaWduYXR1cmUgaXMgc2VudCB1 c2luZyB0aGUgZm9sbG93aW5nIHBhY2tldDoNCg0KICAgICBieXRlICAgICAg U1NIX01TR19VU0VSQVVUSF9SRVFVRVNUDQogICAgIHN0cmluZyAgICB1c2Vy IG5hbWUNCiAgICAgc3RyaW5nICAgIHNlcnZpY2UNCiAgICAgc3RyaW5nICAg ICJwdWJsaWNrZXkiDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICAg IEV4cGlyZXMgTWFyY2ggMiwgMjAwMyAgICAgICAgICAgICAgICAgW1BhZ2Ug OF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgU1NIIEF1dGhlbnRpY2F0 aW9uIFByb3RvY29sICAgICAgICBTZXB0ZW1iZXIgMjAwMg0KDQoNCiAgICAg Ym9vbGVhbiAgIFRSVUUNCiAgICAgc3RyaW5nICAgIHB1YmxpYyBrZXkgYWxn b3JpdGhtIG5hbWUNCiAgICAgc3RyaW5nICAgIHB1YmxpYyBrZXkgdG8gYmUg dXNlZCBmb3IgYXV0aGVudGljYXRpb24NCiAgICAgc3RyaW5nICAgIHNpZ25h dHVyZQ0KDQogICAgICBTaWduYXR1cmUgaXMgYSBzaWduYXR1cmUgYnkgdGhl IGNvcnJlc3BvbmRpbmcgcHJpdmF0ZSBrZXkgb3ZlciB0aGUNCiAgICAgIGZv bGxvd2luZyBkYXRhLCBpbiB0aGUgZm9sbG93aW5nIG9yZGVyOg0KDQogICAg IHN0cmluZyAgICBzZXNzaW9uIGlkZW50aWZpZXINCiAgICAgYnl0ZSAgICAg IFNTSF9NU0dfVVNFUkFVVEhfUkVRVUVTVA0KICAgICBzdHJpbmcgICAgdXNl ciBuYW1lDQogICAgIHN0cmluZyAgICBzZXJ2aWNlDQogICAgIHN0cmluZyAg ICAicHVibGlja2V5Ig0KICAgICBib29sZWFuICAgVFJVRQ0KICAgICBzdHJp bmcgICAgcHVibGljIGtleSBhbGdvcml0aG0gbmFtZQ0KICAgICBzdHJpbmcg ICAgcHVibGljIGtleSB0byBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbg0K DQogICAgICBXaGVuIHRoZSBzZXJ2ZXIgcmVjZWl2ZXMgdGhpcyBtZXNzYWdl LCBpdCBNVVNUIGNoZWNrIHdoZXRoZXIgdGhlDQogICAgICBzdXBwbGllZCBr ZXkgaXMgYWNjZXB0YWJsZSBmb3IgYXV0aGVudGljYXRpb24sIGFuZCBpZiBz bywgaXQgTVVTVA0KICAgICAgY2hlY2sgd2hldGhlciB0aGUgc2lnbmF0dXJl IGlzIGNvcnJlY3QuDQoNCiAgICAgIElmIGJvdGggY2hlY2tzIHN1Y2NlZWQs IHRoaXMgbWV0aG9kIGlzIHN1Y2Nlc3NmdWwuICBOb3RlIHRoYXQgdGhlDQog ICAgICBzZXJ2ZXIgbWF5IHJlcXVpcmUgYWRkaXRpb25hbCBhdXRoZW50aWNh dGlvbnMuICBUaGUgc2VydmVyIE1VU1QNCiAgICAgIHJlc3BvbmQgd2l0aCBT U0hfTVNHX1VTRVJBVVRIX1NVQ0NFU1MgKGlmIG5vIG1vcmUgYXV0aGVudGlj YXRpb25zDQogICAgICBhcmUgbmVlZGVkKSwgb3IgU1NIX01TR19VU0VSQVVU SF9GQUlMVVJFIChpZiB0aGUgcmVxdWVzdCBmYWlsZWQsDQogICAgICBvciBt b3JlIGF1dGhlbnRpY2F0aW9ucyBhcmUgbmVlZGVkKS4NCg0KICAgICAgVGhl IGZvbGxvd2luZyBtZXRob2Qtc3BlY2lmaWMgbWVzc2FnZSBudW1iZXJzIGFy ZSB1c2VkIGJ5IHRoZQ0KICAgICAgcHVibGlja2V5IGF1dGhlbnRpY2F0aW9u IG1ldGhvZC4NCg0KICAgICAvKiBLZXktYmFzZWQgKi8NCiAgICAgI2RlZmlu ZSBTU0hfTVNHX1VTRVJBVVRIX1BLX09LICAgICAgICAgICAgICA2MA0KDQoN CiAgIDUuIFBhc3N3b3JkIEF1dGhlbnRpY2F0aW9uIE1ldGhvZDogcGFzc3dv cmQNCg0KICAgICAgUGFzc3dvcmQgYXV0aGVudGljYXRpb24gdXNlcyB0aGUg Zm9sbG93aW5nIHBhY2tldHMuICBOb3RlIHRoYXQgYQ0KICAgICAgc2VydmVy IE1BWSByZXF1ZXN0IHRoZSB1c2VyIHRvIGNoYW5nZSB0aGUgcGFzc3dvcmQu ICBBbGwNCiAgICAgIGltcGxlbWVudGF0aW9ucyBTSE9VTEQgc3VwcG9ydCBw YXNzd29yZCBhdXRoZW50aWNhdGlvbi4NCg0KICAgICBieXRlICAgICAgU1NI X01TR19VU0VSQVVUSF9SRVFVRVNUDQogICAgIHN0cmluZyAgICB1c2VyIG5h bWUNCiAgICAgc3RyaW5nICAgIHNlcnZpY2UNCiAgICAgc3RyaW5nICAgICJw YXNzd29yZCINCiAgICAgYm9vbGVhbiAgIEZBTFNFDQogICAgIHN0cmluZyAg ICBwbGFpbnRleHQgcGFzc3dvcmQgKElTTy0xMDY0NiBVVEYtOCkNCg0KICAg ICAgTm90ZSB0aGF0IHRoZSBwYXNzd29yZCBpcyBlbmNvZGVkIGluIElTTy0x MDY0NiBVVEYtOC4gIEl0IGlzIHVwIHRvDQoNCg0KDQpZbG9uZW4sIGV0LiBh bC4gICAgICAgICAgIEV4cGlyZXMgTWFyY2ggMiwgMjAwMyAgICAgICAgICAg ICAgICAgW1BhZ2UgOV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgU1NI IEF1dGhlbnRpY2F0aW9uIFByb3RvY29sICAgICAgICBTZXB0ZW1iZXIgMjAw Mg0KDQoNCiAgICAgIHRoZSBzZXJ2ZXIgaG93IGl0IGludGVycHJldHMgdGhl IHBhc3N3b3JkIGFuZCB2YWxpZGF0ZXMgaXQgYWdhaW5zdA0KICAgICAgdGhl IHBhc3N3b3JkIGRhdGFiYXNlLiAgSG93ZXZlciwgaWYgdGhlIGNsaWVudCBy ZWFkcyB0aGUgcGFzc3dvcmQNCiAgICAgIGluIHNvbWUgb3RoZXIgZW5jb2Rp bmcgKGUuZy4sIElTTyA4ODU5LTEgKElTTyBMYXRpbjEpKSwgaXQgTVVTVA0K ICAgICAgY29udmVydCB0aGUgcGFzc3dvcmQgdG8gSVNPLTEwNjQ2IFVURi04 IGJlZm9yZSB0cmFuc21pdHRpbmcsIGFuZA0KICAgICAgdGhlIHNlcnZlciBN VVNUIGNvbnZlcnQgdGhlIHBhc3N3b3JkIHRvIHRoZSBlbmNvZGluZyB1c2Vk IG9uIHRoYXQNCiAgICAgIHN5c3RlbSBmb3IgcGFzc3dvcmRzLg0KDQogICAg ICBOb3RlIHRoYXQgZXZlbiB0aG91Z2ggdGhlIGNsZWFydGV4dCBwYXNzd29y ZCBpcyB0cmFuc21pdHRlZCBpbiB0aGUNCiAgICAgIHBhY2tldCwgdGhlIGVu dGlyZSBwYWNrZXQgaXMgZW5jcnlwdGVkIGJ5IHRoZSB0cmFuc3BvcnQgbGF5 ZXIuDQogICAgICBCb3RoIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjbGllbnQgc2hv dWxkIGNoZWNrIHdoZXRoZXIgdGhlIHVuZGVybHlpbmcNCiAgICAgIHRyYW5z cG9ydCBsYXllciBwcm92aWRlcyBjb25maWRlbnRpYWxpdHkgKGkuZS4sIGlm IGVuY3J5cHRpb24gaXMNCiAgICAgIGJlaW5nIHVzZWQpLiAgSWYgbm8gY29u ZmlkZW50aWFsaXR5IGlzIHByb3ZpZGVkIChub25lIGNpcGhlciksDQogICAg ICBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiBTSE9VTEQgYmUgZGlzYWJsZWQu ICBJZiB0aGVyZSBpcyBubw0KICAgICAgY29uZmlkZW50aWFsaXR5IG9yIG5v IE1BQywgcGFzc3dvcmQgY2hhbmdlIFNIT1VMRCBiZSBkaXNhYmxlZC4NCg0K ICAgICAgTm9ybWFsbHksIHRoZSBzZXJ2ZXIgcmVzcG9uZHMgdG8gdGhpcyBt ZXNzYWdlIHdpdGggc3VjY2VzcyBvcg0KICAgICAgZmFpbHVyZS4gIEhvd2V2 ZXIsIGlmIHRoZSBwYXNzd29yZCBoYXMgZXhwaXJlZCB0aGUgc2VydmVyIFNI T1VMRA0KICAgICAgaW5kaWNhdGUgdGhpcyBieSByZXNwb25kaW5nIHdpdGgN CiAgICAgIFNTSF9NU0dfVVNFUkFVVEhfUEFTU1dEX0NIQU5HRVJFUS4gIElu IGFueWNhc2UgdGhlIHNlcnZlciBNVVNUIE5PVA0KICAgICAgYWxsb3cgYW4g ZXhwaXJlZCBwYXNzd29yZCB0byBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlv bi4NCg0KICAgICBieXRlICAgICAgU1NIX01TR19VU0VSQVVUSF9QQVNTV0Rf Q0hBTkdFUkVRDQogICAgIHN0cmluZyAgICBwcm9tcHQgKElTTy0xMDY0NiBV VEYtOCkNCiAgICAgc3RyaW5nICAgIGxhbmd1YWdlIHRhZyAoYXMgZGVmaW5l ZCBpbiBbUkZDMTc2Nl0pDQoNCiAgICAgIEluIHRoaXMgY2FzZSwgdGhlIGNs aWVudCBNQVkgY29udGludWUgd2l0aCBhIGRpZmZlcmVudA0KICAgICAgYXV0 aGVudGljYXRpb24gbWV0aG9kLCBvciByZXF1ZXN0IGEgbmV3IHBhc3N3b3Jk IGZyb20gdGhlIHVzZXIgYW5kDQogICAgICByZXRyeSBwYXNzd29yZCBhdXRo ZW50aWNhdGlvbiB1c2luZyB0aGUgZm9sbG93aW5nIG1lc3NhZ2UuICBUaGUN CiAgICAgIGNsaWVudCBNQVkgYWxzbyBzZW5kIHRoaXMgbWVzc2FnZSBpbnN0 ZWFkIG9mIHRoZSBub3JtYWwgcGFzc3dvcmQNCiAgICAgIGF1dGhlbnRpY2F0 aW9uIHJlcXVlc3Qgd2l0aG91dCB0aGUgc2VydmVyIGFza2luZyBmb3IgaXQu DQoNCiAgICAgYnl0ZSAgICAgIFNTSF9NU0dfVVNFUkFVVEhfUkVRVUVTVA0K ICAgICBzdHJpbmcgICAgdXNlciBuYW1lDQogICAgIHN0cmluZyAgICBzZXJ2 aWNlDQogICAgIHN0cmluZyAgICAicGFzc3dvcmQiDQogICAgIGJvb2xlYW4g ICBUUlVFDQogICAgIHN0cmluZyAgICBwbGFpbnRleHQgb2xkIHBhc3N3b3Jk IChJU08tMTA2NDYgVVRGLTgpDQogICAgIHN0cmluZyAgICBwbGFpbnRleHQg bmV3IHBhc3N3b3JkIChJU08tMTA2NDYgVVRGLTgpDQoNCiAgICAgIFRoZSBz ZXJ2ZXIgbXVzdCByZXBseSB0byByZXF1ZXN0IG1lc3NhZ2Ugd2l0aA0KICAg ICAgU1NIX01TR19VU0VSQVVUSF9TVUNDRVNTLCBTU0hfTVNHX1VTRVJBVVRI X0ZBSUxVUkUsIG9yIGFub3RoZXINCiAgICAgIFNTSF9NU0dfVVNFUkFVVEhf UEFTU1dEX0NIQU5HRVJFUS4gIFRoZSBtZWFuaW5nIG9mIHRoZXNlIGlzIGFz DQogICAgICBmb2xsb3dzOg0KDQogICAgICAgICBTU0hfTVNHX1VTRVJBVVRI X1NVQ0NFU1MgVGhlIHBhc3N3b3JkIGhhcyBiZWVuIGNoYW5nZWQsIGFuZA0K ICAgICAgICAgYXV0aGVudGljYXRpb24gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IGNvbXBsZXRlZC4NCg0KICAgICAgICAgU1NIX01TR19VU0VSQVVUSF9GQUlM VVJFIHdpdGggcGFydGlhbCBzdWNjZXNzIFRoZSBwYXNzd29yZCBoYXMNCg0K DQoNCllsb25lbiwgZXQuIGFsLiAgICAgICAgICAgRXhwaXJlcyBNYXJjaCAy LCAyMDAzICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQt RHJhZnQgICAgICAgICBTU0ggQXV0aGVudGljYXRpb24gUHJvdG9jb2wgICAg ICAgIFNlcHRlbWJlciAyMDAyDQoNCg0KICAgICAgICAgYmVlbiBjaGFuZ2Vk LCBidXQgbW9yZSBhdXRoZW50aWNhdGlvbnMgYXJlIG5lZWRlZC4NCg0KICAg ICAgICAgU1NIX01TR19VU0VSQVVUSF9GQUlMVVJFIHdpdGhvdXQgcGFydGlh bCBzdWNjZXNzIFRoZSBwYXNzd29yZA0KICAgICAgICAgaGFzIG5vdCBiZWVu IGNoYW5nZWQuICBFaXRoZXIgcGFzc3dvcmQgY2hhbmdpbmcgd2FzIG5vdA0K ICAgICAgICAgc3VwcG9ydGVkLCBvciB0aGUgb2xkIHBhc3N3b3JkIHdhcyBi YWQuICBOb3RlIHRoYXQgaWYgdGhlDQogICAgICAgICBzZXJ2ZXIgaGFzIGFs cmVhZHkgc2VudCBTU0hfTVNHX1VTRVJBVVRIX1BBU1NXRF9DSEFOR0VSRVEs IHdlDQogICAgICAgICBrbm93IHRoYXQgaXQgc3VwcG9ydHMgY2hhbmdpbmcg dGhlIHBhc3N3b3JkLg0KDQogICAgICAgICBTU0hfTVNHX1VTRVJBVVRIX0NI QU5HRVJFUSBUaGUgcGFzc3dvcmQgd2FzIG5vdCBjaGFuZ2VkIGJlY2F1c2UN CiAgICAgICAgIHRoZSBuZXcgcGFzc3dvcmQgd2FzIG5vdCBhY2NlcHRhYmxl IChlLmcuICB0b28gZWFzeSB0byBndWVzcykuDQoNCiAgICAgIFRoZSBmb2xs b3dpbmcgbWV0aG9kLXNwZWNpZmljIG1lc3NhZ2UgbnVtYmVycyBhcmUgdXNl ZCBieSB0aGUNCiAgICAgIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIG1ldGhv ZC4NCg0KICAgICAjZGVmaW5lIFNTSF9NU0dfVVNFUkFVVEhfUEFTU1dEX0NI QU5HRVJFUSAgIDYwDQoNCg0KICAgNi4gSG9zdC1CYXNlZCBBdXRoZW50aWNh dGlvbjogaG9zdGJhc2VkDQoNCiAgICAgIFNvbWUgc2l0ZXMgd2lzaCB0byBh bGxvdyBhdXRoZW50aWNhdGlvbiBiYXNlZCBvbiB0aGUgaG9zdCB3aGVyZQ0K ICAgICAgdGhlIHVzZXIgaXMgY29taW5nIGZyb20sIGFuZCB0aGUgdXNlciBu YW1lIG9uIHRoZSByZW1vdGUgaG9zdC4NCiAgICAgIFdoaWxlIHRoaXMgZm9y bSBvZiBhdXRoZW50aWNhdGlvbiBpcyBub3Qgc3VpdGFibGUgZm9yIGhpZ2gt DQogICAgICBzZWN1cml0eSBzaXRlcywgaXQgY2FuIGJlIHZlcnkgY29udmVu aWVudCBpbiBtYW55IGVudmlyb25tZW50cy4NCiAgICAgIFRoaXMgZm9ybSBv ZiBhdXRoZW50aWNhdGlvbiBpcyBPUFRJT05BTC4gIFdoZW4gdXNlZCwgc3Bl Y2lhbCBjYXJlDQogICAgICBTSE9VTEQgYmUgdGFrZW4gdG8gcHJldmVudCBh IHJlZ3VsYXIgdXNlciBmcm9tIG9idGFpbmluZyB0aGUNCiAgICAgIHByaXZh dGUgaG9zdCBrZXkuDQoNCiAgICAgIFRoZSBjbGllbnQgcmVxdWVzdHMgdGhp cyBmb3JtIG9mIGF1dGhlbnRpY2F0aW9uIGJ5IHNlbmRpbmcgdGhlDQogICAg ICBmb2xsb3dpbmcgbWVzc2FnZS4gIEl0IGlzIHNpbWlsYXIgdG8gdGhlIFVO SVggInJob3N0cyIgYW5kDQogICAgICAiaG9zdHMuZXF1aXYiIHN0eWxlcyBv ZiBhdXRoZW50aWNhdGlvbiwgZXhjZXB0IHRoYXQgdGhlIGlkZW50aXR5DQog ICAgICBvZiB0aGUgY2xpZW50IGhvc3QgaXMgY2hlY2tlZCBtb3JlIHJpZ29y b3VzbHkuDQoNCiAgICAgIFRoaXMgbWV0aG9kIHdvcmtzIGJ5IGhhdmluZyB0 aGUgY2xpZW50IHNlbmQgYSBzaWduYXR1cmUgY3JlYXRlZA0KICAgICAgd2l0 aCB0aGUgcHJpdmF0ZSBrZXkgb2YgdGhlIGNsaWVudCBob3N0LCB3aGljaCB0 aGUgc2VydmVyIGNoZWNrcw0KICAgICAgd2l0aCB0aGF0IGhvc3QncyBwdWJs aWMga2V5LiAgT25jZSB0aGUgY2xpZW50IGhvc3QncyBpZGVudGl0eSBpcw0K ICAgICAgZXN0YWJsaXNoZWQsIGF1dGhvcml6YXRpb24gKGJ1dCBubyBmdXJ0 aGVyIGF1dGhlbnRpY2F0aW9uKSBpcw0KICAgICAgcGVyZm9ybWVkIGJhc2Vk IG9uIHRoZSB1c2VyIG5hbWVzIG9uIHRoZSBzZXJ2ZXIgYW5kIHRoZSBjbGll bnQsDQogICAgICBhbmQgdGhlIGNsaWVudCBob3N0IG5hbWUuDQoNCiAgICAg Ynl0ZSAgICAgIFNTSF9NU0dfVVNFUkFVVEhfUkVRVUVTVA0KICAgICBzdHJp bmcgICAgdXNlciBuYW1lDQogICAgIHN0cmluZyAgICBzZXJ2aWNlDQogICAg IHN0cmluZyAgICAiaG9zdGJhc2VkIg0KICAgICBzdHJpbmcgICAgcHVibGlj IGtleSBhbGdvcml0aG0gZm9yIGhvc3Qga2V5DQogICAgIHN0cmluZyAgICBw dWJsaWMgaG9zdCBrZXkgYW5kIGNlcnRpZmljYXRlcyBmb3IgY2xpZW50IGhv c3QNCiAgICAgc3RyaW5nICAgIGNsaWVudCBob3N0IG5hbWUgKEZRRE47IFVT LUFTQ0lJKQ0KICAgICBzdHJpbmcgICAgdXNlciBuYW1lIG9uIHRoZSBjbGll bnQgaG9zdCAoSVNPLTEwNjQ2IFVURi04KQ0KICAgICBzdHJpbmcgICAgc2ln bmF0dXJlDQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICAgIEV4cGly ZXMgTWFyY2ggMiwgMjAwMyAgICAgICAgICAgICAgICBbUGFnZSAxMV0NCgwN CkludGVybmV0LURyYWZ0ICAgICAgICAgU1NIIEF1dGhlbnRpY2F0aW9uIFBy b3RvY29sICAgICAgICBTZXB0ZW1iZXIgMjAwMg0KDQoNCiAgICAgIFB1Ymxp YyBrZXkgYWxnb3JpdGhtIG5hbWVzIGZvciB1c2UgaW4gInB1YmxpYyBrZXkg YWxnb3JpdGhtIGZvcg0KICAgICAgaG9zdCBrZXkiIGFyZSBkZWZpbmVkIGlu IHRoZSB0cmFuc3BvcnQgbGF5ZXIgc3BlY2lmaWNhdGlvbi4gIFRoZQ0KICAg ICAgInB1YmxpYyBob3N0IGtleSBmb3IgY2xpZW50IGhvc3QiIG1heSBpbmNs dWRlIGNlcnRpZmljYXRlcy4NCg0KICAgICAgU2lnbmF0dXJlIGlzIGEgc2ln bmF0dXJlIHdpdGggdGhlIHByaXZhdGUgaG9zdCBrZXkgb2YgdGhlDQogICAg ICBmb2xsb3dpbmcgZGF0YSwgaW4gdGhpcyBvcmRlcjoNCg0KICAgICBzdHJp bmcgICAgc2Vzc2lvbiBpZGVudGlmaWVyDQogICAgIGJ5dGUgICAgICBTU0hf TVNHX1VTRVJBVVRIX1JFUVVFU1QNCiAgICAgc3RyaW5nICAgIHVzZXIgbmFt ZQ0KICAgICBzdHJpbmcgICAgc2VydmljZQ0KICAgICBzdHJpbmcgICAgImhv c3RiYXNlZCINCiAgICAgc3RyaW5nICAgIHB1YmxpYyBrZXkgYWxnb3JpdGht IGZvciBob3N0IGtleQ0KICAgICBzdHJpbmcgICAgcHVibGljIGhvc3Qga2V5 IGFuZCBjZXJ0aWZpY2F0ZXMgZm9yIGNsaWVudCBob3N0DQogICAgIHN0cmlu ZyAgICBjbGllbnQgaG9zdCBuYW1lIChGUUROOyBVUy1BU0NJSSkNCiAgICAg c3RyaW5nICAgIHVzZXIgbmFtZSBvbiB0aGUgY2xpZW50IGhvc3QoSVNPLTEw NjQ2IFVURi04KQ0KDQogICAgICBUaGUgc2VydmVyIE1VU1QgdmVyaWZ5IHRo YXQgdGhlIGhvc3Qga2V5IGFjdHVhbGx5IGJlbG9uZ3MgdG8gdGhlDQogICAg ICBjbGllbnQgaG9zdCBuYW1lZCBpbiB0aGUgbWVzc2FnZSwgdGhhdCB0aGUg Z2l2ZW4gdXNlciBvbiB0aGF0IGhvc3QNCiAgICAgIGlzIGFsbG93ZWQgdG8g bG9nIGluLCBhbmQgdGhhdCB0aGUgc2lnbmF0dXJlIGlzIGEgdmFsaWQgc2ln bmF0dXJlDQogICAgICBvbiB0aGUgYXBwcm9wcmlhdGUgdmFsdWUgYnkgdGhl IGdpdmVuIGhvc3Qga2V5LiAgVGhlIHNlcnZlciBNQVkNCiAgICAgIGlnbm9y ZSB0aGUgY2xpZW50IHVzZXIgbmFtZSwgaWYgaXQgd2FudHMgdG8gYXV0aGVu dGljYXRlIG9ubHkgdGhlDQogICAgICBjbGllbnQgaG9zdC4NCg0KICAgICAg SXQgaXMgUkVDT01NRU5ERUQgdGhhdCB3aGVuZXZlciBwb3NzaWJsZSwgdGhl IHNlcnZlciBwZXJmb3JtDQogICAgICBhZGRpdGlvbmFsIGNoZWNrcyB0byB2 ZXJpZnkgdGhhdCB0aGUgbmV0d29yayBhZGRyZXNzIG9idGFpbmVkIGZyb20N CiAgICAgIHRoZSAodW50cnVzdGVkKSBuZXR3b3JrIG1hdGNoZXMgdGhlIGdp dmVuIGNsaWVudCBob3N0IG5hbWUuICBUaGlzDQogICAgICBtYWtlcyBleHBs b2l0aW5nIGNvbXByb21pc2VkIGhvc3Qga2V5cyBtb3JlIGRpZmZpY3VsdC4g IE5vdGUgdGhhdA0KICAgICAgdGhpcyBtYXkgcmVxdWlyZSBzcGVjaWFsIGhh bmRsaW5nIGZvciBjb25uZWN0aW9ucyBjb21pbmcgdGhyb3VnaCBhDQogICAg ICBmaXJld2FsbC4NCg0KICAgNy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMN Cg0KICAgICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBwcm90b2NvbCBpcyB0byBw ZXJmb3JtIGNsaWVudCB1c2VyDQogICAgICBhdXRoZW50aWNhdGlvbi4gIEl0 IGFzc3VtZWQgdGhhdCB0aGlzIHJ1bnMgb3ZlciBhIHNlY3VyZSB0cmFuc3Bv cnQNCiAgICAgIGxheWVyIHByb3RvY29sLCB3aGljaCBoYXMgYWxyZWFkeSBh dXRoZW50aWNhdGVkIHRoZSBzZXJ2ZXINCiAgICAgIG1hY2hpbmUsIGVzdGFi bGlzaGVkIGFuIGVuY3J5cHRlZCBjb21tdW5pY2F0aW9ucyBjaGFubmVsLCBh bmQNCiAgICAgIGNvbXB1dGVkIGEgdW5pcXVlIHNlc3Npb24gaWRlbnRpZmll ciBmb3IgdGhpcyBzZXNzaW9uLiAgVGhlDQogICAgICB0cmFuc3BvcnQgbGF5 ZXIgcHJvdmlkZXMgZm9yd2FyZCBzZWNyZWN5IGZvciBwYXNzd29yZA0KICAg ICAgYXV0aGVudGljYXRpb24gYW5kIG90aGVyIG1ldGhvZHMgdGhhdCByZWx5 IG9uIHNlY3JldCBkYXRhLg0KDQogICAgICBGdWxsIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIGZvciB0aGlzIHByb3RvY29sIGFyZSBwcm92aWRlZCBpbg0K ICAgICAgU2VjdGlvbiA4IG9mIFtTU0gtQVJDSF0NCg0KICAgOC4gSW50ZWxs ZWN0dWFsIFByb3BlcnR5DQoNCiAgICAgIFRoZSBJRVRGIHRha2VzIG5vIHBv c2l0aW9uIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55 DQogICAgICBpbnRlbGxlY3R1YWwgcHJvcGVydHkgb3Igb3RoZXIgcmlnaHRz IHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KDQoNCg0KWWxvbmVuLCBldC4g YWwuICAgICAgICAgICBFeHBpcmVzIE1hcmNoIDIsIDIwMDMgICAgICAgICAg ICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIFNT SCBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAgICAgICAgU2VwdGVtYmVyIDIw MDINCg0KDQogICAgICBwZXJ0YWluIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBv ciB1c2Ugb2YgdGhlIHRlY2hub2xvZ3kgZGVzY3JpYmVkDQogICAgICBpbiB0 aGlzIGRvY3VtZW50IG9yIHRoZSBleHRlbnQgdG8gd2hpY2ggYW55IGxpY2Vu c2UgdW5kZXIgc3VjaA0KICAgICAgcmlnaHRzIG1pZ2h0IG9yIG1pZ2h0IG5v dCBiZSBhdmFpbGFibGU7IG5laXRoZXIgZG9lcyBpdCByZXByZXNlbnQNCiAg ICAgIHRoYXQgaXQgaGFzIG1hZGUgYW55IGVmZm9ydCB0byBpZGVudGlmeSBh bnkgc3VjaCByaWdodHMuDQogICAgICBJbmZvcm1hdGlvbiBvbiB0aGUgSUVU RidzIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbg0KICAg ICAgc3RhbmRhcmRzLXRyYWNrIGFuZCBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1 bWVudGF0aW9uIGNhbiBiZSBmb3VuZA0KICAgICAgaW4gQkNQLTExLiAgQ29w aWVzIG9mIGNsYWltcyBvZiByaWdodHMgbWFkZSBhdmFpbGFibGUgZm9yDQog ICAgICBwdWJsaWNhdGlvbiBhbmQgYW55IGFzc3VyYW5jZXMgb2YgbGljZW5z ZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsDQogICAgICBvciB0aGUgcmVzdWx0 IG9mIGFuIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5lcmFsIGxpY2Vu c2Ugb3INCiAgICAgIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ugb2Ygc3VjaCBw cm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzDQogICAgICBvciB1 c2VycyBvZiB0aGlzIHNwZWNpZmljYXRpb24gY2FuIGJlIG9idGFpbmVkIGZy b20gdGhlIElFVEYNCiAgICAgIFNlY3JldGFyaWF0Lg0KDQogICAgICBUaGUg SUVURiBoYXMgYmVlbiBub3RpZmllZCBvZiBpbnRlbGxlY3R1YWwgcHJvcGVy dHkgcmlnaHRzIGNsYWltZWQNCiAgICAgIGluIHJlZ2FyZCB0byBzb21lIG9y IGFsbCBvZiB0aGUgc3BlY2lmaWNhdGlvbiBjb250YWluZWQgaW4gdGhpcw0K ICAgICAgZG9jdW1lbnQuICBGb3IgbW9yZSBpbmZvcm1hdGlvbiBjb25zdWx0 IHRoZSBvbmxpbmUgbGlzdCBvZiBjbGFpbWVkDQogICAgICByaWdodHMuDQoN CiAgIDkuIEFkZGl0aW9uYWwgSW5mb3JtYXRpb24NCg0KICAgICAgVGhlIGN1 cnJlbnQgZG9jdW1lbnQgZWRpdG9yIGlzOiBEYXJyZW4uTW9mZmF0QFN1bi5D T00uICBDb21tZW50cw0KICAgICAgb24gdGhpcyBpbnRlcm5ldCBkcmFmdCBz aG91bGQgYmUgc2VudCB0byB0aGUgSUVURiBTRUNTSCB3b3JraW5nDQogICAg ICBncm91cCwgZGV0YWlscyBhdDogaHR0cDovL2lldGYub3JnL2h0bWwuY2hh cnRlcnMvc2Vjc2gtDQogICAgICBjaGFydGVyLmh0bWwNCg0KUmVmZXJlbmNl cw0KDQogICAgICBbUkZDMTc2Nl0gICAgICAgQWx2ZXN0cmFuZCwgSC4sICJU YWdzIGZvciB0aGUgSWRlbnRpZmljYXRpb24gb2YNCiAgICAgICAgICAgICAg ICAgICAgICBMYW5ndWFnZXMiLCBSRkMgMTc2NiwgTWFyY2ggMTk5NS4NCg0K ICAgICAgW1JGQzIyNzldICAgICAgIFllcmdlYXUsIEYuLCAiVVRGLTgsIGEg dHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mDQogICAgICAgICAgICAgICAgICAg ICAgSVNPIDEwNjQ2IiwgUkZDIDIyNzksIEphbnVhcnkgMTk5OC4NCg0KICAg ICAgW1NTSC1BUkNIXSAgICAgIFlsb25lbiwgVC4sICJTU0ggUHJvdG9jb2wg QXJjaGl0ZWN0dXJlIiwgSS1EDQogICAgICAgICAgICAgICAgICAgICAgZHJh ZnQtaWV0Zi1hcmNoaXRlY3R1cmUtMTQudHh0LCBKdWx5IDIwMDMuDQoNCiAg ICAgIFtTU0gtVFJBTlNdICAgICBZbG9uZW4sIFQuLCAiU1NIIFRyYW5zcG9y dCBMYXllciBQcm90b2NvbCIsIEktRA0KICAgICAgICAgICAgICAgICAgICAg IGRyYWZ0LWlldGYtdHJhbnNwb3J0LTE2LnR4dCwgSnVseSAyMDAzLg0KDQog ICAgICBbU1NILVVTRVJBVVRIXSAgWWxvbmVuLCBULiwgIlNTSCBBdXRoZW50 aWNhdGlvbiBQcm90b2NvbCIsIEktRA0KICAgICAgICAgICAgICAgICAgICAg IGRyYWZ0LWlldGYtdXNlcmF1dGgtMTcudHh0LCBKdWx5IDIwMDMuDQoNCiAg ICAgIFtTU0gtQ09OTkVDVF0gICBZbG9uZW4sIFQuLCAiU1NIIENvbm5lY3Rp b24gUHJvdG9jb2wiLCBJLUQgZHJhZnQtDQogICAgICAgICAgICAgICAgICAg ICAgaWV0Zi1jb25uZWN0LTE3LnR4dCwgSnVseSAyMDAzLg0KDQogICAgICBb U1NILU5VTUJFUlNdICAgTGVodGluZW4sIFMuIGFuZCBELiBNb2ZmYXQsICJT U0ggUHJvdG9jb2wgQXNzaWduZWQNCiAgICAgICAgICAgICAgICAgICAgICBO dW1iZXJzIiwgSS1EIGRyYWZ0LWlldGYtc2Vjc2gtYXNzaWduZWRudW1iZXJz LQ0KICAgICAgICAgICAgICAgICAgICAgIDAzLnR4dCwgSnVseSAyMDAzLg0K DQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgICBFeHBpcmVzIE1hcmNo IDIsIDIwMDMgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQpJbnRlcm5l dC1EcmFmdCAgICAgICAgIFNTSCBBdXRoZW50aWNhdGlvbiBQcm90b2NvbCAg ICAgICAgU2VwdGVtYmVyIDIwMDINCg0KDQpBdXRob3JzJyBBZGRyZXNzZXMN Cg0KICAgVGF0dSBZbG9uZW4NCiAgIFNTSCBDb21tdW5pY2F0aW9ucyBTZWN1 cml0eSBDb3JwDQogICBGcmVkcmlraW5rYXR1IDQyDQogICBIRUxTSU5LSSAg RklOLTAwMTAwDQogICBGaW5sYW5kDQoNCiAgIEVNYWlsOiB5bG9Ac3NoLmNv bQ0KDQoNCiAgIFRlcm8gS2l2aW5lbg0KICAgU1NIIENvbW11bmljYXRpb25z IFNlY3VyaXR5IENvcnANCiAgIEZyZWRyaWtpbmthdHUgNDINCiAgIEhFTFNJ TktJICBGSU4tMDAxMDANCiAgIEZpbmxhbmQNCg0KICAgRU1haWw6IGtpdmlu ZW5Ac3NoLmNvbQ0KDQoNCiAgIE1hcmtrdS1KdWhhbmkgTy4gU2FhcmluZW4N CiAgIFVuaXZlcnNpdHkgb2YgSnl2YXNreWxhDQoNCg0KICAgVGltbyBKLiBS aW5uZQ0KICAgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5IENvcnANCiAg IEZyZWRyaWtpbmthdHUgNDINCiAgIEhFTFNJTktJICBGSU4tMDAxMDANCiAg IEZpbmxhbmQNCg0KICAgRU1haWw6IHRyaUBzc2guY29tDQoNCg0KICAgU2Ft aSBMZWh0aW5lbg0KICAgU1NIIENvbW11bmljYXRpb25zIFNlY3VyaXR5IENv cnANCiAgIEZyZWRyaWtpbmthdHUgNDINCiAgIEhFTFNJTktJICBGSU4tMDAx MDANCiAgIEZpbmxhbmQNCg0KICAgRU1haWw6IHNqbEBzc2guY29tDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KWWxvbmVuLCBldC4gYWwuICAgICAgICAgICBF eHBpcmVzIE1hcmNoIDIsIDIwMDMgICAgICAgICAgICAgICAgW1BhZ2UgMTRd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgIFNTSCBBdXRoZW50aWNhdGlv biBQcm90b2NvbCAgICAgICAgU2VwdGVtYmVyIDIwMDINCg0KDQpGdWxsIENv cHlyaWdodCBTdGF0ZW1lbnQNCg0KICAgICAgQ29weXJpZ2h0IChDKSBUaGUg SW50ZXJuZXQgU29jaWV0eSAoMjAwMikuICBBbGwgUmlnaHRzIFJlc2VydmVk Lg0KDQogICAgICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2Yg aXQgbWF5IGJlIGNvcGllZCBhbmQgZnVybmlzaGVkDQogICAgICB0byBvdGhl cnMsIGFuZCBkZXJpdmF0aXZlIHdvcmtzIHRoYXQgY29tbWVudCBvbiBvciBv dGhlcndpc2UNCiAgICAgIGV4cGxhaW4gaXQgb3IgYXNzaXN0IGluIGl0cyBp bXBsZW1lbnRhdGlvbiBtYXkgYmUgcHJlcGFyZWQsDQogICAgICBjb3BpZWQs IHB1Ymxpc2hlZCBhbmQgZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBh cnQsIHdpdGhvdXQNCiAgICAgIHJlc3RyaWN0aW9uIG9mIGFueSBraW5kLCBw cm92aWRlZCB0aGF0IHRoZSBhYm92ZSBjb3B5cmlnaHQgbm90aWNlDQogICAg ICBhbmQgdGhpcyBwYXJhZ3JhcGggYXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNo IGNvcGllcyBhbmQgZGVyaXZhdGl2ZQ0KICAgICAgd29ya3MuICBIb3dldmVy LCB0aGlzIGRvY3VtZW50IGl0c2VsZiBtYXkgbm90IGJlIG1vZGlmaWVkIGlu IGFueQ0KICAgICAgd2F5LCBzdWNoIGFzIGJ5IHJlbW92aW5nIHRoZSBjb3B5 cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlDQogICAgICBJbnRl cm5ldCBTb2NpZXR5IG9yIG90aGVyIEludGVybmV0IG9yZ2FuaXphdGlvbnMs IGV4Y2VwdCBhcyBuZWVkZWQNCiAgICAgIGZvciB0aGUgcHVycG9zZSBvZiBk ZXZlbG9waW5nIEludGVybmV0IHN0YW5kYXJkcyBpbiB3aGljaCBjYXNlIHRo ZQ0KICAgICAgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBkZWZpbmVkIGlu IHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMNCiAgICAgIHByb2Nlc3MgbXVzdCBi ZSBmb2xsb3dlZCwgb3IgYXMgcmVxdWlyZWQgdG8gdHJhbnNsYXRlIGl0IGlu dG8NCiAgICAgIGxhbmd1YWdlcyBvdGhlciB0aGFuIEVuZ2xpc2guDQoNCiAg ICAgIFRoZSBsaW1pdGVkIHBlcm1pc3Npb25zIGdyYW50ZWQgYWJvdmUgYXJl IHBlcnBldHVhbCBhbmQgd2lsbCBub3QNCiAgICAgIGJlIHJldm9rZWQgYnkg dGhlIEludGVybmV0IFNvY2lldHkgb3IgaXRzIHN1Y2Nlc3NvcnMgb3IgYXNz aWducy4NCg0KICAgICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBoZXJlaW4gaXMgcHJvdmlkZWQgb24NCiAgICAgIGFu ICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBJTlRFUk5FVCBTT0NJRVRZIEFORCBU SEUgSU5URVJORVQNCiAgICAgIEVOR0lORUVSSU5HIFRBU0sgRk9SQ0UgRElT Q0xBSU1TIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SDQogICAgICBJTVBM SUVELCBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5U WSBUSEFUIFRIRSBVU0UgT0YNCiAgICAgIFRIRSBJTkZPUk1BVElPTiBIRVJF SU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElF RA0KICAgICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1IgRklU TkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCkFja25vd2xlZGdl bWVudA0KDQogICAgICBGdW5kaW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5j dGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkgdGhlDQogICAgICBJbnRl cm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQpZbG9uZW4sIGV0LiBhbC4gICAgICAgICAgIEV4cGlyZXMgTWFy Y2ggMiwgMjAwMyAgICAgICAgICAgICAgICBbUGFnZSAxNV0NCgwNCg== ---559023410-1483920592-1058246303=:895-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 17:03:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04963 for ; Tue, 15 Jul 2003 17:03:37 -0400 (EDT) Received: (qmail 11279 invoked by uid 605); 15 Jul 2003 21:03:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11272 invoked from network); 15 Jul 2003 21:03:37 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 15 Jul 2003 21:03:37 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6FL3biR025522 for ; Tue, 15 Jul 2003 15:03:37 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FL3atK013056 for ; Tue, 15 Jul 2003 17:03:36 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FL3a8Q002777 for ; Tue, 15 Jul 2003 17:03:36 -0400 (EDT) Message-Id: <200307152103.h6FL3a8Q002777@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Secure Shell WG: Issue Tracking "Last Call" Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jul 2003 17:03:36 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Several working groups have experimented with issue tracking systems to attempt to better keep track of needed document changes. There are at least three out there that have been reportedly used successfully for this purpose. Bugzilla RT (http://rt.psg.com/) Roundup (http://roundup.sourceforge.com) I'm currently leaning towards RT because I know the maintainer and because several IETFers have volunteered to host it for IETF working groups. If anyone has any substantive opinions on the subject, please speak up soon, as I'd like to get this rolling within the next month or so. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 17:25:31 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05622 for ; Tue, 15 Jul 2003 17:25:29 -0400 (EDT) Received: (qmail 22833 invoked by uid 605); 15 Jul 2003 21:25:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22826 invoked from network); 15 Jul 2003 21:25:31 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 15 Jul 2003 21:25:31 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6FLPPtI023251; Tue, 15 Jul 2003 14:25:25 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FLPO27024974; Tue, 15 Jul 2003 17:25:24 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FLPO8Q002856; Tue, 15 Jul 2003 17:25:24 -0400 (EDT) Message-Id: <200307152125.h6FLPO8Q002856@thunk.east.sun.com> From: Bill Sommerfeld To: tkohno@cs.ucsd.edu cc: ietf-ssh@NetBSD.org Subject: wg chair comments on draft-ietf-secsh-newmodes-00.txt Reply-to: sommerfeld@sun.com Date: Tue, 15 Jul 2003 17:25:24 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Two editorial comments: First, as is the current preference of the IESG, references should be split into normative and non-normative sections. It appears that of the current references, - AES,RFC2119,RFC2144,SCHNEIER,SERPENT,SSH-*,TWOFISH are normative, as they define things necessary to implement the new modes (ciphers, mostly). - DAI,KRAWCZYK,BKN,BN are informative as they provide background/rationale only. Second (as a minor nit), the page headers say "Month, Year" rather than the month and year of publication... Comments for the WG as a whole: Other than that, the document looks nearly ready to go. I'd like to encourage participants in this WG to review this document as I'm inclined to issue a WG Last Call as soon as these above nits are corrected. In particular, I'd like to hear opinions from the WG about the requirement level of each listed algorithm (see section 4 of the document). Aer we listing too many? Should any be required? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 17:35:54 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05848 for ; Tue, 15 Jul 2003 17:35:53 -0400 (EDT) Received: (qmail 29659 invoked by uid 605); 15 Jul 2003 21:35:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29649 invoked from network); 15 Jul 2003 21:35:54 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 15 Jul 2003 21:35:54 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6FLZstI000047 for ; Tue, 15 Jul 2003 14:35:54 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FLZs27027171 for ; Tue, 15 Jul 2003 17:35:54 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FLZr8Q002928 for ; Tue, 15 Jul 2003 17:35:53 -0400 (EDT) Message-Id: <200307152135.h6FLZr8Q002928@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: WG Last Call on draft-ietf-secsh-auth-kbdinteract-05.txt Reply-to: sommerfeld@sun.com Date: Tue, 15 Jul 2003 17:35:53 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list the -05 draft changed relatively little from the -04 draft; the main difference is the addition of a security considerations section. So, I'd like to start a new WG Last Call on Generic Message Exchange Authentication For SSH draft-ietf-secsh-auth-kbdinteract-05.txt .. for publication as a Proposed Standard RFC; the Last Call period ends on 7/29/2003. If possible, be sure to review the new Security Considerations section for completeness. Please send comments on this document to this mailing list. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 17:42:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06053 for ; Tue, 15 Jul 2003 17:42:13 -0400 (EDT) Received: (qmail 3292 invoked by uid 605); 15 Jul 2003 21:42:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3284 invoked from network); 15 Jul 2003 21:42:15 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 15 Jul 2003 21:42:15 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6FLgEiR018346; Tue, 15 Jul 2003 15:42:14 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FLgD27028467; Tue, 15 Jul 2003 17:42:13 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FLgD8Q002978; Tue, 15 Jul 2003 17:42:13 -0400 (EDT) Message-Id: <200307152142.h6FLgD8Q002978@thunk.east.sun.com> From: Bill Sommerfeld To: markus@openbsd.org cc: ietf-ssh@NetBSD.org Subject: One last nit on draft-ietf-secsh-dh-group-exchange-03.txt Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jul 2003 17:42:13 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list One editorial comment: Please revise the document to split the current "Bibliography" section into "Normative References" and "Informative References". It appears that 1,2,3 are informative and 4,5,6 are normative. To the WG: I believe this document has been through WG Last Call a couple times with only insignificant comments. If anyone disagrees, please speak up and I'll re-run a formal WGLC. Otherwise, the document should head down the pipeline once the above nit is fixed. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 17:47:01 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06184 for ; Tue, 15 Jul 2003 17:47:00 -0400 (EDT) Received: (qmail 5914 invoked by uid 605); 15 Jul 2003 21:47:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5907 invoked from network); 15 Jul 2003 21:46:59 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 Jul 2003 21:46:59 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FLkwpi018773 for ; Tue, 15 Jul 2003 14:46:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FLkw27029451 for ; Tue, 15 Jul 2003 17:46:58 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FLkw8Q003017 for ; Tue, 15 Jul 2003 17:46:58 -0400 (EDT) Message-Id: <200307152146.h6FLkw8Q003017@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: WG Last Call on draft-ietf-secsh-gsskeyex-06.txt Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jul 2003 17:46:58 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The active document editor has informed me that he believes that this document is done. So, I'm starting a two week Working Group Last Call on : GSSAPI Authentication and Key Exchange for the Secure Shell Protocol draft-ietf-secsh-gsskeyex-06 This Last Call period expires on 7/29/2003. Please send comments on this document to this list. [one nit: the section 11 title is apparently missing the word "since"] From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 17:50:59 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06371 for ; Tue, 15 Jul 2003 17:50:59 -0400 (EDT) Received: (qmail 8568 invoked by uid 605); 15 Jul 2003 21:51:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8560 invoked from network); 15 Jul 2003 21:51:00 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 Jul 2003 21:51:00 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FLoxpi021207; Tue, 15 Jul 2003 14:50:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FLox27000155; Tue, 15 Jul 2003 17:50:59 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FLox8Q003055; Tue, 15 Jul 2003 17:50:59 -0400 (EDT) Message-Id: <200307152150.h6FLox8Q003055@thunk.east.sun.com> From: Bill Sommerfeld To: markus@openbsd.org cc: ietf-ssh@NetBSD.org Subject: WG chair nits on draft-ietf-secsh-fingerprint-01.txt Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jul 2003 17:50:59 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list (Yes, this is getting repetitive) 1) Please split references into normative and non-normative. Actualyl, looks like all three are Normative. 2) there is no security considerations section in the document. Please fix this so I can send it to Working Group Last Call. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 18:06:00 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07045 for ; Tue, 15 Jul 2003 18:05:59 -0400 (EDT) Received: (qmail 15690 invoked by uid 605); 15 Jul 2003 22:06:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15683 invoked from network); 15 Jul 2003 22:06:00 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 Jul 2003 22:06:00 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FM5rpi029909; Tue, 15 Jul 2003 15:05:53 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FM5qtK025554; Tue, 15 Jul 2003 18:05:52 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FM5p8Q003128; Tue, 15 Jul 2003 18:05:52 -0400 (EDT) Message-Id: <200307152205.h6FM5p8Q003128@thunk.east.sun.com> From: Bill Sommerfeld To: galb-list@vandyke.com, remaker@cisco.com cc: ietf-ssh@NetBSD.org Subject: wg chair comments on draft-ietf-secsh-break-00.txt Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jul 2003 18:05:51 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list 1) missing security considerations section. 2) need references split (normative/non-normative) other comments: 3) security considerations should mention that BREAK often provides an out-of-band signal giving access to a debugger or boot ROM and that therefore support for this facility should be controllable by the administrator of the receiving end. 4) an implementation not directly connected to a serial line may instead choose to interpret BREAK in an implementation-defined manner consistent with the general use of BREAK as an attention/interrupt signal; for instance, a service processor could use some other out-of-band facility to get the attention of a system it manages. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 18:25:54 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08794 for ; Tue, 15 Jul 2003 18:25:53 -0400 (EDT) Received: (qmail 25875 invoked by uid 605); 15 Jul 2003 22:25:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25868 invoked from network); 15 Jul 2003 22:25:54 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 Jul 2003 22:25:54 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FMPrRi012683; Tue, 15 Jul 2003 16:25:53 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FMPqtK029010; Tue, 15 Jul 2003 18:25:52 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FMPq8Q003265; Tue, 15 Jul 2003 18:25:52 -0400 (EDT) Message-Id: <200307152225.h6FMPq8Q003265@thunk.east.sun.com> From: Bill Sommerfeld To: sjl@ssh.com CC: ietf-ssh@NetBSD.org Subject: WG Chair comments on draft-ietf-secsh-agent-01.txt Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jul 2003 18:25:52 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Two comments: 1) "split" references (there's only one and it's normative) 2) security considerations section doesn't mention the case where you do an ssh-add into a forwarded agent connection. While this exchange is protected via encryption, it does involve casually moving a long-term public keypair over the net to a remote system, which should raise a few eyebrows.. It is not clear to me what we should do about this. Either we should: a) suggest that implementations detect and warn about this case, or b) redesign the protocol so that SSH_AGENT_PRIVATE_KEY_OP requests flow towards the node with the key rather than having all keys and requests flow to the "root" agent. Any comments from the rest of the WG? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 18:34:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09134 for ; Tue, 15 Jul 2003 18:34:21 -0400 (EDT) Received: (qmail 794 invoked by uid 605); 15 Jul 2003 22:34:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 787 invoked from network); 15 Jul 2003 22:34:22 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 Jul 2003 22:34:22 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FMYMpi016602; Tue, 15 Jul 2003 15:34:22 -0700 (PDT) Received: from islay (vpn-129-150-18-246.SFBay.Sun.COM [129.150.18.246]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6FMYLtf399995; Tue, 15 Jul 2003 15:34:21 -0700 (PDT) Date: Tue, 15 Jul 2003 15:34:44 -0700 (PDT) From: Darren J Moffat To: Bill Sommerfeld cc: sjl@ssh.com, Subject: Re: WG Chair comments on draft-ietf-secsh-agent-01.txt In-Reply-To: <200307152225.h6FMPq8Q003265@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 15 Jul 2003, Bill Sommerfeld wrote: > Two comments: > > 1) "split" references (there's only one and it's normative) > > 2) security considerations section doesn't mention the case where you > do an ssh-add into a forwarded agent connection. While this > exchange is protected via encryption, it does involve casually > moving a long-term public keypair over the net to a remote system, > which should raise a few eyebrows.. > > It is not clear to me what we should do about this. Either we should: > > a) suggest that implementations detect and warn about this case, > > or > > b) redesign the protocol so that SSH_AGENT_PRIVATE_KEY_OP requests > flow towards the node with the key rather than having all keys and > requests flow to the "root" agent. Or maybe both, if it can be migrated do so and the implementation SHOULD warn. In fact if the key is actually in an HSM it may not be possible to migrate the actual key to the "root" agent anyway so we might actually want to forward the request to the "owning" agent in some cases. However I could be convinced the practical aspects of having access to an HSM (like a smartcard) on the remote machine are such that this maybe unlikely and thus we don't need to complicate the protocol. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 15 18:37:03 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09216 for ; Tue, 15 Jul 2003 18:37:02 -0400 (EDT) Received: (qmail 2275 invoked by uid 605); 15 Jul 2003 22:37:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2268 invoked from network); 15 Jul 2003 22:37:04 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 15 Jul 2003 22:37:04 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6FMb3pi018162; Tue, 15 Jul 2003 15:37:04 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6FMb3tK001107; Tue, 15 Jul 2003 18:37:03 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6FMb38Q003327; Tue, 15 Jul 2003 18:37:03 -0400 (EDT) Message-Id: <200307152237.h6FMb38Q003327@thunk.east.sun.com> From: Bill Sommerfeld To: galb-list@vandyke.com Cc: ietf-ssh@NetBSD.org Subject: WG chair comments on draft-ietf-secsh-filexfer-04.txt Reply-to: sommerfeld@sun.com Date: Tue, 15 Jul 2003 18:37:03 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list #include "usual-draft-nits.h" 1) Security considerations section looks OK but could probably use some more meat (though I can't thnk of anything else at the moment). 2) section 11 will need to be replaced by the IESG-approved vague "there may be IPR issues here" text; see http://www.ietf.org/IESG/Section10.txt or the core drafts for the appropriate wording to use. 3) Needs references split; looks like 2,5-8 and maybe 4 are normative; others are informative. A question for the WG as a whole: assuming these issues are resolved, is there any reason that this shouldn't go to WG Last Call? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 03:33:11 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18607 for ; Wed, 16 Jul 2003 03:33:10 -0400 (EDT) Received: (qmail 11781 invoked by uid 605); 16 Jul 2003 07:33:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11774 invoked from network); 16 Jul 2003 07:33:08 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.145.201) by mail.netbsd.org with SMTP; 16 Jul 2003 07:33:08 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa07233; 16 Jul 2003 9:32 CEST Date: Wed, 16 Jul 2003 09:32:24 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: "David M. Williams" cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: I-D ACTION:draft-ietf-secsh-gsskeyex-06.txt In-Reply-To: <3EF2199F.7000902@lanl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 19 Jun 2003, David M. Williams wrote: > does anyone know where I can get the nroff version of this draft?? I > have edits I'd like to propose to the group and find nroff easier to > work with. The draft source is in XML form, not nroff. If you happen to have an AFS client lying around, you can find it in /afs/cs.cmu.edu/project/systems-jhutz/Documents/internet-drafts/draft-ietf-secsh-gsskeyex.xml Otherwise, let me know and I'll email you a copy. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 03:59:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19910 for ; Wed, 16 Jul 2003 03:59:28 -0400 (EDT) Received: (qmail 25787 invoked by uid 605); 16 Jul 2003 07:59:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25780 invoked from network); 16 Jul 2003 07:59:28 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.145.201) by mail.netbsd.org with SMTP; 16 Jul 2003 07:59:28 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa07307; 16 Jul 2003 9:58 CEST Date: Wed, 16 Jul 2003 09:58:53 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" cc: Nicolas Williams , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) 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 Wed, 9 Jul 2003, Joel N. Weber II wrote: > > > If you send the last message in a key exchange sequence, wait to see > > > if SSH_MSG_NEWKEYS comes. If it does, your peer accepted what you > > > sent in that last message, and you can send SSH_MSG_NEWKEYS too. > > > (This avoids having only one side use keys from a key exchange: you > > > get either both or neither, which simplifies the session identifier > > > question a bit.) > > > > If the client got an error from the peer then it knows that the > > SSH_MSG_NEWKEYS won't come and so it can just try again immediately. > > True. > > The case I was thinking of, though, is the case where the client > decides it doesn't trust the certificate presented by the server, But this case is simple to handle -- you disconnect and try again. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:02:34 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20081 for ; Wed, 16 Jul 2003 04:02:33 -0400 (EDT) Received: (qmail 27737 invoked by uid 605); 16 Jul 2003 08:02:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27729 invoked from network); 16 Jul 2003 08:02:33 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.145.201) by mail.netbsd.org with SMTP; 16 Jul 2003 08:02:33 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa07329; 16 Jul 2003 10:02 CEST Date: Wed, 16 Jul 2003 10:02:19 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: draft-ietf-secsh-gsskeyex-06.txt security considerations In-Reply-To: <20030714184059.A3998@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 Mon, 14 Jul 2003, Nicolas Williams wrote: > On Mon, Jul 14, 2003 at 11:52:52AM -0400, Joel N. Weber II wrote: > > And it seems somewhat asymetrical that security considerations talks > > about the required properties of a GSSAPI mechanism used for key > > exchange, but says nothing about user authentication. I believe the document specifies the minimum properties required for GSS-API contexts in both keyex and userauth. As Nico points out, there are fewer requirements in the userauth case, because there are no non-context tokens exchanged. > Perhaps the fact that and reasons why GSS-API replay and out-of-sequence > detection are not needed at all here and why GSS-API mutual > authentication and per-message integrity services are not needed in the > userauth case ought to be stated. The document has just gone into last call. I anticipate that there will be one more cycle to address comments raised during last call and improve the security considerations section; if so, I'll try to address this issue more clearly. But IMNSHO it's not worth a cycle for this alone. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:19:01 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA20510 for ; Wed, 16 Jul 2003 04:19:00 -0400 (EDT) Received: (qmail 7867 invoked by uid 605); 16 Jul 2003 08:19:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7860 invoked from network); 16 Jul 2003 08:19:00 -0000 Received: from liandra.pc.cs.cmu.edu.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.145.201) by mail.netbsd.org with SMTP; 16 Jul 2003 08:19:00 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa07394; 16 Jul 2003 10:18 CEST Date: Wed, 16 Jul 2003 10:18:37 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 1 Jul 2003, Joel N. Weber II wrote: > Looking at the January 2002 mailing list archive, it becomes clear > that while the public key types defined in the transport draft have > this encoding: > > string certificate or public key format identifier > byte[n] key/certificate data > > there is no requirement that public key types defined elsewhere will > have that encoding. Perhaps the gsskeyex draft should explicitly say > that SSH_MSG_KEXGSS_HOSTKEY only works with ssh-dss and ssh-rsa keys, > or that it only works with types that start out with the type > identifier as a string. Hm.. My interpretation of the description of public key algorithms in section 4.6 of the transport draft is that the encoding described above applies to _all_ public key types, not just the ones defined in that document. In particular, the section you quoted contains general information describing the nature of public key algorithms and key and certificate formats. The descriptions of specific algorithms defined in that document occur further down, and while they do describe key formats including the specific value of the format identifier to be used, this duplication is consistent with usage in these documents. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:43:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21337 for ; Wed, 16 Jul 2003 04:43:22 -0400 (EDT) Received: (qmail 24258 invoked by uid 605); 16 Jul 2003 08:42:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24207 invoked from network); 16 Jul 2003 08:42:51 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 16 Jul 2003 08:42:51 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6G8gotI009950; Wed, 16 Jul 2003 01:42:50 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6G8go27022001; Wed, 16 Jul 2003 04:42:50 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6G8gn8Q005261; Wed, 16 Jul 2003 04:42:49 -0400 (EDT) Message-Id: <200307160842.h6G8gn8Q005261@thunk.east.sun.com> From: Bill Sommerfeld To: galb-list@vandyke.com cc: ietf-ssh@NetBSD.org Subject: WG chair nits on draft-ietf-secsh-publickeyfile-03.txt Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 04:42:49 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Oops, missed this one: #include needs security considerations section needs "reference split" (all look normative). Also, document is older than its expire-by date. Please fix these and I think it's done. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:45:57 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21411 for ; Wed, 16 Jul 2003 04:45:56 -0400 (EDT) Received: (qmail 26405 invoked by uid 605); 16 Jul 2003 08:45:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26398 invoked from network); 16 Jul 2003 08:45:57 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 16 Jul 2003 08:45:57 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6G8jtRi014003; Wed, 16 Jul 2003 02:45:56 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6G8jt27022361; Wed, 16 Jul 2003 04:45:55 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6G8jt8Q005284; Wed, 16 Jul 2003 04:45:55 -0400 (EDT) Message-Id: <200307160845.h6G8jt8Q005284@thunk.east.sun.com> From: Bill Sommerfeld To: "Brent McClure" cc: ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted In-Reply-To: Your message of "Tue, 08 Jul 2003 14:16:32 MDT." <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 04:45:54 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-subsystem-01.txt > > The public-key subsystem is a mechanism that allows authenticated clients > to upload/manage their public keys through an implementation-independent > interface. > > In the past, we've felt that there has been some interest in pursuing > this draft as a working group document. > > I'd be happy to hear whatever feedback you have on what steps might help > move the document in that direction. I'd like to hear feedback from the rest of the WG as to whether this is of interest as a WG item. [I haven't heard a whole lot one way or the other on this and while it appears to be in scope for the WG, I'd like to see some actual enthusiasm for it as well..] - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:47:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21485 for ; Wed, 16 Jul 2003 04:47:55 -0400 (EDT) Received: (qmail 27497 invoked by uid 605); 16 Jul 2003 08:47:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27490 invoked from network); 16 Jul 2003 08:47:56 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 16 Jul 2003 08:47:56 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19chx0-00034H-00; Wed, 16 Jul 2003 09:47:50 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <200307152225.h6FMPq8Q003265@thunk.east.sun.com> Subject: Re: WG Chair comments on draft-ietf-secsh-agent-01.txt Message-Id: Date: Wed, 16 Jul 2003 09:47:50 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld wrote: > 2) security considerations section doesn't mention the case where you > do an ssh-add into a forwarded agent connection. While this > exchange is protected via encryption, it does involve casually > moving a long-term public keypair over the net to a remote system, > which should raise a few eyebrows.. Hmm. I tend to see it the other way round. In the designed usage model, the real agent is running on your _local_ system, which is usually the only one you trust with your private keys. If you do an ssh-add from a remote system, the potential problem is not the transfer of the key to your trusted local machine: it's the fact that the remote system somewhere on the Internet which you're transferring the key _from_ had access to both the key file and the passphrase. Or, if you're concerned about attacks on the network connection between them, then the damage is probably already done once you've typed the passphrase through your SSH connection. I'm tempted to suggest that if you _must_ store your private key remotely, then the only sensible mode of use is to transfer it _encrypted_ to your local agent and have that prompt for the passphrase. But that's getting back to my pet extension feature :-) > Any comments from the rest of the WG? I posted several comments on the agent draft on 28th April, which are still in the list archives. The only response I got was from Damien Miller supporting one of my suggestions. If anyone is actually collecting comments, please don't overlook those. Cheers, Simon -- Simon Tatham These are my opinions. There are many like them but these ones are mine. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:51:24 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21583 for ; Wed, 16 Jul 2003 04:51:23 -0400 (EDT) Received: (qmail 2108 invoked by uid 605); 16 Jul 2003 08:51:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2101 invoked from network); 16 Jul 2003 08:51:23 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 16 Jul 2003 08:51:23 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19ci0Q-0003nr-00; Wed, 16 Jul 2003 09:51:22 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <200307160845.h6G8jt8Q005284@thunk.east.sun.com> Subject: Re: Publickey subsystem draft posted Message-Id: Date: Wed, 16 Jul 2003 09:51:22 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld wrote: >> The public-key subsystem is a mechanism that allows authenticated clients >> to upload/manage their public keys through an implementation-independent >> interface. > > I'd like to hear feedback from the rest of the WG as to whether this > is of interest as a WG item. I quite like the idea in principle; I get a fair amount of mail from people who can't figure out how to set up public-key authentication, and I can't imagine that the variety of implementations all doing it in different ways can possibly be helping that. A standard protocol for setting up the server would mean users wouldn't need to bounce back and forth between the client and server documentation, but could simply follow one set of instructions. I haven't looked at the details yet, though. Cheers, Simon -- Simon Tatham "A defensive weapon is one with my finger on the trigger. An offensive weapon is one with yours." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:52:25 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21631 for ; Wed, 16 Jul 2003 04:52:25 -0400 (EDT) Received: (qmail 3221 invoked by uid 605); 16 Jul 2003 08:52:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3214 invoked from network); 16 Jul 2003 08:52:25 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 16 Jul 2003 08:52:25 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6G8qPtI014646; Wed, 16 Jul 2003 01:52:25 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6G8qOtK011548; Wed, 16 Jul 2003 04:52:24 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6G8qO8Q005343; Wed, 16 Jul 2003 04:52:24 -0400 (EDT) Message-Id: <200307160852.h6G8qO8Q005343@thunk.east.sun.com> From: Bill Sommerfeld To: Simon Tatham cc: ietf-ssh@NetBSD.org Subject: Re: WG Chair comments on draft-ietf-secsh-agent-01.txt In-Reply-To: Your message of "Wed, 16 Jul 2003 09:47:50 BST." Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 04:52:24 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Hmm. I tend to see it the other way round. In the designed usage > model, the real agent is running on your _local_ system, which is > usually the only one you trust with your private keys. well, I was assuming that there may be multiple keys with different roles involved; host A may be trusted with key A, host B may be trusted with key B, but neither is trusted with both.. You may trust host A enough to use it temporarily to get access to host B but not want it to get a copy of key B.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:56:48 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21751 for ; Wed, 16 Jul 2003 04:56:47 -0400 (EDT) Received: (qmail 8019 invoked by uid 605); 16 Jul 2003 08:56:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8007 invoked from network); 16 Jul 2003 08:56:47 -0000 Received: from unknown (HELO konishi-polis.mit.edu) (81.160.157.184) by mail.netbsd.org with SMTP; 16 Jul 2003 08:56:47 -0000 Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id 3ECEA151D60; Wed, 16 Jul 2003 04:56:45 -0400 (EDT) To: ietf-ssh@NetBSD.org mail-copies-to: never Subject: draft-ietf-secsh-gss-keyex and null host keys Message-Id: <20030716085645.3ECEA151D60@konishi-polis.mit.edu> Date: Wed, 16 Jul 2003 04:56:45 -0400 (EDT) From: hartmans@mit.edu (Sam Hartman) Sender: ietf-ssh-owner@NetBSD.org Precedence: list One desire in writing the GSSAPI draft was to allow sites to optionally deploy GSS without any host keys specific to ssh. It was our belief that the mechanism introduced inht,in the draft to allow gssapi key exchange to transport a host key and thus to allow hosts to easily rekey met this need. At least one integrator has chosen to select encrypted telnet as a technology instead of ssh because our support for null host keys in GSSAPI was weak. After looking more closely at the situation I believe that we can and should improve our support for this configuration. First, I propose that the GSSAPI draft fold in draft-weber-secsh-pkalg-none-00. The none key type should be combined with the null host key type already in the GSSAPI draft. The intent would be that you would use the null key type with GSSAPI key exchange if you had no host key for the initial setup. If later, you find that you cannot perform GSSAPI key exchange because you do not have credentials, or gss_init_sec_context failed for some other reason, you can engage in some other key exchange with the null host key tipe. This exchange would be integrity protected by the existing channel, so the fact that you would effectively be doing anonymous DH is acceptable. Second, I believe we should add text to the GSSAPI draft proposing two possible ways of handling the host key transmitted by the GSSAPI key exchange. 1) We clarify that environments may update their ssh keys much more frequently if they typically use GSSAPI auth, and that user interfaces should take this into account when noting that GSSAPI key exchange has proposed a host key that would update a host key the client already knows about. In particular, strong warnings about man in the middle attacks normally presented when a host key has changed are probably not appropriate if the host key change is authenticated by GSSAPI. Second we should say that implementations SHOULD store any host key sent via GSSAPI for the duration of the session so it can be used for rekeing, even if the key was not stored for long-term use. --Sam From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 04:59:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21872 for ; Wed, 16 Jul 2003 04:59:37 -0400 (EDT) Received: (qmail 9227 invoked by uid 605); 16 Jul 2003 08:59:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9220 invoked from network); 16 Jul 2003 08:59:38 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 16 Jul 2003 08:59:38 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6G8xbpi018886; Wed, 16 Jul 2003 01:59:38 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6G8xbtK012367; Wed, 16 Jul 2003 04:59:37 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6G8xb8Q005426; Wed, 16 Jul 2003 04:59:37 -0400 (EDT) Message-Id: <200307160859.h6G8xb8Q005426@thunk.east.sun.com> From: Bill Sommerfeld To: Russ Housley , "Steven M. Bellovin" cc: ietf-ssh@NetBSD.org Subject: Secure Shell: WG Meeting Summary Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 04:59:37 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Summary of IETF57 Secure Shell WG meeting. The actual meeting was short, mostly largely of document status updates. Attendance was very light. There was brief discussion of open issues with several of the documents. One document is now in the IESG's hands: draft-ietf-secsh-dns-04.txt (SSH key fingerprints in DNS). The core draft update to resolve IESG issues missed publication deadline for this meeting, but editing is now done and the documents should reappear shortly. This will hopefully break the logjam and get the rest of the documents moving. There are few open issues at present -- mostly editorial nits. Starting with this IETF, the AD has requested that I list the actions expected before the next IETF meeting (November 9-14, 2003, in Minneapolis). Expected within next month: [responsible party] Creation of issue tracking database for the WG. [chair] core drafts reissued with revised sec-cons [moffat] draft-ietf-secsh-dh-group-exchange-04.txt [provos/friedl] reissued with nit fixed [provos/friedl] to AD for IETF-wide Last Call [chair] core drafts back to IESG review. [chair] Completion of WG last call period on draft-ietf-secsh-gsskeyex-06.txt [jhutz] draft-ietf-secsh-auth-kbdinteract-05.txt [cusack/forssen] Expected before next IETF: Reissue of extensions drafts with WG chair's nits fixed, and run WG last call: draft-ietf-secsh-break-00.txt [galbraith/remaker] draft-ietf-secsh-filexfer-04.txt [galbraith] draft-ietf-secsh-fingerprint-01.txt [friedl] draft-ietf-secsh-publickeyfile-03.txt [galbraith] Discussion and resolution of technical issues with extension drafts: draft-ietf-secsh-agent-01 [lehtinen] Issue: moving keys to root agent vs. moving requests to keys. draft-ietf-secsh-newmodes-00.txt [kohno] Issue: Tweak/prune algorithm list? Discussion of whether to accept individual submissions as WG items: draft-galb-secsh-publickey-subsystem-01.txt [mcclure] From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 05:28:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22900 for ; Wed, 16 Jul 2003 05:28:49 -0400 (EDT) Received: (qmail 23139 invoked by uid 605); 16 Jul 2003 09:28:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23130 invoked from network); 16 Jul 2003 09:28:50 -0000 Received: from liandra.pc.cs.cmu.edu.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.145.201) by mail.netbsd.org with SMTP; 16 Jul 2003 09:28:50 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa07918; 16 Jul 2003 11:28 CEST Date: Wed, 16 Jul 2003 11:28:05 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: Sam Hartman cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: draft-ietf-secsh-gss-keyex and null host keys In-Reply-To: <20030716085645.3ECEA151D60@konishi-polis.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 16 Jul 2003, Sam Hartman wrote: > First, I propose that the GSSAPI draft fold in > draft-weber-secsh-pkalg-none-00. The none key type should be combined > with the null host key type already in the GSSAPI draft. > Second, I believe we should add text to the GSSAPI draft proposing two > possible ways of handling the host key transmitted by the GSSAPI key > exchange. I agree that both of these changes would be useful. I'm going to wait a little longer for comments, and then I'll produce a new version of the document containing these changes and the other wording improvements we've discussed recently, plus a better securit considerations section. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 05:29:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22945 for ; Wed, 16 Jul 2003 05:29:14 -0400 (EDT) Received: (qmail 23502 invoked by uid 605); 16 Jul 2003 09:29:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23494 invoked from network); 16 Jul 2003 09:29:14 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 16 Jul 2003 09:29:14 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6G9TDRi005868; Wed, 16 Jul 2003 03:29:13 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6G9TCtK015387; Wed, 16 Jul 2003 05:29:12 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6G9TC8Q005958; Wed, 16 Jul 2003 05:29:12 -0400 (EDT) Message-Id: <200307160929.h6G9TC8Q005958@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org cc: steve.hanna@sun.com, Thor Lancelot Simon Subject: "Please Send Draft" Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 05:29:12 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I've recieved a number of promises from people to provide drafts on subjects of interest to the WG. These include: - X.509/pkix Certificate usage with ssh (Steve Hanna) - Line Mode (Thor Simon) - Performance Analysis (Bill Squier). Also, there have been repeated requests for "ssh/scp/sftp" URI/URL types but no volunteer to write a draft. If anyone wants these documents to exist, "please send draft". - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 07:24:08 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25796 for ; Wed, 16 Jul 2003 07:24:08 -0400 (EDT) Received: (qmail 21978 invoked by uid 605); 16 Jul 2003 11:24:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21971 invoked from network); 16 Jul 2003 11:24:07 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 16 Jul 2003 11:24:07 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6GBNxiR015424; Wed, 16 Jul 2003 05:24:03 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GBNx27008809; Wed, 16 Jul 2003 07:23:59 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6GBNw8Q006340; Wed, 16 Jul 2003 07:23:59 -0400 (EDT) Message-Id: <200307161123.h6GBNw8Q006340@thunk.east.sun.com> From: Bill Sommerfeld To: Jack Lloyd cc: ietf-ssh@NetBSD.org Subject: Re: preliminary version of counter mode draft In-Reply-To: Your message of "Fri, 21 Mar 2003 13:52:13 EST." Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 07:23:58 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list [responding to 4-month-old mail] > I'm curious why all of these were here: > > > twofish128-ctr RECOMMENDED Twofish in SDCTR mode, > > with 128-bit key > > twofish192-ctr OPTIONAL Twofish with 192-bit key > > twofish256-ctr OPTIONAL Twofish with 256-bit key > > serpent128-ctr RECOMMENDED Serpent in SDCTR mode, with > > with 128-bit key > > serpent192-ctr OPTIONAL Serpent with 192-bit key > > serpent256-ctr OPTIONAL Serpent with 256-bit key > > Serpent and Twofish treat 128, 192 and 256 bit keys basically the > same anyway (unlike AES, where all three different versions might be > useful). Obviously there is no reason _not to have them all (besides > a fairly small amount of extra work for implementors), but it seems > pointless, given that serpent256-ctr and twofish256-ctr would do the > job of all six of these just fine. I didn't see a response to this.. I don't (wg chair hat off) think it makes a lot of sense to any of the include AES runners-up at anything above OPTIONAL but I don't feel particully strongly about it either way. Regarding the key lengths, though, there are enough regulatory/policy issues out there (for instance, additional paperwork required for export of sw or hw doing key sizes over 128 bits) that we're better off specifying and negotiating all believed-to-be-strong key lengths separately -- if we were to only do a 256-bit version, it might cause certain vendors to omit the algorithm entirely. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 07:37:39 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26335 for ; Wed, 16 Jul 2003 07:37:37 -0400 (EDT) Received: (qmail 28979 invoked by uid 605); 16 Jul 2003 11:37:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28971 invoked from network); 16 Jul 2003 11:37:36 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 16 Jul 2003 11:37:36 -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 h6GBXlOc006247; Wed, 16 Jul 2003 13:33:47 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 66EA12D041; Wed, 16 Jul 2003 13:34:23 +0200 (CEST) Date: Wed, 16 Jul 2003 13:34:23 +0200 From: Markus Friedl To: ietf-ssh@NetBSD.org Cc: Bill Sommerfeld , Jack Lloyd Subject: Re: preliminary version of counter mode draft Message-ID: <20030716113423.GA25765@folly> References: <200307161123.h6GBNw8Q006340@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307161123.h6GBNw8Q006340@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 16, 2003 at 07:23:58AM -0400, Bill Sommerfeld wrote: > I don't (wg chair hat off) think it makes a lot of sense to any of the > include AES runners-up at anything above OPTIONAL but I don't feel > particully strongly about it either way. I think there's no reason to have them at all. They shouldn't even be in the core drafts.... From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 07:38:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26388 for ; Wed, 16 Jul 2003 07:38:20 -0400 (EDT) Received: (qmail 29683 invoked by uid 605); 16 Jul 2003 11:38:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29672 invoked from network); 16 Jul 2003 11:38:20 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 16 Jul 2003 11:38:20 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GBcEpi004484; Wed, 16 Jul 2003 04:38:14 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GBcE27010377; Wed, 16 Jul 2003 07:38:14 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6GBcD8Q006460; Wed, 16 Jul 2003 07:38:14 -0400 (EDT) Message-Id: <200307161138.h6GBcD8Q006460@thunk.east.sun.com> From: Bill Sommerfeld To: Jack Lloyd Cc: ietf-ssh@NetBSD.org Subject: Re: preliminary version of counter mode draft In-Reply-To: Your message of "Wed, 16 Jul 2003 07:23:58 EDT." <200307161123.h6GBNw8Q006340@thunk.east.sun.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 07:38:13 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list wow, I'm word order having problems with today: > I don't (wg chair hat off) think it makes a lot of sense to any of the > include AES runners-up at anything above OPTIONAL but I don't feel > particully strongly about it either way. I meant, of course: I don't (wg chair hat off) think it makes a lot of sense to include any of the AES runners-up at anything above OPTIONAL but I don't feel particularly strongly about it either way. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 08:41:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27917 for ; Wed, 16 Jul 2003 08:41:37 -0400 (EDT) Received: (qmail 2263 invoked by uid 605); 16 Jul 2003 12:41:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2251 invoked from network); 16 Jul 2003 12:41:28 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 16 Jul 2003 12:41:28 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6GCfRiR020196 for ; Wed, 16 Jul 2003 06:41:27 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GCfR27019290 for ; Wed, 16 Jul 2003 08:41:27 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6GCfR8Q006880 for ; Wed, 16 Jul 2003 08:41:27 -0400 (EDT) Message-Id: <200307161241.h6GCfR8Q006880@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: draft-ietf-secsh-architecture-14.txt preview. Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 08:41:27 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list As promised earlier during the meeting, here's the missing draft, rescued from the bogus-message-trap. - Bill Network Working Group T. Ylonen Internet-Draft T. Kivinen Expires: January 12, 2004 SSH Communications Security Corp M. Saarinen University of Jyvaskyla T. Rinne S. Lehtinen SSH Communications Security Corp July 14, 2003 SSH Protocol Architecture draft-ietf-secsh-architecture-14.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH Ylonen, et. al. Expires January 12, 2004 [Page 1] Internet-Draft SSH Protocol Architecture July 2003 protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Specification of Requirements . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Host Keys . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 Policy Issues . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Security Properties . . . . . . . . . . . . . . . . . . . . 7 3.5 Packet Size and Overhead . . . . . . . . . . . . . . . . . . 7 3.6 Localization and Character Set Support . . . . . . . . . . . 8 4. Data Type Representations Used in the SSH Protocols . . . . 9 5. Algorithm Naming . . . . . . . . . . . . . . . . . . . . . . 11 6. Message Numbers . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . 13 8.1 Pseudo-Random Number Generation . . . . . . . . . . . . . . 13 8.2 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . 14 8.2.2 Data Integrity . . . . . . . . . . . . . . . . . . . . . . . 17 8.2.3 Replay . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.2.4 Man-in-the-middle . . . . . . . . . . . . . . . . . . . . . 18 8.2.5 Denial-of-service . . . . . . . . . . . . . . . . . . . . . 20 8.2.6 Covert Channels . . . . . . . . . . . . . . . . . . . . . . 21 8.2.7 Forward Secrecy . . . . . . . . . . . . . . . . . . . . . . 21 8.3 Authentication Protocol . . . . . . . . . . . . . . . . . . 21 8.3.1 Weak Transport . . . . . . . . . . . . . . . . . . . . . . . 22 8.3.2 Debug messages . . . . . . . . . . . . . . . . . . . . . . . 22 8.3.3 Local security policy . . . . . . . . . . . . . . . . . . . 23 8.3.4 Public key authentication . . . . . . . . . . . . . . . . . 23 8.3.5 Password authentication . . . . . . . . . . . . . . . . . . 24 8.3.6 Host based authentication . . . . . . . . . . . . . . . . . 24 8.4 Connection protocol . . . . . . . . . . . . . . . . . . . . 24 8.4.1 End point security . . . . . . . . . . . . . . . . . . . . . 24 8.4.2 Proxy forwarding . . . . . . . . . . . . . . . . . . . . . . 24 8.4.3 X11 forwarding . . . . . . . . . . . . . . . . . . . . . . . 25 9. Intellectual Property . . . . . . . . . . . . . . . . . . . 25 10. Additional Information . . . . . . . . . . . . . . . . . . . 26 References . . . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 Ylonen, et. al. Expires January 12, 2004 [Page 2] Internet-Draft SSH Protocol Architecture July 2003 Full Copyright Statement . . . . . . . . . . . . . . . . . . 31 Ylonen, et. al. Expires January 12, 2004 [Page 3] Internet-Draft SSH Protocol Architecture July 2003 1. Introduction SSH is a protocol for secure remote login and other secure network services over an insecure network. It consists of three major components: o The Transport Layer Protocol [SSH-TRANS] provides server authentication, confidentiality, and integrity. It may optionally also provide compression. The transport layer will typically be run over a TCP/IP connection, but might also be used on top of any other reliable data stream. o The User Authentication Protocol [SSH-USERAUTH] authenticates the client-side user to the server. It runs over the transport layer protocol. o The Connection Protocol [SSH-CONNECT] multiplexes the encrypted tunnel into several logical channels. It runs over the user authentication protocol. The client sends a service request once a secure transport layer connection has been established. A second service request is sent after user authentication is complete. This allows new protocols to be defined and coexist with the protocols listed above. The connection protocol provides channels that can be used for a wide range of purposes. Standard methods are provided for setting up secure interactive shell sessions and for forwarding ("tunneling") arbitrary TCP/IP ports and X11 connections. 2. Specification of Requirements All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. They are to be interpreted as described in [RFC- 2119]. 3. Architecture 3.1 Host Keys Each server host SHOULD have a host key. Hosts MAY have multiple host keys using multiple different algorithms. Multiple hosts MAY share the same host key. If a host has keys at all, it MUST have at least one key using each REQUIRED public key algorithm (currently DSS [FIPS-186]). The server host key is used during key exchange to verify that the client is really talking to the correct server. For this to be possible, the client must have a priori knowledge of the server's Ylonen, et. al. Expires January 12, 2004 [Page 4] Internet-Draft SSH Protocol Architecture July 2003 public host key. 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. The protocol provides the option that the server name - host key association is not checked when connecting to the host for the first time. This allows communication without prior communication of host keys or certification. The connection still provides protection against passive listening; however, it becomes vulnerable to active man-in-the-middle attacks. Implementations SHOULD NOT normally allow such connections by default, as they pose a potential security problem. However, as there is no widely deployed key infrastructure available on the Internet yet, this option makes the protocol much more usable during the transition time until such an infrastructure emerges, while still providing a much higher level of security than that offered by older solutions (e.g. telnet [RFC-854] and rlogin [RFC-1282]). Implementations SHOULD try to make the best effort to check host keys. An example of a possible strategy is to only accept a host key without checking the first time a host is connected, save the key in a local database, and compare against that key on all future connections to that host. Implementations MAY provide additional methods for verifying the correctness of host keys, e.g. a hexadecimal fingerprint derived from the SHA-1 hash of the public key. Such fingerprints can easily be verified by using telephone or other external communication channels. All implementations SHOULD provide an option to not accept host Ylonen, et. al. Expires January 12, 2004 [Page 5] Internet-Draft SSH Protocol Architecture July 2003 keys that cannot be verified. We believe that ease of use is critical to end-user acceptance of security solutions, and no improvement in security is gained if the new solutions are not used. Thus, providing the option not to check the server host key is believed to improve the overall security of the Internet, even though it reduces the security of the protocol in configurations where it is allowed. 3.2 Extensibility We believe that the protocol will evolve over time, and some organizations will want to use their own encryption, authentication and/or key exchange methods. Central registration of all extensions is cumbersome, especially for experimental or classified features. On the other hand, having no central registration leads to conflicts in method identifiers, making interoperability difficult. We have chosen to identify algorithms, methods, formats, and extension protocols with textual names that are of a specific format. DNS names are used to create local namespaces where experimental or classified extensions can be defined without fear of conflicts with other implementations. One design goal has been to keep the base protocol as simple as possible, and to require as few algorithms as possible. However, all implementations MUST support a minimal set of algorithms to ensure interoperability (this does not imply that the local policy on all hosts would necessary allow these algorithms). The mandatory algorithms are specified in the relevant protocol documents. Additional algorithms, methods, formats, and extension protocols can be defined in separate drafts. See Section Algorithm Naming (Section 5) for more information. 3.3 Policy Issues The protocol allows full negotiation of encryption, integrity, key exchange, compression, and public key algorithms and formats. Encryption, integrity, public key, and compression algorithms can be different for each direction. The following policy issues SHOULD be addressed in the configuration mechanisms of each implementation: o Encryption, integrity, and compression algorithms, separately for each direction. The policy MUST specify which is the Ylonen, et. al. Expires January 12, 2004 [Page 6] Internet-Draft SSH Protocol Architecture July 2003 preferred algorithm (e.g. the first algorithm listed in each category). o Public key algorithms and key exchange method to be used for host authentication. The existence of trusted host keys for different public key algorithms also affects this choice. o The authentication methods that are to be required by the server for each user. The server's policy MAY require multiple authentication for some or all users. The required algorithms MAY depend on the location where the user is trying to log in from. o The operations that the user is allowed to perform using the connection protocol. Some issues are related to security; for example, the policy SHOULD NOT allow the server to start sessions or run commands on the client machine, and MUST NOT allow connections to the authentication agent unless forwarding such connections has been requested. Other issues, such as which TCP/IP ports can be forwarded and by whom, are clearly issues of local policy. Many of these issues may involve traversing or bypassing firewalls, and are interrelated with the local security policy. 3.4 Security Properties The primary goal of the SSH protocol is improved security on the Internet. It attempts to do this in a way that is easy to deploy, even at the cost of absolute security. o All encryption, integrity, and public key algorithms used are well-known, well-established algorithms. o All algorithms are used with cryptographically sound key sizes that are believed to provide protection against even the strongest cryptanalytic attacks for decades. o All algorithms are negotiated, and in case some algorithm is broken, it is easy to switch to some other algorithm without modifying the base protocol. Specific concessions were made to make wide-spread fast deployment easier. The particular case where this comes up is verifying that the server host key really belongs to the desired host; the protocol allows the verification to be left out (but this is NOT RECOMMENDED). This is believed to significantly improve usability in the short term, until widespread Internet public key infrastructures emerge. 3.5 Packet Size and Overhead Some readers will worry about the increase in packet size due to new headers, padding, and MAC. The minimum packet size is in the order of 28 bytes (depending on negotiated algorithms). The Ylonen, et. al. Expires January 12, 2004 [Page 7] Internet-Draft SSH Protocol Architecture July 2003 increase is negligible for large packets, but very significant for one-byte packets (telnet-type sessions). There are, however, several factors that make this a non-issue in almost all cases: o The minimum size of a TCP/IP header is 32 bytes. Thus, the increase is actually from 33 to 51 bytes (roughly). o The minimum size of the data field of an Ethernet packet is 46 bytes [RFC-894]. Thus, the increase is no more than 5 bytes. When Ethernet headers are considered, the increase is less than 10 percent. o The total fraction of telnet-type data in the Internet is negligible, even with increased packet sizes. The only environment where the packet size increase is likely to have a significant effect is PPP [RFC-1134] over slow modem lines (PPP compresses the TCP/IP headers, emphasizing the increase in packet size). However, with modern modems, the time needed to transfer is in the order of 2 milliseconds, which is a lot faster than people can type. There are also issues related to the maximum packet size. To minimize delays in screen updates, one does not want excessively large packets for interactive sessions. The maximum packet size is negotiated separately for each channel. 3.6 Localization and Character Set Support For the most part, the SSH protocols do not directly pass text that would be displayed to the user. However, there are some places where such data might be passed. When applicable, the character set for the data MUST be explicitly specified. In most places, ISO 10646 with UTF-8 encoding is used [RFC-2279]. When applicable, a field is also provided for a language tag [RFC- 1766]. One big issue is the character set of the interactive session. There is no clear solution, as different applications may display data in different formats. Different types of terminal emulation may also be employed in the client, and the character set to be used is effectively determined by the terminal emulation. Thus, no place is provided for directly specifying the character set or encoding for terminal session data. However, the terminal emulation type (e.g. "vt100") is transmitted to the remote site, and it implicitly specifies the character set and encoding. Applications typically use the terminal type to determine what character set they use, or the character set is determined using some external means. The terminal emulation may also allow configuring the default character set. In any case, the character set for the terminal session is considered primarily a client Ylonen, et. al. Expires January 12, 2004 [Page 8] Internet-Draft SSH Protocol Architecture July 2003 local issue. Internal names used to identify algorithms or protocols are normally never displayed to users, and must be in US-ASCII. The client and server user names are inherently constrained by what the server is prepared to accept. They might, however, occasionally be displayed in logs, reports, etc. They MUST be encoded using ISO 10646 UTF-8, but other encodings may be required in some cases. It is up to the server to decide how to map user names to accepted user names. Straight bit-wise binary comparison is RECOMMENDED. For localization purposes, the protocol attempts to minimize the number of textual messages transmitted. When present, such messages typically relate to errors, debugging information, or some externally configured data. For data that is normally displayed, it SHOULD be possible to fetch a localized message instead of the transmitted message by using a numerical code. The remaining messages SHOULD be configurable. 4. Data Type Representations Used in the SSH Protocols byte A byte represents an arbitrary 8-bit value (octet) [RFC-1700]. Fixed length data is sometimes represented as an array of bytes, written byte[n], where n is the number of bytes in the array. boolean A boolean value is stored as a single byte. The value 0 represents FALSE, and the value 1 represents TRUE. All non- zero values MUST be interpreted as TRUE; however, applications MUST NOT store values other than 0 and 1. uint32 Represents a 32-bit unsigned integer. Stored as four bytes in the order of decreasing significance (network byte order). For example, the value 699921578 (0x29b7f4aa) is stored as 29 b7 f4 aa. uint64 Represents a 64-bit unsigned integer. Stored as eight bytes in the order of decreasing significance (network byte order). Ylonen, et. al. Expires January 12, 2004 [Page 9] Internet-Draft SSH Protocol Architecture July 2003 string Arbitrary length binary string. Strings are allowed to contain arbitrary binary data, including null characters and 8-bit characters. They are stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string. Terminating null characters are not used. Strings are also used to store text. In that case, US-ASCII is used for internal names, and ISO-10646 UTF-8 for text that might be displayed to the user. The terminating null character SHOULD NOT normally be stored in the string. For example, the US-ASCII string "testing" is represented as 00 00 00 07 t e s t i n g. The UTF8 mapping does not alter the encoding of US-ASCII characters. mpint Represents multiple precision integers in two's complement format, stored as a string, 8 bits per byte, MSB first. Negative numbers have the value 1 as the most significant bit of the first byte of the data partition. If the most significant bit would be set for a positive number, the number MUST be preceded by a zero byte. Unnecessary leading bytes with the value 0 or 255 MUST NOT be included. The value zero MUST be stored as a string with zero bytes of data. By convention, a number that is used in modular computations in Z_n SHOULD be represented in the range 0 <= x < n. Examples: value (hex) representation (hex) --------------------------------------------------------------- 0 00 00 00 00 9a378f9b2e332a7 00 00 00 08 09 a3 78 f9 b2 e3 32 a7 80 00 00 00 02 00 80 -1234 00 00 00 02 ed cc -deadbeef 00 00 00 05 ff 21 52 41 11 name-list A string containing a comma separated list of names. A name list is represented as a uint32 containing its length (number of bytes that follow) followed by a comma-separated list of Ylonen, et. al. Expires January 12, 2004 [Page 10] Internet-Draft SSH Protocol Architecture July 2003 zero or more names. A name MUST be non-zero length, and it MUST NOT contain a comma (','). Context may impose additional restrictions on the names; for example, the names in a list may have to be valid algorithm identifier (see Algorithm Naming below), or [RFC-1766] language tags. The order of the names in a list may or may not be significant, also depending on the context where the list is is used. Terminating NUL characters are not used, neither for the individual names, nor for the list as a whole. Examples: value representation (hex) --------------------------------------- (), the empty list 00 00 00 00 ("zlib") 00 00 00 04 7a 6c 69 62 ("zlib", "none") 00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65 5. Algorithm Naming The SSH protocols refer to particular hash, encryption, integrity, compression, and key exchange algorithms or protocols by names. There are some standard algorithms that all implementations MUST support. There are also algorithms that are defined in the protocol specification but are OPTIONAL. Furthermore, it is expected that some organizations will want to use their own algorithms. In this protocol, all algorithm identifiers MUST be printable US- ASCII non-empty strings no longer than 64 characters. Names MUST be case-sensitive. There are two formats for algorithm names: o Names that do not contain an at-sign (@) are reserved to be assigned by IETF consensus (RFCs). Examples include `3des- cbc', `sha-1', `hmac-sha1', and `zlib' (the quotes are not part of the name). Names of this format MUST NOT be used without first registering them. Registered names MUST NOT contain an at-sign (@) or a comma (,). o Anyone can define additional algorithms by using names in the format name@domainname, e.g. "ourcipher-cbc@ssh.com". The format of the part preceding the at sign is not specified; it MUST consist of US-ASCII characters except at-sign and comma. The part following the at-sign MUST be a valid fully qualified internet domain name [RFC-1034] controlled by the person or organization defining the name. It is up to each domain how it Ylonen, et. al. Expires January 12, 2004 [Page 11] Internet-Draft SSH Protocol Architecture July 2003 manages its local namespace. 6. Message Numbers SSH packets have message numbers in the range 1 to 255. These numbers have been allocated as follows: Transport layer protocol: 1 to 19 Transport layer generic (e.g. disconnect, ignore, debug, etc.) 20 to 29 Algorithm negotiation 30 to 49 Key exchange method specific (numbers can be reused for different authentication methods) User authentication protocol: 50 to 59 User authentication generic 60 to 79 User authentication method specific (numbers can be reused for different authentication methods) Connection protocol: 80 to 89 Connection protocol generic 90 to 127 Channel related messages Reserved for client protocols: 128 to 191 Reserved Local extensions: 192 to 255 Local extensions 7. IANA Considerations Allocation of the following types of names in the SSH protocols is assigned by IETF consensus: o encryption algorithm names, o MAC algorithm names, o public key algorithm names (public key algorithm also implies encoding and signature/encryption capability), o key exchange method names, and o protocol (service) names. Ylonen, et. al. Expires January 12, 2004 [Page 12] Internet-Draft SSH Protocol Architecture July 2003 These names MUST be printable US-ASCII strings, and MUST NOT contain the characters at-sign ('@'), comma (','), or whitespace or control characters (ASCII codes 32 or less). Names are case- sensitive, and MUST NOT be longer than 64 characters. Names with the at-sign ('@') in them are allocated by the owner of DNS name after the at-sign (hierarchical allocation in [RFC- 2343]), otherwise the same restrictions as above. Each category of names listed above has a separate namespace. However, using the same name in multiple categories SHOULD be avoided to minimize confusion. Message numbers (see Section Message Numbers (Section 6)) in the range of 0..191 should be allocated via IETF consensus; message numbers in the 192..255 range (the "Local extensions" set) are reserved for private use. 8. Security Considerations In order to make the entire body of Security Considerations more accessible, Security Considerations for the transport, authentication, and connection documents have been gathered here. The transport protocol [1] provides a confidential channel over an insecure network. It performs server host authentication, key exchange, encryption, and integrity protection. It also derives a unique session id that may be used by higher-level protocols. The authentication protocol [2] provides a suite of mechanisms which can be used to authenticate the client user to the server. Individual mechanisms specified in the in authentication protocol use the session id provided by the transport protocol and/or depend on the security and integrity guarantees of the transport protocol. The connection protocol [3] specifies a mechanism to multiplex multiple streams [channels] of data over the confidential and authenticated transport. It also specifies channels for accessing an interactive shell, for 'proxy-forwarding' various external protocols over the secure transport (including arbitrary TCP/IP protocols), and for accessing secure 'subsystems' on the server host. 8.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 Ylonen, et. al. Expires January 12, 2004 [Page 13] Internet-Draft SSH Protocol Architecture July 2003 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. 8.2 Transport 8.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 published as a US Federal Information Processing Standards [FIPS-197] and the cryptographic community as being acceptable for this purpose as well has accepted AES. As always, implementors and users should check current literature to ensure that no recent vulnerabilities have been found in ciphers used within products. Implementors should also check to see which ciphers are considered to be relatively stronger than others and should recommend their use to users over relatively weaker ciphers. It would be considered good form for an implementation to politely and unobtrusively notify a user that a stronger cipher is available and should be used when a weaker one is actively chosen. The "none" cipher is provided for debugging and SHOULD NOT be used except for that purpose. It's cryptographic properties are sufficiently described in RFC 2410, which will show that its use does not meet the intent of this protocol. The relative merits of these and other ciphers may also be found in current literature. Two references that may provide information on the subject are [SCHNEIER] and Ylonen, et. al. Expires January 12, 2004 [Page 14] Internet-Draft SSH Protocol Architecture July 2003 [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 [ROGAWAY],[DAI],[BELLARE,KOHNO,NAMPREMPRE]) 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 Ylonen, et. al. Expires January 12, 2004 [Page 15] Internet-Draft SSH Protocol Architecture July 2003 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. Ylonen, et. al. Expires January 12, 2004 [Page 16] Internet-Draft SSH Protocol Architecture July 2003 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 8.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. 8.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 Ylonen, et. al. Expires January 12, 2004 [Page 17] Internet-Draft SSH Protocol Architecture July 2003 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. 8.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. Ylonen, et. al. Expires January 12, 2004 [Page 18] Internet-Draft SSH Protocol Architecture July 2003 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 Ylonen, et. al. Expires January 12, 2004 [Page 19] Internet-Draft SSH Protocol Architecture July 2003 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. 8.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 Ylonen, et. al. Expires January 12, 2004 [Page 20] Internet-Draft SSH Protocol Architecture July 2003 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. 8.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. 8.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. 8.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 Ylonen, et. al. Expires January 12, 2004 [Page 21] Internet-Draft SSH Protocol Architecture July 2003 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. 8.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. 8.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. Administrators of host machines should make all attempts to compartmentalize all event notification messages and protect them from unwarranted observation. Developers should be aware of the sensitive nature of some of the normal event messages and debug messages and may want to provide guidance to administrators on ways to keep this information away from unauthorized people. Developers should consider minimizing the amount of sensitive information obtainable by users during the authentication phase in accordance with the local policies. For this reason, it is RECOMMENDED that debug messages be initially disabled at the time Ylonen, et. al. Expires January 12, 2004 [Page 22] Internet-Draft SSH Protocol Architecture July 2003 of deployment and require an active decision by an administrator to allow them to be enabled. It is also RECOMMENDED that a message expressing this concern be presented to the administrator of a system when the action is taken to enable debugging messages. 8.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. 8.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.) Ylonen, et. al. Expires January 12, 2004 [Page 23] Internet-Draft SSH Protocol Architecture July 2003 8.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. 8.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. 8.4 Connection protocol 8.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. 8.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 Ylonen, et. al. Expires January 12, 2004 [Page 24] Internet-Draft SSH Protocol Architecture July 2003 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. 8.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. 9. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described Ylonen, et. al. Expires January 12, 2004 [Page 25] Internet-Draft SSH Protocol Architecture July 2003 in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 10. Additional Information The current document editor is: Darren.Moffat@Sun.COM. Comments on this internet draft should be sent to the IETF SECSH working group, details at: http://ietf.org/html.charters/secsh- charter.html References [FIPS-186] Federal Information Processing Standards Publication, ., "FIPS PUB 186, Digital Signature Standard", May 1994. [FIPS-197] National Institue of Standards and Technology, ., "FIPS 197, Specification for the Advanced Encryption Standard", November 2001. [ANSI T1.523-2001] American National Standards Insitute, Inc., "Telecom Glossary 2000", February 2001. [SCHEIFLER] Scheifler, R., "X Window System : The Complete Reference to Xlib, X Protocol, Icccm, Xlfd, 3rd edition.", Digital Press ISBN 1555580882, Feburary 1992. [RFC0854] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC Ylonen, et. al. Expires January 12, 2004 [Page 26] Internet-Draft SSH Protocol Architecture July 2003 854, May 1983. [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, Apr 1984. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, Nov 1987. [RFC1134] Perkins, D., "Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point- to-Point links", RFC 1134, Nov 1989. [RFC1282] Kantor, B., "BSD Rlogin", RFC 1282, December 1991. [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC1964] Linn, J., "The Kerberos Version 5 GSS- API Mechanism", RFC 1964, June 1996. [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. Ylonen, et. al. Expires January 12, 2004 [Page 27] Internet-Draft SSH Protocol Architecture July 2003 Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [SSH-ARCH] Ylonen, T., "SSH Protocol Architecture", I-D draft-ietf- architecture-14.txt, July 2003. [SSH-TRANS] Ylonen, T., "SSH Transport Layer Protocol", I-D draft-ietf-transport- 16.txt, July 2003. [SSH-USERAUTH] Ylonen, T., "SSH Authentication Protocol", I-D draft-ietf-userauth- 17.txt, July 2003. [SSH-CONNECT] Ylonen, T., "SSH Connection Protocol", I-D draft-ietf-connect-17.txt, July 2003. [SSH-NUMBERS] Lehtinen, S. and D. Moffat, "SSH Protocol Assigned Numbers", I-D draft- ietf-secsh-assignednumbers-03.txt, Ylonen, et. al. Expires January 12, 2004 [Page 28] Internet-Draft SSH Protocol Architecture July 2003 July 2003. [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols algorithms and source in code in C", 1996. [KAUFMAN,PERLMAN,SPECINER] Kaufman, C., Perlman, R. and M. Speciner, "Network Security: PRIVATE Communication in a PUBLIC World", 1995. [CERT] CERT Coordination Center, The., "http://www.cert.org/nav/index_red.html" . [VENEMA] Venema, W., "Murphy's Law and Computer Security", Proceedings of 6th USENIX Security Symposium, San Jose CA http://www.usenix.org/publications/library/proceedings/sec96/venema.html , July 1996. [ROGAWAY] Rogaway, P., "Problems with Proposed IP Cryptography", Unpublished paper http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt , 1996. [DAI] Dai, W., "An attack against SSH2 protocol", Email to the SECSH Working Group ietf-ssh@netbsd.org ftp://ftp.ietf.org/ietf-mail- archive/secsh/2002-02.mail, Feb 2002. [BELLARE,KOHNO,NAMPREMPRE] Bellaire, M., Kohno, T. and C. Namprempre, "Authenticated Encryption in SSH: Fixing the SSH Binary Packet Protocol", , Sept 2002. Authors' Addresses Tatu Ylonen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: ylo@ssh.com Ylonen, et. al. Expires January 12, 2004 [Page 29] Internet-Draft SSH Protocol Architecture July 2003 Tero Kivinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: kivinen@ssh.com Markku-Juhani O. Saarinen University of Jyvaskyla Timo J. Rinne SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: tri@ssh.com Sami Lehtinen SSH Communications Security Corp Fredrikinkatu 42 HELSINKI FIN-00100 Finland EMail: sjl@ssh.com Ylonen, et. al. Expires January 12, 2004 [Page 30] Internet-Draft SSH Protocol Architecture July 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Ylonen, et. al. Expires January 12, 2004 [Page 31] From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 08:59:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28458 for ; Wed, 16 Jul 2003 08:59:37 -0400 (EDT) Received: (qmail 14483 invoked by uid 605); 16 Jul 2003 12:59:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14476 invoked from network); 16 Jul 2003 12:59:36 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 16 Jul 2003 12:59:36 -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 h6GCtnOc010095; Wed, 16 Jul 2003 14:55:49 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 7F2EE2D041; Wed, 16 Jul 2003 14:56:25 +0200 (CEST) Date: Wed, 16 Jul 2003 14:56:25 +0200 From: Markus Friedl To: ietf-ssh@NetBSD.org Cc: Bill Sommerfeld Subject: Re: WG chair nits on draft-ietf-secsh-fingerprint-01.txt Message-ID: <20030716125625.GA11035@folly> References: <200307152150.h6FLox8Q003055@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307152150.h6FLox8Q003055@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 15, 2003 at 05:50:59PM -0400, Bill Sommerfeld wrote: > (Yes, this is getting repetitive) > > 1) Please split references into normative and non-normative. > Actualyl, looks like all three are Normative. > > 2) there is no security considerations section in the document. What do you like to see in the 'Security Considerations' section? INTERNET-DRAFT Markus Friedl draft-ietf-secsh-fingerprint-02.txt The OpenBSD Project Expires: January 2004 July 2003 SSH Fingerprint Format Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document formally documents the fingerprint format in use for verifying public keys from SSH clients and servers. 1. Introduction The security of the SSH protocols relies on the verification of public host keys. Since public keys tend to be very large, it is difficult for a human to verify an entire host key. Even with a PKI in place, it is useful to have a standard for exchanging short fingerprints of public keys. This document formally describes the simple key fingerprint format. Friedl [Page 1] INTERNET-DRAFT July 2003 2. Fingerprint Format The fingerprint of a public key consists of the output of the MD5 message-digest algorithm [RFC-1321]. The input to the algorithm is the public key blob as described in [SSH-TRANS]. The output of the algorithm is presented to the user as a sequence of 16 octets printed as hexadecimal with lowercase letters and separated by colons. For example: "c1:b1:30:29:d7:b8:de:6c:97:77:10:d7:46:41:63:87" 3. Security Considerations XXX 4. References 4.1 Normative References [SSH-TRANS] Ylonen, T., et al: "SSH Transport Layer Protocol", Internet Draft, draft-secsh-transport-15.txt [RFC-1321] R. Rivest: "The MD5 Message-Digest Algorithm", April 1992. 4.2 Informative References [RFC-2026] S. Bradner: "The Internet Standards Process -- Revision 3", October 1996. 5. Author's Address: Markus Friedl markus@openbsd.org Munich, Germany Friedl [Page 2] From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 09:02:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28576 for ; Wed, 16 Jul 2003 09:02:12 -0400 (EDT) Received: (qmail 16276 invoked by uid 605); 16 Jul 2003 13:02:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16268 invoked from network); 16 Jul 2003 13:02:12 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 16 Jul 2003 13:02:12 -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 h6GCwROc010159 for ; Wed, 16 Jul 2003 14:58:27 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id E31FE2D049; Wed, 16 Jul 2003 14:59:02 +0200 (CEST) Date: Wed, 16 Jul 2003 14:59:01 +0200 From: Markus Friedl To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell: WG Meeting Summary Message-ID: <20030716125901.GB11035@folly> References: <200307160859.h6G8xb8Q005426@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307160859.h6G8xb8Q005426@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list hi, FYI: support for these drafts is included in recent OpenSSH snapshots, if you want to test interoperability and other problems... > draft-ietf-secsh-dns-04.txt > [...] > draft-ietf-secsh-newmodes-00.txt -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 09:04:26 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28689 for ; Wed, 16 Jul 2003 09:04:26 -0400 (EDT) Received: (qmail 17700 invoked by uid 605); 16 Jul 2003 13:04:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17693 invoked from network); 16 Jul 2003 13:04:26 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 16 Jul 2003 13:04:26 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6GD4PiR000982; Wed, 16 Jul 2003 07:04:26 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6GD4P27022977; Wed, 16 Jul 2003 09:04:25 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6GD4P8Q007033; Wed, 16 Jul 2003 09:04:25 -0400 (EDT) Message-Id: <200307161304.h6GD4P8Q007033@thunk.east.sun.com> From: Bill Sommerfeld To: Markus Friedl cc: ietf-ssh@NetBSD.org Subject: Re: WG chair nits on draft-ietf-secsh-fingerprint-01.txt In-Reply-To: Your message of "Wed, 16 Jul 2003 14:56:25 +0200." <20030716125625.GA11035@folly> Reply-to: sommerfeld@east.sun.com Date: Wed, 16 Jul 2003 09:04:25 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > What do you like to see in the 'Security Considerations' section? See http://www.ietf.org/internet-drafts/draft-iab-sec-cons-03.txt ("Guidelines for Writing RFC Text on Security Considerations"). for this document, this likely won't require much text. Two points I'd make: - reference security considerations of [SSH-ARCH] and point out that this is a common exchange format to help with the problem. - point out that the 'trusted' copy of the fingerprint must be transmitted by some form of secure channel; how to do that is out of scope. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 09:24:03 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29115 for ; Wed, 16 Jul 2003 09:24:02 -0400 (EDT) Received: (qmail 27650 invoked by uid 605); 16 Jul 2003 13:24:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27640 invoked from network); 16 Jul 2003 13:24:00 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 16 Jul 2003 13:24:00 -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 h6GDNutI026295; Wed, 16 Jul 2003 06:23:56 -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 h6GDNqcm002601; Wed, 16 Jul 2003 07:23:53 -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 h6GDKhQx005386; Wed, 16 Jul 2003 06:20:43 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6GDKhnf005385; Wed, 16 Jul 2003 06:20:43 -0700 (PDT) Date: Wed, 16 Jul 2003 06:20:43 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) Message-ID: <20030716062042.C4862@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 jhutz@cmu.edu on Wed, Jul 16, 2003 at 09:58:53AM +0200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 16, 2003 at 09:58:53AM +0200, Jeffrey Hutzelman wrote: > On Wed, 9 Jul 2003, Joel N. Weber II wrote: > > The case I was thinking of, though, is the case where the client > > decides it doesn't trust the certificate presented by the server, > > But this case is simple to handle -- you disconnect and try again. If keyex was re-triable and the session ID hash was taken over the failed kex messages too (in addition to the other things that go into it) then it would be possible to detect downgrade attacks. Disconnecting after kex failure without the possibility of retrying may leave the user (oh, probably not the average user) wondering if a downgrade attack was not taking place. Of course, all of this assumes that one kex is weaker, or, if not, less desirable, than another. Anyways, we can fix this some other time. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 09:42:37 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29815 for ; Wed, 16 Jul 2003 09:42:36 -0400 (EDT) Received: (qmail 8380 invoked by uid 605); 16 Jul 2003 13:41:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8372 invoked from network); 16 Jul 2003 13:41:41 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 16 Jul 2003 13:41:41 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6GDfctI005261; Wed, 16 Jul 2003 06:41: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 h6GDfbbO002321; Wed, 16 Jul 2003 07:41:38 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6GDcSQx005434; Wed, 16 Jul 2003 06:38:28 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6GDcSFA005433; Wed, 16 Jul 2003 06:38:28 -0700 (PDT) Date: Wed, 16 Jul 2003 06:38:28 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-gsskeyex-06.txt security considerations Message-ID: <20030716063828.G4862@binky.central.sun.com> References: <20030714184059.A3998@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 jhutz@cmu.edu on Wed, Jul 16, 2003 at 10:02:19AM +0200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 16, 2003 at 10:02:19AM +0200, Jeffrey Hutzelman wrote: > On Mon, 14 Jul 2003, Nicolas Williams wrote: > > > On Mon, Jul 14, 2003 at 11:52:52AM -0400, Joel N. Weber II wrote: > > > > And it seems somewhat asymetrical that security considerations talks > > > about the required properties of a GSSAPI mechanism used for key > > > exchange, but says nothing about user authentication. > > I believe the document specifies the minimum properties required for > GSS-API contexts in both keyex and userauth. As Nico points out, there > are fewer requirements in the userauth case, because there are no > non-context tokens exchanged. > > > Perhaps the fact that and reasons why GSS-API replay and out-of-sequence > > detection are not needed at all here and why GSS-API mutual > > authentication and per-message integrity services are not needed in the > > userauth case ought to be stated. > > The document has just gone into last call. I anticipate that there will > be one more cycle to address comments raised during last call and improve > the security considerations section; if so, I'll try to address this issue > more clearly. But IMNSHO it's not worth a cycle for this alone. Agreed. Not having such text is not a failure to describe a real security issue (or interop, for that matter). Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 09:47:34 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29999 for ; Wed, 16 Jul 2003 09:47:34 -0400 (EDT) Received: (qmail 12409 invoked by uid 605); 16 Jul 2003 13:47:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12402 invoked from network); 16 Jul 2003 13:47:34 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 16 Jul 2003 13:47:34 -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 h6GDlXRi011058; Wed, 16 Jul 2003 07:47:33 -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 h6GDlXbO003797; Wed, 16 Jul 2003 07:47:33 -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 h6GDiOQx005447; Wed, 16 Jul 2003 06:44:24 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6GDiNgG005446; Wed, 16 Jul 2003 06:44:23 -0700 (PDT) Date: Wed, 16 Jul 2003 06:44:23 -0700 From: Nicolas Williams To: Bill Sommerfeld Cc: sjl@ssh.com, ietf-ssh@NetBSD.org Subject: Re: WG Chair comments on draft-ietf-secsh-agent-01.txt Message-ID: <20030716064417.A5428@binky.central.sun.com> References: <200307152225.h6FMPq8Q003265@thunk.east.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: <200307152225.h6FMPq8Q003265@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Jul 15, 2003 at 06:25:52PM -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 15, 2003 at 06:25:52PM -0400, Bill Sommerfeld wrote: > Two comments: > > 1) "split" references (there's only one and it's normative) > > 2) security considerations section doesn't mention the case where you > do an ssh-add into a forwarded agent connection. While this > exchange is protected via encryption, it does involve casually > moving a long-term public keypair over the net to a remote system, > which should raise a few eyebrows.. > > It is not clear to me what we should do about this. Either we should: > > a) suggest that implementations detect and warn about this case, > > or > > b) redesign the protocol so that SSH_AGENT_PRIVATE_KEY_OP requests > flow towards the node with the key rather than having all keys and > requests flow to the "root" agent. > > Any comments from the rest of the WG? Perhaps an optional message could be added to indicate that a node has added a key to the [now distributed] agent. Of course, now we'd have bidirectional agent channels, with requests and responses going in either direction. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 11:32:36 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06121 for ; Wed, 16 Jul 2003 11:32:35 -0400 (EDT) Received: (qmail 16792 invoked by uid 605); 16 Jul 2003 15:32:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16784 invoked from network); 16 Jul 2003 15:32:32 -0000 Received: from chiark.greenend.org.uk (193.201.200.170) by mail.netbsd.org with SMTP; 16 Jul 2003 15:32:32 -0000 Received: by chiark.greenend.org.uk (Debian Exim 3.35 #1) with local for ietf-ssh@netbsd.org id 19coGd-0004Do-00; Wed, 16 Jul 2003 16:32:31 +0100 Date: Wed, 16 Jul 2003 16:32:31 +0100 From: Jacob Nevins To: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-assignednumbers-03.txt Message-ID: <20030716153231.GA11552@chiark.greenend.org.uk> Reply-To: ietf-ssh@NetBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list At the risk of reigniting the "des-cbc" discussion... From attachment draft-ietf-secsh-assignednumbers-03.txt: | Abstract | | This document defines the initial state of the IANA assigned | numbers for the SSH protocol as defined in [SSH-ARCH], [SSH- | TRANS], [SSH-CONNECT], [SSH-USERAUTH]. This document does not | define any new protocols or any number ranges not already defined | in the above referenced documents. However, this isn't strictly correct, as section 4.1 "Encryption Algorithm Names" defines "des-cbc", which isn't mentioned in any of the above references: | des-cbc [FIPS-46-3] HISTORIC; See page 4 of [FIPS 46-3] In effect it appears to define a new algorithm by reference to [FIPS-46-3]. The simplest solution might be to amend the Abstract of assignednumbers to add an exception for "des-cbc". However I don't know if this is considered "bad form" for such an IANA-oriented document. (derived from ) From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 15:15:54 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14322 for ; Wed, 16 Jul 2003 15:15:54 -0400 (EDT) Received: (qmail 15201 invoked by uid 605); 16 Jul 2003 19:15:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15193 invoked from network); 16 Jul 2003 19:15:53 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 16 Jul 2003 19:15:53 -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 h6GJFosR020173; Wed, 16 Jul 2003 13:15:50 -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 h6GJFncm013135; Wed, 16 Jul 2003 13:15: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 h6GJCeQx005754; Wed, 16 Jul 2003 12:12:40 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6GJCWpP005753; Wed, 16 Jul 2003 12:12:32 -0700 (PDT) Date: Wed, 16 Jul 2003 12:12:32 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@NetBSD.org Subject: Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) Message-ID: <20030716191228.GA5747@binky.central.sun.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> <20030709225327.GN380@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 09, 2003 at 08:12:52PM -0400, Joel N. Weber II wrote: > The case I was thinking of, though, is the case where the client > decides it doesn't trust the certificate presented by the server, and > that it wants to try another method. For example, a common problem is > that your average web browser doesn't recognize the X.509 CA that > issues certificates for most HTTPS web servers in the mit.edu domain. > And with OpenPGP, everyone has their own set of trust values, and > there's no chance you could ever predict whether a client will trust a > host key without feeding the client the host key and asking whether it > trusts it. > > Since the host key is sent in the last message of the public key key > exchange algorithms, the client doesn't realize that it doesn't trust > the key until key exchange would appear to have finished judging from > the messages being passed back and forth. BTW, this would apply to GSS-API keyex with SPKM as well. I think the problem can be fixed without revving the protocol version, but it wouldn't be pretty (I imagine using a bogus alg name to indicate support for retriable keyex). If has to be pretty then the protocol will have to be revved. Either way the fix will have to wait. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 15:21:36 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14496 for ; Wed, 16 Jul 2003 15:21:35 -0400 (EDT) Received: (qmail 18550 invoked by uid 605); 16 Jul 2003 19:21:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18543 invoked from network); 16 Jul 2003 19:21:35 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 16 Jul 2003 19:21:35 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6GJLYsR024124; Wed, 16 Jul 2003 13:21:34 -0600 (MDT) Received: from islay (vpn-129-150-20-15.SFBay.Sun.COM [129.150.20.15]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6GJLY9k270877; Wed, 16 Jul 2003 12:21:34 -0700 (PDT) Date: Wed, 16 Jul 2003 12:21:56 -0700 (PDT) From: Darren J Moffat To: Bill Sommerfeld cc: Brent McClure , Subject: Re: Publickey subsystem draft posted In-Reply-To: <200307160845.h6G8jt8Q005284@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 16 Jul 2003, Bill Sommerfeld wrote: > > The public-key subsystem is a mechanism that allows authenticated clients > > to upload/manage their public keys through an implementation-independent > > interface. > I'd like to hear feedback from the rest of the WG as to whether this > is of interest as a WG item. [I haven't heard a whole lot one way or > the other on this and while it appears to be in scope for the WG, I'd > like to see some actual enthusiasm for it as well..] I support the concept and I believe that it is appropriate work for this WG. I'll need to spend some time reading the draft again to see if I support this actual proposal or not. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 15:23:27 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14585 for ; Wed, 16 Jul 2003 15:23:25 -0400 (EDT) Received: (qmail 19651 invoked by uid 605); 16 Jul 2003 19:23:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19644 invoked from network); 16 Jul 2003 19:23:25 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 16 Jul 2003 19:23:25 -0000 Received: by xanthine.gratuitous.org with local; Wed, 16 Jul 2003 15:23:24 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: ietf-ssh@NetBSD.org In-reply-to: <20030716191228.GA5747@binky.central.sun.com> (message from Nicolas Williams on Wed, 16 Jul 2003 12:12:32 -0700) Subject: Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> <20030709225327.GN380@binky.central.sun.com> <20030716191228.GA5747@binky.central.sun.com> Message-Id: Date: Wed, 16 Jul 2003 15:23:24 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > BTW, this would apply to GSS-API keyex with SPKM as well. What does SPKM do that GSI and x509v3-sign-rsa/x509v3-sign-dss don't? It's bad enough that we already have lots of potential for two gratuitously incompatible ways to use simple bare Verisign-signed X.509 certificates. (And I think there are implementations of both approaches out there.) If we want to discuss another GSSAPI mechanism that might possibly be worth supporting in the future, SRP might be more interesting to discuss. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 15:40:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14931 for ; Wed, 16 Jul 2003 15:40:05 -0400 (EDT) Received: (qmail 29482 invoked by uid 605); 16 Jul 2003 19:40:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29457 invoked from network); 16 Jul 2003 19:40:05 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 16 Jul 2003 19:40:05 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6GJe565028592; Wed, 16 Jul 2003 12:40:05 -0700 (PDT) Received: from islay (vpn-129-150-20-15.SFBay.Sun.COM [129.150.20.15]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6GJe49k276186; Wed, 16 Jul 2003 12:40:04 -0700 (PDT) Date: Wed, 16 Jul 2003 12:40:27 -0700 (PDT) From: Darren J Moffat To: Brent McClure cc: ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted In-Reply-To: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list In the introduction you say: This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. While I support the intent of this the functionality seems like it would actually be more appropriate for one of the core drafts rather than this one. 3.2 Adding a public key If the client wishes to add a public key, the client sends: string "add" string comment string public-key algorithm name string public-key blob The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. The comment field contains user-specified text about the public key and MAY be empty. I'd like to see text added to say that the server is not supposed to interpret the comment in any way and is NOT required to preserve it for subsequent return in a list command. 3.4 Listing public keys If the client wishes to list the known public keys, the client sends: string "list" The server will respond with zero or more of the following responses: string "publickey" string comment string public-key algorithm name string public-key blob The comment field contains user-specified text about the public key and MAY be empty. Following the last "publickey" response, a status packet MUST be sent. An implementation MAY choose not to support this request. How long is the client supposed to wait for the server to send the status packet to say it is done ? I would have expected the server to send a packed more like this: string "publickey-list" uint32 number of following public keys string comment string public-key algorithm name string public-key blob .... and so on upto uint32 number of keys OR something like string "publickey-list" uint32 number of following public keys then send the publickeys in the packet format you defined in 3.4 Telling the client how many keys are comming would probably be helpful for implementers building a UI to display this info. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 16:11:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15445 for ; Wed, 16 Jul 2003 16:11:09 -0400 (EDT) Received: (qmail 20870 invoked by uid 605); 16 Jul 2003 20:11:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20863 invoked from network); 16 Jul 2003 20:11:10 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 16 Jul 2003 20:11:10 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 6E3533BD04; Wed, 16 Jul 2003 22:11:02 +0200 (MET DST) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 30C506C98B; Wed, 16 Jul 2003 22:11:08 +0200 (MEST) Date: Wed, 16 Jul 2003 22:11:12 +0200 (CEST) From: maf@appgate.com Reply-To: maf@appgate.com Subject: Re: Secure Shell: WG Meeting Summary To: markus@openbsd.org Cc: ietf-ssh@NetBSD.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-Disposition: INLINE Message-Id: <20030716201108.30C506C98B@shala.firedoor.se> Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 16 Jul, Markus Friedl wrote: > hi, FYI: support for these drafts is included in recent OpenSSH > snapshots, if you want to test interoperability and other problems... > >> draft-ietf-secsh-dns-04.txt >> [...] >> draft-ietf-secsh-newmodes-00.txt Newmodes is supported in the latest MindTerm (2.4) as well. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 16:34:35 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16483 for ; Wed, 16 Jul 2003 16:34:34 -0400 (EDT) Received: (qmail 3385 invoked by uid 605); 16 Jul 2003 20:34:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3378 invoked from network); 16 Jul 2003 20:34:34 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 16 Jul 2003 20:34:34 -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 h6GKYV1v019464; Wed, 16 Jul 2003 13:34:31 -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 h6GKYUcm016280; Wed, 16 Jul 2003 14:34:31 -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 h6GKVJQx005776; Wed, 16 Jul 2003 13:31:19 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6GKVJbo005775; Wed, 16 Jul 2003 13:31:19 -0700 (PDT) Date: Wed, 16 Jul 2003 13:31:19 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@NetBSD.org Subject: Re: retrying keyex (was: Re: Why SFTP performance sucks, and how to fix it) Message-ID: <20030716203119.GC5706@binky.central.sun.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> <20030709225327.GN380@binky.central.sun.com> <20030716191228.GA5747@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 16, 2003 at 03:23:24PM -0400, Joel N. Weber II wrote: > > BTW, this would apply to GSS-API keyex with SPKM as well. > > What does SPKM do that GSI and x509v3-sign-rsa/x509v3-sign-dss don't? Nothing. That's the point. By the time that the SPKM initiator (client) finds out what the acceptor's (server's) certificate is the client and server have committed to doing SSHv2 GSS-API kex w/ SPKM and CAN'T fallback on another kex method should the acceptor's cert not be good enough for the client. I was pointing out more scenarios in which the inability to re-try kex could be obnoxious. > If we want to discuss another GSSAPI mechanism that might possibly be > worth supporting in the future, SRP might be more interesting to > discuss. Not in this WG. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 16:56:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17080 for ; Wed, 16 Jul 2003 16:56:17 -0400 (EDT) Received: (qmail 15060 invoked by uid 605); 16 Jul 2003 20:56:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15053 invoked from network); 16 Jul 2003 20:56:18 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 16 Jul 2003 20:56:18 -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 h6GKuGv5017620; Wed, 16 Jul 2003 14:56:16 -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 h6GKuGbO001306; Wed, 16 Jul 2003 14:56:16 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6GKr6Qx005802; Wed, 16 Jul 2003 13:53:07 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6GKr6tP005801; Wed, 16 Jul 2003 15:53:06 -0500 (CDT) Date: Wed, 16 Jul 2003 15:53:06 -0500 From: Nicolas Williams To: "Joel N. Weber II" Cc: ietf-ssh@NetBSD.org Subject: GSS-API SRP mech (was Re: retrying keyex ...) Message-ID: <20030716205306.GD3182@binky.central.sun.com> References: <200307080401.h68412200867@medusa01.cs.auckland.ac.nz> <20030708084607.A18772@binky.central.sun.com> <20030709225327.GN380@binky.central.sun.com> <20030716191228.GA5747@binky.central.sun.com> <20030716203119.GC5706@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030716203119.GC5706@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 16, 2003 at 01:31:19PM -0700, Nicolas Williams wrote: > On Wed, Jul 16, 2003 at 03:23:24PM -0400, Joel N. Weber II wrote: > > If we want to discuss another GSSAPI mechanism that might possibly be > > worth supporting in the future, SRP might be more interesting to > > discuss. > > Not in this WG. I should correct myself here: if you can get the charter of SECSH ammended so it can design a new GSS-API mechanism using SRP, go for it. The CAT WG is not open, so there's no single best forum to discuss new GSS-API mechanisms. If that is what you want then I see some options: - discuss the new mechanism in the old CAT WG mailing list and proceed with an individual I-D - get some WG's charter amended so it can be responsible for the proposed GSS-API mechanism - get a new WG created or have CAT revived I think a number of issues are slowly piling up that ought to lead to the revival of CAT, eventually. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 17:31:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18457 for ; Wed, 16 Jul 2003 17:31:20 -0400 (EDT) Received: (qmail 4570 invoked by uid 605); 16 Jul 2003 21:31:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4563 invoked from network); 16 Jul 2003 21:31:17 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by mail.netbsd.org with SMTP; 16 Jul 2003 21:31:17 -0000 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 16 Jul 2003 14:35:47 -0700 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6GLVEuG015788; Wed, 16 Jul 2003 14:31:15 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.226.159]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Jul 2003 14:35:01 -0700 From: "Joseph Salowey" To: "'Nicolas Williams'" , "'Joel N. Weber II'" Cc: Subject: RE: GSS-API SRP mech (was Re: retrying keyex ...) Date: Wed, 16 Jul 2003 14:31:12 -0700 Message-ID: <01b501c34be1$9541ad20$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <20030716205306.GD3182@binky.central.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-OriginalArrivalTime: 16 Jul 2003 21:35:01.0855 (UTC) FILETIME=[1D0C66F0:01C34BE2] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I believe http://www.ietf.org/internet-drafts/draft-burdis-cat-srp-sasl-08.txt Is an SRP SASL mechanism that also uses GSSAPI framing, perhaps this is enough (I haven't looked at it yet). Joe > -----Original Message----- > From: ietf-ssh-owner@NetBSD.org > [mailto:ietf-ssh-owner@NetBSD.org] On Behalf Of Nicolas Williams > Sent: Wednesday, July 16, 2003 1:53 PM > To: Joel N. Weber II > Cc: ietf-ssh@NetBSD.org > Subject: GSS-API SRP mech (was Re: retrying keyex ...) > > > On Wed, Jul 16, 2003 at 01:31:19PM -0700, Nicolas Williams wrote: > > On Wed, Jul 16, 2003 at 03:23:24PM -0400, Joel N. Weber II wrote: > > > If we want to discuss another GSSAPI mechanism that might > possibly > > > be worth supporting in the future, SRP might be more > interesting to > > > discuss. > > > > Not in this WG. > > I should correct myself here: if you can get the charter of > SECSH ammended so it can design a new GSS-API mechanism using > SRP, go for it. > > The CAT WG is not open, so there's no single best forum to > discuss new GSS-API mechanisms. If that is what you want > then I see some options: > > - discuss the new mechanism in the old CAT WG mailing list > and proceed > with an individual I-D > > - get some WG's charter amended so it can be responsible for the > proposed GSS-API mechanism > > - get a new WG created or have CAT revived > > I think a number of issues are slowly piling up that ought to > lead to the revival of CAT, eventually. > > Cheers, > > Nico > -- > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 18:02:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19543 for ; Wed, 16 Jul 2003 18:02:40 -0400 (EDT) Received: (qmail 19926 invoked by uid 605); 16 Jul 2003 22:02:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19919 invoked from network); 16 Jul 2003 22:02:36 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 16 Jul 2003 22:02:36 -0000 Received: by xanthine.gratuitous.org with local; Wed, 16 Jul 2003 18:02:31 -0400 From: "Joel N. Weber II" To: "Joseph Salowey" CC: "'Nicolas Williams'" , In-reply-to: <01b501c34be1$9541ad20$0200000a@amer.cisco.com> (jsalowey@cisco.com) Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) References: <01b501c34be1$9541ad20$0200000a@amer.cisco.com> Message-Id: Date: Wed, 16 Jul 2003 18:02:31 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I believe > > http://www.ietf.org/internet-drafts/draft-burdis-cat-srp-sasl-08.txt > > Is an SRP SASL mechanism that also uses GSSAPI framing, perhaps this is > enough (I haven't looked at it yet). It appears that that by itself doesn't provide integrity protection, and draft-ietf-secsh-gsskeyex says: The key exchange method described in section 1 of this document depends on the underlying GSSAPI mechanism to provide both mutual authentication and per-message integrity services. If either of these features is not supported by a particular GSSAPI mechanism, or by a particular implementation of a GSSAPI mechanism, then the key exchange is not secure and MUST fail. In theory, you can use that SASL mechanism with an intergrity protection layer. In practice, since it appears that the SASL SRP mechanism basically does the things you want a Secure Shell key exchange to accomplish, it may be better to define a new Secure Shell key exchange algorithm to support SRP. However, this is probably a mostly academic discussion at the moment, due to IPR issues related to SRP. Fortunately, patents do expire eventually. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 18:26:08 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21318 for ; Wed, 16 Jul 2003 18:26:07 -0400 (EDT) Received: (qmail 3481 invoked by uid 605); 16 Jul 2003 22:26:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3463 invoked from network); 16 Jul 2003 22:26:09 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 16 Jul 2003 22:26:09 -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 h6GMPt1v024884; Wed, 16 Jul 2003 15:25:55 -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 h6GMPscm001200; Wed, 16 Jul 2003 16:25:54 -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 h6GMMiQx005908; Wed, 16 Jul 2003 15:22:44 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6GMMiub005907; Wed, 16 Jul 2003 15:22:44 -0700 (PDT) Date: Wed, 16 Jul 2003 15:22:44 -0700 From: Nicolas Williams To: Joseph Salowey Cc: "'Joel N. Weber II'" , ietf-ssh@NetBSD.org Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) Message-ID: <20030716222243.GJ5706@binky.central.sun.com> References: <20030716205306.GD3182@binky.central.sun.com> <01b501c34be1$9541ad20$0200000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01b501c34be1$9541ad20$0200000a@amer.cisco.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 16, 2003 at 02:31:12PM -0700, Joseph Salowey wrote: > I believe > > http://www.ietf.org/internet-drafts/draft-burdis-cat-srp-sasl-08.txt > > Is an SRP SASL mechanism that also uses GSSAPI framing, perhaps this is > enough (I haven't looked at it yet). > > Joe I've just read the relevant portions of that I-D and find it lacking. I have a number of objections, particularly to section 8 where the GSS-API mechanism is defined. This seems really way off-topic for ietf-ssh@netbsd.org; I do not expect to continue this topic here. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 16 18:39:17 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21554 for ; Wed, 16 Jul 2003 18:39:16 -0400 (EDT) Received: (qmail 12332 invoked by uid 605); 16 Jul 2003 22:39:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12322 invoked from network); 16 Jul 2003 22:39:18 -0000 Received: from anchorage.arcot.com (206.14.221.34) by mail.netbsd.org with SMTP; 16 Jul 2003 22:39:18 -0000 Received: from arcot.com (172.16.50.219 [172.16.50.219]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 38JG72PP; Wed, 16 Jul 2003 15:34:42 -0700 Message-ID: <3F15D701.9090508@arcot.com> Date: Wed, 16 Jul 2003 15:51:45 -0700 From: Tom Wu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Joel N. Weber II" CC: Joseph Salowey , "'Nicolas Williams'" , ietf-ssh@NetBSD.org Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) References: <01b501c34be1$9541ad20$0200000a@amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Joel N. Weber II wrote: > > In theory, you can use that SASL mechanism with an intergrity > protection layer. In practice, since it appears that the SASL SRP > mechanism basically does the things you want a Secure Shell key > exchange to accomplish, it may be better to define a new Secure Shell > key exchange algorithm to support SRP. There are implementations of SRP as an SSH key exchange mechanism 'in the wild', and at least one expired I-D documenting them. They can presumably be revived as needed. > However, this is probably a mostly academic discussion at the moment, > due to IPR issues related to SRP. Fortunately, patents do expire > eventually. But SRP has a royalty-free license: http://www.ietf.org/ietf/IPR/WU-SRP. Although there is some concern over third-party IPR, that should not (and has not) prevented movement on standards documents in this space. Ultimately it is up to the marketplace to decide. Tom -- Tom Wu Chief Security Architect Arcot Systems (408) 969-6124 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 03:39:16 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20619 for ; Thu, 17 Jul 2003 03:39:15 -0400 (EDT) Received: (qmail 9140 invoked by uid 605); 17 Jul 2003 07:39:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9133 invoked from network); 17 Jul 2003 07:39:03 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 17 Jul 2003 07:39:03 -0000 Received: from mindrot.org (136.195.20.10.dhcp.netstarnetworks.com [10.20.195.136] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id h6H7g9Q11744; Thu, 17 Jul 2003 17:42:10 +1000 Message-ID: <3F165253.8050208@mindrot.org> Date: Thu, 17 Jul 2003 17:37:55 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: sommerfeld@east.sun.com CC: sjl@ssh.com, ietf-ssh@NetBSD.org Subject: Re: WG Chair comments on draft-ietf-secsh-agent-01.txt References: <200307152225.h6FMPq8Q003265@thunk.east.sun.com> In-Reply-To: <200307152225.h6FMPq8Q003265@thunk.east.sun.com> X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: > Any comments from the rest of the WG? Simon Tatham had some comments on the agent protocol (posted 2003-04-29) which I think are important. I especially support his proposed extension mechanism. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 04:07:55 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22034 for ; Thu, 17 Jul 2003 04:07:54 -0400 (EDT) Received: (qmail 25109 invoked by uid 605); 17 Jul 2003 08:07:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25102 invoked from network); 17 Jul 2003 08:07:54 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 17 Jul 2003 08:07:54 -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 h6H848Oc001590 for ; Thu, 17 Jul 2003 10:04:09 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 189312D041; Thu, 17 Jul 2003 10:04:41 +0200 (CEST) Date: Thu, 17 Jul 2003 10:04:41 +0200 From: Markus Friedl To: ietf-ssh@NetBSD.org Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) Message-ID: <20030717080441.GC626@folly> References: <01b501c34be1$9541ad20$0200000a@amer.cisco.com> <3F15D701.9090508@arcot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F15D701.9090508@arcot.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 16, 2003 at 03:51:45PM -0700, Tom Wu wrote: > But SRP has a royalty-free license: http://www.ietf.org/ietf/IPR/WU-SRP. > Although there is some concern over third-party IPR, that should not > (and has not) prevented movement on standards documents in this space. > Ultimately it is up to the marketplace to decide. Things like this prevent SRP support in OpenSSH, for example. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 04:46:04 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23582 for ; Thu, 17 Jul 2003 04:46:03 -0400 (EDT) Received: (qmail 15803 invoked by uid 605); 17 Jul 2003 08:46:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15796 invoked from network); 17 Jul 2003 08:46:04 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 Jul 2003 08:46:04 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6H8k165015203; Thu, 17 Jul 2003 01:46:02 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H8k027020560; Thu, 17 Jul 2003 04:46:00 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6H8jx8Q011049; Thu, 17 Jul 2003 04:45:59 -0400 (EDT) Message-Id: <200307170845.h6H8jx8Q011049@thunk.east.sun.com> From: Bill Sommerfeld To: Nicolas Williams cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) In-Reply-To: Your message of "Wed, 16 Jul 2003 15:53:06 CDT." <20030716205306.GD3182@binky.central.sun.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 17 Jul 2003 04:45:59 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I should correct myself here: if you can get the charter of SECSH > ammended so it can design a new GSS-API mechanism using SRP, go for it. The current working group chair (me) would very much like the working group to finish up, ship a bunch of documents and go inactive. Expanding the charter doesn't sound like the way to get there. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 05:08:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24493 for ; Thu, 17 Jul 2003 05:08:09 -0400 (EDT) Received: (qmail 29081 invoked by uid 605); 17 Jul 2003 09:08:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29063 invoked from network); 17 Jul 2003 09:08:08 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 17 Jul 2003 09:08:08 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6H983sR008011 for ; Thu, 17 Jul 2003 03:08:04 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6H983tK022034 for ; Thu, 17 Jul 2003 05:08:03 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6H9838Q011230 for ; Thu, 17 Jul 2003 05:08:03 -0400 (EDT) Message-Id: <200307170908.h6H9838Q011230@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Re: draft-ietf-secsh-assignednumbers-03.txt In-Reply-To: Your message of "Wed, 16 Jul 2003 16:32:31 BST." <20030716153231.GA11552@chiark.greenend.org.uk> Reply-to: sommerfeld@east.sun.com Date: Thu, 17 Jul 2003 05:08:03 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > The simplest solution might be to amend the Abstract of > assignednumbers to add an exception for "des-cbc". However I don't know > if this is considered "bad form" for such an IANA-oriented document. I wouldn't think so. but I'd just revise it to: This document defines the initial state of the IANA assigned numbers for the SSH protocol as defined in [SSH-ARCH], [SSH- TRANS], [SSH-CONNECT], [SSH-USERAUTH]. Except for one HISTORIC algorithm generally regarded as obsolete, this document does not define any protocols or any number ranges not already defined in the above referenced documents. (add exception, delete "new" because des-cbc use by sshv2 implementations is not new). If anyone objects, speak up ASAP. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 07:59:31 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02070 for ; Thu, 17 Jul 2003 07:59:30 -0400 (EDT) Received: (qmail 28120 invoked by uid 605); 17 Jul 2003 11:59:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28113 invoked from network); 17 Jul 2003 11:59:25 -0000 Received: from unknown (HELO konishi-polis.mit.edu) (81.160.157.184) by mail.netbsd.org with SMTP; 17 Jul 2003 11:59:25 -0000 Received: by konishi-polis.mit.edu (Postfix, from userid 8042) id A7499151D76; Thu, 17 Jul 2003 07:59:24 -0400 (EDT) To: Tom Wu Cc: "Joel N. Weber II" , Joseph Salowey , "'Nicolas Williams'" , ietf-ssh@NetBSD.org Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) References: <01b501c34be1$9541ad20$0200000a@amer.cisco.com> <3F15D701.9090508@arcot.com> From: Sam Hartman Date: Thu, 17 Jul 2003 07:59:24 -0400 In-Reply-To: <3F15D701.9090508@arcot.com> (Tom Wu's message of "Wed, 16 Jul 2003 15:51:45 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list >>>>> "Tom" == Tom Wu writes: Tom> Joel N. Weber II wrote: >> In theory, you can use that SASL mechanism with an intergrity >> protection layer. In practice, since it appears that the SASL >> SRP mechanism basically does the things you want a Secure Shell >> key exchange to accomplish, it may be better to define a new >> Secure Shell key exchange algorithm to support SRP. Tom> There are implementations of SRP as an SSH key exchange Tom> mechanism 'in the wild', and at least one expired I-D Tom> documenting them. They can presumably be revived as needed. Please don't; use Keith's GSSAPI mechanism. I believe that getting his draft in shape should not take too much time at all. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 08:25:19 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03283 for ; Thu, 17 Jul 2003 08:25:18 -0400 (EDT) Received: (qmail 11467 invoked by uid 605); 17 Jul 2003 12:25:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11459 invoked from network); 17 Jul 2003 12:25:17 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.203.76) by mail.netbsd.org with SMTP; 17 Jul 2003 12:25:17 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa09321; 17 Jul 2003 14:24 CEST Date: Thu, 17 Jul 2003 14:24:57 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) In-Reply-To: <20030716205306.GD3182@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 Wed, 16 Jul 2003, Nicolas Williams wrote: > I think a number of issues are slowly piling up that ought to lead to > the revival of CAT, eventually. Well, the creation of a new WG, since cat has concluded, but yes. However, a number of the people involved have been rather busy with Kerberos lately, and so we've been putting off trying to spin up KITTEN (BTW, if you can think of a name to go with that acronym, let me know). At this point don't expect to see that work begin before late next year... -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 08:55:26 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04497 for ; Thu, 17 Jul 2003 08:55:26 -0400 (EDT) Received: (qmail 27661 invoked by uid 605); 17 Jul 2003 12:55:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27654 invoked from network); 17 Jul 2003 12:55:26 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 17 Jul 2003 12:55:26 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19d8I9-0001lw-00; Thu, 17 Jul 2003 13:55:25 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) Message-Id: Date: Thu, 17 Jul 2003 13:55:25 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Sam Hartman wrote: [existing implementations of SRP authentication in SSH] > Please don't; use Keith's GSSAPI mechanism. I believe that getting > his draft in shape should not take too much time at all. Stop me if I'm being completely ignorant, but I thought GSSAPI required the use of a null host key? One of the great things about SRP as implemented in the hacked OpenSSH I saw is that it uses the shared secret output from the SRP exchange to validate the ordinary SSH host key - so that you can connect to a machine whose host key you don't already know, enter your SRP passphrase in confidence that it can't be stolen even if the server has been spoofed, and if the SRP exchange completes successfully then you can also be sure that _that host key_ belongs to a machine which already knew what your passphrase should have been. Then, later, you can use other forms of authentication to talk to the same server and now be confident of its host key. I think that any SRP implementation which worked by avoiding the host key completely would be a step backwards from this. The whole host key problem is a major hassle to many SSH users, and making it simpler would be a serious gain. Cheers, Simon -- Simon Tatham "You may call that a cheap shot. I prefer to think of it as good value." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 09:46:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06400 for ; Thu, 17 Jul 2003 09:46:28 -0400 (EDT) Received: (qmail 24792 invoked by uid 605); 17 Jul 2003 13:46:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24785 invoked from network); 17 Jul 2003 13:46:28 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.220.41) by mail.netbsd.org with SMTP; 17 Jul 2003 13:46:28 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa01360; 17 Jul 2003 15:46 CEST Date: Thu, 17 Jul 2003 15:46:23 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: Simon Tatham cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 17 Jul 2003, Simon Tatham wrote: > Sam Hartman wrote: > [existing implementations of SRP authentication in SSH] > > Please don't; use Keith's GSSAPI mechanism. I believe that getting > > his draft in shape should not take too much time at all. > > Stop me if I'm being completely ignorant, but I thought GSSAPI > required the use of a null host key? No. The GSSAPI key exchange mechanisms support the use of any server host key type, and do provide a mechanism to (optionally) transport and authenticate the server host key in a secure fashion. The GSSAPI key exchange document defines the 'null' host key type so that hosts which have no host key can satisfy the following requirement, included in section 5.1 of the ssh transport draft, under the description of the 'server_host_key_algorithms' field: Algorithm selection depends on whether the chosen key exchange algorithm requires a signature or encryption capable host key. It MUST be possible to determine this from the public key algorithm name. The first algorithm on the client's list that satisfies the requirements and is also supported by the server MUST be chosen. If there is no such algorithm, both sides MUST disconnect. Servers will list only host key algorithms which they can actually use; if no host key is present for a particular algorithm, then that algorithm will not be listed. What this means is that if a host has no host keys at all, then no algorithms will be listed, and the requirement in the above-quoted paragraph cannot possibly be satisfied. What the 'null' host key algorithm does is provide a 'placeholder' to be included in the list when no other host key algorithms are present. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 10:11:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07905 for ; Thu, 17 Jul 2003 10:11:20 -0400 (EDT) Received: (qmail 8833 invoked by uid 605); 17 Jul 2003 14:11:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8826 invoked from network); 17 Jul 2003 14:11:19 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.220.41) by mail.netbsd.org with SMTP; 17 Jul 2003 14:11:19 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa01604; 17 Jul 2003 16:10 CEST Date: Thu, 17 Jul 2003 16:10:56 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 16 Jul 2003, Jeffrey Hutzelman wrote: > On Tue, 1 Jul 2003, Joel N. Weber II wrote: > > > Looking at the January 2002 mailing list archive, it becomes clear > > that while the public key types defined in the transport draft have > > this encoding: > > > > string certificate or public key format identifier > > byte[n] key/certificate data > > > > there is no requirement that public key types defined elsewhere will > > have that encoding. Perhaps the gsskeyex draft should explicitly say > > that SSH_MSG_KEXGSS_HOSTKEY only works with ssh-dss and ssh-rsa keys, > > or that it only works with types that start out with the type > > identifier as a string. > > Hm.. > My interpretation of the description of public key algorithms in section > 4.6 of the transport draft is that the encoding described above applies to > _all_ public key types, not just the ones defined in that document. In > particular, the section you quoted contains general information describing > the nature of public key algorithms and key and certificate formats. The > descriptions of specific algorithms defined in that document occur further > down, and while they do describe key formats including the specific value > of the format identifier to be used, this duplication is consistent with > usage in these documents. Actually, on further reflection, it doesn't matter. The key transported in an SSH_MSG_KEXGSS_HOSTKEY message belongs to the host key algorithm selected during algorithm negotiation. So we already know its type, and it doesn't matter whether the type is included in the blob we transport or not. Of course, this only helps when you are transporting a single host key of the type selected during algorithm negotiation. Fortunately, that is all that gsskeyex currently does. However, it doesn't help if what you want to do is transport multiple host keys, or use keyex with one algorithm to transport a key belonging to a second algorithm. To address those issues, I would like to propose a protocol extension in the form of a new host key algorithm, which could be called something like 'multi'. The key format for this algorithm would consist of a list of one or more { algorithm, key-data } tuples, and the format and semantics of signatures would be identical to those for the first tuple in the list. I haven't yet worked out all the details of how the algorithm negotiation would work, but I think it's doable. If there's interest in this, I'd be willing to work up a draft, either as a working group item or for individual submission. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 10:15:07 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08419 for ; Thu, 17 Jul 2003 10:15:06 -0400 (EDT) Received: (qmail 10849 invoked by uid 605); 17 Jul 2003 14:15:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10842 invoked from network); 17 Jul 2003 14:15:06 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.220.41) by mail.netbsd.org with SMTP; 17 Jul 2003 14:15:06 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa01608; 17 Jul 2003 16:14 CEST Date: Thu, 17 Jul 2003 16:14:47 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: Simon Tatham cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: WG Chair comments on draft-ietf-secsh-agent-01.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, 16 Jul 2003, Simon Tatham wrote: > Bill Sommerfeld wrote: > > 2) security considerations section doesn't mention the case where you > > do an ssh-add into a forwarded agent connection. While this > > exchange is protected via encryption, it does involve casually > > moving a long-term public keypair over the net to a remote system, > > which should raise a few eyebrows.. > > Hmm. I tend to see it the other way round. In the designed usage > model, the real agent is running on your _local_ system, which is > usually the only one you trust with your private keys. If you do an > ssh-add from a remote system, the potential problem is not the > transfer of the key to your trusted local machine: it's the fact > that the remote system somewhere on the Internet which you're > transferring the key _from_ had access to both the key file and the > passphrase. Or, if you're concerned about attacks on the network > connection between them, then the damage is probably already done > once you've typed the passphrase through your SSH connection. I think the key words in Bill's comment above are 'over the net', not 'remote'. I do think that moving a long-term keypair over the net is indeed not something to be done causally. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 10:30:59 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09195 for ; Thu, 17 Jul 2003 10:30:58 -0400 (EDT) Received: (qmail 21136 invoked by uid 605); 17 Jul 2003 14:30:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21129 invoked from network); 17 Jul 2003 14:30:58 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.220.41) by mail.netbsd.org with SMTP; 17 Jul 2003 14:30:58 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa01757; 17 Jul 2003 16:30 CEST Date: Thu, 17 Jul 2003 16:30:35 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: Simon Josefsson cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: Comment on draft-ietf-secsh-gsskeyex-06 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 Sun, 6 Jul 2003, Simon Josefsson wrote: > The document says: > > The client SHOULD NOT send more then one gssapi mechanism OID unless > there are no non-GSSAPI authentication methods between the GSSAPI > mechanisms in the order of preference, otherwise, authentication > methods may be executed out of order. > > Besides having four (!) negations, I think some hints on how different > GSSAPI mechanisms should be handled instead would be useful. E.g.: > > The client SHOULD send more than one mechanism OIDs only when all > of the mechanisms are of the same priority, compared to non-GSSAPI > authentication methods. Otherwise, authentication methods may be > executed out of order. Thus, the client could first send a > SSH_MSG_USERAUTH_REQUEST for one GSSAPI mechanism, then try public > key authentication, and then try another GSSAPI mechanism. I think we can do something along these lines, but not specifically the text you propose. The problem is that SHOULD and SHOULD NOT are not exactly inverses. We say "you SHOULD NOT do X unless Y". This makes a recommendation if Y is false, but none if Y is true. You say "you SHOULD do X if Y". This makes a recommendation if Y is true, but none if Y is false. > FWIW, another implementation of the GSSAPI user authentication part of > the specification is available. Patches (experimental!) for LSH using > GSSLib, Heimdal or MIT Kerberos 5, are available from > . Wonderful; thank you. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 11:09:16 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11011 for ; Thu, 17 Jul 2003 11:09:15 -0400 (EDT) Received: (qmail 10630 invoked by uid 605); 17 Jul 2003 15:09:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10623 invoked from network); 17 Jul 2003 15:09:13 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 Jul 2003 15:09:13 -0000 Received: by xanthine.gratuitous.org with local; Thu, 17 Jul 2003 11:09:11 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: ietf-ssh@NetBSD.org In-reply-to: (message from Jeffrey Hutzelman on Thu, 17 Jul 2003 16:10:56 +0200 (CEST)) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: Message-Id: Date: Thu, 17 Jul 2003 11:09:11 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list I'm likely to submit an individual draft soon describing an SSH_MSG_KEXINIT2 message real soon now. (Existing implementations will see it as a reserved message and send a message back saying that they don't recognize SSH_MSG_KEXINIT2, at least if they follow the IETF spec.) Specific things I want to change vs SSH_MSG_KEXINIT: 1) You iterate primarily over the host key list, rather than the algorithm list. Once you find a host key type that's in common between the client and the server, you then iterate over the key exchange algorithm list looking for the first algorithm on the client's list that's also in the server's list that works with the host key type you picked. 2) Each gss mechanism becomes a host key type, so that if your order of preference is kerberos, pgp, gsi, x.509, bare ssh key, in that order, you can actually express that preference (which you just can't do in that order with the way SSH_MSG_KEXINIT and the gssapi draft are currently specified). 3) The language optional field as it exists goes away. 4) Any optional fields after the standard set of required fields each start out with a name indicating what they are negotiating. So, you could have, for example secondary-host-key,ssh-dss,ssh-rsa if you wanted to negotiate public key algorithms for a secondary host key. The functionality of the optional language field in SSH_MSG_KEXINIT would also have a name added to the front of it. Perhaps the multi type you're proposing should be defined for secondary-host-key but not for use with a key exchange algorithm to actually verify the host's identity? 5) In order to prevent downgrade attacks, an implementation that would prefer to use SSH_MSG_KEXINIT2 lists SSH_MSG_KEXINIT2 as a keyex algorithm if it ends up sending an SSH_MSG_KEXINIT message, and if the SSH_MSG_KEXINIT from the peer includes SSH_MSG_KEXINIT2 as a key exchange algorithm when you also included SSH_MSG_KEXINIT2 as a key exchange algorithm, you abort. Does this seem like it would help with solving the problems you're interested in solving? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 12:26:46 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13054 for ; Thu, 17 Jul 2003 12:26:45 -0400 (EDT) Received: (qmail 2426 invoked by uid 605); 17 Jul 2003 16:25:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2418 invoked from network); 17 Jul 2003 16:25:50 -0000 Received: from mailrelay1.lanl.gov (128.165.4.101) by mail.netbsd.org with SMTP; 17 Jul 2003 16:25:50 -0000 Received: from lanl.gov (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (8.12.9/8.12.9/(ccn-5)) with ESMTP id h6HGPmZm013967; Thu, 17 Jul 2003 10:25:48 -0600 Message-ID: <3F16CE0C.4070009@lanl.gov> Date: Thu, 17 Jul 2003 10:25:48 -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: Jeffrey Hutzelman CC: ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-gsskeyex-06.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.35 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jeff, Can you also send me the .dtd for the XML? Since Bill seems in quite a hurry I thought I'd start now with comments and edits inline to my email. First some notes on my feedback. I will get as many of these edits as possible to you today. Editing Notes (based on RFC2223 and RFC2360): General Notes: 1. There is no intended audience section (RFC2223). 2. No references are given for any of the GSSAPI calls or messages, in any section. 3. The use of "section" is not capitalized consistently when used as part of a reference. 4. All acronyms/abbreviations must be written out fully and parenthetically referenced at their first occurance. 5. There should be two blank spaces between sentences. Title: 1. GSSAPI acronym must be written out fully. In my edit I expand GSS leaving out API. Table of Contents (TOC): 1. I think that we should have one. The document length falls in the optional range, 15-20. Abstract (see RFC2223 sect. 4.5): 1. Must not contain references. 2. Should not be longer than 20 lines. 3. Should be much less detailed. Introduction: 1. Introduction is inappropriately detailed and specific. 2. Should be much longer and more general in scope. Change log: 1. Is not conformant to recommendations in either RFC2223 or RFC2360. References: 1. Normative References 6-9, must be listed as Non-normative as these RFC's will not have been approved by the IETF at the time of this draft's submission. 2. I believe that 12-14 need to be Informative. Please correct me if I am wrong. These are the notes I have already and as soon as you can get me the .dtd you'll get my diff with most of these changes. I can provide exact references for my notes if anyone cares for clarification. Dave Jeffrey Hutzelman wrote: >On Wed, 16 Jul 2003, David M. Williams wrote: > > > >> Can you please email me a copy. I don't have afs on ony of my >>boxen. Most of my edits are gramatical and structural in nature so I'll >>be changing things a bit but not really touching the actual technical >>aspects of the draft. >> >> > >Sure; it's attached. Feel free to send me some patches. > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 12:44:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13454 for ; Thu, 17 Jul 2003 12:44:28 -0400 (EDT) Received: (qmail 11041 invoked by uid 605); 17 Jul 2003 16:44:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11034 invoked from network); 17 Jul 2003 16:44:29 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 Jul 2003 16:44:29 -0000 Received: by xanthine.gratuitous.org with local; Thu, 17 Jul 2003 12:44:26 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: Jeffrey Hutzelman , ietf-ssh@NetBSD.org In-reply-to: <20030717092241.A6332@binky.central.sun.com> (message from Nicolas Williams on Thu, 17 Jul 2003 09:22:44 -0700) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: <20030717092241.A6332@binky.central.sun.com> Message-Id: Date: Thu, 17 Jul 2003 12:44:26 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > How about a global request that a client send (after kex) to the server > to list the server's public host keys? Regardless of what GSSAPI ends up doing, something like that is probably a good idea for OpenPGP: it would be nice to have a way to get revocation certificates from the server after you have connected to the correct server, in case there are old host keys that have been stolen, and I don't think putting multiple toplevel keys in the key sent during keyex is the right solution. I'm willing to write a draft about messages to do this, though if jhutz wants to, I'd be happy to defer to him. (Indeed, the draft on using pgp-sign-* with secsh that I've written and intend to submit as soon as drafts are being accepted again talks about the usefulness of such a mechanism, without proposing one.) A similar revocation mechanism for X.509 may also be a good idea. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 13:03:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13845 for ; Thu, 17 Jul 2003 13:03:21 -0400 (EDT) Received: (qmail 18771 invoked by uid 605); 17 Jul 2003 17:03:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18764 invoked from network); 17 Jul 2003 17:03:23 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 17 Jul 2003 17:03:23 -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 h6HH3KWv029560; Thu, 17 Jul 2003 11:03:20 -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 h6HH3JbO024731; Thu, 17 Jul 2003 11:03:19 -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 h6HH09Qx006353; Thu, 17 Jul 2003 10:00:09 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6HH09of006352; Thu, 17 Jul 2003 10:00:09 -0700 (PDT) Date: Thu, 17 Jul 2003 10:00:09 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030717170009.GX5706@binky.central.sun.com> References: <20030717092241.A6332@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 17, 2003 at 12:44:26PM -0400, Joel N. Weber II wrote: > > How about a global request that a client send (after kex) to the server > > to list the server's public host keys? > > Regardless of what GSSAPI ends up doing, something like that is > probably a good idea for OpenPGP: it would be nice to have a way to > get revocation certificates from the server after you have connected > to the correct server, in case there are old host keys that have been > stolen, and I don't think putting multiple toplevel keys in the key > sent during keyex is the right solution. I'm willing to write a draft > about messages to do this, though if jhutz wants to, I'd be happy to > defer to him. > > (Indeed, the draft on using pgp-sign-* with secsh that I've written > and intend to submit as soon as drafts are being accepted again talks > about the usefulness of such a mechanism, without proposing one.) > > A similar revocation mechanism for X.509 may also be a good idea. I think I'd call this "implicit revocation." The server tells the clients what all its publick keys (and certs) are after authenticating itself to the clients and the clients update their database of known server host keys, adding new ones and removing old ones. I think doing this as a global request rather than as a new host key pseudo-alg is the way to go. The only problem being that global requests are a feature of the "ssh-connection" service, so new services would have to duplicate this functionality. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 13:12:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13053 for ; Thu, 17 Jul 2003 12:26:45 -0400 (EDT) Received: (qmail 2773 invoked by uid 605); 17 Jul 2003 16:26:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2763 invoked from network); 17 Jul 2003 16:25:59 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 17 Jul 2003 16:25:59 -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 h6HGPuKO006100; Thu, 17 Jul 2003 09:25:56 -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 h6HGPtcm008987; Thu, 17 Jul 2003 10:25:55 -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 h6HGMjQx006338; Thu, 17 Jul 2003 09:22:45 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6HGMirx006337; Thu, 17 Jul 2003 09:22:44 -0700 (PDT) Date: Thu, 17 Jul 2003 09:22:44 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030717092241.A6332@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 jhutz@cmu.edu on Thu, Jul 17, 2003 at 04:10:56PM +0200 Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 17, 2003 at 04:10:56PM +0200, Jeffrey Hutzelman wrote: > Of course, this only helps when you are transporting a single host key of > the type selected during algorithm negotiation. Fortunately, that is all > that gsskeyex currently does. However, it doesn't help if what you want > to do is transport multiple host keys, or use keyex with one algorithm to > transport a key belonging to a second algorithm. > > To address those issues, I would like to propose a protocol extension in > the form of a new host key algorithm, which could be called something like > 'multi'. The key format for this algorithm would consist of a list of one > or more { algorithm, key-data } tuples, and the format and semantics of > signatures would be identical to those for the first tuple in the list. > I haven't yet worked out all the details of how the algorithm negotiation > would work, but I think it's doable. How about a global request that a client send (after kex) to the server to list the server's public host keys? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 14:25:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16685 for ; Thu, 17 Jul 2003 14:25:09 -0400 (EDT) Received: (qmail 3259 invoked by uid 605); 17 Jul 2003 18:25:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3252 invoked from network); 17 Jul 2003 18:25:08 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.210.59) by mail.netbsd.org with SMTP; 17 Jul 2003 18:25:08 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa08583; 17 Jul 2003 20:24 CEST Date: Thu, 17 Jul 2003 20:24:42 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: "David M. Williams" cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: I-D ACTION:draft-ietf-secsh-gsskeyex-06.txt In-Reply-To: <3F16CE0C.4070009@lanl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 17 Jul 2003, David M. Williams wrote: > Can you also send me the .dtd for the XML? Since Bill seems in > quite a hurry I thought I'd start now with comments and edits inline to > my email. First some notes on my feedback. I will get as many of these > edits as possible to you today. The DTD and the (tcl) code to turn it into an internet-draft are available from the IETF web site. I didn't write them; they're the result of some work that Marshall Rose did. > Table of Contents (TOC): > > 1. I think that we should have one. The document length falls in > the optional range, > 15-20. Yeah; unfortunately, the code which translates the XML isn't flexible enough to generate one, which means I'd have to do it by hand, and repaginate by hand. Which sort of defeats the point of not just editing it as text to begin with. > Change log: > > 1. Is not conformant to recommendations in either RFC2223 or > RFC2360. I don't see anything in ID-nits, RFC2223, or RFC2360 that says I shouldn't keep a change log between versions of an I-D, or that says what form it should take. Note that the section will be removed prior to publication as an RFC. > References: > > 1. Normative References 6-9, must be listed as Non-normative as > these RFC's will > not have been approved by the IETF at the time of this draft's > submission. Incorrect. The references are normative; that is, they materially affect the meaning of the document and are required in order to implement it correctly. This property does not magically disappear just because the documents in question haven't been approved yet. This document can't proceed faster than the core documents, and appropriate RFC references will be filled in once they are resolved. > 2. I believe that 12-14 need to be Informative. Please correct me > if I am wrong. References 12-14 are indeed listed as non-normative references. > These are the notes I have already and as soon as you can get me the > .dtd you'll get my diff with most of these changes. I can provide exact > references for my notes if anyone cares for clarification. Thanks for the notes. Diffs aren't actually required; I'll probably make the relevant edits during my trip home, along with some other changes that have been discussed on the list. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 14:31:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16866 for ; Thu, 17 Jul 2003 14:31:12 -0400 (EDT) Received: (qmail 6258 invoked by uid 605); 17 Jul 2003 18:31:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6251 invoked from network); 17 Jul 2003 18:31:12 -0000 Received: from liandra.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.210.59) by mail.netbsd.org with SMTP; 17 Jul 2003 18:31:12 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa08587; 17 Jul 2003 20:30 CEST Date: Thu, 17 Jul 2003 20:30:30 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: <20030717170009.GX5706@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 Thu, 17 Jul 2003, Nicolas Williams wrote: > I think doing this as a global request rather than as a new host key > pseudo-alg is the way to go. The only problem being that global > requests are a feature of the "ssh-connection" service, so new services > would have to duplicate this functionality. I agree. Let's drop the 'multi' pseudo-algorithm proposal, and consider a new global request instead. Ideally, we'd find a way to do this not as part of a particular connection service, since it really relates directly to the transport protocol. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 14:57:35 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17738 for ; Thu, 17 Jul 2003 14:57:34 -0400 (EDT) Received: (qmail 22661 invoked by uid 605); 17 Jul 2003 18:57:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22610 invoked from network); 17 Jul 2003 18:57:31 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 17 Jul 2003 18:57:31 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6HIvSuR026686; Thu, 17 Jul 2003 11:57:29 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6HIvStK011648; Thu, 17 Jul 2003 14:57:28 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6HIvS8Q014324; Thu, 17 Jul 2003 14:57:28 -0400 (EDT) Message-Id: <200307171857.h6HIvS8Q014324@thunk.east.sun.com> From: Bill Sommerfeld To: "David M. Williams" cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: I-D ACTION:draft-ietf-secsh-gsskeyex-06.txt In-Reply-To: Your message of "Thu, 17 Jul 2003 20:24:42 +0200." Reply-to: sommerfeld@east.sun.com Date: Thu, 17 Jul 2003 14:57:27 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > > Can you also send me the .dtd for the XML? Since Bill seems in > > quite a hurry I thought I'd start now with comments and edits inline to > > my email. First some notes on my feedback. I will get as many of these > > edits as possible to you today. > > The DTD and the (tcl) code to turn it into an internet-draft are available > from the IETF web site. I didn't write them; they're the result of some > work that Marshall Rose did. If Jeff is using the tool/dtd I'm thinking of, see http://xml.resource.org/ for the toolset and backing databases. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 14:58:24 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17776 for ; Thu, 17 Jul 2003 14:58:23 -0400 (EDT) Received: (qmail 23305 invoked by uid 605); 17 Jul 2003 18:58:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23298 invoked from network); 17 Jul 2003 18:58:22 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 17 Jul 2003 18:58:22 -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 h6HIwIWv014842; Thu, 17 Jul 2003 12:58:18 -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 h6HIwIcm018459; Thu, 17 Jul 2003 12:58:18 -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 h6HIt8Qx006429; Thu, 17 Jul 2003 11:55:08 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6HIt7Bb006428; Thu, 17 Jul 2003 11:55:07 -0700 (PDT) Date: Thu, 17 Jul 2003 11:55:07 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030717185507.GD6374@binky.central.sun.com> References: <20030717170009.GX5706@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 17, 2003 at 08:30:30PM +0200, Jeffrey Hutzelman wrote: > I agree. Let's drop the 'multi' pseudo-algorithm proposal, and consider a > new global request instead. Ideally, we'd find a way to do this not as > part of a particular connection service, since it really relates directly > to the transport protocol. Agreed. Unfortunately, there is no method for negotiating the use of features not present in the transport I-D. This problem has come up in the "gssapi host key algorithm usage" and "retrying keyex" threads. To solve the multi host public key advertisement issue elegantly we'd have to add a post-keyex, pre-userauth message and response. And we'd have to negotiate support for this during keyex. To negotiate new features in keyex elegantly we must either make use of the reserved uint32 field in the SSH_MSG_KEXINIT packet or rev the protocol minor version. Making use of that reserved field without revving the protocol minor version is problematic because the transport I-D does not discuss its semantics (do we have time to fix that? I guess I'd better comment on that before the last call ends). And revving the protocol minor version is a non-starter at the moment and probably won't come to pass for quite some time. (I'm ignoring, too, the issue of how v1 vs. v2 negotiation would happen if the v2 minor version is revved - let's not go there). To negotiate new features in keyex without revving the protocol minor version or without extending the SSH_MSG_KEXINIT may not be elegant but it is doable. I have suggested the use of bogus alg names for this purpose in earlier threads. We should explore the semantics of SSH_MSG_KEXINIT extensibility. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 15:19:46 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19474 for ; Thu, 17 Jul 2003 15:19:45 -0400 (EDT) Received: (qmail 9180 invoked by uid 605); 17 Jul 2003 19:19:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9103 invoked from network); 17 Jul 2003 19:19:43 -0000 Received: from anchorage.arcot.com (206.14.221.34) by mail.netbsd.org with SMTP; 17 Jul 2003 19:19:43 -0000 Received: from arcot.com (172.16.50.219 [172.16.50.219]) by anchorage.arcot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 38JG75BN; Thu, 17 Jul 2003 12:14:28 -0700 Message-ID: <3F16F988.20103@arcot.com> Date: Thu, 17 Jul 2003 12:31:20 -0700 From: Tom Wu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Tatham CC: ietf-ssh@NetBSD.org Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) 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: > Sam Hartman wrote: > [existing implementations of SRP authentication in SSH] > >>Please don't; use Keith's GSSAPI mechanism. I believe that getting >>his draft in shape should not take too much time at all. > > > Stop me if I'm being completely ignorant, but I thought GSSAPI > required the use of a null host key? > > One of the great things about SRP as implemented in the hacked > OpenSSH I saw is that it uses the shared secret output from the SRP > exchange to validate the ordinary SSH host key - so that you can > connect to a machine whose host key you don't already know, enter > your SRP passphrase in confidence that it can't be stolen even if > the server has been spoofed, and if the SRP exchange completes > successfully then you can also be sure that _that host key_ belongs > to a machine which already knew what your passphrase should have > been. Then, later, you can use other forms of authentication to talk > to the same server and now be confident of its host key. > > I think that any SRP implementation which worked by avoiding the > host key completely would be a step backwards from this. The whole > host key problem is a major hassle to many SSH users, and making it > simpler would be a serious gain. I agree completely - one of the big benefits of SRP is that it does both strong password authentication *and* key exchange, and a protocol can leverage the exchanged key for subsequent secure communications. The important technical property is the tying of the SRP exchange to the protocol's native session security layer. As of now, the two popular approaches are: - Use the SRP session key directly as a session key (e.g. SRP/TLS) - Use the SRP key exchange to validate another, previously unauthenticated, key exchange (e.g. SSH). The latter approach seems useful for SSH since its own key exchange mechanism is based on the host key. I am also ignorant of how GSSAPI would handle this. The important question to ask is: What happens if the SSH host public key is modified by an attacker in transit when doing an SRP authentication? With the patched OpenSSH, since it includes a hash of the public key inside the SRP verification messages, it would cause authentication to fail, thwarting the MITM attack. > > Cheers, > Simon Tom -- Tom Wu Chief Security Architect Arcot Systems (408) 969-6124 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 15:21:43 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19549 for ; Thu, 17 Jul 2003 15:21:42 -0400 (EDT) Received: (qmail 10629 invoked by uid 605); 17 Jul 2003 19:21:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10622 invoked from network); 17 Jul 2003 19:21:42 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 Jul 2003 19:21:42 -0000 Received: by xanthine.gratuitous.org with local; Thu, 17 Jul 2003 15:21:39 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: Jeffrey Hutzelman , ietf-ssh@NetBSD.org In-reply-to: <20030717185507.GD6374@binky.central.sun.com> (message from Nicolas Williams on Thu, 17 Jul 2003 11:55:07 -0700) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: <20030717170009.GX5706@binky.central.sun.com> <20030717185507.GD6374@binky.central.sun.com> Message-Id: Date: Thu, 17 Jul 2003 15:21:39 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > To negotiate new features in keyex elegantly we must either make use of > the reserved uint32 field in the SSH_MSG_KEXINIT packet or rev the > protocol minor version. Making use of that reserved field without > revving the protocol minor version is problematic because the transport > I-D does not discuss its semantics (do we have time to fix that? I > guess I'd better comment on that before the last call ends). And > revving the protocol minor version is a non-starter at the moment and > probably won't come to pass for quite some time. > > (I'm ignoring, too, the issue of how v1 vs. v2 negotiation would happen > if the v2 minor version is revved - let's not go there). While I have previously spewed to the list about many of these things as possible ways to extend the protocol and why they will work badly, I did so before I'd realized that we had this in the transport draft: | 9.4 Reserved Messages | | An implementation MUST respond to all unrecognized messages with an | SSH_MSG_UNIMPLEMENTED message in the order in which the messages were | received. Such messages MUST be otherwise ignored. Later protocol | versions may define other meanings for these message types. | | byte SSH_MSG_UNIMPLEMENTED | uint32 packet sequence number of rejected message So I see no reason why the working group can't declare that there will be an SSH_MSG_KEXINIT2 which has a numeric value of 22, and SSH_MSG_HOST_KEYS_REQ can be 23, and SSH_MSG_HOST_KEYS_REP can be 24. (Or we could pick other numbers. It isn't important what the numbers are as long as we agree on them and nobody is using them for something else.) And unless someone knows that there are buggy implementations out there, we can assume that ``negotiation'' will happen when SSH_MSG_UNIMPLEMENTED gets sent. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 15:28:44 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19799 for ; Thu, 17 Jul 2003 15:28:43 -0400 (EDT) Received: (qmail 15350 invoked by uid 605); 17 Jul 2003 19:28:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15343 invoked from network); 17 Jul 2003 19:28:42 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 Jul 2003 19:28:42 -0000 Received: by xanthine.gratuitous.org with local; Thu, 17 Jul 2003 15:28:40 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: , ietf-ssh@NetBSD.org In-reply-to: <20030717170009.GX5706@binky.central.sun.com> (message from Nicolas Williams on Thu, 17 Jul 2003 10:00:09 -0700) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: <20030717092241.A6332@binky.central.sun.com> <20030717170009.GX5706@binky.central.sun.com> Message-Id: Date: Thu, 17 Jul 2003 15:28:40 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I think I'd call this "implicit revocation." The server tells the > clients what all its publick keys (and certs) are after authenticating > itself to the clients and the clients update their database of known > server host keys, adding new ones and removing old ones. You don't want to remove the old ones. You want to mark them as permanently unusable. Consider a host foo.example.com which has a GPG host key. Assume it gets compromised, and the attacker copies the private key, and gets a copy of the public key which has a signature made by the sysadmin's public key. Assume that my client doesn't store the compromised key. There is nothing to require the attacker to send the revocation certficate along with the key, and so if I don't have the revocation certificate cached locally and pay attention to only what the attacker sends me, it's entirely possible that I'll get something that looks like a valid key. Another way to try to solve this problem is by contacting a keyserver. If you connect to a keyserver using TLS, and you trust the keyserver to keep the revocation certificate for forever once it gets it, this can be secure. But I don't know any keyservers that support this level of security, and it's desireable to not depend on being able to contact a key server when authenticating an ssh server, for various reasons related to performance, reliability, and denial of service tradeoffs. Contacting a keyserver in this fashion may be a feature worth implementing someday, but being able to send revocation certificates in the ssh protocol is still useful. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 15:29:48 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19862 for ; Thu, 17 Jul 2003 15:29:47 -0400 (EDT) Received: (qmail 16114 invoked by uid 605); 17 Jul 2003 19:29:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16107 invoked from network); 17 Jul 2003 19:29:47 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 17 Jul 2003 19:29:47 -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 h6HJThQY004007; Thu, 17 Jul 2003 13:29:43 -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 h6HJThbO015828; Thu, 17 Jul 2003 13:29: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 h6HJQXQx006456; Thu, 17 Jul 2003 12:26:33 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6HJQXbI006455; Thu, 17 Jul 2003 12:26:33 -0700 (PDT) Date: Thu, 17 Jul 2003 12:26:33 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030717192633.GG6374@binky.central.sun.com> References: <20030717170009.GX5706@binky.central.sun.com> <20030717185507.GD6374@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 17, 2003 at 03:21:39PM -0400, Joel N. Weber II wrote: > While I have previously spewed to the list about many of these things > as possible ways to extend the protocol and why they will work badly, > I did so before I'd realized that we had this in the transport draft: > > | 9.4 Reserved Messages > | > | An implementation MUST respond to all unrecognized messages with an > | SSH_MSG_UNIMPLEMENTED message in the order in which the messages were > | received. Such messages MUST be otherwise ignored. Later protocol > | versions may define other meanings for these message types. > | > | byte SSH_MSG_UNIMPLEMENTED > | uint32 packet sequence number of rejected message > > So I see no reason why the working group can't declare that there will > be an SSH_MSG_KEXINIT2 which has a numeric value of 22, and > SSH_MSG_HOST_KEYS_REQ can be 23, and SSH_MSG_HOST_KEYS_REP can be 24. > (Or we could pick other numbers. It isn't important what the numbers > are as long as we agree on them and nobody is using them for something > else.) And unless someone knows that there are buggy implementations > out there, we can assume that ``negotiation'' will happen when > SSH_MSG_UNIMPLEMENTED gets sent. But, again, we have the problem that any such messages would not be factored into the session ID, thus making downgrade attacks possible. I'd rather either have KEXINIT extensibility semantics clarified or use bogus alg names. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 15:46:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20202 for ; Thu, 17 Jul 2003 15:46:13 -0400 (EDT) Received: (qmail 28132 invoked by uid 605); 17 Jul 2003 19:46:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28125 invoked from network); 17 Jul 2003 19:46:13 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 Jul 2003 19:46:13 -0000 Received: by xanthine.gratuitous.org with local; Thu, 17 Jul 2003 15:46:11 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: , ietf-ssh@NetBSD.org In-reply-to: <20030717192633.GG6374@binky.central.sun.com> (message from Nicolas Williams on Thu, 17 Jul 2003 12:26:33 -0700) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: <20030717170009.GX5706@binky.central.sun.com> <20030717185507.GD6374@binky.central.sun.com> <20030717192633.GG6374@binky.central.sun.com> Message-Id: Date: Thu, 17 Jul 2003 15:46:11 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > But, again, we have the problem that any such messages would not be > factored into the session ID, thus making downgrade attacks possible. Are we discussing the mechanism for sending host keys after key exchange? If so, the answer is that you wait until after the SSH_MSG_NEWKEYS, since the whole point of that is to provide keys that will be useful for rekeying and or for host key veriftication in key exchange in future connections. As for SSH_MSG_KEXINIT2, I believe I explained how I propose to prevent downgrade attacks. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 15:54:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20451 for ; Thu, 17 Jul 2003 15:54:36 -0400 (EDT) Received: (qmail 3030 invoked by uid 605); 17 Jul 2003 19:54:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3023 invoked from network); 17 Jul 2003 19:54:35 -0000 Received: from liandra.pc.cs.cmu.edu.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.210.59) by mail.netbsd.org with SMTP; 17 Jul 2003 19:54:35 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa08779; 17 Jul 2003 21:54 CEST Date: Thu, 17 Jul 2003 21:54:05 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 17 Jul 2003, Joel N. Weber II wrote: > I'm likely to submit an individual draft soon describing an > SSH_MSG_KEXINIT2 message real soon now. (Existing implementations > will see it as a reserved message and send a message back saying that > they don't recognize SSH_MSG_KEXINIT2, at least if they follow the > IETF spec.) Specific things I want to change vs SSH_MSG_KEXINIT: > > 1) You iterate primarily over the host key list, rather than the > algorithm list. Once you find a host key type that's in common > between the client and the server, you then iterate over the key > exchange algorithm list looking for the first algorithm on the > client's list that's also in the server's list that works with the > host key type you picked. Eh. I don't see a particular problem with this, but I don't see that it really solves anything either. This negotiation directly affects the fundamental security of the protocol, and getting it wrong would really suck badly. > 2) Each gss mechanism becomes a host key type, so that if your order > of preference is kerberos, pgp, gsi, x.509, bare ssh key, in that > order, you can actually express that preference (which you just > can't do in that order with the way SSH_MSG_KEXINIT and the gssapi > draft are currently specified). I don't think it's a good idea to try to treat GSS mechanisms as "host keys". The gsskeyex draft effectively defines a way to generate an independent key exchange algorithm for any GSS mechanism. Such algorithms use a number of common components, but they are not one key exchange algorithm with multiple "host key algorithms"; they are different key exchange algorithms and should be treated as such. Note that this approach was adopted in large part to specifically avoid the sort of multi-level negotiation problem that you appear to be trying to fix in item 1. I also think that such a change is completely orthogonal to the question of whether to select first the keyex algorithm or the host key algorithm. GSS key exchange algorithms work with _any_ host key, so the selection of host key type is not relevant to whether you want to use GSS, nor does it affect what GSS mechanism will be used. Similarly, neither the decision to use GSS nor the selection of mechanism should affect what host key algorithm is used. > 3) The language optional field as it exists goes away. > > 4) Any optional fields after the standard set of required fields each > start out with a name indicating what they are negotiating. So, > you could have, for example > > secondary-host-key,ssh-dss,ssh-rsa > > if you wanted to negotiate public key algorithms for a secondary host > key. The functionality of the optional language field in > SSH_MSG_KEXINIT would also have a name added to the front of it. Hm. I'm sort of neutral on this. An extension mechanism is probably useful, but we should be careful that it does not get overused. > Perhaps the multi type you're proposing should be defined for > secondary-host-key but not for use with a key exchange algorithm to > actually verify the host's identity? Actually, I think we can punt this part entirely; I think I prefer Nico's approach of doing host key transfer in a separate message after key exchange is complete. > 5) In order to prevent downgrade attacks, an implementation that would > prefer to use SSH_MSG_KEXINIT2 lists SSH_MSG_KEXINIT2 as a keyex > algorithm if it ends up sending an SSH_MSG_KEXINIT message, and if > the SSH_MSG_KEXINIT from the peer includes SSH_MSG_KEXINIT2 as a > key exchange algorithm when you also included SSH_MSG_KEXINIT2 as a > key exchange algorithm, you abort. Yes, something like this is definitely necessary, and I think what you describe will work. > Does this seem like it would help with solving the problems you're > interested in solving? So, I was going to start this message by suggesting that I think the goal of solving the multi-level negotiation mechanism would be better solved by the mechanism I proposed. Unfortunately, I realized first that I hadn't actually yet proposed the mechanism in question. So I will do so now.... Basically, the general idea is to create a new series of "magic" keyex algorithm names (hm.. I see a theme here). These would look something like XX:diffie-hellman-group1-sha1:ssh-dss, with the 'XX:' a constant defined in the spec. There are some problems with this approach, which I haven't yet had time to fully research; that's why I hadn't yet brought up the idea. But I'd much rather see a mechanism that allows negotiation of { keyex, host-key } tuples rather than simply switching the order, which doesn't eliminate the existence of a multi-level negotiation. Perhaps we could come up with a solution that incorporates both ideas, by adding a new message type that results in selection of algorithm and host key type at the same time. I'm not sure what the right answer is here, exactly, but I would not mind seeing a solution to the multi-level problem. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 16:10:52 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20814 for ; Thu, 17 Jul 2003 16:10:50 -0400 (EDT) Received: (qmail 13426 invoked by uid 605); 17 Jul 2003 20:10:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13419 invoked from network); 17 Jul 2003 20:10:50 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 17 Jul 2003 20:10:50 -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 h6HKAkQY026919; Thu, 17 Jul 2003 14:10:46 -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 h6HKAjbO001438; Thu, 17 Jul 2003 14:10: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 h6HK7ZQx006480; Thu, 17 Jul 2003 13:07:35 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6HK7Zj1006479; Thu, 17 Jul 2003 13:07:35 -0700 (PDT) Date: Thu, 17 Jul 2003 13:07:35 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: jhutz@cmu.edu, ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030717200735.GH6374@binky.central.sun.com> References: <20030717170009.GX5706@binky.central.sun.com> <20030717185507.GD6374@binky.central.sun.com> <20030717192633.GG6374@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 17, 2003 at 03:46:11PM -0400, Joel N. Weber II wrote: > > But, again, we have the problem that any such messages would not be > > factored into the session ID, thus making downgrade attacks possible. > > Are we discussing the mechanism for sending host keys after key > exchange? If so, the answer is that you wait until after the > SSH_MSG_NEWKEYS, since the whole point of that is to provide keys that > will be useful for rekeying and or for host key veriftication in key > exchange in future connections. I was discussing the mechanism by which we extend the kex part of the protocol. While I agree with your comment about the mechanism for sending host keys after kex, you suggested a negotiation method that would apply also to extending the kex phase: On Thu, Jul 17, 2003 at 03:21:39PM -0400, Joel N. Weber II wrote: > So I see no reason why the working group can't declare that there will > be an SSH_MSG_KEXINIT2 which has a numeric value of 22, and > SSH_MSG_HOST_KEYS_REQ can be 23, and SSH_MSG_HOST_KEYS_REP can be 24. > (Or we could pick other numbers. It isn't important what the numbers > are as long as we agree on them and nobody is using them for something > else.) And unless someone knows that there are buggy implementations > out there, we can assume that ``negotiation'' will happen when > SSH_MSG_UNIMPLEMENTED gets sent. On Thu, Jul 17, 2003 at 03:46:11PM -0400, Joel N. Weber II wrote: > As for SSH_MSG_KEXINIT2, I believe I explained how I propose to > prevent downgrade attacks. Remind me? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 16:14:21 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20915 for ; Thu, 17 Jul 2003 16:14:20 -0400 (EDT) Received: (qmail 15398 invoked by uid 605); 17 Jul 2003 20:14:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15376 invoked from network); 17 Jul 2003 20:14:18 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 Jul 2003 20:14:18 -0000 Received: by xanthine.gratuitous.org with local; Thu, 17 Jul 2003 16:14:16 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: ietf-ssh@NetBSD.org In-reply-to: (message from Jeffrey Hutzelman on Thu, 17 Jul 2003 21:54:05 +0200 (CEST)) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: Message-Id: Date: Thu, 17 Jul 2003 16:14:16 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I don't think it's a good idea to try to treat GSS mechanisms as "host > keys". I don't understand why not. A ``host key algorithm'' is a subcomponent that is called by a key exchange algorithm in order to verify the identity of a host. The interface between the key exchange algorithm and the host key algorithm is well defined, creating a certain sort of interchangability. The key exchange mechanisms described by draft-ietf-secsh-gsskeyex all make the same GSSAPI calls; the only difference is which GSSAPI mechanism is being used. Also, the reason that I use the krb5 GSSAPI mechanism is because I have a keytab, and I want to verify that that keytab matches up properly. The purpose of using the GSSAPI mechanism is to verify the host's identity using a cryptographic key. > The gsskeyex draft effectively defines a way to generate an independent > key exchange algorithm for any GSS mechanism. Such algorithms use a > number of common components, but they are not one key exchange algorithm > with multiple "host key algorithms"; they are different key exchange > algorithms and should be treated as such. Note that this approach was > adopted in large part to specifically avoid the sort of multi-level > negotiation problem that you appear to be trying to fix in item 1. Yes, but it's the wrong way to avoid that problem, precisely because if I want to use pgp-sign-rsa if that's available, and then use Kerberos, and then use ssh-rsa, there is no way to specify that. > I also think that such a change is completely orthogonal to the question > of whether to select first the keyex algorithm or the host key algorithm. > GSS key exchange algorithms work with _any_ host key, so the selection of > host key type is not relevant to whether you want to use GSS, nor does it > affect what GSS mechanism will be used. Similarly, neither the decision > to use GSS nor the selection of mechanism should affect what host key > algorithm is used. I think you're confused on the definition of a host key. You seem to be assuming that a host key is always a public signing key. But draft-secsh-transport already allows for the possibility that you can have a public encryption key, which would require a different sort of key exchange algorithm. > So, I was going to start this message by suggesting that I think the goal > of solving the multi-level negotiation mechanism would be better solved by > the mechanism I proposed. Unfortunately, I realized first that I hadn't > actually yet proposed the mechanism in question. So I will do so now.... > > Basically, the general idea is to create a new series of "magic" keyex > algorithm names (hm.. I see a theme here). These would look something > like XX:diffie-hellman-group1-sha1:ssh-dss, with the 'XX:' a constant > defined in the spec. There are some problems with this approach, which I > haven't yet had time to fully research; that's why I hadn't yet brought up > the idea. But I'd much rather see a mechanism that allows negotiation of > { keyex, host-key } tuples rather than simply switching the order, which > doesn't eliminate the existence of a multi-level negotiation. What problem are you trying to solve that switching the order and treating GSSAPI mechanisms as host keys can't solve? I can't think of any reason why I'd want to use one key exchange mechanism with pgp-sign-rsa and a different one with ssh-rsa, which seems to be the problem you're trying to solve, so I'm wondering why you're trying to solve that problem. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 16:39:46 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21906 for ; Thu, 17 Jul 2003 16:39:45 -0400 (EDT) Received: (qmail 2024 invoked by uid 605); 17 Jul 2003 20:39:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2017 invoked from network); 17 Jul 2003 20:39:44 -0000 Received: from liandra.pc.cs.cmu.edu.ietf57.telekom.at (HELO liandra.pc.cs.cmu.edu) (81.160.210.59) by mail.netbsd.org with SMTP; 17 Jul 2003 20:39:44 -0000 Received: from liandra.pc.cs.cmu.edu ([127.0.0.1]) by liandra.pc.cs.cmu.edu id aa08875; 17 Jul 2003 22:39 CEST Date: Thu, 17 Jul 2003 22:39:23 +0200 (CEST) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" cc: ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at liandra.pc.cs.cmu.edu Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, 17 Jul 2003, Joel N. Weber II wrote: > The interface between the key exchange > algorithm and the host key algorithm is well defined And does not match the interface between a GSSAPI application protocol and a GSSAPI mechanism. > Yes, but it's the wrong way to avoid that problem, precisely because > if I want to use pgp-sign-rsa if that's available, and then use > Kerberos, and then use ssh-rsa, there is no way to specify that. No, it's not. Please note that the problem you describe exists _whether or not_ the intervening mechanism is GSS-KRB5. krb5 is not a "host key" that you want to use in preference to ssh-rsa; it's a key exchange that you want to use in preference to using a DH exchange signed by a non-PGP RSA key. The problem would exist for some other key exchange, too. The method in which GSS mechanisms are named doesn't make this problem go away, since the scope of the problem goes beyond GSS. However, it doesn't make it worse, either. > > I also think that such a change is completely orthogonal to the question > > of whether to select first the keyex algorithm or the host key algorithm. > > GSS key exchange algorithms work with _any_ host key, so the selection of > > host key type is not relevant to whether you want to use GSS, nor does it > > affect what GSS mechanism will be used. Similarly, neither the decision > > to use GSS nor the selection of mechanism should affect what host key > > algorithm is used. > > I think you're confused on the definition of a host key. You seem to > be assuming that a host key is always a public signing key. But > draft-secsh-transport already allows for the possibility that you can > have a public encryption key, which would require a different sort of > key exchange algorithm. No, I'm not confused. I know what the sshv2 protocol defines as a host key. GSS mechanisms are not host keys. I don't think we're going to make any progress on this issue, and I haven't heard any comments on this from the rest of the working group. At the moment, I'm disinclined to make a sweeping change of the sort you describe, because (1) I don't believe that it is either necessary or sufficient to solve the multi-level negoitation problem. (2) I don't believe it's the appropriate abstraction. (3) I don't see a working group concensus for a change. Actually, I don't see much of any response, but you need a concensus to make a change. (4) We have a fair bit of implementation experience with the current approach, including multiple implementations some of which support several GSSAPI mechanisms. It does work. (5) It's late in the process, which IMHO raises the bar for changes. (6) Again, lack of concensus to make the change. > What problem are you trying to solve that switching the order and > treating GSSAPI mechanisms as host keys can't solve? What problem are you trying to solve that treating GSSAPI mechanisms as host keys will solve? The multi-layer negotiation problem (keyex must be selected before host keys) is not unique to GSSAPI, and treating GSSAPI mechanisms as host keys makes the problem _WORSE_, not better. > I can't think of any reason why I'd want to use one key exchange > mechanism with pgp-sign-rsa and a different one with ssh-rsa, which > seems to be the problem you're trying to solve, so I'm wondering why > you're trying to solve that problem. I think you're limiting your vision to the mechanisms you happen to see today, and what you can think of yourself using. All of the algorithms are replaceable, which can lead to arbitrary combinations, including algorithms not presently in use. For example, you'd have exactly the same problem if you substituted the SRP algorithm that was discussed in another thread instead of one of the GSS algorithms. The problem is a general problem; let's use a general solution. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 16:48:19 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22127 for ; Thu, 17 Jul 2003 16:48:19 -0400 (EDT) Received: (qmail 7059 invoked by uid 605); 17 Jul 2003 20:48:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7050 invoked from network); 17 Jul 2003 20:48:19 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 17 Jul 2003 20:48:19 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1701343; Thu, 17 Jul 2003 14:48:18 -0600 Message-ID: <3F170B92.4030307@vandyke.com> Date: Thu, 17 Jul 2003 14:48:18 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: "Joel N. Weber II" CC: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) 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 >>The gsskeyex draft effectively defines a way to generate an independent >>key exchange algorithm for any GSS mechanism. Such algorithms use a >>number of common components, but they are not one key exchange algorithm >>with multiple "host key algorithms"; they are different key exchange >>algorithms and should be treated as such. Note that this approach was >>adopted in large part to specifically avoid the sort of multi-level >>negotiation problem that you appear to be trying to fix in item 1. >> >> > >Yes, but it's the wrong way to avoid that problem, precisely because >if I want to use pgp-sign-rsa if that's available, and then use >Kerberos, and then use ssh-rsa, there is no way to specify that. > Now, I'm not claiming we can arrange it at this late data, but it seems like maybe the correct way to address your concern would be to seperate key exchange and server authentication. Putting aside how to do this without a significant rewrite of the core drafts, doing this might have several advantages. 1. I believe the problem you have would be resolved. Rather than 'publickey' algorithms in our key exchange, you would instead have 'server-authentication' methods. Gssapi would not be a key exchange method, it would be a server-authentication method. 2. Gssapi would have been a simpler draft because it would have had to define diffie-hellman key exchange as well, and we would be wondering whether we should do gssapi-group-exchange as well. Now, on the half-serious, we could, but I'm not sure we want to, side of things, we could introduce a new service, called authentication, instead of userauth, and make it responsible for handling both host and user authentication. We could do this in conjuction with the new KEX2 message you are proposing. On the brighter side, it wouldn't hold up the core drafts, we could address other userauth problems that have come up, and we would be world famous :-) On the darker side, it is a lot of work, will take time, and we might be world infamous for even suggesting it :-) At any rate, I was hoping perhaps some clarity would be brought by the realization that it is the tying of host authentication and key exchange that is the root of the problem. Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 17:09:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22878 for ; Thu, 17 Jul 2003 17:09:28 -0400 (EDT) Received: (qmail 21014 invoked by uid 605); 17 Jul 2003 21:09:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21007 invoked from network); 17 Jul 2003 21:09:28 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 Jul 2003 21:09:28 -0000 Received: by xanthine.gratuitous.org with local; Thu, 17 Jul 2003 17:09:27 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: "Joel N. Weber II" , ietf-ssh@NetBSD.org In-reply-to: (message from Jeffrey Hutzelman on Thu, 17 Jul 2003 22:39:23 +0200 (CEST)) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: Message-Id: Date: Thu, 17 Jul 2003 17:09:27 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > What problem are you trying to solve that treating GSSAPI mechanisms as > host keys will solve? The multi-layer negotiation problem (keyex must be > selected before host keys) is not unique to GSSAPI, and treating GSSAPI > mechanisms as host keys makes the problem _WORSE_, not better. Note that I proposed making two changes together (each GSS mechanism is a host key algorithm, and you negotiate first on host keys rather than first on key exchange algorithms). It's obvious that if you make either change without the other, the situation gets worse than it is now. However, I believe that if you make the two changes together, you solve the problem I want to solve. > I think you're limiting your vision to the mechanisms you happen to see > today, and what you can think of yourself using. All of the algorithms > are replaceable, which can lead to arbitrary combinations, including > algorithms not presently in use. For example, you'd have exactly the same > problem if you substituted the SRP algorithm that was discussed in another > thread instead of one of the GSS algorithms. How would this fail? If my host key algorithms are pgp-sign-rsa,pgp-sign-dss,Se3H81ismmOC3OE+FwYCiQ==,srp,[GSI],x509v3-sign-rsa,x509v3-sign-dss,ssh-rsa,ssh-dss and my key exchange algorithms are diffie-hellman-group-exchange,diffie-hellman-group1,gss-group-exchange-sha1,gss-group1-sha1,srp (assuming for the moment that srp ends up being its own keyex mechanism and not a GSS mech, not that it matters for this discussion) I don't see why going through the list of host key algorithms, finding the first one that will work, and then picking the first suitable key exchange algorithms will fail. > The problem is a general problem; let's use a general solution. Yes, but we shouldn't design in generality that doesn't provide value, which I think your tuples proposal does. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 17 17:20:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23043 for ; Thu, 17 Jul 2003 17:20:05 -0400 (EDT) Received: (qmail 28530 invoked by uid 605); 17 Jul 2003 21:20:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28523 invoked from network); 17 Jul 2003 21:20:06 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 17 Jul 2003 21:20:06 -0000 Received: by xanthine.gratuitous.org with local; Thu, 17 Jul 2003 17:20:05 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: ietf-ssh@NetBSD.org In-reply-to: (message from Jeffrey Hutzelman on Thu, 17 Jul 2003 22:39:23 +0200 (CEST)) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: Message-Id: Date: Thu, 17 Jul 2003 17:20:05 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > (1) I don't believe that it is either necessary or sufficient to solve > the multi-level negoitation problem. Could you please explain why you believe the changes I have proposed are not sufficient? I don't think you've done so. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 18 03:39:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20963 for ; Fri, 18 Jul 2003 03:39:41 -0400 (EDT) Received: (qmail 6449 invoked by uid 605); 18 Jul 2003 07:39:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6442 invoked from network); 18 Jul 2003 07:39:38 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 18 Jul 2003 07:39:38 -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 h6I7ZrOc009024 for ; Fri, 18 Jul 2003 09:35:53 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 3D4472D041; Fri, 18 Jul 2003 09:36:27 +0200 (CEST) Date: Fri, 18 Jul 2003 09:36:27 +0200 From: Markus Friedl To: ietf-ssh@NetBSD.org Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) Message-ID: <20030718073627.GB18727@folly> References: <3F16F988.20103@arcot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F16F988.20103@arcot.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 17, 2003 at 12:31:20PM -0700, Tom Wu wrote: > With the patched OpenSSH, since it includes a > hash of the public key inside the SRP verification messages, it would > cause authentication to fail, thwarting the MITM attack. I don't see how this is an improvement over pubkey auth, since it allows you to detect a MITM attack as well. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 18 04:11:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA21875 for ; Fri, 18 Jul 2003 04:11:14 -0400 (EDT) Received: (qmail 21747 invoked by uid 605); 18 Jul 2003 08:11:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21740 invoked from network); 18 Jul 2003 08:11:13 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 18 Jul 2003 08:11:13 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19dQKe-0005lA-00; Fri, 18 Jul 2003 09:11:12 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <20030718073627.GB18727@folly> Subject: Re: GSS-API SRP mech (was Re: retrying keyex ...) Message-Id: Date: Fri, 18 Jul 2003 09:11:12 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > On Thu, Jul 17, 2003 at 12:31:20PM -0700, Tom Wu wrote: >> With the patched OpenSSH, since it includes a >> hash of the public key inside the SRP verification messages, it would >> cause authentication to fail, thwarting the MITM attack. Markus Friedl wrote: > I don't see how this is an improvement over pubkey auth, since > it allows you to detect a MITM attack as well. It isn't an improvement over pubkey auth. It's an improvement over _password_ auth - the authentication method you use when you're logging in from (say) a new computer and don't have your private key conveniently to hand. Once you have bootstrapped your authentication of the host using an SRP login, you can then create a public key on your new system and set the server up to recognise it. Cheers, Simon -- Simon Tatham "That all men should be brothers is a dream of people who have no brothers." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 18 22:21:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20841 for ; Fri, 18 Jul 2003 22:21:05 -0400 (EDT) Received: (qmail 4118 invoked by uid 605); 19 Jul 2003 02:21:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4111 invoked from network); 19 Jul 2003 02:21:04 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 19 Jul 2003 02:21:04 -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 h6J2Kwt7022471; Fri, 18 Jul 2003 19:20:58 -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 h6J2Kvcm021057; Fri, 18 Jul 2003 20:20:57 -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 h6J2HkQx007637; Fri, 18 Jul 2003 19:17:46 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6J2HjuM007636; Fri, 18 Jul 2003 19:17:45 -0700 (PDT) Date: Fri, 18 Jul 2003 19:17:45 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030719021742.GA7369@binky.central.sun.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 17, 2003 at 09:54:05PM +0200, Jeffrey Hutzelman wrote: > On Thu, 17 Jul 2003, Joel N. Weber II wrote: > > 1) You iterate primarily over the host key list, rather than the > > algorithm list. Once you find a host key type that's in common > > between the client and the server, you then iterate over the key > > exchange algorithm list looking for the first algorithm on the > > client's list that's also in the server's list that works with the > > host key type you picked. > > Eh. I don't see a particular problem with this, but I don't see that it > really solves anything either. This negotiation directly affects the > fundamental security of the protocol, and getting it wrong would really > suck badly. I do have a problem with it. The reason the current KEXINIT sucks is that it negotiates two important aspects of the ultimate kex method independently. While reversing the order of algorithm matching and treating the GSS-API mechanisms as "host key algorithms" would solve one problem we're dealing with I don't believe it to be a general solution. The kex negotiation should negotiate kex method tuples where there's a method name and some method-specific data, e.g., - "diffie-hellman-group1-sha1 w/ ssh-dss host keys" - "diffie-hellman-group-exchange-sha1 w/ pgp-sign-dss host keys" - "gss-group1-sha1 w/ Kerberos mech [OID]" And then too, the selection of cipher algorithm maybe ought to have an impact on the selection of kex method - or else we should deprecate fixed-group dh kex methods (at the cost of an extra 1/2 round-trip or having the client always pick the group that satisfies the needs of the cipher with largest key size). I'm with Jeff - we gotta get this right; let's not have to repeat this later. But, see below - I want to fix KEXINIT rather than add KEXINIT2. > I don't think it's a good idea to try to treat GSS mechanisms as "host > keys". Me either. > The gsskeyex draft effectively defines a way to generate an independent > key exchange algorithm for any GSS mechanism. Such algorithms use a > number of common components, but they are not one key exchange algorithm > with multiple "host key algorithms"; they are different key exchange > algorithms and should be treated as such. Note that this approach was > adopted in large part to specifically avoid the sort of multi-level > negotiation problem that you appear to be trying to fix in item 1. I don't mind separating the one part from the other - I just mind treating that second aspect of kex methods (the host key or gss mech) as the same thing when they aren't obviously the same kind of thing. I'd much rather treat the host key alg / gss mech as kex-specific "arguments" and then negotiate {kex, kex-specific-args} tuples. Alternatively, we could break the key exchange and the key exchange authentication parts of kex apart and have a generic DH key exchange and a generic message exchange for signing the DH key resulting from the DH key exchange. That way we'd need but a single key exchange method (or two, if the fixed-group (1 round-trip) vs. negotiated group (1.5 round-trips) distinction is worth keeping) and a bunch of kex signature exchange methods (ssh-*, pgp-*, ... gss-*). This may sound suspiciously like Joel's proposal, but the innovation here lies in changing the actual kex messages for the dh methods and getting rid of the gss kex name. All of this is way too complicated anyways. So let's see first if we can't just cut through and simplify: Earlier I proposed the use of "alias" alg names to cure some of the ills with KEXINIT that would solve the preference expression problem that Joel had. We could also negotiate KEXINIT extensions through the use of a bogus alg name. If we then define the semantics of the reserved field of KEXINIT we could add a field to KEXINIT (w/o revving the protocol version) for chaining hashes of failed kex messages through to the next KEXINIT so that the resulting session ID is bound to all kex messages and bingo, we've got secure re-triable kex w/ downgrade attack detection and w/o having to go back and modify the way each kex method defines the session ID hash. > > 3) The language optional field as it exists goes away. Why? I agree that we don't need two sets of lang fields (server-to-client and client-to-server). But we need a language negotiation for G11N. And it has to happen _before_ userauth, and if it can be piggy-backed onto the kex then you save a round-trip - funny, that's how it is now, and it works too. > > prefer to use SSH_MSG_KEXINIT2 lists SSH_MSG_KEXINIT2 as a keyex > > algorithm if it ends up sending an SSH_MSG_KEXINIT message, and if > > the SSH_MSG_KEXINIT from the peer includes SSH_MSG_KEXINIT2 as a > > key exchange algorithm when you also included SSH_MSG_KEXINIT2 as a > > key exchange algorithm, you abort. > > Yes, something like this is definitely necessary, and I think what you > describe will work. See above. I'd rather not do a KEXINIT2 - I think we can fix most of the problems, albeit not very elegantly, w/o such a drastic step. > So, I was going to start this message by suggesting that I think the goal > of solving the multi-level negotiation mechanism would be better solved by > the mechanism I proposed. Unfortunately, I realized first that I hadn't > actually yet proposed the mechanism in question. So I will do so now.... :) > Basically, the general idea is to create a new series of "magic" keyex > algorithm names (hm.. I see a theme here). These would look something > like XX:diffie-hellman-group1-sha1:ssh-dss, with the 'XX:' a constant > defined in the spec. There are some problems with this approach, which I > haven't yet had time to fully research; that's why I hadn't yet brought up > the idea. But I'd much rather see a mechanism that allows negotiation of > { keyex, host-key } tuples rather than simply switching the order, which > doesn't eliminate the existence of a multi-level negotiation. Hey, you're stealing my idea! Except that what I'd poposed was to use aliases like "diffie-hellman-group1-sha1:ssh" and "diffie-hellman-group1-sha1:pgp" (i.e., leave the actual signature alg out, but leave the "cert" type in). Plus a "re-triable-kex" bogus alg name to indicate, well, that and the use extended kexinit for kex hash chaining in subsequent kexinit messages. This way we've got a backwards compatible set of kex extensions. > Perhaps we could come up with a solution that incorporates both ideas, by > adding a new message type that results in selection of algorithm and host > key type at the same time. I'm not sure what the right answer is here, > exactly, but I would not mind seeing a solution to the multi-level > problem. KISS. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 18 22:27:07 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20929 for ; Fri, 18 Jul 2003 22:27:07 -0400 (EDT) Received: (qmail 7177 invoked by uid 605); 19 Jul 2003 02:27:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7168 invoked from network); 19 Jul 2003 02:27:06 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 19 Jul 2003 02:27:06 -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 h6J2R2E6019839; Fri, 18 Jul 2003 20:27:02 -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 h6J2R2bO010943; Fri, 18 Jul 2003 20:27:02 -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 h6J2NpQx007646; Fri, 18 Jul 2003 19:23:51 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6J2NpnF007645; Fri, 18 Jul 2003 19:23:51 -0700 (PDT) Date: Fri, 18 Jul 2003 19:23:51 -0700 From: Nicolas Williams To: Joseph Galbraith Cc: "Joel N. Weber II" , Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030719022351.GB7369@binky.central.sun.com> References: <3F170B92.4030307@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F170B92.4030307@vandyke.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 17, 2003 at 02:48:18PM -0600, Joseph Galbraith wrote: > Now, I'm not claiming we can arrange it at this late data, but it seems like > maybe the correct way to address your concern would be to seperate key > exchange and server authentication. Correct. And that's how it should have been from the get go. But I do think it's too late and I do think we have a not-elegant-but-bacwards- compatible way of solving the problems with kex/key preference expression and kex re-triability - I just posted on that. > Putting aside how to do this without a significant rewrite of the core > drafts, > doing this might have several advantages. > > 1. I believe the problem you have would be resolved. Rather than > 'publickey' algorithms in our key exchange, you would instead > have 'server-authentication' methods. Gssapi would not be a > key exchange method, it would be a server-authentication method. But each of these would have its own kex method too - to separate the two now would be too much work and not backwards compatible -> a big PITA. > 2. Gssapi would have been a simpler draft because it would have had > to define diffie-hellman key exchange as well, and we would be > wondering whether we should do gssapi-group-exchange as well. Yup - kex and kex auth should have been separate all along. > Now, on the half-serious, we could, but I'm not sure we want to, side of > things, we > could introduce a new service, called authentication, instead of > userauth, and make > it responsible for handling both host and user authentication. > > We could do this in conjuction with the new KEX2 message you are proposing. > > On the brighter side, it wouldn't hold up the core drafts, we could > address other userauth > problems that have come up, and we would be world famous :-) Yes it would hold up the core drafts. We'd have to define a KEX1 vs. KEX2 negotiation mechanism and all that. > On the darker side, it is a lot of work, will take time, and we might be > world infamous for > even suggesting it :-) We've been discussing it already, and I can imagine that the chair might be getting gloomy :) > At any rate, I was hoping perhaps some clarity would be brought by the > realization that > it is the tying of host authentication and key exchange that is the root > of the problem. I think so. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 19 01:55:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24228 for ; Sat, 19 Jul 2003 01:55:14 -0400 (EDT) Received: (qmail 23123 invoked by uid 605); 19 Jul 2003 05:55:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23114 invoked from network); 19 Jul 2003 05:55:11 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 19 Jul 2003 05:55:11 -0000 Received: by xanthine.gratuitous.org with local; Sat, 19 Jul 2003 01:55:07 -0400 From: "Joel N. Weber II" To: Nicolas Williams CC: Jeffrey Hutzelman , ietf-ssh@NetBSD.org In-reply-to: <20030719021742.GA7369@binky.central.sun.com> (message from Nicolas Williams on Fri, 18 Jul 2003 19:17:45 -0700) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: <20030719021742.GA7369@binky.central.sun.com> Message-Id: Date: Sat, 19 Jul 2003 01:55:07 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > I do have a problem with it. The reason the current KEXINIT sucks is > that it negotiates two important aspects of the ultimate kex method > independently. While reversing the order of algorithm matching and > treating the GSS-API mechanisms as "host key algorithms" would solve one > problem we're dealing with I don't believe it to be a general solution. What problem do you believe would actually be solved by the solution you're proposing that isn't solved by the solution I'm proposing? I can see where you're proposing to introduce more generality, but I don't see why anyone will ever benefit from that generality. As I think I've said, it seems that you and jhutz think that someone someday is going to have a burning desire to use group-exchange with pgp and group1 with ssh-*, and I really don't see why that is going to be especially useful. > And then too, the selection of cipher algorithm maybe ought to have an > impact on the selection of kex method - or else we should deprecate > fixed-group dh kex methods (at the cost of an extra 1/2 round-trip or > having the client always pick the group that satisfies the needs of the > cipher with largest key size). We can always introduce a fixed-group dh kex method with a larger modulus later. Chances are that the implementations supporting the new fixed group are going to be the ones that support the support the stronger encryption algorithms. > I don't mind separating the one part from the other - I just mind > treating that second aspect of kex methods (the host key or gss mech) as > the same thing when they aren't obviously the same kind of thing. So, stating that something is ``obviously [not] the same kind of thing'' is not a useful way to communicate after we've had as many round trips as we have establishing that we see things differently. Can you explain why you believe this? > Alternatively, we could break the key exchange and the key exchange > authentication parts of kex apart and have a generic DH key exchange and > a generic message exchange for signing the DH key resulting from the DH > key exchange. That way we'd need but a single key exchange method (or > two, if the fixed-group (1 round-trip) vs. negotiated group (1.5 > round-trips) distinction is worth keeping) and a bunch of kex signature > exchange methods (ssh-*, pgp-*, ... gss-*). This may sound suspiciously > like Joel's proposal, but the innovation here lies in changing the > actual kex messages for the dh methods and getting rid of the gss kex > name. One of my goals was to avoid changing the actual key exchange protocols, and change only the KEXINIT message itself. I also suspect you'd end up adding a round trip or two in the GSSAPI case if you did this. > Earlier I proposed the use of "alias" alg names to cure some of the > ills with KEXINIT that would solve the preference expression problem > that Joel had. Ugh, but I suppose that could solve the problem. (If I end up with a client that does all of krb5, X.509, pgp, and bare host keys, I'll end up listing 8 distinct algorithms, probably, assuming each of those four types does both group1 and group-exchange. Plus at the end I'll end up listing diffie-hellman-group1 and diffie-hellman-group-exchange, for a total of ten. While this is ugly, it is difficult to argue that it is a problem; I don't know of any reason why listing ten algorithms will fail.) > We could also negotiate KEXINIT extensions through > the use of a bogus alg name. > > If we then define the semantics of the reserved field of KEXINIT we > could add a field to KEXINIT (w/o revving the protocol version) for > chaining hashes of failed kex messages through to the next KEXINIT so > that the resulting session ID is bound to all kex messages and bingo, > we've got secure re-triable kex w/ downgrade attack detection and w/o > having to go back and modify the way each kex method defines the > session ID hash. Right now, each kex method just includes the packet that negotiated the algorithm usage in the hash. The amount of code required to use KEXINIT2 when KEXINIT2 is used is almost certainly less than this chaining proposal. And this bogus algorithm name also strikes me as likely to add complexity. > > > 3) The language optional field as it exists goes away. > > Why? I agree that we don't need two sets of lang fields > (server-to-client and client-to-server). But we need a language > negotiation for G11N. And it has to happen _before_ userauth, and if it > can be piggy-backed onto the kex then you save a round-trip - funny, > that's how it is now, and it works too. Because I want to treat it as just another optional field that has a field name label, rather than having its mere presence there imply that it is what it is. I certainly want the language field content to remain just as expressible as it is now. (And shifting to only one field rather than two was a mistake that came from not reading the draft carefully enough to realize there were two, not from intending a change.) > > Basically, the general idea is to create a new series of "magic" keyex > > algorithm names (hm.. I see a theme here). These would look something > > like XX:diffie-hellman-group1-sha1:ssh-dss, with the 'XX:' a constant > > defined in the spec. There are some problems with this approach, which I > > haven't yet had time to fully research; that's why I hadn't yet brought up > > the idea. But I'd much rather see a mechanism that allows negotiation of > > { keyex, host-key } tuples rather than simply switching the order, which > > doesn't eliminate the existence of a multi-level negotiation. How does this interact with key exchange mechanisms and host key mechanisms that contain at signs? I think we need to figure out whether the problem of having extra optional fields available is actually worth solving. At one point I thought it would be useful for SSH_MSG_KEXGSS_HOSTKEY public key algorithm negotiation, but I no longer believe it is needed for that. This leaves me feeling like I understand how to solve some problem that might exist, without knowing what problem it solves. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 19 02:20:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06720 for ; Sat, 19 Jul 2003 02:20:40 -0400 (EDT) Received: (qmail 5234 invoked by uid 605); 19 Jul 2003 06:20:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5227 invoked from network); 19 Jul 2003 06:20:40 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 19 Jul 2003 06:20: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 h6J6KZE6005387; Sat, 19 Jul 2003 00:20:35 -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 h6J6KZbO016382; Sat, 19 Jul 2003 00:20: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 h6J6HOQx007889; Fri, 18 Jul 2003 23:17:24 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6J6HNNB007888; Fri, 18 Jul 2003 23:17:23 -0700 (PDT) Date: Fri, 18 Jul 2003 23:17:23 -0700 From: Nicolas Williams To: "Joel N. Weber II" Cc: Jeffrey Hutzelman , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030719061722.GI6374@binky.central.sun.com> References: <20030719021742.GA7369@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Jul 19, 2003 at 01:55:07AM -0400, Joel N. Weber II wrote: > > I do have a problem with it. The reason the current KEXINIT sucks is > > that it negotiates two important aspects of the ultimate kex method > > independently. While reversing the order of algorithm matching and > > treating the GSS-API mechanisms as "host key algorithms" would solve one > > problem we're dealing with I don't believe it to be a general solution. > > What problem do you believe would actually be solved by the solution > you're proposing that isn't solved by the solution I'm proposing? I > can see where you're proposing to introduce more generality, but I > don't see why anyone will ever benefit from that generality. Whoever designed KEXINIT did not foresee the problems we're running into now. Thus the desire to get the model right the second time. Though that may be moot since I am actually arguing that we ought to work with what we got anyways. > As I think I've said, it seems that you and jhutz think that someone > someday is going to have a burning desire to use group-exchange with > pgp and group1 with ssh-*, and I really don't see why that is going to > be especially useful. No, I'm thinking that the distinction between kex and host key is artificial and what we need is a distinction between kex method and kex authentication method. > > I don't mind separating the one part from the other - I just mind > > treating that second aspect of kex methods (the host key or gss mech) as > > the same thing when they aren't obviously the same kind of thing. > > So, stating that something is ``obviously [not] the same kind of > thing'' is not a useful way to communicate after we've had as many > round trips as we have establishing that we see things differently. > Can you explain why you believe this? I will have to sleep on it. Right now my thought is that we have a separate kex alg for gss and so separating the kex name from the gss mechanism name doesn't really change much (though taken with the change in alg selection that you propose it would). I think my argument boils down to this: if we're to introduce KEXINIT2 then we might as well fix it right, and that includes separating kex from kex auth, because even adding KEXINIT2 would be a lot of work and wouldn't be sufficiently general as proposed; the alternative is to hack, if you wish, around the limitations of KEXINIT in a backwards compatible way. > > Alternatively, we could break the key exchange and the key exchange [...] > > One of my goals was to avoid changing the actual key exchange > protocols, and change only the KEXINIT message itself. > > I also suspect you'd end up adding a round trip or two in the GSSAPI > case if you did this. No - the two exchanges could be done in parallel, with the MIC coming last. For 1-round-trip GSS mechanisms this means you can do the DH exchange and the GSS-API exchange and the exchange of the signature of the session ID all in one round-trip. Cool, eh? > > Earlier I proposed the use of "alias" alg names to cure some of the > > ills with KEXINIT that would solve the preference expression problem > > that Joel had. > > Ugh, but I suppose that could solve the problem. (If I end up with a > client that does all of krb5, X.509, pgp, and bare host keys, I'll end > up listing 8 distinct algorithms, probably, assuming each of those > four types does both group1 and group-exchange. Plus at the end I'll > end up listing diffie-hellman-group1 and > diffie-hellman-group-exchange, for a total of ten. While this is > ugly, it is difficult to argue that it is a problem; I don't know of > any reason why listing ten algorithms will fail.) Exactly. It ain't elegant, but it's not wasteful either, either of network resources or of WG reasources :) > > We could also negotiate KEXINIT extensions through > > the use of a bogus alg name. > > > > If we then define the semantics of the reserved field of KEXINIT we > > could add a field to KEXINIT (w/o revving the protocol version) for > > chaining hashes of failed kex messages through to the next KEXINIT so > > that the resulting session ID is bound to all kex messages and bingo, > > we've got secure re-triable kex w/ downgrade attack detection and w/o > > having to go back and modify the way each kex method defines the > > session ID hash. > > Right now, each kex method just includes the packet that negotiated > the algorithm usage in the hash. The amount of code required to use > KEXINIT2 when KEXINIT2 is used is almost certainly less than this > chaining proposal. And this bogus algorithm name also strikes me as > likely to add complexity. Why? If both the client and the server propose that bogus alg they know that if the first kex selected fails then they can retry and that the second try will have an extension field to the KEXINIT where the hash of the failed kex's messages will be included, or something to that effect. The point here is to avoid changing the definition of the channel ID hash, of which there are three currently, in three separate I-Ds. > > > > 3) The language optional field as it exists goes away. > > > > Why? I agree that we don't need two sets of lang fields > > (server-to-client and client-to-server). But we need a language > > negotiation for G11N. And it has to happen _before_ userauth, and if it > > can be piggy-backed onto the kex then you save a round-trip - funny, > > that's how it is now, and it works too. > > Because I want to treat it as just another optional field that has a > field name label, rather than having its mere presence there imply > that it is what it is. Ok, I can live with that. > I certainly want the language field content to remain just as > expressible as it is now. (And shifting to only one field rather than > two was a mistake that came from not reading the draft carefully > enough to realize there were two, not from intending a change.) Yes, but I'm afraid that having two was a mistake anyways, and the semantics of language negotiation are much too underspecified. > > > Basically, the general idea is to create a new series of "magic" keyex > > > algorithm names (hm.. I see a theme here). These would look something > > > like XX:diffie-hellman-group1-sha1:ssh-dss, with the 'XX:' a constant > > > defined in the spec. There are some problems with this approach, which I > > > haven't yet had time to fully research; that's why I hadn't yet brought up > > > the idea. But I'd much rather see a mechanism that allows negotiation of > > > { keyex, host-key } tuples rather than simply switching the order, which > > > doesn't eliminate the existence of a multi-level negotiation. > > How does this interact with key exchange mechanisms and host key > mechanisms that contain at signs? I don't know what Jeff had in mind, but in my proposal these would be aliases of existing kex methods - taken to be limited to subsets of the host key algorithms - so any implementors of non-standard kex methods would not be affected (and to take advantage of this they'd have to define their own aliases). > I think we need to figure out whether the problem of having extra > optional fields available is actually worth solving. At one point I > thought it would be useful for SSH_MSG_KEXGSS_HOSTKEY public key > algorithm negotiation, but I no longer believe it is needed for that. > This leaves me feeling like I understand how to solve some problem > that might exist, without knowing what problem it solves. You mean by adding "named" fields? Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 19 13:29:27 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18392 for ; Sat, 19 Jul 2003 13:29:27 -0400 (EDT) Received: (qmail 3029 invoked by uid 605); 19 Jul 2003 17:29:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3022 invoked from network); 19 Jul 2003 17:29:25 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 19 Jul 2003 17:29:25 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6JHTH9V029481; Sat, 19 Jul 2003 11:29:17 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6JHTGtK018057; Sat, 19 Jul 2003 13:29:16 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6JHTG8Q023166; Sat, 19 Jul 2003 13:29:16 -0400 (EDT) Message-Id: <200307191729.h6JHTG8Q023166@thunk.east.sun.com> From: Bill Sommerfeld To: Jeffrey Hutzelman cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: Your message of "Thu, 17 Jul 2003 22:39:23 +0200." Reply-to: sommerfeld@east.sun.com Date: Sat, 19 Jul 2003 13:29:16 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is your working group chair speaking. The sudden jump to discussion of problems with gss negotiation to the overall ssh protocol architecture has gone way faster than I could follow it in detail. We've skipped from a statement of the problem directly to discussing fundamental structural changes to ssh... So, I'd like to call for a general moratorium on such proposals until such time as we have a clear statement of why anything NEEDS to be changed, and a clear understaning of the requirements of any such change so we can figure out the path of least resistance. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 10:41:46 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29669 for ; Mon, 21 Jul 2003 10:41:44 -0400 (EDT) Received: (qmail 8978 invoked by uid 605); 21 Jul 2003 14:41:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8958 invoked from network); 21 Jul 2003 14:41:42 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 21 Jul 2003 14:41:42 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa08867; 21 Jul 2003 10:41 EDT Date: Mon, 21 Jul 2003 10:41:10 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Nicolas Williams cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: <20030719061722.GI6374@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 Fri, 18 Jul 2003, Nicolas Williams wrote: > On Sat, Jul 19, 2003 at 01:55:07AM -0400, Joel N. Weber II wrote: > > As I think I've said, it seems that you and jhutz think that someone > > someday is going to have a burning desire to use group-exchange with > > pgp and group1 with ssh-*, and I really don't see why that is going to > > be especially useful. Joel, I think you're failing to see the big picture. You seem to be seeing the multi-level negotiation problem only in terms of the mechanisms that exist today. You talk about wanting to prefer a traditional exchange with PGP-signed keys over GSS-krb5, and GSS-krb5 over an exchange with non-PGP-signed keys. That's all well and good, but you are proposing a "solution" which assumes that the _only_ alternative algorithm you'll ever want to put in the second slot is a GSS-based one, and fails to have any benefit in any other case. When I point this out, you seem to think I am thinking of some situation in which the second slot is occupied by diffie-hellman-group1-sha1 or group exchange, combined with pgp-* or ssh-* host keys. I am not. I am envisioning a situation in which the second slot is occupied by a yet-to-be-defined keyex algorithm, or perhaps an existing one which uses a yet-to-be-defined host key algorithm. Since both of these spaces are highly open to future extension, it is unacceptable to dismiss potential extensions as irrelevant. The problem is a general one, and requires a general solution. > No, I'm thinking that the distinction between kex and host key is > artificial and what we need is a distinction between kex method and kex > authentication method. I agree that this should have been done from the beginning, but even that is not sufficient. There are really three separate problems here, which existing keyex algorithms try to solve: (1) key exchange; that is, agreeing on a key for encrpyting the session. (2) authentication of the host, and binding this to the key exchange (3) secure transport of a host key from the host to the client. We've discussed a general solution to problem (3), involving a new message type that could be sent after key exchange is complete. I think we should explore that avenue further in another thread, and concentrate for now on problems (1) and (2). Currently, solutions to (1) and (2) are defined by every "key exchange" algorithm, which results in a lot of duplication. For example, it means that group exchange needs to be defined separately for every algorithm, as does the exchange hash. I agree that this is an unfortunate situation, and that it would be better had these operations been separate. However, I also feel that, for those host authentication algorithms which require the use of public-key encryption, it would be as inappropriate to bind the key type to the host authentication algorithm as it is to bind key exchange to that algorithm, or the symmetric cipher used for the session to the particular key exchange method used. Thus, if we wanted to do this right, we should negotiate key exchange, host authentication, and host key algorithms as separate entities. And of course, parameterization should be involved so as to avoid the multi-level negotiation problem. However, I also feel that it is _far_ too late to rearchitect the protocol to address this issue. Making this change would affect the core drafts as well as every keyex algorithm defined. It would require defining new auth-independent keyex algorithms, and new keyex-independent auth algorithms, which is a lot of text to write. And it would require changing existing implementations, which I'll bet no one wants to do. I'm having enough trouble getting vendors to adopt gsskeyex; imagine the difficulty of getting them to adopt a completely new keyex process with completely new algorithms. No, it is far too late. What I think we _can_ do is agree on a mechanism, either through the extension of KEXINIT or the addition of KEXINIT2, to negotiate tuples of { keyex algorithm, keyex restrictions }, where the format of keyex restrictions would be mostly keyex-specific but could include a restriction (preferably defined in a general way) on what host key algorithms could be used. Note that it is important IMHO that the restrictions field be used only to restrict the ways in which the keyex algorithm can be used, and not to arbitrarily parameterize it. Perhaps I'm being too picky on this point... > > > We could also negotiate KEXINIT extensions through > > > the use of a bogus alg name. > > > If we then define the semantics of the reserved field of KEXINIT we > > > could add a field to KEXINIT (w/o revving the protocol version) for > > > chaining hashes of failed kex messages through to the next KEXINIT so > > > that the resulting session ID is bound to all kex messages and bingo, > > > we've got secure re-triable kex w/ downgrade attack detection and w/o > > > having to go back and modify the way each kex method defines the > > > session ID hash. > > > > Right now, each kex method just includes the packet that negotiated > > the algorithm usage in the hash. The amount of code required to use > > KEXINIT2 when KEXINIT2 is used is almost certainly less than this > > chaining proposal. And this bogus algorithm name also strikes me as > > likely to add complexity. > > Why? If both the client and the server propose that bogus alg they know > that if the first kex selected fails then they can retry and that the > second try will have an extension field to the KEXINIT where the hash of > the failed kex's messages will be included, or something to that effect. > The point here is to avoid changing the definition of the channel ID > hash, of which there are three currently, in three separate I-Ds. Hm. On some reflection, I don't believe the bogus algorithm name is necessary to prevent a downgrade attack, nor do I believe that a KEXINIT2 message is required. It should be sufficient to define a non-zero value of the reserved field to indicate that additional fields follow. These fields should include advanced algorithm negotiation information (such as I described above, or whatever we end up agreeing on) and also a boolean to indicate whether keyex retries are supported. There is some question as to what to do with a keyex retry, and how to authenticate it. I don't see how KEXINIT2 helps us here, but I don't see how Nico's chaining proposal helps either. The KEXINIT message is constructed as part of the exchange hash, which is computed by each keyex algorithm when the exchange is complete. If key exchange fails, there is and can be no hash, and thus nothing to chain. I also don't believe it's necessary to repeat algorithm negotiation in the case of a retry -- just go on to the next algorithm in the selection process, as if the one that just failed had not been available. However, I do think we need a mechanism to signal keyex failure and the start of a retry, as well as to carry information about the failure. To this end, I will propose that when a keyex fails and retry is supported, a SSH_MSG_KEXFAIL message is sent, possibly containing information about what combination of algorithms failed. We can then assert that for the purposes of computing the exchange hash, "the SSH_MSG_KEXINIT message" actually consists of the concatenation of the KEXINIT message and all KEXFAIL messages sent as part of the same exchange. > > > > Basically, the general idea is to create a new series of "magic" keyex > > > > algorithm names (hm.. I see a theme here). These would look something > > > > like XX:diffie-hellman-group1-sha1:ssh-dss, with the 'XX:' a constant > > > > defined in the spec. There are some problems with this approach, which I > > > > haven't yet had time to fully research; that's why I hadn't yet brought up > > > > the idea. But I'd much rather see a mechanism that allows negotiation of > > > > { keyex, host-key } tuples rather than simply switching the order, which > > > > doesn't eliminate the existence of a multi-level negotiation. > > > > How does this interact with key exchange mechanisms and host key > > mechanisms that contain at signs? > > I don't know what Jeff had in mind, but in my proposal these would be > aliases of existing kex methods - taken to be limited to subsets of the > host key algorithms - so any implementors of non-standard kex methods > would not be affected (and to take advantage of this they'd have to > define their own aliases). Actually, my proposal was intended to model the semantics of Nico's (I'll freely admit that's where I got the idea), in which these new things are aliases of existing kex algorithms, with limitations on what host key algorithms could be used. However, I was going for a general solution, in which aliases would not have to be explicitly defined "by hand" for each possible combination -- IMHO this is always a good thing when the things being combined are defined independently, as keyex and host key algorithms are. In this context, Joel's question about the handling of '@' indeed makes sense. I don't yet have a good answer; probably the '@' would be mapped to some other character, such as '%', with a quoting mechanism for literal occurances of '%', ':', and whatever the quoting character is. Unfortunately, there is a fixed limit on algorithm name lengths, so I don't yet see how my proposal can work. I suppose we could have a model in which we use a hash if the concatenation is too long, but I'd prefer not to make implementations compute hashes of all the possible combinations just to see what the peer supports. Hm... How about something like 'XX:keyex-alg:hostkey-alg', where XX is again a constant, and keyex-alg and hostkey-alg are fixed-length hashes of the corresponding algorithm names. Then implementations could simply know the hashed names of all their supported algorithms in advance, and the search would become simple again. Of course, this is only needed if we choose to solve the multi-level problem in the context of the existing KEXINIT message, rather than adopting a new negotiation mechanism by extending the message or adding a new one. I do think the alias approach is far less complex... > > I think we need to figure out whether the problem of having extra > > optional fields available is actually worth solving. At one point I > > thought it would be useful for SSH_MSG_KEXGSS_HOSTKEY public key > > algorithm negotiation, but I no longer believe it is needed for that. Joel... Why is this? Is the solution of adding a transport message to be used for host key exchange after keyex is complete acceptable to you? > > This leaves me feeling like I understand how to solve some problem > > that might exist, without knowing what problem it solves. Indeed, while I thought the named-field idea was a good general extension mechanism when you proposed it, I'm not convinced it's necessary right now. Perhaps we should drop it, and focus exclusively on multi-level algorithm negotiation and the possibility of keyex retries... -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 11:27:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00817 for ; Mon, 21 Jul 2003 11:27:09 -0400 (EDT) Received: (qmail 1895 invoked by uid 605); 21 Jul 2003 15:27:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1888 invoked from network); 21 Jul 2003 15:27:09 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 21 Jul 2003 15:27:09 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa08893; 21 Jul 2003 11:23 EDT Date: Mon, 21 Jul 2003 11:23:34 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: Bill Sommerfeld cc: "Joel N. Weber II" , Nicolas.Williams@sun.com, jhutz+@cmu.edu, ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: <200307191729.h6JHTG8Q023166@thunk.east.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, 19 Jul 2003, Bill Sommerfeld wrote: > So, I'd like to call for a general moratorium on such proposals until > such time as we have a clear statement of why anything NEEDS to be > changed, and a clear understaning of the requirements of any such > change so we can figure out the path of least resistance. OK; that's fair enough. I think we have been discussing four basic problems, and have even come to agreement on solutions for two of them. Allow me to recap somewhat, and then we can decide where to go from here. (1) It is desirable for GSS-API key exchange to be able to proceed even when the server has no host key and the user's credentials have expired. This is particularly important in the case of a rekey, where a failure means the session will be disconnected. Ken Hornstein reports that this problem is causing difficulties for him in deploying ssh in his environment. Joel Weber proposed a solution to this, in the form of an individual internet-draft submission, draft-weber-secsh-pkalg-none-00.txt. This proposal defines a new hostkey algorithm, to be used only during rekey, whose semantics amount to not actually performing any signature checking or encryption operations. While there was some initial concern, people eventually realized that the rekey operation would be protected by the existng encryption. It was then agreed, at least among those who spoke up, that this should be rolled into the gsskeyex draft. (2) Currently, when key exchange fails for any reason, the session is disconnected and a client which wishes to try another key exchange method must reconnect and try again. This has the disadvantage that any negotiation performed as part of the first connection is lost, and particularly that the sequence of negotiations and failures that lead to the ultimate selection of a key exchange algorithm and host key are not properly authenticated. To solve this problem, it has been proposed that key exchange be allowed to fail and be retried without disconnection, using a method that would allow the complete process to be properly authenticated. Exactly how to do this is under discussion, but it would likely involve a new message to be used when keyex fails, combined with one of (a) a rev in the protocol version, (b) a backward-compatible change to the format of the SSH_MSG_KEXINIT message, or (c) a new message to be used in place of SSH_MSG_KEXINIT. I believe it is generally agreed that (a) is not acceptable. (3) There is a multi-level negotiation issue involving the negotiation of keyex and host key algorithms. These are currently listed and selected almost as if they were independent, when in fact that are not; in particular, a client must choose and express its order of preference for key exchange algorithms without regard to what host key algorithm will be used. This makes it impossible to express cases like that described by Joel Weber, in which one would prefer to use a traditional DH algorithm (either group1 or group exchange) with a pgp-* host key, but failing that, to try a mechanism like GSS-krb5 before falling back on DH using an ssh-* host key. IMHO, this is clearly the issue with the most contention with regard to finding a solution. There are three separate proposals under discussion: (a) Joel Weber's proposal of turning GSSAPI key exchange into a single keyex algorithm with multiple host key types, and simultaneously reversing the order of selection such that the host key type is selected before keyex algorithm. This involves a change in semantics which would be signalled by one of the methods described in (2)(a), (b), or (c) above; again, I believe it is generally agreed that (2)(a) is not acceptable. (b) Nico Williams' proposal of inventing "alias" names for keyex algorithms, which would be negotiated in the usual way but would carry with them the semantics of being restricted to particular host key types. I expanded on this to propose a general way of constructing alias names, rather than requiring them to be registered individually for each { keyex, host key } tuple for which they are to be used. (c) The third proposal (whose origin I can't recall, but it might have been myself or Nico Williams) is to exchange a list of { keyex, restrictions } tuples, where restrictions might include host key algorithms or other parameters. This would involve a change in the way in which this information is exchanged, using one of the methods described in (2)(b) or (2)(c) above. (4) It is desirable under certain circumstances to securely transmit to the client a host key which was not used to authenticate the key exchange; particularly, a key not known to the client in advance. This is useful for bootstrapping a client's host key database using a preexisting authentication infrastructure (PGP, PKI, Kerberos, DNSSEC, etc), and also for allowing "rollover" when a host decides to change its long-term key (Ken Hornstein points out that some sites have policies which require long-term keys to be changed on a regular basis). The GSSAPI-based key exchange algorithms provide an optional mechanism for this, by allowing the transport of a host key belonging to the algorithm selected in the first steps of key exchange, and including that key in the exchange hash. However, a more general solution is desired, which would allow multiple keys to be transported, as well as allowing the transport of additional host keys when using keyex algorithms other than the GSSAPI-based ones. My original proposal was to create a host key pseudo-algorithm which would actually carry a list of keys, and perform encryption and signature operations as with the first key. I have since withdrawn that proposal, in favor of one proposed by Nico Williams, in which a new message type is defined which can be used to transport arbitrary host keys once the key exchange has been completed and new keys have been taken into use. I believe the problem described in (1) is well-understood, and the solution is fairly clean. Barring any further discussion or objections from the working group (which has been mostly silent on this), I will be incorporating Joel's solution into the description of the 'null' host key algorithm in the next version of the gsskeyex document. I also believe the problem described in (4) is well-understood, and the solution is again appropriate and fairly clean. However, I think some further work is required to nail down the details. I will probably contact Nico offline about preparing an internet-draft to document this proposal. (2) and (3) both involve significant changes to the protocol. I believe these can both be done as backward-compatible extensions without holding up the core drafts. However, I also agree that we should carefully consider whether these problems are worth solving, particularly given the amount of work required to specify them properly, evaluate the security implications, and implement and test the changes. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 12:08:49 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02098 for ; Mon, 21 Jul 2003 12:08:48 -0400 (EDT) Received: (qmail 22580 invoked by uid 605); 21 Jul 2003 16:08:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22573 invoked from network); 21 Jul 2003 16:08:47 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 21 Jul 2003 16:08:47 -0000 Received: by xanthine.gratuitous.org with local; Mon, 21 Jul 2003 12:08:43 -0400 From: "Joel N. Weber II" To: Jeffrey Hutzelman CC: Nicolas Williams , ietf-ssh@NetBSD.org In-reply-to: (message from Jeffrey Hutzelman on Mon, 21 Jul 2003 10:41:10 -0400 (EDT)) Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) References: Message-Id: Date: Mon, 21 Jul 2003 12:08:43 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list [since my understanding is that Bill has asked us to not discuss how to solve the problems we are trying to solve until we figure out what problems we are trying to solve, there are some parts of your message that I am not replying to here.] > Joel, I think you're failing to see the big picture. You seem to be > seeing the multi-level negotiation problem only in terms of the mechanisms > that exist today. You talk about wanting to prefer a traditional exchange > with PGP-signed keys over GSS-krb5, and GSS-krb5 over an exchange with > non-PGP-signed keys. That's all well and good, but you are proposing a > "solution" which assumes that the _only_ alternative algorithm you'll ever > want to put in the second slot is a GSS-based one, and fails to have any > benefit in any other case. I don't think that's true. I even mentioned a hypothetical example involving an srp kex algorithm when I said ``here's a list of possible kex algorithms and ``host key'' algoithms; if we invert the order of negotiation, why won't my proposal work?'' > When I point this out, you seem to think I am thinking of some situation > in which the second slot is occupied by diffie-hellman-group1-sha1 or > group exchange, combined with pgp-* or ssh-* host keys. I am not. I am > envisioning a situation in which the second slot is occupied by a > yet-to-be-defined keyex algorithm, or perhaps an existing one which uses a > yet-to-be-defined host key algorithm. Since both of these spaces are > highly open to future extension, it is unacceptable to dismiss potential > extensions as irrelevant. The problem is a general one, and requires a > general solution. What sort of new requirements do you think we'd get using a new host key algorithm with an existing key exchange algorithm that provide different problems than negotiating PGP vs X.509 vs a bare ssh host key? As far as I can guess, while the future is very much open to new host key algorithms in this space, the problems in negotiating them shouldn't be any different than what we have with the current algorithms. And what sort of new requirements do you expect would exist with new host key algorithms? If you could give a concrete example of a hypothetical new algorithm, even if it had a few properties which were rather contrived, and explain why it would have substantially different negotiation requirements, I'd probably have an easier time understanding. I think at some point in the past I may have also pointed out that the current multilevel approach doesn't do the right thing if you introduce key exchange algorithms that support encryption rather than signing keys, and pgp-encrypt-dss, ssh-encrypt-dss, etc, and that switching the host key vs key exchange algorithm order ought to fix the problems with that, too. Of course, I'm assuming that the thing you care about primarily is being able to pick the most trusted trusted-third-party scheme, since in practice host key verification seems to be the weak link. I just got thinking that another question we might consider is what happens when you have an ssh server that wants to provide multiple X.509 keys, each signed by a different CA. (Last time I dealt with a well-known CA, I distintively remember them not handling the private key, but let's hypothetically assume a world where the CA hands you the private key and the public key; it's probably a good thought experiment for understanding what problem we're trying to solve if we're going for generalization. And I'm also not sure if the X.509 standard allows you to get your cert signed by more than one CA.) I could imagine solutions involving an extra field to negotiate which CA to use; or creating x509v3-sign-rsa-verisign, x509v3-sign-rsa-thawte, x509v3-sign-rsa@joelweber.com, etc, though I don't think either of these schemes is necessarily ideal. The latter at least could be done in a way that doesn't require any changes to the negotiating infrastructure. I'm starting to think that the last paragraph may be an argument in favor of doing a KEXFAIL message with a reason code, where the reason code indicates what kind of retry to do. Because for some failure modes, retrying the same thing with a different key is an option. In the extreme case, consider a GSSAPI mechanism where both the client and the server have alternate credentials. I don't think that KEXINIT has much hope of being the right way to efficiently negotiate what to retry when in that case. > Currently, solutions to (1) and (2) are defined by every "key exchange" > algorithm, which results in a lot of duplication. For example, it means > that group exchange needs to be defined separately for every algorithm, as > does the exchange hash. I agree that this is an unfortunate situation, > and that it would be better had these operations been separate. However, > I also feel that, for those host authentication algorithms which require > the use of public-key encryption, it would be as inappropriate to bind the > key type to the host authentication algorithm as it is to bind key > exchange to that algorithm, or the symmetric cipher used for the session > to the particular key exchange method used. Why is it inappropriate to bind the public key algorithm to the key exchange algorithm, yet appropriate to bind a GSSAPI mechanism to a key exchange algorithm? > > > I think we need to figure out whether the problem of having extra > > > optional fields available is actually worth solving. At one point I > > > thought it would be useful for SSH_MSG_KEXGSS_HOSTKEY public key > > > algorithm negotiation, but I no longer believe it is needed for that. > > Joel... Why is this? Is the solution of adding a transport message to be > used for host key exchange after keyex is complete acceptable to you? Yes, a transport message to deal with that is acceptable to me, but it was fairly recently that I realized that it was a valid option. Indeed, I believe that I will end up wanting to define such a message for PGP regardless of what GSSAPI ends up doing, though if it's possible to use the same message for both (and I believe it is) I'd like to do so. (In practice, I believe that openssh has bugs such that we probably want to recommend that you wait until after you've established a connection with the userauth service before sending that transport message, but I believe the IETF spec ought to allow its use anytime after SSH_MSG_NEWKEYS.) > > > This leaves me feeling like I understand how to solve some problem > > > that might exist, without knowing what problem it solves. > > Indeed, while I thought the named-field idea was a good general extension > mechanism when you proposed it, I'm not convinced it's necessary right > now. Perhaps we should drop it, and focus exclusively on multi-level > algorithm negotiation and the possibility of keyex retries... Probably. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 12:15:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02265 for ; Mon, 21 Jul 2003 12:15:28 -0400 (EDT) Received: (qmail 26190 invoked by uid 605); 21 Jul 2003 16:15:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26165 invoked from network); 21 Jul 2003 16:15:29 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 21 Jul 2003 16:15:29 -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 h6LGFLoF020657; Mon, 21 Jul 2003 09:15:21 -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 h6LGFKbO017177; Mon, 21 Jul 2003 10:15:20 -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 h6LGC8Qx008978; Mon, 21 Jul 2003 09:12:08 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6LGC7DP008977; Mon, 21 Jul 2003 09:12:07 -0700 (PDT) Date: Mon, 21 Jul 2003 09:12:07 -0700 From: Nicolas Williams To: Bill Sommerfeld Cc: Jeffrey Hutzelman , "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: KEX problems Message-ID: <20030721161202.GA8960@binky.central.sun.com> References: <200307191729.h6JHTG8Q023166@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307191729.h6JHTG8Q023166@thunk.east.sun.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Sat, Jul 19, 2003 at 01:29:16PM -0400, Bill Sommerfeld wrote: > So, I'd like to call for a general moratorium on such proposals until > such time as we have a clear statement of why anything NEEDS to be > changed, and a clear understaning of the requirements of any such > change so we can figure out the path of least resistance. There are two, well, three problems that we've been discussing. These are all related only in that they have something to do with key exchanges. The problem statement: A. Key Exchange and Host Authentication Preference Expressibility This is a very unlikely problem that occurs under the following circumstances: - the client can support the use of three or more host authentication infrastructures and - at least two of those host authentication infrastructures are based on public key based using the dh-group1-sha1 or dh-group-exchange-sha1 key exchange methods and - at least one of those host authentication infrastructures is not based on host public keys usable with the dh-group1-sha1 or dh-group-exchange-sha1 key exchange methods The problem then is that some preferences cannot be expressed with the current KEXINIT message and algorithm negotiation algorithm. One example given to the list was one where the client wishes to offer the following preference: - diffie-hellman-group1-sha1 w/ pgp-* host keys - gss-group1-sha1-* - diffie-hellman-group1-sha1 w/ ssh-* host keys IMO, the proximate causes of this problem is the conflation of raw key exchange methods (DH) with host authentication methods (e.g., ssh-rsa, pgp-dss, x509v3-sign-rsa, ...) and the expectation that all host authentication methods would be based on public key cryptosystems. Thus draft-ietf-secsh-gsskeyex defines its own key exchange method which is based on DH because the ones defined in the transport I-D are not appropriate since there is no way to fit in the GSS-API to authenticate the server. A separate gss-group-exchange-sha1-* key exchange method will eventually be needed also, adding more duplication This too is a result of the conflation of key exchange and host authentication methods in draft-ietf-secsh-transport. A generic key exchange method based on DH plus a generic message exchange for server authentication would have allowed both, the use of public keys and the use of the GSS-API to authenticate the server to the client and prove that there's no man-in-the-middle. It is years too late to consider this in any way other than academically. I do not propose that we solve this problem by starting from scratch. In fact, I do not propose solving this problem unless we also want to solve (B) - see below. B. Key Exchange Should be Re-Triable SSHv2 clients and servers must commit to undertaking a single initial key exchange method per-connection and disconnect if that method fails. In the case of public key / certificate based host authentication algorithms the client might well refuse to accept the server's keys once the client knows what they are, but by then the key exchange cannot be re-tried. This problem too is unlikely (though I myself have experienced it plenty, mostly in situations where a server had multiple identities but the server's GSS-API implementation did not support the full range of GSS_C_NO_CREDENTIAL/GSS_C_NO_NAME semantics and the SSHv2 server software did not fully support virtualization). C. Distribution of Authenticated Servers' Other Keys Draft-ietf-secsh-gsskeyex allows servers to send one, and only one public host key to clients protected by the gss-group1-sha1-... key exchange. The I-D should have allowed for hosts to tell clients of all their host keys - but then, this feature should be not be specific to the GSS key exchange method, it should be available in all cases after key exchange succeeds. IMO, problem (B) is the problem most worth solving, but it requires extending the key exchange phase of the protocol, one way or another. IMO, problem (C) is the simplest to solve and does not require modifying the key exchange part of the protocol. IMO, problem (A) is the problem least worth solving, but if we solve (B) then we should consider solving (A) as well. IMO, problems (A) and (B) can be solve backwards compatibly through extensions to the KEXINIT message (see its 'reserved' field). For this we'd need draft-ietf-secsh-transport to have some text describing the meta-semantics KEXINIT extensions and their negotiation so that problems (A) and (B) can be solved in a separate I-D. I will submit a last call comment on this point. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 12:20:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02420 for ; Mon, 21 Jul 2003 12:20:12 -0400 (EDT) Received: (qmail 28656 invoked by uid 605); 21 Jul 2003 16:20:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28649 invoked from network); 21 Jul 2003 16:20:14 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 21 Jul 2003 16:20:14 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6LGKBCW019132; Mon, 21 Jul 2003 10:20:11 -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 h6LGK9cm021014; Mon, 21 Jul 2003 10:20:10 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6LGGtQx008992; Mon, 21 Jul 2003 09:16:56 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6LGGtGH008991; Mon, 21 Jul 2003 11:16:55 -0500 (CDT) Date: Mon, 21 Jul 2003 11:16:55 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: Jeffrey Hutzelman , "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: KEX problems Message-ID: <20030721161655.GA8918@binky.central.sun.com> References: <200307191729.h6JHTG8Q023166@thunk.east.sun.com> <20030721161202.GA8960@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030721161202.GA8960@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list I missed Jeff's post on the same topic. My apologies. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 12:44:57 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03140 for ; Mon, 21 Jul 2003 12:44:56 -0400 (EDT) Received: (qmail 13713 invoked by uid 605); 21 Jul 2003 16:44:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13706 invoked from network); 21 Jul 2003 16:44:56 -0000 Received: from dsl093-061-085.pit1.dsl.speakeasy.net (HELO mariner.pc.cs.cmu.edu) (66.93.61.85) by mail.netbsd.org with SMTP; 21 Jul 2003 16:44:56 -0000 Received: from mariner.pc.cs.cmu.edu ([127.0.0.1]) by mariner.pc.cs.cmu.edu id aa09159; 21 Jul 2003 12:44 EDT Date: Mon, 21 Jul 2003 12:44:22 -0400 (EDT) From: Jeffrey Hutzelman X-X-Sender: To: "Joel N. Weber II" cc: Nicolas Williams , ietf-ssh@NetBSD.org MMDF-Warning: Parse error in original version of preceding line at mariner.pc.cs.cmu.edu Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, 21 Jul 2003, Joel N. Weber II wrote: > I don't think that's true. I even mentioned a hypothetical example > involving an srp kex algorithm when I said ``here's a list of possible > kex algorithms and ``host key'' algoithms; if we invert the order of > negotiation, why won't my proposal work?'' Because your proposal depends on the thing in the second slot being something that uses a "fake" host key algorithm instead of a real one. Note that GSSAPI-based and SRP keyex mechanisms currently negotiate a _real_ hostkey algorithm; if you change the process out from under them then this functionality goes away. > What sort of new requirements do you think we'd get using a new host > key algorithm with an existing key exchange algorithm that provide > different problems than negotiating PGP vs X.509 vs a bare ssh host > key? As far as I can guess, while the future is very much open to new > host key algorithms in this space, the problems in negotiating them > shouldn't be any different than what we have with the current > algorithms. That's probably true, which is why I prefer to concentrate on the case of potential new key exchange algorithms, which may be significantly different from what we know about now. However, the point is not that new host key algorithms might have particular requirements as that people might be willing to use certain keyex algorithms only with a suitably "strong" host key algorithm. > I think at some point in the past I may have also pointed out that > the current multilevel approach doesn't do the right thing if you > introduce key exchange algorithms that support encryption rather than > signing keys, and pgp-encrypt-dss, ssh-encrypt-dss, etc, and that > switching the host key vs key exchange algorithm order ought to fix > the problems with that, too. I'm not sure I see how it's a problem. Can you elaborate on why the current model causes a problem here? > Of course, I'm assuming that the thing > you care about primarily is being able to pick the most trusted > trusted-third-party scheme, since in practice host key verification > seems to be the weak link. Ah, but I think you're making an invalid assumption. While host key verification is important, so is selection of a key exchange algorithm that is suitably secure (and here by "key exchange", I mean it in the ssh sense, where it includes the method used to bind a host's authentication to the exchanged key). Back when people assumed all keyex algorithms would do basically the same thing (do an exchange and sign it with a host's public key), the two seemed independent. But in reality they are not, as algorithms like the GSS and SRP ones have taught us. I don't think reversing the order makes anything better; it means we still have a multi-layer negotiation problem; we have just inverted the order of the layers. > I just got thinking that another question we might consider is what > happens when you have an ssh server that wants to provide multiple > X.509 keys, each signed by a different CA. (Last time I dealt with a > well-known CA, I distintively remember them not handling the private > key, but let's hypothetically assume a world where the CA hands you > the private key and the public key; it's probably a good thought > experiment for understanding what problem we're trying to solve if > we're going for generalization. And I'm also not sure if the X.509 > standard allows you to get your cert signed by more than one CA.) I > could imagine solutions involving an extra field to negotiate which CA > to use; or creating x509v3-sign-rsa-verisign, x509v3-sign-rsa-thawte, > x509v3-sign-rsa@joelweber.com, etc, though I don't think either of > these schemes is necessarily ideal. The latter at least could be done > in a way that doesn't require any changes to the negotiating > infrastructure. Hm; this is an interesting problem. I think the current theory is that the host sends you its key along with all the signatures. But if it has to select which key to send you on the basis of what CA's you'll accept, then it won't work. There's also an identity problem here, in that a host may need to decide which key and certs to send you based on what identity you think it has. TLS has this problem today... > I'm starting to think that the last paragraph may be an argument in > favor of doing a KEXFAIL message with a reason code, where the reason > code indicates what kind of retry to do. Because for some failure > modes, retrying the same thing with a different key is an option. In > the extreme case, consider a GSSAPI mechanism where both the client > and the server have alternate credentials. I don't think that KEXINIT > has much hope of being the right way to efficiently negotiate what to > retry when in that case. I think I agree that if we handle the retry problem at all, there is some complexity in deciding at what level to retry. Probably we should put that off until the WG has decided whether the problem is worth solving. > > Currently, solutions to (1) and (2) are defined by every "key exchange" > > algorithm, which results in a lot of duplication. For example, it means > > that group exchange needs to be defined separately for every algorithm, as > > does the exchange hash. I agree that this is an unfortunate situation, > > and that it would be better had these operations been separate. However, > > I also feel that, for those host authentication algorithms which require > > the use of public-key encryption, it would be as inappropriate to bind the > > key type to the host authentication algorithm as it is to bind key > > exchange to that algorithm, or the symmetric cipher used for the session > > to the particular key exchange method used. > > Why is it inappropriate to bind the public key algorithm to the key > exchange algorithm, yet appropriate to bind a GSSAPI mechanism to a > key exchange algorithm? I think you misunderstood my intent. In Nico's ideal world where "key exchange" and "host authentication" are separate steps, there's no reason that any particular key exchange and host authentication algorithms should be bound together. What I was suggesting above was that while it would be good for "key exchange" and "host auth" to be separate, that doesn't mean that for "host auth" types that use a public key, the public key algorithm should be a function of the "host auth" type, any more than the symmetric key algorithms we negotiate today are a function of the algorithm we use to exchange them, or vice versa. Please note that GSSAPI is not magically interchangeable with other host key types. Even in your hypothetical world where GSS mechanisms are represented as host key types, you couldn't use one with dffie-hellman-group1-sha1 -- GSS requires context establishment, which could potentially take multiple round trips, before you can sign or encrypt anything. I guess what I'm saying is that it's not appropriate to bind GSSAPI to a "key exchange" in the sense of the independent anonymous-DH-or-whatever that would exist in Nico's ideal world. But in the world we have today, where key exchange and host authentication happen in the same place, it is impossible not to bind key exchange and host authentication together. And GSS-API must be bound to a particular host authentication method, because that is what defines the wire protocol bits that allow for GSS context establishment. So, I think we've argued on this issue more than enough. Let's take a step back and answer the question of whether the multi-level negotiation problem is worth solving at all. I don't think I know the answer to that yet. If the concensus is that it should be solved, then we can discuss how. So... Do we believe this problem is worth solving? If so, how simple does the solution need to be to be worthwhile? Does an alias-based solution meet our needs? If not, are new messages the only alternative? If so, is that solution acceptable, or too complex to be worthwhile? > Yes, a transport message to deal with that is acceptable to me, but it > was fairly recently that I realized that it was a valid option. > Indeed, I believe that I will end up wanting to define such a message > for PGP regardless of what GSSAPI ends up doing, though if it's > possible to use the same message for both (and I believe it is) I'd > like to do so. GSSAPI has a mechanism for dealing with this within the key exchange, for a single key. I think we're talking about a general solution now. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 13:34:36 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04737 for ; Mon, 21 Jul 2003 13:34:35 -0400 (EDT) Received: (qmail 22129 invoked by uid 605); 21 Jul 2003 17:34:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22122 invoked from network); 21 Jul 2003 17:34:33 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 21 Jul 2003 17:34:33 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6LHYXoF010621 for ; Mon, 21 Jul 2003 10:34:33 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6LHYWtK014571 for ; Mon, 21 Jul 2003 13:34:32 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6LHYW8Q007213 for ; Mon, 21 Jul 2003 13:34:32 -0400 (EDT) Message-Id: <200307211734.h6LHYW8Q007213@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: Issue Tracking "Last Call" In-Reply-To: Your message of "Tue, 15 Jul 2003 17:03:36 EDT." <200307152103.h6FL3a8Q002777@thunk.east.sun.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 21 Jul 2003 13:34:32 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Having heard no substantive comments one way or the other, I'll be setting up RT, with write access to the queue from the chair and current document editors of working group items. Active document editors who want write access should send me the email address they want registered with the ticketing system as their account name; I'll send them on in a batch to the admins. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 17:21:17 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11211 for ; Mon, 21 Jul 2003 17:21:16 -0400 (EDT) Received: (qmail 18826 invoked by uid 605); 21 Jul 2003 21:21:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18817 invoked from network); 21 Jul 2003 21:21:16 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 21 Jul 2003 21:21:16 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa11139; 21 Jul 2003 17:20 EDT Date: Mon, 21 Jul 2003 17:20:56 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: KEX problems Message-ID: <142100000.1058822456@minbar.fac.cs.cmu.edu> In-Reply-To: <20030721161202.GA8960@binky.central.sun.com> References: <200307191729.h6JHTG8Q023166@thunk.east.sun.com> <20030721161202.GA8960@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, July 21, 2003 09:12:07 -0700 Nicolas Williams wrote: I'm glad that we pretty much agree on what the problems are. You seem to have omitted the rekey-without-host-key problem, which I called problem (1), probably because it's only peripherally relevant to this discussion. I would like to hear more comments from people as to whether problem (1) is worth solving and whether the solution I described (rolling the semantics of Joel Weber's 'none' hostkey algorithm into the 'null' already described in the gsskeyex document) is the correct solution. I believe the answers to both questions are "yes", but confirmation would be nice. I think I need to disagree with you slightly on priorities for the other problems... > IMO, problem (B) is the problem most worth solving, but it requires > extending the key exchange phase of the protocol, one way or another. IIRC this is what I called problem (2), the keyex retry problem. I'm not sure whether it occurs often enough to be worth solving; I'd love to hear comments from people other than you, me, and Joel on this point. I do agree that solving it requires extending the keyex protocol, probably along one of the three general paths I described in my message, none of which are terribly appealing to me. I believe the bar to be passed before solving this problem should be rather high. > IMO, problem (C) is the simplest to solve and does not require modifying > the key exchange part of the protocol. Well, no disagreement here. Of the three problems you listed, this is clearly the simplest to solve, and I think we have already achieved concensus both that this is worth solving, and that the general approach we've discussed is correct. Hopefully we'll have an I-D in short order, and people can comment on whether the specifics are right. I would like some opinion from the WG members and the chair as to whether this should be a working group item or not. > IMO, problem (A) is the problem least worth solving, but if we solve (B) > then we should consider solving (A) as well. This is the multi-level algorithm negotiation problem, which I called problem (3). I can only partially agree here... If we solve (B), we should certainly consider solving (A), since it's clearly possible to do so if we're extending the key exchange anyway. However, I think it may also be possible to solve (A) without modifying the key exchange mechanism, by using an alias-based approach. If such a solution is sufficiently simple and actually meets the need, then I think the bar should be significantly lower than for a solution which requires modifying or extending the key exchange. > IMO, problems (A) and (B) can be solve backwards compatibly through > extensions to the KEXINIT message (see its 'reserved' field). For this > we'd need draft-ietf-secsh-transport to have some text describing the > meta-semantics KEXINIT extensions and their negotiation so that problems > (A) and (B) can be solved in a separate I-D. I will submit a last call > comment on this point. Agree. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 18:20:55 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13536 for ; Mon, 21 Jul 2003 18:20:55 -0400 (EDT) Received: (qmail 23837 invoked by uid 605); 21 Jul 2003 22:20:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23830 invoked from network); 21 Jul 2003 22:20:56 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 21 Jul 2003 22:20:56 -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 h6LMKuUg023830 for ; Mon, 21 Jul 2003 15:20:56 -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 h6LMKtcm008404 for ; Mon, 21 Jul 2003 16:20:55 -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 h6LMHgQx009132 for ; Mon, 21 Jul 2003 15:17:42 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6LMHgWU009131 for ietf-ssh@NetBSD.org; Mon, 21 Jul 2003 15:17:42 -0700 (PDT) Date: Mon, 21 Jul 2003 15:17:42 -0700 From: Nicolas Williams To: ietf-ssh@NetBSD.org Subject: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030721221742.GI8917@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list The transport I-D defines the SSH_MSG_KEXINIT message: byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string mac_algorithms_client_to_server string mac_algorithms_server_to_client string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client boolean first_kex_packet_follows uint32 0 (reserved for future extension) Nothing is said about the semantics of the last field. Can implementors describe how they handle non-zero values for the last field of SSH_MSG_KEXINIT? I propose the following change: - Name the last field of KEXINIT "extensions": byte SSH_MSG_KEXINIT byte[16] cookie (random bytes) string kex_algorithms string server_host_key_algorithms string encryption_algorithms_client_to_server string encryption_algorithms_server_to_client string mac_algorithms_client_to_server string mac_algorithms_server_to_client string compression_algorithms_client_to_server string compression_algorithms_server_to_client string languages_client_to_server string languages_server_to_client boolean first_kex_packet_follows uint32 extensions - Describe the 'extensions' field and the semantics of extensions negotiation: extensions Currently MUST always be set to zero (0). If set to zero this is the last item in this packet. Future extensions to SSH_MSG_KEXINIT may be defined by IETF RFCs which specify non-zero values for this field and add fields to the end of the packet. Receipients MUST ignore any items in SSH_MSG_KEXINIT packets past this field that if they do not know the extensions value. ["Implementations must be careful to include the entire SSH_MSG_KEXINIT packets in the session ID hash, not just the fields they know about." ??] Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 18:27:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13688 for ; Mon, 21 Jul 2003 18:27:29 -0400 (EDT) Received: (qmail 29067 invoked by uid 605); 21 Jul 2003 22:27:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29060 invoked from network); 21 Jul 2003 22:27:30 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 21 Jul 2003 22:27:30 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6LMRUbj006691 for ; Mon, 21 Jul 2003 16:27:30 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6LMRTtK017718 for ; Mon, 21 Jul 2003 18:27:29 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6LMRT8Q018072 for ; Mon, 21 Jul 2003 18:27:29 -0400 (EDT) Message-Id: <200307212227.h6LMRT8Q018072@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Re: Secure Shell WG: Issue Tracking "Last Call" In-Reply-To: Your message of "Mon, 21 Jul 2003 13:34:32 EDT." Reply-to: sommerfeld@east.sun.com Date: Mon, 21 Jul 2003 18:27:29 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Okay, RT tracking is now set up and I've created tickets reflecting the state of most of the current WG documents. You can reach the tracker at http://rt.psg.com (intro page) or https://rt.psg.com (direct entry to the database). We're using the "secsh" queue (duh!) Subject conventions: docname: issue summary i.e., newmodes: resolve algorithm set RT allows for issues to have "parents". I've created a bunch of docname: need to finish issues, assigned to me, as parents for document-specific issues. I have not yet created tickets for either: a) any of the extended filexfer discussions of the past couple months b) any of the recent gsskeyex discussions. As I mentioned earlier today, active document editors who want write access should send me the email address they want registered with the ticketing system as their account name; I'll send them on in a batch to the admins. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 18:43:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13956 for ; Mon, 21 Jul 2003 18:43:08 -0400 (EDT) Received: (qmail 11118 invoked by uid 605); 21 Jul 2003 22:43:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11107 invoked from network); 21 Jul 2003 22:43:05 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 21 Jul 2003 22:43:05 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6LMh1Ug007370; Mon, 21 Jul 2003 15:43:01 -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 h6LMh0bO001279; Mon, 21 Jul 2003 16:43: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 h6LMdlQx009144; Mon, 21 Jul 2003 15:39:47 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6LMdlFo009143; Mon, 21 Jul 2003 15:39:47 -0700 (PDT) Date: Mon, 21 Jul 2003 15:39:46 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: "Joel N. Weber II" , ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030721223943.GA9122@binky.central.sun.com> References: <20030719061722.GI6374@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jul 21, 2003 at 10:41:10AM -0400, Jeffrey Hutzelman wrote: > On Fri, 18 Jul 2003, Nicolas Williams wrote: > [...] > Hm. On some reflection, I don't believe the bogus algorithm name is > necessary to prevent a downgrade attack, nor do I believe that a KEXINIT2 > message is required. It should be sufficient to define a non-zero value > of the reserved field to indicate that additional fields follow. These > fields should include advanced algorithm negotiation information (such as > I described above, or whatever we end up agreeing on) and also a boolean > to indicate whether keyex retries are supported. Right, I've been toying with this. We need to have the transport I-D fixed to describe the semantics of the last field of KEXINIT. I just posted separately about that with proposed I-D changes. > There is some question as to what to do with a keyex retry, and how to > authenticate it. I don't see how KEXINIT2 helps us here, but I don't see > how Nico's chaining proposal helps either. The KEXINIT message is > constructed as part of the exchange hash, which is computed by each keyex > algorithm when the exchange is complete. If key exchange fails, there is > and can be no hash, and thus nothing to chain. I think we should proceed by: - describing the semantics of KEXINIT extensions (just posted on this) - extending KEXINIT in a separate I-D to include: - a field containing the checksum of the concatenation of previous packets relating to FAILED kex attempts (if any); this is where "chaining" comes in (and note that this checksum need not be specified on a per-kex method basis); - text stating that peers must not disconnect when kex fails if there remain any untried kex methods (including host key types); - a field for expressing kex/host key preferences as a list of tuples to override any values of the 'kex_algorithms' and 'server_host_key_algorithms' legacy fields of the KEXINIT. > I also don't believe it's necessary to repeat algorithm negotiation in the > case of a retry -- just go on to the next algorithm in the selection > process, as if the one that just failed had not been available. However, Correct. > I do think we need a mechanism to signal keyex failure and the start of a > retry, as well as to carry information about the failure. To this end, I > will propose that when a keyex fails and retry is supported, a > SSH_MSG_KEXFAIL message is sent, possibly containing information about I don't think this is necessary when keyex fails on the client side - it just should send a new [extended] KEXINIT. > what combination of algorithms failed. We can then assert that for the > purposes of computing the exchange hash, "the SSH_MSG_KEXINIT message" > actually consists of the concatenation of the KEXINIT message and all > KEXFAIL messages sent as part of the same exchange. I don't like the idea of modifying the existing session ID specifications because those are spread over three I-Ds and never envisioned that the session ID hash specs would change. Whereas including a hash of the failed key exchange method's packets in subsequent kex attempts results in binding the failed attempts to the subsequent attempts without having to change the actual kex methods. I much prefer the latter as it will result in a cleaner document. [...] > > I don't know what Jeff had in mind, but in my proposal these would be > > aliases of existing kex methods - taken to be limited to subsets of the > > host key algorithms - so any implementors of non-standard kex methods > > would not be affected (and to take advantage of this they'd have to > > define their own aliases). > > Actually, my proposal was intended to model the semantics of Nico's (I'll > freely admit that's where I got the idea), in which these new things are > aliases of existing kex algorithms, with limitations on what host key > algorithms could be used. However, I was going for a general solution, in > which aliases would not have to be explicitly defined "by hand" for each > possible combination -- IMHO this is always a good thing when the things > being combined are defined independently, as keyex and host key algorithms > are. :) Details. We want to negotiate tuples - how we encode them is not very important right now (and "dh-group1-sha1-pgp-sign-dss" is really an encoding for {"dh-group1-sha1", "pgp-sign-dss"}). > In this context, Joel's question about the handling of '@' indeed makes > sense. I don't yet have a good answer; probably the '@' would be mapped > to some other character, such as '%', with a quoting mechanism for literal > occurances of '%', ':', and whatever the quoting character is. I think we can come up with a tuple encoding that preserves @ signs. Again, details. > Unfortunately, there is a fixed limit on algorithm name lengths, so I > don't yet see how my proposal can work. I suppose we could have a model > in which we use a hash if the concatenation is too long, but I'd prefer > not to make implementations compute hashes of all the possible > combinations just to see what the peer supports. Hm... With a new field for negotiating kex/host key type tuples the length issue can go away. > > > This leaves me feeling like I understand how to solve some problem > > > that might exist, without knowing what problem it solves. > > Indeed, while I thought the named-field idea was a good general extension > mechanism when you proposed it, I'm not convinced it's necessary right > now. Perhaps we should drop it, and focus exclusively on multi-level > algorithm negotiation and the possibility of keyex retries... The reason named fields are a good ide here is that we may only have ONE shot at using the reserved uint32 last field of KEXINIT (once there are several values defined for it, not just two, the semantics of KEXINIT extensions negotiation become more complex...). Of course, we could just keep appending an extensions field to every KEXINIT extension, to avoid this problem. :) :) Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 19:25:37 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14747 for ; Mon, 21 Jul 2003 19:25:36 -0400 (EDT) Received: (qmail 5926 invoked by uid 605); 21 Jul 2003 23:25:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5888 invoked from network); 21 Jul 2003 23:25:38 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 21 Jul 2003 23:25:38 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6LNPaFu010833 for ; Mon, 21 Jul 2003 17:25:36 -0600 (MDT) Message-ID: <006701c34fdf$288df880$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: References: Subject: Re: Publickey subsystem draft posted Date: Mon, 21 Jul 2003 17:23:56 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-1.3 required=10.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Darren, Sorry for the delay responding to your comments. > In the introduction you say: > > This protocol requires that the user be able to authenticate in some > fashion before it can be used. If password authentication is used, > servers SHOULD provide a configuration option to disable the use of > password authentication after the first public key is added. > > > While I support the intent of this the functionality seems like it would > actually be more appropriate for one of the core drafts rather than this one. It seems to me that the core drafts are pretty well closed up at this point. I'm not sure yet if I understand completely why some language like this would be inappropriate in this document. I'd be happy to see it changed to "MAY provide a configuration option...". I could also see rephrasing it to not specifically mention password authentication. Otherwise this seems pretty innocuous. > > > 3.2 Adding a public key > > If the client wishes to add a public key, the client sends: > > string "add" > string comment > string public-key algorithm name > string public-key blob > > The server MUST attempt to store the public key for the user in the > appropriate location so the public key can be used for subsequent > public-key authentications. > > The comment field contains user-specified text about the public key > and MAY be empty. > > > I'd like to see text added to say that the server is not supposed to > interpret the comment in any way and is NOT required to preserve it for > subsequent return in a list command. Sounds good. But, I do think it would be nice to have a statement that indicates that returning the comment in a list would be helpful to users trying to distinguish keys from each other in a listing (other than by looking at fingerprints). > > 3.4 Listing public keys > > If the client wishes to list the known public keys, the client sends: > > string "list" > > The server will respond with zero or more of the following responses: > > string "publickey" > string comment > string public-key algorithm name > string public-key blob > > The comment field contains user-specified text about the public key > and MAY be empty. > > Following the last "publickey" response, a status packet MUST be > sent. > > An implementation MAY choose not to support this request. > > How long is the client supposed to wait for the server to send the > status packet to say it is done ? On one hand I'd say that how long a client decides to wait could be implementation dependent. I suppose some implementations might simply hang until the status packet comes through assuming that a user would cancel or interrupt the whole thing... I see your point though. I believe one of the reasons we chose to have a bunch of 'list' responses followed by a 'status' response was that we found it easy to parse. > > I would have expected the server to send a packed more like this: > > string "publickey-list" > uint32 number of following public keys > string comment > string public-key algorithm name > string public-key blob > .... and so on upto uint32 number of keys > > OR something like > > string "publickey-list" > uint32 number of following public keys > > then send the publickeys in the packet format you defined in 3.4 > > Telling the client how many keys are comming would probably be helpful > for implementers building a UI to display this info. --Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Mon Jul 21 19:40:25 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15006 for ; Mon, 21 Jul 2003 19:40:24 -0400 (EDT) Received: (qmail 13742 invoked by uid 605); 21 Jul 2003 23:40:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13733 invoked from network); 21 Jul 2003 23:40:25 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 21 Jul 2003 23:40:25 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa11411; 21 Jul 2003 19:40 EDT Date: Mon, 21 Jul 2003 19:40:00 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <33940000.1058830800@minbar.fac.cs.cmu.edu> In-Reply-To: <20030721223943.GA9122@binky.central.sun.com> References: <20030719061722.GI6374@binky.central.sun.com> <20030721223943.GA9122@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, July 21, 2003 15:39:46 -0700 Nicolas Williams wrote: > On Mon, Jul 21, 2003 at 10:41:10AM -0400, Jeffrey Hutzelman wrote: >> There is some question as to what to do with a keyex retry, and how to >> authenticate it. I don't see how KEXINIT2 helps us here, but I don't see >> how Nico's chaining proposal helps either. The KEXINIT message is >> constructed as part of the exchange hash, which is computed by each keyex >> algorithm when the exchange is complete. If key exchange fails, there is >> and can be no hash, and thus nothing to chain. > > I think we should proceed by: > > - describing the semantics of KEXINIT extensions (just posted on this) > > - extending KEXINIT in a separate I-D to include: > > - a field containing the checksum of the concatenation of previous > packets relating to FAILED kex attempts (if any); this is where > "chaining" comes in (and note that this checksum need not be > specified on a per-kex method basis); I'm not totally convinced. It can't be a fixed algorithm; there has to be an upgrade path so we don't get screwed if the algorithm we choose turns out to be broken. IMHO the simplest way to handle this is by just allowing the keyex to checksum the concatenation of the whole mess at the end, but maybe you have a better idea. Is it necessary to record the complete set of messages exchanged? I guess it probably is, since otherwise the attacker could DoS a better keyex out of the way to get at a worse one. > - text stating that peers must not disconnect when kex fails if > there remain any untried kex methods (including host key types); MUST NOT is too strong, I think. I'd be happy with a SHOULD NOT, with the idea being that you either disconnect or send a retry message, with a strong preference for the latter. > - a field for expressing kex/host key preferences as a list of > tuples to override any values of the 'kex_algorithms' and > 'server_host_key_algorithms' legacy fields of the KEXINIT. Yes. >> I do think we need a mechanism to signal keyex failure and the start of a >> retry, as well as to carry information about the failure. To this end, I >> will propose that when a keyex fails and retry is supported, a >> SSH_MSG_KEXFAIL message is sent, possibly containing information about > > I don't think this is necessary when keyex fails on the client side - it > just should send a new [extended] KEXINIT. I'm not sure. I'd have to consider the semantics of this carefully, to make sure we don't have a deadlock. I think you're probably right, but I'll have to reread the transport document. >> what combination of algorithms failed. We can then assert that for the >> purposes of computing the exchange hash, "the SSH_MSG_KEXINIT message" >> actually consists of the concatenation of the KEXINIT message and all >> KEXFAIL messages sent as part of the same exchange. > > I don't like the idea of modifying the existing session ID > specifications because those are spread over three I-Ds and never > envisioned that the session ID hash specs would change. I'm fine with chaining, as long as you can show me a reasonable way to determine what hash algorithm to use. > Details. We want to negotiate tuples - how we encode them is not very > important right now (and "dh-group1-sha1-pgp-sign-dss" is really an > encoding for {"dh-group1-sha1", "pgp-sign-dss"}). Agreed. A better question is, can we solve the problem adequately using an encoding that fits everything into the existing key exchange process, or do we have to extend it. I believe this has a significant impact on whether the work is too complex to be worthwhile, and on whether we will be able to get implementors to adopt it. > The reason named fields are a good ide here is that we may only have ONE > shot at using the reserved uint32 last field of KEXINIT (once there are > several values defined for it, not just two, the semantics of KEXINIT > extensions negotiation become more complex...). Of course, we could > just keep appending an extensions field to every KEXINIT extension, to > avoid this problem. :) :) I guess I was thinking in terms of defining the extensions field as a sort of sub-version, which grows as more extension fields are added. Yes, this means the extension mechanism can only be used by IETF consensus. That does not strike me as a problem in this case. :-) -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 00:25:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19168 for ; Tue, 22 Jul 2003 00:25:27 -0400 (EDT) Received: (qmail 18328 invoked by uid 605); 22 Jul 2003 04:25:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18321 invoked from network); 22 Jul 2003 04:25:24 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 22 Jul 2003 04:25:24 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6M4PHCW004500; Mon, 21 Jul 2003 22:25:17 -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 h6M4PHcm025474; Mon, 21 Jul 2003 22:25:17 -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 h6M4M4Qx009354; Mon, 21 Jul 2003 21:22:04 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6M4M3g9009353; Mon, 21 Jul 2003 21:22:03 -0700 (PDT) Date: Mon, 21 Jul 2003 21:22:03 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org Subject: Re: KEX problems Message-ID: <20030722042159.GA9346@binky.central.sun.com> References: <200307191729.h6JHTG8Q023166@thunk.east.sun.com> <20030721161202.GA8960@binky.central.sun.com> <142100000.1058822456@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <142100000.1058822456@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jul 21, 2003 at 05:20:56PM -0400, Jeffrey Hutzelman wrote: > On Monday, July 21, 2003 09:12:07 -0700 Nicolas Williams > wrote: I too am glad to see that we're mostly in agreement. > >IMO, problem (B) is the problem most worth solving, but it requires > >extending the key exchange phase of the protocol, one way or another. > > IIRC this is what I called problem (2), the keyex retry problem. I'm not > sure whether it occurs often enough to be worth solving; I'd love to hear You need only have two kex methods (in any permutation with host key algs) to trigger this problem from time to time. Whereas you need at least three for problem (A), at least two of which must be the traditional kex methods, and at least one of which must not. I think (B) is much more likely than (A) - and I have experienced it myself; I have never experienced (A). > comments from people other than you, me, and Joel on this point. I do > agree that solving it requires extending the keyex protocol, probably along > one of the three general paths I described in my message, none of which are > terribly appealing to me. I believe the bar to be passed before solving > this problem should be rather high. I agree, but I think we MUST fix the transport I-D wrt KEXINIT extensibility. If we do that now then we can wait till later to solve (A) and/or (B). > [...] Yes, you can solve (A) with aliases. You can also solve (B) with the "bogus" alg name approach (and modifying the session ID specs to include the failed kex attempt's messages in the session ID hash). Before we do either we really ought to fix the transport I-D wrt KEXINIT extensibility, and in the process find out what implementations do today about extended KEXINITs. Though I've proposed the alg aliases/bogus alg approach I think extending KEXINIT is the right approach and the clean approach. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 05:44:45 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07343 for ; Tue, 22 Jul 2003 05:44:45 -0400 (EDT) Received: (qmail 4044 invoked by uid 605); 22 Jul 2003 09:44:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3999 invoked from network); 22 Jul 2003 09:44:35 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 22 Jul 2003 09:44:35 -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 h6M9eiOc014315; Tue, 22 Jul 2003 11:40:48 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id E5C972D041; Tue, 22 Jul 2003 11:41:14 +0200 (CEST) Date: Tue, 22 Jul 2003 11:41:14 +0200 From: Markus Friedl To: Nicolas Williams Cc: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030722094114.GA20491@folly> References: <20030721221742.GI8917@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030721221742.GI8917@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jul 21, 2003 at 03:17:42PM -0700, Nicolas Williams wrote: > Can implementors describe how they handle non-zero values for the last > field of SSH_MSG_KEXINIT? OpenSSH will accept non-zero values for the reserved uint32 value, but will not allow more data after this field. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 06:07:00 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07819 for ; Tue, 22 Jul 2003 06:07:00 -0400 (EDT) Received: (qmail 19324 invoked by uid 605); 22 Jul 2003 10:07:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19310 invoked from network); 22 Jul 2003 10:07:00 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 22 Jul 2003 10:07:00 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6MA6xoY011014; Tue, 22 Jul 2003 22:06:59 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6MA6xF23834; Tue, 22 Jul 2003 22:06:59 +1200 Date: Tue, 22 Jul 2003 22:06:59 +1200 Message-Id: <200307221006.h6MA6xF23834@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: markus@openbsd.org, Nicolas.Williams@sun.com Subject: Re: Transport I-D: KEXINIT reserved field needs description Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Markus Friedl writes: >On Mon, Jul 21, 2003 at 03:17:42PM -0700, Nicolas Williams wrote: >>Can implementors describe how they handle non-zero values for the last >>field of SSH_MSG_KEXINIT? > >OpenSSH will accept non-zero values for the reserved uint32 value, but will >not allow more data after this field. Same for cryptlib. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 06:11:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07891 for ; Tue, 22 Jul 2003 06:11:12 -0400 (EDT) Received: (qmail 21399 invoked by uid 605); 22 Jul 2003 10:11:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21392 invoked from network); 22 Jul 2003 10:11:13 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Jul 2003 10:11:13 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6MAB9bj021492; Tue, 22 Jul 2003 04:11:09 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MAB8tK011066; Tue, 22 Jul 2003 06:11:08 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6MAB88Q023737; Tue, 22 Jul 2003 06:11:08 -0400 (EDT) Message-Id: <200307221011.h6MAB88Q023737@thunk.east.sun.com> From: Bill Sommerfeld To: pgut001@cs.auckland.ac.nz (Peter Gutmann) cc: markus@openbsd.org, Nicolas.Williams@sun.com, ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description In-Reply-To: Your message of "Tue, 22 Jul 2003 22:06:59 +1200." <200307221006.h6MA6xF23834@medusa01.cs.auckland.ac.nz> Reply-to: sommerfeld@east.sun.com Date: Tue, 22 Jul 2003 06:11:08 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > >OpenSSH will accept non-zero values for the reserved uint32 value, but will > >not allow more data after this field. > > Same for cryptlib. What's the detailed behavior? suddenly drop the connection? drop the connection after sending an error packet? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 06:14:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07951 for ; Tue, 22 Jul 2003 06:14:41 -0400 (EDT) Received: (qmail 23525 invoked by uid 605); 22 Jul 2003 10:14:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23517 invoked from network); 22 Jul 2003 10:14:41 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 22 Jul 2003 10:14:41 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 438CE567F; Tue, 22 Jul 2003 12:14:27 +0200 (CEST) Message-ID: <3F1D0F10.9000407@siliconcircus.com> Date: Tue, 22 Jul 2003 12:16:48 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com Cc: Peter Gutmann , markus@openbsd.org, Nicolas.Williams@sun.com, ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description References: <200307221011.h6MAB88Q023737@thunk.east.sun.com> In-Reply-To: <200307221011.h6MAB88Q023737@thunk.east.sun.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 Bill Sommerfeld wrote: >>>OpenSSH will accept non-zero values for the reserved uint32 value, but will >>>not allow more data after this field. >> >>Same for cryptlib. > > > What's the detailed behavior? suddenly drop the connection? drop the > connection after sending an error packet? PenguiNet will allow any value in the reserved field and silently ignore any additional data in the packet. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 06:30:57 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08462 for ; Tue, 22 Jul 2003 06:30:57 -0400 (EDT) Received: (qmail 2848 invoked by uid 605); 22 Jul 2003 10:30:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2841 invoked from network); 22 Jul 2003 10:30:58 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 22 Jul 2003 10:30:58 -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 h6MAR5Oc017071; Tue, 22 Jul 2003 12:27:05 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id A3F452D041; Tue, 22 Jul 2003 12:27:35 +0200 (CEST) Date: Tue, 22 Jul 2003 12:27:35 +0200 From: Markus Friedl To: Bill Sommerfeld Cc: Peter Gutmann , Nicolas.Williams@sun.com, ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030722102735.GB974@folly> References: <200307221006.h6MA6xF23834@medusa01.cs.auckland.ac.nz> <200307221011.h6MAB88Q023737@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307221011.h6MAB88Q023737@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 22, 2003 at 06:11:08AM -0400, Bill Sommerfeld wrote: > > >OpenSSH will accept non-zero values for the reserved uint32 value, but will > > >not allow more data after this field. > > > > Same for cryptlib. > > What's the detailed behavior? suddenly drop the connection? drop the > connection after sending an error packet? yes, OpenSSH will send a SSH2_MSG_DISCONNECT/SSH2_DISCONNECT_PROTOCOL_ERROR error message and close the connection. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 06:31:18 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08487 for ; Tue, 22 Jul 2003 06:31:17 -0400 (EDT) Received: (qmail 3196 invoked by uid 605); 22 Jul 2003 10:31:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3189 invoked from network); 22 Jul 2003 10:31:18 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 22 Jul 2003 10:31:18 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6MATboY011478; Tue, 22 Jul 2003 22:29:37 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6MATbQ24035; Tue, 22 Jul 2003 22:29:37 +1200 Date: Tue, 22 Jul 2003 22:29:37 +1200 Message-Id: <200307221029.h6MATbQ24035@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: sommerfeld@east.sun.com Subject: Re: Transport I-D: KEXINIT reserved field needs description Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: >>>OpenSSH will accept non-zero values for the reserved uint32 value, but will >>>not allow more data after this field. >> >>Same for cryptlib. > >What's the detailed behavior? suddenly drop the connection? drop the >connection after sending an error packet? Send a handshake-failed indication and drop the connection. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 09:17:40 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12496 for ; Tue, 22 Jul 2003 09:17:39 -0400 (EDT) Received: (qmail 12096 invoked by uid 605); 22 Jul 2003 13:17:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12089 invoked from network); 22 Jul 2003 13:17:38 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 22 Jul 2003 13:17:38 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6MDHbCW029703; Tue, 22 Jul 2003 07:17:38 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MDHbtK004953; Tue, 22 Jul 2003 09:17:37 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6MDHX8Q024859; Tue, 22 Jul 2003 09:17:33 -0400 (EDT) Message-Id: <200307221317.h6MDHX8Q024859@thunk.east.sun.com> From: Bill Sommerfeld To: "Brent McClure" cc: ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted In-Reply-To: Your message of "Mon, 21 Jul 2003 17:23:56 MDT." <006701c34fdf$288df880$4900a8c0@galb.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 22 Jul 2003 09:17:33 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > > While I support the intent of this the functionality seems like it would > > actually be more appropriate for one of the core drafts rather than this one. > > It seems to me that the core drafts are pretty well closed up at this point. > I'm not sure yet if I understand completely why some language like this > would be inappropriate in this document. I'd be happy to see it changed > to "MAY provide a configuration option...". I could also see rephrasing it > to not specifically mention password authentication. Otherwise this > seems pretty innocuous. there is no strong requirement that the document boundaries exactly match the implementation boundaries. as a quality of implementation issue it seems like the "disable password once a public key is registered" should be enforced on a user-by-user basis (some users may haev a need to be able use passwords even when a public key is present) which suggests to me that the feature description touches both parts and could end up in either place... > > I'd like to see text added to say that the server is not supposed to > > interpret the comment in any way and is NOT required to preserve it for > > subsequent return in a list command. > > Sounds good. But, I do think it would be nice to have a statement > that indicates that returning the comment in a list would be helpful > to users trying to distinguish keys from each other in a listing > (other than by looking at fingerprints). [wg chair hat off..] For what it's worth, the management UI guy who sits next to me really seems to like this sort of thing and i'm inclined to take his word for it. However, as long-lived user-visible text, you've just invoked the full complexity of I18N: All user-visible text fields must be internationalizable See RFC 2277. For most cases, this means UTF-8. If text fields are included in some calculation, like matching, sorting etc, it must be described in detail how those operations are applied to the Unicode/ISO 10646 character set. see "stringprep" for more information on the recommended way of handling comparisons. I think the case we want to worry about is -- what happens when you get a client from mars which registers a key with a comment in martian, then a client from venus connects to the same account and registers a comment in venusian.. you need to tag each comment with an appropriate language: quoting from 2277: Protocols that transfer text MUST provide for carrying information about the language of that text. Protocols SHOULD also provide for carrying information about the language of names, where appropriate. Note that this does NOT mean that such information must always be present; the requirement is that if the sender of information wishes to send information about the language of a text, the protocol provides a well-defined way to carry this information. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 10:02:39 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13685 for ; Tue, 22 Jul 2003 10:02:38 -0400 (EDT) Received: (qmail 13626 invoked by uid 605); 22 Jul 2003 14:02:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13619 invoked from network); 22 Jul 2003 14:02:38 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Jul 2003 14:02:38 -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 h6ME2WFt015812; Tue, 22 Jul 2003 08:02:32 -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 h6ME2Wcm016926; Tue, 22 Jul 2003 08:02:32 -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 h6MDxIQx009527; Tue, 22 Jul 2003 06:59:18 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6MDxIeO009526; Tue, 22 Jul 2003 06:59:18 -0700 (PDT) Date: Tue, 22 Jul 2003 06:59:18 -0700 From: Nicolas Williams To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) Message-ID: <20030722135914.GA9522@binky.central.sun.com> References: <20030719061722.GI6374@binky.central.sun.com> <20030721223943.GA9122@binky.central.sun.com> <33940000.1058830800@minbar.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <33940000.1058830800@minbar.fac.cs.cmu.edu> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jul 21, 2003 at 07:40:00PM -0400, Jeffrey Hutzelman wrote: > On Monday, July 21, 2003 15:39:46 -0700 Nicolas Williams > wrote: > > >I don't like the idea of modifying the existing session ID > >specifications because those are spread over three I-Ds and never > >envisioned that the session ID hash specs would change. > > I'm fine with chaining, as long as you can show me a reasonable way to > determine what hash algorithm to use. First extended KEXINIT pair of messages has no chained checksum - it would have to have a field for negotiation of hash functions. > >Details. We want to negotiate tuples - how we encode them is not very > >important right now (and "dh-group1-sha1-pgp-sign-dss" is really an > >encoding for {"dh-group1-sha1", "pgp-sign-dss"}). > > Agreed. A better question is, can we solve the problem adequately using an > encoding that fits everything into the existing key exchange process, or do > we have to extend it. I believe this has a significant impact on whether > the work is too complex to be worthwhile, and on whether we will be able to > get implementors to adopt it. Agreed. This is the crucial decision we'll have to make. > I guess I was thinking in terms of defining the extensions field as a sort > of sub-version, which grows as more extension fields are added. Yes, this > means the extension mechanism can only be used by IETF consensus. That > does not strike me as a problem in this case. :-) Ok. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 10:05:58 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14000 for ; Tue, 22 Jul 2003 10:05:58 -0400 (EDT) Received: (qmail 16812 invoked by uid 605); 22 Jul 2003 14:05:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16501 invoked from network); 22 Jul 2003 14:05:50 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 22 Jul 2003 14:05:50 -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 h6ME5oxk001063; Tue, 22 Jul 2003 07:05:50 -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 h6ME5ncm017883; Tue, 22 Jul 2003 08:05: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 h6ME2aQx009536; Tue, 22 Jul 2003 07:02:36 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6ME2ZfS009535; Tue, 22 Jul 2003 07:02:35 -0700 (PDT) Date: Tue, 22 Jul 2003 07:02:35 -0700 From: Nicolas Williams To: Brent McClure Cc: ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted Message-ID: <20030722140235.GB9522@binky.central.sun.com> References: <006701c34fdf$288df880$4900a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <006701c34fdf$288df880$4900a8c0@galb.vandyke.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jul 21, 2003 at 05:23:56PM -0600, Brent McClure wrote: > > 3.4 Listing public keys > > > > If the client wishes to list the known public keys, the client sends: > > > > string "list" > > > > The server will respond with zero or more of the following responses: > > > > string "publickey" > > string comment > > string public-key algorithm name > > string public-key blob > > > > The comment field contains user-specified text about the public key > > and MAY be empty. > > > > Following the last "publickey" response, a status packet MUST be > > sent. > > > > An implementation MAY choose not to support this request. > > > > How long is the client supposed to wait for the server to send the > > status packet to say it is done ? > > On one hand I'd say that how long a client decides to wait could > be implementation dependent. I suppose some implementations might > simply hang until the status packet comes through assuming that > a user would cancel or interrupt the whole thing... > > I see your point though. I believe one of the reasons we chose to > have a bunch of 'list' responses followed by a 'status' response > was that we found it easy to parse. If you want to keep to one packet per-listed key then you could add a bit to the packet to indicate whether more are coming or not... Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 10:16:48 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15114 for ; Tue, 22 Jul 2003 10:16:47 -0400 (EDT) Received: (qmail 24411 invoked by uid 605); 22 Jul 2003 14:16:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24404 invoked from network); 22 Jul 2003 14:16:46 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Jul 2003 14:16:46 -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 h6MEGkFt024421; Tue, 22 Jul 2003 08:16: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 h6MEGjcm022775; Tue, 22 Jul 2003 08:16: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 h6MEDWQx009547; Tue, 22 Jul 2003 07:13:32 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6MEDVEf009546; Tue, 22 Jul 2003 07:13:31 -0700 (PDT) Date: Tue, 22 Jul 2003 07:13:31 -0700 From: Nicolas Williams To: Brent McClure Cc: ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted Message-ID: <20030722141331.GC9522@binky.central.sun.com> References: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list I think this subsystem should model some of the pubkey restrictions implemented by OpenSSH and others. E.g., "this key can use the sftp subsystem but cannot forward any ports." Some such restrictions may be platform specific and therefore do not belong in your I-D. But certainly some are generic. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 10:18:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15166 for ; Tue, 22 Jul 2003 10:18:27 -0400 (EDT) Received: (qmail 25476 invoked by uid 605); 22 Jul 2003 14:18:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25466 invoked from network); 22 Jul 2003 14:18:26 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 22 Jul 2003 14:18:26 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6MEIPxk008569 for ; Tue, 22 Jul 2003 07:18:25 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6MEIPfM008590 for ; Tue, 22 Jul 2003 10:18:25 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6MEIO8Q025154 for ; Tue, 22 Jul 2003 10:18:24 -0400 (EDT) Message-Id: <200307221418.h6MEIO8Q025154@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: public key subsystem document. Reply-to: sommerfeld@east.sun.com Date: Tue, 22 Jul 2003 10:18:24 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Based on the nature and tone of the comments (nitpickers are out in force; no real architectural issues), looks like there's rough consensus that it should be a work item. If anyone disagrees, please speak up and explain why soon.. WG chair comments (please fix before resubmitting as draft-ietf-secsh-*): - I18N issue on comments (mentioned earlier); also needs cite to the relevant I18N RFC in the references section - no security considerations section! - nit: rename references section to "normative references." - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 10:22:24 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15222 for ; Tue, 22 Jul 2003 10:22:23 -0400 (EDT) Received: (qmail 28283 invoked by uid 605); 22 Jul 2003 14:22:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28274 invoked from network); 22 Jul 2003 14:22:21 -0000 Received: from adsl-64-123-27-105.dsl.austtx.swbell.net (HELO pyramid.twistedmatrix.com) (64.123.27.105) by mail.netbsd.org with SMTP; 22 Jul 2003 14:22:21 -0000 Received: from z3p by pyramid.twistedmatrix.com with local (Exim 3.35 #1 (Debian)) id 19ey1y-0003kK-00 for ; Tue, 22 Jul 2003 09:22:18 -0500 Date: Tue, 22 Jul 2003 09:22:18 -0500 From: Paul Swartz To: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030722142218.GA11857@pyramid.twistedmatrix.com> Mail-Followup-To: ietf-ssh@netbsd.org References: <200307221011.h6MAB88Q023737@thunk.east.sun.com> <3F1D0F10.9000407@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1D0F10.9000407@siliconcircus.com> User-Agent: Mutt/1.3.28i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 22, 2003 at 12:16:48PM +0200, Jon Bright wrote: > PenguiNet will allow any value in the reserved field and silently ignore > any additional data in the packet. Conch will also allow any value and ignore extra data. -p -- Paul Swartz (o_ http://www.twistedmatrix.com/users/z3p.twistd/ _o) //\ z3p@twistedmatrix.com /\\ V_/_ AIM: z3penguin _\_V-> From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 10:58:32 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16370 for ; Tue, 22 Jul 2003 10:58:32 -0400 (EDT) Received: (qmail 22758 invoked by uid 605); 22 Jul 2003 14:58:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22704 invoked from network); 22 Jul 2003 14:58:20 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 22 Jul 2003 14:58:20 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19eyak-0007vA-00; Tue, 22 Jul 2003 15:58:14 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> Subject: Re: Publickey subsystem draft posted Message-Id: Date: Tue, 22 Jul 2003 15:58:14 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Brent McClure wrote: > We've refreshed the individual draft of the "Secure Shell Public-Key > Subsystem". > The new draft is available here: [...] OK, here are some comments. I'm in favour of a protocol of this type existing, but I think this draft is going to need some work before it's useful. - You don't mention any kind of packet structure within the subsystem channel, like SFTP has. Is this deliberate? It looks at the moment as if the individual components of any given request (e.g. string "add", string comment, string algorithm, string pubkey blob) are sent straight to the subsystem without any overall length field. If that's correct and not simply a documentation error, it _completely_ destroys extensibility: if a subsystem receives any request with a name it doesn't recognise, then it cannot know how much of the following data belongs to that request, so after returning REQUEST_NOT_SUPPORTED it _can't_ resume parsing at the next request boundary. Without this basic extensibility property, what was the point of having request types described in an extensible string namespace at all? - Speaking of extensibility, I strongly support Nicolas Williams's comment that there already exist SSH server implementations supporting a greater range of public key options and restrictions than your draft specifies. Surely at the very least there ought to be some sort of extension mechanism within the "add" request type? - The "command" request is seriously under-specified. It does not mention whether the key in question is expected to have been added using "add" previously, or is added by the "command" request itself. * If the former, this is a security hazard if naively implemented: the _only_ way to set up a restricted key is by issuing "add" and then "command", but between those two requests, there is a window of opportunity in which someone possessing the private key can gain unrestricted access to the target account. Since restricted keys are typically keys you don't fully trust not to fall into enemy hands, there should never be such a window of opportunity. Therefore, an implementation MUST delay actually making the changes until the subsystem channel is closed or a subsequent synchronisation message is sent; this should be clearly specified. * If the latter, this would make far more sense to me, except that the comment field present in the "add" request is missing in the "command" request. Since I've already proposed an extensibility field in the "add" request, I'm tempted to suggest that "command" is a complete misfeature and ought to be implemented in terms of that instead. Cheers, Simon -- Simon Tatham These are my opinions. There are many like them but these ones are mine. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 11:01:00 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16500 for ; Tue, 22 Jul 2003 11:00:59 -0400 (EDT) Received: (qmail 24386 invoked by uid 605); 22 Jul 2003 15:01:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24376 invoked from network); 22 Jul 2003 15:00:59 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 22 Jul 2003 15:00:59 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1725502; Tue, 22 Jul 2003 09:00:58 -0600 Message-ID: <3F1D51AA.7010408@vandyke.com> Date: Tue, 22 Jul 2003 09:00:58 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Nicolas Williams CC: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description References: <20030721221742.GI8917@binky.central.sun.com> In-Reply-To: <20030721221742.GI8917@binky.central.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Nicolas Williams wrote: >The transport I-D defines the SSH_MSG_KEXINIT message: > > byte SSH_MSG_KEXINIT > byte[16] cookie (random bytes) > string kex_algorithms > string server_host_key_algorithms > string encryption_algorithms_client_to_server > string encryption_algorithms_server_to_client > string mac_algorithms_client_to_server > string mac_algorithms_server_to_client > string compression_algorithms_client_to_server > string compression_algorithms_server_to_client > string languages_client_to_server > string languages_server_to_client > boolean first_kex_packet_follows > uint32 0 (reserved for future extension) > >Nothing is said about the semantics of the last field. > >Can implementors describe how they handle non-zero values for the last >field of SSH_MSG_KEXINIT? > Currently, debug builds of VanDyke's implementation ASSERT that the value is 0, but since these builds are not shipped (as a general rule), I believe we are okay with the value being changed. >I propose the following change: > > - Name the last field of KEXINIT "extensions": > > byte SSH_MSG_KEXINIT > byte[16] cookie (random bytes) > string kex_algorithms > string server_host_key_algorithms > string encryption_algorithms_client_to_server > string encryption_algorithms_server_to_client > string mac_algorithms_client_to_server > string mac_algorithms_server_to_client > string compression_algorithms_client_to_server > string compression_algorithms_server_to_client > string languages_client_to_server > string languages_server_to_client > boolean first_kex_packet_follows > uint32 extensions > > - Describe the 'extensions' field and the semantics of extensions > negotiation: > > extensions > Currently MUST always be set to zero (0). If set to zero this > is the last item in this packet. Future extensions to > SSH_MSG_KEXINIT may be defined by IETF RFCs which specify > non-zero values for this field and add fields to the end of the > packet. Receipients MUST ignore any items in SSH_MSG_KEXINIT > packets past this field that if they do not know the extensions > value. > > ["Implementations must be careful to include the entire > SSH_MSG_KEXINIT packets in the session ID hash, not just the > fields they know about." ??] > > I do think we want the sentance clarifying that the entire KEX packet must be included in session id hash. Should it say key exchange hash instead? Since only the first key exchange hash becomes the session id. I assume we don't want to define the extension format now because of last call? We might be able to use the extensions field as a count field: boolean first_kex_packet_follows uint32 extension_count string extension_name[1] string extension_data[1] string extension_name[2] string extension_data[2] string extension_name[...] string extension_data[...] string extension_name[extension_count] string extension_data[extension_count] And give extension name the same semantics that is used else where in the document-- @dns name extendable. Remember, what is being extended here is algorithm negotiation, not (as the packet name might have you think) key exchange (well, key exchange algorithm is part of what is being negotiated.) So I think a flexible extension mechanism is called for. I.e., some of the things that might be negotiated here in the future might be: - hash algorithm for failed kex packets. - compatibility work arounds (My implementation is vandyke.com, and I've fixed bugs 1 & 2; if you were working around this bugs, please don't anymore.) - Capabilities announcement (I support packets > 35K; I support key exchange retry; etc., etc.) I wouldn't want to assume we are smart enough to anticipate all future needs, or that everyone's needs will actually need to be standardized by the IETF. By allowing extensibility, we prevent those people that have needs not met by the IETF from producing broken, non-complaint implementations. (I believe that people will produce implementations that meet their needs, whether they can do it and comply with the RFC or not.) But this is all probably discussion for a new I-D. Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 11:03:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16653 for ; Tue, 22 Jul 2003 11:03:56 -0400 (EDT) Received: (qmail 26842 invoked by uid 605); 22 Jul 2003 15:03:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26835 invoked from network); 22 Jul 2003 15:03:56 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 22 Jul 2003 15:03:56 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19eygF-00088E-00; Tue, 22 Jul 2003 16:03:55 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <20030721221742.GI8917@binky.central.sun.com> Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-Id: Date: Tue, 22 Jul 2003 16:03:55 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Nicolas Williams wrote: > Can implementors describe how they handle non-zero values for the last > field of SSH_MSG_KEXINIT? PuTTY ignores it, and will also tolerate extra stuff in the packet after it. Cheers, Simon -- Simon Tatham "I'm going to pull his head off. Ear by ear." - a games teacher From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 11:13:24 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16898 for ; Tue, 22 Jul 2003 11:13:23 -0400 (EDT) Received: (qmail 2508 invoked by uid 605); 22 Jul 2003 15:13:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2480 invoked from network); 22 Jul 2003 15:13:23 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 22 Jul 2003 15:13:23 -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 h6MFDMDZ026512; Tue, 22 Jul 2003 08:13:22 -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 h6MFDMcm013083; Tue, 22 Jul 2003 09:13:22 -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 h6MFA9Qx009571; Tue, 22 Jul 2003 08:10:09 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6MFA8Sx009570; Tue, 22 Jul 2003 08:10:08 -0700 (PDT) Date: Tue, 22 Jul 2003 08:10:08 -0700 From: Nicolas Williams To: Joseph Galbraith Cc: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030722151008.GN8917@binky.central.sun.com> References: <20030721221742.GI8917@binky.central.sun.com> <3F1D51AA.7010408@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1D51AA.7010408@vandyke.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 22, 2003 at 09:00:58AM -0600, Joseph Galbraith wrote: > Nicolas Williams wrote: > > ["Implementations must be careful to include the entire > > SSH_MSG_KEXINIT packets in the session ID hash, not just the > > fields they know about." ??] > > > > > I do think we want the sentance clarifying that the entire KEX packet must > be included in session id hash. Should it say key exchange hash instead? > Since only the first key exchange hash becomes the session id. Hmmm, doesn't matter much if it's "key exchange hash" or "session ID hash" since re-keying is protected anyways. But yes, it probably should say "key exchange hash." And of course, KEXINIT extensions should apply to re-keying as much as to the initial kex. > I assume we don't want to define the extension format now because of > last call? If we define the semantics of how we extedn KEXINIT we can let the core drafts progress and describe any KEXINIT extensions in subsequent I-Ds. > We might be able to use the extensions field as a count field: [...] > And give extension name the same semantics that is used else where in the > document-- @dns name extendable. This is like Joel's named fields proposal and it does sound reasonable to me, though in this form it does mean that the extensions field is a one-shot extension device, mitigated by the permanent extensibility of the named fields. > Remember, what is being extended here is algorithm negotiation, not > (as the packet name might have you think) key exchange (well, key exchange > algorithm is part of what is being negotiated.) Yes. > I wouldn't want to assume we are smart enough to anticipate all future > needs, or that everyone's needs will actually need to be standardized > by the IETF. Me neither. As long as any extension to KEXINIT leaves in extensible we should be ok. > By allowing extensibility, we prevent those people that have needs not > met by the IETF from producing broken, non-complaint implementations. A very strong argument for Joel's and your named fields proposals. > But this is all probably discussion for a new I-D. Indeed. A small amount of text will fix transport so we can fix KEXINIT later. Later is good too - we ought not hurry in this case, as long as we fix the transport I-D. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 11:37:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17612 for ; Tue, 22 Jul 2003 11:37:41 -0400 (EDT) Received: (qmail 13875 invoked by uid 605); 22 Jul 2003 15:37:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13868 invoked from network); 22 Jul 2003 15:37:41 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 22 Jul 2003 15:37:41 -0000 Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa13266; 22 Jul 2003 11:37 EDT Date: Tue, 22 Jul 2003 11:37:37 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: KEX problems Message-ID: <21320000.1058888257@mariner.pc.cs.cmu.edu> In-Reply-To: <20030722042159.GA9346@binky.central.sun.com> References: <200307191729.h6JHTG8Q023166@thunk.east.sun.com> <20030721161202.GA8960@binky.central.sun.com> <142100000.1058822456@minbar.fac.cs.cmu.edu> <20030722042159.GA9346@binky.central.sun.com> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, July 21, 2003 21:22:03 -0700 Nicolas Williams wrote: > I think (B) is much more likely than (A) - and I have experienced it > myself; I have never experienced (A). Fair enough. >> comments from people other than you, me, and Joel on this point. I do >> agree that solving it requires extending the keyex protocol, probably >> along one of the three general paths I described in my message, none of >> which are terribly appealing to me. I believe the bar to be passed >> before solving this problem should be rather high. > > I agree, but I think we MUST fix the transport I-D wrt KEXINIT > extensibility. If we do that now then we can wait till later to solve > (A) and/or (B). Yes, definitely. > Before we do either we really ought to fix the transport I-D wrt KEXINIT > extensibility, and in the process find out what implementations do today > about extended KEXINITs. Though I've proposed the alg aliases/bogus alg > approach I think extending KEXINIT is the right approach and the clean > approach. Yes, extending KEXINIT is definitely cleaner. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 13:48:17 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20701 for ; Tue, 22 Jul 2003 13:48:17 -0400 (EDT) Received: (qmail 5701 invoked by uid 605); 22 Jul 2003 17:48:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5687 invoked from network); 22 Jul 2003 17:48:14 -0000 Received: from fw.hel.fi.ssh.com (195.20.116.97) by mail.netbsd.org with SMTP; 22 Jul 2003 17:48:14 -0000 Received: from viikuna.hel.fi.ssh.com (viikuna.hel.fi.ssh.com [10.1.0.46]) by fw.hel.fi.ssh.com (SSH-1.15) with SMTP id h6MHmDjj004727 for ; Tue, 22 Jul 2003 20:48:13 +0300 (EEST) Received: (qmail 12774 invoked from network); 22 Jul 2003 17:48:13 -0000 Received: from unknown (HELO torni.hel.fi.ssh.com) ([10.1.0.48]) (envelope-sender ) by viikuna.hel.fi.ssh.com (qmail-ldap-1.03) with SMTP for ; 22 Jul 2003 17:48:13 -0000 Received: (from ttsalo@localhost) by torni.hel.fi.ssh.com (8.9.3/8.9.3/SSH-1.3) id UAA10042; Tue, 22 Jul 2003 20:48:12 +0300 (EET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16157.30940.423246.364744@torni.hel.fi.ssh.com> Date: Tue, 22 Jul 2003 20:48:12 +0300 From: Tomi Salo To: ietf-ssh@NetBSD.org Subject: Re: SSH_MSG_KEXGSS_HOSTKEY (was: Re: I-D ACTION:draft-weber-secsh-pkalg-none-00.txt) In-Reply-To: References: X-Mailer: VM 6.88 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Organization: SSH Communications Security Corp, Finland Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Jeffrey Hutzelman writes: > Hm; this is an interesting problem. I think the current theory is that > the host sends you its key along with all the signatures. But if it has > to select which key to send you on the basis of what CA's you'll accept, > then it won't work. There's also an identity problem here, in that a > host may need to decide which key and certs to send you based on what > identity you think it has. TLS has this problem today... It's an interesting problem, and a real one. There may not be many reasons for a host to have multiple plain DSA or RSA keys, but with certificates (X.509), there is a real need for one server to have multiple certificates. For example, the server might be used by several groups of clients, each group trusting its' own CA. Right now, the server can't advertise multiple host keys of the same type and the client can't select among multiple host keys (of the same type), even if it retried the connection after having the key exchange fail because of receiving a 'wrong' hostkey. Of Joel's ideas for fixing this...: Putting the hostkeys into the hostkey algorithm list as algorithm@name pairs might be a partial solution. The client would at least be able to iterate through the list of keys, even if it did have to start a new connection for each try. Negotiating the CA by having the client send a list of trusted CAs and the server the list of available CAs could also work, but different host key algorithms might have completely different lists, so each party would have to send a separate list for each host key algorithm. -- Tomi T. Salo , SSH Communications Security Corp From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 14:18:20 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21546 for ; Tue, 22 Jul 2003 14:18:19 -0400 (EDT) Received: (qmail 21474 invoked by uid 605); 22 Jul 2003 18:18:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21467 invoked from network); 22 Jul 2003 18:18:19 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 22 Jul 2003 18:18:19 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1726092; Tue, 22 Jul 2003 12:18:18 -0600 Message-ID: <3F1D7F85.6070908@vandyke.com> Date: Tue, 22 Jul 2003 12:16:37 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Simon Tatham CC: ietf-ssh@NetBSD.org, mcclure@swcp.com Subject: Re: Publickey subsystem draft posted 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 > OK, here are some comments. I'm in favour of a protocol of this type > existing, but I think this draft is going to need some work before > it's useful. > > - You don't mention any kind of packet structure within the > subsystem channel, like SFTP has. Is this deliberate? It looks at > the moment as if the individual components of any given request > (e.g. string "add", string comment, string algorithm, string > pubkey blob) are sent straight to the subsystem without any > overall length field. > > If that's correct and not simply a documentation error, it > _completely_ destroys extensibility: if a subsystem receives any > request with a name it doesn't recognise, then it cannot know how > much of the following data belongs to that request, so after > returning REQUEST_NOT_SUPPORTED it _can't_ resume parsing at the > next request boundary. Without this basic extensibility property, > what was the point of having request types described in an > extensible string namespace at all? It is a documentation error-- thank heavens. The generalized message format is: UINT32 length string type ... request specific data follows Sections 2.2 and 2.3 should be updated to reflect this. > - Speaking of extensibility, I strongly support Nicolas Williams's > comment that there already exist SSH server implementations > supporting a greater range of public key options and restrictions > than your draft specifies. Surely at the very least there ought > to be some sort of extension mechanism within the "add" request > type? Yes, this makes sense. The "command" option was supposed to deal with the various restrictions supported by openssh and other implementations, but... a. Since we don't support it, we were kind of shooting in the dark as to what people needed, and clearly, we undershot. b. As you point out below, it needs to be integrated with the add command to prevent 'vulnerability windows' > - The "command" request is seriously under-specified. It does not > mention whether the key in question is expected to have been > added using "add" previously, or is added by the "command" > request itself. > > * If the former, this is a security hazard if naively > implemented: the _only_ way to set up a restricted key is by > issuing "add" and then "command", but between those two > requests, there is a window of opportunity in which someone > possessing the private key can gain unrestricted access to the > target account. Since restricted keys are typically keys you > don't fully trust not to fall into enemy hands, there should > never be such a window of opportunity. Therefore, an > implementation MUST delay actually making the changes until > the subsystem channel is closed or a subsequent > synchronisation message is sent; this should be clearly > specified. > > * If the latter, this would make far more sense to me, except > that the comment field present in the "add" request is missing > in the "command" request. > > Since I've already proposed an extensibility field in the "add" > request, I'm tempted to suggest that "command" is a complete > misfeature and ought to be implemented in terms of that instead. What if the "add" command where changed as follows? string "add" string public-key algorithm string public-key blob uint32 attribute-count string attrib-name string attrib-value bool mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. attrib-names without a '@' are reserved to the IETF. Extensions MAY be used by composing the '@' with a DNS name, for example, 'spiffy-extension@vandyke.com' If the server does not implement a mandatory attribute, it MUST fail the add. For the purposes of a mandatory attribute, storage of the attribute is not sufficient, but requires that the server understand and implement the intent of the attribute. The following attributes are defined by this draft. "comment" The comment field contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during a list operation. The comment field is useful so the user can identify the key without resorting to comparing it's fingerprint. "command" Command bypasses the session channel "exec" and "shell" requests by always execution the specified command. This attribute SHOULD be mandatory. "restrict" The value of this attribute contains server functions that may not be preformed when this key is used. It is a comma seperated list. Elements containing an '@' are reserved for implementation / site specific extension; all other elements are reserved for use by the IETF. Currently defined restrictions are: "x11" "shell" "exec" "port-forward" "reverse-forward" This attribute SHOULD be mandatory. For example, we might have: "add" "ssh-rsa" public-key-blob 4 "comment" "2048 bit RSA key for my daughter" "special@openssh.org" "restrict" "port-forward,reverse-forward,x11,exec" "command" "daughter-shell" The 'list' command would need to be updated to have a similar extension format. What do you think? What other extensions should we define here? What other types ofrestrictions should be defined? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 16:21:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25820 for ; Tue, 22 Jul 2003 16:21:11 -0400 (EDT) Received: (qmail 23639 invoked by uid 605); 22 Jul 2003 20:21:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23630 invoked from network); 22 Jul 2003 20:21:11 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 22 Jul 2003 20:21:11 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19f3dG-0001fb-00; Tue, 22 Jul 2003 21:21:10 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <3F1D7F85.6070908@vandyke.com> Subject: Re: Publickey subsystem draft posted Message-Id: Date: Tue, 22 Jul 2003 21:21:10 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Joseph Galbraith wrote: > The generalized message format is: > > UINT32 length > string type > ... request specific data follows Does the length include the 4 bytes of the length field itself? (I don't care, but don't forget to state it either way :-) > What if the "add" command were changed as follows? > > string "add" > string public-key algorithm > string public-key blob > uint32 attribute-count > string attrib-name > string attrib-value > bool mandatory > repeated attribute-count times Works for me. If anyone needs an attrib-value which is more complex than a simple string, there's nothing to stop them treating the string as a blob, and formatting the data inside the blob using another layer of SSH data types, or indeed any other format they feel like. Is it worth defining what should happen if a user attempts to add a key which is already present, but with different attributes? Should the add operation fail, or succeed and alter the key setup? > If the server does not implement a mandatory attribute, it MUST fail > the add. For the purposes of a mandatory attribute, storage of the > attribute is not sufficient, but requires that the server understand > and implement the intent of the attribute. I particularly like that. It reminds me of the bits in PNG that define what an editing program should do to chunk types it doesn't recognise. Simple and effective. > The comment field is useful so the user can identify the > key without resorting to comparing it's fingerprint. (As a vague aside: has anyone done a detailed study of what attacks might be possible by people - malicious clients, servers, agents, people, software, sysadmins or anyone else - substituting the comment for one valid key on another? PuTTY's custom-designed SSH2 key format contains a passphrase-keyed MAC designed to make the comment field tamper-evident, largely because I couldn't work out whether there was a possibility of an attack or not, and could see no reason not to be ultra-cautious. Anyone else had any thoughts on the subject?) > "restrict" [...] > Currently defined restrictions are: > "x11" > "shell" > "exec" > "port-forward" > "reverse-forward" What about "subsystem"? Is that worth putting in as a separate one? Or even "subsystem:foo", for any value of foo? Actually, the latter might get messy, since subsystem names are permitted to contain commas by my understanding. And in practice, anyone restricting a key would be more likely to want to forbid _all but_ specific subsystems rather than restricting particular ones. Cheers, Simon -- Simon Tatham "infinite loop _see_ loop, infinite" - Index, Borland Pascal Language Guide From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 17:05:07 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26870 for ; Tue, 22 Jul 2003 17:05:07 -0400 (EDT) Received: (qmail 14989 invoked by uid 605); 22 Jul 2003 21:05:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14980 invoked from network); 22 Jul 2003 21:05:03 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 22 Jul 2003 21:05:03 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1726472; Tue, 22 Jul 2003 15:05:02 -0600 Message-ID: <3F1DA69A.3090206@vandyke.com> Date: Tue, 22 Jul 2003 15:03:22 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Simon Tatham CC: ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted 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 >>The generalized message format is: >> >>UINT32 length >>string type >>... request specific data follows > > > Does the length include the 4 bytes of the length field itself? (I > don't care, but don't forget to state it either way :-) I believe it is like both Sftp and the SSH Transport layer; the length is not included. > Is it worth defining what should happen if a user attempts to add a > key which is already present, but with different attributes? Should > the add operation fail, or succeed and alter the key setup? Hmmm-- since we don't have a modify, maybe we should change add as follows: ... string public-key-blob bool overwrite ... with wording like: Clients SHOULD send the add request the first time with overwrite false, and then, if the key turns out to be already present, give the user the option of overwriting the key. We would also need to add a KEY_ALREADY_PRESENT status message. >> "restrict" > > [...] > >> Currently defined restrictions are: >> "x11" >> "shell" >> "exec" >> "port-forward" >> "reverse-forward" > > > What about "subsystem"? Is that worth putting in as a separate one? > Or even "subsystem:foo", for any value of foo? > > Actually, the latter might get messy, since subsystem names are > permitted to contain commas by my understanding. And in practice, > anyone restricting a key would be more likely to want to forbid _all > but_ specific subsystems rather than restricting particular ones. How about this: Currently defined restrictions are: "x11" "shell" "exec" "port-forward" "reverse-forward" "subsystem" And an additional attribute: "subsystem" The value is a subsystem that will be run when the key is used. Any attempt to access an different subsystem MUST fail. Any attempt to access other features is governed by the "restrict" attribute. Are there restrictions that can be expressed for openssh keys or ssh.com keys that can't be expressed in what is proposed? Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 17:40:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27549 for ; Tue, 22 Jul 2003 17:40:22 -0400 (EDT) Received: (qmail 5141 invoked by uid 605); 22 Jul 2003 21:40:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5133 invoked from network); 22 Jul 2003 21:40:18 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 22 Jul 2003 21:40:18 -0000 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6MLeGDZ011680; Tue, 22 Jul 2003 14:40:18 -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 h6MLeGbO022756; Tue, 22 Jul 2003 15:40:16 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6MLb2Qx009988; Tue, 22 Jul 2003 14:37:02 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6MLb0ed009987; Tue, 22 Jul 2003 14:37:00 -0700 (PDT) Date: Tue, 22 Jul 2003 14:37:00 -0700 From: Nicolas Williams To: Joseph Galbraith Cc: Simon Tatham , ietf-ssh@NetBSD.org, mcclure@swcp.com Subject: Re: Publickey subsystem draft posted Message-ID: <20030722213657.GA9981@binky.central.sun.com> References: <3F1D7F85.6070908@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1D7F85.6070908@vandyke.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 22, 2003 at 12:16:37PM -0600, Joseph Galbraith wrote: > What if the "add" command where changed as follows? > > string "add" > string public-key algorithm > string public-key blob > uint32 attribute-count > string attrib-name > string attrib-value > bool mandatory > repeated attribute-count times > > The server MUST attempt to store the public key for the user in the > appropriate location so the public key can be used for subsequent > public-key authentications. > > attrib-names without a '@' are reserved to the IETF. Extensions > MAY be used by composing the '@' with a DNS name, for example, > 'spiffy-extension@vandyke.com' > > If the server does not implement a mandatory attribute, it MUST fail > the add. For the purposes of a mandatory attribute, storage of the > attribute is not sufficient, but requires that the server understand > and implement the intent of the attribute. > > The following attributes are defined by this draft. > > "comment" > The comment field contains user-specified text > about the public key. The server SHOULD make every > effort to preserve this value and return it with the > key during a list operation. > > The comment field is useful so the user can identify the > key without resorting to comparing it's fingerprint. See Bill Sommerfeld's comment about I18N. You ought to associate a language tag with the comment. > "command" > Command bypasses the session channel "exec" and "shell" > requests by always execution the specified command. > > This attribute SHOULD be mandatory. This attibute's values are generally going to be platform-specific. There's no avoiding that, but it might be a good idea to have a way for clients to find out about the server's platform and/or validate the command. > "restrict" > The value of this attribute contains server functions that > may not be preformed when this key is used. It is a comma > seperated list. Elements containing an '@' are reserved for > implementation / site specific extension; all other elements > are reserved for use by the IETF. I think of "command" as a restriction, and all of these should be treated the same way, perhaps with each having it's own attribute name. > Currently defined restrictions are: > > "x11" > "shell" > "exec" > "port-forward" > "reverse-forward" > > This attribute SHOULD be mandatory. Don't forget about subsystems. And no, I don't think the "command" restriction should be conflated with subsystem restrictions. For the port forwarding restrictions there should probably be a list of host:port restrictions associated. There should probably be a list of host:ports which are allowed to use this key to authenticate. > The 'list' command would need to be updated to have > a similar extension format. Yes. > What do you think? What other extensions should we > define here? What other types ofrestrictions should > be defined? See above. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 18:48:02 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29794 for ; Tue, 22 Jul 2003 18:48:02 -0400 (EDT) Received: (qmail 5537 invoked by uid 605); 22 Jul 2003 22:48:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5525 invoked from network); 22 Jul 2003 22:47:59 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Jul 2003 22:47:59 -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 h6MMlxFt025384 for ; Tue, 22 Jul 2003 16:47:59 -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 h6MMltcm012361 for ; Tue, 22 Jul 2003 16:47: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 h6MMigQx010052 for ; Tue, 22 Jul 2003 15:44:42 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6MMig5o010051 for ietf-ssh@NetBSD.org; Tue, 22 Jul 2003 15:44:42 -0700 (PDT) Date: Tue, 22 Jul 2003 15:44:42 -0700 From: Nicolas Williams To: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030722224439.GA10045@binky.central.sun.com> References: <20030721221742.GI8917@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030721221742.GI8917@binky.central.sun.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Mon, Jul 21, 2003 at 03:17:42PM -0700, Nicolas Williams wrote: > Can implementors describe how they handle non-zero values for the last > field of SSH_MSG_KEXINIT? Thanks to all who did. For those whose implementations ignore additional data past the reserved field, is that data included in the key exchange hash? I think the fact that some implementations do not tolerate KEXINIT "extensions" should not precluse the proposed change. Several implementations already map the peer's version string to compatibility notes and react accordingly. While I hope that we can put stop adding to this database of compatibility notes I think that this particular issue (KEXINIT extensibility) is worth the trouble to fix. (When the core I-Ds progress I think it might be worthwhile to built a registry of compatibility notes.) Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 18:52:49 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29904 for ; Tue, 22 Jul 2003 18:52:48 -0400 (EDT) Received: (qmail 8006 invoked by uid 605); 22 Jul 2003 22:52:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7999 invoked from network); 22 Jul 2003 22:52:50 -0000 Received: from adsl-64-123-27-105.dsl.austtx.swbell.net (HELO pyramid.twistedmatrix.com) (64.123.27.105) by mail.netbsd.org with SMTP; 22 Jul 2003 22:52:50 -0000 Received: from adsl-64-123-27-105.dsl.austtx.swbell.net ([64.123.27.105] helo=Moo) by pyramid.twistedmatrix.com with esmtp (Exim 3.35 #1 (Debian)) id 19f5zw-0002G8-00 for ; Tue, 22 Jul 2003 17:52:47 -0500 From: "Paul Swartz" To: ietf-ssh@NetBSD.org Date: Tue, 22 Jul 2003 18:52:48 -0400 Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <3F1D8800.5091.13D4B65D@localhost> In-reply-to: <20030722224439.GA10045@binky.central.sun.com> References: <20030721221742.GI8917@binky.central.sun.com> X-mailer: Pegasus Mail for Windows (v4.12a) Sender: ietf-ssh-owner@NetBSD.org Precedence: list On 22 Jul 2003 at 15:44, Nicolas Williams wrote: > For those whose implementations ignore additional data past the reserved > field, is that data included in the key exchange hash? Yes, Conch includes the entire packet, regardless of how much of the packet it parses. -p -- Paul Swartz (o_ http://twistedmatrix.com/users/z3p.twistd/ //\ z3p@twistedmatrix.com V_/_ AIM: Z3Penguin From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 22 19:05:36 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00236 for ; Tue, 22 Jul 2003 19:05:35 -0400 (EDT) Received: (qmail 13410 invoked by uid 605); 22 Jul 2003 23:05:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13403 invoked from network); 22 Jul 2003 23:05:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 22 Jul 2003 23:05:36 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1726779; Tue, 22 Jul 2003 17:05:35 -0600 Message-ID: <3F1DC2DA.3090704@vandyke.com> Date: Tue, 22 Jul 2003 17:03:54 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Nicolas Williams CC: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> In-Reply-To: <20030722224439.GA10045@binky.central.sun.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 > For those whose implementations ignore additional data past the reserved > field, is that data included in the key exchange hash? VanDykes products use the entire kexinit packet, including any excess data. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 00:20:19 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05299 for ; Wed, 23 Jul 2003 00:20:19 -0400 (EDT) Received: (qmail 28332 invoked by uid 605); 23 Jul 2003 04:20:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28325 invoked from network); 23 Jul 2003 04:20:14 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 23 Jul 2003 04:20:14 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6N4KCoY005886; Wed, 23 Jul 2003 16:20:12 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6N4KC906667; Wed, 23 Jul 2003 16:20:12 +1200 Date: Wed, 23 Jul 2003 16:20:12 +1200 Message-Id: <200307230420.h6N4KC906667@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, z3p@twistedmatrix.com Subject: Re: Transport I-D: KEXINIT reserved field needs description Sender: ietf-ssh-owner@NetBSD.org Precedence: list "Paul Swartz" writes: >On 22 Jul 2003 at 15:44, Nicolas Williams wrote: >>For those whose implementations ignore additional data past the reserved >>field, is that data included in the key exchange hash? > >Yes, Conch includes the entire packet, regardless of how much of the packet >it parses. Same with cryptlib (or at least it would if it didn't reject the packet for having undefined extra data after the reserved field - if an extension mechanism is defined in the future, it's a one-line change to accomodate it by not rejecting the packet). Speaking of extensions, it would be useful when/if these are defined to have a per-extension flag indicating that an inability to process the extension should be treated as a fatal error vs. simply ignoring the extension, which I assume would be the default action. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 03:56:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05081 for ; Wed, 23 Jul 2003 03:56:14 -0400 (EDT) Received: (qmail 13425 invoked by uid 605); 23 Jul 2003 07:55:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13415 invoked from network); 23 Jul 2003 07:55:06 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 23 Jul 2003 07:55:06 -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 h6N7pJOc017213; Wed, 23 Jul 2003 09:51:20 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id CAF022D041; Wed, 23 Jul 2003 09:51:49 +0200 (CEST) Date: Wed, 23 Jul 2003 09:51:49 +0200 From: Markus Friedl To: Nicolas Williams , ietf-ssh@NetBSD.org Cc: Joseph Galbraith Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030723075149.GC7060@folly> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <3F1DC2DA.3090704@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1DC2DA.3090704@vandyke.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 22, 2003 at 05:03:54PM -0600, Joseph Galbraith wrote: > >For those whose implementations ignore additional data past the reserved > >field, is that data included in the key exchange hash? > > VanDykes products use the entire kexinit packet, > including any excess data. OpenSSH would do the same if it would accept badly formated KEXINIT packets. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 04:00:42 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05197 for ; Wed, 23 Jul 2003 04:00:41 -0400 (EDT) Received: (qmail 16149 invoked by uid 605); 23 Jul 2003 08:00:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16142 invoked from network); 23 Jul 2003 08:00:40 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 23 Jul 2003 08:00:40 -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 h6N7usOc017403; Wed, 23 Jul 2003 09:56:54 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id E0C8D2D041; Wed, 23 Jul 2003 09:57:24 +0200 (CEST) Date: Wed, 23 Jul 2003 09:57:24 +0200 From: Markus Friedl To: Nicolas Williams Cc: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030723075724.GD7060@folly> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030722224439.GA10045@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 22, 2003 at 03:44:42PM -0700, Nicolas Williams wrote: > I think the fact that some implementations do not tolerate KEXINIT > "extensions" should not precluse the proposed change. Several > implementations already map the peer's version string to compatibility > notes and react accordingly. While I hope that we can put stop adding > to this database of compatibility notes I think that this particular > issue (KEXINIT extensibility) is worth the trouble to fix. I don't think it's a good idea to break the protocol at this point. This compatibility database is always a pain and you always miss some implementations. I think you could only assume that the peer is able to deal with the extension if it sends a non-zero value in the reserved field, but I doubt this helps for what you want. On the other hand, you could send the extension data in an extra packet if the reserved byte is not zero. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 04:20:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA05595 for ; Wed, 23 Jul 2003 04:20:04 -0400 (EDT) Received: (qmail 27063 invoked by uid 605); 23 Jul 2003 08:20:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27056 invoked from network); 23 Jul 2003 08:20:03 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 23 Jul 2003 08:20:03 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 19fEqx-0003bb-00; Wed, 23 Jul 2003 09:20:03 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@NetBSD.org In-Reply-To: <20030722224439.GA10045@binky.central.sun.com> Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-Id: Date: Wed, 23 Jul 2003 09:20:03 +0100 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Nicolas Williams wrote: > For those whose implementations ignore additional data past the reserved > field, is that data included in the key exchange hash? At the risk of making a barely contentful `M33 T00!!!1!!' post ... yes, PuTTY hashes the whole incoming packet, whether it recognises it all or not. -- Simon Tatham "I thought I'd put my foot so far into my mouth I wouldn't be able to sit down without standing up." From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 07:00:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08283 for ; Wed, 23 Jul 2003 07:00:12 -0400 (EDT) Received: (qmail 19629 invoked by uid 605); 23 Jul 2003 11:00:05 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20030723110005.19628.qmail@mail.netbsd.org> Received: (qmail 19606 invoked from network); 23 Jul 2003 11:00:02 -0000 Received: from host-209.167.194.104.mondenet.com (HELO mondenet.com) (209.167.194.104) by mail.netbsd.org with SMTP; 23 Jul 2003 11:00:02 -0000 From: "Canada Books" To: Subject: Federal provincial funds Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Wed, 23 Jul 2003 07:00:49 -0400 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 8bit CANADA BOOKS 36 Felix Renaud Aylmer Qc J9H 7C1 (819)682-7983 PRESS RELEASE CANADIAN SUBSIDY DIRECTORY YEAR 2003 EDITION Legal Deposit-National Library of Canada ISBN 2-922870-05-7 The new revised edition of the Canadian Subsidy Directory 2003 is now available. The new edition is the most complete and affordable reference for anyone looking for financial support. It is deemed to be the perfect tool for new or existing businesses, individual ventures, foundations and associations. This Publication contains more than 2000 direct and indirect financial subsidies, grants and loans offered by government departments and agencies, foundations, associations and organisations. In this new 2003 edition all programs are well described. The Canadian Subsidy Directory is the most comprehensive tool to start up a business, improve existent activities, set up a business plan, or obtain assistance from experts in fields such as: Industry, transport, agriculture, communications, municipal infrastructure, education, import-export, labor, construction and renovation, the service sector, hi-tech industries, research and development, joint ventures, arts, cinema, theatre, music and recording industry, the self employed, contests, and new talents. Assistance from and for foundations and associations, guidance to prepare a business plan, market surveys, computers, and much more! The Canadian Subsidy Directory is sold $ 69.95, to obtain a copy please call: Canada Books, (819)682-7983 From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 08:12:55 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09286 for ; Wed, 23 Jul 2003 08:12:54 -0400 (EDT) Received: (qmail 29337 invoked by uid 605); 23 Jul 2003 12:12:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29330 invoked from network); 23 Jul 2003 12:12:52 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 23 Jul 2003 12:12:52 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id DEC25567D for ; Wed, 23 Jul 2003 14:12:45 +0200 (CEST) Message-ID: <3F1E7BBD.9020406@siliconcircus.com> Date: Wed, 23 Jul 2003 14:12:45 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description References: <20030721221742.GI8917@binky.central.sun.com> <3F1D8800.5091.13D4B65D@localhost> In-Reply-To: <3F1D8800.5091.13D4B65D@localhost> 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 Paul Swartz wrote: > On 22 Jul 2003 at 15:44, Nicolas Williams wrote: > > >>For those whose implementations ignore additional data past the reserved >>field, is that data included in the key exchange hash? > > > Yes, Conch includes the entire packet, regardless of how much of the > packet it parses. PenguiNet too. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 11:07:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16335 for ; Wed, 23 Jul 2003 11:07:41 -0400 (EDT) Received: (qmail 14701 invoked by uid 605); 23 Jul 2003 15:07:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14694 invoked from network); 23 Jul 2003 15:07:40 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 23 Jul 2003 15:07:40 -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 h6NF7dvH001037; Wed, 23 Jul 2003 09:07:39 -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 h6NF7cbO024080; Wed, 23 Jul 2003 09:07: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 h6NF0cQx010422; Wed, 23 Jul 2003 08:00:38 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6NF0bDf010421; Wed, 23 Jul 2003 08:00:37 -0700 (PDT) Date: Wed, 23 Jul 2003 08:00:37 -0700 From: Nicolas Williams To: Markus Friedl Cc: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030723150037.GD8917@binky.central.sun.com> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723075724.GD7060@folly> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 23, 2003 at 09:57:24AM +0200, Markus Friedl wrote: > On Tue, Jul 22, 2003 at 03:44:42PM -0700, Nicolas Williams wrote: > > I think the fact that some implementations do not tolerate KEXINIT > > "extensions" should not precluse the proposed change. Several > > implementations already map the peer's version string to compatibility > > notes and react accordingly. While I hope that we can put stop adding > > to this database of compatibility notes I think that this particular > > issue (KEXINIT extensibility) is worth the trouble to fix. > > I don't think it's a good idea to break the protocol at > this point. This compatibility database is always a pain > and you always miss some implementations. > > I think you could only assume that the peer is able to deal with > the extension if it sends a non-zero value in the reserved field, > but I doubt this helps for what you want. On the other hand, you > could send the extension data in an extra packet if the reserved byte > is not zero. Of all the things in the compat db, this would be amongst the most important things to have in there. So if a peer has a version string that according to the compat db means that the peer does not support KEXINIT non-zero reserved field, then you send zero in your KEXINIT's reserved field and no extra data in that packet. Otherwise you are free to use KEXINIT extensions. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 13:30:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20529 for ; Wed, 23 Jul 2003 13:30:40 -0400 (EDT) Received: (qmail 11459 invoked by uid 605); 23 Jul 2003 17:28:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11370 invoked from network); 23 Jul 2003 17:28:50 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 23 Jul 2003 17:28:50 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 4D109567D; Wed, 23 Jul 2003 19:28:49 +0200 (CEST) Message-ID: <3F1EC5D2.7090105@siliconcircus.com> Date: Wed, 23 Jul 2003 19:28:50 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Friedl Cc: Nicolas Williams , ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> In-Reply-To: <20030723075724.GD7060@folly> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Markus Friedl wrote: > On Tue, Jul 22, 2003 at 03:44:42PM -0700, Nicolas Williams wrote: > >>I think the fact that some implementations do not tolerate KEXINIT >>"extensions" should not precluse the proposed change. Several >>implementations already map the peer's version string to compatibility >>notes and react accordingly. While I hope that we can put stop adding >>to this database of compatibility notes I think that this particular >>issue (KEXINIT extensibility) is worth the trouble to fix. > > > I don't think it's a good idea to break the protocol at > this point. This compatibility database is always a pain > and you always miss some implementations. > > I think you could only assume that the peer is able to deal with > the extension if it sends a non-zero value in the reserved field, > but I doubt this helps for what you want. On the other hand, you > could send the extension data in an extra packet if the reserved byte > is not zero. If you wanted to get really hacky about it, you could put the additional data in the padding part of the SSH packet. This restricts you to 251 bytes of data (255 bytes max padding - 4 bytes of real padding) but should retain compatibility with all current clients. Of course, it's also a truly unpleasant hack and probably messy to implement for everyone concerned. But it's possible... Overall, my personal opinion (FWIW) is: a) using an extra packet would be best, and b) implementations should ignore additional data within packets, or at least within packets with reserved fields allowing for extensions. Not ignoring additional data basically means reserved fields are useless, since in every case the only decent solution will be a) above, and if that was the desired extensibility mechanism, one could just rely on sending new packet types, receiving SSH_MSG_UNIMPLEMENTED from old clients and then sending the old packet type in order to extend things. I'm curious as to why OpenSSH does refuse extra packet data - this goes against the general liberal-in-what-you-receive principle, which makes me interested in the thinking behind doing things this way. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 13:35:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20648 for ; Wed, 23 Jul 2003 13:35:09 -0400 (EDT) Received: (qmail 17185 invoked by uid 605); 23 Jul 2003 17:35:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17178 invoked from network); 23 Jul 2003 17:35:07 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 23 Jul 2003 17:35:07 -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 h6NHZ6Gg001695; Wed, 23 Jul 2003 10:35:06 -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 h6NHZ5bO003724; Wed, 23 Jul 2003 11:35:06 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6NHVrQx010553; Wed, 23 Jul 2003 10:31:53 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6NHVrWp010552; Wed, 23 Jul 2003 10:31:53 -0700 (PDT) Date: Wed, 23 Jul 2003 10:31:53 -0700 From: Nicolas Williams To: Jon Bright Cc: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030723173153.GH8917@binky.central.sun.com> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> <3F1EC5D2.7090105@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1EC5D2.7090105@siliconcircus.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 23, 2003 at 07:28:50PM +0200, Jon Bright wrote: > Overall, my personal opinion (FWIW) is: > > a) using an extra packet would be best, and > b) implementations should ignore additional data within packets, or at > least within packets with reserved fields allowing for extensions. Not > ignoring additional data basically means reserved fields are useless, > since in every case the only decent solution will be a) above, and if > that was the desired extensibility mechanism, one could just rely on > sending new packet types, receiving SSH_MSG_UNIMPLEMENTED from old > clients and then sending the old packet type in order to extend things. I believe not all implementations reply with SSH_MSG_UNIMPLEMENTED before userauth or before userauth completes. To avoid another avalanche of "me toos" :) I will ask for such information to be sent to me which then I'll summarize. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 13:39:54 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20741 for ; Wed, 23 Jul 2003 13:39:53 -0400 (EDT) Received: (qmail 21340 invoked by uid 605); 23 Jul 2003 17:39:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21333 invoked from network); 23 Jul 2003 17:39:51 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 23 Jul 2003 17:39:51 -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 h6NHdpGg004499 for ; Wed, 23 Jul 2003 10:39:51 -0700 (PDT) Received: from binky.central.sun.com (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6NHdocm021670 for ; Wed, 23 Jul 2003 11:39: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 h6NHacQx010564 for ; Wed, 23 Jul 2003 10:36:38 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6NHacYn010563 for ietf-ssh@NetBSD.org; Wed, 23 Jul 2003 10:36:38 -0700 (PDT) Date: Wed, 23 Jul 2003 10:36:38 -0700 From: Nicolas Williams To: ietf-ssh@NetBSD.org Subject: Implementation support for SSH_MSG_UNIMPLEMENTED Message-ID: <20030723173638.GI8917@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list Are there any implementations which do not respond with SSH_MSG_UNIMPLEMENTED to unknown packet types during the key exchange phase of the protocol? Please do not Cc the list - I'll summarize all responses and post them later. Thanks, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 13:41:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20780 for ; Wed, 23 Jul 2003 13:41:29 -0400 (EDT) Received: (qmail 24510 invoked by uid 605); 23 Jul 2003 17:41:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24500 invoked from network); 23 Jul 2003 17:41:22 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 23 Jul 2003 17:41:22 -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 h6NHfMGg005583; Wed, 23 Jul 2003 10:41:22 -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 h6NHfMcm022426; Wed, 23 Jul 2003 11:41:22 -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 h6NHc9Qx010571; Wed, 23 Jul 2003 10:38:09 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6NHc9Kd010570; Wed, 23 Jul 2003 10:38:09 -0700 (PDT) Date: Wed, 23 Jul 2003 10:38:09 -0700 From: Nicolas Williams To: Jon Bright Cc: Markus Friedl , ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030723173809.GJ8917@binky.central.sun.com> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> <3F1EC5D2.7090105@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1EC5D2.7090105@siliconcircus.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 23, 2003 at 07:28:50PM +0200, Jon Bright wrote: > Overall, my personal opinion (FWIW) is: > > a) using an extra packet would be best, and This would require the use of extra packets after kex to verify that one's peer truly did not support the new packets. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 13:46:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20992 for ; Wed, 23 Jul 2003 13:46:23 -0400 (EDT) Received: (qmail 28550 invoked by uid 605); 23 Jul 2003 17:46:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28543 invoked from network); 23 Jul 2003 17:46:21 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 23 Jul 2003 17:46:21 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 4FA6D567D; Wed, 23 Jul 2003 19:46:20 +0200 (CEST) Message-ID: <3F1EC9ED.7030600@siliconcircus.com> Date: Wed, 23 Jul 2003 19:46:21 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Cc: Markus Friedl , ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> <3F1EC5D2.7090105@siliconcircus.com> <20030723173809.GJ8917@binky.central.sun.com> In-Reply-To: <20030723173809.GJ8917@binky.central.sun.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 Nicolas Williams wrote: > This would require the use of extra packets after kex to verify that > one's peer truly did not support the new packets. Sorry, on this occasion, I meant an extra packet sent after receiving the other side's key if the reserved field from the remote side is non-zero (as Markus suggested). It's an extra round-trip, but should be fairly foolproof. Basically, both sides, upon receiving non-zero from the other side, embark on new-and-shiny-kex and forget about whatever they would have done with current-kex. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 15:05:58 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24086 for ; Wed, 23 Jul 2003 15:05:58 -0400 (EDT) Received: (qmail 14971 invoked by uid 605); 23 Jul 2003 19:03:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14959 invoked from network); 23 Jul 2003 19:03:22 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 23 Jul 2003 19:03:22 -0000 Received: from jurassic.eng.sun.com ([129.146.17.55]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6NJ3K9k018671; Wed, 23 Jul 2003 13:03:20 -0600 (MDT) Received: from braveheart (braveheart.Eng.Sun.COM [129.146.86.198]) by jurassic.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h6NJ3J9k976010; Wed, 23 Jul 2003 12:03:19 -0700 (PDT) Date: Wed, 23 Jul 2003 12:03:19 -0700 (PDT) From: Darren J Moffat To: Joseph Galbraith cc: Simon Tatham , Subject: Re: Publickey subsystem draft posted In-Reply-To: <3F1DA69A.3090206@vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, 22 Jul 2003, Joseph Galbraith wrote: > Hmmm-- since we don't have a modify, maybe we should > change add as follows: > ... > string public-key-blob > bool overwrite > ... > > with wording like: > > Clients SHOULD send the add request the first time > with overwrite false, and then, if the key turns out > to be already present, give the user the option of > overwriting the key. > > We would also need to add a KEY_ALREADY_PRESENT status > message. Which needs to have the possibility of permission denied, so that an admin can setup a set of restrictions on a key that the user can't later override by using the public key subsystem to modify the attributes of an already existing key. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 18:29:13 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06165 for ; Wed, 23 Jul 2003 18:29:12 -0400 (EDT) Received: (qmail 21218 invoked by uid 605); 23 Jul 2003 22:29:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21210 invoked from network); 23 Jul 2003 22:29:07 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 23 Jul 2003 22:29:07 -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 h6NMT719027094; Wed, 23 Jul 2003 15:29:07 -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 h6NMT5cm012807; Wed, 23 Jul 2003 16:29:06 -0600 (MDT) Received: from binky.central.sun.com (localhost [127.0.0.1]) by binky.central.sun.com (8.12.5+Sun/8.12.3) with ESMTP id h6NMPrQx010764; Wed, 23 Jul 2003 15:25:53 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6NMPqEn010763; Wed, 23 Jul 2003 15:25:52 -0700 (PDT) Date: Wed, 23 Jul 2003 15:25:52 -0700 From: Nicolas Williams To: Darren J Moffat Cc: Joseph Galbraith , Simon Tatham , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted Message-ID: <20030723222549.GA10755@binky.central.sun.com> References: <3F1DA69A.3090206@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 23, 2003 at 12:03:19PM -0700, Darren J Moffat wrote: > Which needs to have the possibility of permission denied, so that an > admin can setup a set of restrictions on a key that the user can't > later override by using the public key subsystem to modify the attributes > of an already existing key. Also, the restrictions actually stored need not match the restrictions listed in the add request. This could allow sysadmins to force restriction templates. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 18:35:09 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06370 for ; Wed, 23 Jul 2003 18:35:08 -0400 (EDT) Received: (qmail 25626 invoked by uid 605); 23 Jul 2003 22:35:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25618 invoked from network); 23 Jul 2003 22:35:09 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 23 Jul 2003 22:35:09 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6NMZ819000275; Wed, 23 Jul 2003 15:35:08 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6NMZ7fM004418; Wed, 23 Jul 2003 18:35:07 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6NMZ68Q009174; Wed, 23 Jul 2003 18:35:06 -0400 (EDT) Message-Id: <200307232235.h6NMZ68Q009174@thunk.east.sun.com> From: Bill Sommerfeld To: Nicolas Williams cc: Darren J Moffat , Joseph Galbraith , Simon Tatham , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted In-Reply-To: Your message of "Wed, 23 Jul 2003 15:25:52 PDT." <20030723222549.GA10755@binky.central.sun.com> Reply-to: sommerfeld@east.sun.com Date: Wed, 23 Jul 2003 18:35:06 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Also, the restrictions actually stored need not match the restrictions > listed in the add request. This could allow sysadmins to force > restriction templates. [wg chair hat off] I'd hope that the set of restrictions stored would be spec'ed to be a superset of the restrictions requested. looking at it another way, the set of things permitted to be done with a key would be a subset of the things that the add request requested to be permitted... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 18:36:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06431 for ; Wed, 23 Jul 2003 18:36:14 -0400 (EDT) Received: (qmail 26369 invoked by uid 605); 23 Jul 2003 22:36:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26362 invoked from network); 23 Jul 2003 22:36:14 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 23 Jul 2003 22:36:14 -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 h6NMaDvH022857; Wed, 23 Jul 2003 16:36:13 -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 h6NMaDbO010844; Wed, 23 Jul 2003 16:36: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 h6NMX1Qx010773; Wed, 23 Jul 2003 15:33:01 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6NMX0bw010772; Wed, 23 Jul 2003 15:33:00 -0700 (PDT) Date: Wed, 23 Jul 2003 15:33:00 -0700 From: Nicolas Williams To: Bill Sommerfeld Cc: Darren J Moffat , Joseph Galbraith , Simon Tatham , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted Message-ID: <20030723223300.GN8917@binky.central.sun.com> References: <20030723222549.GA10755@binky.central.sun.com> <200307232235.h6NMZ68Q009174@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307232235.h6NMZ68Q009174@thunk.east.sun.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 23, 2003 at 06:35:06PM -0400, Bill Sommerfeld wrote: > > Also, the restrictions actually stored need not match the restrictions > > listed in the add request. This could allow sysadmins to force > > restriction templates. > > [wg chair hat off] > > I'd hope that the set of restrictions stored would be spec'ed to be a > superset of the restrictions requested. > looking at it another way, the set of things permitted to be done with > a key would be a subset of the things that the add request requested > to be permitted... Yes. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 18:54:19 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06819 for ; Wed, 23 Jul 2003 18:54:18 -0400 (EDT) Received: (qmail 6714 invoked by uid 605); 23 Jul 2003 22:54:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6707 invoked from network); 23 Jul 2003 22:54:17 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 23 Jul 2003 22:54:17 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with SMTP id CC368567D; Thu, 24 Jul 2003 00:54:16 +0200 (CEST) Received: from 212.23.126.4 (SquirrelMail authenticated user sircus) by mail.siliconcircus.com with HTTP; Thu, 24 Jul 2003 00:54:16 +0200 (CEST) Message-ID: <14811.212.23.126.4.1059000856.squirrel@mail.siliconcircus.com> In-Reply-To: <20030723222549.GA10755@binky.central.sun.com> References: <3F1DA69A.3090206@vandyke.com> <20030723222549.GA10755@binky.central.sun.com> Date: Thu, 24 Jul 2003 00:54:16 +0200 (CEST) Subject: Re: Publickey subsystem draft posted From: "Jon Bright" To: "Nicolas Williams" Cc: "Darren J Moffat" , "Joseph Galbraith" , "Simon Tatham" , ietf-ssh@NetBSD.org Reply-To: jon@siliconcircus.com User-Agent: SquirrelMail/1.4.0 RC2a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Also, the restrictions actually stored need not match the restrictions > listed in the add request. This could allow sysadmins to force > restriction templates. This sounds like a good plan. From a GUI perspective, though, it'd be nice to have a facility to additionally have operations to: a) List restrictions the sever supports. b) Discover which of those restrictions will be compulsorily applied. The first enables presenting a list of checkboxes to the user (with, for those restrictions the client know of, human-friendly text). The second allows certain of those checkboxes to be compulsorily checked, thereby (hopefully) avoiding user confusion about the restrictions applied to the key. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 23 21:39:02 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09694 for ; Wed, 23 Jul 2003 21:39:01 -0400 (EDT) Received: (qmail 28747 invoked by uid 605); 24 Jul 2003 01:38:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28739 invoked from network); 24 Jul 2003 01:38:56 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 24 Jul 2003 01:38:56 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6O1csoY000800; Thu, 24 Jul 2003 13:38:54 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6O1ctm30482; Thu, 24 Jul 2003 13:38:55 +1200 Date: Thu, 24 Jul 2003 13:38:55 +1200 Message-Id: <200307240138.h6O1ctm30482@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-ssh@NetBSD.org, Nicolas.Williams@sun.com Subject: Re: Implementation support for SSH_MSG_UNIMPLEMENTED Sender: ietf-ssh-owner@NetBSD.org Precedence: list [I've made this a public reply because it contains a point that may be worth considering] >Are there any implementations which do not respond with SSH_MSG_UNIMPLEMENTED >to unknown packet types during the key exchange phase of the protocol? I don't, but that can be fixed if it becomes a critical requirement of the protocol. The reason I don't is that I always send the minimal amount of info in error returns for any protocol I do (SSH/SSL/CMP/TSP/RTCS/OCSP/etc), which has saved me from at least two attacks on SSL and probably attacks on other protocols as well. In other words if the protocol requires a certain response in order to function I'll do it, but if it's merely a nicety for debugging, I'll send the most generic response I can get away with. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 03:54:49 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27902 for ; Thu, 24 Jul 2003 03:54:48 -0400 (EDT) Received: (qmail 3806 invoked by uid 605); 24 Jul 2003 07:54:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3799 invoked from network); 24 Jul 2003 07:54:48 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 24 Jul 2003 07:54:48 -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 h6O7p1Oc020835; Thu, 24 Jul 2003 09:51:02 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 4583E2D004; Thu, 24 Jul 2003 09:51:29 +0200 (CEST) Date: Thu, 24 Jul 2003 09:51:29 +0200 From: Markus Friedl To: Nicolas Williams Cc: ietf-ssh@NetBSD.org Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <20030724075128.GA1887@folly> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> <20030723150037.GD8917@binky.central.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030723150037.GD8917@binky.central.sun.com> User-Agent: Mutt/1.4.1i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Wed, Jul 23, 2003 at 08:00:37AM -0700, Nicolas Williams wrote: > On Wed, Jul 23, 2003 at 09:57:24AM +0200, Markus Friedl wrote: > > On Tue, Jul 22, 2003 at 03:44:42PM -0700, Nicolas Williams wrote: > > > I think the fact that some implementations do not tolerate KEXINIT > > > "extensions" should not precluse the proposed change. Several > > > implementations already map the peer's version string to compatibility > > > notes and react accordingly. While I hope that we can put stop adding > > > to this database of compatibility notes I think that this particular > > > issue (KEXINIT extensibility) is worth the trouble to fix. > > > > I don't think it's a good idea to break the protocol at > > this point. This compatibility database is always a pain > > and you always miss some implementations. > > > > I think you could only assume that the peer is able to deal with > > the extension if it sends a non-zero value in the reserved field, > > but I doubt this helps for what you want. On the other hand, you > > could send the extension data in an extra packet if the reserved byte > > is not zero. > > Of all the things in the compat db, this would be amongst the most > important things to have in there. yes, that's why it's dangerous and it's likely that you miss versions strings. you should not depend on this and break the protocol this late. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 09:42:32 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05973 for ; Thu, 24 Jul 2003 09:42:30 -0400 (EDT) Received: (qmail 20844 invoked by uid 605); 24 Jul 2003 13:42:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20837 invoked from network); 24 Jul 2003 13:42:21 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 24 Jul 2003 13:42:21 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id EC1DA567D; Thu, 24 Jul 2003 15:42:08 +0200 (CEST) Message-ID: <3F1FE234.4030703@siliconcircus.com> Date: Thu, 24 Jul 2003 15:42:12 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brent McClure Cc: ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted References: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> In-Reply-To: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Hi, Brent McClure wrote: > We've refreshed the individual draft of the "Secure Shell Public-Key Subsystem". > The new draft is available here: > > http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-subsystem-01.txt Following the various comments from the WG, I have the following suggested text for the changes discussed. A lot of this is taken directly from things people posted to the mailing list. I think I caught all the suggested changes. Any errors are my fault. My comments on the change appear above each patch hunk (I realise you're probably not going to be able to apply the patch, since the text output is not the source format, but this seemed the easiest way of presenting it all). "will" doesn't seem especially RFCish... @@ -207,7 +207,7 @@ Client implementations SHOULD reject this request; it is normally only sent by the client. - If want reply is TRUE, the server will respond with + If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. As Joseph mentioned, length was omitted in the previous version. Additionally, clarify what the length specifies. @@ -228,23 +228,25 @@ 2.2 Requests - All public-key subsystem requests are sent request in the following - form: + All public-key subsystem requests are sent in the following form: + uint32 length string request-name ... request specific data follows - The client MUST receive acknowledgement of each request prior to - sending a new request. + The length field describes the length of the request-name field and + the request-specific data, but not of the length field itself. The + client MUST receive a response to each request prior to sending a + new request. - All requests described in Section 3 are a description of the 'data' - portion of the packet. + All requests described in Section 3 are a description of the + 'request-name' and 'data' portions of the packet. 2.3 Responses - All public-key subsystem requests are sent request in the following - form: + All public-key subsystem responses are sent in the following form: + uint32 length string response-name ... response specific data follows All the other drafts define a prefix of the form SSH_; Thu, 24 Jul 2003 10:25:33 -0400 (EDT) Received: (qmail 16888 invoked by uid 605); 24 Jul 2003 14:25:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16877 invoked from network); 24 Jul 2003 14:25:20 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 24 Jul 2003 14:25:20 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6OEPJFW014595; Thu, 24 Jul 2003 07:25:20 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OEPItK023077; Thu, 24 Jul 2003 10:25:18 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6OEPI8Q011972; Thu, 24 Jul 2003 10:25:18 -0400 (EDT) Message-Id: <200307241425.h6OEPI8Q011972@thunk.east.sun.com> From: Bill Sommerfeld To: Jon Bright cc: Brent McClure , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted In-Reply-To: Your message of "Thu, 24 Jul 2003 15:42:12 +0200." <3F1FE234.4030703@siliconcircus.com> Reply-to: sommerfeld@east.sun.com Date: Thu, 24 Jul 2003 10:25:18 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > If I should avoid wholesale editing of other people's documents in the > future, please let me know :-) One common fix to this problem is to add the new editor's name to the document ;-) other meta-comments: [not speaking as WG chair..] it would be helpful to also add a list of some well-known restrictions, while making it clear that precise interpretation is a local matter on the server. Decide whether to call them "attributes" or "restrictions" Having a "critical bit" for restrictions may be important. (this means "fail the request if I don't know what to do with it") Maybe the way to go is to define restrictions as attributes with the critical bit set? - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 10:41:58 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09454 for ; Thu, 24 Jul 2003 10:41:58 -0400 (EDT) Received: (qmail 27624 invoked by uid 605); 24 Jul 2003 14:41:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27616 invoked from network); 24 Jul 2003 14:41:58 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 24 Jul 2003 14:41:58 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 47588567D; Thu, 24 Jul 2003 16:41:57 +0200 (CEST) Message-ID: <3F1FF038.7030104@siliconcircus.com> Date: Thu, 24 Jul 2003 16:42:00 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com Cc: Brent McClure , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted References: <200307241425.h6OEPI8Q011972@thunk.east.sun.com> In-Reply-To: <200307241425.h6OEPI8Q011972@thunk.east.sun.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 Bill Sommerfeld wrote: >>If I should avoid wholesale editing of other people's documents in the >>future, please let me know :-) > > > One common fix to this problem is to add the new editor's name to the > document ;-) I wouldn't want to go treading on other people's toes :-) > other meta-comments: [not speaking as WG chair..] > > it would be helpful to also add a list of some well-known > restrictions, while making it clear that precise interpretation is a > local matter on the server. I'm not sure what you mean by this - we're already listing x11, shell, exec, agent, env and subsystem? > Decide whether to call them "attributes" or "restrictions" At the moment, they're two different things (and I think I used the names consistently to refer to one or the other). I'm increasingly inclined to the view that the restrictions should become attributes. > Having a "critical bit" for restrictions may be important. (this > means "fail the request if I don't know what to do with it") > > Maybe the way to go is to define restrictions as attributes with the > critical bit set? I think so. If everyone else also thinks so, I'd be happy to produce another version of my edits with this changed. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 12:17:02 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12317 for ; Thu, 24 Jul 2003 12:17:00 -0400 (EDT) Received: (qmail 21109 invoked by uid 605); 24 Jul 2003 16:16:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21092 invoked from network); 24 Jul 2003 16:16:39 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 24 Jul 2003 16:16:39 -0000 Received: by xanthine.gratuitous.org with local; Thu, 24 Jul 2003 12:16:35 -0400 From: "Joel N. Weber II" To: pgut001@cs.auckland.ac.nz (Peter Gutmann) CC: ietf-ssh@NetBSD.org In-reply-to: <200307240138.h6O1ctm30482@medusa01.cs.auckland.ac.nz> (pgut001@cs.auckland.ac.nz) Subject: Re: Implementation support for SSH_MSG_UNIMPLEMENTED References: <200307240138.h6O1ctm30482@medusa01.cs.auckland.ac.nz> Message-Id: Date: Thu, 24 Jul 2003 12:16:35 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > >Are there any implementations which do not respond with SSH_MSG_UNIMPLEMENTED > >to unknown packet types during the key exchange phase of the protocol? > > I don't, but that can be fixed if it becomes a critical requirement of the > protocol. The reason I don't is that I always send the minimal amount of info > in error returns for any protocol I do (SSH/SSL/CMP/TSP/RTCS/OCSP/etc), which > has saved me from at least two attacks on SSL and probably attacks on other > protocols as well. In other words if the protocol requires a certain response > in order to function I'll do it, but if it's merely a nicety for debugging, > I'll send the most generic response I can get away with. The text of the protocol spec says that sending SSH_MSG_UNIMPLEMENTED is mandatory, if I recall correctly. Not implementing this according to the spec makes interoperability harder when new features get added later. SSH_MSG_UNIMPLEMENTED is already fairly generic. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 12:34:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13273 for ; Thu, 24 Jul 2003 12:34:22 -0400 (EDT) Received: (qmail 2803 invoked by uid 605); 24 Jul 2003 16:34:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2789 invoked from network); 24 Jul 2003 16:34:23 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 24 Jul 2003 16:34:23 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13212; Thu, 24 Jul 2003 12:33:35 -0400 (EDT) Message-Id: <200307241633.MAA13212@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-userauth-17.txt Date: Thu, 24 Jul 2003 12:33:34 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Authentication Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-userauth-17.txt Pages : 15 Date : 2003-7-24 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-userauth-17.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-userauth-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-userauth-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-24122721.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-userauth-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-userauth-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122721.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 12:34:47 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13310 for ; Thu, 24 Jul 2003 12:34:46 -0400 (EDT) Received: (qmail 2816 invoked by uid 605); 24 Jul 2003 16:34:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2790 invoked from network); 24 Jul 2003 16:34:23 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 24 Jul 2003 16:34:23 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13252; Thu, 24 Jul 2003 12:34:06 -0400 (EDT) Message-Id: <200307241634.MAA13252@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-connect-17.txt Date: Thu, 24 Jul 2003 12:34:06 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Connection Protocol Author(s) : T. Ylonen, T. Kivinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-connect-17.txt Pages : 22 Date : 2003-7-24 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH Connection Protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connections. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-17.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-connect-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-connect-17.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-24122730.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-connect-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-connect-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122730.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 12:35:15 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13378 for ; Thu, 24 Jul 2003 12:35:12 -0400 (EDT) Received: (qmail 3839 invoked by uid 605); 24 Jul 2003 16:35:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3825 invoked from network); 24 Jul 2003 16:35:11 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 24 Jul 2003 16:35:11 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13346; Thu, 24 Jul 2003 12:35:06 -0400 (EDT) Message-Id: <200307241635.MAA13346@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-architecture-14.txt Date: Thu, 24 Jul 2003 12:35:05 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Architecture Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-architecture-14.txt Pages : 31 Date : 2003-7-24 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the architecture of the SSH protocol, as well as the notation and terminology used in SSH protocol documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy. The User Authentication Protocol authenticates the client to the server. The Connection Protocol multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-architecture-14.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-architecture-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-architecture-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-24122739.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-architecture-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-architecture-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122739.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 12:35:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13416 for ; Thu, 24 Jul 2003 12:35:29 -0400 (EDT) Received: (qmail 4046 invoked by uid 605); 24 Jul 2003 16:35:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4001 invoked from network); 24 Jul 2003 16:35:17 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 24 Jul 2003 16:35:17 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13368; Thu, 24 Jul 2003 12:35:11 -0400 (EDT) Message-Id: <200307241635.MAA13368@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-02.txt Date: Thu, 24 Jul 2003 12:35:11 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : S. Lehtinen, D. Moffat Filename : draft-ietf-secsh-assignednumbers-02.txt Pages : 10 Date : 2003-7-24 This document defines the initial state of the IANA assigned numbers for the SSH protocol as defined in [SSH-ARCH], [SSH- TRANS], [SSH-CONNECT], [SSH-USERAUTH]. This document does not define any new protocols or any number ranges not already defined in the above referenced documents. It is intended only for initalization of the IANA databases referenced in those documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-assignednumbers-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-assignednumbers-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-24122749.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122749.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 12:35:49 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13444 for ; Thu, 24 Jul 2003 12:35:48 -0400 (EDT) Received: (qmail 4170 invoked by uid 605); 24 Jul 2003 16:35:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4114 invoked from network); 24 Jul 2003 16:35:23 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 24 Jul 2003 16:35:23 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13402; Thu, 24 Jul 2003 12:35:17 -0400 (EDT) Message-Id: <200307241635.MAA13402@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-transport-16.txt Date: Thu, 24 Jul 2003 12:35:16 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Transport Layer Protocol Author(s) : T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen Filename : draft-ietf-secsh-transport-16.txt Pages : 29 Date : 2003-7-24 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH transport layer protocol which typically runs on top of TCP/IP. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. It may also provide compression. Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. This document also describes the Diffie-Hellman key exchange method and the minimal set of algorithms that are needed to implement the SSH transport layer protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-16.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-transport-16.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-transport-16.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-24122800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-transport-16.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-transport-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122800.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 13:41:07 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17403 for ; Thu, 24 Jul 2003 13:41:06 -0400 (EDT) Received: (qmail 7046 invoked by uid 605); 24 Jul 2003 17:39:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7036 invoked from network); 24 Jul 2003 17:39:25 -0000 Received: from brmea-mail-2.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 24 Jul 2003 17:39:25 -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 h6OHdO0P003434; Thu, 24 Jul 2003 11:39:24 -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 h6OHdNbO025080; Thu, 24 Jul 2003 11:39: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 h6OHaAQx011349; Thu, 24 Jul 2003 10:36:10 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6OHaAR3011348; Thu, 24 Jul 2003 10:36:10 -0700 (PDT) Date: Thu, 24 Jul 2003 10:36:09 -0700 From: Nicolas Williams To: Jon Bright Cc: Brent McClure , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted Message-ID: <20030724173607.GA11272@binky.central.sun.com> References: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> <3F1FE234.4030703@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F1FE234.4030703@siliconcircus.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 24, 2003 at 03:42:12PM +0200, Jon Bright wrote: > The big change. This is mostly Joseph's suggested text. I added > "agent", "env" and "subsystem" to the restrictions and moved > "port-forward" and "reverse-forward" to be attributes, to allow for > specification of allowed-host lists. Additionally integrated Nicolas' > suggestion regarding mandatory restrictions. Finally, added overwrite, > with behaviour as discussed. > [...] > Integrate the attribute stuff into the list response. Further, remove > the "command" request, since it's no longer useful in light of the > additional "add" functionality. Finally, add a method of discovering > the server's supported restrictions. I'm convinced this will assist in > building a sane GUI for this stuff. The split that's present between > "attributes" and "restrictions" makes the response to this request a > little messy. I'm not sure whether it would be better to make the > "restrictions" be freestanding attributes, being that they're (as far as > I can tell) all boolean. I think "from" should be added also (i.e., what source addresses a client may use this key from). Yeah, all restrictions should be standalone attributes. Those restrictions which you modeled as values of the "restrict" attributes could be standalone attributes with boolean values (or null; if the attribute is present, the restriction is on, if not, not). The "subsystem" restriction should go and be replaced by the subsystem attribute which should list the sub-systems that a user is allowed to start (if the list empty, then none are allowed; if the attribute is missing or if the value is "*", then all are allowed). Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 13:48:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18067 for ; Thu, 24 Jul 2003 13:48:40 -0400 (EDT) Received: (qmail 13719 invoked by uid 605); 24 Jul 2003 17:48:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13712 invoked from network); 24 Jul 2003 17:48:39 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 24 Jul 2003 17:48:39 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 40ABD567D; Thu, 24 Jul 2003 19:48:38 +0200 (CEST) Message-ID: <3F201BFA.3070908@siliconcircus.com> Date: Thu, 24 Jul 2003 19:48:42 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Williams Cc: Brent McClure , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted References: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> <3F1FE234.4030703@siliconcircus.com> <20030724173607.GA11272@binky.central.sun.com> In-Reply-To: <20030724173607.GA11272@binky.central.sun.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 (a side not - Brent has sent me the XML source, which I'm currently updating to match my earlier mail) Nicolas Williams wrote: > I think "from" should be added also (i.e., what source addresses a > client may use this key from). Sounds like a good idea. > Yeah, all restrictions should be standalone attributes. Those I've now converted them all to be. > restrictions which you modeled as values of the "restrict" attributes > could be standalone attributes with boolean values (or null; if the > attribute is present, the restriction is on, if not, not). I've defined them as being null. > The "subsystem" restriction should go and be replaced by the subsystem > attribute which should list the sub-systems that a user is allowed to > start (if the list empty, then none are allowed; if the attribute is > missing or if the value is "*", then all are allowed). This doesn't match the "command" attribute, which starts the command itself. Then again, I'm unhappy with that aspect of the "command" attribute's behaviour - it raises questions such as When does it start the command?, Does it wait for the client to request a pty or run the command without one?, etc. Maybe change "command" to specify a command which the user's allowed to execute. Ideally, change it to specify more than one command, but in that case, I'm not sure what could be used as a separator. Maybe allow for more than one command attribute to be set? -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 14:15:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19490 for ; Thu, 24 Jul 2003 14:15:28 -0400 (EDT) Received: (qmail 25717 invoked by uid 605); 24 Jul 2003 18:15:29 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25710 invoked from network); 24 Jul 2003 18:15:26 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 24 Jul 2003 18:15:26 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id F2ED1567D for ; Thu, 24 Jul 2003 20:15:24 +0200 (CEST) Message-ID: <3F202241.7070701@siliconcircus.com> Date: Thu, 24 Jul 2003 20:15:29 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Revised Publickey subsystem draft Content-Type: multipart/mixed; boundary="------------050602040302070706080804" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------050602040302070706080804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Brent sent me the XML source for the Publickey subsystem draft. I've integrated the changes I mentioned earlier, added a reference to RFC1766 (and changed "References" to be "Normative References") as well as converting the restrictions previously under the "restrict" attribute to be attributes, as Bill and Nicolas suggested. Attached is the text of the updated version. I have two questions: a) Does anyone have some suggested text for a security considerations section? That the protocol assumes it's running over a secure transport layer would seem to be fairly standard, for starters. b) Bill, did you decide to make this a WG work item? If so, should the subsystem name remain as "publickey@vandyke.com" or should it just become "publickey"? -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com --------------050602040302070706080804 Content-Type: text/plain; name="draft-galb-secsh-publickey-subsystem.txt" Content-Disposition: inline; filename="draft-galb-secsh-publickey-subsystem.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Expires: January 22, 2004 B. McClure VanDyke Software J. Bright Silicon Circus July 24, 2003 Secure Shell Public-Key Subsystem draft-galb-secsh-publickey-subsystem-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 22, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting a Galbraith, et al. Expires January 22, 2004 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Shell or a Command''. The subsystem name used with this protocol is "publickey@vandyke.com". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . 4 2.1 Opening the Public-Key Subsystem . . . . . . . . . . . . . . 4 2.2 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 The Status Response . . . . . . . . . . . . . . . . . . . . 5 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . 7 3.1 Version Packet . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Adding a public key . . . . . . . . . . . . . . . . . . . . 7 3.3 Removing a public key . . . . . . . . . . . . . . . . . . . 10 3.4 Listing public keys . . . . . . . . . . . . . . . . . . . . 10 3.5 Listing server capabilities . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . 14 Galbraith, et al. Expires January 22, 2004 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem July 2003 1. Introduction SECSH is a protocol for secure remote login and other secure network services over an insecure network. SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the SECSH transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the SECSH architecture [1] and SECSH connection [4] documents. This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires January 22, 2004 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem July 2003 2. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey@vandyke.com". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in the SSH Transport Protocol document [2]. 2.1 Opening the Public-Key Subsystem The public-key subsystem is opened when the clients sends a SSH_MSG_CHANNEL_REQUEST over an existing session. The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session". To open the public-key subsystem, the client sends: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey@vandyke.com" Client implementations SHOULD reject this request; it is normally only sent by the client. If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user authenticated with a restricted public key that does not allow access to the publickey subsystem. It is RECOMMENDED that clients request and check the reply for this request. Galbraith, et al. Expires January 22, 2004 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem July 2003 2.2 Requests All public-key subsystem requests are sent in the following form: uint32 length string request-name ... request specific data follows The length field describes the length of the request-name field and the request-specific data, but not of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request. All requests described in Section 3 are a description of the 'request-name' and 'data' portion of the packet. 2.3 Responses All public-key subsystem responses are sent in the following form: uint32 length string response-name ... response specific data follows 2.3.1 The Status Response A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. string "status" uint32 status code string description [RFC-2279] string language tag [RFC-1766] A status message MUST be sent for any unrecognized packets and the request SHOULD NOT close the subsystem. 2.3.1.1 Status Codes The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 3 Galbraith, et al. Expires January 22, 2004 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem July 2003 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 Galbraith, et al. Expires January 22, 2004 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem July 2003 3. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and command. 3.1 Version Packet Both sides MUST start by sending a version packet that indicates the version of the protocol they are using. string "version" uint32 protocol-version-number The version of the protocol described by this document is version 1. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Both sides MUST wait to receive this version before continuing. 3.2 Adding a public key If the client wishes to add a public key, the client sends: string "add" string public-key algorithm name string public-key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED Attribute names are defined following the same scheme laid out for Galbraith, et al. Expires January 22, 2004 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem July 2003 algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add. For the purposes of a mandatory attribute, storage of the attribute is not sufficient, but requires that the server understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [6]. The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be mandatory. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specifies the language for that attribute [5]. The client MAY specify more than comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment, together with that comment's lanuage attribute. This attribute SHOULD NOT be mandatory. "command" "command" specifies a command which the may be executed (via the "exec" channel request) when this key is in use. More than one "command" attribute may be specified. This attribute SHOULD be mandatory. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be mandatory. If the value is empty, no subsystems may be started. "x11" "x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. Galbraith, et al. Expires January 22, 2004 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem July 2003 "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "exec" "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorisation purposes, the authorisation attempt MUST be denied. The server SHOULD make a log entry regarding this. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except to those hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be mandatory. "reverse-forward" "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, accept for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be mandatory. Galbraith, et al. Expires January 22, 2004 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem July 2003 In addition to the attributes specified by the client, the server MAY provide a method for administrators to compulsorily enforce certain attributes. 3.3 Removing a public key If the client wishes to remove a public key, the client sends: string "remove" string public-key algorithm name string public-key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. 3.4 Listing public keys If the client wishes to list the known public keys, the client sends: string "list" The server will respond with zero or more of the following responses: string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times Following the last "publickey" response, a status packet MUST be sent. An implementation MAY choose not to support this request. 3.5 Listing server capabilities If the client wishes to know which key attributes the server supports, it sends: string "listattributes" The server will respond with zero or more of the following responses: string "attribute" string attribute name Galbraith, et al. Expires January 22, 2004 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem July 2003 boolean compulsory The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. Following the last "attribute" response, a status packet MUST be sent. An implementation MAY choose not to support this request. Galbraith, et al. Expires January 22, 2004 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Normative References [1] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-13 (work in progress), January 2002. [2] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh-transport-15 (work in progress), March 2002. [3] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-16 (work in progress), February 2002. [4] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 (work in progress), January 2002. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb-list@vandyke.com Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: jpv@vandyke.com Galbraith, et al. Expires January 22, 2004 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: bdm@vandyke.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 EMail: jon@siliconcircus.com Galbraith, et al. Expires January 22, 2004 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Galbraith, et al. Expires January 22, 2004 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem July 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith, et al. Expires January 22, 2004 [Page 15] --------------050602040302070706080804-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 14:27:41 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20044 for ; Thu, 24 Jul 2003 14:27:39 -0400 (EDT) Received: (qmail 2206 invoked by uid 605); 24 Jul 2003 18:27:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2199 invoked from network); 24 Jul 2003 18:27:36 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 24 Jul 2003 18:27:36 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1731380; Thu, 24 Jul 2003 12:27:35 -0600 Message-ID: <3F2024B1.8000806@vandyke.com> Date: Thu, 24 Jul 2003 12:25:53 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Jon Bright CC: Nicolas Williams , Brent McClure , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted References: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> <3F1FE234.4030703@siliconcircus.com> <20030724173607.GA11272@binky.central.sun.com> <3F201BFA.3070908@siliconcircus.com> In-Reply-To: <3F201BFA.3070908@siliconcircus.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 > This doesn't match the "command" attribute, which starts the command > itself. Then again, I'm unhappy with that aspect of the "command" > attribute's behaviour - it raises questions such as When does it start > the command?, Does it wait for the client to request a pty or run the > command without one?, etc. Maybe change "command" to specify a command > which the user's allowed to execute. Ideally, change it to specify more > than one command, but in that case, I'm not sure what could be used as a > separator. Maybe allow for more than one command attribute to be set? If I'm not mistaken openssh allows a command to be associated with the key? I believe ssh.com and f-secure do as well. Does any one know what their behavior is? I was thinking that whenever one of exec / shell where issued, the command specified by the publickey was substituted. But maybe that isn't the case. If we really wanted allowed commands, and I'm not sure we do, the attrib-value string could be: string attrib-value uint32 command-count string command[1] string command[2] string command[...] string command[command-count] But, how closely doe the user have to match the command? Exactly? Just the first argument? I'm worried about over complexifying things... sure we could do it, but one of the goals of the subsystem is to be easy to implement. Maybe we should rename command to command-override and specify that it forces either the 'exec' or the 'shell' session channel requests to act as if the 'exec' request had been issued with the given command. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 14:34:04 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20518 for ; Thu, 24 Jul 2003 14:34:02 -0400 (EDT) Received: (qmail 5463 invoked by uid 605); 24 Jul 2003 18:34:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5145 invoked from network); 24 Jul 2003 18:33:57 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 24 Jul 2003 18:33:57 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20470; Thu, 24 Jul 2003 14:33:08 -0400 (EDT) Message-Id: <200307241833.OAA20470@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@NetBSD.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-dh-group-exchange-04.txt Date: Thu, 24 Jul 2003 14:33:07 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol Author(s) : M. Friedl, N. Provos, W. Simpson Filename : draft-ietf-secsh-dh-group-exchange-04.txt Pages : 8 Date : 2003-7-24 This memo describes a new key exchange method for the SSH protocol. It allows the SSH server to propose to the client new groups on which to perform the Diffie-Hellman key exchange. The proposed groups need not be fixed and can change with time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-dh-group-exchange-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-dh-group-exchange-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-24122712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dh-group-exchange-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dh-group-exchange-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-24122712.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 14:35:34 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20640 for ; Thu, 24 Jul 2003 14:35:26 -0400 (EDT) Received: (qmail 6182 invoked by uid 605); 24 Jul 2003 18:35:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6175 invoked from network); 24 Jul 2003 18:35:20 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 24 Jul 2003 18:35:20 -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 h6OIZKLL020178; Thu, 24 Jul 2003 11:35:20 -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 h6OIZJcm010680; Thu, 24 Jul 2003 12:35:19 -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 h6OIW6Qx011391; Thu, 24 Jul 2003 11:32:06 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6OIW6t1011390; Thu, 24 Jul 2003 11:32:06 -0700 (PDT) Date: Thu, 24 Jul 2003 11:32:06 -0700 From: Nicolas Williams To: Jon Bright Cc: Brent McClure , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted Message-ID: <20030724183206.GV8917@binky.central.sun.com> References: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> <3F1FE234.4030703@siliconcircus.com> <20030724173607.GA11272@binky.central.sun.com> <3F201BFA.3070908@siliconcircus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F201BFA.3070908@siliconcircus.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 24, 2003 at 07:48:42PM +0200, Jon Bright wrote: > Nicolas Williams wrote: > >The "subsystem" restriction should go and be replaced by the subsystem > >attribute which should list the sub-systems that a user is allowed to > >start (if the list empty, then none are allowed; if the attribute is > >missing or if the value is "*", then all are allowed). > > This doesn't match the "command" attribute, which starts the command > itself. Then again, I'm unhappy with that aspect of the "command" > attribute's behaviour - it raises questions such as When does it start > the command?, Does it wait for the client to request a pty or run the > command without one?, etc. Maybe change "command" to specify a command > which the user's allowed to execute. Ideally, change it to specify more > than one command, but in that case, I'm not sure what could be used as a > separator. Maybe allow for more than one command attribute to be set? The "command" attribute should apply to "session" type channels and should be executed when the "exec" or "shell" channel requests are processed. If a null "command" is given then neither should be allowed. If no "command" is given both should be allowed. The "subsystem" attribute should apply to "session" type channels when the "subsystem" requests are processed. If a null "subsystem" is given then none should be allowed. If no "subsystem" is given then any should be allowed. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 14:40:50 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20822 for ; Thu, 24 Jul 2003 14:40:49 -0400 (EDT) Received: (qmail 9276 invoked by uid 605); 24 Jul 2003 18:40:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9264 invoked from network); 24 Jul 2003 18:40:37 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 24 Jul 2003 18:40:37 -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 h6OIebFW011224; Thu, 24 Jul 2003 11:40:37 -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 h6OIeacm012231; Thu, 24 Jul 2003 12:40: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 h6OIbMQx011398; Thu, 24 Jul 2003 11:37:22 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6OIbMEn011397; Thu, 24 Jul 2003 11:37:22 -0700 (PDT) Date: Thu, 24 Jul 2003 11:37:22 -0700 From: Nicolas Williams To: Joseph Galbraith Cc: Jon Bright , Brent McClure , ietf-ssh@NetBSD.org Subject: Re: Publickey subsystem draft posted Message-ID: <20030724183722.GW8917@binky.central.sun.com> References: <005101c3458d$d2ca89a0$4900a8c0@galb.vandyke.com> <3F1FE234.4030703@siliconcircus.com> <20030724173607.GA11272@binky.central.sun.com> <3F201BFA.3070908@siliconcircus.com> <3F2024B1.8000806@vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F2024B1.8000806@vandyke.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Thu, Jul 24, 2003 at 12:25:53PM -0600, Joseph Galbraith wrote: > >This doesn't match the "command" attribute, which starts the command > >itself. Then again, I'm unhappy with that aspect of the "command" > >attribute's behaviour - it raises questions such as When does it start > >the command?, Does it wait for the client to request a pty or run the > >command without one?, etc. Maybe change "command" to specify a command > >which the user's allowed to execute. Ideally, change it to specify more > >than one command, but in that case, I'm not sure what could be used as a > >separator. Maybe allow for more than one command attribute to be set? > > If I'm not mistaken openssh allows a command to be associated > with the key? I believe ssh.com and f-secure do as well. > > Does any one know what their behavior is? I was thinking that > whenever one of exec / shell where issued, the command specified > by the publickey was substituted. But maybe that isn't the case. That's exactly it. > Maybe we should rename command to command-override and > specify that it forces either the 'exec' or the 'shell' > session channel requests to act as if the 'exec' request > had been issued with the given command. That's how we should define its semantics. Cheers, Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 15:33:53 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26433 for ; Thu, 24 Jul 2003 15:33:52 -0400 (EDT) Received: (qmail 9908 invoked by uid 605); 24 Jul 2003 19:33:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9900 invoked from network); 24 Jul 2003 19:33:52 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 24 Jul 2003 19:33:52 -0000 Received: by xanthine.gratuitous.org with local; Thu, 24 Jul 2003 15:33:51 -0400 From: "Joel N. Weber II" To: ietf-ssh@NetBSD.org Subject: [Jeffrey Hutzelman : Re: Implementation support for SSH_MSG_UNIMPLEMENTED] Message-Id: Date: Thu, 24 Jul 2003 15:33:51 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list [jhutz said I could forward this to the list.] ------- Start of forwarded message ------- Date: Thu, 24 Jul 2003 13:30:52 -0400 From: Jeffrey Hutzelman To: "Joel N. Weber II" Subject: Re: Implementation support for SSH_MSG_UNIMPLEMENTED Content-Disposition: inline On Thursday, July 24, 2003 12:16:35 -0400 "Joel N. Weber II" wrote: >> > Are there any implementations which do not respond with >> > SSH_MSG_UNIMPLEMENTED to unknown packet types during the key exchange >> > phase of the protocol? >> >> I don't, but that can be fixed if it becomes a critical requirement of >> the protocol. The reason I don't is that I always send the minimal >> amount of info in error returns for any protocol I do >> (SSH/SSL/CMP/TSP/RTCS/OCSP/etc), which has saved me from at least two >> attacks on SSL and probably attacks on other protocols as well. In >> other words if the protocol requires a certain response in order to >> function I'll do it, but if it's merely a nicety for debugging, I'll >> send the most generic response I can get away with. > > The text of the protocol spec says that sending SSH_MSG_UNIMPLEMENTED > is mandatory, if I recall correctly. Not implementing this according > to the spec makes interoperability harder when new features get added > later. It's actually fairly important to send SSH_MSG_UNIMPLEMENTED when you get a message you don't understand. This is a critical extensibility mechanism - -- a peer may send you a message which requires a response, and adjust his behavior based on whether the response is SSH_MSG_UNIMPLEMENTED or some other message mandated by the extension he's following. If you just send nothing, he can't distinguish your behavior from that of a peer which supports the extension but is starved for CPU cycles or whatever. ------- End of forwarded message ------- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 24 15:39:10 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26623 for ; Thu, 24 Jul 2003 15:39:09 -0400 (EDT) Received: (qmail 12505 invoked by uid 605); 24 Jul 2003 19:39:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12498 invoked from network); 24 Jul 2003 19:39:10 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 24 Jul 2003 19:39:10 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6OJd9LL025070 for ; Thu, 24 Jul 2003 12:39:10 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6OJd8fM020863 for ; Thu, 24 Jul 2003 15:39:08 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6OJd88Q015537 for ; Thu, 24 Jul 2003 15:39:08 -0400 (EDT) Message-Id: <200307241939.h6OJd88Q015537@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Working group LAST CALL on draft-ietf-secsh-dh-group-exchange-04.txt Reply-to: sommerfeld@east.sun.com Date: Thu, 24 Jul 2003 15:39:08 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This message marks the start of a two week WORKING GROUP LAST CALL on Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol draft-ietf-secsh-dh-group-exchange-04.txt prior to review by the IETF and IESG for publication as a Proposed Standard. Please send comments to ietf-ssh@netbsd.org by August 8th, 2003. Notes to reviewers: I asserted that there was a previous WGLC on this document but I can't find any evidence of this in my own mail archives. Just to be safe, I'm starting this now.. Sorry for any confusion. This document was recently reissued with a few nits fixed but has been basically stable for a while, queued up behind the core drafts. I believe there are implementations of this extension in widespread use; implementors should speak up about their implementation and interop experience (while this is not a requirement for Proposed Standard, it's always good to get a few positive comments during a Last Call period..) - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 03:37:31 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27307 for ; Fri, 25 Jul 2003 03:37:31 -0400 (EDT) Received: (qmail 27115 invoked by uid 605); 25 Jul 2003 07:33:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27108 invoked from network); 25 Jul 2003 07:33:37 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 25 Jul 2003 07:33:37 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6P7XSs1009344; Fri, 25 Jul 2003 19:33:28 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6P7XSj14725; Fri, 25 Jul 2003 19:33:28 +1200 Date: Fri, 25 Jul 2003 19:33:28 +1200 Message-Id: <200307250733.h6P7XSj14725@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-secsh@joelweber.com, ietf-ssh@NetBSD.org Subject: Re: [Jeffrey Hutzelman : Re: Implementation support for SSH_MSG_UNIMPLEMENTED] Sender: ietf-ssh-owner@NetBSD.org Precedence: list Jeffrey Hutzelman (via "Joel N. Weber II" ) writes: >It's actually fairly important to send SSH_MSG_UNIMPLEMENTED when you get a >message you don't understand. Right, but you're now acting as an oracle for an attacker by responding to corrupted encrypted data differently depending on what the corruption is, which is the exact problem that has hit SSL (several times). I guess I can respond with an "unimplemented" during the (non-secured) initial portions of the handshake, but I think I'll stick with my generic "Sod off Baldrick" response once things are encrypted, until there's an urgent need to do otherwise. Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 03:51:59 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27782 for ; Fri, 25 Jul 2003 03:51:58 -0400 (EDT) Received: (qmail 7232 invoked by uid 605); 25 Jul 2003 07:52:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7222 invoked from network); 25 Jul 2003 07:51:59 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 25 Jul 2003 07:51:59 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 0E595567D; Fri, 25 Jul 2003 09:51:58 +0200 (CEST) Message-ID: <3F20E1A5.5080409@siliconcircus.com> Date: Fri, 25 Jul 2003 09:52:05 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Gutmann Cc: ietf-ssh@joelweber.com, ietf-ssh@NetBSD.org Subject: Re: [Jeffrey Hutzelman : Re: Implementation support for SSH_MSG_UNIMPLEMENTED] References: <200307250733.h6P7XSj14725@medusa01.cs.auckland.ac.nz> In-Reply-To: <200307250733.h6P7XSj14725@medusa01.cs.auckland.ac.nz> 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 Peter Gutmann wrote: > Jeffrey Hutzelman (via "Joel N. Weber II" ) writes: > > >>It's actually fairly important to send SSH_MSG_UNIMPLEMENTED when you get a >>message you don't understand. > > > Right, but you're now acting as an oracle for an attacker by responding to > corrupted encrypted data differently depending on what the corruption is, > which is the exact problem that has hit SSL (several times). I guess I can > respond with an "unimplemented" during the (non-secured) initial portions of > the handshake, but I think I'll stick with my generic "Sod off Baldrick" > response once things are encrypted, until there's an urgent need to do > otherwise. Erm, you already respond differently to corrupted encrypted data depending on what the corruption is. Or don't you look at the message type field of a packet? Aside from that, you have a MAC to tell you whether the data's corrupted? -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 09:00:06 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03708 for ; Fri, 25 Jul 2003 09:00:05 -0400 (EDT) Received: (qmail 21812 invoked by uid 605); 25 Jul 2003 12:59:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21780 invoked from network); 25 Jul 2003 12:59:13 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 25 Jul 2003 12:59:13 -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 h6PCtQOc017258 for ; Fri, 25 Jul 2003 14:55:27 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 185CB2D004; Fri, 25 Jul 2003 14:55:21 +0200 (CEST) X-Original-To: markus@localhost Delivered-To: markus@localhost.informatik.uni-erlangen.de Received: from localhost (localhost [127.0.0.1]) by folly.informatik.uni-erlangen.de (Postfix) with ESMTP id 4B5EA2D048 for ; Wed, 23 Jul 2003 13:25:37 +0200 (CEST) Received: from 127.0.0.1 [127.0.0.1] by localhost with POP3 (fetchmail-6.2.2) for markus@localhost (single-drop); Wed, 23 Jul 2003 13:25:37 +0200 (CEST) Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.34.45]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h6NBKZOc027043 for ; Wed, 23 Jul 2003 13:20:35 +0200 (CEST) Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by faui45.informatik.uni-erlangen.de (8.9.3p2/8.1.49-FAU) with ESMTP id NAA19253 for ; Wed, 23 Jul 2003 13:20:33 +0200 (MET DST) Received: from openbsd.cs.colorado.edu (openbsd.cs.colorado.edu [128.138.192.83]) by cvs.openbsd.org (8.12.9/8.12.1) with ESMTP id h6NBLOf4022970 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=FAIL) for ; Wed, 23 Jul 2003 05:21:25 -0600 (MDT) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by openbsd.cs.colorado.edu (8.12.9/8.12.9) with SMTP id h6NBJFPp017895 for ; Wed, 23 Jul 2003 05:19:16 -0600 (MDT) Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa15720; 23 Jul 2003 7:19 EDT Date: Wed, 23 Jul 2003 07:19:12 -0400 From: Jeffrey Hutzelman To: Markus Friedl Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <6610000.1058959152@mariner.pc.cs.cmu.edu> In-Reply-To: <20030723075724.GD7060@folly> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: M_!!g;n"!3n<"! X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, July 23, 2003 09:57:24 +0200 Markus Friedl wrote: > On Tue, Jul 22, 2003 at 03:44:42PM -0700, Nicolas Williams wrote: >> I think the fact that some implementations do not tolerate KEXINIT >> "extensions" should not precluse the proposed change. Several >> implementations already map the peer's version string to compatibility >> notes and react accordingly. While I hope that we can put stop adding >> to this database of compatibility notes I think that this particular >> issue (KEXINIT extensibility) is worth the trouble to fix. > > I don't think it's a good idea to break the protocol at > this point. This compatibility database is always a pain > and you always miss some implementations. > > I think you could only assume that the peer is able to deal with > the extension if it sends a non-zero value in the reserved field, > but I doubt this helps for what you want. On the other hand, you > could send the extension data in an extra packet if the reserved byte > is not zero. Actually, I think that would work. Based on what people have said about what implementations do, I will suggest that the core transport draft specify the following behavior: - MUST send 0 in the KEXINIT reserved field - MUST ignored the received value in the KEXINIT reserved field - MUST NOT add any fields after the reserved field - MAY reject KEXINIT packets with extra fields At which point we can (in a later document) use the reserved field to indicate support for extensions, which are then negotiated in a separate exchange of packets after the KEXINIT messages have been received. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 09:23:39 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04252 for ; Fri, 25 Jul 2003 09:23:39 -0400 (EDT) Received: (qmail 8275 invoked by uid 605); 25 Jul 2003 13:23:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8268 invoked from network); 25 Jul 2003 13:23:26 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 25 Jul 2003 13:23:26 -0000 Received: from home (dpm1-37.swcp.com [204.134.5.38]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6PDNNWx086615; Fri, 25 Jul 2003 07:23:24 -0600 (MDT) Message-ID: <001601c352af$c2a12140$260586cc@swcp.com> From: "Brent McClure" To: "Jon Bright" , References: <3F202241.7070701@siliconcircus.com> Subject: Re: Revised Publickey subsystem draft Date: Fri, 25 Jul 2003 07:22:11 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-1.0 required=10.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > a) Does anyone have some suggested text for a security considerations > section? That the protocol assumes it's running over a secure transport > layer would seem to be fairly standard, for starters. What about this for a first pass on Security Considerations. Note, this text is inspired by and almost identical to similar statements in SFTP's security considerations: This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [8]. I was wondering also if something needs to be said about users applying/erasing "command" attributes in such a way that the publickey subsystem might be used by a user to override some restrictions on that user's account that an administrator thought were securely in place. eg. Once authenticated with a key that always execs some restricted command shell, the user then uploads a key that has no such restictions. I'm not really sure if this is how this "command" feature is used by admins on servers that support it, but if it were the case then perhaps some language about implementations needing to allow configuration to disable access to this subsystem for such users. OTOH, maybe the second paragraph above covers that. --Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 09:35:54 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04477 for ; Fri, 25 Jul 2003 09:35:53 -0400 (EDT) Received: (qmail 14366 invoked by uid 605); 25 Jul 2003 13:35:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14358 invoked from network); 25 Jul 2003 13:35:54 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 25 Jul 2003 13:35:54 -0000 Received: from home (dpm1-37.swcp.com [204.134.5.38]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6PDZoWx093602; Fri, 25 Jul 2003 07:35:51 -0600 (MDT) Message-ID: <003701c352b1$803a4fa0$260586cc@swcp.com> From: "Brent McClure" To: "Jon Bright" , References: <3F202241.7070701@siliconcircus.com> Subject: Re: Revised Publickey subsystem draft Date: Fri, 25 Jul 2003 07:34:39 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Status: No, hits=-1.0 required=10.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > 3.1 Version Packet > > Both sides MUST start by sending a version packet that indicates the > version of the protocol they are using. > > string "version" > uint32 protocol-version-number > > The version of the protocol described by this document is version 1. > > Both sides send the highest version that they implement. The lower of > the version numbers is the version of the protocol to use. If either > side can't support the lower version, it should close the subsystem > and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE > message. > > Both sides MUST wait to receive this version before continuing. I think we need to bump the version to 2. I also just remembered something that I found awkward about the current protocol: If there is a version mismatch then the channel gets slammed shut with no opportunity to communicate what the problem was to the other side. It would be nice to allow for shoving a status packet down the channel indicating a version mismatch before sending the SSH_MSG_CHANNEL_CLOSE. This would be a benefit both to clients trying to figure out why their channel won't open or to admins reading through a server log. --Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 09:42:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04751 for ; Fri, 25 Jul 2003 09:42:55 -0400 (EDT) Received: (qmail 18588 invoked by uid 605); 25 Jul 2003 13:42:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18581 invoked from network); 25 Jul 2003 13:42:56 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 25 Jul 2003 13:42:56 -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 h6PDdAOc019008 for ; Fri, 25 Jul 2003 15:39:10 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id C2BEF2D004; Fri, 25 Jul 2003 15:39:04 +0200 (CEST) X-Original-To: markus@localhost Delivered-To: markus@localhost.informatik.uni-erlangen.de Received: from localhost (localhost [127.0.0.1]) by folly.informatik.uni-erlangen.de (Postfix) with ESMTP id 4B5EA2D048 for ; Wed, 23 Jul 2003 13:25:37 +0200 (CEST) Received: from 127.0.0.1 [127.0.0.1] by localhost with POP3 (fetchmail-6.2.2) for markus@localhost (single-drop); Wed, 23 Jul 2003 13:25:37 +0200 (CEST) Received: from faui45.informatik.uni-erlangen.de (root@faui45.informatik.uni-erlangen.de [131.188.34.45]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h6NBKZOc027043 for ; Wed, 23 Jul 2003 13:20:35 +0200 (CEST) Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by faui45.informatik.uni-erlangen.de (8.9.3p2/8.1.49-FAU) with ESMTP id NAA19253 for ; Wed, 23 Jul 2003 13:20:33 +0200 (MET DST) Received: from openbsd.cs.colorado.edu (openbsd.cs.colorado.edu [128.138.192.83]) by cvs.openbsd.org (8.12.9/8.12.1) with ESMTP id h6NBLOf4022970 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=FAIL) for ; Wed, 23 Jul 2003 05:21:25 -0600 (MDT) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by openbsd.cs.colorado.edu (8.12.9/8.12.9) with SMTP id h6NBJFPp017895 for ; Wed, 23 Jul 2003 05:19:16 -0600 (MDT) Received: from MARINER.PC.CS.CMU.EDU ([128.2.200.130]) by minbar.fac.cs.cmu.edu id aa15720; 23 Jul 2003 7:19 EDT Date: Wed, 23 Jul 2003 07:19:12 -0400 From: Jeffrey Hutzelman To: Markus Friedl Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <6610000.1058959152@mariner.pc.cs.cmu.edu> In-Reply-To: <20030723075724.GD7060@folly> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: M_!!g;n"!3n<"! X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Wednesday, July 23, 2003 09:57:24 +0200 Markus Friedl wrote: > On Tue, Jul 22, 2003 at 03:44:42PM -0700, Nicolas Williams wrote: >> I think the fact that some implementations do not tolerate KEXINIT >> "extensions" should not precluse the proposed change. Several >> implementations already map the peer's version string to compatibility >> notes and react accordingly. While I hope that we can put stop adding >> to this database of compatibility notes I think that this particular >> issue (KEXINIT extensibility) is worth the trouble to fix. > > I don't think it's a good idea to break the protocol at > this point. This compatibility database is always a pain > and you always miss some implementations. > > I think you could only assume that the peer is able to deal with > the extension if it sends a non-zero value in the reserved field, > but I doubt this helps for what you want. On the other hand, you > could send the extension data in an extra packet if the reserved byte > is not zero. Actually, I think that would work. Based on what people have said about what implementations do, I will suggest that the core transport draft specify the following behavior: - MUST send 0 in the KEXINIT reserved field - MUST ignored the received value in the KEXINIT reserved field - MUST NOT add any fields after the reserved field - MAY reject KEXINIT packets with extra fields At which point we can (in a later document) use the reserved field to indicate support for extensions, which are then negotiated in a separate exchange of packets after the KEXINIT messages have been received. -- Jeffrey T. Hutzelman (N3NHS) Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 09:48:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03709 for ; Fri, 25 Jul 2003 09:00:05 -0400 (EDT) Received: (qmail 21793 invoked by uid 605); 25 Jul 2003 12:59:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21779 invoked from network); 25 Jul 2003 12:59:13 -0000 Received: from faui03.informatik.uni-erlangen.de (131.188.30.103) by mail.netbsd.org with SMTP; 25 Jul 2003 12:59:13 -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 h6PCtQOc017259 for ; Fri, 25 Jul 2003 14:55:27 +0200 (CEST) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 335DD2D006; Fri, 25 Jul 2003 14:55:21 +0200 (CEST) X-Original-To: markus@localhost Delivered-To: markus@localhost.arcor.net Received: from localhost (unknown [127.0.0.1]) by localhost.arcor.net (Postfix) with ESMTP id 22E462D004 for ; Thu, 24 Jul 2003 20:16:51 +0200 (CEST) Received: from 127.0.0.1 [127.0.0.1] by localhost with POP3 (fetchmail-6.2.2) for markus@localhost (single-drop); Thu, 24 Jul 2003 20:16:51 +0200 (CEST) Received: from faui45.informatik.uni-erlangen.de (root@fauern.informatik.uni-erlangen.de [131.188.34.45]) by faui03.informatik.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h6OHesOc017759 for ; Thu, 24 Jul 2003 19:40:54 +0200 (CEST) Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by faui45.informatik.uni-erlangen.de (8.9.3p2/8.1.49-FAU) with ESMTP id TAA26551 for ; Thu, 24 Jul 2003 19:40:52 +0200 (MET DST) Received: from openbsd.cs.colorado.edu (openbsd.cs.colorado.edu [128.138.192.83]) by cvs.openbsd.org (8.12.9/8.12.1) with ESMTP id h6OHfnf4006669 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=FAIL) for ; Thu, 24 Jul 2003 11:41:50 -0600 (MDT) Received: from minbar.fac.cs.cmu.edu (MINBAR.FAC.CS.CMU.EDU [128.2.185.161]) by openbsd.cs.colorado.edu (8.12.9/8.12.9) with SMTP id h6OHdXPp001318 for ; Thu, 24 Jul 2003 11:39:34 -0600 (MDT) Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa23838; 24 Jul 2003 13:39 EDT Date: Thu, 24 Jul 2003 13:39:08 -0400 From: Jeffrey Hutzelman To: Markus Friedl Subject: Re: Transport I-D: KEXINIT reserved field needs description Message-ID: <225230000.1059068348@minbar.fac.cs.cmu.edu> In-Reply-To: <20030724075128.GA1887@folly> References: <20030721221742.GI8917@binky.central.sun.com> <20030722224439.GA10045@binky.central.sun.com> <20030723075724.GD7060@folly> <20030723150037.GD8917@binky.central.sun.com> <20030724075128.GA1887@folly> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Type: text/plain; charset=us-ascii; format=flowed X-UIDL: [NV"!'b(#!4I+!!]D>!! X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit > yes, that's why it's dangerous and it's likely that you miss versions > strings. you should not depend on this and break the protocol this late. I have to agree with Markus here. Implementations may wish to maintain information about noncompliant implementations, but that should never be required or even suggested as a way to implement the protocol correctly. Given a choice between "do X unless the peer is broken, in which case we do Y, which works with all peers" and "always do Y, which works with all peers", the first is only acceptable if there is a pretty compelling reason why you'd want to do X. In the present case, there is a clear way to specify the extension such that a correct implementation will work with existing implementations that do not support the extension, regardless of whether they can handle extra fields in the KEXINIT packet -- don't send any such fields, and trade a second set of messages instead. Of course, we do still need to update the transport document to specify that its implementations MUST NOT consider the contents of the reserved field in deciding whether a KEXINIT packet is valid, but MUST include its actual contents in the hash anyway. Fortunately, it sounds like all the existing implementations behave this way anyway. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 10:10:24 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06119 for ; Fri, 25 Jul 2003 10:10:23 -0400 (EDT) Received: (qmail 4145 invoked by uid 605); 25 Jul 2003 14:10:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4106 invoked from network); 25 Jul 2003 14:10:22 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 25 Jul 2003 14:10:22 -0000 Received: from [127.0.0.1] (HELO vandyke.com) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 1733034; Fri, 25 Jul 2003 08:10:21 -0600 Message-ID: <3F2139E5.5090902@vandyke.com> Date: Fri, 25 Jul 2003 08:08:37 -0600 From: Joseph Galbraith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Brent McClure CC: Jon Bright , ietf-ssh@NetBSD.org Subject: Re: Revised Publickey subsystem draft References: <3F202241.7070701@siliconcircus.com> <003701c352b1$803a4fa0$260586cc@swcp.com> In-Reply-To: <003701c352b1$803a4fa0$260586cc@swcp.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 Brent McClure wrote: >>3.1 Version Packet >> >> Both sides MUST start by sending a version packet that indicates the >> version of the protocol they are using. >> >> string "version" >> uint32 protocol-version-number >> >> The version of the protocol described by this document is version 1. >> >> Both sides send the highest version that they implement. The lower of >> the version numbers is the version of the protocol to use. If either >> side can't support the lower version, it should close the subsystem >> and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE >> message. >> >> Both sides MUST wait to receive this version before continuing. > > > I think we need to bump the version to 2. > > I also just remembered something that I found awkward about the current protocol: > > If there is a version mismatch then the channel gets slammed shut with no > opportunity to communicate what the problem was to the other side. It would > be nice to allow for shoving a status packet down the channel indicating > a version mismatch before sending the SSH_MSG_CHANNEL_CLOSE. This would > be a benefit both to clients trying to figure out why their channel won't > open or to admins reading through a server log. This occurs if one of the sides has dropped support for older versions, and the other side is still using an older version. In this case, the newer-versioned implementation has no choice but to close the channel (it can't communicate with the older version.) The older version will just assume that, as per the spec, the new version will downgrade to talk to it. So, if and only if, the newer-version is willing to keep support for sending status packets for all older versions, we could allow either side to send a status packet at any time describing a general failure of some sort, and followed immeadiately by a channel close. Perhaps we should create a new message that is only sent during a general failure (i.e, when the failure is not the failure of a given request.) If we are going to add a message to handle this case, I think I need to be able to tell the difference between 'the command you just sent failed' and 'there was a general failure, not related to the command you just sent, which in fact, I haven't yet recieved, but you don't know that.' So, maybe: string "general-failure" uint32 reason-code [same as for status] string human-readable-variant string language Either side may send "general-failure" at any time during the session. "general-failure" MUST NOT be sent in response to a request, unless the request itself is malformed (a protocol conformance failure.) "general-failure" MUST always be followed immediately by the channel closing. "general-failure" is used to indicate failure on either side that is not related to request processing, but that requires communication to be aborted. One example of such failure is the case where one of the sides does not support the version of the other side. Another example is protocol failures, such as short packets, malformed packets, etc. This message MUST NOT be sent in response to a well formed, but unrecognized request. In this case, 'well formed' means that the packet length was at least long enough to hold the request string itself. A server or client MAY also send this message in response to a termination signal. The purpose of this message is to give users and administrators more information with which to troubleshoot a failure. Implementations of version 1 will not be able to recieve this message, so this only helps if version 2 becomes obsolete. On a different note, we might want to restrict to request names to us-ascii (probably the same subset used by DNS.) This would allow better detection of protocol error vs. unrecognized request. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 11:16:23 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08823 for ; Fri, 25 Jul 2003 11:16:23 -0400 (EDT) Received: (qmail 7753 invoked by uid 605); 25 Jul 2003 15:15:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7746 invoked from network); 25 Jul 2003 15:15:10 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 25 Jul 2003 15:15:10 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6PFF8Wx067308 for ; Fri, 25 Jul 2003 09:15:08 -0600 (MDT) Message-ID: <000b01c352bf$4b2fc980$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: Subject: PublicKeyFile Format Security Considerations Date: Fri, 25 Jul 2003 09:13:24 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=10.0 tests=none version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit I'm wondering if the following is a sufficient statement for the security considerations of the "SSH Public Key File Format" document: ----- Security Considerations There are no known security issues raised by this document. ----- I mulled over a couple possibilities such as cautions about parsing illegal UTF-8, but wasn't sure how that might constitute a security issue. Any other ideas? thanks, Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 11:31:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09296 for ; Fri, 25 Jul 2003 11:31:21 -0400 (EDT) Received: (qmail 18666 invoked by uid 605); 25 Jul 2003 15:31:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18614 invoked from network); 25 Jul 2003 15:31:23 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 25 Jul 2003 15:31:23 -0000 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6PFVJ2h019919; Fri, 25 Jul 2003 08:31:23 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6PFVItK016844; Fri, 25 Jul 2003 11:31:18 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6PFVI8Q020299; Fri, 25 Jul 2003 11:31:18 -0400 (EDT) Message-Id: <200307251531.h6PFVI8Q020299@thunk.east.sun.com> From: Bill Sommerfeld To: "Brent McClure" cc: ietf-ssh@NetBSD.org Subject: Re: PublicKeyFile Format Security Considerations In-Reply-To: Your message of "Fri, 25 Jul 2003 09:13:24 MDT." <000b01c352bf$4b2fc980$4900a8c0@galb.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 25 Jul 2003 11:31:18 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Security Considerations > > There are no known security issues raised by this document. Sorry, this is a good way to get laughed at by the IESG these days. This is an out of band exchange format for public keys, so it's going to be shovelled around between systems. The big one which jumps out at me is: - by design, the file format does not provide meaningful integrity protection or authentication of the contents (i.e., this is not a certificate) so you have to be careful with how you move the file around and how you store it.. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 12:19:34 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10901 for ; Fri, 25 Jul 2003 12:19:33 -0400 (EDT) Received: (qmail 18119 invoked by uid 605); 25 Jul 2003 16:19:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18110 invoked from network); 25 Jul 2003 16:19:29 -0000 Received: from goldfinger.siliconcircus.com (HELO mail.siliconcircus.com) (62.141.33.103) by mail.netbsd.org with SMTP; 25 Jul 2003 16:19:29 -0000 Received: from siliconcircus.com (drno [127.0.0.1]) by mail.siliconcircus.com (Postfix) with ESMTP id 195A3567D for ; Fri, 25 Jul 2003 18:19:22 +0200 (CEST) Message-ID: <3F215892.2030305@siliconcircus.com> Date: Fri, 25 Jul 2003 18:19:30 +0200 From: Jon Bright User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5a) Gecko/20030708 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-ssh@NetBSD.org Subject: Updated Publickey draft Content-Type: multipart/mixed; boundary="------------080702000402020805070304" Sender: ietf-ssh-owner@NetBSD.org Precedence: list This is a multi-part message in MIME format. --------------080702000402020805070304 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Following changes: - "command" is now "command-override" and specifies a single compulsory command, run when "exec" or "shell" is received. - Bumped version to 2, added SSH_PUBLICKEY_VERSION_NOT_SUPPORTED in the place of REQUEST_NOT_SUPPORTED. Moved REQUEST_NOT_SUPPORTED to the end of the list, specified that a status packet SHOULD be sent when disconnecting for version reasons. The effect of this is (hopefully) that v1 implementations will see what they consider to be a REQUEST_NOT_SUPPORTED status in response to their first packet, followed by channel closed. v2 clients will see VERSION_NOT_SUPPORTED. Am interested to know whether this attempt at backward-compatibility is considered useful. - Added security considerations section, integrating Brent's suggested text and some of my own stuff. -- Jon Bright Lead Programmer, Silicon Circus Ltd. http://www.siliconcircus.com --------------080702000402020805070304 Content-Type: text/plain; name="draft-galb-secsh-publickey-subsystem.txt" Content-Disposition: inline; filename="draft-galb-secsh-publickey-subsystem.txt" Content-Transfer-Encoding: 7bit Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Expires: January 23, 2004 B. McClure VanDyke Software J. Bright Silicon Circus July 25, 2003 Secure Shell Public-Key Subsystem draft-galb-secsh-publickey-subsystem-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 23, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting a Galbraith, et al. Expires January 23, 2004 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Shell or a Command''. The subsystem name used with this protocol is "publickey@vandyke.com". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . 4 2.1 Opening the Public-Key Subsystem . . . . . . . . . . . . . . 4 2.2 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 The Status Response . . . . . . . . . . . . . . . . . . . . 5 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . 7 3.1 Version Packet . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Adding a public key . . . . . . . . . . . . . . . . . . . . 7 3.3 Removing a public key . . . . . . . . . . . . . . . . . . . 10 3.4 Listing public keys . . . . . . . . . . . . . . . . . . . . 10 3.5 Listing server capabilities . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 15 Galbraith, et al. Expires January 23, 2004 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem July 2003 1. Introduction SECSH is a protocol for secure remote login and other secure network services over an insecure network. SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. The Secure Shell Public-Key subsystem has been designed to run on top of the SECSH transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. This document should be read only after reading the SECSH architecture [1] and SECSH connection [4] documents. This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. Galbraith, et al. Expires January 23, 2004 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem July 2003 2. Public-Key Subsystem Overview The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey@vandyke.com". The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. The operations to add, remove and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. The format of public-key blobs are detailed in the SSH Transport Protocol document [2]. 2.1 Opening the Public-Key Subsystem The public-key subsystem is opened when the clients sends a SSH_MSG_CHANNEL_REQUEST over an existing session. The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session". To open the public-key subsystem, the client sends: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey@vandyke.com" Client implementations SHOULD reject this request; it is normally only sent by the client. If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user authenticated with a restricted public key that does not allow access to the publickey subsystem. It is RECOMMENDED that clients request and check the reply for this request. Galbraith, et al. Expires January 23, 2004 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem July 2003 2.2 Requests All public-key subsystem requests are sent in the following form: uint32 length string request-name ... request specific data follows The length field describes the length of the request-name field and the request-specific data, but not of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request. All requests described in Section 3 are a description of the 'request-name' and 'data' portion of the packet. 2.3 Responses All public-key subsystem responses are sent in the following form: uint32 length string response-name ... response specific data follows 2.3.1 The Status Response A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. string "status" uint32 status code string description [RFC-2279] string language tag [RFC-1766] A status message MUST be sent for any unrecognized packets and the request SHOULD NOT close the subsystem. 2.3.1.1 Status Codes The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 Galbraith, et al. Expires January 23, 2004 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem July 2003 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 Galbraith, et al. Expires January 23, 2004 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem July 2003 3. Public-Key Subsystem Operations The public-key subsystem currently defines four operations: add, remove, list, and command. 3.1 Version Packet Both sides MUST start by sending a version packet that indicates the version of the protocol they are using. string "version" uint32 protocol-version-number The version of the protocol described by this document is version 2. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. Both sides MUST wait to receive this version before continuing. 3.2 Adding a public key If the client wishes to add a public key, the client sends: string "add" string public-key algorithm name string public-key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED Galbraith, et al. Expires January 23, 2004 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add. For the purposes of a mandatory attribute, storage of the attribute is not sufficient, but requires that the server understand and implement the intent of the attribute. The following attributes are currently defined: "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [6]. The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be mandatory. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specifies the language for that attribute [5]. The client MAY specify more than comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment, together with that comment's lanuage attribute. This attribute SHOULD NOT be mandatory. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorisation checks the server may perform). This attribute SHOULD be mandatory. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be mandatory. If the value is empty, no subsystems may be started. Galbraith, et al. Expires January 23, 2004 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem July 2003 "x11" "x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "exec" "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorisation purposes, the authorisation attempt MUST be denied. The server SHOULD make a log entry regarding this. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except to those hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be mandatory. "reverse-forward" Galbraith, et al. Expires January 23, 2004 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem July 2003 "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, accept for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be mandatory. In addition to the attributes specified by the client, the server MAY provide a method for administrators to compulsorily enforce certain attributes. 3.3 Removing a public key If the client wishes to remove a public key, the client sends: string "remove" string public-key algorithm name string public-key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. 3.4 Listing public keys If the client wishes to list the known public keys, the client sends: string "list" The server will respond with zero or more of the following responses: string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times Following the last "publickey" response, a status packet MUST be sent. An implementation MAY choose not to support this request. 3.5 Listing server capabilities If the client wishes to know which key attributes the server supports, it sends: Galbraith, et al. Expires January 23, 2004 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem July 2003 string "listattributes" The server will respond with zero or more of the following responses: string "attribute" string attribute name boolean compulsory The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. Following the last "attribute" response, a status packet MUST be sent. An implementation MAY choose not to support this request. Galbraith, et al. Expires January 23, 2004 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem July 2003 4. Security Considerations This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorise keys for access they were not intended to have, or to apply fewer restrictions than were intended. Galbraith, et al. Expires January 23, 2004 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Normative References [1] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-13 (work in progress), January 2002. [2] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh-transport-15 (work in progress), March 2002. [3] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-16 (work in progress), February 2002. [4] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 (work in progress), January 2002. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb-list@vandyke.com Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: jpv@vandyke.com Galbraith, et al. Expires January 23, 2004 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: bdm@vandyke.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 EMail: jon@siliconcircus.com Galbraith, et al. Expires January 23, 2004 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem July 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Galbraith, et al. Expires January 23, 2004 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem July 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Galbraith, et al. Expires January 23, 2004 [Page 16] --------------080702000402020805070304-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 19:23:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01379 for ; Fri, 25 Jul 2003 19:23:55 -0400 (EDT) Received: (qmail 4338 invoked by uid 605); 25 Jul 2003 23:23:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4331 invoked from network); 25 Jul 2003 23:23:55 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 25 Jul 2003 23:23:55 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6PNNpQH055588; Fri, 25 Jul 2003 17:23:51 -0600 (MDT) Message-ID: <004901c35303$90f8fd30$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: Cc: References: <200307251531.h6PFVI8Q020299@thunk.east.sun.com> Subject: Re: PublicKeyFile Format Security Considerations Date: Fri, 25 Jul 2003 17:22:06 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-1.5 required=10.0 tests=ORIGINAL_MESSAGE,QUOTED_EMAIL_TEXT,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bill Sommerfeld" > The big one which jumps out at me is: > > - by design, the file format does not provide meaningful integrity > protection or authentication of the contents (i.e., this is not a > certificate) so you have to be careful with how you move the file > around and how you store it.. > > - Bill Bill, Thanks for the help. Here's another crack at it. --Brent ---- Security Considerations The file format described by this document provides no mechanism to verify the integrity or otherwise detect tampering of the data stored in such files. It is the responsibility of the parties that create or exchange files written in this format to ensure that appropriate access controls are applied to such files, and that the files, if transfered, are exchanged over a trusted channel. The data encoded using this file format is sensitive. Implementors are cautioned to verify the correctness of the encoding/decoding routines used to save and read files in this format. A malfunctioning decoder used to read a public-key file will most likely produce unsound data of unknown cryptographic properties that in the worst case could be vulnerable various forms of cryptographic attack. This file format allows for headers that contain data associated with a public key. This header data could contain an unlimited range of information. While in many environments the information conveyed by a "Subject:" header would be considered innocuous public information, the potential exposure of information through header data should be reviewed by sites that deploy this file format. ---- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 19:25:43 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01498 for ; Fri, 25 Jul 2003 19:25:43 -0400 (EDT) Received: (qmail 5966 invoked by uid 605); 25 Jul 2003 23:25:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5959 invoked from network); 25 Jul 2003 23:25:45 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 25 Jul 2003 23:25:45 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h6PNPj2h027332; Fri, 25 Jul 2003 16:25:45 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6PNPifM012013; Fri, 25 Jul 2003 19:25:44 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6PNPi8Q026321; Fri, 25 Jul 2003 19:25:44 -0400 (EDT) Message-Id: <200307252325.h6PNPi8Q026321@thunk.east.sun.com> From: Bill Sommerfeld To: "Brent McClure" cc: ietf-ssh@NetBSD.org Subject: Re: PublicKeyFile Format Security Considerations In-Reply-To: Your message of "Fri, 25 Jul 2003 17:22:06 MDT." <004901c35303$90f8fd30$4900a8c0@galb.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Fri, 25 Jul 2003 19:25:44 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > The file format described by this document provides no mechanism > to verify the integrity or otherwise detect tampering of the > data stored in such files. It is the responsibility of the parties > that create or exchange files written in this format to ensure that > appropriate access controls are applied to such files, and that > the files, if transfered, are exchanged over a trusted channel. > > The data encoded using this file format is sensitive. "sensitive" in what sense? > Implementors are cautioned to verify the correctness of the > encoding/decoding routines used to save and read files in this > format. A malfunctioning decoder used to read a public-key file > will most likely produce unsound data of unknown cryptographic > properties that in the worst case could be vulnerable various > forms of cryptographic attack. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Fri Jul 25 19:47:37 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02299 for ; Fri, 25 Jul 2003 19:47:36 -0400 (EDT) Received: (qmail 14887 invoked by uid 605); 25 Jul 2003 23:47:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14880 invoked from network); 25 Jul 2003 23:47:37 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 25 Jul 2003 23:47:37 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6PNlWQH068862; Fri, 25 Jul 2003 17:47:32 -0600 (MDT) Message-ID: <001601c35306$df9c2f90$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: Cc: References: <200307252325.h6PNPi8Q026321@thunk.east.sun.com> Subject: Re: PublicKeyFile Format Security Considerations Date: Fri, 25 Jul 2003 17:45:47 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-1.3 required=10.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Bill Sommerfeld" To: "Brent McClure" Cc: Sent: Friday, July 25, 2003 5:25 PM Subject: Re: PublicKeyFile Format Security Considerations > > The file format described by this document provides no mechanism > > to verify the integrity or otherwise detect tampering of the > > data stored in such files. It is the responsibility of the parties > > that create or exchange files written in this format to ensure that > > appropriate access controls are applied to such files, and that > > the files, if transfered, are exchanged over a trusted channel. > > > > The data encoded using this file format is sensitive. > > "sensitive" in what sense? In the sense that it's important for authentication. Ie, if the data causes the wrong thing to happen it could be bad thing. Saying "sensitive" seemed vague when I wrote it. How about: The data encoded using this file format is critical for authentication to work correctly. Or, I'm open to suggestions. --Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Sat Jul 26 10:45:04 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09678 for ; Sat, 26 Jul 2003 10:45:04 -0400 (EDT) Received: (qmail 12336 invoked by uid 605); 26 Jul 2003 14:45:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12328 invoked from network); 26 Jul 2003 14:45:01 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 26 Jul 2003 14:45:01 -0000 Received: from extremenetworks.com (unknown [10.0.8.115]) by gnat.inet.org (Postfix) with ESMTP id 7582167107; Sat, 26 Jul 2003 11:14:32 -0400 (EDT) Date: Sat, 26 Jul 2003 10:44:43 -0400 Subject: Re: PublicKeyFile Format Security Considerations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Brent McClure" , ietf-ssh@NetBSD.org To: sommerfeld@east.sun.com From: RJ Atkinson In-Reply-To: <200307252325.h6PNPi8Q026321@thunk.east.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 Friday, Jul 25, 2003, at 19:25 America/Montreal, Bill Sommerfeld wrote: >> The file format described by this document provides no mechanism >> to verify the integrity or otherwise detect tampering of the >> data stored in such files. It is the responsibility of the parties >> that create or exchange files written in this format to ensure that >> appropriate access controls are applied to such files, and that >> the files, if transfered, are exchanged over a trusted channel. >> >> The data encoded using this file format is sensitive. > > "sensitive" in what sense? > >> Implementors are cautioned to verify the correctness of the >> encoding/decoding routines used to save and read files in this >> format. A malfunctioning decoder used to read a public-key file >> will most likely produce unsound data of unknown cryptographic >> properties that in the worst case could be vulnerable various >> forms of cryptographic attack. Suggested text fragment: "Given the potential of an adversary tampering with data stored in such files on filesystems, system-specific measures (e.g. Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory Access Controls) SHOULD be used to protect these files." (edit to taste) Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 16:19:32 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07861 for ; Tue, 29 Jul 2003 16:19:29 -0400 (EDT) Received: (qmail 17164 invoked by uid 605); 29 Jul 2003 20:19:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17157 invoked from network); 29 Jul 2003 20:19:30 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 29 Jul 2003 20:19:30 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6TKJTpO015751 for ; Tue, 29 Jul 2003 14:19:29 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TKJTfM006979 for ; Tue, 29 Jul 2003 16:19:29 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6TKJS8Q026306 for ; Tue, 29 Jul 2003 16:19:29 -0400 (EDT) Message-Id: <200307292019.h6TKJS8Q026306@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Re: WG Last Call on draft-ietf-secsh-auth-kbdinteract-05.txt In-Reply-To: Your message of "Tue, 15 Jul 2003 17:35:53 EDT." Reply-to: sommerfeld@east.sun.com Date: Tue, 29 Jul 2003 16:19:28 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > So, I'd like to start a new WG Last Call on > > Generic Message Exchange Authentication For SSH > draft-ietf-secsh-auth-kbdinteract-05.txt > > .. for publication as a Proposed Standard RFC; the Last Call period > ends on 7/29/2003. The last call period has ended. I have seen no comments on this document during the last-call period. I will shortly be forwarding this document to our AD. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 16:25:14 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07958 for ; Tue, 29 Jul 2003 16:25:13 -0400 (EDT) Received: (qmail 21572 invoked by uid 605); 29 Jul 2003 20:25:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21564 invoked from network); 29 Jul 2003 20:25:13 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 29 Jul 2003 20:25:13 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6TKPCpO018912; Tue, 29 Jul 2003 14:25:12 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TKPCfM008253; Tue, 29 Jul 2003 16:25:12 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6TKPB8Q026343; Tue, 29 Jul 2003 16:25:12 -0400 (EDT) Message-Id: <200307292025.h6TKPB8Q026343@thunk.east.sun.com> From: Bill Sommerfeld To: Russ Housley cc: ietf-ssh@NetBSD.org Subject: Please advance draft-ietf-secsh-auth-kbdinteract-05.txt Reply-to: sommerfeld@east.sun.com Date: Tue, 29 Jul 2003 16:25:11 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Please start the ball rolling on: Generic Message Exchange Authentication For SSH .. for publication as a Proposed Standard. The document has gone through WG last call with no comments. I've reviewed it and it appears to be in conformance with the current ID-nits list. While not a requirement for Proposed Standards status, I believe there are multiple interoperable implementations deployed already. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 16:48:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08693 for ; Tue, 29 Jul 2003 16:48:38 -0400 (EDT) Received: (qmail 5829 invoked by uid 605); 29 Jul 2003 20:48:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5822 invoked from network); 29 Jul 2003 20:48:36 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 29 Jul 2003 20:48:36 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6TKmapO001677 for ; Tue, 29 Jul 2003 14:48:36 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TKmZfM013541 for ; Tue, 29 Jul 2003 16:48:35 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6TKmZ8Q026753 for ; Tue, 29 Jul 2003 16:48:35 -0400 (EDT) Message-Id: <200307292048.h6TKmZ8Q026753@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Re: WG Last Call on draft-ietf-secsh-gsskeyex-06.txt In-Reply-To: Your message of "Tue, 15 Jul 2003 17:46:58 EDT." <200307152146.h6FLkw8Q003017@thunk.east.sun.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 29 Jul 2003 16:48:35 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list This WG Last Call has timed out; however the extensive discussion regarding key exchange negotiation makes it clear that the document needs a respin to address these issues. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 17:17:58 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09926 for ; Tue, 29 Jul 2003 17:17:57 -0400 (EDT) Received: (qmail 23971 invoked by uid 605); 29 Jul 2003 21:17:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23964 invoked from network); 29 Jul 2003 21:17:59 -0000 Received: from psg.com (147.28.0.62) by mail.netbsd.org with SMTP; 29 Jul 2003 21:17:59 -0000 Received: from www by psg.com with local (Exim 4.20) id 19hbr5-000339-1b for ietf-ssh@netbsd.org; Tue, 29 Jul 2003 21:17:59 +0000 Subject: [psg.com #151] transport: kexinit MBZ field underspecified In-Reply-To: RT-Originator: sommerfeld@sun.com From: " via RT" Managed-BY: RT 2.0.15 (http://bestpractical.com/rt/) CC: ietf-ssh@NetBSD.org RT-Ticket: psg.com #151 X-RT-Loop-Prevention: psg.com Reply-To: rt+secsh@rt.psg.com Message-Id: X-Mailer: Perl5 Mail::Internet v1.58 Date: Tue, 29 Jul 2003 21:17:59 +0000 Sender: ietf-ssh-owner@NetBSD.org Precedence: list Survey of existing implementations conducted on the WG list suggests that all seem to support receiving a non-zero value, but not all support additional data after this field, which suggests that there may be some fairly tightly constrained ways to use it for extensions. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 17:34:22 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10598 for ; Tue, 29 Jul 2003 17:34:21 -0400 (EDT) Received: (qmail 4792 invoked by uid 605); 29 Jul 2003 21:32:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4785 invoked from network); 29 Jul 2003 21:32:55 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 29 Jul 2003 21:32:55 -0000 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h6TLWtTU025939 for ; Tue, 29 Jul 2003 14:32:55 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h6TLWsfM024935 for ; Tue, 29 Jul 2003 17:32:54 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h6TLWs8Q027081 for ; Tue, 29 Jul 2003 17:32:54 -0400 (EDT) Message-Id: <200307292132.h6TLWs8Q027081@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@NetBSD.org Subject: Resolving the newmodes algorithm list. Reply-to: sommerfeld@east.sun.com Date: Tue, 29 Jul 2003 17:32:54 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list The current list in http://www.ietf.org/internet-drafts/draft-ietf-secsh-newmodes-00.txt is: aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, with 128-bit key aes192-ctr RECOMMENDED AES with 192-bit key aes256-ctr RECOMMENDED AES with 256-bit key 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode blowfish-ctr RECOMMENDED Blowfish in SDCTR mode twofish128-ctr RECOMMENDED Twofish in SDCTR mode, with 128-bit key twofish192-ctr OPTIONAL Twofish with 192-bit key twofish256-ctr OPTIONAL Twofish with 256-bit key serpent128-ctr RECOMMENDED Serpent in SDCTR mode, with with 128-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key idea-ctr OPTIONAL IDEA in SDCTR mode cast128-ctr OPTIONAL CAST-128 in SDCTR mode There seems to be no objection to the concept of downgrading all the AES runner-ups to OPTIONAL, leaving only the three aes sizes and 3des as RECOMMENDED. Namely: aes128-ctr RECOMMENDED AES (Rijndael) in SDCTR mode, with 128-bit key aes192-ctr RECOMMENDED AES with 192-bit key aes256-ctr RECOMMENDED AES with 256-bit key 3des-ctr RECOMMENDED Three-key 3DES in SDCTR mode blowfish-ctr OPTIONAL Blowfish in SDCTR mode twofish128-ctr OPTIONAL Twofish in SDCTR mode, with 128-bit key twofish192-ctr OPTIONAL Twofish with 192-bit key twofish256-ctr OPTIONAL Twofish with 256-bit key serpent128-ctr OPTIONAL Serpent in SDCTR mode, with with 128-bit key serpent192-ctr OPTIONAL Serpent with 192-bit key serpent256-ctr OPTIONAL Serpent with 256-bit key idea-ctr OPTIONAL IDEA in SDCTR mode cast128-ctr OPTIONAL CAST-128 in SDCTR mode Also, what do people think of boosting aes128-ctr to MANDATORY ? (note: this is a separate document. as a practical matter, implementations would not be "forced" to implement aes128-ctr until they chose to claim they implemented newmodes). - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 17:35:27 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10667 for ; Tue, 29 Jul 2003 17:35:26 -0400 (EDT) Received: (qmail 5893 invoked by uid 605); 29 Jul 2003 21:35:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5886 invoked from network); 29 Jul 2003 21:35:25 -0000 Received: from abraham.cs.berkeley.edu (128.32.37.170) by mail.netbsd.org with SMTP; 29 Jul 2003 21:35:25 -0000 Received: from news by abraham.cs.berkeley.edu with local (Exim 4.20) id 19hc7b-0004Gt-BJ for ietf-ssh@netbsd.org; Tue, 29 Jul 2003 14:35:03 -0700 To: ietf-ssh@NetBSD.org Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ietf-ssh Subject: Re: Resolving the newmodes algorithm list. Date: Tue, 29 Jul 2003 21:35:03 +0000 (UTC) Organization: University of California, Berkeley Lines: 7 Distribution: isaac Message-ID: References: <200307292132.h6TLWs8Q027081@thunk.east.sun.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1059514503 16407 128.32.153.211 (29 Jul 2003 21:35:03 GMT) X-Complaints-To: usenet@abraham.cs.berkeley.edu NNTP-Posting-Date: Tue, 29 Jul 2003 21:35:03 +0000 (UTC) X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld wrote: >There seems to be no objection to the concept of downgrading all the >AES runner-ups to OPTIONAL, leaving only the three aes sizes and 3des >as RECOMMENDED. As one of the co-designers of one of the algorithms that was downgraded, I warmly support your proposed downgrading. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 18:36:30 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13656 for ; Tue, 29 Jul 2003 18:36:30 -0400 (EDT) Received: (qmail 5693 invoked by uid 605); 29 Jul 2003 22:36:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5686 invoked from network); 29 Jul 2003 22:36:24 -0000 Received: from hermes.cs.auckland.ac.nz (130.216.35.151) by mail.netbsd.org with SMTP; 29 Jul 2003 22:36:24 -0000 Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h6TMaKak032241; Wed, 30 Jul 2003 10:36:20 +1200 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h6TMaKl13699; Wed, 30 Jul 2003 10:36:20 +1200 Date: Wed, 30 Jul 2003 10:36:20 +1200 Message-Id: <200307292236.h6TMaKl13699@medusa01.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: sommerfeld@east.sun.com Subject: Re: Resolving the newmodes algorithm list. Cc: ietf-ssh@NetBSD.org Sender: ietf-ssh-owner@NetBSD.org Precedence: list Bill Sommerfeld writes: >Also, what do people think of boosting aes128-ctr to MANDATORY ? Given that AES-CTR's main feature is that it's building block for a variety of confidentiality+integrity modes (rather than a mode in and of itself) and that it's parallelisable (if you happen to be doing, say, Gbps link encryption in hardware), what would be the benefit of this? Peter. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 18:39:00 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13799 for ; Tue, 29 Jul 2003 18:39:00 -0400 (EDT) Received: (qmail 7079 invoked by uid 605); 29 Jul 2003 22:39:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7071 invoked from network); 29 Jul 2003 22:39:02 -0000 Received: from brmea-mail-3.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 29 Jul 2003 22:39:02 -0000 Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6TMd2pO000497 for ; Tue, 29 Jul 2003 16:39:02 -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 h6TMd2cm005299; Tue, 29 Jul 2003 16:39:02 -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 h6TMZjQx015735; Tue, 29 Jul 2003 15:35:45 -0700 (PDT) Received: (from nw141292@localhost) by binky.central.sun.com (8.12.5+Sun/8.12.3/Submit) id h6TMZj5p015734; Tue, 29 Jul 2003 15:35:45 -0700 (PDT) Date: Tue, 29 Jul 2003 15:35:45 -0700 From: Nicolas Williams To: Bill Sommerfeld Cc: ietf-ssh@NetBSD.org Subject: Re: Resolving the newmodes algorithm list. Message-ID: <20030729223541.GA15730@binky.central.sun.com> References: <200307292132.h6TLWs8Q027081@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200307292132.h6TLWs8Q027081@thunk.east.sun.com> User-Agent: Mutt/1.4i Sender: ietf-ssh-owner@NetBSD.org Precedence: list On Tue, Jul 29, 2003 at 05:32:54PM -0400, Bill Sommerfeld wrote: > Also, what do people think of boosting aes128-ctr to MANDATORY ? > (note: this is a separate document. as a practical matter, > implementations would not be "forced" to implement aes128-ctr until > they chose to claim they implemented newmodes). I agree. If two implementations support newmodes they should be able to interop, and that means having at least one mode be required to implement. Nico -- From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Tue Jul 29 23:06:38 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA20718 for ; Tue, 29 Jul 2003 23:06:37 -0400 (EDT) Received: (qmail 16235 invoked by uid 605); 30 Jul 2003 03:06:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16214 invoked from network); 30 Jul 2003 03:06:34 -0000 Received: from unknown (HELO mail.mel.netstarnetworks.com) (61.95.66.138) by mail.netbsd.org with SMTP; 30 Jul 2003 03:06:34 -0000 Received: from mindrot.org (116.195.20.10.dhcp.netstarnetworks.com [10.20.195.116] (may be forged)) by mail.mel.netstarnetworks.com (8.11.6/8.11.6) with ESMTP id h6U39OQ14974; Wed, 30 Jul 2003 13:09:34 +1000 Message-ID: <3F2735ED.7070008@mindrot.org> Date: Wed, 30 Jul 2003 13:05:17 +1000 From: Damien Miller User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en, ja MIME-Version: 1.0 To: Peter Gutmann CC: sommerfeld@east.sun.com, ietf-ssh@NetBSD.org Subject: Re: Resolving the newmodes algorithm list. References: <200307292236.h6TMaKl13699@medusa01.cs.auckland.ac.nz> In-Reply-To: <200307292236.h6TMaKl13699@medusa01.cs.auckland.ac.nz> X-Enigmail-Version: 0.74.3.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Peter Gutmann wrote: > Bill Sommerfeld writes: > > >>Also, what do people think of boosting aes128-ctr to MANDATORY ? > > Given that AES-CTR's main feature is that it's building block for a variety of > confidentiality+integrity modes (rather than a mode in and of itself) and that > it's parallelisable (if you happen to be doing, say, Gbps link encryption in > hardware), what would be the benefit of this? There was a long discussions on problems with CBC modes on this list a while back. CTR mode was offered as not vulnerable to the same problems. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 30 10:19:32 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02900 for ; Wed, 30 Jul 2003 10:19:30 -0400 (EDT) Received: (qmail 5839 invoked by uid 605); 30 Jul 2003 14:18:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5832 invoked from network); 30 Jul 2003 14:18:05 -0000 Received: from minbar.fac.cs.cmu.edu (128.2.185.161) by mail.netbsd.org with SMTP; 30 Jul 2003 14:18:05 -0000 Received: from minbar.fac.cs.cmu.edu ([128.2.185.161]) by minbar.fac.cs.cmu.edu id aa11252; 30 Jul 2003 10:17 EDT Date: Wed, 30 Jul 2003 10:17:17 -0400 From: Jeffrey Hutzelman To: ietf-ssh@NetBSD.org Subject: Re: WG Last Call on draft-ietf-secsh-gsskeyex-06.txt Message-ID: <71710000.1059574637@minbar.fac.cs.cmu.edu> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; FORMAT=flowed Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, July 29, 2003 16:48:35 -0400 Bill Sommerfeld wrote: > This WG Last Call has timed out; however the extensive discussion > regarding key exchange negotiation makes it clear that the document > needs a respin to address these issues. Yes, I think that's clear. I have a list of outstanding issues, and will be creating entries for them in the issue-tracking system in the next couple of days. I'll try to submit a new version of the document within a couple of weeks. -- Jeff From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 30 12:35:12 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07455 for ; Wed, 30 Jul 2003 12:35:12 -0400 (EDT) Received: (qmail 27299 invoked by uid 605); 30 Jul 2003 16:35:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27292 invoked from network); 30 Jul 2003 16:35:14 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 30 Jul 2003 16:35:14 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6UGZAD4087522; Wed, 30 Jul 2003 10:35:10 -0600 (MDT) Message-ID: <001501c356b8$49df2d80$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: "RJ Atkinson" Cc: References: Subject: Re: PublicKeyFile Format Security Considerations Date: Wed, 30 Jul 2003 10:33:20 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-1.3 required=10.0 tests=QUOTED_EMAIL_TEXT,QUOTE_TWICE_1,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit Revised the Public-key file format Security Considerations based on comments: - Removed use of vague term "sensitive". - Added in text suggestion from Ran. Is the blurb about information disclosure by "Comment" headers too strong, unnecessary or OK? thanks, Brent ---- Security Considerations The file format described by this document provides no mechanism to verify the integrity or otherwise detect tampering with the data stored in such files. Given the potential of an adversarial tampering with this data, system-specific measures (e.g. Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory Access Controls) SHOULD be used to protect these files. Also, if the contents of these files are transferred it SHOULD be done over a trusted channel. Implementors are cautioned to verify the correctness of the encoding/decoding routines used to save and read files in this format. A malfunctioning decoder used to read public-key data will most likely produce invalid data with unknown cryptographic properties. In the worst case this cata could be vulnerable various forms of cryptographic attack. The header data allowed by this file format could contain an unlimited range of information. While in many environments the information conveyed by this header data may be considered innocuous public information, it may constitute a channel through which information about a user, a key or its use may be disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, Home Phone:..."). The presence and use of this header data SHOULD be reviewed by sites that deploy this file format. --Brent ----- Original Message ----- From: "RJ Atkinson" To: Cc: "Brent McClure" ; Sent: Saturday, July 26, 2003 8:44 AM Subject: Re: PublicKeyFile Format Security Considerations > > On Friday, Jul 25, 2003, at 19:25 America/Montreal, Bill Sommerfeld > wrote: > >> The file format described by this document provides no mechanism > >> to verify the integrity or otherwise detect tampering of the > >> data stored in such files. It is the responsibility of the parties > >> that create or exchange files written in this format to ensure that > >> appropriate access controls are applied to such files, and that > >> the files, if transfered, are exchanged over a trusted channel. > >> > >> The data encoded using this file format is sensitive. > > > > "sensitive" in what sense? > > > >> Implementors are cautioned to verify the correctness of the > >> encoding/decoding routines used to save and read files in this > >> format. A malfunctioning decoder used to read a public-key file > >> will most likely produce unsound data of unknown cryptographic > >> properties that in the worst case could be vulnerable various > >> forms of cryptographic attack. > > Suggested text fragment: > > "Given the potential of an adversary tampering with data stored > in such files on filesystems, system-specific measures (e.g. > Access Control Lists, UNIX permissions, other Discretionary > and/or Mandatory Access Controls) SHOULD be used to protect > these files." > > (edit to taste) > > Ran > From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 30 12:56:29 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08019 for ; Wed, 30 Jul 2003 12:56:28 -0400 (EDT) Received: (qmail 12714 invoked by uid 605); 30 Jul 2003 16:56:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12698 invoked from network); 30 Jul 2003 16:56:31 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 30 Jul 2003 16:56:31 -0000 Received: by xanthine.gratuitous.org with local; Wed, 30 Jul 2003 12:56:20 -0400 From: "Joel N. Weber II" To: "Brent McClure" CC: "RJ Atkinson" , In-reply-to: <001501c356b8$49df2d80$4900a8c0@galb.vandyke.com> (mcclure@swcp.com) Subject: Re: PublicKeyFile Format Security Considerations References: <001501c356b8$49df2d80$4900a8c0@galb.vandyke.com> Message-Id: Date: Wed, 30 Jul 2003 12:56:20 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > Implementors are cautioned to verify the correctness of the encoding/decoding > routines used to save and read files in this format. A malfunctioning > decoder used to read public-key data will most likely produce > invalid data with unknown cryptographic properties. In the worst > case this cata could be vulnerable various forms of cryptographic attack. I'm not sure that a cryptographic attack is the worst case. Are we sure that a malfunctioning decoder can't possibly be vulnerable to a buffer overflow? From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 30 17:15:56 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18159 for ; Wed, 30 Jul 2003 17:15:55 -0400 (EDT) Received: (qmail 14280 invoked by uid 605); 30 Jul 2003 21:15:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14273 invoked from network); 30 Jul 2003 21:15:53 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 30 Jul 2003 21:15:52 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6ULFmD4064713; Wed, 30 Jul 2003 15:15:48 -0600 (MDT) Message-ID: <005c01c356df$7de48590$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: "Joel N. Weber II" Cc: References: <001501c356b8$49df2d80$4900a8c0@galb.vandyke.com> Subject: Re: PublicKeyFile Format Security Considerations Date: Wed, 30 Jul 2003 15:13:57 -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 5.50.4807.1700 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-1.0 required=10.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit From: "Joel N. Weber II" > I'm not sure that a cryptographic attack is the worst case. Are we > sure that a malfunctioning decoder can't possibly be vulnerable to a > buffer overflow? That's true. So, should I just change the use of the wording "worst case" to something like this?: "... A malfunctioning decoder used to read public-key data will most likely produce invalid data with unknown cryptographic properties which may leave this data vulnerable various forms of cryptographic attack." On the other hand, your suggestion of a buffer overflow makes me wonder if this caution about properly implementing the parsing/decoding of public-key data is too much a statement of the obvious. Ie. if there isn't a specific concern about the decoding of public keys here that warrants mentioning, then maybe I should just strike it. After all if what I wrote above is just another way of saying "Implementors should avoid bugs, and especially buffer overruns in their code" then maybe it doesn't add anything of value. --Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 30 17:37:40 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19152 for ; Wed, 30 Jul 2003 17:37:38 -0400 (EDT) Received: (qmail 26046 invoked by uid 605); 30 Jul 2003 21:37:41 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26039 invoked from network); 30 Jul 2003 21:37:40 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 30 Jul 2003 21:37:40 -0000 Received: by xanthine.gratuitous.org with local; Wed, 30 Jul 2003 17:37:39 -0400 From: "Joel N. Weber II" To: "Brent McClure" CC: In-reply-to: <005c01c356df$7de48590$4900a8c0@galb.vandyke.com> (mcclure@swcp.com) Subject: Re: PublicKeyFile Format Security Considerations References: <001501c356b8$49df2d80$4900a8c0@galb.vandyke.com> <005c01c356df$7de48590$4900a8c0@galb.vandyke.com> Message-Id: Date: Wed, 30 Jul 2003 17:37:39 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > After all > if what I wrote above is just another way of saying "Implementors should > avoid bugs, and especially buffer overruns in their code" then maybe > it doesn't add anything of value. It does seem to be the case that the text we're discussing covers a subject that is assumed to be obvious in just about every other IETF document. If we want to say ``don't write buffer overflows, and verify your data, and stuff'' in a very general way, it might be appropriate to write up a protocol-independent RFC saying those things, and have the security considerations section of every RFC refer to that generic, protocol-independent writeup. This discussion makes me wonder if it is a bug that there is no RFC talking about buffer overflows, as far as I know. There *is* an RFC about random numbers, for example. But I'm sure an RFC about buffer overflows is beyond the scope of this working group. If there is a specific reason why being careful about parsing the data is more important, or more difficult, or more subtle with an ssh public key file than in a generic case of parsing data, then explaining that would be useful. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Wed Jul 30 20:36:05 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25119 for ; Wed, 30 Jul 2003 20:36:05 -0400 (EDT) Received: (qmail 19987 invoked by uid 605); 31 Jul 2003 00:36:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19976 invoked from network); 31 Jul 2003 00:36:02 -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; 31 Jul 2003 00:36:02 -0000 Received: from latte.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 h6V0ZmgW026221 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 31 Jul 2003 02:35:48 +0200 From: Simon Josefsson To: Jeffrey Hutzelman Cc: ietf-ssh@NetBSD.org Subject: Re: Comment on draft-ietf-secsh-gsskeyex-06 References: From: Simon Josefsson X-Payment: hashcash 1.2 0:030731:jhutz@cmu.edu:fadeccb7252cfa41 X-Hashcash: 0:030731:jhutz@cmu.edu:fadeccb7252cfa41 X-Payment: hashcash 1.2 0:030731:ietf-ssh@netbsd.org:59706a73bceada2b X-Hashcash: 0:030731:ietf-ssh@netbsd.org:59706a73bceada2b Date: Thu, 31 Jul 2003 02:25:47 +0200 In-Reply-To: (Jeffrey Hutzelman's message of "Thu, 17 Jul 2003 16:30:35 +0200 (CEST)") Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: ietf-ssh-owner@NetBSD.org Precedence: list (Sorry for the delay, vacation time.) Jeffrey Hutzelman writes: > On Sun, 6 Jul 2003, Simon Josefsson wrote: > >> The document says: >> >> The client SHOULD NOT send more then one gssapi mechanism OID unless >> there are no non-GSSAPI authentication methods between the GSSAPI >> mechanisms in the order of preference, otherwise, authentication >> methods may be executed out of order. >> >> Besides having four (!) negations, I think some hints on how different >> GSSAPI mechanisms should be handled instead would be useful. E.g.: >> >> The client SHOULD send more than one mechanism OIDs only when all >> of the mechanisms are of the same priority, compared to non-GSSAPI >> authentication methods. Otherwise, authentication methods may be >> executed out of order. Thus, the client could first send a >> SSH_MSG_USERAUTH_REQUEST for one GSSAPI mechanism, then try public >> key authentication, and then try another GSSAPI mechanism. > > I think we can do something along these lines, but not specifically the > text you propose. The problem is that SHOULD and SHOULD NOT are not > exactly inverses. > > We say "you SHOULD NOT do X unless Y". This makes a recommendation if Y > is false, but none if Y is true. > > You say "you SHOULD do X if Y". This makes a recommendation if Y is true, > but none if Y is false. You are right, my text isn't good. Still, some improvement on that paragraph probably wouldn't hurt. The rather obvious intended behaviour is currently easily lost in the complicated language. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 31 12:57:28 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04214 for ; Thu, 31 Jul 2003 12:57:28 -0400 (EDT) Received: (qmail 14168 invoked by uid 605); 31 Jul 2003 16:57:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13824 invoked from network); 31 Jul 2003 16:57:18 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 31 Jul 2003 16:57:18 -0000 Received: from BLUETAIL (shimi.swcp.com [198.59.115.14]) by taka.swcp.com (8.12.9/8.12.9) with SMTP id h6VGvDx7055948; Thu, 31 Jul 2003 10:57:14 -0600 (MDT) Message-ID: <000701c35784$88541fe0$4900a8c0@galb.vandyke.com> From: "Brent McClure" To: "Joel N. Weber II" Cc: References: <001501c356b8$49df2d80$4900a8c0@galb.vandyke.com> <005c01c356df$7de48590$4900a8c0@galb.vandyke.com> Subject: Re: PublicKeyFile Format Security Considerations Date: Thu, 31 Jul 2003 10:55:22 -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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=-1.0 required=10.0 tests=QUOTED_EMAIL_TEXT,REFERENCES version=2.54 X-Spam-Checker-Version: SpamAssassin 2.54 (1.174.2.17-2003-05-11-exp) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Joel N. Weber II" .... > It does seem to be the case that the text we're discussing covers a > subject that is assumed to be obvious in just about every other IETF > document. If we want to say ``don't write buffer overflows, and > verify your data, and stuff'' in a very general way, it might be > appropriate to write up a protocol-independent RFC saying those > things, and have the security considerations section of every RFC > refer to that generic, protocol-independent writeup. This discussion > makes me wonder if it is a bug that there is no RFC talking about > buffer overflows, as far as I know. There *is* an RFC about random > numbers, for example. But I'm sure an RFC about buffer overflows is > beyond the scope of this working group. > > If there is a specific reason why being careful about parsing the data > is more important, or more difficult, or more subtle with an ssh > public key file than in a generic case of parsing data, then > explaining that would be useful. I can't make a case that this parsing of the encoded key data presents a specific condition that warrants it being mentioned. So, unless someone else can then I'll drop it from the security considerations. So, here's the text as I currently have it, does this work? ---- Security Considerations The file format described by this document provides no mechanism to verify the integrity or otherwise detect tampering with the data stored in such files. Given the potential of an adversarial tampering with this data, system-specific measures (e.g. Access Control Lists, UNIX permissions, other Discretionary and/or Mandatory Access Controls) SHOULD be used to protect these files. Also, if the contents of these files are transferred it SHOULD be done over a trusted channel. The header data allowed by this file format could contain an unlimited range of information. While in many environments the information conveyed by this header data may be considered innocuous public information, it may constitute a channel through which information about a user, a key or its use may be disclosed intentionally or otherwise (e.g "Comment: Mary E. Jones, 123 Main St, Home Phone:..."). The presence and use of this header data SHOULD be reviewed by sites that deploy this file format. thanks, Brent From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 31 13:27:01 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05011 for ; Thu, 31 Jul 2003 13:27:00 -0400 (EDT) Received: (qmail 29767 invoked by uid 605); 31 Jul 2003 17:26:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29760 invoked from network); 31 Jul 2003 17:26:57 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 31 Jul 2003 17:26:57 -0000 Received: by xanthine.gratuitous.org with local; Thu, 31 Jul 2003 13:26:56 -0400 From: "Joel N. Weber II" To: "Brent McClure" CC: In-reply-to: <000701c35784$88541fe0$4900a8c0@galb.vandyke.com> (mcclure@swcp.com) Subject: Re: PublicKeyFile Format Security Considerations References: <001501c356b8$49df2d80$4900a8c0@galb.vandyke.com> <005c01c356df$7de48590$4900a8c0@galb.vandyke.com> <000701c35784$88541fe0$4900a8c0@galb.vandyke.com> Message-Id: Date: Thu, 31 Jul 2003 13:26:56 -0400 Sender: ietf-ssh-owner@NetBSD.org Precedence: list > So, here's the text as I currently have it, does this work? It mostly looks fine to me. > data stored in such files. Given the potential of an adversarial I believe that should be ``adversary''. > tampering with this data, system-specific measures (e.g. Access Control Lists, [...] > Home Phone:..."). The presence and use of this header data SHOULD be > reviewed by sites that deploy this file format. RFC 2119 says: | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there | may exist valid reasons in particular circumstances to ignore a | particular item, but the full implications must be understood and | carefully weighed before choosing a different course. So to take this excessively literally, it sounds like sites that aren't going to review the presence and use of this header data must understand and carefully weigh the full implications of skipping this review before choosing to not do this review. It may be that you should just write the word ``should'' without the capital letters. From ietf-ssh-owner-secsh-archive=odin.ietf.org@NetBSD.org Thu Jul 31 13:39:17 2003 Received: from mail.netbsd.org (mail.isc.netbsd.org [204.152.185.212]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05494 for ; Thu, 31 Jul 2003 13:39:16 -0400 (EDT) Received: (qmail 7076 invoked by uid 605); 31 Jul 2003 17:39:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7069 invoked from network); 31 Jul 2003 17:39:16 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 31 Jul 2003 17:39:16 -0000 Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 2FAF567106 for ; Thu, 31 Jul 2003 14:09:45 -0400 (EDT) Date: Thu, 31 Jul 2003 13:39:08 -0400 Subject: Re: PublicKeyFile Format Security Considerations Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: RJ Atkinson To: ietf-ssh@NetBSD.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) Sender: ietf-ssh-owner@NetBSD.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, Jul 31, 2003, at 13:26 America/Montreal, Joel N. Weber II wrote: > So to take this excessively literally, ... Lets not be silly, please. :-) > It may be that you should just write the word ``should'' without the > capital letters. SHOULD with capitals is helpful in this case, IMHO, because it adds emphasis. Ran