From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 2 08:19:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03422 for ; Wed, 2 Jan 2002 08:19:49 -0500 (EST) Received: (qmail 9711 invoked by uid 605); 2 Jan 2002 13:19:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9704 invoked from network); 2 Jan 2002 13:19:41 -0000 Received: from f160.law14.hotmail.com (HELO hotmail.com) (64.4.21.160) by mail.netbsd.org with SMTP; 2 Jan 2002 13:19:41 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 2 Jan 2002 05:19:40 -0800 Received: from 157.228.22.42 by lw14fd.law14.hotmail.msn.com with HTTP; Wed, 02 Jan 2002 13:19:22 GMT X-Originating-IP: [157.228.22.42] From: "muhammad quddoos" To: kamyab73@hotmail.com Subject: Fwd: enjoy Date: Wed, 02 Jan 2002 13:19:22 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_42c7_7d4c_38e0" Message-ID: X-OriginalArrivalTime: 02 Jan 2002 13:19:40.0987 (UTC) FILETIME=[22B3D8B0:01C19390] Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_42c7_7d4c_38e0 Content-Type: text/html

MSN Photos is the easiest way to share and print your photos: Click Here
------=_NextPart_000_42c7_7d4c_38e0 Content-Type: text/html X-Stn-Info:

------=_NextPart_000_42c7_7d4c_38e0 Content-Type: image/gif; name="English.gif" Content-Disposition: attachment; filename="English.gif" Content-Transfer-Encoding: base64 R0lGODlhAgISBPcAAAAAAAA5e1paWnNzc3t7e3ucvZycnJy1zr29vb3O3v///wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAAAgISBAAI/wAVCBxI sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN mzhz6tzJs6fPn0CDCh2a8kABokiTKl3KtGnDAwEKJDjqtKrVq1izFo2aAOoBrWDDih1LlmACrlAD JCjLtq3btz0PdA0Q4Cvcu3jz6i2Z1u7ev4ADC2bodbDhw4j1dk3MuLFjnFP9UqR6du3jy5gzizyr 9uJRzp01ix5NOmIBuhgDCDxNVeHZ1oRLy54Nt3DqgZIlEzxtmWEB3bSDC78a+rbBxQYPAFdYfLjz 50mRG5Qasa5Av3ILToXdsDn07+Bt9v9ePX7gae8L6Rr1S50g6urh48uXqft3eQXnx0s/SJdu7/YC ddXbcvzNZ+CBRRV0HnAAKjDVfQGeZ515EF5XoUGqIajhhh4lUF5a3E33nohq7adAhgdN9RCKHLbo 4kTZaWeUa/6lSFeIArE40FToJaTji0AGiRCOqyn0W0IFEJljclxBhOKFQka5IZEqImQiQTMaWZBR UCLU2VlShglkj0famFBlC8GGpkT+JSnmmxxGJaKVEx4n50KSLeihk/0RCOef0Km31lx3mnVeivlV 19+ijDZK1XlKAiqpcBIyWl6S9k2XZIwRGdUoo5jW1+CkpA6XFqN+3tRlqayKVmmdiHb/FelJnLZq 62yQQglaf6uONOutwDp3mqe/jnRlsMhCN2ixI3ma7LPQPjVitNRW6yCs1mar7bbcdustRcd+K66U bo5rbphnfRXuuewyViZFdiW5FlS9tmsvVuU6lFa9ya115L73BsxWXw8lmlyqJwbII7MCNxxUdspR 2CmEnKWaIcAOZ9xUX+p5RLCP+GGr8chELdixR/l6mSXJLCeV3WLr8XsjwsxFFXHLOLus3MzXJaSc hDiue+KiDOds9EwDymkibwpgV+huqbKW1tFUC5VlgyBuSeSoW9oFZtVgr5TyQlXi9yF3ZU+na2dj h+22rwwDWOyoyP26KM1v513SwpL9/4hbnyJ+RZWfi/Kr9+Ednaqj3yHfaGdU1K27IOKUo/SavAX5 /RqXTJ5cq1mGVy76RSKbx5+urJmOEN6jt+4bkTcPefBTvTHetOu4V9R2kQrplvaZLJIZeu7EIxk6 dW6ayGPfDBZd/PPTsW6e4DeejN+mmU9I6PDQQ7+7kZTZbD2Sn0rfffeRQZT+cXjvOv758K9uftNc S8Rjk/Hnr//+/Pfv//8ADKAAB9g/A4yGAAYsHgKFhAACIOAiBjDgAgcSwcQYAAAAeCBPEjipC2Yw SBgkAEI4uBAEelCDESShYSaokwYiwAAalBQLwwNDhTQwIQBwCAAkmMAXCkSFhkFADP8b4kOTGECE FeRIEZ8jRIgssSNPbMoFLQJEhMxQAQBAYhU9EsWfIOCDRCSACCHokAWKUYkEAKNzvjhEG6axjRo5 IlYw2JAaGuSFOSxhA7OoAA/ukCR7hONN2vjFLRZkj4ZkSBOTuBAYNjCREdnjGA/CSEZq5YtjxKRD CPnHOmZRkBcpZEzUqBE6MoSPd7zhQrJ4xDymEZIYkaRPkojJKx4EkVTEICoVyUYFgNKJaXRgQoQp EGKG5Yt5RGYde5hFW94Sg7+0iBijSRBjeiSNedyIKUuYzYE00JrPfGASLcnFYFKTJmfsIxZhecRz LgSZu1QkMSdJEUxS85MCwadYltj/xYOk04CdbGRAKyJIOzYEmyG5ICwf4sBt2rCbAnGnAhbYzmmK xJ4Z4eBCpdnMYh5UoCFMiAGb+BASQlQi4LQiGN9IEF261KFDqeRGgznGSRrShRmhJwUhotCdOuSC 4jQiQMGYyJN6MyGSZKVBf1hGiaa0IpM06kbgmUB2RtOOT63IUo0KyqX28yJSLQtVmdrHX2ZVIif9 KlIpCMdpprOPCRyAREOpwZfqtCB3jWhe+6jUrrrTg0TcqA4jGlaLfHOH5GykO98q0rkK84xGpecD WUqQxGKksGA5bAoNclZSWiStguVsGz2IzQfi1AACiOZeIzJBeEITqVu0bC/1SMSB/4o0tKck7Ecw ScKNwlChFi2IHBlyVs7ydYdp7eQF92pZsB5ElwXJIXSxCFPqQlS6psRuN6ebz5Z6VyK8rWw1FYJZ iIDWiZ3MawWTiM2OkncjCPwjZY86kNVaVpfUXK066cuQ5jKUg8ks737NK9yS4vGEh8zkQyFSU4D2 UIIu1e9SS2mQbG7Xwhb+LhZbet2TZri7A9kuRSCqwsJi1py5PWRoAbvhg4YUswKu4zlJeEWKjtal 90TIN4fp2R/O1Z/bDPA7GVvg5+LVt0OEIwfne8gYe7SaiMVmBPGL1B5fNrpYBrGWW8xlLXu4wllu sXS3PEKEQHSGJkaqA9PYkPMyNP+7JR3jiS+CTf1GlMbbVKZk22tbIz/Xs8ys7mzrGdBkIhGUr70l KHVaXStGs4jI7GGTGTxEP3YzuJSMpzbD7GUNc/m6IQYzpz/d3TxilqTG5bCnJ03J4oqaIKiuI5u7 bBDSDpfWlbXyQ+B540pXOtF+HOI052rUdqo4n9z9oaYva9pg1/qsE9arcGOYyOIa9NZAJLFCjHnE 0m6Syh4BtYZFHGoyf3jVtM6wuhV7S51uddt3dLWfi0nkhcpZpC+NIVf1WZFlK1vY8daglCtr53mP t9YC5y6vM0LSDwIVi20toRUNKOmDA1mE/dxrF89c5QQmur4SRHSfN73qc3fZ5KT/HnW6Q71uePuT 4hFNtRVlHhHlRrCNBceqjh2ITICLFiNEXiUlYa1TedPcxwZ/YVRHHkkMAjjkfbxrtFXuyxwGs6ch bmYKxeh0cEdXkClltFJr+M3l9pjPZxewWoVe8nJvGeUox7W4N9xyHD5zoqy0bW+hiVMo8/yd0c0i 00N4cyFufZdblDBndxjrW1b5x55V5Z3xOhEV3rqaRU94YBMszL7Xt5lilHrBbSvKVzqdwy8NoRBP /1wgBj2KqdclEkMabxiO3OmCfGG3f4xuk5P77W6X+7znTubWNxnCHjQk2rMd+9QjEOfJDnzzWW9D 3E7frlMvpvVV2Fom4zqS3u+5/zffivtbRhDTx5V9ptVP9AwWN9F7zKZpCcnn5+uwk3jscePjT/gY svSNb+Vf/GdXYpR9g1VhMPV76ZaAryZ9Dfh9gadB8XdUjQdrFPdx7edSBghrGJhgzudM/gRe9QeC O+dLvlRw1IVCprR7D8haBYhXmHZEJDSAEVaAo+VAycdjthV6rVRYaNeB1xR7uKVIIfRakQYeP6hr ZaYUaxcSayZ4TAdl+ZZiXqRESlh1LzWE4JV6WshLcFVfKEgarkV9IVGBClFDG1hPYdgRFBVltaWB bUZnUYcSElgS8GR0DFdnvEcqd7iHE/FjpAWEhnWFu4WH64eHTgZkutSFW9hQjP9IQCvxY/YUhX9o iHH0iCOWS0p3Emjnh5C4Euf3Ev51FYk4E45EiJ84E6+EIKWYiq74Ua8Yi7L4E6O4QZg4i3pRUbf4 ciOhUJIHFL64hg7jeVK0izRRhKgYEQj2EQrVbZW4hCLRjEF3NLQ3dF60ilbRRGYIdMZYa+dHiTwG R8TIjN/YjePyiy04SDkohp54hqo3Ec6EddH4jrtmjttij8zIeGOxjWT1h8nIYPz2UzuUV9/Ujm9m iYGUEv94INmHR72oVfioE7MGa+K0UZxkj6IkiSLkdfkUkXf0R3O1XAYJj/5WZIHhkVikceioEYsE S3WIbmHBZH4UhrSkdRNHEWz/5n3bJkQiNEO1CF9Wh4ripxIryVkoKU0jCVUoOZFEZ4kCWY34hkvB 1xHmmJSEFUN3yFBj5GAq5YnQRIaKxXOMdhJfCY7ymBJuxUGxNo2NRBIIBUjCFoZ++EWOZ14LlZXv 1HWk1IoMxRHCSFtMxY8XV1MjBI7klUNLBElcx3VtxJcjhpga1W5W6Y9QiEL+95dPZmD9KFCRKZAo 1F+X2ZcTUViLFWMjJVE+FEWY+RCO6VOZCXShtIib6U0L+WfTtm1jZ3DQCFYkBnaTWU8Up2+E1YVO BkNbOVfU1lZrZlMPdk4Bxk71hZNqpkhHaZRFSWEE1VssKXXnpFm1OGHXaWYg/1lMvzSOjflOWxSe fzZS5Plcv7lpg4ZWbeZtE+WH4BSIH3Ra42hk8aljnRlJhlSLJXmGnsh1P+liJUZF2ulP1ORrP5eX Pglr4oVXmmZILhWdElpf0GdSjZR4FYpD3LVXrUmV3rWaMFlhS7WGojRRlERxCdRePRmHNPmfeJVk Ftei7riHlghcEmSi03aWMVZQNPZMmEVjKkSXcTihrrlOwqVGO7Z+u6RtIMeBf/RBkySkn6eCWMmW MzmVXup3jjVZXTWDe/l3jlafZpakJ7p+xadSqCRgn0RIOPqatNlNRmqUZbVJqJmI3zRPUBSlRPpg c0qnWKiETxRMHGiSo8ZCsf8WfRF4cb/YTYfqUD60XLRURTXZaCkIqfQkVVLlQkzJTVBIpHdmW3C4 eKOadIL0ZWUEZz8VVW0mm5PnjRhKpWA0qZJKR2uoosUJaGhUaAFXRFNnSXc1kIm0VMtYdRQ5c6qG dBSkqVFXUEBop7+WdsCGpdZVbE+VrF+KpMLllHwVX5jqdCD4UpkmrmnKVroJga1mau7ISp0aq9w1 rEuGoiyErB/nbP1lmLQZRkO4UCN1lhB3VBg3Sczlc1i4WAHnaVOHjgaVV6ulcbp2aQtLoQF1sMXk qCwaTul6dPt5hhk6WhkriPk0Wdk0gzGnpBQbb69mb22qbDi2pgBmsrV6m5n/OZQ3qlf+B5aBWnOw iFLEFbPRNVJ1ho0QyGimZabEZY3Bt1cUlbJfirG8yKyEmqcGJ1WSdXnOiqdUS3k522bRZnjzpUpT l01RFbZKp0Z/JEFTa3E5J3A7t3qepXGwmplY21JJa4bFlmDzOZpB60g29EL6BrgWeHWD13wm1VYl JnjcF3qMGWIRd6P7hnfoCrl8+2yFCbKWS3Qj1KmKW6PfmrkiBbM8KWxxCnjIdn0DlZrTykNZp7om 1VHJpWRZZ0JCpHutZFNdy7TJ93AdOVEzy7XIZrQVRn/H5riPS2/SuUqqG0L297rTd07thbuNiX8s JoXaKqu/W00zaFJHKl/I/zVQO3ikOimVYHtk8baX1kupjJWQHghLyyd9qvu82dp8W5qf/tZeqBe9 FgtQOGdnzeuSM5WF2MthDwZT+otD3KeWlNWD4nu69ShPP0i/7UaAaVinqhV74hiQsSqBMNWot/qW Jth4wIbALwiDJPhnKnhSMgh9qUdtM8SDnHXC1Xdc4rh8Dcp1skfBLJiXq6vDztuwb0pUJDt+HzhT r5p/3ztQSchJ70fEJ4t+apaEO+xVeyiYoMiFfqnFuPnCQTuFIvGDIcnFD3kXP1idvuRblUfGrOXF G3QTfpR9z8evdaq9VUbARHiqM2y1BIXHJbWITnVodvieKuGkdgVIPvrH5f9nnVE4hmicUe34sSUR TBr7rnjYh4qcVcgkwlpFjyOxydCqREnBybYGSLUJqrWJmwlcmBycEzKIk6F8UTiYyjbhSOAaE7ZM yDqWFP15EpIMonZsWLOsy6JIy/8WQKGYGQf6kTyJi8NBvM4czdI8zdTcFiksGtdcFY+MIL98Gdwq G9+8y0jhu4RGzKQBlYrKGNmcGeu8sUEhSSNZyWKxzeD3XpiBxZqBzyMaia/kh15lzEuhtbMUwXjR y6Vh0FSXE4/Ux+2JEvS8rw8tEQ05RW4E0AAaExfZXxoV0UQ5oBlKmwu1zymBiWwWzrT6Q7jVklWX SR7tEb64EyXZzPh2y/D/aM48xUw0PEz+Z9MzoUwdSlg5bc8+kcjURblQ+6BoylPs59M+DZgE1c4w Eap6pclF/BEZdKD4DI9byaS1Fl3E1MpX0YQTtdV0zK43QdQrGFG/pE9grWPsN6tp/MVyONIMfUfu GNGY1NINzYbu5bQUmnD61nxKcaA0lZmwJNJo6ESgVEjEiNZnZlYr5XBv3dWxJlOe9IgXfE2fZUMV u2ueaFp6bM/PR9O2WlUd67NsMVb7dcEjapx8fFCmtXh1hndivUqZp4wCx9MfjZtVVFOSVdX9Jk3T CbqsFds190nQbHeW5qPeediZuI8GmljyZqKVmdQ1vFxBJ0dA1W2s1Me5/1u1ZfS2JiGWRpasF0ja p33RI5RtqHnebCnUqG1CpB1eS5qOaop6WDZdjhp92lVqDpVsCqh23b2kOUecD/uG+jqdMtiavDVr 6tVfKIjew7mTwOtnluTB7QjNfPq1lZVtu6aXtLya3oqd9b2Xzz1uzVrUwPd2HfZqvremo5ag7ZbM fgvj3vSilDhZc5jZKoXScd2UQ3bUH5lRjTaTJelm1i3RB2bjimpLNmbf5pexkISpa1xSSrqoavnf J25uwfd7c8eqbQdiY4ZrW3RmHOpPiOqFDyilh+RYRXhz/VWYYvuFj6q5tO3WOVVdaLdayZSlr93H ddtkq4tnuWp16zpgy//6U7k3miyMWJyr1ru7Tddr1vC9civeaSiucl9eamS2jWKHbgLLbmue6G3O X7WGWDx+glAaxM/WoIFWcf2KEa10ua+swBu7yRKuV8CaYIZXWdVKbRypW6WeSqbOoHV53Id05xSk Ubnnbr/G5Om96V0+lXEH5p1Wd1v76OoafOZbRu3GacNa3+N3y4nlWnAegqBJQbqb0Om8u8LIfgne 7kO35HhLsKr+tZ43cOju67y7tEN3Rut8ejf0kk17k7AuuTBHYGF+cpnudtbO5Zwe8TXLvfsVucoL tML7mswF18Rd44HnapmtcR7u7wTa4bum73xlVl/cuifovKbKtNK2u+7/XGRiHVnH5W3IO19cXHTx OuSGa3lD5LyoTe3T7vBh9vCWTncsR3V0+fMm+d7EXnz9eeY2q7Rg2KCGF5enzk5haGVhF6u2a3jf WHRnyKiaxOEhRrg37vR/JoTFe7k3/qwZtJ/Fltv3ZHlVZXs21V6EHlCM5L7bC9J4t44nWHQ8y3YN z/BFr/gwCXea/r3Id/jIdsHkPLcAfIN+Lr/Na0yAD4ZD9o999nohDbs2q4h8JI49JXLXJ734lUKr usBGnHChvbnqnvkgKoFS/eFMjEJSDH8iPH/qDkRnr/AO6GkKaF2aLp4P72EhnGe+9GhAPH1XVMKE 6PtO2uyxx4NqH3Up/4XQ9AbVrJd/4uhONGiTcG+dhA+GbThlSbbnFPxQqEj96k5MlUqy1o+VrO/H pXRiGlwaTQwQCgQOJFjQoEADAAgYQHCQIAEAESUacPhQ4sSKGTVuVLCQ48eBEC9GpAjSpEEEAE5q HElg5UuHIi82dFhyo0yMJ1NedAmzoseMOy/aBJkSAYKePpUuZUpQaE6YSBFyfKqQ6kibNJtuNJBU o1EDRB1WBSB268GuZwVKTatWJ9amVbOaTKhQq9urEQncBQlRpFm8gd0K3auUcFmOdYF+DEs0IVKv gY1+9EtyI1K9fAUrCCt4cUWkms8qFu2zMcHHBCJvZm0S7OrWsWXfnP85e63eiKWbdtWNkmJb28Er 1qWtUjjenSJ7H2fe3Hnr5awRUFS9ufPKws+df64JILr2j9M7wgZf3vx59OkpR1Tf3v17+PHlzz8/ mf59/Pn17+ff3/9/AAMUcEACCzTwQAQTVHBBBhW8Di/AGlzqwYwihMlCCTPU8DnMMPQptA2X6vCy 7FYSy74QU1Rxtuks+zDChDxc0TcXNYoxqqyqm7E58XYsMMbvKoQNsiB9BJIq1Yo0KLskByPPx4Ew UxLK+CiMCrGDsDToQSu3SqmnL9/rMiMtt7RpzL1AdMoqBcI8ya/HqETNLjmD807EtQoyTqkm0Yqw xBIHY6/NQTnMk6D/PROzENDS9gJsp9sSXU81Nqncaco6lxJJqdTKlDQotHr7dCA6FSgVuaxkbK1T okatyFWBSj3VohqjTPUlmlTN8Ea0ENRVpwvLfKus3BDtq1cyf7qzo2Xd4vJXXJfbqa67YM0yI4ho yjbLiwp6lim+Rup2QTUPIq+uSr2F70k+nROvx5BA+hReh6yli77CentXLHYNsvcju6SS7sl/CQzU 31AF4m6tfrUrmLF4z1tIYI7m9fDhr6A9TryEVGu4oIk/JrUpLDE9CTiEM2z2WpTa1NFM+DDOeCCN H3KL0jHr9Y2l3TwErOYriS22L4hy1pmp3OgNzOhRJdLT1EGd1rPQ/1ihNk4lqWOlOlGu5eUZLWFR Azqwop/umeaYlpN5uLI8erninbNsSOQo/UQ7zz6jfFu6ksrmqm3qRL6TbjIlMllRznT7dE+uGWfc 2KpJlZTqyE0d+fLKN7J31IUR+i06mhoa28YWW11JtAeHpDxlwzzW9iSLwV4IWqU9R8iqaTUbWq1H p4SMScYUMromblf3kj12JzfbcsyZd77yxVmHvuqrTdrcorzXVKnhlMLaXbJKR502bm9tWk2o3ggH my+N5xVNJiUZshvqhQ6m2X5wRTuqbhtX5my973FFNN6R39IMlyzIYa5rClxe9JY3PctVLzzXU1hX FDIqdC2HN0c5XP9R/PY8hh3FLAUsX8QQ1RULxSkqnVtJojwWk1px5FwNeYpu1AcqmqHubqBhIQA1 NqQbvkkvX2ue8xYIQQY+MHNGZKLM+rUsl6QJNn/RSA8Tc8XS6Ukrc3OZuWqilaRcKiizws5ZsNQY UbUwJrZiFwnlxpme3KktPSHKudbioSCyzCRTHJ0HNafExzUvkElMYBEfd8g9ssQlDAlLuQpCsTVq qjgBNBVFMKOQDxbSZqSiYZqq2EGFlWV/oJmOqC4oI5QBTDOfcaO38gi3LWlrlOYSpb5KWZMbzmtt OPqjJgf5vF8yUYkgRCT1KpQ0/CGqJclsE4aKZsvpAKaWj7TgQsL/pjVxXdNUq2zVKWnDEGm9Kpvi Uk0rl5S1sWwLdiUjDsPII6XN+A846izeOCVSTv3RU153cdNm4ElEQgKzkL90YAMBiS24VPGeX9Gn v+xJzgg9lJLnzA0axVmSFklKJhWTqF7MqTeceNR3E73fRydZGzj+qZysGdo/26QvSrXEpKiZ2EuG Ri3WdMWKRcTmA4/YU02CUHIFXaJTfkPSR8ZwSzUNSkyXOTuYLnOmSfWfssTFly9955J62ellQBkb dEGlPCHVZni+ukdx9TFTFdpKT4bkq7S2R63ymyqnJjLSaIJvKPw7WXCq8sq1ykYkfgGZd7IXIHR9 dGJlzSkoFYPU/+1ckLGcolBq6FZXCHk0sPCJUSaTo1R/MnM2lTEeWLsKGrtMlke/AeywlMOY0242 ReDc2fDwsikOOaqqslGhgkQrmcCBpLeylZMYUbLbnCKXuPzB7XKd2569hSRdz6VulJRbXeyaB0XZ 5W53vftd8IZXvOMlb3nNe170ple962Vve937XvjGV77zpW997Xtf/OZXv/vlb3/pO1haRQbA/iVw gZtTtjkiZp4Kbq1XDfxgAw8KIloLpeQqzJp8QVjD+5VwSTps4Y6odSxHfeGGTWzf4XKmqikWlNCu e2IYqze60R0P30Ip4hjnGLtNOxpTeqdjIM/XnB/FrINRssUgJ/95vfobS1RQo8OpKFnK5x0y6mgi xziKzq1RVhjxmjllMI+3n7c533RtmrCOzDLMaz6xPJPSUDbHOcLLcqma5XxnApMVx3jmM3vlwtc+ B7q/p6GZYRssaESf97MvTnSj4SseGjta0pOmdKUtfWlMZ1rTm+Z0pz39aVC3dc+hJrWEcHJWUtfO S6O+r6r/E5p2lhpXkRYRnHPsUllTVmz9GZGTzPxcVMeFsAuybXsD9dv39FotmEH2Zg9dazLGh5Uy 3OV5TxVtL1mn2afDdnWrvexuP3LbrdFnw1JZX3rauik31BVsamYWZNtTTt/W2J+K1Fzn8CokGIJk o9dW5CqfDKv/7QtstfvdS2q6Ro6qBd8qF/Yl2kp6bc0257gVxj6Cr7Xa5wYozYDGwV+vips/s9q3 lTxxxqySrUuCmfWK9zSpoROoI4u51ZT5059uZeMZL+GH1G0jZD0SNUcuDUO8kxI5/7xg23qYOV0F mVBeOZawY13jQCzQzFFudYPE+W3p8jnibbUhGMQUGJE9l8NCfZs7rKSDj1Kd2MJYKOoq6t3m3nTd 1etOcwfhdmFpSEEmUHlFJaowsVb3Cf0KUjNspuEO7veKhYXiuCOJ7vY+KDXLnMvs8Z5O5TwuhvE0 9CUXatqkd78r17zQuTxo1gVv0GEOnnmHL73PCZdB09+OIQfr/9jJMPkrjyaTN7czjhtjbSviK6bI Jr7LRj0+MjtfZ6N7cmbeWS7dqEWK0aeXfdeXGEyhdr+JHwJZ3EOpze5Z93vo82DNavgTbxlnilNX cWY2jOVYabnL/zOqV7hmwQeajigyoXNyCXhZjVYSwP0Drb/7vsALKGEKKvErpvyDowqcIy5LsxX6 CTixNQaEPxxpI5UrvdVIFMjDM0DxCudTGAETHckpJ8n7iwPKQAtcklxhFqqQptbDOiTqQcIzKAq0 K8y6JeSjpbDSCvMpmAMUJapgH904twLyn357m4O7M7XDtQGrs+iypzRhQFxzmciovIOIpsP6Qdd7 wB4sPB+Uvf+l6Kh7IqEvdBnEyKRhE0Pf0CmtcMM3dIpIwzW1a7uHyIrdYTE5QyGESLtiwcOSGkOc YKoqWimaMouteqqZahqtG6ipYUPE0zxN9Dku/JmaUhMUekI6IyuuckR3kqneMERzgcRD7KZcKRTX YUHzyzVJG7YGIatgs0UQZBewYDX24jgeaRdh1L4P5MXdwKTSYhYqQsbbsaYpwQkMIQ1njCfJehKO ebZbvEbfU8Bq1A6jOMGH2MVJAydt/EZpW0ZbpDV0LBBxtEWcakd5zJBaNBJgnEd8rIl7DJ7dy0ew ChFWKzYCAZJzTIyy8Dz9crUdIUTfIsd65I8YQUjbaIxMugr/wzC58wDGYlQRZiNH+QCRXxkehisj 9KDIkeQd+1snpVBHfBmNkOPIZ9qQDdq28RnD7fO99KBG4fCLw2FJlsBI8wDKZ/TIV3tIAJGKdzyu ZrEgxLhJ6xFKteBJ5ki/nsTI0hLI8hBKR8oPrOwrjoQjJLuMVFmoh1FIh6oPxOggo5ywnyOTProm i3MYc/mVgtxJotw/fGE17iCcJlm8disSn3yTsWFLp7SIqqzJ8JBInVBMRInLJalLPcIoyAqq3ZiN cGuXieSTwqwis8CY+umbIVIlo+mRwOyLzZQcxBSukzzLHvEQwtAM17wn9pEuUHqtK4KJPTFAcAoS qLy+2xzH//WQltLoHkeCTBB8CX3zsQFKOQ3coKK4oHeyjNKkwfgbHfaAF11JSs1JlLoSni9SpJ8h R0dyJp94nKJpS9FDGuack968uDYpwCHKln18lSuBzfK0SbHci+rYSKF7ikW5k+mswtsAJcpZvgQk HMuYG5jClgXNPcHovR5To/wjiWNMzzakDKxazRFTsRKjKRUTQDixDVjpNnMyy46z0KEiiZfZqcyo yJYxlct6kgN9SktyzyZju1CKDAsZFwR8MmzZEh+NpAcNTT2SUMvZn1FKwE3yiYp8mLfCJa2i0Mlk C2sS0bEg0rt4lMrymiLVO0xajLrAEJkJnZOkkCwtQLqrJ/8CBFJSEYve+sP4C81PUcFK9M0QKw17 kUrmRCFmMjnw05ozRVEBSs6HGVPNG0PQ5LeOsMDls0ENbED2RMITMhMwYccHAoqG8aRWrKI9mpuC 6Qzjm9Q52aJIQ5ekgJXMU8eJ4slTTSpaoc81edUu5UPMeEqGcxXH0CPOqRE3qtDLCB+b1BJcVcrp +jEAKhrMAozBUkebwNVmSVXu7JPJTCBIwU4h5Yqg+xvbHKPtcYpqUdXdYlXKRIgsXcbh25IAkpSE iNQIVTF2PT3UOxlH4c1zOpP34akYXNLzax1hRYk0aVZEjdO9sbO1CEuwsajwcDfhKSuKeVZRChTj M1eLS4r/MA0jLV1PoaO2+JlBcmXP4cCfeBzXRbVTkLnS5bQIR+3SCQOZk6VVnajHZqnIIWlWMArX 4xo6bM0iREEyA/Q/NCOz72RT/vNXx+SMM3GKQ2G7B6Gz4CpZktVX6vTQ81tKK8PQMfzVuGzGNcXL px3QdqVMxpvLa8VBuhtB6WJTvliNGxJQzenZLnG3Zi0JMfWiraUoSkrLwaJDlX0SO/oyc+mg/9MM EdInrunZCoLXkaU/qC1YzxKwsf3RXoG7EznN0QPboF2SRXkVrHK3c4EVsVidKGqbZfncOWUWC3JB 7CHYjGXGRuIg1x2lWeKJrwWm3yOTzT0hOxPAhY2ocXLT/8eMVVj1FllyOOEkQha8uYeqIxXMCdiQ Qs7lltkhq4SjTP603MdamZg0sjvyl9tdqu5YuSzhlxOBM2XbzjoyOsnC0zJZrPStp4dyRD0UK/ip l7RdXpYsE6TopoeKDvhBWNTCXlFhnzerqvg9FVzrKFLFXqdBXT0RX3EjoLTdX73xH3lySmG5jkaa Lj2cRYYhYAfmw6oq36eMRY1yxZAw4e3cu5VF0h0tllp9Kb/1V6yQFlO8J3yiKsUZ3fWbzJuinEn8 vSAxLhnKHrYF1A7eonzKJo9pXZo6GMjgCVRURO0RIXEi4fKbndX5YSY8RPtpKRctnNBZ2YwJqYkp ulAskf8eLuGFWWImvSpyc2PTHIm7tA09gwldfI9Mjav+YJc7vlJgJCv1qWPBqpQ+ZpGE+t1GvdK9 UrhFjhbw+KsPOWT1QLY/S1r8KENj1NC4aAluk93ZQJlKRmSP1EmlxLdguUy2QeWv0C6xwpWUZKg5 TqciIbTbgVP52EhSFo7EOuWiRcluWzTmMMdY3hgfMeWcUqtFG+ZEE+bykrwZYchka1p/RK8vnmZr vmZszuYHnU9t7mbreNiYACxL9ebAKuJmPsg+BCXVxRVunhFzBjMQfS+TBEVO0cbqXZF7piVlvq9q SmQDMVGXVGXtgNC1GsWaMUp3aWeD8efy0E7XQM+2UuX/r3IsgQbIkLmstpEhhfYgyrVo5uho7BO2 lxSUGlWklcyjrZQTczxJqeBYsNk+gDaNivYRpNvJ6RwOcNFTyhgdwlQbq/w244zkt3vkav6Jobai MWNQvVLnowtqcuPLJnxPymAbHFvnq8hakM6NCl1XmcbN9LinkZbqBy3a3RtqM8orlxQxsHZqa/RX uc2WINEtVeHq0MJIx0zOFlKJ1kSg++xYgEHO/Fkf9HTqPKIUStnFLwlrofXXIlnnTtGgfcaOedm3 KTGskfaw9jxYfrrJmE6qr6KaqWqtN3O5qU4cpsiwG+VrCDEZOCk2Ib5a/6Q6B5UhGsIhyM1J7jQf qCJt/367GmsBrDGRmqnqyhzyVxp9T2bq7A1FvNkN2Ec9HRKjMcGxjrJz4grpSL3TT00eUdCJbvKY bvWo6Q/1uG1FuPqLYAoLXm47EUJ5u58TyEAtLB0VJwlb3aHVR6+Ib+YZzsXVR64dFtxD3FkdDQW1 7ee+MaxtbtIecKUMcAFPmchecKOWarVBWkL1bdW+CdCknPx+xssFX0AcVZDqDjlN0xB7pDAG7UAc mS82Hft+vtrLQQSnW/N2lkvaWZw9XPWjCCnct+PM2fkdURk33R9PlqL+6IAdvqxiLMveIkK+Gj5+ zu3xHn76bvtxaGj9yfexi1YtQq3xv8GB4e19waqBs/9e1ZLWpFgP+01vlaG/7g77meujQPNCoRd8 exeqSb/sILnEoKEMYlt1HcO4/muIthN0rZFl/e2cyN85iZVFQtd706z1+TIBRB3FNu1Cs5ZzjdNw CVLiy/QNcoxylSBJ/e/mkp/ksJ0YjxL9MVgRh6Xk0BaZe+cD/3S/Jj7YpJrByhUmo+1CK+srbfMj A7RX76VSRw9Gj74CN9mR3fTb+HITnGlmeUlT1B+XLvL/dtrjatnE1ZtMD/PFFRh1NZ+bxUvgiEIB CjpJxOSjsSQdWUFVrz6w2dqUdlftM59e/wo6hyyvIDIcdSfA7LnnoJAGQ/V4ZpmFCgmTYVumvN+T 5Jz/4WiUP7Fc6xKdTr8+ps05vHSV0eZUZKmdXKKtc7d3zOFb3OGXujWp5a0j4pHcVhSeQldBL1O1 XAodun6OJ2doxaifVraZS6rZiAON6T0u76EzWhpy58Wl7/WyCuRDp9Xg7uWqkm56b6d6H58Kj/GY ZiG7i2u+aQKNZpVSMIrhGvvy2dEpKV0ZEkr6n711Eqy/8jZdlLpvanEkrk+zCA5656Yfj4hwW3VD phJkbKlSaJUoR4zD+lPKf7JDapJiYXk48j1yUb368YbRBgaZDdfr8CEKRtcajDq++xErN6NN5H3f Opr7Rc0Ol+LCOUfzt3n8dc/vvblguTU62Z/D9WWT/5D6XAEm/dL/RFrRfLY+HacSqY/V3WbTaRC2 YWdCRY9LYoLW4lM8cyu+YnhD4cKRWwlzRTtzkVgTI9tM4+BHfY5KcSR+YJ6QlleecSnu4Dc0Y9Kt /kjM9BIsRXsZRbbx8/N2KPNndRkGCAACARBAoOAgwoQKEAg0SKChwogSJ1KsaPFiQgMYN3Ls6PFj xIcDIYLkKHKkQZMjSUZkmFLByYEvFRhYCUCjx5gCcZbs6XOjTgAzPwbl+fOg0YlFj2J0yfQp1KhS Lzr1yXBk0oQECNAc6vHqwKwWwe7kSPZmxJo7vTZdyZPt1LgTz4rteJarXIp0EcLN6/fn1r+CMYo8 qv+2oF6BhX0e7lux8VfFjg0bMFoTQeCnVQcrhGxYMmeJlS0LzRz6NEa1k1HH3SzYAALMq1nTjkyQ 5c+BtXejvipyNu+/poMTL268OAKNw39ePu48anKYeJ9Tr279Ovbs2rdz7+79O/jw4seTL2/+PPr0 6tezb+/+PfyoPGHHr2//Pv74ABASzO//P4ABYrcfUsAJeCCCCSoIEoELOvgghAlOh1GDlUV4IYYZ qldTRw0+pCGIIYqonUD8EUSfRA2WOCKLLbpI24oaYTahQkIdtCJViL24I489VhTjQjQmxBBOmM1V I44+7mbTiirmFhqBDSYkpXNO+kVlivfVtNxFO8H/1pxEDD1EAJghdWZjRQYqWRKWWXIXpXdWrnnR VjXVRZFOdREJlpD8PcZXbGSqOadHbUZkaHVwdicnoRMZ0OdGahHU16Q0kfljYgap9eidjT45kZX7 6abAqBRJORKmfqpKaqmK+ukkqlOWiKisp7Ka5KG6iVrqjbj+mCSsrb7aJK6xVjeTjgtFRqdiFuFk KGZheSoYoqGqyOihq5Jq6pTdbquqq99e6+23rHa5KrCpmouuttzeiK6t5eI4r7a0xjXmZEahhZRe YdIabVlzZYblpgFPe6VN7Ja7MK3YpirquwuLG7G87YYrcbbeUtmwxRR77Ca4HVdc78f2QlfQh2nO /6QbigjNFyZXW83I10DJpogmlZcOerBP1YZMsrsYuwsxxqMqGq/EF9u7ccnqMp20RYZi6yrSRfsq 16PAJaUamgcZuRBbmB1GUqXOJivlozyj5nPEVXNs4tXdwgp32++m2zTU6tZNLshPMxk1qCIzirTR R00mW0dCypakhV2JppGFjadNWI0vjak2lEGHW3XGnWc5d95RUi14jYBrXLrmqJuMeud+A713uzdq ipeNk+PVKUwftclV4xRDqiORCNlMUcs3csUnUjLujDmFqTPMt+fQlw6668+P/HPsrMP+MevVZw/9 6Kd7HO/TeeF7eOxfazVdm5Ozyn5qQo5UEE5jd//N/FNsT/x639Jrf/26Nkex8o3LdAAUmsISuDo5 TW2AfNvc6nrGJJsIij9JuRRfHvKS+9Gka+pDYAY5CBNeLeREccNfT/QnwO+Nj4Qga+GstretBtJt gXdj4a3y1qsI5jCBsHMb3IiWF4CFZTIkUUtGZCarlEQLUtxbHwYVcpW+xAaFVsThFZkSlNUEZWlZ /CJUOAfGpsxmL1SxiRHPmBzcjdGKxmrjRgzkGzlK61wWGZPB4KjHPZrlOSaLjvv4KMhBPs6JrIng 8AipyEE+hI2ZYxYPFynJSQqnLcujJCYzqclNcjI70ekkKEP5lxldUpSmPGVIgFdKVLISlCgSW2f/ WinLWUqxTmaiJS7n5EipKPGFufzliKrYu7TEpXjRAyYyA2Qn4tUMT7v0CO4imcxpruc3/mqW15Bl yJ58MmgaapM0QYieE0qNQXIJZ4e8yUJ0giePGQFbRiy3TW5GU0TghJAXw3jOK6nTjvAJXjpL+MyP dDNwUBlonHyZoHzmb5950d9G2OmdRKZlZSVcJVXqqRmELuqFLtTeG0H10WGJbmPCCunNTjXSGd5w hyDcVbF8ZSyYorRWwYqpEKOX0xzCKaS8Kh9xZlJQPFl0noZL40YtM87+PdGHb2vquqI6uF75z6lR YyC5yEk4/omuqkC7YQE9Oj4TUVWBIhNO2RyV/5GkcJAhNSpI2AwkQpchlVReqWJqJjcziWhwURPE G1P9CVUghu5/4MOi94D6P6XhTbGLbaxhzQpZ8WEPqppBmb2Mcjmv4cqtNs3KM68CswmJhUCijWX8 dASRLTFxpdS5pw5bpztyPjBXjDWoD30ZvnWqzrCF8yqSbuvYytLQew60LFOylpqZqAYpnTUpr4bq LF9Nka58da6UpBspHZ1khxI9pJv+httbLa1J3iSceWP7WOQmNrKNTZhL94fY9Br3pVE9oHDhe0C7 jIWiSklL1zi0WIeYdnkC1soFwzSfAvtkQt0d4QlfG16OlHO89v1qb71KQAP+0L2F1S1gQfzhdf/u tr4X09ipZic7Sx3kdnfMiWiQpVPhtRivMB5SVvo0TLzAtSTFg1yDkmNU48B2uE2F6IXHOuLBdo/D 8jXykuUrw6dOOcQgPW5lpfy8795xUugTGmm9QiO0XEpSE1RMFAs0JNhqjz5mPrMtO0Oj42kWo6dh s8OyqmFZnZeyAfQwAMtr1bKK+HoqtTJIbysviK7wz3puGpd/deaaoWhfwisSl4b64EmjMYPTiVZp h5KZvXJ6JULVYMtixkQuDcijEWaYa8mbZOvJWtEihbLdWspTdaoUukSDrql0FWJhW3inxAbqRyOd pjw5hiTRQkqaASXFgBGRSXGGNk+2Em0TpaT/uZwKIZyjre3K4KiR2KbmVJSNIXVDZSnbcfdUAIpu hyLXR+wm4xnn1527zJs8NZ3Tq+MdKdB4Bywc7TfCg2PnhDP8YJUZcsMjzjxzS7ziFr84xjOu8Y1z vOMeNw7iPi7yHm2WNRAfOcqrM5+FDzzlLhcPLKF075fTnKAdUe6dZ17znVNOwXKGkc55LnQLW3BI 9BvowZE09NmupHnO6xnRAU1kLDpdtuLUJ78saDmUmOQo/Vl6QIFr2TwXik0korpgDRr0aauZP73s 9kAjzTiwO5m9TvO62bND9rAPbTAEShaRkvI1G/9KyGzqDzbpHnXG1hRVNA0u4GZqU+/SjaTq/7Wt 3FzreFnXKvJgrTdT/j4kwreYszeZaxAt/c6K/AY3io+scJ221bGTD8MK5NxTwypO3WM12JJdO0xw QruWdMZyj1L9oSCnOFYnUVQs/ziWint3P8/6yYGt8p6pn/sM85ayJ9ZMiT5JJXnTJEzExCFLxKLd 19v2jfVtsvZ5jeVHZ3m/h708/bEv4lBhbSfwywiOkB5fGJ1X4Rw8pUXS8RyVaRn8gYt+zRis0ctk 5R8E4lpxPeB68Z9maIVMtMuzZZ1orJVX0Ygx1Rj7pV0GTl/9yR8C7ZYMicsC2prVrWCxHVfDqJhd sVjulB8BakVLTAekFM/GQE7xKcTvOBcTJf+gyMXg2JFO9tGgCzLgDDmZDDag/lUgDTLFUGVFN4mQ Z7XYmBEEacnP4yAhTDzfxlFZeuHWhjWh9/lZ702PP9EQGzZgw8Th9xlOXz3GqQgeBkWLqFHbHk7J UBwYjZ2g1G1eD2Eesr2acc3UvOga2i0i/tVQonnRT2VhTzyKf0GbzVBccsRIL60Zj13bEnkNxSGi iwDfhbyZ6wEGBanii7DiurlFSbjEMPGbLLJIwPEMwHQis4gEaZzILhajdgDSyRmjMjoHMC6jM1LH YjyjNGKHa0yjNV4jNmajNm4jN3ajN34jOIYj1ogjOcpFMpYjOr4YRxgFGqbjLqYMnWiWO4L/o1eM Rphok9TNY/aEEzrtXaKk28zRIp7UUl2kGhmCoD4e09Vh3UJWiVQEnUBGnRSpCvlxVtslpEJGpP1d R0DGhUYqZA9uSzWqSjO6I5tRoqtF2Ob5VMDBVHzpEEu6TS9S4r9VHq1NIYw4SuJtiyGJHkYqlKGp 4O6RlWT5HqHFXlHG4dMtpAaOlc7hi97IxraRSo8hWOmJ0yCS45khWm4JpZapYfwJTfVYoBXun928 oFVglgGJSbLVUQnth/i5TNmARToWmYf5Y1lWYW1l2fdVGFlSIBbiZB6ChAEakIxwBTgZy6b8H4SV 1EfuXJFh4APF2gU2XZ/xZRB9j2NqXlli/yH13KLRqQmaKAdNhNoICU8H+s6oPFg52mVESeT8SeFl XiEUgt5ZMVTdfOaKTU7t8BhCniNakJu24daEfNAOlt+BGR46umb3gWRs6iVXcSVS/mVXpqBuNpiX jYWJiEQFMdGUKAc7bg2NFVRJaiOeoR//zCCW4WbtEeXsBWW9TZUB4d4kShqnVVCLNRNnFcTXNWYI 9YWqoeI5TuNJUubkSVpsxdpNXksMUV7n1ctMkpANKRZeNgWzjUUecWcABgwnOgbFfdtPTqObtWOI 7pwAfsWAligi2tlOqug12lkgueg1PpyM1mgq1iiO5qiO7iiP9qiP/iiQBmk5rp+QdiOIKv9hka4o BpUJaiWpNNZPf0rbMDmpM7IWgLUolbJf2FAU8mTpQ/2VsrGTmGqIWDiR8qyel3pkPlZd2ZlThmAJ kcZYmtKbbdbda7rpurUE7qSaUKHenPIdS+HUVUUisBhNq7Qk52Wmog4q5lkeSipo6OnpHVmOEYoi if6oSdEfe8Khkl3d5xHXfGpqWCklnXpNp3yhxDgFXf5pmzohek4gBTJhlOnNV3ZqrfKTFJ2qGJle lLIqm0bZAsbXeQKXY/3Wr7qq9eBapEqRY6Bq+6CZr7bqe1nmeBmr5HkXZ2bVGtbkkXFfskqmVRyK PM2TGIlJtOIprM4h7MUmFUonrSJre1L/GA725lVmxb6MxmpIiZAw37m2a1jWof9EoawO18B6a7zW aUng0TORFtv1q+6s10Y61Qq9Zw3Cmq1en1K+p0CyZkax3qUmKYU+KILW2qIeqskQELEl6siK7IKy 7BC9ol5QUYo6LNjNLM32WxWV56Te7Mj5xkwKzMfyrCzZCZNCE5IKLdImrdIuLdM2rdM+LdRGrdRO LdVWrdVeLdZmrdZuLdf6FaRW31QcbdfuiLIyWV6U4Njiz0nCJivqbNoCHIUUC+T5mhZ9hNi+LYCc bHQS2k3mHX9QUZzi7Zv6K36dVQqtGbT8rOA+CG7C5z4q7ngh0XUtLtkSLh32EDtt0Jmc/wnyUe6I NC6p0iG95qDtgOC+ciDkeq6DMOd65qVhFKFzoa3qfu6V2eqo8hlU7JUJzq69oZSEzu3ksRuIJg/v cpzNFm8uTSnySpxxLm/EjaTzJlyMRi/DKS/1Xi/2Zq84Bq725hIpdW+/vV3Qgu8evdJUkq/3miL6 AtMori8yya774tLdxu8XldH80u9SOafYPYVRcS/+5sfawmZUrI7//u99BDBQpltT3K8B+5tuFSoE sxsBj28Dd5TnyGd6Hu5FwG8F48dWAhZ9Lqte8GsHe/D1beTXoiDiUnAJn5164tcafkXpnOj5tjAA nzAGD9C84qCLfSc88gUD23B4DOug1f9nlz2XEC+UWNku7h4Fd4ZQECfxd6ythBLqTnETSYybFG8x F3exF38xGIexGI8xGZexGZ8xGqexGq8xG6tx87bxGJUcHLfRjYZEFM+xg3iony4vtTbkux6STKVu bcBGD58fgN0x1bbheGDwY9rtbdTOlvoLC0Mt67aTt/oxayQHebKF9XLwLQkux8Sk3tSkSy4ilJnY ccjYJ3dGkaBpavRq2laLxi6l1NxuJbbu/jpxWqmV2w1FzkBOt33nwMVNVlqtC6HyCVfrv97a/cmF VNoL4f0uzewHXkRzwMmGm81lCjutsCwzYC4xLtMyURaTzhZPNHqMpHQbc53QaMyZoQr/ctPmVx9P Jm29jj824hWDZgapyfJpjzAeohEqRWqi5opwbCJPGPX1U7faM99CoHOO7ugW8nFSWAj6YEiCGV+d SD12EBAf77lWMnRW2AXXFuhyJSxWZb+s2EXzIBATYi2lhSHRmVZMspAqcjirp0i3rN52KkSWmkYX nVUKzP0g37ZVs0zTGPCQcNT2MT6P8koR1iRWMTzniFsY0WiekLb58lVjCWL4bNd8aA2rcSMPxhYR RaeJIBiaKx4fKzWWkS0S1Fu7jEe38VTXhoGk8yYSHCoi8lofS3FUBk33tXHQqGB/UR0XNmIntmL/ RMgdi9suNkfC8nFgKWR/xxun8lxX/7ZmI5wnB0dnbzZvWK/x0IZovxVoH0vncuAgz9MPnzaR4Q6q 3u9kKHVsEx8fb/MAQ+MCWTT/dolGXSVv8+6uUstzVOR/GbEKn4mHSs9YR2v0gRcz7rGp5jJFY+id FNRzC3fc7rY9vzODZt7GQktwYzJbT1txjnd2z+5OM+VeHiwDfWTcaJa+5HaXoE1Qc09zs2pJm86v TeD7IYzPETRy22mutLSA43fx9loMs7dgNqr0yZycyiXO0PccFfhFdtCEo06F461f5qMQfTh9pd6C o5WY/WBKcJlFlZ/u7idA7zOCq7hSX22H7++H3yrZPaZxt0/R8QRE8zBC3oQwCUmZ6P/4jRBhkQc5 5aZ32dY4Us4qWonrS/dKjG93c5n230b5+7DPTsDs2IawH9t0DJOqYFQkUWebOyUs1ym3MN/3P+fn QCd5W/IQPv8aoTL3XjKxBw71VpMi+O2yGZ4ihvP5ND+2a1tF75Q1a0xvY755oaM2Vlh0YLdEXO9g pDf6Buv1CG2FdNvFpkv4J4phW3W6pXOGnZx5CtV17LoTbo+6X8TGieb1wrl6PYo6q7+GZA/2rdd6 Kqc2yPG6rv86sAe7sA87sWdtUf90sXNHWCfXETlO0Sa7dVS5+WSbJhema7vEZVOH4OV6Mekbq9cM tw92pWfQlygGX38ut6oNLU5NsLb/BlxcRjGnckoQ+lNwypRnUdlOy7oLMML2RFenSbRDhM1U1xBl tr4nsLr/RU7zu6F30HBOrsoph0MUH1SCRLZPdAYtxLkPLgu6VK9FIHg7aH3Ti8n+6ndb3pKjpMpf K0mBeINqImNvOZdLFGFDxxrpIKSoNTS1lYEHlxx/EZK9N7zc3p1fptzGJ/fxnoczcnsnfaz2u10I n6+fHF4BDF85RBkBoak1trK02AVhfaYwK80Yk53EO77L1CU3OW36a8iGKrB6eNqnqws+OHPcI1B0 iI0cj5gpBjujpnJYW59KfKU+somLUMv4xj2O+4V0M2a+/S0zqnqtt9qzq1ky94LP/z2y3mJcDaBo 0PpixoZYbMkywQyvAjlg0zCmx268t3lAAyDBoPrBTL48x0r0Qepv+ZqCWotlKrnJY2ud2zhDJ3RT xFNFs7TRPTZeMyznF6LLFIlbGuGnPf9bhOClGEqfKE64Mw9Iy/1C8zsyl92NZ0wv/rfjM7349DjO /yYva1eKOoUQliDoD2J2iba01zGQj97xcajGR5bBN8r2A4QCAAoIEhwosKBBhQkPHkzI8GFEhwsn IoQYUaJFjRQxDqyIcWHBhg9HXqxYcqPDkyFBtrz40AACggQQyExIAEBMmyARGIhIwCBQkQCIFjVK 1OdMoQWTgiTQlGBMkkePCu2pQP8m0aUCdxJEsNVlWLFjyZY1exZtWpYaJxIVOfStQZVxN6YM2xYl 3Y8tV4bc65GsW5ZzB+cVTNgvw7xqAXRVYGApTsdUKQN4CrNxUMWVidr8mtnrZbJfwQrk3HSrZIZQ EeRsXRO0Wtmzade2zdfoVLd4AQ/tLbetxKJjcy8GbvbjcLoky3oUvFn37+LHg/vuvfds59Cxa0b8 bJSmSwLjm3YvSBr8052Qw0cVLdaAVozftb5/7Phnzqhucea+/R/AAAUMEDvsBjxwNgMRXHC2/oyC isEIB2yvpfiOkukr2PCTkMMOPXyJLRA/HDEjEk0Mq7UHzzuRRbGe4+koCFuckcb/2vyzrsYRX8yx RQN8TCg+0nicUT8UtdpwyCSVXJLJJmlMsT8knZySyiqtvBLLLK8aL8suvfwSzDDFHJPMMs08E800 1VyTzTbdfBPOOOWck8467bwTzzz13JPPPv38E9BABR2U0EINPRTRRBVdlNFGHc0xPqkE/PHRSi29 9DH5BKTQNtUw/RTUMlOEbEHLpDzrKUlDXXXKv2xMcLkhZXzoMkrJmjUsT2n7yqtTWf21RVdpUxC5 JVXF6FiscAXSVwaRIhXYaIcUFlbbiD2R0xUtRGqmsbL1MEXLpB03R2pNU/BG53ZUriPgrh2xtKiw sukyXsWKFyTImj2rNXzJ/ddD/2oRYy6uFxErMNZyeepOyMegzS8rhpAM1ymZvp2PJnsB3phEztYy N9bFBF5yL/T6PS+2x7wazqEU5ysq3v76cymp+Mbbl+OcARS2L4J95kjExJTc66nGxG3J3un2+8hC LpG1LFKkhSpqWZ2tJrDdc2+MLmR32X3pXbRw9i7hmix2SDKnHZ6JZSArOjki1ryCCUifoLwab2ez Dtskgt8d2KXMoBVcKKGaItwgmaA1vCB/X1vZMm436gkosCzH1zXvKE+5ZVvz/nznvX8GSeSPs64L 0pZqtdsnp9WeSXFmE2oNN84kV+qmsUHf3cXTAV+udKFLRN1JXlN07LOdGj7vdf8FLvaaMuU9/Yz3 6l8d/tyf09V+Xb12bLK95tlbz77HytcYYwctUw/Im91L1vr4r36+U/ntv39X+mvTH//+/WeqavnT 3f8IWEDaeM6ACVTgAhnYQAc+EIIRlOAEKVhBC14QgxnU4AY5mKSrdBCE1lteCEmIt88EsIQpBNYJ VdjCnBXJhTG8VPlgMkAZ3vBPD9sQ33AoLcoMC2sf4mGxavPBbmFvNijs4aCSU63/DNFaB4LiT8AC MrXAb4mIsmJzghgwKR6wNFt8mLdw5q8s1glhvoGIf7bWke+x8WvMUQ67ekY6relGOOvazYCsOKqx tO5WRzujntIYIrn07S7AQyT/buACtIRNBWyK1Esj93e406EsZfO5yru2Ncg9pbEvoUzkIh1pR0nW 8ZIWESUpiYcWCy0HJ/rSnJGM4x2aYNGTcwKl33gZuNFlr5WSFN61VpmwOf4yLXRsXEyKYsOtGMhH Y8xlnnbJylpuJl2HWQv2qmNIX5qEKmpUJTLF4piZJU5ZzvOJgfBjIahgx0E2nKaaqlmwXvLFlPb8 5mAKRsx7ji54iOOK+Y4oI43phya1Up7sbhLHmEFNnvNM08isuU2Ami6Y/FTk3/45zoraxohUcR9W +uMTBEaqnXEzo0TRiMSDddR3wLumMO3C0UgKzzTeKyJOGqopTILnJ2OzClCM/8hSNIYzjyJqyPfw iE1VMlWjGO0diOKoNOqA8Vh+pBWGcFIaBIoHQ1rRjlE5OMU2rbRujaOJIMmaQbOy6av5QmtbLQhV PKFPakqk61679Liw+CiifBWsseY6WMOWKa6HVexiGdtYxz4WspGV7GQpW1m68s+ymW1RlDTb2SF1 tUMZ8mxbE1sbvSLrtGx762hD2JrUekiaf80kawcJQyU1j7aO+iFaVpvKm+6PaW08C3vYytvX5hZQ TcxOx0Bq2/vM5LhMoVd0mTJbjHRVJ8jl0xb36UXgIgm3aQmvWVwLnwtp95OXjGP2/qbMr82lbXds EHZiK97jQghuLrFJfeWF3v84UdQuhxwlRV4qYJzKhql4va51mVLY8xTVwLqapeao698uKbcuwetu 17x5YMbsBYUUA9JN+MVUwYg4brNymYXhtFuMotK3GT7w75L5EQi78UUaSyx4GSnf2RW3cSyWUzeh p+HAKXORPXvrTiT8XGQ17mu2eh6E3Amjwq0XflUWcou1l0+LfrOYSpYYQQe6uP5ixbn4KirlqLqh ojqoQtyJrYzgvGUuU7WjQwwohzNqFp6OOahbVSugaeU2XGomd4XGzKHtjCYMd1gl/uznJKXaW5S9 k85baVjyGAKWr0CFf0Fi3lZsFuhG/1e9b9yji9xrMD6vNy1+NY2kLES+mo3/FMoZ6wlbS7sfWzeY hr0+9aos/Z+eJEV9VBObSBVdIQf/ZNgbK/aAwqXsWMvMMcJOYoWjvahpUxvb4EaQgrstWVkH6Nzl lix/bcNudTdW27KJ97vpXW973xvf+db3vvnd731z29+dfXbAB8vtgRN8rzT0M8Ibax7cJZHFwg0M PhFUyC9920MUeq2q1FbhlHqWyFxkLj2z9Mojiry8Ucn2vSxWQ5AjkTgmwvi0tARDPaO5K5y6sUTG cxBkB3av7U3OqlNtVxzh8714JNZ6twdrhMxRj89RsqudzqGu3Lw0nvacjHSCIWS/fMDdtOvA0BU0 SpKdkjE95dIjTelSFjin/xMyFW+zk7HR+WioK/3gzOe59DxTvM98dumMAV9Kj3a3OmHmMN9JSr1b PVJlTLHOO9vXnrGSbW2BdyxvtPlRtSNn7PeEMeShE3giD70kIZ+pvDH7kJDmpzxLOYrZ3TMxwyWF 8bmsp+ENxPm7dD6VKBn9l4G5+qiypfPOweYxZ9MV0bpyJ7GJJUwOdzbaO++6oVE58SO7+8MT3+IX 9fLhh9/KYhY+8X4T/vjLPDXFFe7M2GdMp0n61W6mJl/4eRx20TZaDJ8/mMJPqQqP/MhJxg5Q0jTq /PbsNrrK4XiCVp4JZq7rmVoHKmalvhxkW5oC4PhK9YQp9I6Pe3oM0tJueP/IzvgC7O0Mw+2+zXbA Q1WOp6cyidOgzOhIqjFiMCeGo9TQS+KYjui4qercJQCB6WOCEMe4JgVPD0c0LOlugz6Q4lTGI1tk sPKQ53YoMFUEQ5Z6wjMYjkpyz2pSDgyvJOQM5QHL8FMkrlCATg3N7Q3tDO/ikMWmjw7vEA/zUA/3 kA/R5Pn6EOSAjLwAca/IbeEI0f+arwMRMYEYbcD4pcnajRHvRxAnDhIrUS26Y94mMWf+LJnIywEB ZFv8ReHKohQ5EQ0nIrX4pl/c0Dsm0CkYzFtkMUt6r4sMTOQ4hLuE6InE0Etsxl8c8WeejW9az5Xm Jc4qLGrKxMR80RefiEn/pu0Zu4Q8nIvEDpH7YI4nFjHWaNFIXHFa/sIZwzAab2MascTdSG8+KM8U b4Ub8w8e5U13Do65VsLI8OwtIk3qbjAlhlBdjsOpTAe+qgoJ8dEvoG4fg8PpskkhQ1CmPtBEcm6h TGlirlEdqc8dF4RCukKvJIUjzaIHm+Q3FOIeaWokxS7srm8f3e77hA8lcbHL9OntdOoRDyYBh0nw GnDuaGY1JM+O7JBulun6QmMObwUcYWTERMKgUAOGMC2Q+JFIhKYk7Sn1fov7aEy9PgruALDsno73 CE/zACcFEfDvjC2hiOUBeXDlFCIS30zqcgW0RsMbm69lrm5HVEPn7PJa/zJEGKPSkOBOdKqSJTMK K7kpaJjvJWXyKklym5iPLKfqMSFTLKXKtIyRyjojZQ5qbs7sWGqN+JaxLEKS2hyiM3PMKLKNI+0q mujxRATTm8oOvqLKxYquK2Uz+eIOLMvPKxkTIF1y9sJy8Syxw75P8+Zjdozx5JhnxaLCktIqOUPD JkoGKMciXMYmxCCk/6CtuiTHdbJvwS6PHHnzL2EzH2WTiLTx+AJq/V7MAHdzNxUvxk4QpkzpLT1P oASKcYJsuaDNc9rCM+LD7A7HpG7i4LKQOOCnJiAjk2gMLGQpUzKDaBaMfcywPPnJ72JTBXVTAE2S PWWSK30JQ+FTMQEPAP9BdAAPcL7sTr/KJuskkDywgtC0Ty7UZrw0yXnepahe0EDlb6COUzuZE518 FCZYk0aYsEI3DO0GUz5Jz0jxQgFfzQQHrzDMMxuptDjdEyejlLd0FKKUklZYQ8LgLL/SjCltLnNk KyvO1PXwjlN0VP8E9EvPAzRJAkJoaKjSqUqM9CIrTan40ffQD2ziyx4FL74I0PeWSh+HMmRcLRdL rwl3KkZ8ZaxMzj2qUDs4yzT2yzQ1rede8D2iMD0m9DirQlRdL/pAg1LZY0BhdCg09SPCA0rAk0zO keTuzEqSbS5fkcmoYoBspi8/BFc3xFefI1gxUinyixkV5QzXhFapc1//qs0au1FF9NP24g9BWKcs oBVXhrU8YmRI3wQq/4QNHa1ZqTNbj+Q/mibn1me2wmU65a6kQhNdKyRf5pUoUXFKjnJSdjBa1Udf 69VHyjVffhVfWaQoh8RspORfnbVgE+Vda0Q0iSRXG7Z/yJBGapRiM1ZjN5ZjWeUdOzaGLBZkBSsS R7atWtFkDStaU5ascGlhWfaCSBFmJcoW42Zmx+TmEGy3blJR9Yb9rvRmy/E8PxHBfrZDsIN2NjNp g/bi9nP+ijY+dRHwkmJpmfbCjqw+dZNJm6owRjK0IieuCKNqrRZLahZotBb8fssmBaRZMmYHhZJH D2JsydZKws81q1Rr/5DsMdG2xALWzSqn5dBsIF4Pb+k2SYjpNnu2CDuUb0FPZq4rmp7PnZ5pTw33 cGvnbNtza4vsK2MtKUkKdCVPZtZnV8GzMC2XZMbvboEzn7xPJd4Pncws8p4T2tTDZcNIP1E3T1W3 cx/RZ1apce8iqzZnR72DzrziY3XXZ4VwBWPOy7ZSS7eUM561yX7EEJV3aJDqjnzTa402wxj1qiAV BidSWHFtO4kUe/Enlko2fVMoVjGxfUnoKtIxfuvXfu8Xf/NXf/eXf28IY/sXg9IQgDeIfgfYgA84 LRzU9RB4grSK5xgYguZUOCCYgdbXvCg4j8Z1nwQ2OpbVd03kKeLpEf8FeIAfTTg5OCed9kR4hVS8 kdS2kX93sXVlLmohE1tqgqj0DtReJnlBlmeMkI7apo2SDiH5xu9IMiGpKlyhsGh2Tf8+l3YFood9 +ATF7CDVNu08GD1psgWVVC3aEld3MiihyyLnhWB1tzJycj1HdCpt+PMYV3OpM46gFWqQ5p0EaSm2 ZYlR9//EbzIjs3A1949LJHhrpyLUpz2M5wJTEzGAIicANIZF50T/eGczuFHf2Pw4V2xm8MdmpSpy l3niwgsrZ4o79ocnOThrOGyOGEXns/1iF/5mF3lTY1sbQ1ciNHZf43/b95RTGZCJM44faY3hWHHJ KJRpZjKQR/aKRiv/SpmKf3dJhxN6DdJ5uxiaszR/UkN5vlBwr65Oy1SQzthyZ1MceaOVnzAgQQ+d y1mJiw0yLnApRkU1RFZyKFVwOVBWMThaIBlyMPU7T9NInFmf/SS2NPFUtHWgeWcT61WME9qhHxqi I1qiJ5qiK9qiLxqjMxpgBFqjf+UUOzp+RqhTOBqk60RkTSufS/pRRE02vgVZVbpSFFiWZxGF9bdA eMhs0yTrhmtlYRpLA7ma0QR+oEj/UhqjuxfjalpChvphQfIzkDOhUXCPgrg+1cifhjjqTmKPkwg/ dlCvTnpl0BeBB7l7FLPtfg+LrfQch5qnJ4LJSLp+ydqPU1hKS7SV/w+Erf3sOcoLqqM6JgMQ+ND2 Q4mnkK+ohpHFE8OtpMnZmBL3roOv0qhag1fUWn9URJTIKqwNpAEMlYbZ9MrSlV9ZtPPTeQR41zx5 VdGK43raojl7rimTdx+bOC3NTd3IaZq561azuMTZr+mTUFkQJiEbm1/TWmwHvCRHR8FUrCG4Zn9H abS6e6UUII9OnMQXZj46v0B1fS7Qp3zau78bvMNbvMebvMvbvM8brpYbvS3FCtf7akjYvQFGA+M7 Z/olYumbXBgmQnYOv++KQUS6v/Xko5uvqQMcT7aaOgvcwO9q5mQaf2XYe0vFTV6YNuIFrhERwjmG A90wy162YTMcYP+MqK/jBj9GHGbNZQj70U9T3McGMupUfI0QXBKlC5RVylfgR71N+fNqU4tVMCuR T223kvFCUTwSjfhQLB6Hkn1T1mNk28Ni+2cpuSz5LkM8ESlz7cvc9a+6uroSmcV1nJAN8HRJx+gA rHPtOoksUxW1A8Tqg+WGp84m+5nV7zdp8/eMb3s6tJ9+c7WcD6qtvPFQB1mr5lvQRjnqjGl72Y03 t3IdabDtFnZHO/4ODtAjr0WbLT+ICjUkj5/ZzGoVfXG3OHg9mwFHtKVNxVdOVTvxa+jIg02Ropl8 EvvezMP10LVJVCUVA/HAEsiHO0G4VFSzsBQLvTLcdmUBNzRyHMP/i64mU9yqyLyq66hQjRBo9SvZ HDHWHc+WMGZ8ycIO33nBnei2eNUpwv1yG51tn9Vbr8uZotjci1vGoVBeG1o5XYldlfrdF+QoF1ox Hjffz+RgSeQ10u3fxUTBCx7hE17hF57h/c3BG95RkBziHcXfJ148YsLE+eVKyKPW4zvZ9rtK+Ft1 DO7C+/c1WHrcomlKHASzlvxeJvaLIpxoo3fDgnpoh2aiUrJ4YqKUYaNBD0jQZINhCH7R5I21JaQZ JVxqc97RLtmD4pJtqdDl5NFtiu0PYSSwiF6IxFHpkb5Wz8SInUTZIRB5G6dXI8P5jl51GuPT/gjo znjs10iOYJtD//UxUZu9zNNZ8bA6uvPxMF4ca8EX+YQuqczZ7okjCPN8tk1kkTlkALizxIqkNCKK Cpf8I91+MyubZuC3aAfVyZlQT1lZi5M0zBKzzM+auMEMH8c8SXHzrHu81wOMMAr75UONQKWEBuVJ 6lnilrEQNIjF5d0jUzxxLQ1iKaGMA3vyj76c7v6S7qlyJp/fiyWZjXOzPZv0+qF/8WP70S+51Nv4 2rQdhm3QzXaEuqropyBnwoiHauOIynTt2Nhmmx1V/kt7dvSynG7Jw9cTMMP8bgECgIKBAgcSNIjQ YEEFCxM6bEgQwMKJCisiLAgRYsKGHA9edPjRo0CMHi2CzFhS5P/GlCBDmlQosSRFli1rJjRAAIFN hAZ0GjQg0efNmAMRGNhZEwHKiESBalyZ0CjThggIGKwqMWvOohKPDuzJkyjXrEK/lnVa04Baq0jb 1iTJ0OTMliMrwpWZNatNjnrfwrw7d65KlycJY8wrtvBBindp/s3LsnHcqTuXMiQKWK5bh2WrlkXK FqHnlkAVIPi8eSABADrZLlwttnRLnRrBKoDdUO1XAF5nlw2NELhT3qrZAjd4HDnZ1MxlTn5+eC/0 yR0d+1Ws2HJ05yEtY39OPTVju5GvP4Tq/eX57ug1X1aoEyfB+Ma/Bm/+1DZIqzlRu1WqlWqiyYfc VTy1tl5RBHr/VBV++920lQJO0fagQ6sRoF9zm42XUl3ScVgdeCJCleB63nnInUXpkQieZE9pBiKL MrpYXok20jgdeRomdOFpOwn1VHI/GYVYkRIRgCFnvPUlIY9CgYUVcbo1GdxxEd7mGob+ReUja1El J5xXXoqW3II7MhdiiyPe+FKIL7pnXXgwfeQmiRO9qSaceObZpnoJuhlYY3ve2WFmOp45lZFa6Udc cL2RaZWiin42oVH+VcUWpqYVKSSAQmlq2mo+ScqpbY0i1xuRj160apI8FmWVVIhWZpiMdNlJ2GV7 tsgkdpClJxivKH6XZq90YTZjYm8pq6uw0Bl7LIq/phgnc1Fm/5XhScQRKSROXl1rJJKrYrnlT656 q5pOWAmJ5JXoSojkp0iGm21EPqH1lbhUlhXUbhptBSBs5c6KJsEGH3zrrLsizLCGLy7ccK4R7zQc WQNPjHHGyiHmH1AYioXbcjz1Fi8AQmqcMMoqS+egnyu/XKfLL69psI9t4dafyVWNO3PPOwKILWkm A5UqYqua6XNlECd9MLMbQsu0xpBdBDXMSzd38U22XVh11F6ndeTAPEsYNpljf4122mqvzbbXWdt0 lFJvt033jmrNXXfeeu/NN9tr9Q144IIPTnjhhu+02tmHL854444/Dnnkkk9OeeWWX4555ppvznnn nn8Oeuiij/9Oeummn4566qqvznrrrr8Oe+yyz0577bbfjnvuuu/O+8FT9g588MKTpniVF6Y7fPLK 685v8faFOirAKOOdGvXL0z41wtkzfbXD1UYM3Kk/Jq4cghqfPCv61+eepsISz9x9yz5ztBpS7343 cfxt6b9+6xrxbysAuk9q3LsKa9CXOPXRTHv56x/wFtY1/EXLLdkbibH0MqiY8GVXLkqMBQX4nPs5 pCe4YVnGQJgyB+qOgzKT4J+QUh0PygVPhKJWdlxSQ4LtCUpHOYrJTGgTm4FmTAtEFApVSLpB2SqF +KNhe9jzvhqtCIoikowRg/jDo+QEKANbmPPGEqymIXF3G0T/VhRLhJgawdCMKlqiFN04mCp+Tzwj 3Bim2nWxggSsM1+kDIPKNsA9jnF2D1MjrW54RqbEcZELXMoU25goNmqIX1UC0pH66JG4Iako1ith JkOlQJB8piCaDOUgTVdIOe4vYY98IxXj5Eg4yolmGaHPfOAlICrdUkIZMoopN9ITW6bLer5USDBx yRBheolAbFkVb3yEtFO67n/qWRo1DckmVbYylok0FCQN1hVX3eQzm9xLV/pFNlIdSZzIY8qEwHlO IkoTdu0L4yHVqMQ5qfJZJhSLPV8ZGIR5ElJDEZ+F8mJJdYoMlMFB6MFCZr15jm57f5HlY7QFQQwa UqPmHFYE/xnZqyOOhVLs/EnxBHmVkHGKnSLclM4QhlKJXk+kdKOpTG/qQJt6rX1920q9cArUoCrN aXuDDWwaJreMJZVhSxWqU4GnFLUYVIdEhadOP/rUrAKVixnjKsO8qtWwinWsZC2rWc+K1rSqda1s batb3wrXuMq1dL+bq13vKkp04nWvePUUX/9617oCdrBs9cxoCIvYtCLml6ZJrGPBycSqskynTOMi WEHz2MyeCYKbHV1oKKtZvHJ2R6AFnKyKGNrUuvFO/pTsNxVpF6y6TZcg+V1pVRvXVHaoha8NVCKj dpofFqW2vbktbt+q2xzxdpbcXG7SnGIbWS3Itsetrgv51P/KODZ3jj1r0Dhd2szijuVK1g1tcllL URNVE5v/+ZnQ9FqgfA3JIqUsr2rP69wnahM9yhRmM+GDzGXWh7Y/CZqN4kuQY0bTvo7FL3v1u13U qiyq5ZKnah6FLfgy+LEOtiEiU5TdlZFXW9/C18Y0vOEGF2m3VBttRmT42+k5T6UajmmKbyw6U1as Kzju8eoilCQhhqUrEfWxkSt3riOheDNNPbKTJXfY4iiFsRh9spUhJ9ivWvjKXO6yl78M5jCLecxk LrOZ9YbJM6vZcCNes5sbN5o0v3nOdMPJadpM5zzzrUFNvome/zyzk8ILNdCUM6APzZyS7odnw6Ey oh/tmyr/gYZnQHM0pFX3FONm7mz6KSfcthS3Il8adczS9OV++scvmnrUE91n6pKE53YWps/mIY2o WV26YTmLTqWu1UUf7DOVbkl9AqHynmKNa3qyWLnvSWHMQJq2nUW11g/pz4awmGzcBXSf+fRQsHCE ZlnV5jF9xJNSsn27bWvnkN6usof9NmX1eFdXrkVwXtFtuxjik1Ycgu22J3mmrL1TPbZtDSnhpsBV 4xtyKAG3Evu97mbfkkACziWG+4vM/9aEfBZi0WtyySWOU3vhr2v4vj90qBNJeGXvVNyjPM0QLYpp aDhZMeJITsiH/FvCKtfnYtIm7LZg5TdMorFDg2honIMu/9MtDuCMNsLR/E5viy+1X7yiwuOUFgnV orm10oOqcLh9nc5hHzuk6232tKt97Wxvu9vfDve4y33udK+73e+O97zrfe9877vf/w74wAt+8Gvz OuFz7atq/VOHgfuluw6PSnb3E2Nl76z9mmJ4yDuu25NvIOAWNu3bZF7zjDM5I1tcF4rKVpEb1HlH Vn9Fodub9EunohVx+OzRSlwwvn3olqVOGFG9ZfS0V9u/bw8naANxlsqnKdD8nBKPdawkz+fJWIrP 8GUj34bgjqwrX6uwXs27IQO9iph+DSt/Yf9xFsSh4tdL749GGEcCJHpiqOuj8pulJOX/nWzWX3re tH3Mxv98q/RKBegiGMdMz2N+4cMq9dND13QbA+KA9wGApWd77/d93zN/G2gwVwJzJRQrrRIarSIU MMd1F/h5GVhE35Z85uFPffJuP1NOQ9dQP8Qfn7JkoGKDDKWCi2N6BQh1utZ6FKRBTTeEMeYW74IT I+ZXIodHtXUuVwcvSfeDV4iFWaiFW8iFXeiFXwiGYSiGY0iGZWiGZ4iGaaiGa8iGbeiGbwiHcSiH c0iHdWiHd4iHeaiHe8iHfeiHfwiIgSiIg0iIhWiIh4iIiaiIOxEAjdiIDhEACRGJNTGJIOGIj0iJ mbiItlOJA9GJCvCJnyiJmuiJGiKKm/g6k+iIpWgQoVj/iqoYiarYiqxIi6vIirEIi6HYibYIiqAI i6ioObE4i7s4ir54i7J4iwiBjL3IjJi4jMnIjM34i9EIjJUjjMqIjdlYidtYi554ibMIjdxIjeMo juI4jtUoOdfYi7boitFYjuB4iu/ojrRIj/Noj+eIjpCTi/TYjua4jM8Ijs3YjeRYjAI5kPlIOe2Y jfcojwZZkMjYkOEIjwF5igj5OJdYkbxIjd/ojc7YErz4j97ojruIiQxpkSeJkimpkivJki3pki8J kzEpkzNJkzVpkwmpjaQIiTupNxV5k2qjjgDpFqLok2lTlD/5NUFZj8K4jdeIix0JlaO4j61Ykr7I jSU5lJUieZRIGTVKSY4QKZLGaJDmGJYNGZLGeJUTKZZcyTbyqJBn6ZakGJEDmZb2SJZsaZQcCZBm SZdUSZR+iZWByY7D2JEeWY94mZRq+ZZ9CY0LeZCWeJh1+ZeHiZhM44p7qZhw+ZgmaZdqeZBnWZmJ iY2YWYtOCY9ZGZBWqYxVCZKOqZEcGZr6GJsyBZuzaZu3iZttERAAOw== ------=_NextPart_000_42c7_7d4c_38e0 Content-Type: image/gif; name="Funny5.gif" Content-Disposition: attachment; filename="Funny5.gif" Content-Transfer-Encoding: base64 R0lGODlhvAGvAMQAAP//////AMzMzISEhISEABCE1ghrvQhjvQhStYoyDABCpQAzmQAhlAAQjAAA hAAAAP4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH/C05F VFNDQVBFMi4wAwEAAAAh+QQEFAD/ACwAAAAAvAGvAAAF/6AgjmRpnmiqrmzrvnAsz3Rt33iu73yP PgKAcEgsGo/IpHLJbDqf0Kh0Sq1ar9isdsvtGgdAgG9MLpvP6LR6zW67wEGBY06v2+/4vH7P79Mb gIGCg4EMhoeIiYqLjI2LC5CRkpOUlZaXlwqam5ydnp+goZ8IpKWmp6ipqqusra6qB7Gys7SyBre4 ubq7vL2+v7cFwsPExcUCcGIOhMzNzs/Q0dLTzY7W19iKmNvc3Zai4OHinq/l5uforbXrtMDu7/C8 xvPzyGFy1Pn6+/zS2f8AH3kbSPDbuIMIyaVbyLBhKnYQD8SbSNGXsCcPhNmLs6yfx48goQUcGbCg yZMJU/8mdMiyJbqI7CrKnHmxBRiNyfAJGrJTSCAiP4OGHLqPpFFsJ5MOVMlUnMunUGHBrDWz6sSa LG4W2Khsp1AAX8MCAku07LSjaBspXbutqdtQUePGnUrVql1gWAU8ADJirwitXHWOFduALNnCgxOb XewsreNEbCNXeku5k9zLLum2u8tZXgExffn6/Ztxa86OioUiXr368GHGsAU9ns1Asu1IlXMrwMy7 oeZZnYPnyiti72jSOO+hZq3aMOHXsWPTfnz7tu7KvbO//B1LuHfixfmOAHza6yDXip2njg57uuPq tq9T1k7/Fffu3oODNy7eXnKO5rX2XHrssedeWvBJJt//W/U1uMp9EuXXGXGjHUeecgGqJ2Bi6BUo 3YFHJRjZgm45aOIpEEo44WehkTDahQD29BpPY9FYo0+sdeghPyCGKOJaJDZ14pAIpKjiXeChAGNX +kB33o7t9UjSj0AGqRKRJxp5pFVJnrCkYNQ4qSOUZUk5JZVJWXkllg5quSVNnw0g55x00llaYMt9 ZCOZZZpZEpooqbkSmw26+WZFwvCn6KJ3lsfno/n4+SegBQk6KKH0GXroVfR0+p8yfoQq6qik2lGU pP9QapKlCGFan6abwuOpp4G5YeutuOaq66689ppDTr4GK+ywxBZr7LHj3YPsssw26+yz0JYAbLTU Vmvt/7XY7jBtttx26+231G4L7rjklmtuG+Keq+667Lb7QrruxivvvOXCS++9+ObrrL369uvvv7ny C/DABBfcg8AGJ6zwwlkpy/DDEEdMAsISV2wxvhRf3K6iGj+cccfmMnocyAR/TDK4Iht3cskOr7yx XyK7/K/JMmc7MqM160tzztf2F57KPN+7c9DU+qwXf0TTO3TSzormItJMx7t01MsavSjV7k79LtZt WP0z1+xqbZNeYK/hs2gjl02u2CsMIATZap9x9tFpx/0t2+PV6fYQcNs9htFf86D3nH6j23INew+R ON+AF45D3XXfsHgRAziuBt4DBCCA5gFMzrjlPuAsuP8YnG9ueuegn8G226d7TkTfqfMQuQ2sl277 5pXHPobYtePOhF56625D44iTfvrxnA9Op/Az8A5A8k7oVQTxzK9AvQxu3659EEpcX720h8dQu+tJ 6FU6Ad5/X8LszRu//fvHo6++TeHDkD35Spi/ufzzt+D0r89DngDhFwD+9S8FzsPfEvRnwAP+4H84 6B0BB2i6BjoQfHFoXu5u8IACpk99N5PcBm/gwQsqqX5Z0QIQHmBBE0bug15SYeVaaMJaiW+CONwI DfvHPtjZL4cTBEMJa4hB0IiPgkDEHRB2+L0e9qV5SIyi7eDARAcuLXNSzGIAHjCAKurOievDXhIJ yEX/L/bvilrMYhlhWLjGUY+NyEjjBNdIxCLSoHJjHCAYzGg5N74Re3JE4h7hKLypYTGPtxskD1Ow wh80D5ECVGQdk5VBQELydiwkZNmIB0EXQfGSx8vkJClpxBsG8n2iHKV45vbIUw4wlaPU2iFdWTow aDJ1/Vkl7UBZSzDOT5a0RJ4tR3m0p91yPMGcoi/VJ0temq6YxDwmAp2pOWjGEoVjo6Y1VXmwZIZS mpbjnTc5x8dFCm6c+wOn43inzXIKT2VA08EsQenO6vGOAPjMpz73yU9+qlNtMdNWPwdK0Hz+029s S5lCA0pEhupgoRCFGjHxRsyKyouiFs3oujCq0Y6u/w2bHg2p0EAq0pJmjaQmTem5OKrSljaLpS6N qbFgKtOaBoumNs2prnCq0566gac+DWoagCrUopKBqEZNqrZQqtSm4gqpTo0q9pgq1aqiAapWzSoC qarVri61kl4NqxmwKtaukrWsWT0rWquq1rVGta1ubSpc45rUudK1qHa9a1Dzqtee8vVpJoDc2eLJ glUetK8J+2txFvtE2EEwlzE4LGITy1TCxlOXgSPbZT3pWMYyFrKBBRrMljlZjVEMs6htLGq9plrO gha0nO1bJ0vLs9O29rO3hRvgXuva3jY2tqmlLdFsG0bcfhZqu/WtcT3LseLK1rPCzRlxgftEzMb2 uv+dzO4JWPtcH0bXZdP9rS6t+1vsQle7gU0vc6H7XfCiNLjPte5sz0vfzqqXusttr3vB6sjlwra7 bqwvb++LX93qt2YZs2zaBkve9VntwQ7+r0Tne+COKZYNkq3wwC4st/JqGMFc7RlpP1wxDpO4oiY+ 8TX5q2K3prjFRHwxjE0o4xlbMcQ2liuOc1zXHfMYrz7+8V6DLGS/ErnIOa0xkgt55CXLVMlOTl3G lEflKlv5yljOspa3zOUue/nLYA6zmMdM5jJTuZQRjqia18zmlL2LqSOMcrvQ7CIv2NkIpJ2yHOwg gjv0mc97rsOfBR1oOgza0HIuA537suhjDfMNcC7/9BwOPWlJO4DSl7Y0pjedaDI0WnrQejT9WOwl TZvaz6cGNKpR3WkffPoBny6WqBtGahNUbtWqzjWhcb1rQLe6B6+OdRpGPOu2RZrXiEZ2pZWdaVb/ egfB3hUbi60CPTOb09dONaGfDW1GCjs0uTzOCsNt2P82DIbW1nWy1b1sdjfb19zOQbQLm1u0+be7 3q12no/tbmz3W9uIjre8ve0/8Yo2t+tlr7HRze9eO3zdD293xDMtcBzM23r3fSy4fyZu++271tIC uMQhTvKRm5ziFbfBxVXAXY2HMblvZjjIJ5Zycq2ckRlPuCdhDmmZf5t7dw660IdO9KIb/ehIPwLB 3el9bwBXV7we93nNCwbrgjcdvo3UOf2kPvWBVd1/Nzs4c8Udwpi/eeZdn9fX9/Xxn6d9Y273FbW3 iva3u2vtL2273f2Fd2bN/YR13/u6YG3mwltZ74LPV5sXz3g2nz3uiSdX4ydPedGNGvKRXzHmM19H KHP+ZJ7/PMhCL3rTNrn03yM96kt8+tUzOfCup3HrYy/l2dM+nLa/feFUr3uF8b73Bvs98FkG++Hb M/fGB5vwk+8vOBj++dCPvvSnT/3qW//62M9+4SvP/e57//vgD7/4x0/+8pv//OgnfwgAACH5BAUU ABAALDEALgAQABIAAAVJICRCwzCeqDgApZmeKyC3byzfbAnj/DzaPR8piBs8VMSbEZlkHYHBpQDa W1KrD1PTOeK1vkeRFwcJlx8PpUxkRqVX7NcITU+FAAAh+QQEFAD/ACwxACIAQgAeAAAFlaAgjmRp nmiaDoPqvnBMDgDbynj+0kBv68Agr0essYJI2LBYvCWfpiWz94BaR9LmoHq9Zm3UrpcI7gm44qeN xTynreyi6IF+I2nDed0u9AH0fFAPfnR7gUGFdIeLjI1YTo5PYZFPAQIEhpQ5AZiaSJadnkAPnJmi MA+hpzhVqqsxraavKA8DrrMutbe4K6myvDO+wC8hACH5BAQUAP8ALGEAGwA5ABYAAAVgoCCOZGme aEoOg+q+cDoAbGzf6AzQbYv/st5uyAMaSywhsXds6pLQmcDXBOqIRMGjerxiAVqu0YsNi63fnfn8 I6u37HZZC4/jrqJH3X7P6/lHenuAhIWGh4iJiouMjS8hACH5BAQUAP8ALIoAGwBXACYAAAXcoCCO ZGmeaKqubOu+cCzPdG3feK7v+vDwwN0A8Asaa4Nh8ch8DYfEpnQFhS5bj2x2eqsColit+Mp1fr9W 1nhdjkHRX/JJK1hv2633Wam+2vEselpxaiZjgCpvg2dyhoZiiCk+WWeVYChFfpCRc5aeRI11j5uc JXqfhHOOdXelpqgAAkkDKWSZra4kp7FJD7S1JT+kuSN6spMJK6F0xKYivZl9j80nyCS4tWzUL6HZ 2zDYyt8xwyrd49nhIofoMnbY5+018fI09PXu+Pr7/P2A9/68BbQnamC+giNCAAAh+QQEFAD/ACy7 AB8AMgApAAAFqKAgjmRpnmiqrmzrvnAsz3T83Het43yu273eD4YTBH1DFtIYTLYeJqFzBS1Jp6iq cXTFRqNdL0nLFRXFJ/KWqUabrey2W852p9tLu7WpV9L7cIBPf4JmZ4VZa4hfTIuMh46KkItkeYiV hHqVmipVUANzhJ4AAKBiUHQ8pKVonnerpKZeWmoPsLCyU5tvt6u5TktFUL2spyk+t7/AnVW+c8w+ yjXClncPIQAh+QQEFAD/ACzgADUADQATAAAFOeAjjGRJPqKpoqlasquJxm97ym4rDvn4AACeDAUM DotAIQmJVAqYReEMakzNns3hKLqCCZxdm2sUAgAh+QQEFAD/ACzgADUADQATAAAFO6AgjuT4lKj4 nCm5sij8prCw0m5tui17DjgbAADMrYbE0hGZNDGZxdMTCTxJp0UV65nViqixmaAbfoQAACH5BAQU AP8ALOAANQANABMAAAU54COMZEk+oqmiqVqyq4nGb3vKbisO+fgAAJ4MBQwOi0AhCYlUCphF4Qxq TM2ezeEouoIJnF2baxQCACH5BAQUAP8ALOAANQANABMAAAU7oCCO5PiUqPicKbmyKPymsLDSbm26 LXsOOBsAAMythsTSEZk0MZnF0xMJPEmnRRXrmdWKqLGZoBt+hAAAIfkEBBQA/wAs4AA1AA0AEwAA BTngI4xkST6iqaKpWrKricZve8puKw75+AAAngwFDA6LQCEJiVQKmEXhDGpMzZ7N4Si6ggmcXZtr FAIAIfkEBRQAEAAs0wAjADAAJAAABd2gIApPWUJoqq5s66ai+7x03Qr0bO80aeIrHW+o8o2AKiFx KHocmyblcjWQQppP6GmqGngB1ibLt+V+AegwKUu27s7ouBR7hJGI3kF8n17RR3ZuL3p7CQl7c2tZ V2U8hGiGh3JFYn4+S4+Rkn12fyONjnGam0pPLII2hKOkNZdcEJmHhpM9qG98kYivNVuPfIi2STaN vr9oEMFBL6CwxmgCeUxtUajFALBVyWMxjrs9SN7e3OHi5OJsbOYuderS7O026fC86PPL6OD2lPj8 +ef99eABlCdw4Dt9gHaFAAAh+QQFFAAQACzOACMARgAeAAAF7yAkjuJjmgKprmzrvnDZpnFt3+Tz 0njvqyeBacX7GW8ogVKnKh6fr4dyKjxJoSMlFkhdWp2+7nYkFRa/x652DClTrUm1fC5nu6fM9p3O 71MHP3t5cX6FdIB5SF06X4aOagMAAG09ZStBj34Dm5yRkpOJNYRemZqfkp6nlJVERnMDAQKxEKmn oEcoaZAAsrK1treBYDi7vQG/wLyhxKWHELHHwAnTCSRCus2QEL7S1AAJp9c4edna0bbT3+m24qLL IuWAv9T06+Hvl/g/w0b6emwA4b0bElDGGCcECyok42/hloYOsUCM+GQiRVwXHYYAADs= ------=_NextPart_000_42c7_7d4c_38e0-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 3 13:23:46 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07568 for ; Thu, 3 Jan 2002 13:23:45 -0500 (EST) Received: (qmail 12891 invoked by uid 605); 3 Jan 2002 18:23:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12755 invoked from network); 3 Jan 2002 18:23:24 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 3 Jan 2002 18:23:24 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27916; Thu, 3 Jan 2002 10:23:16 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02552; Thu, 3 Jan 2002 13:23:14 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g03INEXt016683; Thu, 3 Jan 2002 13:23:14 -0500 (EST) Message-Id: <200201031823.g03INEXt016683@thunk.east.sun.com> From: Bill Sommerfeld To: jml@ssh.com cc: ietf-ssh@netbsd.org Subject: Re: Comment on drafts in last call In-Reply-To: Your message of "Tue, 18 Dec 2001 17:49:10 +0200." Reply-to: sommerfeld@east.sun.com Date: Thu, 03 Jan 2002 13:23:14 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Markus, My apology for not responding sooner, but my day job and the holidays intervened. This message is a formal ruling by the working group chair. The working group has rough consensus that the documents and protocol should continue to be named "SSH". The proposal you made was made once before; at the time, the working group soundly rejected the proposed rename. It is therefore not appropriate to re-open the issue of the protocol name at this time. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 7 11:43:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19940 for ; Mon, 7 Jan 2002 11:43:31 -0500 (EST) Received: (qmail 5038 invoked by uid 605); 7 Jan 2002 16:43:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4513 invoked from network); 7 Jan 2002 16:42:12 -0000 Received: from sentry.gw.tislabs.com (192.94.214.100) by mail.netbsd.org with SMTP; 7 Jan 2002 16:42:12 -0000 Received: by sentry.gw.tislabs.com; id LAA18106; Mon, 7 Jan 2002 11:47:10 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018089; Mon, 7 Jan 02 11:46:16 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g07Gexl29883 for ietf-ssh@netbsd.org; Mon, 7 Jan 2002 11:40:59 -0500 (EST) Date: Mon, 7 Jan 2002 11:40:59 -0500 (EST) Message-Id: <200201071640.g07Gexl29883@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-ssh@netbsd.org Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching Sender: ietf-ssh-owner@netbsd.org Precedence: list R E G I S T E R N O W ! ! EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002 FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml. 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) hosted by THE INTERNET SOCIETY February 6 - 8, 2002 Catamaran Resort Hotel, San Diego, California NDSS is the premier event for security experts around the world. Come to the 9th Annual NDSS and share in the latest concepts on the Internet security front. Southern California's Catamaran Resort Hotel offers spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny getaway with opportunities to confer with your security counterparts from across the globe. For more information and on line registration go to the NDSS'02 web site: http://www.isoc.org/ndss02. Questions about registration? Contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org. Interested in sponsoring a give-away or meal? Contact Martin Kupres at +1 41 22 807 1444 or send e-mail to sponsorndss@isoc.org. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 7 15:33:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27274 for ; Mon, 7 Jan 2002 15:33:15 -0500 (EST) Received: (qmail 23877 invoked by uid 605); 7 Jan 2002 20:33:13 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23870 invoked from network); 7 Jan 2002 20:33:12 -0000 Received: from snoopy.oit.edu (140.211.135.12) by mail.netbsd.org with SMTP; 7 Jan 2002 20:33:12 -0000 Received: from cvc.net (purvine-140-222.oit.edu [140.211.140.222]) by snoopy.oit.edu (8.12.1/8.12.1/OIT-1.0) with ESMTP id g07KXAF9002742 for ; Mon, 7 Jan 2002 12:33:11 -0800 Message-ID: <3C3A0607.317DC1D8@cvc.net> Date: Mon, 07 Jan 2002 12:33:11 -0800 From: Dennis Gearon X-Mailer: Mozilla 4.79 [en] (Win95; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: ssh1 vs ssh2 in openssh(portable) Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit The ssh manual at: http://www.openssh.com/manual.html says ssh2 is used, but the man page for sftp: http://www.openbsd.org/cgi-bin/man.cgi?query=sftp says ssh1 is used. What is the reality? Also, has anyone found a secure way to get the certificate to/from the server, ANY arbitrary server? I've noticed that it is now possible to get a class 1 secure mail certificate from the ssl certificate people for ONLY 8.95 a month! Maybe have a daemon that would accept new certificates over a secure EMAIL channel might be useful? Please cc me directly as well as the email list. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 9 02:56:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00880 for ; Wed, 9 Jan 2002 02:56:03 -0500 (EST) Received: (qmail 9116 invoked by uid 605); 9 Jan 2002 07:56:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9108 invoked from network); 9 Jan 2002 07:56:00 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by mail.netbsd.org with SMTP; 9 Jan 2002 07:56:00 -0000 Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g097u0F28751 for ; Tue, 8 Jan 2002 23:56:00 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-110.cisco.com [171.71.137.110]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ADG32392; Tue, 8 Jan 2002 23:45:41 -0800 (PST) Message-ID: <3C3BF84A.FB4E7AEE@cisco.com> Date: Tue, 08 Jan 2002 23:59:06 -0800 From: Pankaj Bhagra X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: Keepalive message per channel in SSHv2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Hi There, I am not sure how to handle a keepalive message received on the client side after the session is successfully established. Scenario: Inhouse implementation of sshv2 client <----> SSH Secure Shell 2.3.0 Server After the connection is established successfully between the inhouse sshv2 client and SSH 2.3.0 server, the ssh client receive the following message from the server side. 62 00 00 00 00 00 00 00-15 6b 65 65 70 61 6c 69 b........keepali 76 65 40 6f 70 65 6e 73-73 68 2e 63 6f 6d 01 ve@openssh.com. This is a SSH_MSG_CHANNEL_REQUEST (0x62) message for channel id 0 (0x 00000000), with a string len (0x15) "keepalive@openssh.com" and have a want reply flag = TRUE. I have couple of questions related to this message: 1. Do we support per channel keepalive messages in sshv2 protocol ? I couldn't find this specified in ietf drafts. any pointers ?? 2. How to handle this request ? 3. To me this message is not from the SO_KEEPALIVE, if the above said is true I couldn't find the generation of the message in the 2.3 code base, could anyone xplain what is happening here. Is it mandated/suggested by the protocol to support 2 kinds of keepalive, one at TCP level and another at per channel ?? comments ?? later, pankaj From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 9 04:07:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01498 for ; Wed, 9 Jan 2002 04:07:57 -0500 (EST) Received: (qmail 14032 invoked by uid 605); 9 Jan 2002 09:07:56 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14025 invoked from network); 9 Jan 2002 09:07:54 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 9 Jan 2002 09:07:54 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id KAA12975; Wed, 9 Jan 2002 10:07:45 +0100 (MET) Date: Wed, 9 Jan 2002 10:07:45 +0100 From: Markus Friedl To: Pankaj Bhagra Cc: ietf-ssh@netbsd.org Subject: Re: Keepalive message per channel in SSHv2 Message-ID: <20020109090745.GB12529@faui02> References: <3C3BF84A.FB4E7AEE@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C3BF84A.FB4E7AEE@cisco.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 08, 2002 at 11:59:06PM -0800, Pankaj Bhagra wrote: > Hi There, > > I am not sure how to handle a keepalive message received on the client > side after the session is successfully established. > > Scenario: > > Inhouse implementation of sshv2 client <----> SSH Secure Shell 2.3.0 > Server > > After the connection is established successfully between the inhouse > sshv2 client and SSH 2.3.0 server, the ssh client receive the following > message from the server side. > > 62 00 00 00 00 00 00 00-15 6b 65 65 70 61 6c 69 b........keepali > 76 65 40 6f 70 65 6e 73-73 68 2e 63 6f 6d 01 ve@openssh.com. > > This is a SSH_MSG_CHANNEL_REQUEST (0x62) message for channel id 0 (0x > 00000000), with a string len (0x15) "keepalive@openssh.com" and have a > want reply flag = TRUE. > > I have couple of questions related to this message: > > 1. Do we support per channel keepalive messages in sshv2 protocol ? I > couldn't find this specified in ietf drafts. any pointers ?? no. > 2. How to handle this request ? send a request failed message back if 'want reply' is true. > 3. To me this message is not from the SO_KEEPALIVE, if the above said is > true I couldn't find the generation of the message in the 2.3 code base, it's an experimental feature in openssh. > could anyone xplain what is happening here. Is it mandated/suggested by > the protocol to support 2 kinds of keepalive, one at TCP level and > another at per channel ?? no. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 9 04:17:37 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01563 for ; Wed, 9 Jan 2002 04:17:36 -0500 (EST) Received: (qmail 15018 invoked by uid 605); 9 Jan 2002 09:17:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15011 invoked from network); 9 Jan 2002 09:17:35 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 9 Jan 2002 09:17:35 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 16OErH-00022b-00; Wed, 09 Jan 2002 09:17:19 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <3C3BF84A.FB4E7AEE@cisco.com> Subject: Re: Keepalive message per channel in SSHv2 Message-Id: Date: Wed, 09 Jan 2002 09:17:19 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Pankaj Bhagra wrote: > This is a SSH_MSG_CHANNEL_REQUEST (0x62) message for channel id 0 (0x > 00000000), with a string len (0x15) "keepalive@openssh.com" and have a > want reply flag = TRUE. [...] > 1. Do we support per channel keepalive messages in sshv2 protocol ? I > couldn't find this specified in ietf drafts. any pointers ?? The idea is that you _don't_ support it. From your client's point of view - and, I believe, even from the OpenSSH client's point of view - this is an unsupported channel request. Hence you send SSH_MSG_CHANNEL_FAILURE, indicating that you were unable to perform whatever function the message was requesting. Even clients that don't understand it should do this. And this is sufficient to reassure the server that the client is still alive - if it sees SSH_MSG_CHANNEL_FAILURE, the client must still be around to have sent it. > 2. How to handle this request ? The same way you would handle any other unsupported channel request with want_reply set to TRUE: you send SSH_MSG_CHANNEL_FAILURE. > Is it mandated/suggested by the protocol to support 2 kinds of > keepalive, one at TCP level and another at per channel ?? It doesn't have to be mandated in the protocol; this is a protocol extension on the part of the OpenSSH people, cleverly designed so that any standards-compliant client should work correctly with it. It's not an unmixed blessing; an SSH session without protocol-level keepalives might survive a very long (hours or days) network outage if no data transfer was attempted in the meantime, but this sort of keepalive might actually _shorten_ the session lifetime in this sort of situation. On the other hand, it would help to remind some types of connection-aware firewall that the connection is still alive. (Given all this I'm not entirely sure why it's sensible to run it at the server end as a matter of sysadmin policy, instead of running it at the client end and allowing individual users to adapt it to their needs. Also I have no idea why it's an SSH_MSG_CHANNEL_REQUEST instead of an SSH_MSG_GLOBAL_REQUEST, since there's nothing actually channel-specific about it and the latter would even work if no channels happened to be open at the time; but *shrug*, that's not my problem :-) 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 Wed Jan 9 11:58:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07236 for ; Wed, 9 Jan 2002 11:58:58 -0500 (EST) Received: (qmail 5466 invoked by uid 605); 9 Jan 2002 16:58:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5300 invoked from network); 9 Jan 2002 16:58:49 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 9 Jan 2002 16:58:49 -0000 Received: from folly.informatik.uni-erlangen.de (root@faui08a.informatik.uni-erlangen.de [131.188.30.224]) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) with ESMTP id RAA28314; Wed, 9 Jan 2002 17:58:45 +0100 (MET) Received: by folly.informatik.uni-erlangen.de (Postfix, from userid 31451) id 9EB9343CF; Wed, 9 Jan 2002 17:58:36 +0100 (CET) Date: Wed, 9 Jan 2002 17:58:36 +0100 From: Markus Friedl To: Dennis Gearon Cc: ietf-ssh@netbsd.org Subject: Re: ssh1 vs ssh2 in openssh(portable) Message-ID: <20020109175835.A7205@folly> References: <3C3A0607.317DC1D8@cvc.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C3A0607.317DC1D8@cvc.net>; from gearond@cvc.net on Mon, Jan 07, 2002 at 12:33:11PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Jan 07, 2002 at 12:33:11PM -0800, Dennis Gearon wrote: > The ssh manual at: http://www.openssh.com/manual.html says ssh2 is used, but the > man page for sftp: http://www.openbsd.org/cgi-bin/man.cgi?query=sftp says ssh1 > is used. What is the reality? this is not an ietf-ssh issue. (however, i suggest to reread the manpage. moreover, you can run sftp over any 8bit clean transport, rsh, ssh v1, ssh v2) -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 10 03:49:37 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11774 for ; Thu, 10 Jan 2002 03:49:36 -0500 (EST) Received: (qmail 4684 invoked by uid 605); 10 Jan 2002 08:49:30 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4677 invoked from network); 10 Jan 2002 08:49:29 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 10 Jan 2002 08:49:29 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA02734; Thu, 10 Jan 2002 09:48:57 +0100 (MET) Date: Thu, 10 Jan 2002 09:48:57 +0100 From: Markus Friedl To: Frank Cusack Cc: openssh-unix-dev@shitei.mindrot.org, ietf-ssh@netbsd.org Subject: Re: keyboard-interactive Message-ID: <20020110084856.GA19126@faui02> References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110001026.B30796@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020110001026.B30796@google.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Jan 10, 2002 at 12:10:26AM -0800, Frank Cusack wrote: > But KEXINIT (or any other non-auth message) /need not/ be handled > "synchronously". as i understand the transport draft, the KEXINIT is handled by a lower layer, and if the client send a KEXINIT message after the USERAUTH_REQUEST message, then the lower layer must finish the key exchange before continuing with the user authentication. > Well, at best it's not clear that it /must be/ handled > synchronously. Before I get to that, let me start with a problem in > draft-ietf-secsh-userauth-13.txt, sec 2.1. As someone else mentioned, > it says > > An authentication request MAY result in a further exchange of > messages. All such messages depend on the authentication method > used, and the client MAY at any time continue with a new > SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST > abandon the previous authentication attempt and continue with the new > one. > > However, this conflicts with the text of sec 2.2, which says > > The client MAY send several authentication requests without waiting > for responses from previous requests. The server MUST acknowledge > any failed requests with a SSH_MSG_USERAUTH_FAILURE message. > However, SSH_MSG_USERAUTH_SUCCESS MUST be sent only once, and once > SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication > requests received after that SHOULD be silently ignored. > > The conflict is that the server must acknowledge failed requests. > Sec 2.1 says the server must ABANDON previous authentications if it > receives another request. So we're off to a bad start. > > Sec. 2.2 goes on, > > Any non-authentication messages sent by the client after the request > that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed > to the service being run on top of this protocol. i don't think this includes KEXINIT, because it's a lower layer. > IMvHO, I would say the best course of action is to make no changes in > the current implementation (other than perhaps handling an abortive (new) > auth request), and instead spend energy getting the draft corrected/clarified. yes, the only thing that needs to be handled is: (1) C->S: USERAUTH_REQUEST(kbdint) (2) S->C: INFO_REQUEST (3) C->S: USERAUTH_REQUEST(pubkey) (4) S->C: USERAUTH_SUCCESS/FAILURE the draft reads: > The server MUST acknowledge > any failed requests with a SSH_MSG_USERAUTH_FAILURE message. I guess this does _not_ mean that after message (3) the server has to send a USERAUTH_FAILURE for message (1), since this message has been handled by (2). However, on receiving (3) the state associated with "kbdint" must be abandonned. > Again, I'd do nothing until the draft is clarified. Especially given the > expectation that current clients don't/won't actually show this behaviour. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 10 05:55:17 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12896 for ; Thu, 10 Jan 2002 05:55:16 -0500 (EST) Received: (qmail 22933 invoked by uid 605); 10 Jan 2002 10:55:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22926 invoked from network); 10 Jan 2002 10:55:14 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 10 Jan 2002 10:55:14 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id CAA02315; Thu, 10 Jan 2002 02:55:04 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id CAA21858; Thu, 10 Jan 2002 02:55:04 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g0AAt4531267; Thu, 10 Jan 2002 02:55:04 -0800 Date: Thu, 10 Jan 2002 02:55:04 -0800 From: Frank Cusack To: Markus Friedl Cc: openssh-unix-dev@shitei.mindrot.org, ietf-ssh@netbsd.org Subject: Re: keyboard-interactive Message-ID: <20020110025504.U30796@google.com> References: <3C3A02AB.2010701@ayrnetworks.com> <20020107174807.A12162@yorktown.isdn.uiuc.edu> <1010464177.24458.6.camel@xenon> <20020108051913.A25407@google.com> <20020109232106.B28750@folly> <20020109214807.A15545@yorktown.isdn.uiuc.edu> <20020110001026.B30796@google.com> <20020110084856.GA19126@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20020110084856.GA19126@faui02>; from markus@openbsd.org on Thu, Jan 10, 2002 at 09:48:57AM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Jan 10, 2002 at 09:48:57AM +0100, Markus Friedl wrote: > On Thu, Jan 10, 2002 at 12:10:26AM -0800, Frank Cusack wrote: > > But KEXINIT (or any other non-auth message) /need not/ be handled > > "synchronously". > > as i understand the transport draft, the KEXINIT > is handled by a lower layer, and if the client > send a KEXINIT message after the USERAUTH_REQUEST message, > then the lower layer must finish the key exchange > before continuing with the user authentication. This should be clarified to read any non-auth message received by the auth layer, then. Natch, if the auth layer doesn't receive the message, it's immaterial. KEXINIT may be been a bad example. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Sat Jan 12 13:26:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22815 for ; Sat, 12 Jan 2002 13:26:26 -0500 (EST) Received: (qmail 18077 invoked by uid 605); 12 Jan 2002 18:26:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 18070 invoked from network); 12 Jan 2002 18:26:22 -0000 Received: from unknown (HELO ns4.trafficnet.net) (211.101.236.180) by mail.netbsd.org with SMTP; 12 Jan 2002 18:26:22 -0000 Received: from sendmail ([211.101.236.29]) by ns4.trafficnet.net (8.11.6/8.11.6) with SMTP id g0CITWr08656 for ; Sun, 13 Jan 2002 02:29:33 +0800 Message-Id: <200201121829.g0CITWr08656@ns4.trafficnet.net> From: Christine Hall To: "ietf-ssh@netbsd.org" Subject: WWW.OPENSSH.COM Date: Sun, 13 Jan 2002 2:28:35 +0800 X-Mailer: CSMTPConnection v2.17 MIME-Version: 1.0 Content-Type: multipart/related; boundary="a5e38450-0c73-40d6-afef-1bdf3b84868a" Content-Transfer-Encoding: quoted-printable Reply-To: Christine Hall Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format --a5e38450-0c73-40d6-afef-1bdf3b84868a Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi

I visited WWW.OPENSSH.COM, = and noticed that you're not listed on some search engines! I think we can = offer you a service which can help you increase traffic and the number of = visitors to your website.

I would like to introduce you to TrafficMagnet.net. We offer a unique = technology that will submit your website to over 300,000 search engines and = directories every month.

You'll be surprised by the low cost, and by how effective this website = promotion method can be.

To find out more about TrafficMagnet and the cost for submitting your = website to over 300,000 search engines and directories, visit www.TrafficMagnet.net.

I would love to hear from you.

Best Regards,

Christine Hall
Sales and Marketing
E-mail: christine@trafficmagnet.net
http://www.TrafficMagnet.net

--a5e38450-0c73-40d6-afef-1bdf3b84868a-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 14 16:11:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19431 for ; Mon, 14 Jan 2002 16:11:22 -0500 (EST) Received: (qmail 25600 invoked by uid 605); 14 Jan 2002 21:11:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25593 invoked from network); 14 Jan 2002 21:11:19 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 14 Jan 2002 21:11:19 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16043; Mon, 14 Jan 2002 13:11:16 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29339; Mon, 14 Jan 2002 16:11:16 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0ELBFXt008277; Mon, 14 Jan 2002 16:11:15 -0500 (EST) Message-Id: <200201142111.g0ELBFXt008277@thunk.east.sun.com> From: Bill Sommerfeld To: minutes@ietf.org Cc: ietf-ssh@netbsd.org Subject: Minutes of IETF52 Secure Shell (secsh) meeting. Reply-to: sommerfeld@east.sun.com Date: Mon, 14 Jan 2002 16:11:15 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [Notes taken by Michael Richardson and Jun-ichiro "itojun" Hagino ] Minutes from Secure Shell (secsh) meeting of IETF 52 in Salt Lake City: - Agenda bashing/WG status - last call, core drafts WG Status Last call started on core drafts. One issue remaining, which is a typo. draft-ietf-secsh-architecture-11 transport-11 userauth-13 connect-14 Core issue - formatting errors in transport draft. - some references have been added. - no need to repeat last-call for this. - more text for @domain extensions. - clarification for advice for setting environment variables. - client to bind to port 0 to let server decide on port #. New issue - multiple outstanding userauth requests. - problem with multiple outstanding userauth requests. - comes from GSSAPI, where successful authentication requires multiple round trips. - if a client has started more than one userauth requests, how does one know which request the response applies to? Joe: if the client sends only first round responses, the ordering is maintained, but if there are multiple rounds, then the ordering can not be determined. Bill: ambiguity when there are multiple rounds required. Bill: can we insist that client send in order as well? Joe: that kills multiple requests. - the server interprets new userauth's as aborts of previous requests. If one asserts the rule that every reply gets only one response, then we can fix this, but this breaks GSSAPI, but GSSAPI can work around it. Eliminating multiple userauth's requests would solve this. Bill: Anyone object to this? Joe: Neils Mueller (absent) may be using this. Discussion about different methods and whether or not different methods of operation are in fact using multiple userauths. Markus: what is the gain in having multiple outstanding requests? Bill: the rational is to cut down the number of round trips. Documenting historic identifiers - historic algorithm use (des-cbc). - other identifiers in deployed implementations? Marked as historic. RFC2026: specs can be historic, and applicability statements can be "Not Recommended"; one document can be both. No comments - issue is resolved this way. Extension drafts - Generic Message Exchange Authentication for SSH (auth-kbdinteract-02.txt) believed to be ready for last call. - GSSAPI Authentication and Key Exchange (gsskeyex-02.txt) concern about errors on the server be returned properly to the client. Clarification about what happens after the last client message has been sent, and it needs an ACK, but there isn't space for one. If the userauth multiple-outsanding-requests issue is not resolved in the core draft, then GSSAPI may have to resolve it. - SECSH Public key File Format (publickeyfile-02.txt) ready for last call? taken to list. - Diffie Hellman Group Exchange (dh-group-exchange-01) ready for last call? Think so. two implementations out there. - Storing SSH Host Keys in DNS (dns-key-format-00.txt) Using DNSSEC extensions to store SSH host keys. Current KEY RR is not sufficient to do what we need to do. APPKEY is a proposed solution. Want to approach this from a different point of view, what do application need in the way of key distribution? Concern was raised about security of DNSSEC server. - File Transfer Protocol (filexfer-02.txt) more work need. - string vs numeric user ids? - how many reinvented wheels? Much Unix centric pieces in the draft. Even under Unix systems, it is used between disparit spheres of control, so that numbers are meaningless. Conclusion get rid of long names. MCR asked for attribute to say whether or not the file/directories are writable. Future directions - an agent forwarding would be nice. Darren has volunteered to write this draft. It was in v1, but was omitted from v2. If there are other vendors who want to have interoperable versions, contact Darren. - review milestones ------- End of Forwarded Message From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 14 22:32:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02867 for ; Mon, 14 Jan 2002 22:32:24 -0500 (EST) Received: (qmail 21411 invoked by uid 605); 15 Jan 2002 03:32:23 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21404 invoked from network); 15 Jan 2002 03:32:22 -0000 Received: from ams-clip-nat-ext1.cisco.com (HELO dfawcus-laptop.cisco.com) (64.103.37.2) by mail.netbsd.org with SMTP; 15 Jan 2002 03:32:22 -0000 Received: (qmail 3157 invoked by uid 500); 15 Jan 2002 03:29:42 -0000 Date: Tue, 15 Jan 2002 03:29:42 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: More draft formatting / grammer problems Message-ID: <20020115032941.A3070@dfawcus-gw-home.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: ietf-ssh-owner@netbsd.org Precedence: list I happened to reread the drafts over the weekend, and a couple of things jumped out at me. In draft-ietf-secsh-connect-14.txt, pg 11, first paragraph: mechanisms. As the user's shell is usually used to execute the subsystem, it is advisable for the subsystem protocol to have a "magic cookie" at the beginning of the protocol transaction to distinguish from arbitrary output from shell initialization scripts the last line has two 'from's, and doesn't parse (or at least not too well). I'd suggest either adding 'it' before the first 'from', or removing the first 'from' and replacing the second 'from' with 'generated by'. In draft-ietf-secsh-transport-11.txt, pg 21, there is an incorrect reference, and formatting error: Message numbers used by services should be in the area reserved for them (see Section Section 10). The transport level will continue to process its own messages. The problem is in the text inside parenthesis 'Section' appears twice. Also the reference is wrong, I'd suggest the text be: '(see Section 6 in [SSH-ARCH])'. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 14 22:33:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA02900 for ; Mon, 14 Jan 2002 22:33:11 -0500 (EST) Received: (qmail 21924 invoked by uid 605); 15 Jan 2002 03:33:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21911 invoked from network); 15 Jan 2002 03:33:09 -0000 Received: from ams-clip-nat-ext1.cisco.com (HELO dfawcus-laptop.cisco.com) (64.103.37.2) by mail.netbsd.org with SMTP; 15 Jan 2002 03:33:09 -0000 Received: (qmail 3164 invoked by uid 500); 15 Jan 2002 03:30:31 -0000 Date: Tue, 15 Jan 2002 03:30:31 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Question on transport protocol Message-ID: <20020115032944.A3149@dfawcus-gw-home.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: ietf-ssh-owner@netbsd.org Precedence: list In the transport protocol, section 8 (Service Request), the last paragraph states: Note that after a key exchange with implicit server authentication, the client MUST wait for response to its service request message before sending any further data. I'd like to ask why is the above contraint there? I assume it's for some security reason, but looking at the packet flow, I can't see a reason for it. i.e. it would appear that no additional information is leaked by allowing say a USERAUTH_REQUEST to immediatly follow the SERVICE_REQUEST even when the server has been implicity authenticated. Mind it's a bit of a pointless optimisation given that the user should be prompted about the implicit authentication, but it could make an implementation fractionally simpler. What am I missing? DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 14 23:08:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03619 for ; Mon, 14 Jan 2002 23:08:26 -0500 (EST) Received: (qmail 27818 invoked by uid 605); 15 Jan 2002 04:08:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27811 invoked from network); 15 Jan 2002 04:08:24 -0000 Received: from edinburgh.cisco.com (HELO cisco.com) (144.254.112.76) by mail.netbsd.org with SMTP; 15 Jan 2002 04:08:24 -0000 Received: (from dfawcus@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id EAA27948; Tue, 15 Jan 2002 04:06:42 GMT Date: Tue, 15 Jan 2002 04:06:42 +0000 From: Derek Fawcus To: "Richard E. Silverman" Cc: ietf-ssh@netbsd.org Subject: Re: Question on transport protocol Message-ID: <20020115040641.A27295@edinburgh.cisco.com> References: <20020115032944.A3149@dfawcus-gw-home.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from res@shore.net on Mon, Jan 14, 2002 at 10:36:37PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [ I'm adding the list back into this reply ] On Mon, Jan 14, 2002 at 10:36:37PM -0500, Richard E. Silverman wrote: > On Tue, 15 Jan 2002, Derek Fawcus wrote: > > > In the transport protocol, section 8 (Service Request), the last > > paragraph states: > > > > Note that after a key exchange with implicit server authentication, > > the client MUST wait for response to its service request message > > before sending any further data. > > > > I'd like to ask why is the above contraint there? I assume it's for some > > security reason, but looking at the packet flow, I can't see a reason > > for it. > > With implicit authentication, the client verifies server authentication by > checking that it can decode traffic from the server using the > just-negotiated shared encryption key. That's the bit I don't get. > So it must wait for the next > message from the server; if it doesn't, then it may be sending (possibly > sensitive) data to a bogus server. Surely after the DH exchange, both ends have the same shared secret, thus the above authentication will always succeed? The fact that the KEX_DH_REPLY had a signed hash seems to provide as good an authentication as one is going to get. Thus the client should always be able to decode the first packet. Or is the intention that if a non DH exchange is used, then this delay is required (i.e in the more general case). I'll admit that I'm discussing this from a position of ignorance wrt the key exchange protocol, it may well be that it's required and the method of attack it would fall to is just not obvious to me. DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 14 23:10:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03637 for ; Mon, 14 Jan 2002 23:10:10 -0500 (EST) Received: (qmail 28477 invoked by uid 605); 15 Jan 2002 04:10:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28470 invoked from network); 15 Jan 2002 04:10:09 -0000 Received: from sj-msg-core-1.cisco.com (171.71.163.11) by mail.netbsd.org with SMTP; 15 Jan 2002 04:10:09 -0000 Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g0F4A9F20029 for ; Mon, 14 Jan 2002 20:10:09 -0800 (PST) Received: from cisco.com (dhcp-171-71-137-110.cisco.com [171.71.137.110]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ADH51057; Mon, 14 Jan 2002 20:00:03 -0800 (PST) Message-ID: <3C43AC70.E44694D4@cisco.com> Date: Mon, 14 Jan 2002 20:13:36 -0800 From: Pankaj Bhagra X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: Do we have standards available for scp ?? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Hi There, Do we have any standards/draft/RFC for scp protocol. My initial search over the web didn't returned any relevent information. My understanding of scp (very very limited) is that it is a wrapper around ssh. Any pointers in these direction would definately help. Brgds, pankaj From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 14 23:58:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA04583 for ; Mon, 14 Jan 2002 23:58:10 -0500 (EST) Received: (qmail 2637 invoked by uid 605); 15 Jan 2002 04:58:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2630 invoked from network); 15 Jan 2002 04:58:09 -0000 Received: from ams-clip-nat-ext1.cisco.com (HELO dfawcus-laptop.cisco.com) (64.103.37.2) by mail.netbsd.org with SMTP; 15 Jan 2002 04:58:09 -0000 Received: (qmail 3224 invoked by uid 500); 15 Jan 2002 04:39:28 -0000 Date: Tue, 15 Jan 2002 04:39:28 +0000 From: Derek Fawcus To: ietf-ssh@netbsd.org Subject: Re: Question on transport protocol Message-ID: <20020115043928.A3189@dfawcus-gw-home.cisco.com> References: <20020115032944.A3149@dfawcus-gw-home.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020115032944.A3149@dfawcus-gw-home.cisco.com>; from dfawcus@cisco.com on Tue, Jan 15, 2002 at 03:29:44 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 15, 2002 at 03:29:44 +0000, Derek Fawcus wrote: > In the transport protocol, section 8 (Service Request), the last paragraph > states: > > Note that after a key exchange with implicit server authentication, > the client MUST wait for response to its service request message > before sending any further data. > > I'd like to ask why is the above contraint there? I assume it's for some > security reason, but looking at the packet flow, I can't see a reason > for it. A bit more about what I'm thinking... The obvious problem with implicit server authentication is that it leaves one open to a MITM attack. However I don't see how the above constraint helps here. You'd have just done a sucessful DH exchange with the MITM, and he can then fake all responses, delaying till you get the SERVICE_ACCEPT doesn't appear to gain any advantage in this case. I there must assume it's for some other scenario, if so then what? DF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 03:55:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15494 for ; Tue, 15 Jan 2002 03:55:02 -0500 (EST) Received: (qmail 6891 invoked by uid 605); 15 Jan 2002 08:54:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6884 invoked from network); 15 Jan 2002 08:54:57 -0000 Received: from pianosa.catch22.org (64.81.48.19) by mail.netbsd.org with SMTP; 15 Jan 2002 08:54:57 -0000 Received: by pianosa.catch22.org (Postfix, from userid 1000) id 629C1454; Tue, 15 Jan 2002 00:54:56 -0800 (PST) Date: Tue, 15 Jan 2002 00:54:56 -0800 From: David Terrell To: Pankaj Bhagra Cc: ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115005456.A13218@pianosa.catch22.org> Reply-To: David Terrell References: <3C43AC70.E44694D4@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C43AC70.E44694D4@cisco.com>; from bhagra@cisco.com on Mon, Jan 14, 2002 at 08:13:36PM -0800 X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:53AM up 2 days, 21:31, 34 users, load averages: 0.08, 0.15, 0.16 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Jan 14, 2002 at 08:13:36PM -0800, Pankaj Bhagra wrote: > Hi There, > > Do we have any standards/draft/RFC for scp protocol. My initial search > over the web didn't returned any relevent information. > > My understanding of scp (very very limited) is that it is a wrapper > around ssh. Any pointers in these direction would definately help. scp is the bsd rcp protocol, exactly. Only over ssh instead of rsh. -- David Terrell | "Anyone who says that is woefully Prime Minister, Nebcorp | underinformed. IE, reads usenet." dbt@meat.net | - Sean O'Connor http://wwn.nebcorp.com/ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 03:58:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15548 for ; Tue, 15 Jan 2002 03:58:34 -0500 (EST) Received: (qmail 8411 invoked by uid 605); 15 Jan 2002 08:58:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8403 invoked from network); 15 Jan 2002 08:58:32 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 15 Jan 2002 08:58:32 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id JAA12101; Tue, 15 Jan 2002 09:58:25 +0100 (MET) Date: Tue, 15 Jan 2002 09:58:24 +0100 From: Markus Friedl To: Pankaj Bhagra Cc: ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115085824.GA11584@faui02> References: <3C43AC70.E44694D4@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C43AC70.E44694D4@cisco.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Jan 14, 2002 at 08:13:36PM -0800, Pankaj Bhagra wrote: > Do we have any standards/draft/RFC for scp protocol. My initial search > over the web didn't returned any relevent information. no. > My understanding of scp (very very limited) is that it is a wrapper > around ssh. Any pointers in these direction would definately help. it's just rcp over scp. there is not spec for rcp and i think it's not worth specifying the rcp protocol because of limitations discussed earlier on this list. just use the rcp source... From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 07:40:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20236 for ; Tue, 15 Jan 2002 07:40:02 -0500 (EST) Received: (qmail 24408 invoked by uid 605); 15 Jan 2002 12:40:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24341 invoked from network); 15 Jan 2002 12:39:59 -0000 Received: from syrinx.oankali.net (209.225.172.154) by mail.netbsd.org with SMTP; 15 Jan 2002 12:39:59 -0000 Received: (from res@localhost) by syrinx.oankali.net (8.11.6/8.11.6) id g0FCdvp22899; Tue, 15 Jan 2002 07:39:57 -0500 X-Authentication-Warning: syrinx.oankali.net: res set sender to slade@shore.net using -f Date: Tue, 15 Jan 2002 07:39:57 -0500 (EST) From: "Richard E. Silverman" X-X-Sender: To: SECSH Discussion List Subject: Re: Question on transport protocol In-Reply-To: <20020115040641.A27295@edinburgh.cisco.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 Jan 2002, Derek Fawcus wrote: > Or is the intention that if a non DH exchange is used, then this delay > is required (i.e in the more general case). Exactly. In your next post, you write: > The obvious problem with implicit server authentication is that it > leaves one open to a MITM attack... This doesn't make sense, as a big objective of anything called "server authentication" is exactly to *prevent* MITM. Perhaps you have some model of implicit authentication in mind, but the spec does not specify a mechanism for "implicit server authentication." The idea is merely that it might happen as an integral part of some future key-exchange method, which could then do without explicit server auth mechanism described here. For examples, see the server auth method of SSH-1, as well as the proprosed GSSAPI/Kerberos method for SSH-2. -- Richard Silverman slade@shore.net From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 09:05:48 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23801 for ; Tue, 15 Jan 2002 09:05:47 -0500 (EST) Received: (qmail 12295 invoked by uid 605); 15 Jan 2002 14:05:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12288 invoked from network); 15 Jan 2002 14:05:45 -0000 Received: from sommerfeld.ne.mediaone.net (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 15 Jan 2002 14:05:45 -0000 Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id 2930626CF; Tue, 15 Jan 2002 09:05:45 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id E15F92A55; Tue, 15 Jan 2002 09:05:44 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id D36881FDA; Tue, 15 Jan 2002 09:05:44 -0500 (EST) From: Bill Sommerfeld To: Markus Friedl Cc: Pankaj Bhagra , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? In-Reply-To: Message from Markus Friedl of "Tue, 15 Jan 2002 09:58:24 +0100." <20020115085824.GA11584@faui02> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 15 Jan 2002 09:05:39 -0500 Message-Id: <20020115140544.E15F92A55@orchard.arlington.ma.us> Sender: ietf-ssh-owner@netbsd.org Precedence: list > just use the rcp source... this is the wrong answer for the IETF. someone has volunteered to do a scp/rcp Informational document but they've been lame. they should finish the draft. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 09:16:30 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24101 for ; Tue, 15 Jan 2002 09:16:29 -0500 (EST) Received: (qmail 13480 invoked by uid 605); 15 Jan 2002 14:16:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13471 invoked from network); 15 Jan 2002 14:16:27 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 15 Jan 2002 14:16:27 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id PAA08179; Tue, 15 Jan 2002 15:16:19 +0100 (MET) Date: Tue, 15 Jan 2002 15:16:19 +0100 From: Markus Friedl To: Bill Sommerfeld Cc: Pankaj Bhagra , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115141619.GA7816@faui02> References: <20020115085824.GA11584@faui02> <20020115140544.E15F92A55@orchard.arlington.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020115140544.E15F92A55@orchard.arlington.ma.us> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 15, 2002 at 09:05:39AM -0500, Bill Sommerfeld wrote: > > just use the rcp source... > > this is the wrong answer for the IETF. sure > someone has volunteered to do a scp/rcp Informational document but > they've been lame. they should finish the draft. sure, but i don't think rcp can be fixed. it's been deployed for years (decades?). From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 09:42:12 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25073 for ; Tue, 15 Jan 2002 09:42:11 -0500 (EST) Received: (qmail 24324 invoked by uid 605); 15 Jan 2002 14:42:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24317 invoked from network); 15 Jan 2002 14:42:10 -0000 Received: from sommerfeld.ne.mediaone.net (HELO stack.hamachi.org) (66.31.126.43) by mail.netbsd.org with SMTP; 15 Jan 2002 14:42:10 -0000 Received: from orchard.arlington.ma.us (orchard.hamachi.org [18.101.2.2]) by stack.hamachi.org (Postfix) with ESMTP id BF94026CF; Tue, 15 Jan 2002 09:42:09 -0500 (EST) Received: by orchard.arlington.ma.us (Postfix, from userid 587) id 90D792A55; Tue, 15 Jan 2002 09:42:09 -0500 (EST) Received: from orchard.arlington.ma.us (localhost [127.0.0.1]) by orchard.arlington.ma.us (Postfix) with ESMTP id 82E8F1FDA; Tue, 15 Jan 2002 09:42:09 -0500 (EST) From: Bill Sommerfeld To: Markus Friedl Cc: Pankaj Bhagra , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? In-Reply-To: Message from Markus Friedl of "Tue, 15 Jan 2002 15:16:19 +0100." <20020115141619.GA7816@faui02> Reply-To: sommerfeld@orchard.arlington.ma.us Date: Tue, 15 Jan 2002 09:42:04 -0500 Message-Id: <20020115144209.90D792A55@orchard.arlington.ma.us> Sender: ietf-ssh-owner@netbsd.org Precedence: list > sure, but i don't think rcp can be fixed. it's been > deployed for years (decades?). it's still worthwhile to document existing practice. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 10:55:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00055 for ; Tue, 15 Jan 2002 10:55:48 -0500 (EST) Received: (qmail 14063 invoked by uid 605); 15 Jan 2002 15:55:46 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14056 invoked from network); 15 Jan 2002 15:55:45 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.netbsd.org with SMTP; 15 Jan 2002 15:55:45 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13079; Tue, 15 Jan 2002 07:55:39 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id HAA12687; Tue, 15 Jan 2002 07:56:49 -0800 (PST) Received: from Sun.COM (dsl-192-32.Eng.Sun.COM [129.146.192.32]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g0FFtaqS244033; Tue, 15 Jan 2002 07:55:36 -0800 (PST) Message-ID: <3C4450BC.8020003@Sun.COM> Date: Tue, 15 Jan 2002 07:54:36 -0800 From: Darren J Moffat Organization: Sun Microsystems, Solaris Software Security Technologies Group User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.2) Gecko/20011002 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Markus Friedl CC: Pankaj Bhagra , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? References: <3C43AC70.E44694D4@cisco.com> <20020115085824.GA11584@faui02> 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: > it's just rcp over scp. there is not spec for rcp and i think > it's not worth specifying the rcp protocol because of limitations > discussed earlier on this list. I think the very reason that rcp has known limitations is a good idea to have it specified and marked is historical. That way when the discussion comes up again there is a simple document to point to. Having said that I don't think it is approriate work for this group to document rcp. -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 11:59:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04985 for ; Tue, 15 Jan 2002 11:59:27 -0500 (EST) Received: (qmail 287 invoked by uid 605); 15 Jan 2002 16:58:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29380 invoked from network); 15 Jan 2002 16:58:01 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 15 Jan 2002 16:58:01 -0000 Received: from localhost (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 61A6B67103; Tue, 15 Jan 2002 12:11:16 -0500 (EST) Date: Tue, 15 Jan 2002 11:57:38 -0500 Subject: Re: Do we have standards available for scp ?? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: ietf-ssh@netbsd.org To: David Terrell From: RJ Atkinson In-Reply-To: <20020115005456.A13218@pianosa.catch22.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, January 15, 2002, at 03:54 AM, David Terrell wrote: > On Mon, Jan 14, 2002 at 08:13:36PM -0800, Pankaj Bhagra wrote: >> Do we have any standards/draft/RFC for scp protocol. My initial search >> over the web didn't returned any relevent information. >> >> My understanding of scp (very very limited) is that it is a wrapper >> around ssh. Any pointers in these direction would definately help. > > scp is the bsd rcp protocol, exactly. Only over ssh instead of rsh. IMHO, it would be strongly desirable to have a (possibly trivially short) RFC describing SCP. If RCP is already in an RFC, then it might cite that RFC by reference and have a page or two about 'what is SCP' and how it is implemented. If RCP is not yet in an RFC, then the SCP RFC might include that protocol definition. Either way, we ought not have SCP's definition only be folklore on IETF mailing lists ("SCP is just BSD RCP over SSH instead of RSH"), IMHO. I do really appreciate the email here today noting that fact; it is just that this data needs to be archivally documented (whether or not on the standards track as WG prefers). RFCs are this community's archival document series. Regrettably, I don't have time to do the SCP writeup myself just now. Maybe someone else could volunteer to the SSH WG Chair ? Ran rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 12:04:30 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05256 for ; Tue, 15 Jan 2002 12:04:28 -0500 (EST) Received: (qmail 2649 invoked by uid 605); 15 Jan 2002 17:04:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2642 invoked from network); 15 Jan 2002 17:04:26 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 15 Jan 2002 17:04:26 -0000 Received: from localhost (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 496A567103; Tue, 15 Jan 2002 12:18:02 -0500 (EST) Date: Tue, 15 Jan 2002 12:04:24 -0500 Subject: Re: Do we have standards available for scp ?? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: ietf-ssh@netbsd.org To: Markus Friedl From: RJ Atkinson In-Reply-To: <20020115141619.GA7816@faui02> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Tuesday, January 15, 2002, at 09:16 AM, Markus Friedl wrote: > sure, but i don't think rcp can be fixed. it's been > deployed for years (decades?). "Fixing RCP" isn't the issue here. Documenting a widely deployed protocol (e.g. SCP) is the important issue here -- even if that means the "Security Considerations" section were to be lengthy with the things that "need fixing" in SCP (if any). Frankly, it would be also good to document RCP and to have a lengthy description of why RCP is a bad idea operationally (e.g. list of security risks with RCP) and even suggest using SCP instead (to reduce security risks). That's a bit outside this WG's charter (potentially, subject to WG Chair decision), whereas documenting SCP sufficiently to write an interoperable implementation from the RFC would seem clearly within this WG's charter (also subject to WG Chair decision). IMHO, Ran rja@extremenetworks.com From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 12:21:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05993 for ; Tue, 15 Jan 2002 12:21:28 -0500 (EST) Received: (qmail 8919 invoked by uid 605); 15 Jan 2002 17:21:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8910 invoked from network); 15 Jan 2002 17:21:26 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 15 Jan 2002 17:21:26 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id SAA21890; Tue, 15 Jan 2002 18:21:23 +0100 (MET) Date: Tue, 15 Jan 2002 18:21:22 +0100 From: Markus Friedl To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115172122.GC8644@faui02> References: <20020115141619.GA7816@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 15, 2002 at 12:04:24PM -0500, RJ Atkinson wrote: > Frankly, it would be also good to document RCP and to have a lengthy > description of why RCP is a bad idea operationally (e.g. list of > security risks with RCP) and even suggest using SCP instead (to > reduce security risks). But SCP == RCP (the protocols), so either _both_ are secure or _none_. > That's a bit outside this WG's charter > (potentially, subject to WG Chair decision), whereas documenting SCP > sufficiently to write an interoperable implementation from the RFC > would seem clearly within this WG's charter (also subject to WG Chair > decision). Well, documenting SCP means documenting RCP. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 12:27:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06144 for ; Tue, 15 Jan 2002 12:27:04 -0500 (EST) Received: (qmail 10451 invoked by uid 605); 15 Jan 2002 17:27:03 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10443 invoked from network); 15 Jan 2002 17:27:03 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 Jan 2002 17:27:03 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21472; Tue, 15 Jan 2002 10:27:01 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11542; Tue, 15 Jan 2002 12:27:01 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0FHR0Xt016228; Tue, 15 Jan 2002 12:27:00 -0500 (EST) Message-Id: <200201151727.g0FHR0Xt016228@thunk.east.sun.com> From: Bill Sommerfeld To: RJ Atkinson cc: David Terrell , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? In-Reply-To: Your message of "Tue, 15 Jan 2002 11:57:38 EST." Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jan 2002 12:27:00 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Ran, There is no rcp RFC; rcp runs over rsh. As I understand it, the rcp client uses the rsh protocol to invoke rcp on the server, then the two rcp's talk to each other over the rsh channel. scp is just rcp over ssh -- scp uses ssh to invoke another scp on the server, then the two scp's talk over the ssh channel using the exact same protocol. A historic or informational document on the existing practice of scp is very much within scope for the working group; if this means that the IETF community also gets an rcp document "for free", even better. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 12:39:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06550 for ; Tue, 15 Jan 2002 12:39:44 -0500 (EST) Received: (qmail 14303 invoked by uid 605); 15 Jan 2002 17:39:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14295 invoked from network); 15 Jan 2002 17:39:42 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 15 Jan 2002 17:39:42 -0000 Received: from inago.swcp.com (inago.swcp.com [198.59.115.17]) by taka.swcp.com (8.11.6/8.11.6) with ESMTP id g0FHdgU69516; Tue, 15 Jan 2002 10:39:42 -0700 (MST) Received: from localhost (dprevett@localhost) by inago.swcp.com (8.8.7/8.8.7) with ESMTP id KAA12896; Tue, 15 Jan 2002 10:39:41 -0700 (MST) X-Authentication-Warning: inago.swcp.com: dprevett owned process doing -bs Date: Tue, 15 Jan 2002 10:39:41 -0700 (MST) From: Daniel Prevett To: Bill Sommerfeld cc: ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? In-Reply-To: <200201151727.g0FHR0Xt016228@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 I was under the impression that scp2 was a truncated sftp client, and that scp1 was rcp over ssh. I know that OpenSSH's implementation of scp can use either an ssh1 or ssh2 connection, but that everyone else's implementation of scp that uses ssh2 uses the sftp subsystem. Could we clarify which one we are talking about here? Thanks, -Daniel On Tue, 15 Jan 2002, Bill Sommerfeld wrote: > Ran, > > There is no rcp RFC; rcp runs over rsh. As I understand it, the rcp > client uses the rsh protocol to invoke rcp on the server, then the two > rcp's talk to each other over the rsh channel. > > scp is just rcp over ssh -- scp uses ssh to invoke another scp on the > server, then the two scp's talk over the ssh channel using the exact > same protocol. > > A historic or informational document on the existing practice of scp > is very much within scope for the working group; if this means that > the IETF community also gets an rcp document "for free", even better. > > - Bill > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 13:03:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07370 for ; Tue, 15 Jan 2002 13:03:15 -0500 (EST) Received: (qmail 20304 invoked by uid 605); 15 Jan 2002 18:03:12 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20297 invoked from network); 15 Jan 2002 18:03:10 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 15 Jan 2002 18:03:10 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id SAA24755; Tue, 15 Jan 2002 18:54:03 +0100 (MET) Date: Tue, 15 Jan 2002 18:54:03 +0100 From: Markus Friedl To: Daniel Prevett Cc: Bill Sommerfeld , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115175402.GA22105@faui02> References: <200201151727.g0FHR0Xt016228@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 15, 2002 at 10:39:41AM -0700, Daniel Prevett wrote: > I was under the impression that scp2 was a truncated sftp client, and that > scp1 was rcp over ssh. yes, now scp2 means the scp binary from SSH.com's 1.2.x software. scp1 means the scp binary from SSH.com's 2.x and 3.x software. > I know that OpenSSH's implementation of scp can > use either an ssh1 or ssh2 connection, but that everyone else's > implementation of scp that uses ssh2 uses the sftp subsystem. Could we > clarify which one we are talking about here? it's what's called scp1 SSH.com's 1.2.x software. scp1 speaks RCP. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 13:45:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09041 for ; Tue, 15 Jan 2002 13:44:59 -0500 (EST) Received: (qmail 29393 invoked by uid 605); 15 Jan 2002 18:44:42 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29346 invoked from network); 15 Jan 2002 18:44:40 -0000 Received: from noc.untraceable.net (166.84.189.65) by mail.netbsd.org with SMTP; 15 Jan 2002 18:44:40 -0000 Received: from noc.untraceable.net (localhost [127.0.0.1]) by noc.untraceable.net (8.12.2/8.12.2/bonk!) with ESMTP id g0FIiYCp022789; Tue, 15 Jan 2002 13:44:35 -0500 (EST) Received: (from andrew@localhost) by noc.untraceable.net (8.12.2/8.12.2) id g0FIiYiD022788; Tue, 15 Jan 2002 13:44:34 -0500 (EST) Date: Tue, 15 Jan 2002 13:44:33 -0500 From: Andrew Brown To: Markus Friedl Cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115134433.A22463@noc.untraceable.net> References: <20020115141619.GA7816@faui02> <20020115172122.GC8644@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020115172122.GC8644@faui02>; from markus@openbsd.org on Tue, Jan 15, 2002 at 06:21:22PM +0100 X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :) Sender: ietf-ssh-owner@netbsd.org Precedence: list >> Frankly, it would be also good to document RCP and to have a lengthy >> description of why RCP is a bad idea operationally (e.g. list of >> security risks with RCP) and even suggest using SCP instead (to >> reduce security risks). > >But SCP == RCP (the protocols), so either _both_ are secure >or _none_. well...yes and no. they are almost the same, but there are also places where they differ radically, depending on your point of view. for example, in the source() routine of my netbsd-current rcp: if (pflag) { /* * Make it compatible with possible future * versions expecting microseconds. */ (void)snprintf(buf, sizeof(buf), "T%ld %ld %ld %ld\n", (long)stb.st_mtimespec.tv_sec, (long)stb.st_mtimespec.tv_nsec / 1000, (long)stb.st_atimespec.tv_sec, (long)stb.st_atimespec.tv_nsec / 1000); ... (void)snprintf(buf, sizeof(buf), "C%04o %lld %s\n", stb.st_mode & RCPMODEMASK, (long long)stb.st_size, last); whereas in the same routine in ssh-1.2.32 (as an example): if (pflag) { /* * Make it compatible with possible future * versions expecting microseconds. */ (void)snprintf(buf, sizeof(buf), "T%lu 0 %lu 0\n", (unsigned long)stb.st_mtime, (unsigned long)stb.st_atime); ... (void)snprintf(buf, sizeof(buf), "C%04o %lu %s\n", (unsigned int)(stb.st_mode & FILEMODEMASK), (unsigned long)stb.st_size, last); the size of longs can differ between cpu architectures, and a long long is not necessarily the same size as a long in all places either. as protocols go, it works, but it appears to be looking for trouble. >> That's a bit outside this WG's charter >> (potentially, subject to WG Chair decision), whereas documenting SCP >> sufficiently to write an interoperable implementation from the RFC >> would seem clearly within this WG's charter (also subject to WG Chair >> decision). > >Well, documenting SCP means documenting RCP. otoh, an existing document covering rcp would make the scp document a lot easier. -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 13:45:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09071 for ; Tue, 15 Jan 2002 13:45:21 -0500 (EST) Received: (qmail 148 invoked by uid 605); 15 Jan 2002 18:45:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 141 invoked from network); 15 Jan 2002 18:45:14 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 15 Jan 2002 18:45:14 -0000 Received: from localhost (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 0B17F67103; Tue, 15 Jan 2002 13:58:51 -0500 (EST) Date: Tue, 15 Jan 2002 13:45:11 -0500 Subject: Re: Do we have standards available for scp ?? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: ietf-ssh@netbsd.org To: Markus Friedl From: RJ Atkinson In-Reply-To: <20020115175402.GA22105@faui02> Message-Id: <015A9A3F-09E8-11D6-9E28-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit That this level of complexity exists in something this simple really adds moment to the notion of documenting the existing practice, IMHO. On Tuesday, January 15, 2002, at 12:54 PM, Markus Friedl wrote: > On Tue, Jan 15, 2002 at 10:39:41AM -0700, Daniel Prevett wrote: >> I was under the impression that scp2 was a truncated sftp client, and >> that >> scp1 was rcp over ssh. > > yes, now > scp2 means the scp binary from SSH.com's 1.2.x software. > scp1 means the scp binary from SSH.com's 2.x and 3.x software. > >> I know that OpenSSH's implementation of scp can >> use either an ssh1 or ssh2 connection, but that everyone else's >> implementation of scp that uses ssh2 uses the sftp subsystem. Could we >> clarify which one we are talking about here? > > it's what's called scp1 SSH.com's 1.2.x software. > > scp1 speaks RCP. > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 14:56:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11405 for ; Tue, 15 Jan 2002 14:56:51 -0500 (EST) Received: (qmail 15519 invoked by uid 605); 15 Jan 2002 19:56:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 15512 invoked from network); 15 Jan 2002 19:56:47 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 15 Jan 2002 19:56:47 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id UAA01329; Tue, 15 Jan 2002 20:56:40 +0100 (MET) Date: Tue, 15 Jan 2002 20:56:40 +0100 From: Markus Friedl To: Andrew Brown Cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115195640.GC22105@faui02> References: <20020115141619.GA7816@faui02> <20020115172122.GC8644@faui02> <20020115134433.A22463@noc.untraceable.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020115134433.A22463@noc.untraceable.net> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 15, 2002 at 01:44:33PM -0500, Andrew Brown wrote: > >> Frankly, it would be also good to document RCP and to have a lengthy > >> description of why RCP is a bad idea operationally (e.g. list of > >> security risks with RCP) and even suggest using SCP instead (to > >> reduce security risks). > > > >But SCP == RCP (the protocols), so either _both_ are secure > >or _none_. > > well...yes and no. they are almost the same, but there are also > places where they differ radically, depending on your point of view. > for example, in the source() routine of my netbsd-current rcp: well, that's not really a protocol issue. > >Well, documenting SCP means documenting RCP. > > otoh, an existing document covering rcp would make the scp document a > lot easier. sure. I just wonder why nobody seems to care about core protocol issues, but everybody cares about scp. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 15:04:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11613 for ; Tue, 15 Jan 2002 15:04:24 -0500 (EST) Received: (qmail 16465 invoked by uid 605); 15 Jan 2002 20:04:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16456 invoked from network); 15 Jan 2002 20:04:21 -0000 Received: from noc.untraceable.net (166.84.189.65) by mail.netbsd.org with SMTP; 15 Jan 2002 20:04:21 -0000 Received: from noc.untraceable.net (localhost [127.0.0.1]) by noc.untraceable.net (8.12.2/8.12.2/bonk!) with ESMTP id g0FK4JCp024291; Tue, 15 Jan 2002 15:04:19 -0500 (EST) Received: (from andrew@localhost) by noc.untraceable.net (8.12.2/8.12.2) id g0FK4J9C024290; Tue, 15 Jan 2002 15:04:19 -0500 (EST) Date: Tue, 15 Jan 2002 15:04:18 -0500 From: Andrew Brown To: Markus Friedl Cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115150417.A24226@noc.untraceable.net> References: <20020115141619.GA7816@faui02> <20020115172122.GC8644@faui02> <20020115134433.A22463@noc.untraceable.net> <20020115195640.GC22105@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020115195640.GC22105@faui02>; from markus@openbsd.org on Tue, Jan 15, 2002 at 08:56:40PM +0100 X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :) Sender: ietf-ssh-owner@netbsd.org Precedence: list >> >> Frankly, it would be also good to document RCP and to have a lengthy >> >> description of why RCP is a bad idea operationally (e.g. list of >> >> security risks with RCP) and even suggest using SCP instead (to >> >> reduce security risks). >> > >> >But SCP == RCP (the protocols), so either _both_ are secure >> >or _none_. >> >> well...yes and no. they are almost the same, but there are also >> places where they differ radically, depending on your point of view. >> for example, in the source() routine of my netbsd-current rcp: > >well, that's not really a protocol issue. not an ssh protocol issue, certainly, but how scp or rcp talks to the other end is. using fsecure's scp to copy a five gigabyte file from an x86 machine to an alpha won't work very well. that's an *scp* protocol failure, and that implies me that there ought to be some simple guidelines. >> >Well, documenting SCP means documenting RCP. >> >> otoh, an existing document covering rcp would make the scp document a >> lot easier. > >sure. > >I just wonder why nobody seems to care about core protocol issues, >but everybody cares about scp. because a lot of people like it? -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 17:03:52 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14659 for ; Tue, 15 Jan 2002 17:03:51 -0500 (EST) Received: (qmail 12896 invoked by uid 605); 15 Jan 2002 22:03:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12889 invoked from network); 15 Jan 2002 22:03:49 -0000 Received: from guinness.cs.stevens-tech.edu (155.246.89.8) by mail.netbsd.org with SMTP; 15 Jan 2002 22:03:49 -0000 Received: by guinness.cs.stevens-tech.edu (Postfix, from userid 3330) id AA567141682; Tue, 15 Jan 2002 17:03:46 -0500 (EST) Date: Tue, 15 Jan 2002 17:03:46 -0500 From: Thor Simon To: ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020115170346.A1220654@cs.stevens-tech.edu> References: <20020115141619.GA7816@faui02> <20020115172122.GC8644@faui02> <20020115134433.A22463@noc.untraceable.net> <20020115195640.GC22105@faui02> <20020115150417.A24226@noc.untraceable.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020115150417.A24226@noc.untraceable.net>; from atatat@atatdot.net on Tue, Jan 15, 2002 at 03:04:18PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 15, 2002 at 03:04:18PM -0500, Andrew Brown wrote: > >> >> Frankly, it would be also good to document RCP and to have a lengthy > >> >> description of why RCP is a bad idea operationally (e.g. list of > >> >> security risks with RCP) and even suggest using SCP instead (to > >> >> reduce security risks). > >> > > >> >But SCP == RCP (the protocols), so either _both_ are secure > >> >or _none_. > >> > >> well...yes and no. they are almost the same, but there are also > >> places where they differ radically, depending on your point of view. > >> for example, in the source() routine of my netbsd-current rcp: > > > >well, that's not really a protocol issue. > > not an ssh protocol issue, certainly, but how scp or rcp talks to the > other end is. using fsecure's scp to copy a five gigabyte file from > an x86 machine to an alpha won't work very well. that's an *scp* > protocol failure, and that implies me that there ought to be some > simple guidelines. Really, the only thing wrong with F-secure's scp is that it's *REALLY OLD*. It is missing bugfixes that went into BSD's rcp about a decade ago. Indeed, 'rcp' of the 4.2BSD era will not work correctly between an x86 and an Alpha. I have an Informational RFC on 'rcp' pretty much ready (FWIW, I document the modern version of the protocol, not the ancient version F-Secure used for their scp; generally, these interoperate, except in conditions like the one Andrew describes above) but there was highly negative raction last time I mentioned that on this list so I decided not to spend more time on it. Did I misapprehend the general feeling about this subject? From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 15 17:05:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14693 for ; Tue, 15 Jan 2002 17:05:36 -0500 (EST) Received: (qmail 13281 invoked by uid 605); 15 Jan 2002 22:05:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 13270 invoked from network); 15 Jan 2002 22:05:35 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 15 Jan 2002 22:05:35 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08540; Tue, 15 Jan 2002 15:05:30 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11149; Tue, 15 Jan 2002 17:05:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0FM5SXt025542; Tue, 15 Jan 2002 17:05:29 -0500 (EST) Message-Id: <200201152205.g0FM5SXt025542@thunk.east.sun.com> From: Bill Sommerfeld To: Thor Simon cc: ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? In-Reply-To: Your message of "Tue, 15 Jan 2002 17:03:46 EST." <20020115170346.A1220654@cs.stevens-tech.edu> Reply-to: sommerfeld@east.sun.com Date: Tue, 15 Jan 2002 17:05:28 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I have an Informational RFC on 'rcp' pretty much ready (FWIW, I document the > modern version of the protocol, not the ancient version F-Secure used for > their scp; generally, these interoperate, except in conditions like the one > Andrew describes above) but there was highly negative raction last time I > mentioned that on this list so I decided not to spend more time on it. Did > I misapprehend the general feeling about this subject? There certainly seems to be interest. - BIll From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 16 01:03:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23126 for ; Wed, 16 Jan 2002 01:03:14 -0500 (EST) Received: (qmail 10552 invoked by uid 605); 16 Jan 2002 06:03:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10400 invoked from network); 16 Jan 2002 06:03:01 -0000 Received: from dsl254-081-164.nyc1.dsl.speakeasy.net (HELO zalon.pc.cs.cmu.edu) (216.254.81.164) by mail.netbsd.org with SMTP; 16 Jan 2002 06:03:01 -0000 Received: from zalon.pc.cs.cmu.edu ([127.0.0.1]) by zalon.pc.cs.cmu.edu id aa25963; 16 Jan 2002 1:02 EST Date: Wed, 16 Jan 2002 01:02:24 -0500 (EST) From: Jeffrey Hutzelman X-Sender: jhutz@zalon.pc.cs.cmu.edu To: "Richard E. Silverman" cc: SECSH Discussion List Subject: Re: Question on transport protocol In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, 15 Jan 2002, Richard E. Silverman wrote: > On Tue, 15 Jan 2002, Derek Fawcus wrote: > > > Or is the intention that if a non DH exchange is used, then this delay > > is required (i.e in the more general case). > > Exactly. In your next post, you write: > > > The obvious problem with implicit server authentication is that it > > leaves one open to a MITM attack... > > This doesn't make sense, as a big objective of anything called "server > authentication" is exactly to *prevent* MITM. Perhaps you have some model > of implicit authentication in mind, but the spec does not specify a > mechanism for "implicit server authentication." The idea is merely that > it might happen as an integral part of some future key-exchange method, > which could then do without explicit server auth mechanism described here. > For examples, see the server auth method of SSH-1, as well as the > proprosed GSSAPI/Kerberos method for SSH-2. FWIW, the GSSAPI key exchange doesn't rely on this -- during key exchange, a GSSAPI security context is established and then used to sign a DH exchange, similarly to the way the host key is used during the normal signed DH exchange described in the transport draft. Once GSSAPI keyex is complete, you know the server's identity and that there is no MITM. However, there's something in the back of my mind saying that removing this requirement would be a bad idea. -- 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 Jan 16 07:03:21 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04746 for ; Wed, 16 Jan 2002 07:03:21 -0500 (EST) Received: (qmail 8417 invoked by uid 605); 16 Jan 2002 12:03:17 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8410 invoked from network); 16 Jan 2002 12:03:16 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 16 Jan 2002 12:03:16 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04694; Wed, 16 Jan 2002 07:03:13 -0500 (EST) Message-Id: <200201161203.HAA04694@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-02.txt Date: Wed, 16 Jan 2002 07:03:03 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : 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-02.txt Pages : 8 Date : 15-Jan-02 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-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-dh-group-exchange-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-dh-group-exchange-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: <20020115095431.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-dh-group-exchange-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-dh-group-exchange-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020115095431.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 16 07:03:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04832 for ; Wed, 16 Jan 2002 07:03:36 -0500 (EST) Received: (qmail 8748 invoked by uid 605); 16 Jan 2002 12:03:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8741 invoked from network); 16 Jan 2002 12:03:31 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 16 Jan 2002 12:03:31 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04693; Wed, 16 Jan 2002 07:03:13 -0500 (EST) Message-Id: <200201161203.HAA04693@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-gsskeyex-03.txt Date: Wed, 16 Jan 2002 07:03:07 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : GSSAPI Authentication and Key Exchange for the Secure Shell Protocol Author(s) : J. Hutzelman, J. Salowey, J. Galbraith, V. Welch Filename : draft-ietf-secsh-gsskeyex-03.txt Pages : 24 Date : 15-Jan-02 The Secure Shell protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. The Generic Security Service Application Program Interface (GSS-API) [2] provides security services to callers in a mechanism-independent fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-gsskeyex-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-gsskeyex-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020115095443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-gsskeyex-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-gsskeyex-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020115095443.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 17 16:59:54 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14173 for ; Thu, 17 Jan 2002 16:59:54 -0500 (EST) Received: (qmail 19548 invoked by uid 605); 17 Jan 2002 21:59:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19541 invoked from network); 17 Jan 2002 21:59:50 -0000 Received: from mx01.nexgo.de (151.189.8.96) by mail.netbsd.org with SMTP; 17 Jan 2002 21:59:50 -0000 Received: from localhost (dsl-213-023-063-082.arcor-ip.net [213.23.63.82]) by mx01.nexgo.de (Postfix) with ESMTP id 66DB73BD44; Thu, 17 Jan 2002 22:59:48 +0100 (CET) Received: by localhost (Postfix, from userid 31451) id D46BD44AE; Thu, 17 Jan 2002 22:59:37 +0100 (CET) Date: Thu, 17 Jan 2002 22:59:37 +0100 From: Markus Friedl To: Andrew Brown Cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020117225937.A32505@folly> References: <20020115141619.GA7816@faui02> <20020115172122.GC8644@faui02> <20020115134433.A22463@noc.untraceable.net> <20020115195640.GC22105@faui02> <20020115150417.A24226@noc.untraceable.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020115150417.A24226@noc.untraceable.net>; from atatat@atatdot.net on Tue, Jan 15, 2002 at 03:04:18PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 15, 2002 at 03:04:18PM -0500, Andrew Brown wrote: > other end is. using fsecure's scp to copy a five gigabyte file from btw, 1.2.32 is not from f-secure From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 17 17:11:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14434 for ; Thu, 17 Jan 2002 17:11:30 -0500 (EST) Received: (qmail 20963 invoked by uid 605); 17 Jan 2002 22:11:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20956 invoked from network); 17 Jan 2002 22:11:22 -0000 Received: from noc.untraceable.net (166.84.189.65) by mail.netbsd.org with SMTP; 17 Jan 2002 22:11:22 -0000 Received: from noc.untraceable.net (localhost [127.0.0.1]) by noc.untraceable.net (8.12.2/8.12.2/bonk!) with ESMTP id g0HMBJCp022402; Thu, 17 Jan 2002 17:11:19 -0500 (EST) Received: (from andrew@localhost) by noc.untraceable.net (8.12.2/8.12.2) id g0HMBF0X022401; Thu, 17 Jan 2002 17:11:15 -0500 (EST) Date: Thu, 17 Jan 2002 17:11:14 -0500 From: Andrew Brown To: Markus Friedl Cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: Do we have standards available for scp ?? Message-ID: <20020117171114.A22156@noc.untraceable.net> References: <20020115141619.GA7816@faui02> <20020115172122.GC8644@faui02> <20020115134433.A22463@noc.untraceable.net> <20020115195640.GC22105@faui02> <20020115150417.A24226@noc.untraceable.net> <20020117225937.A32505@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020117225937.A32505@folly>; from markus@openbsd.org on Thu, Jan 17, 2002 at 10:59:37PM +0100 X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports fans :) Sender: ietf-ssh-owner@netbsd.org Precedence: list >> other end is. using fsecure's scp to copy a five gigabyte file from > >btw, 1.2.32 is not from f-secure that's quite true. i keep confusing ssh.com and fsecure for some reason. i don't know why. but...my point still stands. :) -- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 17 20:08:43 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16710 for ; Thu, 17 Jan 2002 20:08:42 -0500 (EST) Received: (qmail 17879 invoked by uid 605); 18 Jan 2002 01:08:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17872 invoked from network); 18 Jan 2002 01:08:39 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 18 Jan 2002 01:08:39 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id RAA29368 for ; Thu, 17 Jan 2002 17:08:39 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id RAA26013 for ; Thu, 17 Jan 2002 17:08:38 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g0I18cn03949 for ietf-ssh@netbsd.org; Thu, 17 Jan 2002 17:08:38 -0800 Date: Thu, 17 Jan 2002 17:08:38 -0800 From: Frank Cusack To: ietf-ssh@netbsd.org Subject: Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt Message-ID: <20020117170838.L3039@google.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from ShesMax@ru.hilti.com on Wed, Jan 24, 2001 at 10:45:08AM +0300 Sender: ietf-ssh-owner@netbsd.org Precedence: list Hi, I realize this is a year-old message, but I dropped off the list a long time ago, back when the list was lossy (clinet.fi days). Anyway, I am in the process of updating the draft (along with Martin) and wanted to respond to some old issues. In a week or so I'll post the updated draft here for comments before submission. On Wed, Jan 24, 2001 at 10:45:08AM +0300, Shesterikov Maxim (sm) wrote: > For a server that uses a separate authentication layer it is desirable to > state in the draft that the order of responses should match with the order > of prompts. And later: On Thu, Feb 22, 2001 at 09:59:43AM +0300, Shesterikov Maxim (sm) wrote: [Martin Forssen: ] > >Such a text implies that the server is permitted to > >have multiple outstanding authentication requests simultaneously, and > >this can be complicated to handle in the client. Would it not be better > >just instead forbid the server to have more than one set of prompts > >(SSH_MSG_USERAUTH_INFO_REQUEST packets) outstanding at any time? > >Comments? > I agree. I read the question as "each numbered response must match up with the corresponding prompt", ie, in a single INFO_REQUEST there might be multiple prompts, and in the INFO_RESPONSE the answers must be in the same order as the questions. I believe both are valid points, the first (multiple outstanding INFO_REQUEST's) has been addressed, I will add clarification on the second (response ordering) to the draft. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 17 20:18:29 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16831 for ; Thu, 17 Jan 2002 20:18:28 -0500 (EST) Received: (qmail 19780 invoked by uid 605); 18 Jan 2002 01:18:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 19772 invoked from network); 18 Jan 2002 01:18:25 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 18 Jan 2002 01:18:25 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id RAA30216 for ; Thu, 17 Jan 2002 17:18:25 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id RAA29006 for ; Thu, 17 Jan 2002 17:18:25 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g0I1IPq03959 for ietf-ssh@netbsd.org; Thu, 17 Jan 2002 17:18:25 -0800 Date: Thu, 17 Jan 2002 17:18:25 -0800 From: Frank Cusack To: ietf-ssh@netbsd.org Subject: Re: Section 3.2 of secsh-auth-kbdinteract-01 Message-ID: <20020117171824.M3039@google.com> References: <200012190328.eBJ3Swm155608@jurassic.eng.sun.com> <20001219101930.26D0C317AA@pelee.firedoor.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20001219101930.26D0C317AA@pelee.firedoor.se>; from maf@appgate.com on Tue, Dec 19, 2000 at 11:19:32AM +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Dec 19, 2000 at 11:19:32AM +0100, Martin Forssen wrote: > On 18 Dec, Darren Moffat wrote: > >>Section 3.2: > > > >> The server SHOULD limit the length of the name and prompt fields to > >> 30 characters. No restrictions are placed on the instruction > >>field. > >> > >>30 characters could be too little. > >> > >> "sjl@foobar.internal.fi.ssh.com's passcode for SecurID auth:" > >> > >>especially considering section 3.3 considerations > > > > Agreed where did 30 come from ? (I'll take a wild guess here and > > assume it is the number of chars that can be displayed on the screen > > of a PalmPilot using the default font? (I checked ;-)) > > I think I already have countered this example, ut I just wanted to > comment on the number 30. The number 30 is just an arbitrary number and > I am not aware of any systems which actually enforces those limits. 30 does seem an odd number[1]. I don't recall the exact device (probably Palm) but I do believe it was in fact based on some minimal screen width limitation. The reason the name and prompt fields were limited is b/c they are expected to be printed on a single line. In your example, is it feasible that instead of a single long prompt, it could be broken up as: name: "SecurID auth" instruction: "SecurID auth for sjl@foobar.internal.fi.ssh.com" prompt: "Enter passcode: " This might be difficult for PAM (sshd might have to know what text to expect from the underlying PAM module), but would be feasible for "native" securID auth. Perhaps a good compromise is to just say that the server should expect that the client may truncate these fields. /fc [1] ha! From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 17 20:34:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17004 for ; Thu, 17 Jan 2002 20:34:24 -0500 (EST) Received: (qmail 22807 invoked by uid 605); 18 Jan 2002 01:34:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22800 invoked from network); 18 Jan 2002 01:34:22 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 18 Jan 2002 01:34:22 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id RAA31510; Thu, 17 Jan 2002 17:34:22 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id RAA01724; Thu, 17 Jan 2002 17:34:18 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g0I1YHs04310; Thu, 17 Jan 2002 17:34:17 -0800 Date: Thu, 17 Jan 2002 17:34:17 -0800 From: Frank Cusack To: ietf-ssh@netbsd.org Cc: Bill Sommerfeld , Darren Moffat Subject: Re: message lang tags verse SSH_MSG_KEXINIT Message-ID: <20020117173417.N3039@google.com> References: <200103090233.f292X3v678582@jurassic.eng.sun.com> <200103090249.f292nl909123@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200103090249.f292nl909123@thunk.east.sun.com>; from sommerfeld@east.sun.com on Thu, Mar 08, 2001 at 09:49:47PM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list Another old message related to the keyboard-interactive draft. (I believe the first occurence of a langauge tag was in that draft.) On Thu, Mar 08, 2001 at 09:49:47PM -0500, Bill Sommerfeld wrote: > [no attribution: ] > > Are the drafts saying that I should send the language tag the client > > and server agreed on at SSH_MSG_KEXINIT time as every message is > > sent ? > > one possible rationale has occurred to me: > > Even if the peers negotiated that all messages will be in, say, > martian, the server might not have translations for all possible > messages, and might need to send some messages in a "default" > language, in which case it should be tagged as such so it gets > displayed appropriately (e.g., not using martian letters). But isn't that impossible with UTF-8 encodings? The client cannot display the wrong letters (although it may not be able to display the letters at all). I am not that familiar with multi-byte encodings, but that is my understanding. Please clarify. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 17 20:47:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17177 for ; Thu, 17 Jan 2002 20:47:49 -0500 (EST) Received: (qmail 23881 invoked by uid 605); 18 Jan 2002 01:47:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23874 invoked from network); 18 Jan 2002 01:47:46 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 18 Jan 2002 01:47:46 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id RAA32548; Thu, 17 Jan 2002 17:47:45 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id RAA05922; Thu, 17 Jan 2002 17:47:45 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g0I1lj704324; Thu, 17 Jan 2002 17:47:45 -0800 Date: Thu, 17 Jan 2002 17:47:45 -0800 From: Frank Cusack To: Darren Moffat Cc: ietf-ssh@netbsd.org Subject: Re: Using PAM an the SSH Protocol Message-ID: <20020117174745.O3039@google.com> References: <200104112151.f3BLpeB2263903@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200104112151.f3BLpeB2263903@jurassic.eng.sun.com>; from Darren.Moffat@eng.sun.com on Wed, Apr 11, 2001 at 02:51:33PM -0700 Sender: ietf-ssh-owner@netbsd.org Precedence: list Perhaps this has been addressed in some other way, but I'll add my much delayed 0.02 anyway. I've quoted a lot more of the discussion than I would normally since it's so old. On Wed, Apr 11, 2001 at 02:51:33PM -0700, Darren Moffat wrote: > Some of you may have noticed that SSH Communications Security has > announced support for PAM (Pluggable Authentication Modules) in its > latest Windows platform clients and support for PAM first appeared in > their 2.4.0 product. OpenSSH also has support for PAM in the portable > release. > > PAM was originally developed by Sun Microsystems Inc (details at: > http://sun.com/solaris/pam) as a means of abstracting out of programs > like login and telnetd the user interaction required to authenticate > the user, decide (based on access control policies) if they should > access the system at this time and then setup their local credentials. > > At the present time there are (at least) two different methods of using > PAM in the currently available SSH protocol implementations. > > In the SSH Communications Security implementation the client and server > must agree to use the authentication method "pam-1@ssh.com" otherwise > no PAM code is run. > > In the OpenSSH implementation PAM is used to authenticate the user if > Keyboard Interactive is used (I'm talking about v2 protocol support, I > know it is slightly different in v1). Regardless of wither or not > Keyboard Interactive authentiation is run the PAM functions that deal > with account management (pam_acct_mgmt) and setting of credentials > (pam_setcred) are always run. It is worth noting that regular password auth uses PAM now also. > What does this mean ? > > If I have a client connecting to an SSH Communications Security server > that does not understand (or chooses not to send) "pam-1@ssh.com" as > an authentication mechanism then the PAM functionality for pam_acct_mgmt > will not get run. pam_acct_mgmt is responsible for makeing decisions on > wither this user (who is authenticated, either by pam_authenticate or > by other means) is actually allowed to access the system via this service > at this time. > > Compare this with the OpenSSH implmentation where pam_acct_mgmt will always > be run so the access restrictions will be correctly enforced. > > > So isn't this an implmenation issue ? Yes. > Tatu and I had a short discussion on this today and decided that at the > present time we are not sure, there may be protocol issues, it might > be that keyboard interactive can't solves them all, it might be limitations > in PAM, or something else. > > One thing I am positive about is that if a particular server for > the SSH protocol wants PAM to be used there should be no means for the > client to by pass the access controls regardless of which SSH protocol > authentication is used. Put another way PAM as a framework should not > be visible to clients; it was only ever intended to be a server side > implementation framework not a network protocol or an authentication > mechanism in its own right (pam-1@ssh.com make it an auth mech). > > > Why am I bringing this up on ietf-ssh ? > > I want to gather people who are interesting in helping solve this problem > possible out comes are that there are defiencies in the core SSH protocol, > Keyboard Interactive isn't enough to solve all PAM issues, PAM doesn't > fit well with protocols like SSH (if it is the later then my goal would > be to come up with some best practices on how it can be used and what > limitations there are), or may be it is an implmenation issue - but it is > important because at the moment there are interop problems that have > potential security vulnerabilities in the view of system admins. keyboard-interactive is capable of fully interacting with PAM. It was, in fact, designed based on an sshd using PAM. Is "pam-1@ssh.com" still in use? That would be most unfortunate, it breaks one of the things kbdint was meant to solve: client knowledge of the authentication mechanism. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 17 21:03:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17472 for ; Thu, 17 Jan 2002 21:03:09 -0500 (EST) Received: (qmail 25173 invoked by uid 605); 18 Jan 2002 02:03:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25166 invoked from network); 18 Jan 2002 02:03:04 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 18 Jan 2002 02:03:04 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id SAA01239; Thu, 17 Jan 2002 18:03:04 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id SAA12458; Thu, 17 Jan 2002 18:03:04 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g0I234A04341; Thu, 17 Jan 2002 18:03:04 -0800 Date: Thu, 17 Jan 2002 18:03:04 -0800 From: Frank Cusack To: Darren Moffat , ietf-ssh@netbsd.org Subject: Re: Comments for draft-ietf-secsh-auth-kbdinteract-01.txt Message-ID: <20020117180304.P3039@google.com> References: <200012190328.eBJ3Shm155590@jurassic.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200012190328.eBJ3Shm155590@jurassic.eng.sun.com>; from Darren.Moffat@Eng.Sun.COM on Mon, Dec 18, 2000 at 07:28:43PM -0800 Sender: ietf-ssh-owner@netbsd.org Precedence: list OK, this is the last of the old kbdint messages which I think still could stand some addt'l comment. On Mon, Dec 18, 2000 at 07:28:43PM -0800, Darren Moffat wrote: > > The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE > >message > > if the failure is based on the user name or service name; instead > >it > > SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look > >just > > like the one(s) which would have been sent in cases where > > authentication should proceed, and then send the failure message > > (after a suitable delay, as described below). The goal is to make > >it > > impossible to find valid user names by just comparing the results > > when authenticating as different users. > > I think the goal here is basically sound, however as you point out > this SHOULD NOT may actually be hard to implement in some cases, but > being a SHOULD NOT rather than a MUST means that if it is too hard for > a particular system then it can reply SSH_MSG_USERAUTH_FAILURE > > >This is not good, as the server doesn't necessarily have a method to > >get the possible messages from a device (library etc.). For example, > >we don't know what PAM would query from the user if it existed. PAM > >doesn't allow invalid users to continue the login after account > >checkin. Point being, with PAM the server shouldn't take any stand on > >what the PAM queries or tells the users; this depends on the PAM > >configuration. > > Whither or not PAM is used in a particular secsh server side is an > implmentation detail, but it is an important one because using PAM > opens up the scope for messages and interaction outside of the control > of the ssh server software. And this bears mentioning, if using PAM this is trivially easy; any PAM module (that prompts for information) has this same design consideration. If backended by PAM, sshd shouldn't really do anything special. IE, if PAM fails without sending any kind of prompt, then sshd shouldn't add an artificial prompt. But if sshd is doing the auth "natively" and finds "no user" it SHOULD still prompt the user. > It actually depends on exactly how PAM is used how difficult this > becomes to implement. Personally I would say that if PAM is being > used: > pam_authenticate() > PAM_SUCCESS => SSH_MSG_USERAUTH_SUCCESS > PAM_USER_UNKNOWN => SSH_MSG_USERAUTH_FAILURE > PAM_NEW_AUTHTOK_REQD => call pam_chauthtok() and > send SSH_MSG_USERAUTH_SUCCESS if it returns > PAM_SUCCESS otherwise SSH_MSG_USERAUTH_FAILURE > Most others result in SSH_MSG_USERAUTH_FAILURE. > > I guess it depends on exactly how you see PAM and kbdinteract > working together. The way I see it is that any converstaion that PAM > does with the user is one kbdinteract "session" regardless of how many > PAM modules actually get run - since there is no (supported) way for the PAM > application to get information about which modules succeed and which > fail or to run only certain modules. > > I suspect that in many cases things like Engima Safeword and Securid > will actuall get implmented as PAM modules rather than coded directly > into the secsh server software. Or at least the should be for systems > that support PAM to avoid code duplication. > > I think what is needed here is an informational draft on how PAM > and kdbinteract are used with each other. While it is good that we > consider PAM in this draft I don't think kdinteract should depend on > it or make specific consessions for it (For those that know how much > I advocate using PAM that is quite a consession from me!). I hope you feel differently now. :-) PAM is a good thing. It's not perfect, but it is better than what existed before. kbdint was designed specifically with PAM in mind, I am of the opinion that yes, specific concessions should in fact be made for PAM. > To back this up futher the example in the draft of a user changing > their password couldn't be coded that way using PAM since you don't > know what modules in the PAM stack are going to prompt you in advance, > it may be that the password fails some strength checks between the > inital user entry and the re-entering and the output of the error > message is dependant on what the user typed. > > But the draft as it stands is sufficiently flexible to allow for an > implmentation with PAM since the interaction would be a series of single > prompt messages. I just don't see the point in the added complexity > of allowing for multiple prompts. PAM modules can send multiple prompts. The standard example is the change password prompt. It's MUCH better to send this as a single protocol exchange so that a GUI client can present a more sensible dialog. With two seperate exchanges, the messages are disconnected from each other (what does "enter it again" mean in the second exchange?). > IIRC there was also disussion in the wg meeting last week about removing > the ablity to send multiple prompts in one SSH_MSG_USERAUTH_INFO_REQUEST > can someone remind me on the consensus of that (if there was one) ? I > seem to remeber someone saying something that it helped them implement > PAM support on the server (I can't see how this would be the case since > the PAM framework doesn't support multiple prompts for input with out > user feedback - it maybe someone has a module that does something like > this but the PAM framework doesn't require it). Sure it does (both support and require it). /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 18 08:01:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09143 for ; Fri, 18 Jan 2002 08:01:56 -0500 (EST) Received: (qmail 16094 invoked by uid 605); 18 Jan 2002 13:01:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16086 invoked from network); 18 Jan 2002 13:01:52 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 18 Jan 2002 13:01:52 -0000 Received: from localhost (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id E824F67103; Fri, 18 Jan 2002 08:15:37 -0500 (EST) Date: Fri, 18 Jan 2002 08:01:35 -0500 Subject: Re: Section 3.2 of secsh-auth-kbdinteract-01 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: ietf-ssh@netbsd.org To: Frank Cusack From: RJ Atkinson In-Reply-To: <20020117171824.M3039@google.com> Message-Id: <80CC657A-0C13-11D6-8DA6-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, January 17, 2002, at 08:18 PM, Frank Cusack wrote: > On Tue, Dec 19, 2000 at 11:19:32AM +0100, Martin Forssen wrote: >> On 18 Dec, Darren Moffat wrote: >>>> Section 3.2: >>> >>>> The server SHOULD limit the length of the name and prompt fields to >>>> 30 characters. No restrictions are placed on the instruction >>>> field. >>>> >>>> 30 characters could be too little. >>>> >>>> "sjl@foobar.internal.fi.ssh.com's passcode for SecurID auth:" >>>> >>>> especially considering section 3.3 considerations >>> >>> Agreed where did 30 come from ? (I'll take a wild guess here and >>> assume it is the number of chars that can be displayed on the screen >>> of a PalmPilot using the default font? (I checked ;-)) >> >> I think I already have countered this example, ut I just wanted to >> comment on the number 30. The number 30 is just an arbitrary number and >> I am not aware of any systems which actually enforces those limits. > > 30 does seem an odd number[1]. I don't recall the exact device (probably > Palm) but I do believe it was in fact based on some minimal screen width > limitation. The reason the name and prompt fields were limited is b/c > they are expected to be printed on a single line. IMHO, either the advice "SHOULD be limited to 30 characters" ought to be deleted xor that should be edited to a much more reasonable value than 30. Given that most systems, even a Palm, can wrap lines, it isn't clear to me that any limit is needed. And "user@domain" strings can be VERY long. I regularly see long strings (not least since the domain at my office is: va.extremenetworks.com, with a hostname and username being prepended to that for SSH purposes :-) Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 18 08:04:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09198 for ; Fri, 18 Jan 2002 08:04:01 -0500 (EST) Received: (qmail 16465 invoked by uid 605); 18 Jan 2002 13:03:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16456 invoked from network); 18 Jan 2002 13:03:59 -0000 Received: from inet.org (HELO gnat.inet.org) (63.108.254.91) by mail.netbsd.org with SMTP; 18 Jan 2002 13:03:59 -0000 Received: from localhost (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 086B567103; Fri, 18 Jan 2002 08:17:59 -0500 (EST) Date: Fri, 18 Jan 2002 08:03:56 -0500 Subject: Re: message lang tags verse SSH_MSG_KEXINIT Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: ietf-ssh@netbsd.org To: Frank Cusack From: RJ Atkinson In-Reply-To: <20020117173417.N3039@google.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thursday, January 17, 2002, at 08:34 PM, Frank Cusack wrote: > But isn't that impossible with UTF-8 encodings? The client cannot display > the wrong letters (although it may not be able to display the letters > at all). I am not that familiar with multi-byte encodings, but that > is my understanding. Please clarify. If a display can only display US-ASCII and it is confronted with a vowel containing a German umlaut, the display might well show the vowel without the umlaut -- right ? Not clear to me how UTF-8 encoding changes those sorts of functional limits, particularly limits in older boxen. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 18 12:10:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19146 for ; Fri, 18 Jan 2002 12:10:35 -0500 (EST) Received: (qmail 28878 invoked by uid 605); 18 Jan 2002 17:10:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28871 invoked from network); 18 Jan 2002 17:10:33 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 18 Jan 2002 17:10:33 -0000 Received: from sunmail1.Sun.COM ([129.145.1.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12336 for ; Fri, 18 Jan 2002 10:10:32 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.88.130]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id JAA13456 for ; Fri, 18 Jan 2002 09:11:47 -0800 (PST) Received: from brora (brora.Eng.Sun.COM [129.146.81.131]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g0IHAUqT974240 for ; Fri, 18 Jan 2002 09:10:30 -0800 (PST) Message-Id: <200201181710.g0IHAUqT974240@jurassic.eng.sun.com> Date: Fri, 18 Jan 2002 09:10:30 -0800 (PST) From: Darren Moffat Reply-To: Darren Moffat Subject: Re: Using PAM an the SSH Protocol To: ietf-ssh@netbsd.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SEeY8z/5vhuCHlUU0GfP1Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5_54 SunOS 5.9 sun4u sparc Sender: ietf-ssh-owner@netbsd.org Precedence: list >keyboard-interactive is capable of fully interacting with PAM. It was, >in fact, designed based on an sshd using PAM. Is "pam-1@ssh.com" still >in use? That would be most unfortunate, it breaks one of the things >kbdint was meant to solve: client knowledge of the authentication >mechanism. I believe that pam-1@ssh.com is still in use. If some one from SSH Communications is listening can you tells us if you plan to rectify this ? -- Darren J Moffat From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 18 13:14:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21709 for ; Fri, 18 Jan 2002 13:14:50 -0500 (EST) Received: (qmail 8078 invoked by uid 605); 18 Jan 2002 18:14:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8071 invoked from network); 18 Jan 2002 18:14:43 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 18 Jan 2002 18:14:43 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.9.3/8.9.3) with ESMTP id KAA20972; Fri, 18 Jan 2002 10:14:43 -0800 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.9.3/8.9.3) with ESMTP id KAA00732; Fri, 18 Jan 2002 10:14:43 -0800 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g0IIEgc06402; Fri, 18 Jan 2002 10:14:42 -0800 Date: Fri, 18 Jan 2002 10:14:42 -0800 From: Frank Cusack To: RJ Atkinson Cc: ietf-ssh@netbsd.org Subject: Re: Section 3.2 of secsh-auth-kbdinteract-01 Message-ID: <20020118101442.H6348@google.com> References: <20020117171824.M3039@google.com> <80CC657A-0C13-11D6-8DA6-00039357A82A@extremenetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <80CC657A-0C13-11D6-8DA6-00039357A82A@extremenetworks.com>; from rja@extremenetworks.com on Fri, Jan 18, 2002 at 08:01:35AM -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Jan 18, 2002 at 08:01:35AM -0500, RJ Atkinson wrote: > > On Thursday, January 17, 2002, at 08:18 PM, Frank Cusack wrote: > > > On Tue, Dec 19, 2000 at 11:19:32AM +0100, Martin Forssen wrote: > >> On 18 Dec, Darren Moffat wrote: > >>>> Section 3.2: > >>> > >>>> The server SHOULD limit the length of the name and prompt fields to > >>>> 30 characters. No restrictions are placed on the instruction > >>>> field. > >>>> > > > > 30 does seem an odd number[1]. I don't recall the exact device (probably > > Palm) but I do believe it was in fact based on some minimal screen width > > limitation. The reason the name and prompt fields were limited is b/c > > they are expected to be printed on a single line. > > IMHO, either the advice "SHOULD be limited to 30 characters" ought to be > deleted xor that should be edited to a much more reasonable value than 30. > Given that most systems, even a Palm, can wrap lines, it isn't clear to me > that any limit is needed. And "user@domain" strings can be VERY long. The 'name' field is intended to be the window title on GUI clients. The window title has a limited number of characters that can usefully be displayed. If the name is important (eg, tells the user what device to use out of several he has) and is 256 characters but the client is forced to truncate (or the window toolkit just truncates) that important info is lost. A similar argument exists for the prompt fields. So I do not agree with you that no limit is needed, however at the same time it is clear that strings can be very long. /fc From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 18 16:41:41 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28194 for ; Fri, 18 Jan 2002 16:41:40 -0500 (EST) Received: (qmail 20951 invoked by uid 605); 18 Jan 2002 21:38:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20944 invoked from network); 18 Jan 2002 21:38:53 -0000 Received: from mxout1.cac.washington.edu (140.142.32.5) by mail.netbsd.org with SMTP; 18 Jan 2002 21:38:53 -0000 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.12]) by mxout1.cac.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g0ILcqUC031527 for ; Fri, 18 Jan 2002 13:38:52 -0800 Received: from D-140-142-21-15.dhcp2.washington.edu (D-140-142-21-15.dhcp2.washington.edu [140.142.21.15]) (authenticated bits=0) by smtp.washington.edu (8.12.1+UW01.12/8.12.1+UW02.01) with ESMTP id g0ILcpJU017401 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 18 Jan 2002 13:38:52 -0800 Date: Fri, 18 Jan 2002 13:39:41 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perx.cac.washington.edu Reply-To: "RL 'Bob' Morgan" To: IETF ssh WG Subject: ssh, x.509v3 certificates, and PKCS-7 ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list The message below seems to be the last one on the list on this topic. I seem to also recall consensus at the August 2001 meeting to use PKCS-7 format for this. But transport-11 doesn't mention this; its language appears unchanged from that in transport-09 (and maybe before). Does the issue Joseph raises below remain unaddressed? - RL "Bob" ---------- Forwarded message ---------- Date: Tue, 7 Aug 2001 14:29:43 +0100 From: Joseph Galbraith To: ietf-ssh@netbsd.org Subject: x.509v3 certificates... **** **** I've included the algorithm string **** in key packet clarification here even though we **** forgot to talk about it in the meeting. Please, **** comment! **** **** That's the part where it says: **** string "x509v3-*" **** string x.509v3 compatible der encoded certificate data **** In the meeting we talked about x.509v3 certificates -- the problem is that when using smart cards, you don't always have control over the hash algorithm used. So, we decided to change x.509v3 certificates to use pkcs7 signatures, because otherwise, there is no way to know what hashing algorithm was used. As promised, here is the text. Please comment on the changes -- silence means everyone agrees with me, right? Thanks, Joseph Galbraith galb-list@vandyke.com --------- Transport draft, Section 4.6 (We might want to number the different sections of this, so that ssh-dss becomes 4.6.1, ssh-rsa becomes 4.6.2, and x509v3-* becomes 4.6.3) 4.6.3 x.509v3 certificates The "x509v3-*" methods indicate that the certificates, the public key, and the resulting signature are in X.509v3 compatible DER-encoded format. The formats used in X.509v3 are described in [RFC2459]. The formats used for signatures are described in [PKCS7]. Note, that there is no such algorithm as "x509v3-*", but the * is used only in this document to denote all algorithms beginning with x509v3. There are currently two such algorithms defined: x509v3-sign-rsa RECOMMENDED sign X.509 certificates (RSA key) x509v3-sign-dss RECOMMENDED sign X.509 certificates (DSS key) The "x509v3-*" key format has the following generic encoding: string "x509v3-*" string x.509v3 compatible der encoded certificate data The resulting signature is encoded as follows: string "pkcs7" string PKCS-7 signature, DER encoded The "x509v3-sign-rsa" method indicates that the key (or one of the keys in the certificate) is an RSA-key. The "x509v3-sign-dss". As above, but indicates that the key (or one of the keys in the certificate) is a DSS-key. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Jan 18 22:41:41 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05609 for ; Fri, 18 Jan 2002 22:41:40 -0500 (EST) Received: (qmail 26038 invoked by uid 605); 19 Jan 2002 03:41:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26031 invoked from network); 19 Jan 2002 03:41:38 -0000 Received: from unknown (HELO pect.co.kr) (203.228.115.224) by mail.netbsd.org with SMTP; 19 Jan 2002 03:41:38 -0000 Received: from bcjj.com ([64.86.192.78]) by pect.co.kr (AIX4.3/8.9.3/8.9.3) with SMTP id MAA20458; Sat, 19 Jan 2002 12:40:14 +0900 Date: Sat, 19 Jan 2002 12:40:14 +0900 Message-ID: <2d03637b$7932$6565> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_24778_17776_663.AF778020382" To: "gpvclvd@dgzv.com" From: "" Reply-to: dvdburner@ewasher.org Subject: DVD Copier Sender: ietf-ssh-owner@netbsd.org Precedence: list ------=_NextPart_24778_17776_663.AF778020382 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit COPY YOUR DVD's!! Why Spend upwards of $4000 on a DVD Burner when we will show you an alternative that will do the exact same thing for only $19.95? You heard us right - for the price of just 1 DVD's, we'll show you how to back up and/or create Your Own DVD's! Just upgraded to a DVD and still have a ton of VHS tapes lying around? With this program, not only can you burn & copy any DVD you've created, you'll also be able to transfer all your VHS tapes to DVD format as well!! You want to know more? Visit us at http://www.copydvd.net 2ff1a02660c66da382e658c1f6968bf5d685545 ------=_NextPart_24778_17776_663.AF778020382-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 21 04:27:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03211 for ; Mon, 21 Jan 2002 04:27:10 -0500 (EST) Received: (qmail 26798 invoked by uid 605); 21 Jan 2002 09:27:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26791 invoked from network); 21 Jan 2002 09:27:02 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 21 Jan 2002 09:27:02 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id KAA16394; Mon, 21 Jan 2002 10:26:15 +0100 (MET) Date: Mon, 21 Jan 2002 10:26:15 +0100 From: Markus Friedl To: Nicolas Williams Cc: Tobias Ringstrom , mouring@etoh.eviladmin.org, Kevin Steves , openssh-unix-dev@mindrot.org, ietf-ssh@netbsd.org Subject: Re: [PATCH] Using TCP_NODELAY unconditionally Message-ID: <20020121092615.GA16347@faui02> References:

