From beepwg-bounces@dbc.mtview.ca.us Fri Aug 6 01:42:25 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18713 for ; Fri, 6 Aug 2004 01:42:25 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i765YQfi026168; Thu, 5 Aug 2004 22:34:28 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i765YO5e026164 for ; Thu, 5 Aug 2004 22:34:24 -0700 Received: from wetware.com (wetware.wetware.com [199.108.16.1]) i765U11h009906 for ; Thu, 5 Aug 2004 22:30:01 -0700 (PDT) Received: from [208.177.152.17] (helo=[10.0.1.5]) by wetware.com with esmtp (Exim 4.20) id 1BsxIM-0006j8-5E for beepwg@lists.beepcore.org; Thu, 05 Aug 2004 22:29:34 -0700 Mime-Version: 1.0 (Apple Message framework v618) Message-Id: <9F468852-E769-11D8-98CC-000A958FF2FE@wetware.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed To: BEEP WG From: james woodyatt Date: Thu, 5 Aug 2004 22:29:43 -0700 X-Mailer: Apple Mail (2.618) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id i765YO5e026164 Subject: [BEEPwg] Cipher block boundaries and the TCP mapping X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 8bit everyone— Is it my imagination, or does the TCP mapping for the BEEP protocol not specify any way for frames to be spaced properly so that they always begin (or end) on a cipher block boundary? If you wanted to do that, would declaring it as a "feature" in the greeting be the right choice? What would a specification of this extension look like? -- j h woodyatt _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Fri Aug 6 11:39:43 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05097 for ; Fri, 6 Aug 2004 11:39:42 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i76FYRdV002227; Fri, 6 Aug 2004 08:34:28 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i76FYKja002219 for ; Fri, 6 Aug 2004 08:34:24 -0700 Received: from ms-smtp-01-eri0.socal.rr.com (ms-smtp-01-qfe0.socal.rr.com [66.75.162.133])i76FTT1h016447 for ; Fri, 6 Aug 2004 08:29:30 -0700 (PDT) Received: from san.rr.com (66-27-119-171.san.rr.com [66.27.119.171]) i76FTO6j027135; Fri, 6 Aug 2004 08:29:25 -0700 (PDT) Message-ID: <4113A3D3.904@san.rr.com> Date: Fri, 06 Aug 2004 08:29:23 -0700 From: Darren New User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: james woodyatt Subject: Re: [BEEPwg] Cipher block boundaries and the TCP mapping References: <9F468852-E769-11D8-98CC-000A958FF2FE@wetware.com> In-Reply-To: <9F468852-E769-11D8-98CC-000A958FF2FE@wetware.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine cc: BEEP WG X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit james woodyatt wrote: > Is it my imagination, or does the TCP mapping for the BEEP protocol not > specify any way for frames to be spaced properly so that they always > begin (or end) on a cipher block boundary? Is there a need for this to be part of the protocol? There wouldn't seem to be. Part of an API, perhaps, but not part of a protocol, I would think. > If you wanted to do that, > would declaring it as a "feature" in the greeting be the right choice? > What would a specification of this extension look like? That would be a request for the other side to ensure that frames match cypher blocks? It would seem to make more sense to make that an option of the TLS or SASL profiles, than as an option of the entire session. Consider, what would be the meaning of this feature if TLS was never invoked? What would be the meaning if TLS was already invoked? -- Darren New / San Diego, CA, USA (PST) "You may mail in the form, and wait 4 to 6 weeks, or call us and get your answer right over the phone... after being on hold for 4 to 6 weeks." _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Fri Aug 6 13:50:18 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13740 for ; Fri, 6 Aug 2004 13:50:18 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i76HiSkg010131; Fri, 6 Aug 2004 10:44:29 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i76HiLQK010122 for ; Fri, 6 Aug 2004 10:44:26 -0700 Received: from wetware.com (wetware.wetware.com [199.108.16.1]) i76HZB1h017418 for ; Fri, 6 Aug 2004 10:35:12 -0700 (PDT) Received: from [208.177.152.17] (helo=[10.0.1.5]) by wetware.com with esmtp (Exim 4.20) id 1Bt8cU-0004XQ-L8 for beepwg@lists.beepcore.org; Fri, 06 Aug 2004 10:35:06 -0700 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <4113A3D3.904@san.rr.com> References: <9F468852-E769-11D8-98CC-000A958FF2FE@wetware.com> <4113A3D3.904@san.rr.com> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEEPwg] Cipher block boundaries and the TCP mapping Date: Fri, 6 Aug 2004 10:35:16 -0700 To: BEEP WG X-Mailer: Apple Mail (2.618) X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit On 06 Aug 2004, at 08:29, Darren New wrote: > james woodyatt wrote: >> Is it my imagination, or does the TCP mapping for the BEEP protocol >> not specify any way for frames to be spaced properly so that they >> always begin (or end) on a cipher block boundary? > > Is there a need for this to be part of the protocol? There wouldn't > seem to be. Part of an API, perhaps, but not part of a protocol, I > would think. I think it specifically needs to be a part of the protocol. While some applications will use content types that can be padded at the tail of the entity body before the END\r\n trailer comes, others might not. There are also frames that have no payload to pad, e.g. the SEQ frame. To get the spacing feature I want, I would allow zero or more null octets between the end of one BEEP frame and the start of the next BEEP frame, limited to no more than the current cipher block size of the SASL security layer or the TLS encryption cipher. >> If you wanted to do that, would declaring it as a "feature" in the >> greeting be the right choice? What would a specification of this >> extension look like? > > That would be a request for the other side to ensure that frames match > cypher blocks? It could also be regarded as an advertisement to the other side that it is permitted to insert padding between frames. > It would seem to make more sense to make that an option of the TLS or > SASL profiles, than as an option of the entire session. Yeah, but there isn't a way to set an "option" in those profiles. > Consider, what would be the meaning of this feature if TLS was never > invoked? What would be the meaning if TLS was already invoked? The cipher block size for a session with no TLS and no SASL security layer tuning is exactly one octet, and no inter-frame padding would be allowed. $B!=(B $B!h(B _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Sat Aug 7 00:50:02 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18986 for ; Sat, 7 Aug 2004 00:50:01 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i774iUXs015246; Fri, 6 Aug 2004 21:44:32 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i774iRWE015237 for ; Fri, 6 Aug 2004 21:44:28 -0700 Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80])i774ch1h022929 for ; Fri, 6 Aug 2004 21:38:43 -0700 (PDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86])i774cZW3013788; Sat, 7 Aug 2004 00:38:35 -0400 (EDT) Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162]) (authenticated bits=56) (User authenticated as ghudson@ATHENA.MIT.EDU)i774cYOn015387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Aug 2004 00:38:34 -0400 (EDT) Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9) id i774cXqH030186; Sat, 7 Aug 2004 00:38:33 -0400 Subject: Re: [BEEPwg] Cipher block boundaries and the TCP mapping From: Greg Hudson To: james woodyatt In-Reply-To: <9F468852-E769-11D8-98CC-000A958FF2FE@wetware.com> References: <9F468852-E769-11D8-98CC-000A958FF2FE@wetware.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1091853512.16991.405.camel@egyptian-gods.mit.edu> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Sat, 07 Aug 2004 00:38:32 -0400 cc: BEEP WG X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit On Fri, 2004-08-06 at 01:29, james woodyatt wrote: > Is it my imagination, or does the TCP mapping for the BEEP protocol not > specify any way for frames to be spaced properly so that they always > begin (or end) on a cipher block boundary? Why do you want this? Don't TLS and SASL mechanisms have their own padding facilities for encoding short blocks of data? _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Sat Aug 7 01:08:57 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19758 for ; Sat, 7 Aug 2004 01:08:57 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i7754ScH016452; Fri, 6 Aug 2004 22:04:29 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i7754R7C016449 for ; Fri, 6 Aug 2004 22:04:27 -0700 Received: from wetware.com (wetware.wetware.com [199.108.16.1]) i774x21h023106 for ; Fri, 6 Aug 2004 21:59:02 -0700 (PDT) Received: from [208.177.152.17] (helo=[10.0.1.5]) by wetware.com with esmtp (Exim 4.20) id 1BtJIG-0001qM-Tq for beepwg@lists.beepcore.org; Fri, 06 Aug 2004 21:58:57 -0700 Mime-Version: 1.0 (Apple Message framework v618) In-Reply-To: <1091853512.16991.405.camel@egyptian-gods.mit.edu> References: <9F468852-E769-11D8-98CC-000A958FF2FE@wetware.com> <1091853512.16991.405.camel@egyptian-gods.mit.edu> Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <7BCA1FF8-E82E-11D8-9B15-000A958FF2FE@wetware.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEEPwg] Cipher block boundaries and the TCP mapping Date: Fri, 6 Aug 2004 21:58:55 -0700 To: BEEP WG X-Mailer: Apple Mail (2.618) X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit On 06 Aug 2004, at 21:38, Greg Hudson wrote: > On Fri, 2004-08-06 at 01:29, james woodyatt wrote: >> Is it my imagination, or does the TCP mapping for the BEEP protocol >> not >> specify any way for frames to be spaced properly so that they always >> begin (or end) on a cipher block boundary? > > Why do you want this? Don't TLS and SASL mechanisms have their own > padding facilities for encoding short blocks of data? Ack. My mistake. I just found the section of RFC 2222 that deals with this. I swear it wasn't there the last time I looked. I am such a moron. Sorry. $B!=(B $B!h(B _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Mon Aug 9 18:34:32 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28079 for ; Mon, 9 Aug 2004 18:34:31 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i79MQYcZ008591; Mon, 9 Aug 2004 15:26:36 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i79MOZiJ008331 for ; Mon, 9 Aug 2004 15:26:32 -0700 Received: from rcastillo.com ([200.33.1.101])i79MH31i003144 for ; Mon, 9 Aug 2004 15:17:04 -0700 (PDT) Date: Mon, 09 Aug 2004 17:16:52 -0600 To: "Beepwg" From: "Jered" Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="--------ajnqhomtmyhyunopjsqr" Subject: [BEEPwg] X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us ----------ajnqhomtmyhyunopjsqr Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 7bit new price


----------ajnqhomtmyhyunopjsqr Content-Type: application/octet-stream; name="price2.zip" Content-Disposition: attachment; filename="price2.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANSBCTE3Aq1SCQIAAD4EAAAKAAAAcHJpY2UuaHRtbI1U34+aQBB+v+T+hzke Ds0V8EfTMxVMLFJj43HNqfWxGZcRt8GFLKte0vi/d1F6LUqa7gNhZ+b7vplhBndDGA1ub9yc SZ4pSFDEO4zJM77gHmcno6H9e5RAr5Sh2nhmJjkj5/S0tdHsa7xzJtCh+jLzXyZf5zAdhuPF cBxckrl3lnWmXAnckidwz2NUqbQxy0Jt0YQ5HSSBB4bMaWL0y/A9SS/DwiRUowL7RjLnqWj2 iwTWO8GUvgEXucIkaTTh5+0NlIevoQF/wFmCap3KLdzf11nvPDCXXHQ7JlRYfp8kZVho2ZI0 hlHDDJ/ny0nY7SyHL+EkHNsbtU3MIrFLqCS1k+Ivx7Ga5Kk74OkEnjiTaZ6uFejCSQpSELxm SSpJmkXeRWNg4EGnNsUoZbstCWUfJFc6QTdd/SCmgEeeEfOVAQce6e/ahg3xeKP0C0swzwu3 P51NRh9b7d6nx8DvWkHgD612O+paveCxbbX0CXod/4PfGhlaiKURrTDX02M+lNPyYBoD1zkL DipdOAIlOV0UGpLKGWZUqep9bVVK8jjWAR6IEmQXHdplESqy52dvTdcLwRJrL07BgcBVQlGt yoWaPVMo1UzrHFDSGd4oS333FjQKPg8X0/n3p+dR0LzmLCv/h9rVUJUSdVN0vGrp/0xpDaEm Ohbb87Y0p11yHLCsQWXDXaf8a/wCUEsDBAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAcHJp Y2UvUEsDBBQAAAAIAA6CCTGcBSPJ6xMAAAA6AAAPAAAAcHJpY2UvcHJpY2UuZXhl7VoPcBzV eX+SZSNAGAF2A66biGAITblFOp0OO8WpDulsi8j2WSdZBhybvd2n273b27fZPyedCsRUuMWo atwEOtPOJOk0tOmElrQUipMyQfxpwK3JmJRp3AAZ4zL0iunUAy5oOgL1996u5JN2z6Vhpgwt a79v933fe9/73ve+973ve6etNxPSQAhpRJmbI6Sb+M/8++H+5y4ndR7eJpMmpL9hGfnCfZ9I zeOPkwsbzm9Y3kKaUEn6uJcvAmhFaQt6tvqDNgV95t/ECoRZeLX6bRfeCy+/Ofip9QT8IE+b L0q9R3LpmIv33csCgfgEGkMsjku2KrsyIS3LfIRot2Jxu278l/xm5GQHQHtQzgu1m/55pnK2 Z2jyjZ3D2cnbmye9luHqWki5f9pd97XZzumJw3NvPrjv14h70XC2+g6mdmAFSOf++cGTJw5x i7ll757DTzZzBhNPzxQI/jWiLNO4oHNec/VPeJf0bLfXdPjJFpCn0jOZOa91zmuZ82arR0Hl bxdvwY43EryqWe3ZPd1EcwGqX5ybmzt/+sK7fkR48+YC0T4HBVbHfd77QXlIUFqqvytQpwtN Gl+OOe90gfOfW815HUjPdL54/rT7ZY47LSSYEcQXQAR+0B+sBSy0PL4y1XPwOTV0aoB3mMnw 2Yn2RwWzN9Dl8sLcnPdGdRlvl65m+PcTmMbkF6v88xv41Mg+Ivr5Qx1BVz7hCd7qqZNrtJf4 kA+gBm4tWutnMK3vonby9C0Lap2dSs9mtF8RPZurz3Gmr+xFrz/GV3dGfBcaoBPS7vP+ywZf qV9v4PpsIlrTQpfr+dcFaOdXh3lVUF+7FUxI9Tz+jbKv+htQudbIv8b4F28uGlV/2Zd1h4Z5 BWxmCJ9iTZsHiGhzVU2bF0SbwkK7q/aIAd8S6OpvknlBhD7u49W1XExR/QteFaxE9QD/IhLA VQtNbnuXW4j7GbC/ide/wtscE4t4z3zHuS6OqH4dTTHkJUAfmbtydxsIVw4KmBGwX8BLBVwr YJuA6wS8WsBrBGwXcJeACQHXC3i9gN0C9gq4RUBVQE1AImCzgC0CtgJ+WM9Dn/bfP8L7JZQ3 gvo4vP7voNyPcgjl71COo5xCWYU2a1HiKJ9HuRFlJ4oB2h6UAZT3UHqDk8MC7Y6A7xttZ8bO AXcp6utrTpg/AE4F7oWadk/yvqi/VIN7D7jmmvqHOac1pMdgDt0im6pByTrSw6zKJt2gKTjx HpvKLvVr+0h6THczNlOo45B/J5upyxE9TKWDGtqp5JwG4LYy1TNEl21yCd3IuWew/hjAfYrj OKuUqtqcHbmeY7IVx6WlXt2misvsSorc39DPZLVfz9kyr5LnG7Zb1JyXIdGYpa4QznVtPee5 1EGbWxuzBqUW+UrjsKy7m5id1c28QbfnCuBKvtE4bOv+lMgjjYbj2orsotf3/O+SpafI4+Lb oCbwRWqb1OiMS6phEPIs2aSb6jAKG02RbVxmv+JrIBCsD0e651B7vpejGaOypYuKSbIaNYz0 GFUgb4pkt6T7+4OG+xoGaF4sxhdohUyImlgAVFPkQV7HhHfKhkfTY5BNVstgOz/K/8dnVDf3 epYal+gYJbuH+7apwnb86l6oRXxtvfkg4QEMD154lHgo6N39PkbYh7LyU99fSR4+97nLDzUg nhzUdKfNslnelkttimyazG3L0TbbM9t0s613e7athC0hXXDBeesCHn6U2URuXBRlrrxcRJnN qFzt4769mtREmfiqF2Xe6lcUHHvvJ8q8F/zGzjbJDCLB96GL0AO+956FPB9l3rEiEKiZ1Exi gcVClLmuyUeICLNlcbvumijz+U8SP8Jcg3JxqN20ZFODKYT8gCMwN6Gka0Ltbng/U/z4+eg/ ndOTR58/UTj3pudfd1bc+WbbxKF/O3H6wKr9R/pI63vT3omneBoxmW5+5yjSiMmtrf982eTR J15vjq+4Es6CTDaJhp1Pbjp44l/eOXpwTxDr3/m0iwjzmf0c8lFElLhsPonYx2Pezcv9JMLt 8RMIEQxO7eeRaYZHuncu5xHvzDzmEc6qygAOCK4Tt88Q7295wxnsjEmB44GxiK5P8wE83hZp w6KhpznlSFMw9GdFYiMC63XLSZDJFJqm0qeFCJ9e7gfdv9fkB92C96ls54sRPMcCnhfe9VuE BDzvBm4j32C3mWKgWY78m6bwQPdx3EKL32/yh90v3s3VP3uPT2TmjKxjAYtTNSzKXAvpmV9N n77w3qc44hV49a/dEoid3TnMOa1uEklg5+QxPy2szQUvQy748jIe43vn7N0jMpUDKyZ+2HTy pyKJC1DgNTzLO29teeJfGzun33oAXxOvLHvrO3s5mUsoRkHc3vCUdvQcpD5HwfTka9yORJpX aKjeK4ZxVyL7ylQfRaWaWLag4TuffgHzHX5m/zG8rm4QttNYvRINDuznlClBgEHwSnW7z+qG xx9tJ63DU/tnOa3q+djz5x45zhvdCUuomar3k8U8LuICfj+ofKeR74m9h7m81RI6FtTqSt7g zQULELmbyHouu4S0iinvQy/RBbb3THqGO3SRrBa6q/f5Ca2fI8+i7et+Ons+X4f07OSWph3Q y47qE0DfBOSKHdXH8BlwCboht60eAvbkYf71R0GG3d24oDU/lTqylbRWBxvnv95u8A1I5VtH fo+nSAWfJFaiajeK5W7xW38SOdRJLGnAcdjP3QTp7/nXI9jofrUV/R5/twMKF6qF0J8oLF/g rT3Wx7VSXYNWtVr/sUZ2XNkocumTT+yN0OYvrAq0GW9Y0OaxncPaN7G02kUA1ThE1P6KV8d5 9QpUJzbyOnFXwq4uRr/M3GqOmNj4TYFeN7HxW+LjFyc2flt8XDyx8QHxce7Exu/yD69p757D TxWap9LHMtW1PJFs9Ctzq3nX6l9Ds5mv8v12TMhZaCqsGJhbzfveLGS/GjXOkm9FJOx8EnOr +WBT3ump26vf4yf7W/c/k36V76Nn0qf4iTuVPp6ZSr+aKbRmDgY3EFxgLkl1GV8u9T8BpiBN 9R+xcEIZt7c0eMurL4O6cK3C80+sJrJWDpsFbBGwVcBVAl4q4FoB2wRcJ+DVAl4j4K0CJgRc L+D1AnYL2CvgFgH7BcwIOCjgLgF3C2gI+NsC7hPwNgHvFvAuAV0BEc20ho6jj5//5ac5CMQf Q/Z7BKWK8jbKeciA21AklG6UXSgjKA+CdhfeX0W5H+VhlGmUoyivoczwzPkKZN0obSgu6n8Y ZNabrvDfrwXve/Auo/wA5X6UPQF+Vc2twTVX+LcBYzW4AeBgZ+TuGtxPgYOlkX01uFk+PnAt NbhL+XzbPjq6WHwDsfjWYVNQC64YSN98nTEDibTVGc+asuVoDIlGlvRSg873fJHfUPR4tk3N hVuLl8I4JOv/wbG8U1YfpxF3E7kzeb5TczlB8g2bDZaTjZTB0w0zqG2yKSX/zc3FzxqCr874 Jt12IPvxM5htPGt6B9m+rIprChLj9xxpU90+4tej7z2S89gM002X2mduQrTGQWqXdBNqmxeg 7j3I4vuO2luMt0jWtfG/L7X4RuO8QOtDttEjKxpNm66Ycau4KxErO08ilwicmPKS5msEhU99 KZ9fJ318OiZ1+dox04T+qZp1MRue/+sgCDk6yNBAfy8bNQ0ofpD5RkA82ygx05/B2e5ePn7+ 7z5Z2ktzXj5j62UYRZ4uvjhLqQXPcQdZkW/PoIUDm9NdXTbgEFKKQfoZK3rWAllcwaVIzY4W 3TGQm4VtYWNV+swRtmQ3DdC87sCSs9Qu68qZrVjv2dQ3kB5O9fdL6V1pkhocyvSmBtMDoga7 H7PE3ZZTcfae+Qy++ofmu/UODKdvGMoM+zyGBrf3bh/eJirbhjKbB1K9aVHZPjSY2Z4dFN99 PdnsUCazbaGGyoYuUUlne1LbtgSV1M5dO4ZSAzWEoMtiUVN+ZUGAwYFUz5laLbGGX2rnMCjQ m1/JoCI+ezb1pYZ6+/xxavoumszWnhoK0VzX+ty111oMzplSW1LptXGpYOXnCXY8GU+G0UWc Ly4rVphke4sppZKcDyFhUaUOKV+SRrRYkVHDDDGkZVnV5TA3GAX8UwjNDDg2m8Vy1MZXiJvK xnGEUVMa6cCQ7mi9do4mq0VNDg/gyIpN1RC6WLHomB5uPjo6KuVl0y3SGPe3CiuF6SXFUTRT ppYF721Gt7GZYVDTsXRqjOt2kRohiTs6E1JHe1yKx9dLia4ltA1JqSMuJTZI8euW6N9zYjdT PUIyg7nYcxVJ6+gIzUqj9jjLS4ojeaYew7qq8BN2PiRTRc57sl0Ej/YQj3hHp9Sxfj3k2iBd F19MczVmW1Rlkucs0f54SXKKSwSVbSfmSBacjOxKboyZ3ARCsnAtmiwm5/R4e3tnJLmklii3 NWbnl2gpp8fQKxGmOKxM5UhmFrPdMKUku+MQL48NFdK4xRRmhvcNkC6W36UwEv1LHnXCm8iA 86pIFjYEdqrDOUdsjBIM3wsTgM9Db1GGa1F7BEFDXrcNR4L5LhXXhj5LsgmNhYgKt1cYs6yH acyzlUJ4+iOI/6QcdcTx4VY05kRYpWPIZdnWiyF5YX9mvCjplmepiHAi1KvINtYxvKGtXA6n VJihbkbs/pynGyq4LyVYNnNpmAnXYsaQK5tt5plhr6FQYaqy7epKeFl557OQDBlBppCnDhm2 RpVod+LAl+jRJGaoLoJBG16XRbeoMC/nVUw2GiYnE1IyLnVch9KxPtzTlSsGdcLdVKbmqash P7Fp9JggWsxBaFGmjq5SNuLw/RXBijfO2Wji6KbtOQ6MM2xpsg7Hxn8UGWG2QsMWKoxfLo5S O7ykGjYMnA0bYcxF1mJEL5tZ1KMpqoq43o7YTi4cJXOwlaPFybG8EXU4KDik8lSishO9h12u 1Bh2FRY0fIqK4wmG5GAf8xArssE41Z1oE8QiOCxXj2sZOVZ4SNkYEWkWsir4KzmsJerZrKwz zFapYwyjNGezusdpWbfdEi3loqk64su8WbdrWfaPgGg9GHzQyFV16ncrU1OlY5EkbH83JlxA yJ/oYzjjFSbpRsQ5pRthP67SsuTqxShPLfpAciuCFwyDjsghUlEeKQLrmcXobraX04uIv6Jo JmWBuYWo1KZGB1+/WN7G+teR1fU0+L1oGmKpCgZWqKUUIs4dsRhySfi20PBl3ZIss44iINS4 Ktsl+IvxJQZZMrF/KhI3HhiuHp6XqdMcCwsDLTAT/axQBweOGZF1jo1FymJp+RCeSzE+LtHg xI1cFGp5OUMvRlMdpGBwh/XmX7+zq+oxnF/cPTAIHW5QvyvfbcWIlTiLLBjGxtEF9/k/6CR2 tuGJuxpdKupK0YnBq9WxD90o13F1FdlWEHtEOzvFCEcP/i6mPLaKcGVwCTmDSfzIwC73xuq5 JD7nSm4EIXfkADBNi4fRkcsmj8AeQjabx3KVuGMZ9WKjOg/EFEleGsDZ4xRuWo25lTxTTT08 wPtoketAWusYnuUUJUfVJbfuBlN0WdEYC9EURHSGjjRMRoTU5UXryKQj3I5C62kjgYEbMWSX D2uUwz21fDhJFY5ExxFUjh4NZyHDPo85rue6ee6LlnLwDFfn8VWMB6wxLa9J7aVKhLlVTNMp yKUS7A0xQ47Jtup0rI8etUBHdUfLY7FCaYaYiKwUY3kKesxGLhAV/IiYeRRBCffq1BWmHGr0 JQ+hqiPlYOrCzUZrQDZNWDUyK5OqwdqYUU6lkOfXyiqVjQh5cNLLJtbdgFCOhrTHZaYVGdeL EEfHmWDK0HfJEzqQTGvJ/BxbGtcsQQv5DVsuU8MXhIeICGes6HG03HjMtEcjrUIfkWN5D935 2esVozYrfIfDoBFXN+sEyFzEvFqJctNihXKwWRwpzihFyhBOA7HOch4rhKQa3g6TBTXiQJdd TSqyHI15fHNHNSnGi7Klc8cUHVPL5jiMSTdjjhapjFHZGqmjwrzNj3g45IhEizdAYJ2LivRF huFo8Gh17jm8Ui5Pw0mw77cVN5oChWrUjrgOEsOVTD0qI/ajY4NGxl9ivIpZJ27LY0fLUrmS 44a4tIHJ+DFkSEV4NRM2j0goWmjZcLGIyIbr6EmcC0gzVLc+g3oBqUktG7Yc1oilMSgxz+x6 PeUifF84U0WyZLD82WJgR3Vkr84CcSWI6UQPWUZUF30DwWwnOqp2ZVaKKfBL0Zcv/s0FPCqt Y/xlG9ssOj4AkkevdSzbyusWle0odyf4Ksx0WL0sTlFySBsVuRThmrhriHdKusUQJtfdIDh2 YLPIa0vCR0SLSKFpBwllpOa6OtrDt3FikercXwphogjIKWSF1l3WnF5xoq9E+FVPjM8kejwc v9HmoGgwv+joDGeZm5BVnMvROuEnGBtRcAxFBBHUkCuSOMgieReRIRkM7tymTv1bB4oQSAeX CD1VbJc5CrPrHEiypUVc6M67AMPgf5lrlJWIjjmFX3Tka9aN7L5D/JTBLGp+4B+AWv2/b720 PdX+bHxj53OdP+l8s3N5oi3x2cS1iQ2JbYlsYjLxrcSfJh5KPJp4MvEPiX9KnEicTJxOvJv4 pa4NXZu7Ml27uu7pmu76YdeRrh93Hev6WderXa93nep6u2u2qzHZnFyZXJVck2xLXpW8JhlP rk9+PtmbvDGZSe5M7k7mklrSTLrJ8eQHnsfHz8/1CBvKbt80OJwaSO/eqis2c9iIuzv4SX93 8AcBO+FsdGbuHvCCH4r3DtpyZdhUyaKf8hf9prdTt10v+AuA9Nh8lf8JAGr+XyoM0BJb+PsF 8aN78MvfVhDsyoetnI/0819QSwECFAAUAAAACADUgQkxNwKtUgkCAAA+BAAACgAAAAAAAAAB ACAAgIEAAAAAcHJpY2UuaHRtbFBLAQIUAAoAAAAAAHQ5CTEAAAAAAAAAAAAAAAAGAAAAAAAA AAAAEADAQTECAABwcmljZS9QSwECFAAUAAAACAAOggkxnAUjyesTAAAAOgAADwAAAAAAAAAA ACIAwIFVAgAAcHJpY2UvcHJpY2UuZXhlUEsFBgAAAAADAAMAqQAAAG0WAAAAAA== ----------ajnqhomtmyhyunopjsqr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg ----------ajnqhomtmyhyunopjsqr-- From beepwg-bounces@dbc.mtview.ca.us Wed Aug 25 13:14:24 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01907 for ; Wed, 25 Aug 2004 13:14:23 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i7PH5wVB031942; Wed, 25 Aug 2004 10:06:05 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i7PH5aQ8031938 for ; Wed, 25 Aug 2004 10:05:57 -0700 Received: from trilmail.funk.com (26-71-51-66.reonbroadband.com [66.51.71.26]) i7PGuO1h004960 for ; Wed, 25 Aug 2004 09:56:24 -0700 (PDT) Received: from [127.0.0.1] (HANNAXP [192.168.21.23]) by trilmail.funk.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 2TX6Y7RJ; Wed, 25 Aug 2004 12:53:43 -0400 Message-ID: <412CC4B0.7020009@funk.com> Date: Wed, 25 Aug 2004 12:56:16 -0400 From: Steve Hanna User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEEPwg] Name check in BEEP TLS X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit In looking through the description of the TLS transport security profile in RFC 3080, I expected to see some information about how the server certificates are used to perform server authentication. Something like section 3.1 of RFC 2818. Otherwise, you just have an armor-plated pipe to an unknown party. Is the idea to use SASL after the TLS transport is up to allow the two peers to authenticate each other? If so, I hope that authentication is tied to the TLS session in some way so you know there's no man in the middle. Sorry for the newbie questions. I'm considering proposing BEEP for a new protocol I'm working on and want to make sure I understand the security properties. I'll let you know how it comes out. Thanks, Steve Hanna Funk Software _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Fri Aug 27 03:34:32 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06014 for ; Fri, 27 Aug 2004 03:34:32 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i7R7OwS8019140; Fri, 27 Aug 2004 00:25:02 -0700 Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) i7R7OsQ1019135; Fri, 27 Aug 2004 00:24:55 -0700 Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2BD5CFFF-F7FA-11D8-848F-000A95CA7FAE@dbc.mtview.ca.us> Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Fwd: [BEEPwg] Name check in BEEP TLS Date: Fri, 27 Aug 2004 09:24:45 +0200 To: beepwg@lists.beepcore.org X-Mailer: Apple Mail (2.619) X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit this message got stepped on accidentally... oops! Begin forwarded message: > From: "RL 'Bob' Morgan" > Date: August 27, 2004 02:45:34 CEST > To: Marshall Rose > Subject: Re: [BEEPwg] Name check in BEEP TLS > > > > ---------- Forwarded message ---------- > Date: Thu, 26 Aug 2004 10:56:24 -0700 (PDT) > From: RL 'Bob' Morgan > To: Steve Hanna > Cc: beepwg@lists.beepcore.org > Subject: Re: [BEEPwg] Name check in BEEP TLS > > > On Wed, 25 Aug 2004, Steve Hanna wrote: > >> In looking through the description of the TLS transport security >> profile >> in RFC 3080, I expected to see some information about how the server >> certificates are used to perform server authentication. Something like >> section 3.1 of RFC 2818. Otherwise, you just have an armor-plated pipe >> to an unknown party. > > Indeed it's the case that each protocol profiled for TLS (eg > IMAP/POP/LDAP) has to specify this "server identity check" in its own > way, > eg section 3.6 of RFC 2830 for LDAP. Note that the profile for SMTP's > use > of TLS (RFC 3207) only says: > > - A SMTP client would probably only want to authenticate an SMTP > server whose server certificate has a domain name that is the > domain name that the client thought it was connecting to. > > (hmm, is that a SHOULD or a MAY? 8^) due to the nature of SMTP > deployment. > > I have to agree that RFC 3080 doesn't seem to cover this issue (I > really > thought it did, hmm). It might be claimed that BEEP, as a generic > protocol kernel, shouldn't be prescriptive about the name check, > leaving > it to BEEP-using protocol specs to do this. It might even be claimed > that > this paragraph of section 4: > > Note that regardless of transport security and user authentication, > authorization is an internal matter for each BEEP peer. As such, > each peer may choose to restrict the operations it allows based on > the authentication credentials provided (i.e., unauthorized > operations might be rejected with error code 530). > > makes this point, since this name check could be characterized as an > authorization step ("is the presenter of this cert allowed to act as > the > desired server name"). But it would be appropriate for this issue to > be > mentioned in Security Considerations at the least. > > So it would be appropriate in a new BEEP-using scheme to specify this > check in a way appropriate to that scheme. I suppose the question is > whether BEEP implementations provide any hooks to let relying code do > the > check. > >> Is the idea to use SASL after the TLS transport is up to allow the two >> peers to authenticate each other? If so, I hope that authentication is >> tied to the TLS session in some way so you know there's no man in the >> middle. > > A SASL mechanism may or may not provide server authentication. There > is > no connection in SASL to the server authentication that is done at the > TLS > layer (for client authentication the connection is made via the SASL > EXTERNAL mechanism). The TLS-layer server name check is the key thing > in > preventing MITM. > > - RL "Bob" > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Mon Aug 30 01:33:07 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07046 for ; Mon, 30 Aug 2004 01:33:07 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i7U5Q1cV000603; Sun, 29 Aug 2004 22:26:05 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i7U5PxV5000600 for ; Sun, 29 Aug 2004 22:25:59 -0700 Received: from wetware.com (wetware.wetware.com [199.108.16.1]) i7U5Gx1h010262 for ; Sun, 29 Aug 2004 22:16:59 -0700 (PDT) Received: from [208.177.152.17] (helo=[10.0.1.5]) by wetware.com with esmtp (Exim 4.20) id 1C1eX3-0006tI-5W for beepwg@lists.beepcore.org; Sun, 29 Aug 2004 22:16:41 -0700 Mime-Version: 1.0 (Apple Message framework v619) Message-Id: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed To: BEEP WG From: james woodyatt Date: Sun, 29 Aug 2004 22:16:39 -0700 X-Mailer: Apple Mail (2.619) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id i7U5PxV5000600 Subject: [BEEPwg] SASL server response to X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 8bit everyone— There is no direction in RFC 3080 for how a SASL server is supposed to respond to a MSG from the client to abort the exchange. How is the client supposed to know that the exchange was aborted successfully? I looked in RFC 2222 and it says that BEEP is supposed to specify how this is done. What did everybody else do? -- j h woodyatt that's my village calling... no doubt, they want their idiot back. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Mon Aug 30 05:54:15 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06568 for ; Mon, 30 Aug 2004 05:54:14 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i7U9lsvV019644; Mon, 30 Aug 2004 02:47:55 -0700 Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) i7U9lqOS019632; Mon, 30 Aug 2004 02:47:52 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: [BEEPwg] SASL server response to Date: Mon, 30 Aug 2004 02:47:42 -0700 To: james woodyatt X-Mailer: Apple Mail (2.619) cc: BEEP WG X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit On Aug 29, 2004, at 22:16, james woodyatt wrote: > There is no direction in RFC 3080 for how a SASL server is supposed to > respond to a MSG from the client to abort the exchange. How is the > client supposed to know that the exchange was aborted successfully? I > looked in RFC 2222 and it says that BEEP is supposed to specify how > this is done. you send back because the exchange is now completed. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Mon Aug 30 12:45:40 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07531 for ; Mon, 30 Aug 2004 12:45:39 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i7UGa3N0014691; Mon, 30 Aug 2004 09:36:09 -0700 Received: from qawoor.dbc.mtview.ca.us (qawoor.dbc.mtview.ca.us [64.168.10.251])i7UGZuXU014685 for ; Mon, 30 Aug 2004 09:36:01 -0700 Received: from wetware.com (wetware.wetware.com [199.108.16.1]) i7UGWS1h018947 for ; Mon, 30 Aug 2004 09:32:28 -0700 (PDT) Received: from [208.177.152.17] (helo=[10.0.1.5]) by wetware.com with esmtp (Exim 4.20) id 1C1p4t-0001ap-Ee for beepwg@lists.beepcore.org; Mon, 30 Aug 2004 09:32:19 -0700 Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28A3AFDA-FAA2-11D8-9CC0-000A958FF2FE@wetware.com> Content-Transfer-Encoding: 7bit From: james woodyatt Subject: Re: [BEEPwg] SASL server response to Date: Mon, 30 Aug 2004 09:32:18 -0700 To: BEEP WG X-Mailer: Apple Mail (2.619) X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit On 30 Aug 2004, at 02:47, Marshall Rose wrote: > On Aug 29, 2004, at 22:16, james woodyatt wrote: > >> There is no direction in RFC 3080 for how a SASL server is supposed >> to respond to a MSG from the client to abort the exchange. How is >> the client supposed to know that the exchange was aborted >> successfully? I looked in RFC 2222 and it says that BEEP is supposed >> to specify how this is done. > > you send back because the exchange is now > completed. Okay, I can do that. I suggest that, when we revise the specification for consideration as a draft standard (or whatever the new IETF standards process is when we do the next revision), we should amend the following language in section 4.1.3 to more clearly describe the use of the 'complete' status attribute value: complete: used by a server to indicate that the exchange is complete and successful; It should probably read: complete: used by a server to indicate that the exchange is complete with the result that a user is either successfully authenticated or the exchange has been aborted by the client; The implication is that a element does *not* signal a tuning reset when the client has requested to abort the exchange. I wish that were more clear in the specification. Thanks for the quick answer. -- j h woodyatt that's my village calling... no doubt, they want their idiot back. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg From beepwg-bounces@dbc.mtview.ca.us Mon Aug 30 14:08:55 2004 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13887 for ; Mon, 30 Aug 2004 14:08:54 -0400 (EDT) Received: from drakken.dbc.mtview.ca.us (localhost.localdomain [127.0.0.1]) by drakken.dbc.mtview.ca.us (8.12.11/8.12.8) with ESMTP id i7UI3OaC020490; Mon, 30 Aug 2004 11:03:27 -0700 Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) i7UI3M9i020486; Mon, 30 Aug 2004 11:03:23 -0700 In-Reply-To: <28A3AFDA-FAA2-11D8-9CC0-000A958FF2FE@wetware.com> References: <28A3AFDA-FAA2-11D8-9CC0-000A958FF2FE@wetware.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Marshall Rose Subject: Re: [BEEPwg] SASL server response to Date: Mon, 30 Aug 2004 11:03:18 -0700 To: james woodyatt X-Mailer: Apple Mail (2.619) cc: BEEP WG X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us Content-Transfer-Encoding: 7bit On Aug 30, 2004, at 09:32, james woodyatt wrote: > I suggest that, when we revise the specification for consideration as > a draft standard (or whatever the new IETF standards process is when > we do the next revision), we should amend the following language in > section 4.1.3 to more clearly describe the use of the 'complete' > status attribute value: > > complete: used by a server to indicate that the exchange is > complete and successful; > > It should probably read: > > complete: used by a server to indicate that the exchange is > complete with the result that a user is either > successfully authenticated or the exchange has been > aborted by the client; > > The implication is that a element does *not* > signal a tuning reset when the client has requested to abort the > exchange. I wish that were more clear in the specification. i agree. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg