From beepwg-bounces@dbc.mtview.ca.us Mon Oct 31 13:44:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWeeF-0006LX-G9 for beep-archive@megatron.ietf.org; Mon, 31 Oct 2005 13:44:49 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27543 for ; Mon, 31 Oct 2005 13:44:27 -0500 (EST) 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 j9VIdXNc009719; Mon, 31 Oct 2005 10:39:37 -0800 Received: from borg.juniper.net (borg.juniper.net [207.17.137.119]) j9VIdWSv009716 for ; Mon, 31 Oct 2005 10:39:32 -0800 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 31 Oct 2005 10:39:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,270,1125903600"; d="scan'208,217"; a="507297935:sNHT37477856" Received: from antitop.jnpr.net ([172.24.15.27]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 10:39:24 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Oct 2005 10:39:24 -0800 Message-ID: Thread-Topic: after sasl? Thread-Index: AcXeSmn6jwx7RuUcQsmwk6sZFUCnsg== From: "Kent Watsen" To: X-OriginalArrivalTime: 31 Oct 2005 18:39:24.0492 (UTC) FILETIME=[6A74E8C0:01C5DE4A] Subject: [BEEPwg] after sasl? 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: , Content-Type: multipart/mixed; boundary="===============0017131038968090095==" Sender: beepwg-bounces@dbc.mtview.ca.us Errors-To: beepwg-bounces@dbc.mtview.ca.us This is a multi-part message in MIME format. --===============0017131038968090095== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5DE4A.6A38072B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5DE4A.6A38072B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry if this has been answered before, but my search through the archives and other online resources did not provide a definitive answer... =20 Is another exchange expected after the SASL profile is used for authentication? The spec implies there is a "tuning reset" after each tuning profile is used and it implies that the SASL profile is a tuning profile, but I can't find examples illustrating a new exchange either... =20 It would be surprising for a server to advertise its "exchange" profiles before the client has authenticated itself. Not only does this unnecessarily reveal information, but the server might want to select which profiles to advertised based on the authorizations of the authenticated client =20 Thanks Kent =20 =20 ------_=_NextPart_001_01C5DE4A.6A38072B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry if this has = been answered before, but my search through the archives and other online resources = did not provide a definitive answer…

Is another = <greeting> exchange expected after the SASL profile is used for = authentication? The spec implies there is a "tuning reset" after each tuning profile is = used and it implies that the SASL profile is a tuning profile, but I can't = find examples illustrating a new <greeting> exchange = either...

It would be = surprising for a server to advertise its “exchange” profiles before the = client has authenticated itself. Not only does this unnecessarily reveal = information, but the server might want to select which profiles to advertised based on = the authorizations of the authenticated client

Thanks

Kent

------_=_NextPart_001_01C5DE4A.6A38072B-- --===============0017131038968090095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg --===============0017131038968090095==-- From beepwg-bounces@dbc.mtview.ca.us Mon Oct 31 15:56:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWghY-0007fP-Iz for beep-archive@megatron.ietf.org; Mon, 31 Oct 2005 15:56:20 -0500 Received: from drakken.dbc.mtview.ca.us ([168.143.123.173]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09150 for ; Mon, 31 Oct 2005 15:56:00 -0500 (EST) 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 j9VKqhaX011187; Mon, 31 Oct 2005 12:52:44 -0800 Received: from mail.sarbserve.com (mail.sarbserve.com [24.244.171.76]) j9VKqeh7011184 for ; Mon, 31 Oct 2005 12:52:41 -0800 Received: from [IPv6:::1] (mrose@localhost.localdomain [127.0.0.1]) j9VKqQDZ016122; Mon, 31 Oct 2005 12:52:30 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: From: Marshall Rose Subject: Re: [BEEPwg] after sasl? Date: Mon, 31 Oct 2005 12:52:26 -0800 To: Kent Watsen X-Mailer: Apple Mail (2.734) X-MIME-Autoconverted: from quoted-printable to 8bit by drakken.dbc.mtview.ca.us id j9VKqeh7011184 cc: beepwg@lists.beepcore.org 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: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA09150 > Sorry if this has been answered before, but my search through the =20 > archives and other online resources did not provide a definitive =20 > answer=85 > > > > Is another exchange expected after the SASL profile is =20 > used for authentication? The spec implies there is a "tuning =20 > reset" after each tuning profile is used and it implies that the =20 > SASL profile is a tuning profile, but I can't find examples =20 > illustrating a new exchange either... > > > > It would be surprising for a server to advertise its =93exchange=94 =20 > profiles before the client has authenticated itself. Not only does =20 > this unnecessarily reveal information, but the server might want to =20 > select which profiles to advertised based on the authorizations of =20 > the authenticated client authentication, per se, doesn't qualify as a tuning reset; however, =20 if the sasl method also involves additional security features, viz., =20 integrity/privacy, then that does get you a tuning reset. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://drakken.dbc.mtview.ca.us/mailman/listinfo/beepwg