<20020121004135.I27171@sm2p1386swk.wdr.com> <20020121092428.GF14658@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020121092428.GF14658@faui02> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Mon, Jan 21, 2002 at 10:24:28AM +0100, Markus Friedl wrote: > On Mon, Jan 21, 2002 at 12:41:37AM -0500, Nicolas Williams wrote: > > Since the protocol allows a variety of kinds of traffic to be exchanged > > over a TCP connection, some which should be used with Nagle, and some > > which shouldn't, the protocol should really be capable of implementing > > Nagle on a per-channel basis and always run with TCP_NODELAY, but that's > > a lot easier said than done. > > ietf-ssh is the place for this. ietf-ssh@netbsd.org From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 21 05:15:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04073 for ; Mon, 21 Jan 2002 05:15:54 -0500 (EST) Received: (qmail 820 invoked by uid 605); 21 Jan 2002 10:15:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 813 invoked from network); 21 Jan 2002 10:15:49 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 21 Jan 2002 10:15:49 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 6BED1835D9A; Mon, 21 Jan 2002 11:15:47 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id LAA15735; Mon, 21 Jan 2002 11:15:46 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: ietf-ssh@netbsd.org Subject: ssh-agent protocol Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 21 Jan 2002 11:15:45 +0100 Message-ID: Lines: 148 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Hi, Markus asked me to post this information to the list. It's an inofficial description of the ssh-agent protocol, written by Balazs Scheidler. Back then, I expected the SSH folks to publish an official spec on ssh-agent "soon", but now two years have passed and this is still the best information on ssh-agent I have seen. I have some concerns about the security in ssh-agent, and I think improvements are possible, if one also creates a new better publickey userauth methods that signs some more information. But before doing anything about that, we first need to understand the details of the current ssh-agent mechanism. Regards, /Niels : Date: Fri, 5 Nov 1999 20:29:59 +0100 : From: Balazs Scheidler : To: Niels Moller : Subject: ssh-agent protocol : Message-ID: <19991105202959.A5028@balabit.hu> [ ... deletia ...] : SSH-AGENT requests and replies : : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_REQUEST_VERSION(1) : : reply: : byte SSH_AGENT_VERSION_RESPONSE(103) : UINT32 version : : The version field contains 2 for ssh-agent2, and presumably 1 for : ssh-agent1. : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_ADD_KEY(202) : string private : string public : string description : UINT8[] constraint data : : constraint data is an encoded part in the form attribute,value, where : attribute can be one of the following: : : #define SSH_AGENT_CONSTRAINT_OLD_TIMEOUT 1 : #define SSH_AGENT_CONSTRAINT_OLD_USE_LIMIT 2 : #define SSH_AGENT_CONSTRAINT_OLD_FORWARDING_STEPS 3 : #define SSH_AGENT_CONSTRAINT_OLD_FORWARDING_PATH 4 : #define SSH_AGENT_CONSTRAINT_OLD_COMPAT 5 : #define SSH_AGENT_CONSTRAINT_OLD_STATUS 6 : #define SSH_AGENT_CONSTRAINT_TIMEOUT 50 : #define SSH_AGENT_CONSTRAINT_USE_LIMIT 51 : #define SSH_AGENT_CONSTRAINT_FORWARDING_STEPS 52 : #define SSH_AGENT_CONSTRAINT_FORWARDING_PATH 100 : #define SSH_AGENT_CONSTRAINT_COMPAT 150 : #define SSH_AGENT_CONSTRAINT_STATUS 53 : : Different constraint codes may involve different encoding structures. : : reply: : byte SSH_AGENT_SUCCESS or SSH_AGENT_ERROR_FAILURE : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_DELETE_ALL_KEYS : : reply: : byte SSH_AGENT_SUCCESS or SSH_AGENT_ERROR_FAILURE : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_LIST_KEYS(204) : : reply : byte SSH_AGENT_KEY_LIST(104) : UINT32 number of keys (=n) : string certificates ] one pair for each key : string description ] : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_PRIVATE_KEY_OP(205) : string op-name : string public keyblob : op-name dependent parameters : : reply: : byte SSH_AGENT_SUCCESS or SSH_AGENT_ERROR_FAILURE : : possible operations: : : 1) "sign" ask the agent to sign some data : : parameters: : string blob to sign : : 2) "hash-and-sign" ask the agent to hash & sign some data : : parameters: : string blob to sign : : 3) "decrypt" ask the agent to decrypt the given blob : : parameters: : string blob to decrypt : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_FORWARDING_NOTICE (206) : string forwarding host name : string ??? : UINT32 port : : reply: : no reply : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_DELETE_KEY (207) : string public blob : string description : : reply: : byte SSH_AGENT_SUCCESS or SSH_AGENT_ERROR_FAILURE : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_LOCK (208) : string password : : reply: : byte SSH_AGENT_SUCCESS or SSH_AGENT_ERROR_FAILURE : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_UNLOCK (209) : string password : : reply: : byte SSH_AGENT_SUCCESS or SSH_AGENT_ERROR_FAILURE : ---------------------------------------------------------------------- : request: : byte SSH_AGENT_PING : arbitrary data : : reply: : byte SSH_AGENT_ALIVE : arbitrary data returned : ---------------------------------------------------------------------- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 21 06:04:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05007 for ; Mon, 21 Jan 2002 06:04:22 -0500 (EST) Received: (qmail 5497 invoked by uid 605); 21 Jan 2002 11:04:21 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5490 invoked from network); 21 Jan 2002 11:04:18 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 21 Jan 2002 11:04:18 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id MAA22794; Mon, 21 Jan 2002 12:04:14 +0100 (MET) Date: Mon, 21 Jan 2002 12:04:14 +0100 From: Markus Friedl To: Darren J Moffat Cc: ietf-ssh@netbsd.org Subject: Re: SSH agent forwarding Message-ID: <20020121110414.GA22685@faui02> References: <200111121959.fACJxiei469279@jurassic.eng.sun.com> <20020114221337.A9089@folly> <3C434D04.8090203@Sun.COM> <20020114213324.GA2054@faui02> <3C434FE3.80202@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3C434FE3.80202@Sun.COM> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Since there was no documentation about a protocol v2 agent protocol, OpenSSH uses a quick hack and private extensions to the protocol used by the ssh-1.2.x implementations. The protocol v1 agent protocol works as documented below. #define SSH2_AGENTC_REQUEST_IDENTITIES 11 #define SSH2_AGENT_IDENTITIES_ANSWER 12 #define SSH2_AGENTC_SIGN_REQUEST 13 #define SSH2_AGENT_SIGN_RESPONSE 14 #define SSH2_AGENTC_ADD_IDENTITY 17 #define SSH2_AGENTC_REMOVE_IDENTITY 18 #define SSH2_AGENTC_REMOVE_ALL_IDENTITIES 19 #define SSH_AGENTC_ADD_SMARTCARD_KEY 20 #define SSH_AGENTC_REMOVE_SMARTCARD_KEY 21 SSH2_AGENTC_REQUEST_IDENTITIES SSH2_AGENT_IDENTITIES_ANSWER uint32 n string publickey1 string comment1 ... string publickeyn string commentn SSH2_AGENTC_SIGN_REQUEST string pubkey string data uint32 flags SSH2_AGENT_SIGN_RESPONSE string signature_blob SSH2_AGENTC_ADD_IDENTITY string type (ssh-rsa or ssh-dss) payload depends on keytype, [XXX should be wrapped in a string] for ssh-rsa mpint n mpint e mpint d mpint iqmp mpint p mpint q for ssh-dss mpint p mpint q mpint g mpint pub_key mpint priv_key string comment SSH2_AGENTC_REMOVE_IDENTITY string publickey1 SSH2_AGENTC_REMOVE_ALL_IDENTITIES SSH_AGENTC_ADD_SMARTCARD_KEY string cardid SSH_AGENTC_REMOVE_SMARTCARD_KEY string cardid a public key: string pubkey is always encoded as: string "ssh-rsa" mpint e mpint n or string "ssh-dss" mpint p mpint q mpint g mpint y so the complete public key info is wrapped in a string. --- see http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/RFC.nroff?rev=1.2 Ylonen Internet-Draft SSH (Secure Shell) Remote Login Protocol 15 November 1995 The Authentication Agent Protocol The authentication agent is a program that can be used to hold RSA authentication keys for the user (in future, it might hold data for other authentication types as well). An authorized program can send requests to the agent to generate a proper response to an RSA challenge. How the connection is made to the agent (or its representative) inside a host and how access control is done inside a host is implementation- dependent; however, how it is forwarded and how one interacts with it is specified in this protocol. The connection to the agent is normally automatically forwarded over the secure channel. A program that wishes to use the agent first opens a connection to its local representative (typically, the agent itself or an SSH server). It then writes a request to the connection, and waits for response. It is recommended that at least five minutes of timeout are provided waiting for the agent to respond to an authentication challenge (this gives suf� ficient time for the user to cut-and-paste the challenge to a separate machine, perform the computation there, and cut-and-paste the result back if so desired). Messages sent to and by the agent are in the following format: 4 bytes Length, msb first. Does not include length itself. 1 byte Packet type. The value 255 is reserved for future extensions. data Any data, depending on packet type. Encoding as in the ssh packet protocol. The following message types are currently defined: 1 SSH_AGENTC_REQUEST_RSA_IDENTITIES (no arguments) Requests the agent to send a list of all RSA keys for which it can answer a challenge. 2 SSH_AGENT_RSA_IDENTITIES_ANSWER 32-bit int howmany howmany times: 32-bit int bits mp-int public exponent mp-int public modulus string comment The agent sends this message in response to the to SSH_AGENTC_REQUEST_RSA_IDENTITIES. The answer lists all RSA keys for which the agent can answer a challenge. The comment field is intended to help identify each key; it may be printed by an appli� cation to indicate which key is being used. If the agent is not holding any keys, howmany will be zero. 3 SSH_AGENTC_RSA_CHALLENGE 32-bit int bits mp-int public exponent mp-int public modulus mp-int challenge 16 bytes session_id 32-bit int response_type Requests RSA decryption of random challenge to authenticate the other side. The challenge will be decrypted with the RSA private key corresponding to the given public key. The decrypted challenge must contain a zero in the highest (par� tial) byte, 2 in the next byte, followed by non-zero random bytes, a zero byte, and then the real challenge value in the lowermost bytes. The real challenge must be 32 8-bit bytes (256 bits). Response_type indicates the format of the response to be returned. Currently the only supported value is 1, which means to compute MD5 of the real challenge plus session id, and return the resulting 16 bytes in a SSH_AGENT_RSA_RESPONSE message. 4 SSH_AGENT_RSA_RESPONSE 16 bytes MD5 of decrypted challenge Answers an RSA authentication challenge. The response is 16 bytes: the MD5 checksum of the 32-byte challenge. 5 SSH_AGENT_FAILURE (no arguments) This message is sent whenever the agent fails to answer a request properly. For example, if the agent cannot answer a challenge (e.g., no longer has the proper key), it can respond with this. The agent also responds with this message if it receives a message it does not recognize. 6 SSH_AGENT_SUCCESS (no arguments) This message is sent by the agent as a response to certain requests that do not otherwise cause a message be sent. Currently, this is only sent in response to SSH_AGENTC_ADD_RSA_IDENTITY and SSH_AGENTC_REMOVE_RSA_IDENTITY. 7 SSH_AGENTC_ADD_RSA_IDENTITY 32-bit int bits mp-int public modulus mp-int public exponent mp-int private exponent mp-int multiplicative inverse of p mod q mp-int p mp-int q string comment Registers an RSA key with the agent. After this request, the agent can use this RSA key to answer requests. The agent responds with SSH_AGENT_SUCCESS or SSH_AGENT_FAILURE. 8 SSH_AGENT_REMOVE_RSA_IDENTITY 32-bit int bits mp-int public exponent mp-int public modulus Removes an RSA key from the agent. The agent will no longer accept challenges for this key and will not list it as a supported iden� tity. The agent responds with SSH_AGENT_SUCCESS or SSH_AGENT_FAIL� URE. If the agent receives a message that it does not understand, it responds with SSH_AGENT_FAILURE. This permits compatible future extensions. It is possible that several clients have a connection open to the authentication agent simultaneously. Each client will use a separate connection (thus, any SSH connection can have multiple agent connections active simultaneously). From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 21 06:41:30 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05956 for ; Mon, 21 Jan 2002 06:41:30 -0500 (EST) Received: (qmail 20596 invoked by uid 605); 21 Jan 2002 11:41:01 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20569 invoked from network); 21 Jan 2002 11:40:58 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 21 Jan 2002 11:40:58 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.12 #1 (Debian)) id 16Scob-0002df-00; Mon, 21 Jan 2002 11:40:41 +0000 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: Subject: Re: ssh-agent protocol Message-Id: Date: Mon, 21 Jan 2002 11:40:41 +0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Niels M�ller wrote: > Markus asked me to post this information to the list. It's an > inofficial description of the ssh-agent protocol [...] > : ---------------------------------------------------------------------- > : request: > : byte SSH_AGENT_REQUEST_VERSION(1) > : > : reply: > : byte SSH_AGENT_VERSION_RESPONSE(103) > : UINT32 version > : > : The version field contains 2 for ssh-agent2, and presumably 1 for > : ssh-agent1. I'm not sure this is quite right. I tried making my own observations of the ssh-agent2 protocol once, and came up with slightly different conclusions. In ssh-agent1, an empty message-type-1 is not a version request at all: it's SSH_AGENTC_REQUEST_RSA_IDENTITIES, and the response from ssh-agent1 is a list of public keys. If I recall my own analysis correctly, the ssh-agent2 version request is a message-type-1 which _does_ contain something. Then you have some options: - if the agent responds to a version request by returning an ssh-agent1 list of keys, you know it doesn't understand the agent2 protocol at all. - if it returns SSH_AGENT_VERSION_RESPONSE then you know it can act as an agent2; you can then send it an _empty_ message-type-1 and see what it says to that. If it responds to _that_ with an ssh-agent1 list of keys then it's able to act as a two-in-one agent1 and agent2. (A double agent? :-) IIRC the snag is that earlier ssh2 agent clients do expect an empty message-type-1 to provoke an agent2 version response, so to interoperate with these older clients you would want to be able to disable ssh-agent1 behaviour in a decently configurable agent. It's nice to see that the OpenSSH agent2 message numbers are completely disjoint from the ssh.com ones, though; at least there'll be no problem with running both of those agent protocols in parallel! Cheers, Simon -- Simon Tatham "The difference between theory and practice is that, in theory, there is no difference." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Jan 21 17:03:02 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26468 for ; Mon, 21 Jan 2002 17:03:01 -0500 (EST) Received: (qmail 29133 invoked by uid 605); 21 Jan 2002 22:02:40 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20020121220240.29132.qmail@mail.netbsd.org> Cc: recipient list not shown: ; Received: (qmail 29101 invoked from network); 21 Jan 2002 22:02:31 -0000 Received: from unknown (HELO Office) (80.33.147.27) by mail.netbsd.org with SMTP; 21 Jan 2002 22:02:31 -0000 From: Caliente Reply-To: stinger@step.es Subject: Caliente Hot Heiss Date: Mon, 21 Jan 2002 22:02:30 +0000 X-Mailer: 007 Direct Email Easy MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="92b45989-1a8e-4458-8c2f-9dbc22a16567" Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format --92b45989-1a8e-4458-8c2f-9dbc22a16567 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hola chico Lindo!!!, Te queremos invitar a que nos visites a nuestra primera pagina web porno hecha por nosotras mismas!! QUEREMOS TU APOYO Y CALOR!!! POR SUPUESTO = ES TOTALMENTE GRATIS!! Visitanos que te esperamos con mas que los brazos abiertos ;) Haz click en la = direccion web abajo: WWW.EXTREEM.COM No olvides de colocarnos en tus favoritos! WWW.EXTREEM.COM --92b45989-1a8e-4458-8c2f-9dbc22a16567-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 01:59:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA04671 for ; Tue, 22 Jan 2002 01:59:23 -0500 (EST) Received: (qmail 27859 invoked by uid 605); 22 Jan 2002 06:59:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27852 invoked from network); 22 Jan 2002 06:59:19 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 22 Jan 2002 06:59:19 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id DFBD53BD08; Tue, 22 Jan 2002 07:59:17 +0100 (MET) Received: from pelee.firedoor.se (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id DAF636C007; Tue, 22 Jan 2002 07:59:19 +0100 (MET) Received: from appgate.com (pelee.firedoor.se [172.23.2.10]) by pelee.firedoor.se (Postfix) with ESMTP id DA247317A4; Tue, 22 Jan 2002 07:59:10 +0100 (MET) Date: Tue, 22 Jan 2002 07:59:07 +0100 (CET) From: maf@appgate.com Subject: Re: message lang tags verse SSH_MSG_KEXINIT To: fcusack@fcusack.com Cc: ietf-ssh@netbsd.org, sommerfeld@east.sun.com, Darren.Moffat@eng.sun.com In-Reply-To: <20020117173417.N3039@google.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20020122065910.DA247317A4@pelee.firedoor.se> Sender: ietf-ssh-owner@netbsd.org Precedence: list On 17 Jan, Frank Cusack wrote: > Another old message related to the keyboard-interactive draft. > (I believe the first occurence of a langauge tag was in that draft.) > > On Thu, Mar 08, 2001 at 09:49:47PM -0500, Bill Sommerfeld wrote: >> Even if the peers negotiated that all messages will be in, say, >> martian, the server might not have translations for all possible >> messages, and might need to send some messages in a "default" >> language, in which case it should be tagged as such so it gets >> displayed appropriately (e.g., not using martian letters). > > But isn't that impossible with UTF-8 encodings? The client cannot > display the wrong letters (although it may not be able to display the > letters at all). I am not that familiar with multi-byte encodings, > but that is my understanding. Please clarify. No, for some people utf-8 is not enough. Utf-8 did unify a number of code-points in certain asian-languages, that is the letters are the same but the expected glyphs are different. Therefore you must know which language it is to be able to display it correctly. Actually it seems as if rfc2277 (section 4.2) mandates the current behavior. /MaF From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 12:16:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01255 for ; Tue, 22 Jan 2002 12:16:57 -0500 (EST) Received: (qmail 7410 invoked by uid 605); 22 Jan 2002 17:16:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7403 invoked from network); 22 Jan 2002 17:16:56 -0000 Received: from gate2.stm.ubswarburg.com (151.191.1.12) by mail.netbsd.org with SMTP; 22 Jan 2002 17:16:55 -0000 Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id MAA24998; Tue, 22 Jan 2002 12:16:37 -0500 (EST) Received: from (thirteen.ubswarburg.com [192.168.0.7]) by gate2 via smap (V2.0/ubsw) id xma024765; Tue, 22 Jan 2002 12:16:28 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan4 [192.168.0.7]) by virscan4.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA21822; Tue, 22 Jan 2002 12:18:22 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id MAA19620; Tue, 22 Jan 2002 12:16:23 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id MAA07585; Tue, 22 Jan 2002 12:15:59 -0500 (EST) Date: Tue, 22 Jan 2002 12:15:59 -0500 From: Nicolas Williams To: ietf-ssh@netbsd.org Cc: Tobias Ringstrom , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally Message-ID: <20020122121558.A6897@sm2p1386swk.wdr.com> References:

<20020121004135.I27171@sm2p1386swk.wdr.com> <20020121092428.GF14658@faui02> <20020121092615.GA16347@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020121092615.GA16347@faui02>; from markus@openbsd.org on Mon, Jan 21, 2002 at 10:26:15AM +0100 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: ietf-ssh-owner@netbsd.org Precedence: list Brief summary of this thread for the IETF SECSH WG list readers: - two patches were contributed implementing overlapping reads/writes for OpenSSH's sftp client and server to improve its performance - the use of TCP_NODELAY was suggested - it turns out that OpenSSH's sftp implementation triggers the Nagle algorithm; this can probably be avoided, thereby avoiding the need to turn off Nagle on SSHv2 connections, at least in the case of SFTP - but what about X11? X11 normally runs over TCP with Nagle turned off and it stands to reason that a port forwarder ought to forward traffic with Nagle turned off if the traffic being forwarded requires that Nagle be turned off - which brings up the question of what the SSHv2 specs should say about Nagle and whether SSHv2 should have its own per-channel Nagle algorithm and run TCP connections with Nagle turned off The three threads in the OpenSSH list where SFTP performance, Nagle and X11 have been discussed are: http://marc.theaimsgroup.com/?t=101143740600002&r=1&w=2 http://marc.theaimsgroup.com/?t=101010189400002&r=1&w=2 http://marc.theaimsgroup.com/?t=101034855100005&r=1&w=2 A quick search through the IETF SECSH WG mailing list archive yielded no previous mention of Nagle or TCP_NODELAY. It's not clear yet that forwarding X11 traffic with SSHv2 and Nagle turned on is a problem. But this issue may yet come up again. So it's probably worth addressing, even if just to state that Nagle is to remain on at all times... Here's some technical approaches to dealing with Nagle that I can think of right now: - specify heuristics by which SSHv2 clients/servers should unilaterally decide to turn off Nagle. E.g., no pty sessions + X11 forwarding -> turn off Nagle. - add a global request type for requesting the remote side to turn Nagle off or on. - add a per-channel Nagle algorithm protocol, which would probably require new channel request message for turning the algorithm on or off per-channel - an acknowledgment message would also be needed, but gratuitous window adjustments would probably do just fine. I'm not an expert on SSHv2. Take my comments with some salt. Cheers, Nico On Mon, Jan 21, 2002 at 10:26:15AM +0100, Markus Friedl wrote: > On Mon, Jan 21, 2002 at 10:24:28AM +0100, Markus Friedl wrote: > > On Mon, Jan 21, 2002 at 12:41:37AM -0500, Nicolas Williams wrote: > > > Since the protocol allows a variety of kinds of traffic to be exchanged > > > over a TCP connection, some which should be used with Nagle, and some > > > which shouldn't, the protocol should really be capable of implementing > > > Nagle on a per-channel basis and always run with TCP_NODELAY, but that's > > > a lot easier said than done. > > > > ietf-ssh is the place for this. > > ietf-ssh@netbsd.org > -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 12:24:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01361 for ; Tue, 22 Jan 2002 12:24:28 -0500 (EST) Received: (qmail 9051 invoked by uid 605); 22 Jan 2002 17:24:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9038 invoked from network); 22 Jan 2002 17:24:11 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Jan 2002 17:24:11 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24063; Tue, 22 Jan 2002 10:23:55 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01669; Tue, 22 Jan 2002 12:23:54 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0MHNsXt016192; Tue, 22 Jan 2002 12:23:54 -0500 (EST) Message-Id: <200201221723.g0MHNsXt016192@thunk.east.sun.com> From: Bill Sommerfeld To: Nicolas Williams cc: ietf-ssh@netbsd.org, Tobias Ringstrom , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: Your message of "Tue, 22 Jan 2002 12:15:59 EST." <20020122121558.A6897@sm2p1386swk.wdr.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 22 Jan 2002 12:23:53 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list [wg chair hat off] > It's not clear yet that forwarding X11 traffic with SSHv2 and Nagle > turned on is a problem. In my experience, it is; most ssh implementations turn off nagle on "interactive" connections. > But this issue may yet come up again. So it's probably worth > addressing, even if just to state that Nagle is to remain on at all > times... Applications which attempt to track mouse movement (e.g., scroll bar sliders) don't work very well with nagle turned on. my understanding is that "animated" widgest typically require 24-30 updates per second before it begins to look smooth, while the interaction between delayed acks and nagle cause very bursty behavior. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 13:08:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02518 for ; Tue, 22 Jan 2002 13:08:52 -0500 (EST) Received: (qmail 20123 invoked by uid 605); 22 Jan 2002 18:08:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20116 invoked from network); 22 Jan 2002 18:08:49 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 22 Jan 2002 18:08:49 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4C69E8301B0; Tue, 22 Jan 2002 19:08:48 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id TAA13283; Tue, 22 Jan 2002 19:08:47 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: sommerfeld@east.sun.com Cc: Nicolas Williams , ietf-ssh@netbsd.org, Tobias Ringstrom , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally References: <200201221723.g0MHNsXt016192@thunk.east.sun.com> Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 22 Jan 2002 19:08:47 +0100 In-Reply-To: <200201221723.g0MHNsXt016192@thunk.east.sun.com> Message-ID: Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit Bill Sommerfeld writes: > Applications which attempt to track mouse movement (e.g., scroll bar > sliders) don't work very well with nagle turned on. my understanding > is that "animated" widgest typically require 24-30 updates per second > before it begins to look smooth, while the interaction between delayed > acks and nagle cause very bursty behavior. I'm not familiar with this issue, and I'm mostly ignorant about what tcp does below the sockets interface. Can anybody briefly explain what "nagle" is, and how and when to turn it off? Or point me to the appropriate manual. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 13:14:50 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02848 for ; Tue, 22 Jan 2002 13:14:50 -0500 (EST) Received: (qmail 22568 invoked by uid 605); 22 Jan 2002 18:14:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22557 invoked from network); 22 Jan 2002 18:14:46 -0000 Received: from patan.sun.com (192.18.98.43) by mail.netbsd.org with SMTP; 22 Jan 2002 18:14:46 -0000 Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09779; Tue, 22 Jan 2002 11:14:30 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16630; Tue, 22 Jan 2002 13:14:29 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g0MIETXt016542; Tue, 22 Jan 2002 13:14:29 -0500 (EST) Message-Id: <200201221814.g0MIETXt016542@thunk.east.sun.com> From: Bill Sommerfeld To: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) cc: sommerfeld@east.sun.com, Nicolas Williams , ietf-ssh@netbsd.org, Tobias Ringstrom , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: Your message of "22 Jan 2002 19:08:47 +0100." Reply-to: sommerfeld@east.sun.com Date: Tue, 22 Jan 2002 13:14:29 -0500 Sender: ietf-ssh-owner@netbsd.org Precedence: list > I'm not familiar with this issue, and I'm mostly ignorant about what > tcp does below the sockets interface. Can anybody briefly explain what > "nagle" is, and how and when to turn it off? Or point me to the > appropriate manual. See RFC896; on BSD-derived systems, the TCP_NDELAY socket option allows it to be turned on and off. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 13:34:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03941 for ; Tue, 22 Jan 2002 13:34:54 -0500 (EST) Received: (qmail 28703 invoked by uid 605); 22 Jan 2002 18:34:51 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28685 invoked from network); 22 Jan 2002 18:34:50 -0000 Received: from gate2.stm.ubswarburg.com (151.191.1.12) by mail.netbsd.org with SMTP; 22 Jan 2002 18:34:50 -0000 Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id NAA08825; Tue, 22 Jan 2002 13:34:40 -0500 (EST) Received: from (nine.ubswarburg.com [192.168.0.4]) by gate2 via smap (V2.0/ubsw) id xma008260; Tue, 22 Jan 2002 13:34:26 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan2 [192.168.0.4]) by virscan2.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA03447; Tue, 22 Jan 2002 13:30:58 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA04288; Tue, 22 Jan 2002 13:34:27 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id NAA08503; Tue, 22 Jan 2002 13:34:03 -0500 (EST) Date: Tue, 22 Jan 2002 13:34:03 -0500 From: Nicolas Williams To: Frank Cusack Cc: RJ Atkinson , ietf-ssh@netbsd.org Subject: Re: Section 3.2 of secsh-auth-kbdinteract-01 Message-ID: <20020122133402.A8041@sm2p1386swk.wdr.com> References: <20020117171824.M3039@google.com> <80CC657A-0C13-11D6-8DA6-00039357A82A@extremenetworks.com> <20020118101442.H6348@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020118101442.H6348@google.com>; from fcusack@fcusack.com on Fri, Jan 18, 2002 at 10:14:42AM -0800 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: ietf-ssh-owner@netbsd.org Precedence: list On Fri, Jan 18, 2002 at 10:14:42AM -0800, Frank Cusack wrote: > On Fri, Jan 18, 2002 at 08:01:35AM -0500, RJ Atkinson wrote: > > > > On Thursday, January 17, 2002, at 08:18 PM, Frank Cusack wrote: > > > 30 does seem an odd number[1]. I don't recall the exact device (probably > > > Palm) but I do believe it was in fact based on some minimal screen width > > > limitation. The reason the name and prompt fields were limited is b/c > > > they are expected to be printed on a single line. > > > > IMHO, either the advice "SHOULD be limited to 30 characters" ought to be > > deleted xor that should be edited to a much more reasonable value than 30. > > Given that most systems, even a Palm, can wrap lines, it isn't clear to me > > that any limit is needed. And "user@domain" strings can be VERY long. > > The 'name' field is intended to be the window title on GUI clients. > The window title has a limited number of characters that can usefully > be displayed. If the name is important (eg, tells the user what device > to use out of several he has) and is 256 characters but the client > is forced to truncate (or the window toolkit just truncates) that > important info is lost. Why should the "name" be the dialog title? Why can't the dialog title be "SSH Prompt" and let the prompt name be given in full in the dialog window. Bear in mind, I have filed a bug report with Sun about CDE's dtlogin/dtgreet not displaying multi-line PAM prompts correctly, and I would consider the same behaviour a bug in any other GUI. > A similar argument exists for the prompt fields. A similar argument exists for the prompt fields. > So I do not agree with you that no limit is needed, however at the same > time it is clear that strings can be very long. There should be no limit. If kbd-interactive seeks to be a carrier of PAM prompts and responses and PAM places no limit on those, then neither should kbd-interactive. > /fc Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 13:52:08 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04633 for ; Tue, 22 Jan 2002 13:52:08 -0500 (EST) Received: (qmail 4593 invoked by uid 605); 22 Jan 2002 18:52:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4584 invoked from network); 22 Jan 2002 18:52:05 -0000 Received: from gate2.stm.ubswarburg.com (151.191.1.12) by mail.netbsd.org with SMTP; 22 Jan 2002 18:52:05 -0000 Received: (from smap@localhost) by gate2.stm.ubswarburg.com (8.8.8/8.8.8) id NAA14340; Tue, 22 Jan 2002 13:46:48 -0500 (EST) Received: from (thirteen.ubswarburg.com [192.168.0.7]) by gate2 via smap (V2.0/ubsw) id xma014255; Tue, 22 Jan 2002 13:46:36 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan4 [192.168.0.7]) by virscan4.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA21043; Tue, 22 Jan 2002 13:48:36 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id NAA12451; Tue, 22 Jan 2002 13:46:36 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id NAA08797; Tue, 22 Jan 2002 13:46:12 -0500 (EST) Date: Tue, 22 Jan 2002 13:46:11 -0500 From: Nicolas Williams To: Bill Sommerfeld Cc: ietf-ssh@netbsd.org, Tobias Ringstrom , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally Message-ID: <20020122134610.R27171@sm2p1386swk.wdr.com> References: <20020122121558.A6897@sm2p1386swk.wdr.com> <200201221723.g0MHNsXt016192@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200201221723.g0MHNsXt016192@thunk.east.sun.com>; from sommerfeld@east.sun.com on Tue, Jan 22, 2002 at 12:23:53PM -0500 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 22, 2002 at 12:23:53PM -0500, Bill Sommerfeld wrote: > [wg chair hat off] > > > It's not clear yet that forwarding X11 traffic with SSHv2 and Nagle > > turned on is a problem. > > In my experience, it is; most ssh implementations turn off nagle on > "interactive" connections. OpenSSH doesn't. Which implementations do? > > But this issue may yet come up again. So it's probably worth > > addressing, even if just to state that Nagle is to remain on at all > > times... > > Applications which attempt to track mouse movement (e.g., scroll bar > sliders) don't work very well with nagle turned on. my understanding > is that "animated" widgest typically require 24-30 updates per second > before it begins to look smooth, while the interaction between delayed > acks and nagle cause very bursty behavior. Yes, this is my understanding as well. I'll do a simple test of X11 forwarding with OpenSSH with and without Nagle and with some intensive application - nothing scientific, mind you, just a simple test to get a feel of how much of a difference turning off Nagle makes with X11. Rick Jones makes the argument, on the OpenSSH list, that forwarding of other protocols should be done with Nagle turned off, that the forwarded traffic's characteristics would thus mirror the characteristics of the original traffic. I agree. I just don't know whether it would be problematic to run interactive character-based sessions without Nagle. If SSH runs best with Nagle turned off then the draft RFCs should state it, possibly with "SHOULD" language. > - Bill Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 14:25:21 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06460 for ; Tue, 22 Jan 2002 14:25:21 -0500 (EST) Received: (qmail 11865 invoked by uid 605); 22 Jan 2002 19:25:19 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11858 invoked from network); 22 Jan 2002 19:25:18 -0000 Received: from palrel11.hp.com (156.153.255.246) by mail.netbsd.org with SMTP; 22 Jan 2002 19:25:18 -0000 Received: from tardy.cup.hp.com (tardy.cup.hp.com [15.8.80.176]) by palrel11.hp.com (Postfix) with ESMTP id BDF36E01248; Tue, 22 Jan 2002 11:25:13 -0800 (PST) Received: from hp.com (localhost [127.0.0.1]) by tardy.cup.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id LAA15328; Tue, 22 Jan 2002 11:25:12 -0800 (PST) Message-ID: <3C4DBC98.48D0B38@hp.com> Date: Tue, 22 Jan 2002 11:25:12 -0800 From: Rick Jones Reply-To: raj@cup.hp.com Organization: the Unofficial HP X-Mailer: Mozilla 4.79 [en] (X11; I; HP-UX B.11.00 9000/785) X-Accept-Language: en MIME-Version: 1.0 To: Nicolas Williams Cc: Bill Sommerfeld , ietf-ssh@netbsd.org, Tobias Ringstrom , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally References: <20020122121558.A6897@sm2p1386swk.wdr.com> <200201221723.g0MHNsXt016192@thunk.east.sun.com> <20020122134610.R27171@sm2p1386swk.wdr.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > Rick Jones makes the argument, on the OpenSSH list, that forwarding of > other protocols should be done with Nagle turned off, that the > forwarded traffic's characteristics would thus mirror the > characteristics of the original traffic. I agree. I just don't know > whether it would be problematic to run interactive character-based > sessions without Nagle. > > If SSH runs best with Nagle turned off then the draft RFCs should > state it, possibly with "SHOULD" language. However, I would hope that any such language woud include something to the effect that nagle in and of itself is not bad, and that disabling it in ssh is done when acting as a pipe (man in the middle) and so it is simply preserving (or at least trying to) the behaviour of the applications on either end, and that any implementation of ssh SHOULD NOT gratuitously "break-up" the data it recieves as a pipe etc etc etc... rick jones normally a rather zealous opponent of arbitrarily setting TCP_NODELAY -- Wisdom Teeth are impacted, people are affected by the effects of events. these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to raj in cup.hp.com but NOT BOTH... From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 16:22:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11001 for ; Tue, 22 Jan 2002 16:22:49 -0500 (EST) Received: (qmail 4690 invoked by uid 605); 22 Jan 2002 21:22:47 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4682 invoked from network); 22 Jan 2002 21:22:46 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 22 Jan 2002 21:22:46 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id WAA06969; Tue, 22 Jan 2002 22:19:14 +0100 (MET) Date: Tue, 22 Jan 2002 22:19:14 +0100 From: Markus Friedl To: Nicolas Williams Cc: Bill Sommerfeld , ietf-ssh@netbsd.org, Tobias Ringstrom , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally Message-ID: <20020122211914.GE6286@faui02> References: <20020122121558.A6897@sm2p1386swk.wdr.com> <200201221723.g0MHNsXt016192@thunk.east.sun.com> <20020122134610.R27171@sm2p1386swk.wdr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020122134610.R27171@sm2p1386swk.wdr.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 22, 2002 at 01:46:11PM -0500, Nicolas Williams wrote: > On Tue, Jan 22, 2002 at 12:23:53PM -0500, Bill Sommerfeld wrote: > > [wg chair hat off] > > > > > It's not clear yet that forwarding X11 traffic with SSHv2 and Nagle > > > turned on is a problem. > > > > In my experience, it is; most ssh implementations turn off nagle on > > "interactive" connections. > > OpenSSH doesn't. Which implementations do? OpenSSH does, currently. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 16:38:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11542 for ; Tue, 22 Jan 2002 16:38:01 -0500 (EST) Received: (qmail 6318 invoked by uid 605); 22 Jan 2002 21:38:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6263 invoked from network); 22 Jan 2002 21:37:54 -0000 Received: from gate.stm.ubswarburg.com (HELO gate.stm.swissbank.com) (151.191.1.10) by mail.netbsd.org with SMTP; 22 Jan 2002 21:37:54 -0000 Received: (from smap@localhost) by gate.stm.swissbank.com (8.8.8/8.8.8) id QAA25682; Tue, 22 Jan 2002 16:40:45 -0500 (EST) Received: from (twelve.ubswarburg.com [192.168.0.6]) by gate via smap (V2.0) id xma025456; Tue, 22 Jan 2002 16:40:22 -0500 Received: from sm0p9035pos.stm.swissbank.com (virscan3 [192.168.0.6]) by virscan3.swissbank.com (8.8.8/8.8.8) with ESMTP id QAA02486; Tue, 22 Jan 2002 16:37:02 -0500 (EST) Received: from sm2p1386swk.stm.swissbank.com (sm2p1386swk.stm.swissbank.com [151.191.93.86]) by sm0p9035pos.stm.swissbank.com (8.8.8/8.8.8) with ESMTP id QAA00932; Tue, 22 Jan 2002 16:37:26 -0500 (EST) Received: (willian@localhost) by sm2p1386swk.stm.swissbank.com (8.9.3+Sun/8.6.12) id QAA11225; Tue, 22 Jan 2002 16:37:02 -0500 (EST) Date: Tue, 22 Jan 2002 16:37:02 -0500 From: Nicolas Williams To: Markus Friedl Cc: ietf-ssh@netbsd.org, Tobias Ringstrom , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally Message-ID: <20020122163701.T27171@sm2p1386swk.wdr.com> References: <20020122121558.A6897@sm2p1386swk.wdr.com> <200201221723.g0MHNsXt016192@thunk.east.sun.com> <20020122134610.R27171@sm2p1386swk.wdr.com> <20020122211914.GE6286@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020122211914.GE6286@faui02>; from markus@openbsd.org on Tue, Jan 22, 2002 at 10:19:14PM +0100 X-WDR-Disclaimer: Version $Revision: 1.15 $ Sender: ietf-ssh-owner@netbsd.org Precedence: list On Tue, Jan 22, 2002 at 10:19:14PM +0100, Markus Friedl wrote: > On Tue, Jan 22, 2002 at 01:46:11PM -0500, Nicolas Williams wrote: > > On Tue, Jan 22, 2002 at 12:23:53PM -0500, Bill Sommerfeld wrote: > > > [wg chair hat off] > > > > > > > It's not clear yet that forwarding X11 traffic with SSHv2 and Nagle > > > > turned on is a problem. > > > > > > In my experience, it is; most ssh implementations turn off nagle on > > > "interactive" connections. > > > > OpenSSH doesn't. Which implementations do? > > OpenSSH does, currently. Ooo, I see that, yes, and only for interactive sessions. If interactive character-based sessions are the one place where Nagle definitely belongs and OpenSSH turns it off there, why not turn off Nagle altogether for all SSHv2 sessions? Nico PS: Apologies to the list for the automatically appended disclaimer that follows. The first bit is my disclaiming it and assigning rights to the list owner; the second bit is added blindly. -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Jan 22 18:01:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14026 for ; Tue, 22 Jan 2002 18:01:39 -0500 (EST) Received: (qmail 22630 invoked by uid 605); 22 Jan 2002 23:01:36 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22623 invoked from network); 22 Jan 2002 23:01:34 -0000 Received: from as2-1-8.va.g.bonet.se (HELO ringstrom.mine.nu) (194.236.117.122) by mail.netbsd.org with SMTP; 22 Jan 2002 23:01:34 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=localhost) by ringstrom.mine.nu with esmtp (Exim 3.34 #1) id 16T9sW-0001n5-00; Tue, 22 Jan 2002 23:58:56 +0100 Date: Tue, 22 Jan 2002 23:58:56 +0100 (CET) From: Tobias Ringstrom X-X-Sender: tori@boris.prodako.se To: Nicolas Williams cc: Markus Friedl , , Rick Jones Subject: Re: [PATCH] Using TCP_NODELAY unconditionally In-Reply-To: <20020122163701.T27171@sm2p1386swk.wdr.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 Jan 2002, Nicolas Williams wrote: > If interactive character-based sessions are the one place where Nagle > definitely belongs and OpenSSH turns it off there, why not turn off > Nagle altogether for all SSHv2 sessions? This is moving away from the scope of ietf-ssh, and back into openssh-unix-dev... I'm not familiar with the SSHv2 spec, but would it be possible, when opening a new channel, to specify whether the channel should be nodelay or not. Is there a standard-compliant way to do this? A backwards compatible way? If such a facility existed, the implementation could set TCP_NODELAY if one or more channels were nodelay channels. /Tobias From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 30 15:09:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01125 for ; Wed, 30 Jan 2002 15:09:13 -0500 (EST) Received: (qmail 20928 invoked by uid 605); 30 Jan 2002 20:09:05 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20921 invoked from network); 30 Jan 2002 20:09:04 -0000 Received: from malone.cisco.com (171.70.157.157) by mail.netbsd.org with SMTP; 30 Jan 2002 20:09:04 -0000 Received: from cisco.com (dhcp-171-71-137-74.cisco.com [171.71.137.74]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA18844 for ; Wed, 30 Jan 2002 12:09:02 -0800 (PST) Message-ID: <3C58513E.22FC3625@cisco.com> Date: Wed, 30 Jan 2002 12:02:06 -0800 From: Yong Ni X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ssh@netbsd.org Subject: scp2 vs sftp ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Hi, Does anyone know any document defining scp2. Apparently, it is not described either in IETF or ssh.com website. As I understand it, scp2 is a truncated sftp client, but what is exactly take out from sftp? If we want implement scp2, what are the features that we need to support? Thanks, Yong From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 30 15:13:14 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01262 for ; Wed, 30 Jan 2002 15:13:13 -0500 (EST) Received: (qmail 22771 invoked by uid 605); 30 Jan 2002 20:12:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22679 invoked from network); 30 Jan 2002 20:12:31 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 30 Jan 2002 20:12:31 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id VAA23109; Wed, 30 Jan 2002 21:11:51 +0100 (MET) Date: Wed, 30 Jan 2002 21:11:51 +0100 From: Markus Friedl To: Yong Ni Cc: ietf-ssh@netbsd.org Subject: Re: scp2 vs sftp ? Message-ID: <20020130201151.GA19752@faui02> References: <3C58513E.22FC3625@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C58513E.22FC3625@cisco.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list scp2 uses the same protocol as sftp From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 30 15:14:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01317 for ; Wed, 30 Jan 2002 15:14:14 -0500 (EST) Received: (qmail 23776 invoked by uid 605); 30 Jan 2002 20:13:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23760 invoked from network); 30 Jan 2002 20:13:35 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 30 Jan 2002 20:13:35 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA18532; Wed, 30 Jan 2002 15:11:42 -0500 (EST) Date: Wed, 30 Jan 2002 15:11:42 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Yong Ni Cc: ietf-ssh@netbsd.org Subject: Re: scp2 vs sftp ? In-Reply-To: Your message of Wed, 30 Jan 2002 12:02:06 -0800 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > Hi, > > Does anyone know any document defining scp2. Apparently, it is not described > either in IETF or ssh.com website. As I understand it, scp2 is a truncated sftp > client, but what is exactly take out from sftp? If we want implement scp2, what > are the features that we need to support? > > Thanks, > Yong > scp2 I believe is simply rcp protocol over SSHv2. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 30 15:16:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01372 for ; Wed, 30 Jan 2002 15:16:39 -0500 (EST) Received: (qmail 24272 invoked by uid 605); 30 Jan 2002 20:16:34 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 24265 invoked from network); 30 Jan 2002 20:16:33 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 30 Jan 2002 20:16:33 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id VAA23317; Wed, 30 Jan 2002 21:16:17 +0100 (MET) Date: Wed, 30 Jan 2002 21:16:16 +0100 From: Markus Friedl To: Jeffrey Altman Cc: Yong Ni , ietf-ssh@netbsd.org Subject: Re: scp2 vs sftp ? Message-ID: <20020130201616.GB19752@faui02> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Jan 30, 2002 at 03:11:42PM -0500, Jeffrey Altman wrote: > scp2 I believe is simply rcp protocol over SSHv2. no, it's the same protocol as sftp. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 30 15:24:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01544 for ; Wed, 30 Jan 2002 15:24:30 -0500 (EST) Received: (qmail 28856 invoked by uid 605); 30 Jan 2002 20:23:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28787 invoked from network); 30 Jan 2002 20:23:00 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 30 Jan 2002 20:23:00 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id PAA19836; Wed, 30 Jan 2002 15:21:20 -0500 (EST) Date: Wed, 30 Jan 2002 15:21:20 EST From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: Markus Friedl Cc: Yong Ni , ietf-ssh@netbsd.org Subject: Re: scp2 vs sftp ? In-Reply-To: Your message of Wed, 30 Jan 2002 21:16:16 +0100 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list > On Wed, Jan 30, 2002 at 03:11:42PM -0500, Jeffrey Altman wrote: > > scp2 I believe is simply rcp protocol over SSHv2. > > no, it's the same protocol as sftp. Thanks for the correction. Jeffrey Altman * Sr.Software Designer C-Kermit 8.0 available now!!! The Kermit Project @ Columbia University includes Telnet, FTP and HTTP http://www.kermit-project.org/ secured with Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. Interfaces with OpenSSH From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 30 16:39:57 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02735 for ; Wed, 30 Jan 2002 16:39:56 -0500 (EST) Received: (qmail 27446 invoked by uid 605); 30 Jan 2002 21:39:18 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27410 invoked from network); 30 Jan 2002 21:39:17 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 30 Jan 2002 21:39:17 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id WAA26581; Wed, 30 Jan 2002 22:39:15 +0100 (MET) Date: Wed, 30 Jan 2002 22:39:14 +0100 From: Markus Friedl To: ietf-ssh@netbsd.org Cc: openssh@openbsd.org Subject: x509 Message-ID: <20020130213914.GD19752@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list I'm trying to figure out how x509 support should actually work. I think about sending certs encoded as "x509v3-sign-rsa" and the actual signature as "ssh-rsa", since there is no spec for what a matching x509-signature should look like. How should certificates be encoded in "x509v3-sign-rsa"? The spec seems a little bit ambigous to me: Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data The certificate part may have be a zero length string, but a public key is required. This is the public key that will be used for authentication; the certificate sequence contained in the certificate blob can be used to provide authorization. Does this mean that "x509v3-sign-rsa" is encoded as string "x509v3-sign-rsa" byte[n] DER-encoded x509 cert string "x509v3-sign-rsa" int32 n byte[n] DER-encoded x509 cert What does "but a public key is required" mean? Zero length strings for certificates? Are they always required? How is the encoding for userauth? byte SSH_MSG_USERAUTH_REQUEST string user name string service string "publickey" boolean FALSE string public key algorithm name string public key blob For RSA keys the 'public key algorithm name' is "ssh-rsa" and the 'public key blob' is string "ssh-rsa" mpint e mpint n What is used for x509 certs? -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 30 19:03:10 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05056 for ; Wed, 30 Jan 2002 19:03:09 -0500 (EST) Received: (qmail 21310 invoked by uid 605); 31 Jan 2002 00:02:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20862 invoked from network); 31 Jan 2002 00:01:59 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 31 Jan 2002 00:01:59 -0000 Received: from [192.168.0.3] (HELO merlin) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 465273; Wed, 30 Jan 2002 17:08:13 -0700 Message-ID: <00ef01c1a9ea$34eea120$2800a8c0@test.vandyke.com> From: "Joseph Galbraith" To: "Markus Friedl" , Cc: References: <20020130213914.GD19752@faui02> Subject: Re: x509 Date: Wed, 30 Jan 2002 16:59:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit This is clearly still an open issue-- We discussed it on the list before the August meeting, at the August meeting, and it has been brought up at least once recently. Here is a email I sent right before the August meeting with a proposed change: > In the transport draft, Section 4.6, we specify that > public keys are, in general encoded as: > > string certificate or public key format identifier > byte[n] key/certificate data > > However, the sections on x.509 are less clear. And in fact, > SSH Communications current x.509 implementation omits the > string, including only the certificate data -- although > the string is included when sending signatures. > > I would suggest we include the following text in section > documenting "x509v3-sign-rsa": > > The "x509v3-sign-rsa" key format has the following specific encoding: > > string "x509v3-sign-rsa" > byte[n] x.509v3 compatible der encoded certificate data > > The resulting signature is encoded as follows: > > string "x509v3-sign-rsa" > string rsa_signature_blob > > > Variants to this go in the other x.509 sections as appropriate. > > In addition, I would suggest that we note that signatures > made with x509v3-sign-rsa keys MUST use the SHA-1 hash, and > be done using PKCS1. During the August meeting, we decided that we needed to use PKCS 7, because if a hardware device was in play, it might not be possible to control the hash algorithm it uses. Here is an email I sent after the meeting with this proposed change in it: > --------- Transport draft, Section 4.6 > > (We might want to number the different sections > of this, so that ssh-dss becomes 4.6.1, ssh-rsa > becomes 4.6.2, and x509v3-* becomes 4.6.3) > > 4.6.3 x.509v3 certificates > > The "x509v3-*" methods indicate that the certificates, the > public key, and the resulting signature are in X.509v3 compatible > DER-encoded format. The formats used in X.509v3 are described in > [RFC2459]. The formats used for signatures are described in > [PKCS7]. > > Note, that there is no such algorithm as "x509v3-*", but the > * is used only in this document to denote all algorithms > beginning with x509v3. > > There are currently two such algorithms defined: > x509v3-sign-rsa RECOMMENDED sign X.509 certificates (RSA key) > x509v3-sign-dss RECOMMENDED sign X.509 certificates (DSS key) > > The "x509v3-*" key format has the following generic encoding: > > string "x509v3-*" > string x.509v3 compatible der encoded certificate data > > The resulting signature is encoded as follows: > > string "pkcs7" > string PKCS-7 signature, DER encoded > > The "x509v3-sign-rsa" method indicates that the key > (or one of the keys in the certificate) is an RSA-key. > > The "x509v3-sign-dss". As above, but indicates that the key (or > one of the keys in the certificate) is a DSS-key. Now -- on further reflection, I'm not sure. Do hardware devices like smartcards do a hashing operation, or are they passed the hash to sign? If they don't do the hashing operation, and we don't think we need to provide that kind of flexibility, we can probably get away without PKCS 7, and do something like what Markus is proposing in this email: > i don't see why we cannot use the current "ssh-rsa" encoding: > transfer a x509 certificate in addition to "ssh-rsa" encoded > signature? > > since "x509v3-sign-rsa" is not specified in detail, it should be > dropped from the draft and replaced by something like > "x509v5-ssh-rsa" > meaning: > public key is transfered in "x509v3" format and > the current "ssh-rsa" is used for encoding for signatures. > > i think all the confusion is due to the fact that a single > identifier is used for specifying to encoding of > keys, certificates and signatures. > > i don't see why the current signature formats cannot > be used together with x509 certificates. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Jan 30 19:24:56 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05262 for ; Wed, 30 Jan 2002 19:24:56 -0500 (EST) Received: (qmail 29199 invoked by uid 605); 31 Jan 2002 00:24:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29192 invoked from network); 31 Jan 2002 00:24:52 -0000 Received: from iron.ibs.com.au (202.14.182.249) by mail.netbsd.org with SMTP; 31 Jan 2002 00:24:52 -0000 Received: from xenon.mel.ibs.com.au (xenon.mel.ibs.com.au [10.3.0.3]) by iron.ibs.com.au (Postfix) with ESMTP id 9BCA816C7F; Thu, 31 Jan 2002 11:24:22 +1100 (EST) Date: Thu, 31 Jan 2002 11:29:58 +1100 (EST) From: Damien Miller X-X-Sender: To: Joseph Galbraith Cc: Markus Friedl , "ietf-ssh@netbsd.org" , "openssh@openbsd.org" Subject: Re: x509 In-Reply-To: <00ef01c1a9ea$34eea120$2800a8c0@test.vandyke.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, 30 Jan 2002, Joseph Galbraith wrote: > > i don't see why we cannot use the current "ssh-rsa" encoding: > > transfer a x509 certificate in addition to "ssh-rsa" encoded > > signature? > > > > since "x509v3-sign-rsa" is not specified in detail, it should be > > dropped from the draft and replaced by something like > > "x509v5-ssh-rsa" > > meaning: > > public key is transfered in "x509v3" format and > > the current "ssh-rsa" is used for encoding for signatures. I like the idea of removing the underspecified Public Key Algorithms and replacing them with equivalents based on the current ssh-rsa and ssh-dss methods. e.g. string "ssh-rsa-x509v3" mpint e mpint n string der_encoded_certificate This scales nicely to the other certificate (SPKI, OpenPGP) methods. It also allows implementations which don't directly support the certificate format to continue authentication with the pubkey only. Though this may be dangerous as it would miss additional restrictions implicit in the certificate, e.g. validity periods in X.509v3 & OpenPGP or restrictions in SPKI. -d From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 05:10:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA22966 for ; Thu, 31 Jan 2002 05:10:54 -0500 (EST) Received: (qmail 21830 invoked by uid 605); 31 Jan 2002 10:10:53 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21823 invoked from network); 31 Jan 2002 10:10:52 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 31 Jan 2002 10:10:52 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id LAA00588; Thu, 31 Jan 2002 11:10:49 +0100 (MET) Date: Thu, 31 Jan 2002 11:10:48 +0100 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@netbsd.org, openssh@openbsd.org Subject: Re: x509 Message-ID: <20020131101048.GA29356@faui02> References: <20020130213914.GD19752@faui02> <00ef01c1a9ea$34eea120$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ef01c1a9ea$34eea120$2800a8c0@test.vandyke.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Jan 30, 2002 at 04:59:51PM -0700, Joseph Galbraith wrote: > > In the transport draft, Section 4.6, we specify that > > public keys are, in general encoded as: > > > > string certificate or public key format identifier > > byte[n] key/certificate data > > > > However, the sections on x.509 are less clear. And in fact, > > SSH Communications current x.509 implementation omits the > > string, including only the certificate data -- although > > the string is included when sending signatures. I think they use byte[n] der-encoded-x509-cert instead of string "x509v3-sign-rsa" byte[n] der-encoded-x509-cert because with the 2nd encoding the length of the DER blob is not made explicit, while with the 1st encoding you have length, because the pubkey is usually wrapped into a string pubkeyorcertblob An encoding similar to string "x509v3-sign-rsa" int32 n byte[n] der-encoded-x509-cert would be more in line with the other encodings. However, the transport draft also state: The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. This does not match with: Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data Or am I missing something? -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 05:22:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA23081 for ; Thu, 31 Jan 2002 05:22:01 -0500 (EST) Received: (qmail 23253 invoked by uid 605); 31 Jan 2002 10:21:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23246 invoked from network); 31 Jan 2002 10:21:48 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 31 Jan 2002 10:21:48 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id LAA01521; Thu, 31 Jan 2002 11:21:41 +0100 (MET) Date: Thu, 31 Jan 2002 11:21:40 +0100 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@netbsd.org Subject: Re: x509 Message-ID: <20020131102140.GB29356@faui02> References: <20020130213914.GD19752@faui02> <00ef01c1a9ea$34eea120$2800a8c0@test.vandyke.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ef01c1a9ea$34eea120$2800a8c0@test.vandyke.com> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Wed, Jan 30, 2002 at 04:59:51PM -0700, Joseph Galbraith wrote: > If they don't do the hashing operation, and we don't think > we need to provide that kind of flexibility, we can probably > get away without PKCS 7, and do something like what Markus is > proposing in this email: > > > i don't see why we cannot use the current "ssh-rsa" encoding: > > transfer a x509 certificate in addition to "ssh-rsa" encoded > > signature? In the initial keyexchange both parties agree on the used host-key encoding and on supported signature encodings. So If both parties agree on "x509v3-sign-rsa" for the public key encoding, you cannot assume that the peer can decode a "ssh-rsa" type signature. So the "name" from the public key and the "name" of the signature encoding must always match. This means you cannot mix a "x509v3-sign-rsa" host key cert and a "ssh-rsa" signature. But there still seems to be an open issue: The "x509v3-sign-rsa" method indicates that the certificates, the public key, and the resulting signature are in X.509v3 compatible DER-encoded format. The formats used in X.509v3 is described in [RFC2459]. This method indicates that the key (or one of the keys in the certificate) is an RSA-key. Does this mean the signature will look like a string "ssh-rsa" string rsa_signature_blob but with a different name tag instead? string "x509v3-sign-rsa" string rsa_signature_blob Do they differ otherwise? -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 06:00:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23380 for ; Thu, 31 Jan 2002 06:00:04 -0500 (EST) Received: (qmail 348 invoked by uid 605); 31 Jan 2002 11:00:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 121 invoked from network); 31 Jan 2002 11:00:00 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 31 Jan 2002 11:00:00 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 33B84835DAB; Thu, 31 Jan 2002 11:59:59 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id LAA05230; Thu, 31 Jan 2002 11:59:58 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Damien Miller Cc: Joseph Galbraith , Markus Friedl , "ietf-ssh@netbsd.org" , "openssh@openbsd.org" Subject: Re: x509 References: Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 31 Jan 2002 11:59:58 +0100 In-Reply-To: Message-ID: Lines: 42 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit A few comments on some of the issues here. > > > i don't see why we cannot use the current "ssh-rsa" encoding: > > > transfer a x509 certificate in addition to "ssh-rsa" encoded > > > signature? I think it makes sense to keep the ssh-dsa and ssh-rsa encodings for signatures. Certificate standards typically don't define formats for detached signatures. Whether or not a new name is attached to the data isn't terribly important, but I'd prefer *not* introducing new redundant names. > string "ssh-rsa-x509v3" > mpint e > mpint n > string der_encoded_certificate > > This scales nicely to the other certificate (SPKI, OpenPGP) methods. This has one big advantage: The ssh(d) program can verify the signature, and delegate processing of the certificates to an external program or library, which doesn't need to know the SSH protocol data that was signed. One potential disadvantage is that it might encourage implementations to claim they understand x509, and silently ignore the certificate data. In this situation, the right thing to do is to use only plain "ssh-rsa". The certificate blob is still slightly underdefined: string der_encoded_certificate There may be more than one certificate, and there's more than one way to represent a certificate chain (e.g. pure x.509 and SSL do it differently). The spec should at least say explicitly what type of ASN.1-object is expected inside the DER encoding. (Personally, I dislike x.509, but these encoding issues are quite similar for spki). /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 06:12:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA23509 for ; Thu, 31 Jan 2002 06:12:31 -0500 (EST) Received: (qmail 2431 invoked by uid 605); 31 Jan 2002 11:12:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2403 invoked from network); 31 Jan 2002 11:12:24 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 31 Jan 2002 11:12:24 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id MAA03755; Thu, 31 Jan 2002 12:11:23 +0100 (MET) Date: Thu, 31 Jan 2002 12:11:23 +0100 From: Markus Friedl To: Niels =?iso-8859-1?Q?M=F6ller?= Cc: Damien Miller , Joseph Galbraith , "ietf-ssh@netbsd.org" , "openssh@openbsd.org" Subject: Re: x509 Message-ID: <20020131111123.GA1905@faui02> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Jan 31, 2002 at 11:59:58AM +0100, Niels Mller wrote: > A few comments on some of the issues here. > > > > > i don't see why we cannot use the current "ssh-rsa" encoding: > > > > transfer a x509 certificate in addition to "ssh-rsa" encoded > > > > signature? > > I think it makes sense to keep the ssh-dsa and ssh-rsa encodings for > signatures. Certificate standards typically don't define formats for > detached signatures. Whether or not a new name is attached to the data > isn't terribly important, but I'd prefer *not* introducing new > redundant names. ok, then the transport draft must say: signatures for hostkeys of type "ssh-rsa-x509v3" are encoded as string "ssh-rsa" string rsa_signature_blob. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 07:01:10 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24040 for ; Thu, 31 Jan 2002 07:01:09 -0500 (EST) Received: (qmail 11813 invoked by uid 605); 31 Jan 2002 12:01:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11806 invoked from network); 31 Jan 2002 12:01:06 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 31 Jan 2002 12:01:06 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 4142A834CC1; Thu, 31 Jan 2002 13:01:05 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id NAA07758; Thu, 31 Jan 2002 13:01:04 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Damien Miller Cc: Joseph Galbraith , Markus Friedl , "ietf-ssh@netbsd.org" , "openssh@openbsd.org" Subject: Re: x509 References: From: nisse@lysator.liu.se (Niels =?iso-8859-1?q?M=F6ller?=) Date: 31 Jan 2002 13:01:04 +0100 In-Reply-To: Message-ID: Lines: 26 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit nisse@lysator.liu.se (Niels M�ller) writes: > > string "ssh-rsa-x509v3" > > mpint e > > mpint n > > string der_encoded_certificate > > > > This scales nicely to the other certificate (SPKI, OpenPGP) methods. > > This has one big advantage: The ssh(d) program can verify the > signature, and delegate processing of the certificates to an external > program or library, which doesn't need to know the SSH protocol data > that was signed. But on second thought, this beautiful separation of SSH things from x.509 things doesn't quite work. Somebody *has* to check that the e and n above equals the key that is somewhere inside the ASN.1 certificate chain, otherwise, the certificate checking has a hole you can drive a 20 ton truck right through. So now I think it's best to *not* duplicate crucial security information like this. If we do, I'm sure some implementation will forget to check that the information is consistent. Regards, /Niels From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 07:16:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24306 for ; Thu, 31 Jan 2002 07:16:41 -0500 (EST) Received: (qmail 14212 invoked by uid 605); 31 Jan 2002 12:16:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14202 invoked from network); 31 Jan 2002 12:16:34 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 31 Jan 2002 12:16:34 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id E8057EBF4; Thu, 31 Jan 2002 23:24:03 +1100 (EST) Subject: Re: x509 From: Damien Miller To: Markus Friedl Cc: Niels =?ISO-8859-1?Q?M=F6ller?= , Joseph Galbraith , "ietf-ssh@netbsd.org" , "openssh@openbsd.org" In-Reply-To: <20020131111123.GA1905@faui02> References: <20020131111123.GA1905@faui02> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 31 Jan 2002 23:16:17 +1100 Message-Id: <1012479388.2261.17.camel@mothra> Mime-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Thu, 2002-01-31 at 22:11, Markus Friedl wrote: > > I think it makes sense to keep the ssh-dsa and ssh-rsa encodings for > > signatures. Certificate standards typically don't define formats for > > detached signatures. Whether or not a new name is attached to the data > > isn't terribly important, but I'd prefer *not* introducing new > > redundant names. > > ok, then the transport draft must say: > > signatures for hostkeys of type "ssh-rsa-x509v3" are > encoded as > string "ssh-rsa" > string rsa_signature_blob. Here is a modified modified version of the relevent section of the draft. I have removed the "old" certificate-based formats, perhaps they need to be included? The contents of the certificate blobs themselves need further specification too. -------------------------------- 4.6 Public Key Algorithms This protocol has been designed to be able to operate with almost any public key format, encoding, and algorithm (signature and/or encryption). There are several aspects that define a public key type: o Key format: how is the key encoded and how are certificates represented. The key blobs in this protocol MAY contain certificates in addition to keys. o Signature and/or encryption algorithms. Some key types may not support both signing and encryption. Key usage may also be restricted by policy statements in e.g. certificates. In this case, different key types SHOULD be defined for the different policy alternatives. o Encoding of signatures and/or encrypted data. This includes but is not limited to padding, byte order, and data formats. The following public key and/or certificate formats are currently defined: ssh-dss REQUIRED sign no-cert Simple DSS ssh-rsa RECOMMENDED sign no-cert Simple RSA ssh-dss-x509v3 RECOMMENDED sign cert X.509 certificates (DSS) ssh-rsa-x509v3 RECOMMENDED sign cert X.509 certificates (RSA) ssh-dss-spki OPTIONAL sign cert SPKI certificates (DSS) ssh-rsa-spki OPTIONAL sign cert SPKI certificates (RSA) ssh-dss-pgp OPTIONAL sign cert OpenPGP certificates (DSS) ssh-rsa-pgp OPTIONAL sign cert OpenPGP certificates (RSA) Additional key types may be defined as specified in [SSH-ARCH]. The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. Certificates and public keys are encoded as follows: string certificate or public key format identifier mpint[n] key data string certificate data (optional) The certificate part should not be included for formats which include signatures only, but a public key is required. This is the public key that will be used for authentication; the certificate sequence contained in the certificate blob can be used to provide authorization. The "ssh-dss" key format has the following specific encoding: string "ssh-dss" mpint p mpint q mpint g mpint y Here the p, q, g, and y parameters form the signature key blob. Signing and verifying using this key format is done according to the Digital Signature Standard [FIPS-186] using the SHA-1 hash. A description can also be found in [SCHNEIER]. The certificate formats based on ssh-dss extend the public key format to include certificate data: string "ssh-dss-x509v3" / "ssh-dss-spki" / "ssh-dss-pgp" mpint p mpint q mpint g mpint y string certificate In the case of "ssh-dss-x509v3", the certificate must be in a X.509v3 compatible DER-encoded format. The formats used in X.509v3 are described in [RFC2459]. The key (or one of the keys in the certificate) MUST be a DSA key which matches the p, q, g and y public key portions present in the first part of the packet. The "ssh-dss-spki" method indicates that the certificate blob contains a sequence of SPKI certificates. The format of SPKI certificates is described in [RFC2693]. The key (or one of the keys in the certificate) MUST be a DSA key which matches the p, q, g and y public key portions present in the first part of the packet. The "ssh-dss-pgp" method indicates the certificate is in an OpenPGP compatible binary format ([RFC2440]). The key in the certificate MUST be a DSS key which matches the p, q, g and y public key portions present in the first part of the packet.. For all DSS algorithms he resulting signature is encoded as follows: string "ssh-dss" string dss_signature_blob dss_signature_blob is encoded as a string containing r followed by s (which are 160 bits long integers, without lengths or padding, unsigned and in network byte order). The "ssh-rsa" key format has the following specific encoding: string "ssh-rsa" mpint e mpint n Here the e and n parameters form the signature key blob. Signing and verifying using this key format is done according to [SCHNEIER] and [PKCS1] using the SHA-1 hash. The certificate formats based on ssh-rsa extend the public key format to include certificate data: string "ssh-rsa-x509v3" / "ssh-rsa-spki" / "ssh-rsa-pgp" mpint e mpint n string certificate The format of the certificate string for each of these algorithms is that same as the DSS certificate algorithms specified above. In all cases the certificate MUST contain an RSA key which matches the n and e components sent in the first portion of the packet. The resulting signature is encoded as follows: string "ssh-rsa" string rsa_signature_blob rsa_signature_blob is encoded as a string containing s (which is an integer, without lengths or padding, unsigned and in network byte order). -------------------------------------- -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 07:27:32 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24443 for ; Thu, 31 Jan 2002 07:27:32 -0500 (EST) Received: (qmail 16982 invoked by uid 605); 31 Jan 2002 12:27:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16975 invoked from network); 31 Jan 2002 12:27:29 -0000 Received: from intern12.lnk.telstra.net (HELO shitei.mindrot.org) (139.130.53.38) by mail.netbsd.org with SMTP; 31 Jan 2002 12:27:29 -0000 Received: from mothra.mindrot.org (mothra.mindrot.org [203.44.118.225]) by shitei.mindrot.org (Postfix) with ESMTP id C18EEEBFE; Thu, 31 Jan 2002 23:35:02 +1100 (EST) Subject: Re: x509 From: Damien Miller To: "ietf-ssh@netbsd.org" Cc: Joseph Galbraith , Markus Friedl , "ietf-ssh@netbsd.org" , "openssh@openbsd.org" In-Reply-To: References: Content-Type: text/plain; charset=ISO-8859-15 X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 31 Jan 2002 23:27:27 +1100 Message-Id: <1012480047.2257.24.camel@mothra> Mime-Version: 1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA24443 On Thu, 2002-01-31 at 23:01, Niels M�ller wrote: > But on second thought, this beautiful separation of SSH things from > x.509 things doesn't quite work. Somebody *has* to check that the e > and n above equals the key that is somewhere inside the ASN.1 > certificate chain, otherwise, the certificate checking has a hole you > can drive a 20 ton truck right through. > > So now I think it's best to *not* duplicate crucial security > information like this. If we do, I'm sure some implementation will > forget to check that the information is consistent. I think that is putting it a little strong - you still have to present a valid signature. You run into problems if the remote end grants additionak trust (e.g. automatically accepting a host key) based on information in the certificate. It seems unlikely that implementors would go to all the trouble of implementing certificate chain checking, etc only to miss something so basic. -d -- | By convention there is color, \\ Damien Miller | By convention sweetness, By convention bitterness, \\ www.mindrot.org | But in reality there are atoms and space - Democritus (c. 400 BCE) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 07:43:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA24757 for ; Thu, 31 Jan 2002 07:43:52 -0500 (EST) Received: (qmail 20181 invoked by uid 605); 31 Jan 2002 12:43:50 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20174 invoked from network); 31 Jan 2002 12:43:49 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 31 Jan 2002 12:43:49 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id NAA10751; Thu, 31 Jan 2002 13:43:46 +0100 (MET) Date: Thu, 31 Jan 2002 13:43:46 +0100 From: Markus Friedl To: Joseph Galbraith Cc: ietf-ssh@netbsd.org Subject: Re: x509 Message-ID: <20020131124346.GB10392@faui02> References: <20020130213914.GD19752@faui02> <00ef01c1a9ea$34eea120$2800a8c0@test.vandyke.com> <20020131101048.GA29356@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020131101048.GA29356@faui02> User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, Jan 31, 2002 at 11:10:48AM +0100, Markus Friedl wrote: > An encoding similar to > string "x509v3-sign-rsa" > int32 n > byte[n] der-encoded-x509-cert > would be more in line with the other encodings. i.e. string "x509v3-sign-rsa" string der-encoded-x509-cert From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 08:41:17 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26019 for ; Thu, 31 Jan 2002 08:41:16 -0500 (EST) Received: (qmail 27461 invoked by uid 605); 31 Jan 2002 13:41:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27450 invoked from network); 31 Jan 2002 13:41:14 -0000 Received: from nic.appgate.com (193.12.107.226) by mail.netbsd.org with SMTP; 31 Jan 2002 13:41:14 -0000 Received: from shala.firedoor.se (shala.firedoor.se [172.23.2.27]) by nic.appgate.com (Postfix) with ESMTP id 2E0EF3BE0D; Thu, 31 Jan 2002 14:41:12 +0100 (MET) Received: from localhost (localhost.localdomain [127.0.0.1]) by shala.firedoor.se (Postfix) with ESMTP id 703956C007; Thu, 31 Jan 2002 14:41:15 +0100 (MET) Date: Thu, 31 Jan 2002 14:39:54 +0100 (CET) From: "Andersson, Mats" X-X-Sender: To: Markus Friedl Cc: Joseph Galbraith , Subject: Re: x509 In-Reply-To: <20020131124346.GB10392@faui02> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: ietf-ssh-owner@netbsd.org Precedence: list On Thu, 31 Jan 2002, Markus Friedl wrote: > On Thu, Jan 31, 2002 at 11:10:48AM +0100, Markus Friedl wrote: > > An encoding similar to > > string "x509v3-sign-rsa" > > int32 n > > byte[n] der-encoded-x509-cert > > would be more in line with the other encodings. > > i.e. > string "x509v3-sign-rsa" > string der-encoded-x509-cert Hi, This is in fact inconsistent with the other encodings for keys(/certs). For example: The "ssh-dss" key format has the following specific encoding: string "ssh-dss" mpint p ... It is the signature-blob that should be "enclosed" in a ssh2 string. This is the issue, i.e. the format of the signature is not _explicitly_ defined in the draft (hence the discussion on how it should look like I guess). However, in rfc2459 it says: When signing, the DSA algorithm generates two values. These values are commonly referred to as r and s. To easily transfer these two values as one signature, they shall be ASN.1 encoded using the following ASN.1 structure: Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } Which is pretty specific to me. It also refers pkcs1 for RSA which also defines the format of the signature. I might have missed the start of the thread but what is the issue here? The transport draft refers rfc2459 which states the format for both RSA and DSA so what is it that is not clear in all this except for the detail that it doesn't say explicitly something like: string "ssh-rsa" string dss_signature_value dss_signature_value is the DER encoded value of the Dss-Sig-Value as defined in rfc2459. Cheers, /Mats From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 08:59:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26628 for ; Thu, 31 Jan 2002 08:59:30 -0500 (EST) Received: (qmail 239 invoked by uid 605); 31 Jan 2002 13:58:54 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 29979 invoked from network); 31 Jan 2002 13:58:45 -0000 Received: from faui02.informatik.uni-erlangen.de (131.188.30.102) by mail.netbsd.org with SMTP; 31 Jan 2002 13:58:45 -0000 Received: (from msfriedl@localhost) by faui02.informatik.uni-erlangen.de (8.9.1/8.1.16-FAU) id OAA15860; Thu, 31 Jan 2002 14:58:40 +0100 (MET) Date: Thu, 31 Jan 2002 14:58:40 +0100 From: Markus Friedl To: "Andersson, Mats" Cc: Joseph Galbraith , ietf-ssh@netbsd.org Subject: Re: x509 Message-ID: <20020131135840.GA14690@faui02> References: <20020131124346.GB10392@faui02> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.25i Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 8bit On Thu, Jan 31, 2002 at 02:39:54PM +0100, Andersson, Mats wrote: > The transport draft refers rfc2459 which states the format for both RSA > and DSA so what is it that is not clear in all this except for the detail > that it doesn't say explicitly something like: > > string "ssh-rsa" s/rsa/dss/ > string dss_signature_value > > dss_signature_value is the DER encoded value of the Dss-Sig-Value as > defined in rfc2459. the exact format for a "x509v3-sign-rsa" type signature is not specified, i.e.: is it string "x509v3-sign-rsa" string "DER-encoded format � la RFC2459" or string "x509v3-sign-rsa" byte[n] "DER-encoded format � la RFC2459" because the definition for the "x509v3-sign-rsa" type cert is: string "x509v3-sign-rsa" byte[n] "DER-encoded cert" instead of a string "x509v3-sign-rsa" string "DER-encoded cert" moreover, implementations supporting x509 (e.g. ssh.com) currently send string "DER-encoded cert" without even sending the key type. additionally, the draft says: The key type MUST always be explicitly known (from algorithm negotiation or some other source). It is not normally included in the key blob. but: Certificates and public keys are encoded as follows: string certificate or public key format identifier byte[n] key/certificate data so, i'm confused by the draft and the implementations. -m From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Jan 31 09:10:18 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27051 for ; Thu, 31 Jan 2002 09:10:17 -0500 (EST) Received: (qmail 3436 invoked by uid 605); 31 Jan 2002 14:10:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3429 invoked from network); 31 Jan 2002 14:10:14 -0000 Received: from mail.lysator.liu.se (130.236.254.3) by mail.netbsd.org with SMTP; 31 Jan 2002 14:10:14 -0000 Received: from sture.lysator.liu.se (sture.lysator.liu.se [130.236.254.21]) by mail.lysator.liu.se (Postfix) with ESMTP id 6FFFE835E0F; Thu, 31 Jan 2002 15:10:12 +0100 (MET) Received: (from nisse@localhost) by sture.lysator.liu.se (8.9.3/8.8.7) id PAA12880; Thu, 31 Jan 2002 15:10:11 +0100 (MET) X-Authentication-Warning: sture.lysator.liu.se: nisse set sender to nisse@lysator.liu.se using -f To: Damien Miller Cc: "ietf-ssh@netbsd.org" , Joseph Galbraith , Markus Friedl , "openssh@openbsd.org" Subject: Re: x509 References: