From kitten-bounces@lists.ietf.org Thu Jul 19 17:49:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdri-0001qX-Rm; Thu, 19 Jul 2007 17:48:54 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IBdrh-0001qS-T2 for kitten-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 17:48:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBdrh-0001qK-HS for kitten@lists.ietf.org; Thu, 19 Jul 2007 17:48:53 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBdrh-0003Mv-21 for kitten@lists.ietf.org; Thu, 19 Jul 2007 17:48:53 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 23BA03BEC0; Thu, 19 Jul 2007 23:48:52 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28763-01-13; Thu, 19 Jul 2007 23:48:51 +0200 (CEST) Received: from [83.178.2.27] (m83-178-2-27.cust.tele2.se [83.178.2.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 0138D3BE97; Thu, 19 Jul 2007 23:48:50 +0200 (CEST) Message-ID: <469FDC45.1090104@it.su.se> Date: Thu, 19 Jul 2007 23:48:53 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: ietf-krb-wg@anl.gov, kitten@lists.ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.058 tagged_above=-99 required=7 tests=[AWL=0.254, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: bar-bof on saml & kerberos intersections (skint?) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org For want of a better name for it - Bob Morgan and I are going to talk about the various ways in which SAML and Kerberos can make life more interesting together than each can separately and we'd like some company! We're aiming for monday night right after krb-wg. Interested parties should hover after krb-wg in whatever room that meets in. Cheers Leif _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jul 19 18:23:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBeOx-0004BV-2F; Thu, 19 Jul 2007 18:23:15 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IBeOw-0004BN-0d for kitten-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 18:23:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBeOv-0004BF-NI for kitten@lists.ietf.org; Thu, 19 Jul 2007 18:23:13 -0400 Received: from cluster-a.mailcontrol.com ([80.69.8.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBeOt-00045z-Mv for kitten@lists.ietf.org; Thu, 19 Jul 2007 18:23:13 -0400 Received: from rly32a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly32a.srv.mailcontrol.com (MailControl) with ESMTP id l6JMN8Mx023222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jul 2007 23:23:09 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly32a.srv.mailcontrol.com (MailControl) id l6JMMxsN022717 for kitten@lists.ietf.org; Thu, 19 Jul 2007 23:22:59 +0100 Received: from cybersafe.ltd.uk (host90-152-10-238.ipv4.regusnet.com [90.152.10.238]) by rly32a-eth0.srv.mailcontrol.com (envelope-sender Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id l6JMMwB7022690; Thu, 19 Jul 2007 23:22:59 +0100 (BST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 19 Jul 2007 23:20:34 +0100 Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D30334D83@postman-pat.csafe.local> In-Reply-To: <469FDC45.1090104@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bar-bof on saml & kerberos intersections (skint?) Thread-Index: AcfKTqPnWKR0lWvFQF+SFhojtkP8rgAA/ZCQ References: <469FDC45.1090104@it.su.se> From: "Tim Alsop" To: "Leif Johansson" , , X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.65.1.142 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: RE: bar-bof on saml & kerberos intersections (skint?) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Leif, I am very interested in this, but I am not attending IETF meeting this time. So, can I ask if a summary of discussions is going to be published for us to read and comment on ? I worked with bob on Oasis WG for SAML 2.0 and tried to introduce Kerberos, but was only partially successful, so I am keen to contribute in some way as it seems there are now more people interested. Thanks, Tim Alsop CyberSafe -----Original Message----- From: Leif Johansson [mailto:leifj@it.su.se]=20 Sent: 19 July 2007 22:49 To: ietf-krb-wg@anl.gov; kitten@lists.ietf.org Subject: bar-bof on saml & kerberos intersections (skint?) For want of a better name for it - Bob Morgan and I are going to talk about the various ways in which SAML and Kerberos can make life more interesting together than each can separately and we'd like some company! We're aiming for monday night right after krb-wg. Interested parties should hover after krb-wg in whatever room that meets in. Cheers Leif _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jul 19 18:58:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBewo-0003m4-C3; Thu, 19 Jul 2007 18:58:14 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IBewn-0003lN-Rh for kitten-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 18:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBewn-0003kO-Hm for kitten@lists.ietf.org; Thu, 19 Jul 2007 18:58:13 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBewn-0004pr-4J for kitten@lists.ietf.org; Thu, 19 Jul 2007 18:58:13 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id AAA15246; Fri, 20 Jul 2007 00:57:43 +0200 (MESZ) From: Martin Rex Message-Id: <200707192257.l6JMvhdG025310@fs4113.wdf.sap.corp> To: Tim.Alsop@CyberSafe.Com (Tim Alsop) Date: Fri, 20 Jul 2007 00:57:43 +0200 (MEST) In-Reply-To: <0D8F2EFD3A10E24DAEEA48EA6DA07D30334D83@postman-pat.csafe.local> from "Tim Alsop" at Jul 19, 7 11:20:34 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ietf-krb-wg@anl.gov, kitten@lists.ietf.org Subject: Re: bar-bof on saml & kerberos intersections (skint?) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Tim, Tim Alsop wrote: > > I am very interested in this, but I am not attending IETF meeting this > time. So, can I ask if a summary of discussions is going to be published > for us to read and comment on ? I worked with bob on Oasis WG for SAML > 2.0 and tried to introduce Kerberos, but was only partially successful, > so I am keen to contribute in some way as it seems there are now more > people interested. It is possible to participate IETF meetings virtually over the internet. I've been doing for the last couple of meetings, and it works remarkably well (except for the time offset between me in old Europe and the majority of meetings in the US). The audiocast is usually very good, most of the presentations become available online from the IETF website short before or during the meeting, so you can watch the slides as well. And for meetings of the security area, there is a significant amount of talk in the jabber rooms (plus some amount of jabber scribing) and comments from remote participants into jabber are usually fed back into the meeting. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jul 19 19:05:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBf45-0002p2-QK; Thu, 19 Jul 2007 19:05:45 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IBf44-0002ox-JY for kitten-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 19:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBf44-0002op-9x for kitten@lists.ietf.org; Thu, 19 Jul 2007 19:05:44 -0400 Received: from cluster-a.mailcontrol.com ([80.69.8.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBf43-00053p-Rm for kitten@lists.ietf.org; Thu, 19 Jul 2007 19:05:44 -0400 Received: from rly25a.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly25a.srv.mailcontrol.com (MailControl) with ESMTP id l6JN5fcA022120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jul 2007 00:05:42 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly25a.srv.mailcontrol.com (MailControl) id l6JN51RC017825 for kitten@lists.ietf.org; Fri, 20 Jul 2007 00:05:01 +0100 Received: from cybersafe.ltd.uk (host90-152-10-238.ipv4.regusnet.com [90.152.10.238]) by rly25a-eth0.srv.mailcontrol.com (envelope-sender Tim.Alsop@CyberSafe.Com) (MIMEDefang) with ESMTP id l6JN511H017815; Fri, 20 Jul 2007 00:05:01 +0100 (BST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 20 Jul 2007 00:02:37 +0100 Message-ID: <0D8F2EFD3A10E24DAEEA48EA6DA07D30334D84@postman-pat.csafe.local> In-Reply-To: <200707192257.l6JMvhdG025310@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: bar-bof on saml & kerberos intersections (skint?) Thread-Index: AcfKWEAVvKRNmslySEKuEwGhWYZISAAAGj3g References: <0D8F2EFD3A10E24DAEEA48EA6DA07D30334D83@postman-pat.csafe.local> from "Tim Alsop" at Jul 19, 7 11:20:34 pm <200707192257.l6JMvhdG025310@fs4113.wdf.sap.corp> From: "Tim Alsop" To: X-Scanned-By: MailControl A-07-07-10 (www.mailcontrol.com) on 10.65.1.135 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ietf-krb-wg@anl.gov, kitten@lists.ietf.org Subject: RE: bar-bof on saml & kerberos intersections (skint?) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Martin, Thankyou. I wasn't sure about this meeting because it sounded like it might be a less formal meeting (e.g. chat around coffee table) instead of a formal scheduled meeting. So, if the meeting will be online then I look forward to joining in. Take care, Tim=20 -----Original Message----- From: Martin Rex [mailto:Martin.Rex@sap.com]=20 Sent: 19 July 2007 23:58 To: Tim Alsop Cc: leifj@it.su.se; ietf-krb-wg@anl.gov; kitten@lists.ietf.org Subject: Re: bar-bof on saml & kerberos intersections (skint?) Tim, Tim Alsop wrote: >=20 > I am very interested in this, but I am not attending IETF meeting this > time. So, can I ask if a summary of discussions is going to be published > for us to read and comment on ? I worked with bob on Oasis WG for SAML > 2.0 and tried to introduce Kerberos, but was only partially successful, > so I am keen to contribute in some way as it seems there are now more > people interested. It is possible to participate IETF meetings virtually over the internet. I've been doing for the last couple of meetings, and it works remarkably well (except for the time offset between me in old Europe and the majority of meetings in the US). The audiocast is usually very good, most of the presentations become available online from the IETF website short before or during the meeting, so you can watch the slides as well. And for meetings of the security area, there is a significant amount of talk in the jabber rooms (plus some amount of jabber scribing) and comments from remote participants into jabber are usually fed back into the meeting. -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jul 19 19:35:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfWk-0000Wm-TG; Thu, 19 Jul 2007 19:35:22 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IBfWj-0000Wh-MK for kitten-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 19:35:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBfWj-0000WZ-CY for kitten@lists.ietf.org; Thu, 19 Jul 2007 19:35:21 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBfWf-0005w5-Og for kitten@lists.ietf.org; Thu, 19 Jul 2007 19:35:21 -0400 Received: from centralmail4brm.central.Sun.COM ([129.147.62.198]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6JNZGhb028111 for ; Thu, 19 Jul 2007 23:35:17 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail4brm.central.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6JNZFoS011709 for ; Thu, 19 Jul 2007 17:35:16 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l6JNZFTW026114; Thu, 19 Jul 2007 18:35:15 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l6JNZEAS026113; Thu, 19 Jul 2007 18:35:14 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 19 Jul 2007 18:35:14 -0500 From: Nicolas Williams To: Martin Rex Message-ID: <20070719233513.GC25464@Sun.COM> Mail-Followup-To: Martin Rex , Tim Alsop , leifj@it.su.se, ietf-krb-wg@anl.gov, kitten@lists.ietf.org References: <0D8F2EFD3A10E24DAEEA48EA6DA07D30334D83@postman-pat.csafe.local> <200707192257.l6JMvhdG025310@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200707192257.l6JMvhdG025310@fs4113.wdf.sap.corp> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ietf-krb-wg@anl.gov, Tim Alsop , kitten@lists.ietf.org Subject: Re: bar-bof on saml & kerberos intersections (skint?) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Fri, Jul 20, 2007 at 12:57:43AM +0200, Martin Rex wrote: > Tim, > > Tim Alsop wrote: > > > > I am very interested in this, but I am not attending IETF meeting this > > time. So, can I ask if a summary of discussions is going to be published > > for us to read and comment on ? I worked with bob on Oasis WG for SAML > > 2.0 and tried to introduce Kerberos, but was only partially successful, > > so I am keen to contribute in some way as it seems there are now more > > people interested. > > It is possible to participate IETF meetings virtually over the internet. Indeed, and one can even present remotely (but I wouldn't recommend it: a) it doesn't work very well, b) even if it did you miss important communication opportunities, c) it deprives the IETF/ISOC of funds). But bar BoFs are another story. Bar BoFs typically happen at a bar or at a restaurant, typically a noisy one, though preferably not so noisy, and typically too far from IETF tele-conferencing infrastructure. It has to be this way because they are not formally scheduled BoFs, therefore there's no reserved room or tele-conferencing facilities, and, since they are not formally scheduled and participants want to attend other formally scheduled meetings, bar BoFs have to happen before/after the IETF day begins/ends or during lunch, which means during breakfast, lunch or dinner, which means "where there is food." Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jul 20 01:50:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBlNZ-0005Io-82; Fri, 20 Jul 2007 01:50:17 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IBlNX-0005IG-Ko for kitten-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 01:50:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBlNX-0005I8-0d for kitten@lists.ietf.org; Fri, 20 Jul 2007 01:50:15 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBlNV-0005Ou-JJ for kitten@lists.ietf.org; Fri, 20 Jul 2007 01:50:14 -0400 Received: from [194.67.244.30] (natchern.atom.ru [194.67.244.30]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 20 Jul 2007 06:50:11 +0100 Message-ID: <46A04E45.4040702@isode.com> Date: Fri, 20 Jul 2007 09:55:17 +0400 From: Alexey Melnikov User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) To: Leif Johansson References: <469FDC45.1090104@it.su.se> In-Reply-To: <469FDC45.1090104@it.su.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ietf-krb-wg@anl.gov, kitten@lists.ietf.org Subject: Re: bar-bof on saml & kerberos intersections (skint?) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Leif Johansson wrote: > For want of a better name for it - Bob Morgan and I are going to > talk about the various ways in which SAML and Kerberos can make > life more interesting together than each can separately and we'd > like some company! > > We're aiming for monday night right after krb-wg. Interested > parties should hover after krb-wg in whatever room that meets in. > I wish I could attend. I have a conflict with Apps Review Team meeting. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Fri Jul 20 07:34:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBql2-0004wK-AL; Fri, 20 Jul 2007 07:34:52 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IBql0-0004wE-MC for kitten-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 07:34:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBql0-0004w5-Bz for kitten@lists.ietf.org; Fri, 20 Jul 2007 07:34:50 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBqky-0004hT-6y for kitten@lists.ietf.org; Fri, 20 Jul 2007 07:34:50 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 4C0FF741ED; Fri, 20 Jul 2007 13:34:47 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16415-01-35; Fri, 20 Jul 2007 13:34:46 +0200 (CEST) Received: from [83.188.169.224] (m83-188-169-224.cust.tele2.se [83.188.169.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 8144974137; Fri, 20 Jul 2007 13:34:43 +0200 (CEST) Message-ID: <46A09DD4.3060909@it.su.se> Date: Fri, 20 Jul 2007 13:34:44 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Tim Alsop References: <0D8F2EFD3A10E24DAEEA48EA6DA07D30334D83@postman-pat.csafe.local> from "Tim Alsop" at Jul 19, 7 11:20:34 pm <200707192257.l6JMvhdG025310@fs4113.wdf.sap.corp> <0D8F2EFD3A10E24DAEEA48EA6DA07D30334D84@postman-pat.csafe.local> In-Reply-To: <0D8F2EFD3A10E24DAEEA48EA6DA07D30334D84@postman-pat.csafe.local> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.269 tagged_above=-99 required=7 tests=[AWL=0.043, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ietf-krb-wg@anl.gov, kitten@lists.ietf.org Subject: Re: bar-bof on saml & kerberos intersections (skint?) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Tim Alsop wrote: > Martin, > > Thankyou. I wasn't sure about this meeting because it sounded like it > might be a less formal meeting (e.g. chat around coffee table) instead > of a formal scheduled meeting. So, if the meeting will be online then I > look forward to joining in. > > Yes this is a non-formal "coffee-table" bof, otherwise it would be on the agenda ;-) Typically you need a few of these before you go ahead (if ever) and request a formal bof slot. I'll try to take notes an summarize on the krb-wg list. Cheers Leif _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Jul 23 15:48:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3tk-00028Q-C5; Mon, 23 Jul 2007 15:48:52 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1ID3tj-00028L-Ak for kitten-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 15:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3tj-00028D-0x for kitten@lists.ietf.org; Mon, 23 Jul 2007 15:48:51 -0400 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID3th-0001U5-Lj for kitten@lists.ietf.org; Mon, 23 Jul 2007 15:48:51 -0400 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.06) with ESMTP id l6NJmloe018386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Jul 2007 12:48:48 -0700 X-Auth-Received: from [130.129.84.240] ([130.129.84.240]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l6NJmkcG013064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Jul 2007 12:48:47 -0700 Date: Mon, 23 Jul 2007 14:48:44 -0500 (CDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@perf.cac.washington.edu To: IETF Kerberos WG In-Reply-To: <469FDC45.1090104@it.su.se> Message-ID: References: <469FDC45.1090104@it.su.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.3.2.304607, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.7.23.123255 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: -1.0 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: kitten@lists.ietf.org Subject: Re: bar-bof on saml & kerberos intersections (skint?) X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org As one possible angle among many, there is discussion about requirements for getting Kerberos tickets to webapps/middle-tiers here: https://spaces.internet2.edu/display/SHIB/Kerberos+Tickets+for+Middle+Tiers This is in the context of the Shibboleth software package, but most elements should apply to any implementation. - RL "Bob" On Thu, 19 Jul 2007, Leif Johansson wrote: > > For want of a better name for it - Bob Morgan and I are going to > talk about the various ways in which SAML and Kerberos can make > life more interesting together than each can separately and we'd > like some company! > > We're aiming for monday night right after krb-wg. Interested > parties should hover after krb-wg in whatever room that meets in. > > Cheers Leif > > > _______________________________________________ > Kitten mailing list > Kitten@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/kitten > _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 25 16:32:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnXS-0000QF-OT; Wed, 25 Jul 2007 16:32:54 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IDnXS-0000Po-0q for kitten-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 16:32:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnXR-0000PW-N4 for kitten@ietf.org; Wed, 25 Jul 2007 16:32:53 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDnXQ-0003mm-C9 for kitten@ietf.org; Wed, 25 Jul 2007 16:32:53 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id WAA16494 for ; Wed, 25 Jul 2007 22:32:46 +0200 (MESZ) From: Martin Rex Message-Id: <200707252032.l6PKWjrB026473@fs4113.wdf.sap.corp> To: kitten@ietf.org Date: Wed, 25 Jul 2007 22:32:45 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: statless servers, pushing exported (proto)context to clients X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Based on the discussion during the Kitten WG session at IETF 69 today here's another thought about potential problems. (Wasn't NTLM authentication with rfc-4559 mentioned as an example?) I see a problem with challenge-response style gssapi mechanisms such as NTLM to support export of incomplete security contexts because of the challenge. Will a receiver of an exported security context have to accept whatever challenge is in the exported context token? How does it protect against replay? (a copy of the captured session could be replayed against every allowed receiver of the exported security context token.) In the existing implementation, Microsoft's NTLM authentication protocol appears to have a (local) replay cache for challenges, because it limits the lifetime of the proto-security-context to two minutes (IIRC, this is actually visible from the lifetime output parameter of SSPI's AcceptSecurityContext). -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 25 16:43:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnhn-00015a-PB; Wed, 25 Jul 2007 16:43:35 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IDnhn-00015V-F7 for kitten-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 16:43:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnhm-00015N-Qu for kitten@ietf.org; Wed, 25 Jul 2007 16:43:34 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDnhl-00040o-Cp for kitten@ietf.org; Wed, 25 Jul 2007 16:43:34 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 774F73BF58; Wed, 25 Jul 2007 22:43:32 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17316-01-40; Wed, 25 Jul 2007 22:43:32 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id A1A083BEB1; Wed, 25 Jul 2007 22:43:26 +0200 (CEST) Message-ID: <46A7B5F6.9060703@it.su.se> Date: Wed, 25 Jul 2007 22:43:34 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: martin.rex@sap.com References: <200707252032.l6PKWjrB026473@fs4113.wdf.sap.corp> In-Reply-To: <200707252032.l6PKWjrB026473@fs4113.wdf.sap.corp> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.929 tagged_above=-99 required=7 tests=[AWL=0.383, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: kitten@ietf.org Subject: Re: statless servers, pushing exported (proto)context to clients X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org > > How does it protect against replay? (a copy of the captured > session could be replayed against every allowed receiver of > the exported security context token.) > > Off the top of my head a replay cache seems problematic since I believe it will be roughly equivalent to maintaining server-side state. It would be better to bind the exported state to the channel over which it will be sent because this is the intended usecase but I haven't thought this through enough. Cheers Leif _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 25 16:53:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnrR-0008DA-40; Wed, 25 Jul 2007 16:53:33 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IDnrQ-0008D3-2p for kitten-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 16:53:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDnrP-0008Cv-OO for kitten@ietf.org; Wed, 25 Jul 2007 16:53:31 -0400 Received: from brmea-mail-1.sun.com ([192.18.98.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDnrO-0000nQ-UD for kitten@ietf.org; Wed, 25 Jul 2007 16:53:31 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PKrTb9027886 for ; Wed, 25 Jul 2007 20:53:29 GMT Received: from localhost.east.sun.com (punchin-client-129-148-19-35.East.Sun.COM [129.148.19.35]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6PKrTGo007547 for ; Wed, 25 Jul 2007 16:53:29 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l6PKoKC1002550; Wed, 25 Jul 2007 15:50:21 -0500 (CDT) Received: (from nico@localhost) by localhost.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l6PKoEpl002549; Wed, 25 Jul 2007 15:50:14 -0500 (CDT) X-Authentication-Warning: localhost.east.sun.com: nico set sender to Nicolas.Williams@sun.com using -f Date: Wed, 25 Jul 2007 15:50:13 -0500 From: Nico To: Leif Johansson Message-ID: <20070725205013.GB2512@Sun.COM> Mail-Followup-To: Leif Johansson , martin.rex@sap.com, kitten@ietf.org References: <200707252032.l6PKWjrB026473@fs4113.wdf.sap.corp> <46A7B5F6.9060703@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46A7B5F6.9060703@it.su.se> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: kitten@ietf.org Subject: Re: statless servers, pushing exported (proto)context to clients X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Wed, Jul 25, 2007 at 10:43:34PM +0200, Leif Johansson wrote: > > How does it protect against replay? (a copy of the captured > > session could be replayed against every allowed receiver of > > the exported security context token.) > > > > > Off the top of my head a replay cache seems problematic > since I believe it will be roughly equivalent to maintaining > server-side state. If there's a cluster involved then you have this problem no matter what. If not then there is no problem. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 25 16:55:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDntK-0001bi-2y; Wed, 25 Jul 2007 16:55:30 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IDntI-0001bc-Mk for kitten-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 16:55:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDntI-0001bU-C5 for kitten@ietf.org; Wed, 25 Jul 2007 16:55:28 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDntI-0000pr-0X for kitten@ietf.org; Wed, 25 Jul 2007 16:55:28 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id D31463BEFC; Wed, 25 Jul 2007 22:55:26 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17644-01-55; Wed, 25 Jul 2007 22:55:26 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 050D13BEB1; Wed, 25 Jul 2007 22:55:25 +0200 (CEST) Message-ID: <46A7B8C5.6050901@it.su.se> Date: Wed, 25 Jul 2007 22:55:33 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Leif Johansson , martin.rex@sap.com, kitten@ietf.org References: <200707252032.l6PKWjrB026473@fs4113.wdf.sap.corp> <46A7B5F6.9060703@it.su.se> <20070725205013.GB2512@Sun.COM> In-Reply-To: <20070725205013.GB2512@Sun.COM> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.932 tagged_above=-99 required=7 tests=[AWL=0.380, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: Re: statless servers, pushing exported (proto)context to clients X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Nico wrote: > On Wed, Jul 25, 2007 at 10:43:34PM +0200, Leif Johansson wrote: > >>> How does it protect against replay? (a copy of the captured >>> session could be replayed against every allowed receiver of >>> the exported security context token.) >>> >>> >>> >> Off the top of my head a replay cache seems problematic >> since I believe it will be roughly equivalent to maintaining >> server-side state. >> > > If there's a cluster involved then you have this problem no matter what. > If not then there is no problem. > > Nico > What about binding to the client (assuming that is possible)? _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 25 17:04:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo1n-0007Vc-83; Wed, 25 Jul 2007 17:04:15 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IDo1l-0007VS-Pf for kitten-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:04:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo1l-0007VJ-F4 for kitten@ietf.org; Wed, 25 Jul 2007 17:04:13 -0400 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDo1l-00012U-3C for kitten@ietf.org; Wed, 25 Jul 2007 17:04:13 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6PL4BvP019983 for ; Wed, 25 Jul 2007 21:04:12 GMT Received: from localhost.east.sun.com (punchin-client-129-148-19-35.East.Sun.COM [129.148.19.35]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id l6PL4BYw009258 for ; Wed, 25 Jul 2007 17:04:11 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l6PL0wnM002559; Wed, 25 Jul 2007 16:00:59 -0500 (CDT) Received: (from nico@localhost) by localhost.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l6PL0p8b002558; Wed, 25 Jul 2007 16:00:51 -0500 (CDT) X-Authentication-Warning: localhost.east.sun.com: nico set sender to Nicolas.Williams@sun.com using -f Date: Wed, 25 Jul 2007 16:00:50 -0500 From: Nico To: Leif Johansson , martin.rex@sap.com, kitten@ietf.org Message-ID: <20070725210050.GC2512@Sun.COM> Mail-Followup-To: Leif Johansson , martin.rex@sap.com, kitten@ietf.org References: <200707252032.l6PKWjrB026473@fs4113.wdf.sap.corp> <46A7B5F6.9060703@it.su.se> <20070725205013.GB2512@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070725205013.GB2512@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: Re: statless servers, pushing exported (proto)context to clients X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org I should add that clustering replay caches can be done, but high performance clustered replay caches are non-trivial to design and implement. This only comes up here because the context of Leif's HTTP+GSS I-D involves the possibility of Kerberos, concentrators and clusters. But the same issue comes up in other contexts. There is, however, a very neat solution: don't replay cache! Which we can get away with if we use a service name distinct from ones used in the past and if the "cookie" sent to the client is sent in a wrap token. Nico -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Wed Jul 25 17:10:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo7M-0002e7-1m; Wed, 25 Jul 2007 17:10:00 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IDo7J-0002e0-UV for kitten-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 17:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDo7J-0002ds-Kh for kitten@ietf.org; Wed, 25 Jul 2007 17:09:57 -0400 Received: from sca-ea-mail-2.sun.com ([192.18.43.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDo7I-0004aF-AR for kitten@ietf.org; Wed, 25 Jul 2007 17:09:57 -0400 Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l6PL9sPB017102 for ; Wed, 25 Jul 2007 21:09:55 GMT Received: from localhost.east.sun.com (punchin-client-129-148-19-35.East.Sun.COM [129.148.19.35]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id l6PL9su1010468 for ; Wed, 25 Jul 2007 17:09:54 -0400 (EDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l6PL6k6G002567; Wed, 25 Jul 2007 16:06:47 -0500 (CDT) Received: (from nico@localhost) by localhost.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l6PL6i4A002566; Wed, 25 Jul 2007 16:06:44 -0500 (CDT) X-Authentication-Warning: localhost.east.sun.com: nico set sender to Nicolas.Williams@sun.com using -f Date: Wed, 25 Jul 2007 16:06:43 -0500 From: Nico To: Leif Johansson , martin.rex@sap.com, kitten@ietf.org Message-ID: <20070725210643.GD2512@Sun.COM> Mail-Followup-To: Leif Johansson , martin.rex@sap.com, kitten@ietf.org References: <200707252032.l6PKWjrB026473@fs4113.wdf.sap.corp> <46A7B5F6.9060703@it.su.se> <20070725205013.GB2512@Sun.COM> <20070725210050.GC2512@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070725210050.GC2512@Sun.COM> User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: Subject: Re: statless servers, pushing exported (proto)context to clients X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org We can always just add another round-trip if needed to avoid the need to have a replay cache. Again, we need a separate service name so we know we can safely turn the replay cache off. _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Thu Jul 26 12:28:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE6CK-0002Hq-Sd; Thu, 26 Jul 2007 12:28:20 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IE6CK-0002Hd-LY for kitten-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 12:28:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE6CK-0002HV-9E for kitten@ietf.org; Thu, 26 Jul 2007 12:28:20 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE6CJ-0001sO-UX for kitten@ietf.org; Thu, 26 Jul 2007 12:28:20 -0400 Received: from fe-amer-01.sun.com ([192.18.108.175]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l6QGSJaP018650 for ; Thu, 26 Jul 2007 16:28:19 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JLS00L01O0JCZ00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for kitten@ietf.org; Thu, 26 Jul 2007 10:28:19 -0600 (MDT) Received: from shawn-emerys-computer.local ([129.150.35.207]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JLS00FQZOF6C5T2@mail-amer.sun.com> for kitten@ietf.org; Thu, 26 Jul 2007 10:28:18 -0600 (MDT) Date: Thu, 26 Jul 2007 10:25:42 -0600 From: "Shawn M. Emery" To: kitten@ietf.org Message-id: <46A8CB06.1020805@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: C# Bindings Work Item X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org During the kitten-wg session yesterday we polled local and remote (via jabber) participants whether there is anyone willing to takeover C# binding draft as a working group item. No volunteers had come forward then, nor when I posted this request on this mailing list. The next action item for the co-chairs was to poll this working group alias to see if we should drop the C# bindings language specification work from the charter. Please respond to this alias by 8/26/07 if you are not in favor of dropping C# bindings from the charter. The kitten-wg co-chairs -- _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Jul 30 15:22:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFapE-0000Le-MU; Mon, 30 Jul 2007 15:22:40 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IFapD-0000LZ-Iu for kitten-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 15:22:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFapD-0000LR-0J for kitten@ietf.org; Mon, 30 Jul 2007 15:22:39 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFapB-0006rh-Kt for kitten@ietf.org; Mon, 30 Jul 2007 15:22:38 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA12390; Mon, 30 Jul 2007 21:22:32 +0200 (MESZ) From: Martin Rex Message-Id: <200707301922.l6UJM4x0001283@fs4113.wdf.sap.corp> To: miallen@ioplex.com (Michael B Allen) Date: Mon, 30 Jul 2007 21:22:04 +0200 (MEST) In-Reply-To: <20070729230030.bae57a7a.miallen@ioplex.com> from "Michael B Allen" at Jul 29, 7 11:00:30 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: kitten@ietf.org Subject: Re: statless servers, pushing exported (proto)context to clients X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org Michael B Allen wrote: > > On Wed, 25 Jul 2007 22:32:45 +0200 (MEST) > Martin Rex wrote: > > > In the existing implementation, Microsoft's NTLM authentication > > protocol appears to have a (local) replay cache for challenges, > > because it limits the lifetime of the proto-security-context > > to two minutes (IIRC, this is actually visible from > > the lifetime output parameter of SSPI's AcceptSecurityContext). > > I've done a lot of NTLM and I've never seen a problem using an old > challenge. What do you mean by that? > > Then again I'm not sure I understand the whole reply cache thing in the > context of NTLM since the challenge is specific to a TCP connection. The challenge in a challenge-repsonse protocol like NTLM serves the purpose to turn a shared-secret authentication into a non-disclosing authentication, so that a passive observer of the communication can not re-use what he sees on the network to impersonate the client. In order to achieve that, challenges ought to be (globally) unique and a server ought to make sure that responses that it receives are matching to outstanding challenges the server has previously issued and not yet received a response for. Transfering a partially established security context from a challenge response authentication where the server has sent the challenge and is wating for the response is therefore not easily possible. *I* would not attempt to go statless in this situation, as I can not think of an easy way to solve the replay attack vulnerability. Forcing the client to keep track of the (backend) state of a session seems like an idea with an extemely small an limited environment. Personally, I think it is entirey insignificant. Sending the session state back and forth requires a serious amount of bandwidth. Securing and verifying the state on the server additonal CPU overhead. Normally, the cheapest storage space is available on the server, network bandwidth and storage space on the clients are usually much more expensive. If the backend state is large several 10 KBytes to several MBytes of memory, sending the state back and forth with every request becomes entirely insane. If the state is lightweight, serializing and storing it on some mass-storage on the server side (with a lifetime after which it will get forgotten) is something that servers have been successfully doing for more than a decade (with backend state far into the multi-MBytes). So the only scenario where this could make any sense at all is a thin server, a fat client, many users and little server-side storage but NO server-CPU and NO bandwith issues. I have serious difficulties to think of such a usage scenario. an MIT Kerberos KDC might be one of those. But adding a Web Interface to the KDC is likely to become a source for regular vulerability reports... -Martin _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten From kitten-bounces@lists.ietf.org Mon Jul 30 16:35:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbxN-0000Xt-Ti; Mon, 30 Jul 2007 16:35:09 -0400 Received: from kitten by megatron.ietf.org with local (Exim 4.43) id 1IFbxM-0000Wg-HF for kitten-confirm+ok@megatron.ietf.org; Mon, 30 Jul 2007 16:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbxL-0000WU-FT for kitten@ietf.org; Mon, 30 Jul 2007 16:35:07 -0400 Received: from www.ioplex.com ([64.22.109.41] helo=mail.ioplex.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFbxJ-0000C0-U6 for kitten@ietf.org; Mon, 30 Jul 2007 16:35:07 -0400 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: miallen) by mail.ioplex.com (Postfix) with ESMTP id E806640657; Mon, 30 Jul 2007 16:35:04 -0400 (EDT) Date: Mon, 30 Jul 2007 16:35:04 -0400 From: Michael B Allen To: martin.rex@sap.com Message-Id: <20070730163504.5c3127d1.miallen@ioplex.com> In-Reply-To: <200707301922.l6UJM4x0001283@fs4113.wdf.sap.corp> References: <20070729230030.bae57a7a.miallen@ioplex.com> <200707301922.l6UJM4x0001283@fs4113.wdf.sap.corp> Organization: IOPLEX Software X-Mailer: Sylpheed 2.4.0 (GTK+ 2.10.4; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: kitten@ietf.org Subject: Re: statless servers, pushing exported (proto)context to clients X-BeenThere: kitten@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kitten-bounces@lists.ietf.org On Mon, 30 Jul 2007 21:22:04 +0200 (MEST) Martin Rex wrote: > Michael B Allen wrote: > > > > On Wed, 25 Jul 2007 22:32:45 +0200 (MEST) > > Martin Rex wrote: > > > > > In the existing implementation, Microsoft's NTLM authentication > > > protocol appears to have a (local) replay cache for challenges, > > > because it limits the lifetime of the proto-security-context > > > to two minutes (IIRC, this is actually visible from > > > the lifetime output parameter of SSPI's AcceptSecurityContext). > > > > I've done a lot of NTLM and I've never seen a problem using an old > > challenge. > > What do you mean by that? > > > > > Then again I'm not sure I understand the whole reply cache thing in the > > context of NTLM since the challenge is specific to a TCP connection. > > The challenge in a challenge-repsonse protocol like NTLM serves > the purpose to turn a shared-secret authentication into a > non-disclosing authentication, so that a passive observer of the > communication can not re-use what he sees on the network to > impersonate the client. > > In order to achieve that, challenges ought to be (globally) unique > and a server ought to make sure that responses that it receives > are matching to outstanding challenges the server has previously > issued and not yet received a response for. Hey Martin, Still ignorant here. Anyway, the reason I chimed in is because I maintain the JCIFS NTLM HTTP authentication Filter. The way it works is the first request for authentication opens a TCP connection and creates an "SmbTransport" object which has a challenge associated with it. It then proceeds to authenticate all users by multiplexing NTLMSSP authentications (using the same challenge) over the same TCP connection. Web applications being what they are there are idle periods between authentications. After several years of supporting this solution I have never seen the challege expire because of any limit in the lifetime of the challege. Second, if an interloper were to attempt to use a challenge over a new TCP connection it would not be successful (I believe I tested this once but I don't recall). So unless you're talking about an attack that also used TCP connection hijacking I'm not sure I understand the replay attack you speak of. Now, if you're talking about NTLM as defined by the OpenGroup without regard for the TCP constraint then perhaps my observations are of no help to you as I do not usual concern myself with anything not seen in the wild (I'm a programmer not a pioneer). Mike -- Michael B Allen PHP Active Directory Kerberos SSO http://www.ioplex.com/ _______________________________________________ Kitten mailing list Kitten@lists.ietf.org https://www1.ietf.org/mailman/listinfo/kitten