From andros@netapp.com Mon Nov 1 12:21:25 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FEFB28C0FD for ; Mon, 1 Nov 2010 12:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWN3xEgozwz4 for ; Mon, 1 Nov 2010 12:21:24 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 5435228C0DC for ; Mon, 1 Nov 2010 12:21:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.58,276,1286175600"; d="scan'208";a="476129375" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 01 Nov 2010 12:21:26 -0700 Received: from lambert1-xp.hq.netapp.com (dasha1-lxp.hq.netapp.com [10.58.54.11] (may be forged)) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oA1JLPV5027637; Mon, 1 Nov 2010 12:21:25 -0700 (PDT) Message-Id: <2C4912EA-96DC-48F6-8D68-B641BFE06557@netapp.com> From: Andy Adamson To: Leif Johansson In-Reply-To: <4CCDE837.2050406@sunet.se> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 1 Nov 2010 15:21:25 -0400 References: <4CCDE837.2050406@sunet.se> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Tue, 02 Nov 2010 06:19:53 -0700 Cc: abfab@ietf.org Subject: Re: [abfab] draft-adamson-nfsv4-multi-domain-access - which IETF working group? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Nov 2010 19:21:25 -0000 On Oct 31, 2010, at 6:05 PM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> 2) You should definitely seek review from abfab both now and as you >> approach last call. It does overlap with things we care about, but >> it >> is not technically in our charter. If for some reason people who are >> planning on spending significant time contributing to the work >> believe >> that having it driven by nfsv4 is too narrow, we can discuss whether >> adding this to abfab makes sense. I'll note that even in cases where >> people are well-meaning and all want to get some work done, shifting >> working groups tends to slow things down. > > Speaking as the chair of abfab: federated storage is one of the > motivating use-cases of the moonshot project that in turn came up > with most of the work that has motivated the formation of abfab. > > I suspect that abfab members will want to take an active interest > in this work. > > Having said that, Sam is correct that work on nfsv4 is not in our > charter right now and (again speaking as a chair) we need to finish > (or at least make significant progress on) our core documents > before we start thinking about what to do next. OK. Thanks for the clarification. -->Andy > >> >> 4) LDAP schema specification is more mature than Kerberos. The LDAP >> community might well be happy for that part to happen in nfsv4, in >> krb-wg, etc. We should check with them. >> > > There is an LDAP directory for that sort of stuff - the IESG will give > you guidance. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkzN6DcACgkQ8Jx8FtbMZnckogCfYyqqd6F+Ww/luqzbvehthu+x > tvcAn1PvrZ2f7UrCUkzZu3pjJctgsPJJ > =Rr+e > -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Sat Nov 6 19:55:04 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EB2F3A69AC for ; Sat, 6 Nov 2010 19:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gHPEJL2yhNp for ; Sat, 6 Nov 2010 19:55:03 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id C7B583A6774 for ; Sat, 6 Nov 2010 19:55:01 -0700 (PDT) Received: (qmail invoked by alias); 07 Nov 2010 02:55:17 -0000 Received: from dhcp-7730.meeting.ietf.org (EHLO dhcp-7730.meeting.ietf.org) [130.129.119.48] by mail.gmx.net (mp004) with SMTP; 07 Nov 2010 03:55:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18djRZNuHsd/S3FbRXVVbhNoqiOD/OUn8XVnZx7BK TNKBsE0sEpIdp7 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1081) From: Hannes Tschofenig Date: Sat, 6 Nov 2010 21:55:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9B1996E7-7223-4263-9874-A1A3A58F6FF2@gmx.net> References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> To: abfab@ietf.org X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Subject: [abfab] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 02:55:04 -0000 Hi all,=20 please consider attending the following two meetings!=20 ** OAuth Security Session ** =95 Date: Monday, 13:00-15:00 =95 Location: IAB breakout room (Jade 2) =95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security consideration section of OAuth 2.0 (draft -10) is still = empty. Hence, we would like to put some time aside to discuss what = security threats, requirements, and countermeasures need to be = described. We will use the Monday, November 8, 1300-1500 slot to have a = discussion session. As a starting point I suggest to look at the following documents: =95 = http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations =95 http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy =95 = http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt Note: If you are unfamiliar with OAuth then the OAuth tutorial session = might be more suitable for you! ** OAuth Tutorial ** =95 Date: Wednesday, 19:30 (after the plenary) =95 Location: IAB breakout room (Jade 2) =95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows a user to grant a third-party Web site or application = access to their resources, without necessarily revealing their = credentials, or even their identity. The OAuth working group, = seehttp://datatracker.ietf.org/wg/oauth/charter/, is currently trying to = finalize their main specification, namely OAuth v2: = http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ Based on the positive response at the last IETF meeting (in Maastricht) = we decided to hold another OAuth tutorial, namely on *Wednesday, = starting at 19:30 (after the IETF Operations and Administration Plenary) = till about 21:00. (Note: I had to switch the day because of the social = event!) It is helpful to read through the documents available int he working = group but not required. Up-to-date information can be found here: = http://www.ietf.org/registration/MeetingWiki/wiki/79bofs Ciao Hannes From torsten@lodderstedt.net Sun Nov 7 15:04:07 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A981F28C11F; Sun, 7 Nov 2010 15:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwtw++ocQDAp; Sun, 7 Nov 2010 15:04:06 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 89E1A3A6919; Sun, 7 Nov 2010 15:04:06 -0800 (PST) Received: from [79.253.37.94] (helo=[192.168.71.43]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PFEHg-0007pK-9T; Mon, 08 Nov 2010 00:04:24 +0100 Message-ID: <4CD73075.8050408@lodderstedt.net> Date: Mon, 08 Nov 2010 00:04:21 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hannes Tschofenig References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> In-Reply-To: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:52 -0800 Cc: abfab@ietf.org, rai@ietf.org, ietf@ietf.org, secdir@ietf.org, websec@ietf.org, xmpp@ietf.org, kitten@ietf.org, "iab@iab.org Board" , iesg@ietf.org, Mark Mcgloin , oauth@ietf.org Subject: Re: [abfab] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 23:04:07 -0000 Hi all, Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a _preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model. Please give us feedback. regards, Torsten. Am 07.11.2010 03:22, schrieb Hannes Tschofenig: > Hi all, > > please consider attending the following two meetings! > > ** OAuth Security Session ** > > • Date: Monday, 13:00-15:00 > • Location: IAB breakout room (Jade 2) > • Contact: Hannes Tschofenig hannes.tschofenig@gmx.net > The security consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a discussion session. > > As a starting point I suggest to look at the following documents: > > • http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations > • http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy > • http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt > > Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you! > > > > ** OAuth Tutorial ** > > • Date: Wednesday, 19:30 (after the plenary) > • Location: IAB breakout room (Jade 2) > • Contact: Hannes Tschofenig hannes.tschofenig@gmx.net > OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. The OAuth working group, see http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to finalize their main specification, namely OAuth v2: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > Based on the positive response at the last IETF meeting (in Maastricht) we decided to hold another OAuth tutorial, namely on *Wednesday, starting at 19:30 (after the IETF Operations and Administration Plenary) till about 21:00. (Note: I had to switch the day because of the social event!) > > It is helpful to read through the documents available int he working group but not required. > > Up-to-date information can be found here: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From tonynad@microsoft.com Mon Nov 8 17:54:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A861C3A68FA; Mon, 8 Nov 2010 17:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a7xn1iLpb31; Mon, 8 Nov 2010 17:54:35 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id A8A9A3A6898; Mon, 8 Nov 2010 17:54:35 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 8 Nov 2010 17:54:58 -0800 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.199]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0255.003; Mon, 8 Nov 2010 17:54:58 -0800 From: Anthony Nadalin To: Torsten Lodderstedt , Hannes Tschofenig Thread-Topic: [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** Thread-Index: AQHLfisaqAne5bBEGEGUAfaUzHbBGZNnKf+AgAE438A= Date: Tue, 9 Nov 2010 01:54:57 +0000 Message-ID: <180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> <4CD73075.8050408@lodderstedt.net> In-Reply-To: <4CD73075.8050408@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:51 -0800 Cc: "abfab@ietf.org" , "rai@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "websec@ietf.org" , "xmpp@ietf.org" , "kitten@ietf.org" , "iab@iab.org Board" , "iesg@ietf.org" , "oauth@ietf.org" Subject: Re: [abfab] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 01:54:36 -0000 I was looking for less of an analysis and more of considerations (of the cu= rrent flows and actors), I'm not sure how to adapt what you have done to ac= tually fit in the current specification, was your thought that you would pr= oduce a separate security analysis document? -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T= orsten Lodderstedt Sent: Sunday, November 07, 2010 3:04 PM To: Hannes Tschofenig Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ie= tf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; o= auth@ietf.org Subject: Re: [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** Hi all, Mark McGloin and me have been working on OAuth 2.0 security considerations = for a couple of weeks now. Since we both cannot attend the IETF-79 meetings= , we would like to provide the WG with information regarding the current st= atus of our work. I therefore uploaded a _preliminary_ version of our worki= ng document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/at= tachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf.=20 The focus of this version was on consolidating previous work as well as res= ults of mailing list discussions and start working towards a rigorous threa= t model. Please give us feedback. regards, Torsten. Am 07.11.2010 03:22, schrieb Hannes Tschofenig: > Hi all, > > please consider attending the following two meetings! > > ** OAuth Security Session ** > > * Date: Monday, 13:00-15:00 > * Location: IAB breakout room (Jade 2) > * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security=20 > consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we = would like to put some time aside to discuss what security threats, require= ments, and countermeasures need to be described. We will use the Monday, No= vember 8, 1300-1500 slot to have a discussion session. > > As a starting point I suggest to look at the following documents: > > * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations > * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy > *=20 > http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00. > txt > > Note: If you are unfamiliar with OAuth then the OAuth tutorial session mi= ght be more suitable for you! > > > > ** OAuth Tutorial ** > > * Date: Wednesday, 19:30 (after the plenary) > * Location: IAB breakout room (Jade 2) > * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows a=20 > user to grant a third-party Web site or application access to their=20 > resources, without necessarily revealing their credentials, or even=20 > their identity. The OAuth working group, see=20 > http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to=20 > finalize their main specification, namely OAuth v2:=20 > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > > Based on the positive response at the last IETF meeting (in=20 > Maastricht) we decided to hold another OAuth tutorial, namely on=20 > *Wednesday, starting at 19:30 (after the IETF Operations and=20 > Administration Plenary) till about 21:00. (Note: I had to switch the=20 > day because of the social event!) > > It is helpful to read through the documents available int he working grou= p but not required. > > Up-to-date information can be found here:=20 > http://www.ietf.org/registration/MeetingWiki/wiki/79bofs > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From SRS0=si2S7B=SK=lodderstedt.net=torsten@srs.bis.eu.blackberry.com Tue Nov 9 00:07:39 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F0E3A6890; Tue, 9 Nov 2010 00:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.846 X-Spam-Level: X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlATxjM3OeG8; Tue, 9 Nov 2010 00:07:38 -0800 (PST) Received: from smtp06.bis.eu.blackberry.com (smtp06.bis.eu.blackberry.com [216.9.253.29]) by core3.amsl.com (Postfix) with ESMTP id 73A5C3A688E; Tue, 9 Nov 2010 00:07:36 -0800 (PST) Received: from bda2319.bisx.produk.on.blackberry (bda2319.bisx.produk.on.blackberry [172.24.204.122]) by srs.bis.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id oA987xRm004407; Tue, 9 Nov 2010 08:07:59 GMT Received: from bda2319.bisx.produk.on.blackberry (localhost.localdomain [127.0.0.1]) by bda2319.bisx.produk.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id oA987vRo016870; Tue, 9 Nov 2010 08:07:57 GMT X-rim-org-msg-ref-id: 1893623701 Message-ID: <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> Sensitivity: Normal Importance: Normal To: "Anthony Nadalin" , "Tschofenig, Hannes" From: torsten@lodderstedt.net Date: Tue, 9 Nov 2010 08:07:56 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:52 -0800 Cc: "abfab@ietf.org" , "rai@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "websec@ietf.org" , "xmpp@ietf.org" , "kitten@ietf.org" , "iab@iab.org Board" , "iesg@ietf.org" , "oauth@ietf.org" Subject: Re: [abfab] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 08:11:49 -0000 V2UgdGhpbmsgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZSBiYXNlZCBvbiBh IHRocmVhdCBtb2RlbCBvZiBPQXV0aC4gQnV0IGEgY29tcGxldGUgdGhyZWF0IG1vZGVsIHdvdWxk IGJsb3cgdXAgdGhlIHNwZWMuDQoNCldlIHRoZXJlZm9yZSBhaW0gdG8gcHJvZHVjZSBhIHNlcGFy YXRlIHNlY3VyaXR5IGRvY3VtZW50IChpbmZvcm1hdGlvbmFsIEktRC9SRkMpIGNvdmVyaW5nIHRo cmVhdCBtb2RlbCBhcyB3ZWxsIGFzIHNlY3VyaXR5IGRlc2lnbiBhbmQgY29uc2lkZXJhdGlvbnMu IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIHRoZSBjb3JlIHNwZWMgY2Fu IHRoZW4gYmUgZGlzdGlsbGVkIGZyb20gdGhpcyBkb2N1bWVudC4NCg0KUmVnYXJkcywNClRvcnN0 ZW4uDQpHZXNlbmRldCBtaXQgQmxhY2tCZXJyea4gV2VibWFpbCB2b24gVGVsZWtvbSBEZXV0c2No bGFuZCAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbnRob255IE5hZGFs aW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NCkRhdGU6IFR1ZSwgOSBOb3YgMjAxMCAwMTo1NDo1 NyANClRvOiBUb3JzdGVuIExvZGRlcnN0ZWR0PHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PjsgSGFu bmVzIFRzY2hvZmVuaWc8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NCkNjOiBhYmZhYkBpZXRm Lm9yZzxhYmZhYkBpZXRmLm9yZz47IHJhaUBpZXRmLm9yZzxyYWlAaWV0Zi5vcmc+OyBpZXRmQGll dGYub3JnPGlldGZAaWV0Zi5vcmc+OyBzZWNkaXJAaWV0Zi5vcmc8c2VjZGlyQGlldGYub3JnPjsg d2Vic2VjQGlldGYub3JnPHdlYnNlY0BpZXRmLm9yZz47IHhtcHBAaWV0Zi5vcmc8eG1wcEBpZXRm Lm9yZz47IGtpdHRlbkBpZXRmLm9yZzxraXR0ZW5AaWV0Zi5vcmc+OyBpYWJAaWFiLm9yZyBCb2Fy ZDxpYWJAaWFiLm9yZz47IGllc2dAaWV0Zi5vcmc8aWVzZ0BpZXRmLm9yZz47IG9hdXRoQGlldGYu b3JnPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gKiogT0F1dGggVHV0 b3JpYWwgJiBPQXV0aCBTZWN1cml0eSBTZXNzaW9uICoqDQoNCkkgd2FzIGxvb2tpbmcgZm9yIGxl c3Mgb2YgYW4gYW5hbHlzaXMgYW5kIG1vcmUgb2YgY29uc2lkZXJhdGlvbnMgKG9mIHRoZSBjdXJy ZW50IGZsb3dzIGFuZCBhY3RvcnMpLCBJJ20gbm90IHN1cmUgaG93IHRvIGFkYXB0IHdoYXQgeW91 IGhhdmUgZG9uZSB0byBhY3R1YWxseSBmaXQgaW4gdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiwg d2FzIHlvdXIgdGhvdWdodCB0aGF0IHlvdSB3b3VsZCBwcm9kdWNlIGEgc2VwYXJhdGUgc2VjdXJp dHkgYW5hbHlzaXMgZG9jdW1lbnQ/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQNClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIg MDcsIDIwMTAgMzowNCBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogYWJmYWJAaWV0Zi5v cmc7IHJhaUBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnOyB3ZWJzZWNA aWV0Zi5vcmc7IHhtcHBAaWV0Zi5vcmc7IGtpdHRlbkBpZXRmLm9yZzsgaWFiQGlhYi5vcmcgQm9h cmQ7IGllc2dAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdH XSAqKiBPQXV0aCBUdXRvcmlhbCAmIE9BdXRoIFNlY3VyaXR5IFNlc3Npb24gKioNCg0KSGkgYWxs LA0KDQpNYXJrIE1jR2xvaW4gYW5kIG1lIGhhdmUgYmVlbiB3b3JraW5nIG9uIE9BdXRoIDIuMCBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgYSBjb3VwbGUgb2Ygd2Vla3Mgbm93LiBTaW5jZSB3 ZSBib3RoIGNhbm5vdCBhdHRlbmQgdGhlIElFVEYtNzkgbWVldGluZ3MsIHdlIHdvdWxkIGxpa2Ug dG8gcHJvdmlkZSB0aGUgV0cgd2l0aCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlIGN1cnJlbnQg c3RhdHVzIG9mIG91ciB3b3JrLiBJIHRoZXJlZm9yZSB1cGxvYWRlZCBhX3ByZWxpbWluYXJ5XyB2 ZXJzaW9uIG9mIG91ciB3b3JraW5nIGRvY3VtZW50IHRvIHRoZSBXRydzIHdpa2kgYXQgaHR0cDov L3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvb2F1dGgvdHJhYy9hdHRhY2htZW50L3dpa2kvU2VjdXJp dHlDb25zaWRlcmF0aW9ucy9vYXV0aDIwX3NlY2NvbnNfMjAxMDExMDcucGRmLiANClRoZSBmb2N1 cyBvZiB0aGlzIHZlcnNpb24gd2FzIG9uIGNvbnNvbGlkYXRpbmcgcHJldmlvdXMgd29yayBhcyB3 ZWxsIGFzIHJlc3VsdHMgb2YgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zIGFuZCBzdGFydCB3b3Jr aW5nIHRvd2FyZHMgYSByaWdvcm91cyB0aHJlYXQgbW9kZWwuDQoNClBsZWFzZSBnaXZlIHVzIGZl ZWRiYWNrLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMDcuMTEuMjAxMCAwMzoyMiwgc2No cmllYiBIYW5uZXMgVHNjaG9mZW5pZzoNCj4gSGkgYWxsLA0KPg0KPiBwbGVhc2UgY29uc2lkZXIg YXR0ZW5kaW5nIHRoZSBmb2xsb3dpbmcgdHdvIG1lZXRpbmdzIQ0KPg0KPiAqKiBPQXV0aCBTZWN1 cml0eSBTZXNzaW9uICoqDQo+DQo+IAkqIERhdGU6IE1vbmRheSwgMTM6MDAtMTU6MDANCj4gCSog TG9jYXRpb246IElBQiBicmVha291dCByb29tIChKYWRlIDIpDQo+IAkqIENvbnRhY3Q6IEhhbm5l cyBUc2Nob2ZlbmlnIGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQgVGhlIHNlY3VyaXR5IA0KPiBj b25zaWRlcmF0aW9uIHNlY3Rpb24gb2YgT0F1dGggMi4wIChkcmFmdCAtMTApIGlzIHN0aWxsIGVt cHR5LiBIZW5jZSwgd2Ugd291bGQgbGlrZSB0byBwdXQgc29tZSB0aW1lIGFzaWRlIHRvIGRpc2N1 c3Mgd2hhdCBzZWN1cml0eSB0aHJlYXRzLCByZXF1aXJlbWVudHMsIGFuZCBjb3VudGVybWVhc3Vy ZXMgbmVlZCB0byBiZSBkZXNjcmliZWQuIFdlIHdpbGwgdXNlIHRoZSBNb25kYXksIE5vdmVtYmVy IDgsIDEzMDAtMTUwMCBzbG90IHRvIGhhdmUgYSAgZGlzY3Vzc2lvbiBzZXNzaW9uLg0KPg0KPiBB cyBhIHN0YXJ0aW5nIHBvaW50IEkgc3VnZ2VzdCB0byBsb29rIGF0IHRoZSBmb2xsb3dpbmcgZG9j dW1lbnRzOg0KPg0KPiAJKiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9vYXV0aC90cmFj L3dpa2kvU2VjdXJpdHlDb25zaWRlcmF0aW9ucw0KPiAJKiBodHRwOi8vdHJhYy50b29scy5pZXRm Lm9yZy93Zy9vYXV0aC90cmFjL3dpa2kvU2lnbmF0dXJlc1doeQ0KPiAJKiANCj4gaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtc2lnbmF0dXJlLXRob3VnaHRz LTAwLg0KPiB0eHQNCj4NCj4gTm90ZTogSWYgeW91IGFyZSB1bmZhbWlsaWFyIHdpdGggT0F1dGgg dGhlbiB0aGUgT0F1dGggdHV0b3JpYWwgc2Vzc2lvbiBtaWdodCBiZSBtb3JlIHN1aXRhYmxlIGZv ciB5b3UhDQo+DQo+DQo+DQo+ICoqIE9BdXRoIFR1dG9yaWFsICoqDQo+DQo+IAkqIERhdGU6IFdl ZG5lc2RheSwgMTk6MzAgKGFmdGVyIHRoZSBwbGVuYXJ5KQ0KPiAJKiBMb2NhdGlvbjogSUFCIGJy ZWFrb3V0IHJvb20gKEphZGUgMikNCj4gCSogQ29udGFjdDogSGFubmVzIFRzY2hvZmVuaWcgaGFu bmVzLnRzY2hvZmVuaWdAZ214Lm5ldCBPQXV0aCBhbGxvd3MgYSANCj4gdXNlciB0byBncmFudCBh IHRoaXJkLXBhcnR5IFdlYiBzaXRlIG9yIGFwcGxpY2F0aW9uIGFjY2VzcyB0byB0aGVpciANCj4g cmVzb3VyY2VzLCB3aXRob3V0IG5lY2Vzc2FyaWx5IHJldmVhbGluZyB0aGVpciBjcmVkZW50aWFs cywgb3IgZXZlbiANCj4gdGhlaXIgaWRlbnRpdHkuIFRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBz ZWUgDQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9vYXV0aC9jaGFydGVyLywgaXMg Y3VycmVudGx5IHRyeWluZyB0byANCj4gZmluYWxpemUgdGhlaXIgbWFpbiBzcGVjaWZpY2F0aW9u LCBuYW1lbHkgT0F1dGggdjI6IA0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtb2F1dGgtdjIvDQo+DQo+IEJhc2VkIG9uIHRoZSBwb3NpdGl2ZSByZXNwb25zZSBh dCB0aGUgbGFzdCBJRVRGIG1lZXRpbmcgKGluIA0KPiBNYWFzdHJpY2h0KSB3ZSBkZWNpZGVkIHRv IGhvbGQgYW5vdGhlciBPQXV0aCB0dXRvcmlhbCwgbmFtZWx5IG9uIA0KPiAqV2VkbmVzZGF5LCBz dGFydGluZyBhdCAxOTozMCAoYWZ0ZXIgdGhlIElFVEYgT3BlcmF0aW9ucyBhbmQgDQo+IEFkbWlu aXN0cmF0aW9uIFBsZW5hcnkpIHRpbGwgYWJvdXQgMjE6MDAuIChOb3RlOiBJIGhhZCB0byBzd2l0 Y2ggdGhlIA0KPiBkYXkgYmVjYXVzZSBvZiB0aGUgc29jaWFsIGV2ZW50ISkNCj4NCj4gSXQgaXMg aGVscGZ1bCB0byByZWFkIHRocm91Z2ggdGhlIGRvY3VtZW50cyBhdmFpbGFibGUgaW50IGhlIHdv cmtpbmcgZ3JvdXAgYnV0IG5vdCByZXF1aXJlZC4NCj4NCj4gVXAtdG8tZGF0ZSBpbmZvcm1hdGlv biBjYW4gYmUgZm91bmQgaGVyZTogDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmVnaXN0cmF0aW9u L01lZXRpbmdXaWtpL3dpa2kvNzlib2ZzDQo+DQo+IENpYW8NCj4gSGFubmVzDQo+DQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGlu ZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K From igor.faynberg@alcatel-lucent.com Tue Nov 9 22:57:56 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925393A69A3; Tue, 9 Nov 2010 22:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHx5MIc21mga; Tue, 9 Nov 2010 22:57:54 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1E1113A69A9; Tue, 9 Nov 2010 22:57:54 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id oAA6aZcM011476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2010 00:36:35 -0600 (CST) Received: from [135.244.80.3] (faynberg.lra.lucent.com [135.244.80.3]) by umail.lucent.com (8.13.8/TPES) with ESMTP id oAA6aUoF026012; Wed, 10 Nov 2010 00:36:31 -0600 (CST) Message-ID: <4CDA3D73.10609@alcatel-lucent.com> Date: Wed, 10 Nov 2010 01:36:35 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Richard L. Barnes" References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> <4CD90C14.2060803@bbn.com> <180155C5EA10854997314CA5E063D18FEE90B8@TK5EX14MBXC117.redmond.corp.microsoft.com> <4CDA3983.7050101@bbn.com> In-Reply-To: <4CDA3983.7050101@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:51 -0800 Cc: Anthony Nadalin , "abfab@ietf.org" , "rai@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "websec@ietf.org" , "xmpp@ietf.org" , "kitten@ietf.org" , "iab@iab.org Board" , "iesg@ietf.org" , "Tschofenig, Hannes" , "oauth@ietf.org" Subject: Re: [abfab] [OAUTH-WG] [secdir] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: igor.faynberg@alcatel-lucent.com List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:57:56 -0000 (With apologies for bringing up a tangential matter...) Talking about the OAuth model, I still see here "Client" instead of "Consumer." I thought there was an agreement on the terminology change. I have no specific preference for either term, but I think it is essential that our terminology be consistent, especially now that other SDOs are considering adopting OAuth. This is not necessarily a question for Richard, but could someone set me straight: Is it "Client" or "Consumer"? With thanks, Igor Richard L. Barnes wrote: > Of course not every scenario calls for all of the security knobs to be > turned to 11. Think of things instead in terms of syllogisms: "IF you > want X guarantee, THEN you MUST do A, B, C." > > Then you can also read the same things backwards in a given deployment > scenario: "Given that I can't do B, I can't get assurances X, Y, but I > can get Z (if I do D, F as well)". > > I promise to produce something more concrete soon :) In the meantime, > this text illustrates what I mean pretty well: > > > --Richard > > > On 11/10/10 2:03 PM, Anthony Nadalin wrote: >> Issue here is that guarantees (and what you want as a guarantee may >> not be what somebody else wants) can vary depending on scenario and >> deployment. >> >> -----Original Message----- >> From: Richard L. Barnes [mailto:rbarnes@bbn.com] >> Sent: Tuesday, November 09, 2010 12:54 AM >> To: torsten@lodderstedt.net >> Cc: Anthony Nadalin; Tschofenig, Hannes; abfab@ietf.org; >> rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ietf.org; >> xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; >> oauth@ietf.org >> Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial& OAuth Security >> Session ** >> >> I would say that the security considerations should be based on a >> model of OAuth. Start with a model of the protocol and the >> guarantees you want, then explain how to use security mechanisms to >> achieve those guarantees. >> >> I promised Hannes today to do a review of the current document (which >> I admit I haven't read) and start on some security considerations >> from that perspective. So expect that in the next few weeks. >> >> --Richard >> >> >> >> >> On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote: >>> We think the security considerations should be based on a threat >>> model of OAuth. But a complete threat model would blow up the spec. >>> >>> We therefore aim to produce a separate security document >>> (informational I-D/RFC) covering threat model as well as security >>> design and considerations. The security considerations section of >>> the core spec can then be distilled from this document. >>> >>> Regards, >>> Torsten. >>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland >>> >>> -----Original Message----- >>> From: Anthony Nadalin >>> Date: Tue, 9 Nov 2010 01:54:57 >>> To: Torsten Lodderstedt; Hannes >>> Tschofenig >>> Cc: abfab@ietf.org; rai@ietf.org; >>> ietf@ietf.org; secdir@ietf.org; >>> websec@ietf.org; xmpp@ietf.org; >>> kitten@ietf.org; iab@iab.org Board; >>> iesg@ietf.org; oauth@ietf.org >>> Subject: RE: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** >>> >>> I was looking for less of an analysis and more of considerations (of >>> the current flows and actors), I'm not sure how to adapt what you >>> have done to actually fit in the current specification, was your >>> thought that you would produce a separate security analysis document? >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> Of Torsten Lodderstedt >>> Sent: Sunday, November 07, 2010 3:04 PM >>> To: Hannes Tschofenig >>> Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; >>> websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; >>> iesg@ietf.org; oauth@ietf.org >>> Subject: Re: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** >>> >>> Hi all, >>> >>> Mark McGloin and me have been working on OAuth 2.0 security >>> considerations for a couple of weeks now. Since we both cannot >>> attend the IETF-79 meetings, we would like to provide the WG with >>> information regarding the current status of our work. I therefore >>> uploaded a_preliminary_ version of our working document to the WG's >>> wiki at >>> http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. >>> >>> The focus of this version was on consolidating previous work as well >>> as results of mailing list discussions and start working towards a >>> rigorous threat model. >>> >>> Please give us feedback. >>> >>> regards, >>> Torsten. >>> >>> Am 07.11.2010 03:22, schrieb Hannes Tschofenig: >>>> Hi all, >>>> >>>> please consider attending the following two meetings! >>>> >>>> ** OAuth Security Session ** >>>> >>>> * Date: Monday, 13:00-15:00 >>>> * Location: IAB breakout room (Jade 2) >>>> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The >>>> security >>>> consideration section of OAuth 2.0 (draft -10) is still empty. >>>> Hence, we would like to put some time aside to discuss what >>>> security threats, requirements, and countermeasures need to be >>>> described. We will use the Monday, November 8, 1300-1500 slot to >>>> have a discussion session. >>>> >>>> As a starting point I suggest to look at the following documents: >>>> >>>> * >>>> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations >>>> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy >>>> * >>>> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00. >>>> txt >>>> >>>> Note: If you are unfamiliar with OAuth then the OAuth tutorial >>>> session might be more suitable for you! >>>> >>>> >>>> >>>> ** OAuth Tutorial ** >>>> >>>> * Date: Wednesday, 19:30 (after the plenary) >>>> * Location: IAB breakout room (Jade 2) >>>> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth >>>> allows >>>> a user to grant a third-party Web site or application access to their >>>> resources, without necessarily revealing their credentials, or even >>>> their identity. The OAuth working group, see >>>> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to >>>> finalize their main specification, namely OAuth v2: >>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ >>>> >>>> Based on the positive response at the last IETF meeting (in >>>> Maastricht) we decided to hold another OAuth tutorial, namely on >>>> *Wednesday, starting at 19:30 (after the IETF Operations and >>>> Administration Plenary) till about 21:00. (Note: I had to switch the >>>> day because of the social event!) >>>> >>>> It is helpful to read through the documents available int he >>>> working group but not required. >>>> >>>> Up-to-date information can be found here: >>>> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs >>>> >>>> Ciao >>>> Hannes >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From rbarnes@bbn.com Tue Nov 9 00:53:26 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35BCA28C170; Tue, 9 Nov 2010 00:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1-hw6kBQHuj; Tue, 9 Nov 2010 00:53:25 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DDB223A69D8; Tue, 9 Nov 2010 00:53:24 -0800 (PST) Received: from [128.89.253.252] (port=54397 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PFjxa-000OfY-Ep; Tue, 09 Nov 2010 03:53:47 -0500 Message-ID: <4CD90C14.2060803@bbn.com> Date: Tue, 09 Nov 2010 16:53:40 +0800 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: torsten@lodderstedt.net References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> In-Reply-To: <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:51 -0800 Cc: Anthony Nadalin , "abfab@ietf.org" , "rai@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "websec@ietf.org" , "xmpp@ietf.org" , "kitten@ietf.org" , "iab@iab.org Board" , "iesg@ietf.org" , "Tschofenig, Hannes" , "oauth@ietf.org" Subject: Re: [abfab] [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 08:53:26 -0000 I would say that the security considerations should be based on a model of OAuth. Start with a model of the protocol and the guarantees you want, then explain how to use security mechanisms to achieve those guarantees. I promised Hannes today to do a review of the current document (which I admit I haven't read) and start on some security considerations from that perspective. So expect that in the next few weeks. --Richard On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote: > We think the security considerations should be based on a threat model of OAuth. But a complete threat model would blow up the spec. > > We therefore aim to produce a separate security document (informational I-D/RFC) covering threat model as well as security design and considerations. The security considerations section of the core spec can then be distilled from this document. > > Regards, > Torsten. > Gesendet mit BlackBerry® Webmail von Telekom Deutschland > > -----Original Message----- > From: Anthony Nadalin > Date: Tue, 9 Nov 2010 01:54:57 > To: Torsten Lodderstedt; Hannes Tschofenig > Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; oauth@ietf.org > Subject: RE: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** > > I was looking for less of an analysis and more of considerations (of the current flows and actors), I'm not sure how to adapt what you have done to actually fit in the current specification, was your thought that you would produce a separate security analysis document? > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt > Sent: Sunday, November 07, 2010 3:04 PM > To: Hannes Tschofenig > Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; oauth@ietf.org > Subject: Re: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** > > Hi all, > > Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a_preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. > The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model. > > Please give us feedback. > > regards, > Torsten. > > Am 07.11.2010 03:22, schrieb Hannes Tschofenig: >> Hi all, >> >> please consider attending the following two meetings! >> >> ** OAuth Security Session ** >> >> * Date: Monday, 13:00-15:00 >> * Location: IAB breakout room (Jade 2) >> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security >> consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a discussion session. >> >> As a starting point I suggest to look at the following documents: >> >> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations >> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy >> * >> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00. >> txt >> >> Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you! >> >> >> >> ** OAuth Tutorial ** >> >> * Date: Wednesday, 19:30 (after the plenary) >> * Location: IAB breakout room (Jade 2) >> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows a >> user to grant a third-party Web site or application access to their >> resources, without necessarily revealing their credentials, or even >> their identity. The OAuth working group, see >> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to >> finalize their main specification, namely OAuth v2: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ >> >> Based on the positive response at the last IETF meeting (in >> Maastricht) we decided to hold another OAuth tutorial, namely on >> *Wednesday, starting at 19:30 (after the IETF Operations and >> Administration Plenary) till about 21:00. (Note: I had to switch the >> day because of the social event!) >> >> It is helpful to read through the documents available int he working group but not required. >> >> Up-to-date information can be found here: >> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From mark.mcgloin@ie.ibm.com Tue Nov 9 06:54:30 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCC2C3A6A04; Tue, 9 Nov 2010 06:54:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxy8MrZ8zQvp; Tue, 9 Nov 2010 06:54:29 -0800 (PST) Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.17.163]) by core3.amsl.com (Postfix) with ESMTP id 949B13A69BE; Tue, 9 Nov 2010 06:54:28 -0800 (PST) Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.de.ibm.com (8.13.1/8.13.1) with ESMTP id oA9Esflx004036; Tue, 9 Nov 2010 14:54:41 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oA9EsfKQ3305506; Tue, 9 Nov 2010 14:54:41 GMT Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oA9EsfPh002056; Tue, 9 Nov 2010 07:54:41 -0700 Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oA9Esf4U002048; Tue, 9 Nov 2010 07:54:41 -0700 In-Reply-To: <4CD90C14.2060803@bbn.com> References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> <4CD90C14.2060803@bbn.com> X-KeepSent: 7957FE3B:45025425-802577D6:004F9E8F; type=4; name=$KeepSent To: "Richard L. Barnes" X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 Message-ID: From: Mark Mcgloin Date: Tue, 9 Nov 2010 14:54:06 +0000 X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 09/11/2010 14:54:07 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:52 -0800 Cc: "abfab@ietf.org" , torsten@lodderstedt.net, "rai@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "websec@ietf.org" , "xmpp@ietf.org" , "kitten@ietf.org" , "iab@iab.org Board" , "iesg@ietf.org" , "Tschofenig, Hannes" , "oauth@ietf.org" , oauth-bounces@ietf.org Subject: Re: [abfab] [OAUTH-WG] [secdir] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 14:54:31 -0000 When Torsten and I started pulling together the security considerations= over the last 4-6 weeks, we toyed with the idea of either populating th= e security considerations section of the protocol with a list/tree of considerations, or creating a more comprehensive document to ensure we covered all aspects, list security features and which would also act as= a security aid to developers implementing the oauth protocol. We decided = on the latter and agreed it could later be distilled down to something tha= t will fit into the security considerations section of the protocol. Bear in mind the document needs tidying but we wanted to push something= in before the security meeting in China Regards Mark McGloin oauth-bounces@ietf.org wrote on 09/11/2010 08:53:40: > "Richard L. Barnes" > Sent by: oauth-bounces@ietf.org > > 09/11/2010 08:53 > > To > > torsten@lodderstedt.net > > cc > > "abfab@ietf.org" , "rai@ietf.org" , > "ietf@ietf.org" , "secdir@ietf.org" > , "websec@ietf.org" , > "xmpp@ietf.org" , "kitten@ietf.org" > , "iab@iab.org Board" , > "iesg@ietf.org" , "Tschofenig, Hannes" > , "oauth@ietf.org" > > Subject > > Re: [OAUTH-WG] [secdir] ** OAuth Tutorial & OAuth Security Session **= > > I would say that the security considerations should be based on a mod= el > of OAuth. Start with a model of the protocol and the guarantees you > want, then explain how to use security mechanisms to achieve those > guarantees. > > I promised Hannes today to do a review of the current document (which= I > admit I haven't read) and start on some security considerations from > that perspective. So expect that in the next few weeks. > > --Richard > > > > > On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote: > > We think the security considerations should be based on a threat > model of OAuth. But a complete threat model would blow up the spec. > > > > We therefore aim to produce a separate security document > (informational I-D/RFC) covering threat model as well as security > design and considerations. The security considerations section of > the core spec can then be distilled from this document. > > > > Regards, > > Torsten. > > Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland > > > > -----Original Message----- > > From: Anthony Nadalin > > Date: Tue, 9 Nov 2010 01:54:57 > > To: Torsten Lodderstedt; Hannes > Tschofenig > > Cc: abfab@ietf.org; rai@ietf.org; > ietf@ietf.org; secdir@ietf.org; > websec@ietf.org; xmpp@ietf.org; > kitten@ietf.org; iab@iab.org Board; > iesg@ietf.org; oauth@ietf.org > > Subject: RE: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session = ** > > > > I was looking for less of an analysis and more of considerations > (of the current flows and actors), I'm not sure how to adapt what > you have done to actually fit in the current specification, was your > thought that you would produce a separate security analysis document?= > > > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of Torsten Lodderstedt > > Sent: Sunday, November 07, 2010 3:04 PM > > To: Hannes Tschofenig > > Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; > websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; > iesg@ietf.org; oauth@ietf.org > > Subject: Re: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session = ** > > > > Hi all, > > > > Mark McGloin and me have been working on OAuth 2.0 security > considerations for a couple of weeks now. Since we both cannot > attend the IETF-79 meetings, we would like to provide the WG with > information regarding the current status of our work. I therefore > uploaded a_preliminary_ version of our working document to the WG's w= iki at > http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/ > SecurityConsiderations/oauth20_seccons_20101107.pdf. > > The focus of this version was on consolidating previous work as > well as results of mailing list discussions and start working > towards a rigorous threat model. > > > > Please give us feedback. > > > > regards, > > Torsten. > > > > Am 07.11.2010 03:22, schrieb Hannes Tschofenig: > >> Hi all, > >> > >> please consider attending the following two meetings! > >> > >> ** OAuth Security Session ** > >> > >> * Date: Monday, 13:00-15:00 > >> * Location: IAB breakout room (Jade 2) > >> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The secu= rity > >> consideration section of OAuth 2.0 (draft -10) is still empty. > Hence, we would like to put some time aside to discuss what security > threats, requirements, and countermeasures need to be described. We > will use the Monday, November 8, 1300-1500 slot to have a discussion= session. > >> > >> As a starting point I suggest to look at the following documents: > >> > >> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations > >> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy > >> * > >> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts= -00. > >> txt > >> > >> Note: If you are unfamiliar with OAuth then the OAuth tutorial > session might be more suitable for you! > >> > >> > >> > >> ** OAuth Tutorial ** > >> > >> * Date: Wednesday, 19:30 (after the plenary) > >> * Location: IAB breakout room (Jade 2) > >> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth al= lows a > >> user to grant a third-party Web site or application access to thei= r > >> resources, without necessarily revealing their credentials, or eve= n > >> their identity. The OAuth working group, see > >> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying= to > >> finalize their main specification, namely OAuth v2: > >> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ > >> > >> Based on the positive response at the last IETF meeting (in > >> Maastricht) we decided to hold another OAuth tutorial, namely on > >> *Wednesday, starting at 19:30 (after the IETF Operations and > >> Administration Plenary) till about 21:00. (Note: I had to switch t= he > >> day because of the social event!) > >> > >> It is helpful to read through the documents available int he > working group but not required. > >> > >> Up-to-date information can be found here: > >> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs > >> > >> Ciao > >> Hannes > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > secdir mailing list > > secdir@ietf.org > > https://www.ietf.org/mailman/listinfo/secdir > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth= From tonynad@microsoft.com Tue Nov 9 22:03:34 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F13E3A68C8; Tue, 9 Nov 2010 22:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed2jPVsD-p8p; Tue, 9 Nov 2010 22:03:34 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 0EDF53A68C6; Tue, 9 Nov 2010 22:03:34 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 9 Nov 2010 22:03:48 -0800 Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.138]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Tue, 9 Nov 2010 22:03:48 -0800 From: Anthony Nadalin To: "Richard L. Barnes" , "torsten@lodderstedt.net" Thread-Topic: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** Thread-Index: AQHLf+vNz+Zyzs3OwkSCnvjMrh08w5NqOX4w Date: Wed, 10 Nov 2010 06:03:47 +0000 Message-ID: <180155C5EA10854997314CA5E063D18FEE90B8@TK5EX14MBXC117.redmond.corp.microsoft.com> References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> <4CD90C14.2060803@bbn.com> In-Reply-To: <4CD90C14.2060803@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:51 -0800 Cc: "abfab@ietf.org" , "rai@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "websec@ietf.org" , "xmpp@ietf.org" , "kitten@ietf.org" , "iab@iab.org Board" , "iesg@ietf.org" , "Tschofenig, Hannes" , "oauth@ietf.org" Subject: Re: [abfab] [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:03:34 -0000 Issue here is that guarantees (and what you want as a guarantee may not be = what somebody else wants) can vary depending on scenario and deployment. -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20 Sent: Tuesday, November 09, 2010 12:54 AM To: torsten@lodderstedt.net Cc: Anthony Nadalin; Tschofenig, Hannes; abfab@ietf.org; rai@ietf.org; ietf= @ietf.org; secdir@ietf.org; websec@ietf.org; xmpp@ietf.org; kitten@ietf.org= ; iab@iab.org Board; iesg@ietf.org; oauth@ietf.org Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session= ** I would say that the security considerations should be based on a model of = OAuth. Start with a model of the protocol and the guarantees you want, the= n explain how to use security mechanisms to achieve those guarantees. I promised Hannes today to do a review of the current document (which I adm= it I haven't read) and start on some security considerations from that pers= pective. So expect that in the next few weeks. --Richard On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote: > We think the security considerations should be based on a threat model of= OAuth. But a complete threat model would blow up the spec. > > We therefore aim to produce a separate security document (informational I= -D/RFC) covering threat model as well as security design and considerations= . The security considerations section of the core spec can then be distille= d from this document. > > Regards, > Torsten. > Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland > > -----Original Message----- > From: Anthony Nadalin > Date: Tue, 9 Nov 2010 01:54:57 > To: Torsten Lodderstedt; Hannes=20 > Tschofenig > Cc: abfab@ietf.org; rai@ietf.org;=20 > ietf@ietf.org; secdir@ietf.org;=20 > websec@ietf.org; xmpp@ietf.org;=20 > kitten@ietf.org; iab@iab.org Board;=20 > iesg@ietf.org; oauth@ietf.org > Subject: RE: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** > > I was looking for less of an analysis and more of considerations (of the = current flows and actors), I'm not sure how to adapt what you have done to = actually fit in the current specification, was your thought that you would = produce a separate security analysis document? > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Torsten Lodderstedt > Sent: Sunday, November 07, 2010 3:04 PM > To: Hannes Tschofenig > Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org;=20 > websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board;=20 > iesg@ietf.org; oauth@ietf.org > Subject: Re: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** > > Hi all, > > Mark McGloin and me have been working on OAuth 2.0 security consideration= s for a couple of weeks now. Since we both cannot attend the IETF-79 meetin= gs, we would like to provide the WG with information regarding the current = status of our work. I therefore uploaded a_preliminary_ version of our work= ing document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/a= ttachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. > The focus of this version was on consolidating previous work as well as r= esults of mailing list discussions and start working towards a rigorous thr= eat model. > > Please give us feedback. > > regards, > Torsten. > > Am 07.11.2010 03:22, schrieb Hannes Tschofenig: >> Hi all, >> >> please consider attending the following two meetings! >> >> ** OAuth Security Session ** >> >> * Date: Monday, 13:00-15:00 >> * Location: IAB breakout room (Jade 2) >> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security=20 >> consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we= would like to put some time aside to discuss what security threats, requir= ements, and countermeasures need to be described. We will use the Monday, N= ovember 8, 1300-1500 slot to have a discussion session. >> >> As a starting point I suggest to look at the following documents: >> >> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations >> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy >> * >> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00. >> txt >> >> Note: If you are unfamiliar with OAuth then the OAuth tutorial session m= ight be more suitable for you! >> >> >> >> ** OAuth Tutorial ** >> >> * Date: Wednesday, 19:30 (after the plenary) >> * Location: IAB breakout room (Jade 2) >> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows=20 >> a user to grant a third-party Web site or application access to their=20 >> resources, without necessarily revealing their credentials, or even=20 >> their identity. The OAuth working group, see=20 >> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to=20 >> finalize their main specification, namely OAuth v2: >> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ >> >> Based on the positive response at the last IETF meeting (in >> Maastricht) we decided to hold another OAuth tutorial, namely on=20 >> *Wednesday, starting at 19:30 (after the IETF Operations and=20 >> Administration Plenary) till about 21:00. (Note: I had to switch the=20 >> day because of the social event!) >> >> It is helpful to read through the documents available int he working gro= up but not required. >> >> Up-to-date information can be found here: >> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs >> >> Ciao >> Hannes >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From rbarnes@bbn.com Tue Nov 9 22:19:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE0C3A68D6; Tue, 9 Nov 2010 22:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.609 X-Spam-Level: X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZYj+e0Guafa; Tue, 9 Nov 2010 22:19:30 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3EB973A6895; Tue, 9 Nov 2010 22:19:30 -0800 (PST) Received: from [128.89.254.59] (port=53402 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PG42E-000Emt-1U; Wed, 10 Nov 2010 01:19:54 -0500 Message-ID: <4CDA3983.7050101@bbn.com> Date: Wed, 10 Nov 2010 14:19:47 +0800 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Anthony Nadalin References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> <4CD90C14.2060803@bbn.com> <180155C5EA10854997314CA5E063D18FEE90B8@TK5EX14MBXC117.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18FEE90B8@TK5EX14MBXC117.redmond.corp.microsoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:52 -0800 Cc: "abfab@ietf.org" , "Tschofenig, Hannes" , "rai@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "websec@ietf.org" , "xmpp@ietf.org" , "kitten@ietf.org" , "iab@iab.org Board" , "iesg@ietf.org" , "torsten@lodderstedt.net" , "oauth@ietf.org" Subject: Re: [abfab] [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 06:19:37 -0000 Of course not every scenario calls for all of the security knobs to be turned to 11. Think of things instead in terms of syllogisms: "IF you want X guarantee, THEN you MUST do A, B, C." Then you can also read the same things backwards in a given deployment scenario: "Given that I can't do B, I can't get assurances X, Y, but I can get Z (if I do D, F as well)". I promise to produce something more concrete soon :) In the meantime, this text illustrates what I mean pretty well: --Richard On 11/10/10 2:03 PM, Anthony Nadalin wrote: > Issue here is that guarantees (and what you want as a guarantee may not be what somebody else wants) can vary depending on scenario and deployment. > > -----Original Message----- > From: Richard L. Barnes [mailto:rbarnes@bbn.com] > Sent: Tuesday, November 09, 2010 12:54 AM > To: torsten@lodderstedt.net > Cc: Anthony Nadalin; Tschofenig, Hannes; abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; oauth@ietf.org > Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** > > I would say that the security considerations should be based on a model of OAuth. Start with a model of the protocol and the guarantees you want, then explain how to use security mechanisms to achieve those guarantees. > > I promised Hannes today to do a review of the current document (which I admit I haven't read) and start on some security considerations from that perspective. So expect that in the next few weeks. > > --Richard > > > > > On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote: >> We think the security considerations should be based on a threat model of OAuth. But a complete threat model would blow up the spec. >> >> We therefore aim to produce a separate security document (informational I-D/RFC) covering threat model as well as security design and considerations. The security considerations section of the core spec can then be distilled from this document. >> >> Regards, >> Torsten. >> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland >> >> -----Original Message----- >> From: Anthony Nadalin >> Date: Tue, 9 Nov 2010 01:54:57 >> To: Torsten Lodderstedt; Hannes >> Tschofenig >> Cc: abfab@ietf.org; rai@ietf.org; >> ietf@ietf.org; secdir@ietf.org; >> websec@ietf.org; xmpp@ietf.org; >> kitten@ietf.org; iab@iab.org Board; >> iesg@ietf.org; oauth@ietf.org >> Subject: RE: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** >> >> I was looking for less of an analysis and more of considerations (of the current flows and actors), I'm not sure how to adapt what you have done to actually fit in the current specification, was your thought that you would produce a separate security analysis document? >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Torsten Lodderstedt >> Sent: Sunday, November 07, 2010 3:04 PM >> To: Hannes Tschofenig >> Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; >> websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; >> iesg@ietf.org; oauth@ietf.org >> Subject: Re: [OAUTH-WG] ** OAuth Tutorial& OAuth Security Session ** >> >> Hi all, >> >> Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a_preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. >> The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model. >> >> Please give us feedback. >> >> regards, >> Torsten. >> >> Am 07.11.2010 03:22, schrieb Hannes Tschofenig: >>> Hi all, >>> >>> please consider attending the following two meetings! >>> >>> ** OAuth Security Session ** >>> >>> * Date: Monday, 13:00-15:00 >>> * Location: IAB breakout room (Jade 2) >>> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security >>> consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a discussion session. >>> >>> As a starting point I suggest to look at the following documents: >>> >>> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations >>> * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy >>> * >>> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00. >>> txt >>> >>> Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you! >>> >>> >>> >>> ** OAuth Tutorial ** >>> >>> * Date: Wednesday, 19:30 (after the plenary) >>> * Location: IAB breakout room (Jade 2) >>> * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows >>> a user to grant a third-party Web site or application access to their >>> resources, without necessarily revealing their credentials, or even >>> their identity. The OAuth working group, see >>> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to >>> finalize their main specification, namely OAuth v2: >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/ >>> >>> Based on the positive response at the last IETF meeting (in >>> Maastricht) we decided to hold another OAuth tutorial, namely on >>> *Wednesday, starting at 19:30 (after the IETF Operations and >>> Administration Plenary) till about 21:00. (Note: I had to switch the >>> day because of the social event!) >>> >>> It is helpful to read through the documents available int he working group but not required. >>> >>> Up-to-date information can be found here: >>> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs >>> >>> Ciao >>> Hannes >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir > From Nicolas.Williams@oracle.com Tue Nov 9 23:02:36 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF19B3A6A17; Tue, 9 Nov 2010 23:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQmB7Qzdzfxn; Tue, 9 Nov 2010 23:02:25 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 116863A68B5; Tue, 9 Nov 2010 23:02:00 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oAA72ATX008484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Nov 2010 07:02:11 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA9HhiJO024108; Wed, 10 Nov 2010 07:02:09 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 765322921289372442; Tue, 09 Nov 2010 23:00:42 -0800 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Nov 2010 23:00:42 -0800 Date: Wed, 10 Nov 2010 01:00:37 -0600 From: Nicolas Williams To: torsten@lodderstedt.net Message-ID: <20101110070037.GT6536@oracle.com> References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> <4CD73075.8050408@lodderstedt.net> <180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> User-Agent: Mutt/1.5.20 (2010-03-02) X-Mailman-Approved-At: Wed, 10 Nov 2010 00:14:52 -0800 Cc: Anthony Nadalin , "abfab@ietf.org" , "rai@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" , "websec@ietf.org" , "xmpp@ietf.org" , "kitten@ietf.org" , "iab@iab.org Board" , "iesg@ietf.org" , "Tschofenig, Hannes" , "oauth@ietf.org" Subject: Re: [abfab] [kitten] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session ** X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: oauth@ietf.org List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 07:02:37 -0000 [That is some cc list! Do you really need a cc list that large for this thread? I've set the reply-to to just oauth@ietf.org (note: I'm NOT subscribed to that list). Please honor the reply-to header. It's a good idea to set reply-to when making announcements, so that replies don't flood people who are almost certainly not interested.] On Tue, Nov 09, 2010 at 08:07:56AM +0000, torsten@lodderstedt.net wrote: > We think the security considerations should be based on a threat model > of OAuth. But a complete threat model would blow up the spec. Really? I would think that a threat model for OAuth could be described fairly briefly. What is the typical value of resources protected by OAuth? What kinds of attackers (active, passive, ...) does OAuth aim to defeat, and under what assumptions (end-points are secure, trusted third parties are trustworthy, certain cryptographic algorithms are not broken with parameters in certain ranges, smartcards are secure, ...)? Which kinds of attacks does OAuth explicitly not protect against (e.g., DoS)? What resources do you expect attackers to apply to compromising resources protected by OAuth? A few pages should do for the threat model. An abstract of the OAuth threat model should also be possible to write. > We therefore aim to produce a separate security document > (informational I-D/RFC) covering threat model as well as security > design and considerations. The security considerations section of the > core spec can then be distilled from this document. Sure. Procedurally speaking, that works. Nico -- From hartmans@mit.edu Wed Nov 10 15:59:28 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D97BC3A67A1 for ; Wed, 10 Nov 2010 15:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4gyk5WrRV2U for ; Wed, 10 Nov 2010 15:59:27 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 913273A67FB for ; Wed, 10 Nov 2010 15:59:27 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-4d02.meeting.ietf.org [130.129.77.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4AB28202C7; Wed, 10 Nov 2010 18:59:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2B8084761; Wed, 10 Nov 2010 18:59:49 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Wed, 10 Nov 2010 18:59:49 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Mailman-Approved-At: Wed, 10 Nov 2010 16:20:06 -0800 Cc: hardjono@mit.edu Subject: [abfab] [Thomas Hardjono] [Ietf-krb-wg] Charter Update -- RE: Camellia-CCM X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Nov 2010 23:59:28 -0000 --=-=-= FYI, Kerberos participants are considering doing work on inter-organizational federation. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Wed, 10 Nov 2010 10:44:37 -0500 X-Sieve: CMU Sieve 2.2 Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mail.suchdamage.org (Postfix) with ESMTP id 27AC3202B2 for ; Wed, 10 Nov 2010 10:44:33 -0500 (EST) Received: from mailhub-dmz-3.mit.edu ( [18.9.21.42]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 41.D0.02580.6FDBADC4; Wed, 10 Nov 2010 10:44:54 -0500 (EST) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mailhub-dmz-3.mit.edu (8.13.8/8.9.2) with ESMTP id oAAFireN009794; Wed, 10 Nov 2010 10:44:53 -0500 Received: from mailhost.anl.gov ( [130.202.113.50]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 30.D0.02580.5FDBADC4; Wed, 10 Nov 2010 10:44:53 -0500 (EST) Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id ED66356; Wed, 10 Nov 2010 09:44:52 -0600 (CST) Received: from lists.anl.gov (katydid.it.anl.gov [146.137.96.32]) by mailhost.anl.gov (Postfix) with ESMTP id C1C023C; Wed, 10 Nov 2010 09:44:52 -0600 (CST) Received: from katydid.it.anl.gov (localhost [127.0.0.1]) by lists.anl.gov (Postfix) with ESMTP id 9EC3080031; Wed, 10 Nov 2010 09:44:52 -0600 (CST) X-Original-To: ietf-krb-wg@lists.anl.gov Delivered-To: ietf-krb-wg@lists.anl.gov Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by lists.anl.gov (Postfix) with ESMTP id 36FD180031 for ; Wed, 10 Nov 2010 09:44:51 -0600 (CST) Received: by mailhost.anl.gov (Postfix) id 316C93C; Wed, 10 Nov 2010 09:44:51 -0600 (CST) Delivered-To: ietf-krb-wg@anl.gov Received: from mailhost.anl.gov (mailhost.anl.gov [130.202.113.50]) by localhost.anl.gov (Postfix) with ESMTP id 2D14956 for ; Wed, 10 Nov 2010 09:44:51 -0600 (CST) Received: from mailrelay.anl.gov (mailrelay.anl.gov [130.202.101.22]) by mailhost.anl.gov (Postfix) with ESMTP id 100393C for ; Wed, 10 Nov 2010 09:44:51 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by localhost.it.anl.gov (Postfix) with ESMTP id EDB237CC086; Wed, 10 Nov 2010 09:44:50 -0600 (CST) Received: from mailrelay.anl.gov ([127.0.0.1]) by localhost (mailrelay.anl.gov [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04864-03; Wed, 10 Nov 2010 09:44:50 -0600 (CST) Received: from mailgateway.anl.gov (mailgateway.anl.gov [130.202.101.28]) by mailrelay.anl.gov (Postfix) with ESMTP id C8D9C7CC081 for ; Wed, 10 Nov 2010 09:44:50 -0600 (CST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoBABZM2kwSCRkPmWdsb2JhbACDOZ4bYRUBAQIBCAsKBxEirQGIFIhpgSKBUIFlcwSEWoUNcIMSiAM X-IronPort-AV: E=Sophos;i="4.59,178,1288587600"; d="scan'208";a="50382420" Received: from dmz-mailsec-scanner-4.mit.edu ([18.9.25.15]) by mailgateway.anl.gov with ESMTP; 10 Nov 2010 09:44:50 -0600 X-AuditID: 1209190d-b7cacae000000a14-0a-4cdabdf65399 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-4.mit.edu (Symantec Brightmail Gateway) with SMTP id 95.9C.02603.2FDBADC4; Wed, 10 Nov 2010 10:44:50 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id oAAFinS3016573; Wed, 10 Nov 2010 10:44:49 -0500 Received: from oc11exedge1.exchange.mit.edu (OC11EXEDGE1.EXCHANGE.MIT.EDU [18.9.3.17]) ) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id oAAFin9Y002989; Wed, 10 Nov 2010 10:44:49 -0500 Received: from w92exhub6.exchange.mit.edu (18.7.73.12) by oc11exedge1.exchange.mit.edu (18.9.3.17) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 10 Nov 2010 10:43:52 -0500 Received: from EXPO10.exchange.mit.edu ([18.9.4.15]) by w92exhub6.exchange.mit.edu ([18.7.73.12]) with mapi; Wed, 10 Nov 2010 10:44:48 -0500 From: Thomas Hardjono To: "jhutz\@cmu.edu" , "ietf-krb-wg\@anl.gov" Date: Wed, 10 Nov 2010 10:44:47 -0500 Thread-Topic: Charter Update -- RE: [Ietf-krb-wg] Camellia-CCM Thread-Index: AcuA7jMGIX8QSeoyTxSj8zUsnLdo/A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Brightmail-Tracker: AAAAAA== X-Virus-Scanned: Debian amavisd-new at frigga.it.anl.gov Subject: [Ietf-krb-wg] Charter Update -- RE: Camellia-CCM X-BeenThere: ietf-krb-wg@lists.anl.gov X-Mailman-Version: 2.1.13 Precedence: list List-Id: "This is a list for the IETF Kerberos Working Group. {WORLDPUB, EXTERNAL}" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-krb-wg-bounces@lists.anl.gov Errors-To: ietf-krb-wg-bounces@lists.anl.gov X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Wed Nov 10 10:44:37 2010 X-DSPAM-Confidence: 0.9980 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,4cdabde512171437917882 X-DSPAM-Factors: 27, List-Help*request, 0.00010, From*Thomas Hardjono , 0.00010, List-Post*, 0.00019, new+>, 0.00042, List-Subscribe* -----Original Message----- > From: ietf-krb-wg-bounces@lists.anl.gov [mailto:ietf-krb-wg- > bounces@lists.anl.gov] On Behalf Of Jeffrey Hutzelman > Sent: Tuesday, November 09, 2010 2:12 PM > To: ietf-krb-wg@anl.gov > Cc: jhutz@cmu.edu > Subject: [Ietf-krb-wg] Camellia-CCM > ... > I am currently in the process of preparing a proposed charter update, > which unfortunately will probably not be ready in time for discussion > at Friday's meeting. I would like that charter to include work on new > and updated enctype specifications, as I expect to see us wanting to do > additional work in that space. Once the new charter is published, we > will adopt this work under that charter, if it is still ongoing and the > new charter permits. Last week at the Internet Identity Workshop (IIW) during my presentation on Kerberos (on why I thought OAuth2.0 was semantically very close to Kerberos V5, if not a straight re-invent), there was a comment from one of the leading SaaS provider that Kerberos was NOT an "Internet-scale" (inter-Enterprise) solution/protocol. His main gripe was the fact that there was no easy way to establish cross-realm trust between differing providers. So, with this in mind I would strongly recommend that the Charter Update include as deliverable one or more specification(s) covering scalable cross-realm trust establishment and management. cheers, /thomas/ _______________________________________________ ietf-krb-wg mailing list ietf-krb-wg@lists.anl.gov https://lists.anl.gov/mailman/listinfo/ietf-krb-wg --=-=-=-- From hauke@hauke-m.de Tue Nov 23 15:10:46 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B1073A69DA for ; Tue, 23 Nov 2010 15:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay5190qmiRnq for ; Tue, 23 Nov 2010 15:10:43 -0800 (PST) Received: from hauke-m.de (server19320154104.serverpool.info [193.201.54.104]) by core3.amsl.com (Postfix) with ESMTP id B3F6128C0E2 for ; Tue, 23 Nov 2010 15:10:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 247ED87AA for ; Wed, 24 Nov 2010 00:11:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at hauke-m.de Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZPSG0b5iy8t for ; Wed, 24 Nov 2010 00:11:28 +0100 (CET) Received: from [192.168.0.200] (host-091-097-249-199.ewe-ip-backbone.de [91.97.249.199]) by hauke-m.de (Postfix) with ESMTPSA id C6E2E8799 for ; Wed, 24 Nov 2010 00:11:28 +0100 (CET) Message-ID: <4CEC4A1F.3090707@hauke-m.de> Date: Wed, 24 Nov 2010 00:11:27 +0100 From: Hauke Mehrtens User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] How is SAML used? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 23:10:46 -0000 Hi, how is SAML handled in abfab? In the slides at the WG 79 IETF meeting on http://www.ietf.org/proceedings/79/slides/abfab-4.pdf page 6 it looks like the SAML Issuer is some extra service provided by the Identity provider to which the relaying party has to talk to in addition to the EAP server. Is that correct or is the SAML assertion transported in EAP packages through the EAP server? Are there real SAML request and response messages in the architecture anywhere or is the hole request and response stuff done in some special EAP messages and this just uses the SAML assertions in some way to provide additional informations about a user? Is there a description for the image on page 10 of draft-lear-abfab-arch describing when the messages go through what channel? I really liked how kitten did it in draft-ietf-kitten-sasl-saml-01 in section 3 and in the example in section 7.1 describing the messages going over the connections. Hauke From hartmans@painless-security.com Tue Nov 23 20:31:06 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3269828C100 for ; Tue, 23 Nov 2010 20:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.688 X-Spam-Level: X-Spam-Status: No, score=-3.688 tagged_above=-999 required=5 tests=[AWL=-2.912, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fstRBqm1SjBF for ; Tue, 23 Nov 2010 20:31:05 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 74A2E28C1D0 for ; Tue, 23 Nov 2010 20:31:05 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3A1CE20222; Tue, 23 Nov 2010 23:31:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BADAA4644; Tue, 23 Nov 2010 23:31:52 -0500 (EST) From: Sam Hartman To: Hauke Mehrtens References: <4CEC4A1F.3090707@hauke-m.de> Date: Tue, 23 Nov 2010 23:31:52 -0500 In-Reply-To: <4CEC4A1F.3090707@hauke-m.de> (Hauke Mehrtens's message of "Wed, 24 Nov 2010 00:11:27 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] How is SAML used? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 04:31:06 -0000 Hi. Later in the meeting we had a long discussion of draft-ietf-abfab-aaa-saml (including a lot of slides and a lot more in-person discussion) that gets at several of your issues: * Where is SAML sent (AAA attribute) * Are there real SAML request/responses (probably but open issue) The communication between the AAA server and the IDP is out of scope. You could potentially link an IDP directly into your AAA server if you wished. Today, it's going to be more realistic for you to issue authentication requests or attribute queries to your IDP from within your AAA server. In many cases the GSS acceptor will not need to generate a SAML request, but several of us want to retain that flexibility. We're glad you like the diagrams in the kitten documents. On a call today, those of us who are authors of the architecture documents decided we need similar diagrams in our next version. --Sam From Josh.Howlett@ja.net Wed Nov 24 00:26:17 2010 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBF3F3A6A11 for ; Wed, 24 Nov 2010 00:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.346 X-Spam-Level: X-Spam-Status: No, score=-101.346 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7BUEmq6+6D6 for ; Wed, 24 Nov 2010 00:26:17 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 0255D3A6A00 for ; Wed, 24 Nov 2010 00:26:16 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CDD294A6B50_CECCC62B; Wed, 24 Nov 2010 08:27:14 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id BD8914A6B4A_CECCC61F; Wed, 24 Nov 2010 08:27:13 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Wed, 24 Nov 2010 08:27:13 +0000 From: Josh Howlett To: Hauke Mehrtens , "abfab@ietf.org" Thread-Topic: [abfab] How is SAML used? Thread-Index: AQHLi2Pcxuia2f+ez0uIbX3izsQA+JOALe0g Date: Wed, 24 Nov 2010 08:27:12 +0000 Message-ID: <7486C9B3D65BA24FB8A59D740F363C7703B925@EXC001> References: <4CEC4A1F.3090707@hauke-m.de> In-Reply-To: <4CEC4A1F.3090707@hauke-m.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] How is SAML used? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 08:26:18 -0000 Just adding a little to Sam's remarks... > it looks > like the SAML Issuer is some extra service provided by the Identity > provider to which the relaying party has to talk to in addition to the > EAP server. No, it's not an extra service; I agree the diagram is confusing. It's tryin= g to express that the Issuer could be the AAA server (sending a SAML messag= e in the AAA channel at time of EAP authentication) /or/ a conventional SAM= L authority (sending a SAML message using one of the standard SOAP bindings= , after the EAP authentication). > Is that correct or is the SAML assertion transported in EAP packages > through the EAP server? Not quite. If the SAML assertion is transported over AAA it is done /alongs= ide/ the EAP frames (i.e. EAP frames and SAML messages are both encapsulate= d within their respective AAA attributes, and themselves wrapped in AAA). > Are there real SAML request and response messages in the architecture > anywhere or is the hole request and response stuff done in some special > EAP messages and this just uses the SAML assertions in some way to > provide additional informations about a user? This was discussed at the meeting (you might want to listen to the archived= stream, or check out the AAA slideset); the balance of opinion in room was= that we should use real request and response messages. This is how it is c= urrently specified the draft. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG