From hannes.tschofenig@nsn.com Tue Oct 12 02:54: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 561A83A67D7 for ; Tue, 12 Oct 2010 02:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 Cnvb-Kam-YnQ for ; Tue, 12 Oct 2010 02:54:45 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 303F53A6783 for ; Tue, 12 Oct 2010 02:54:45 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9C9tvrr018518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Oct 2010 11:55:57 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9C9tqto006192 for ; Tue, 12 Oct 2010 11:55:57 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 11:55:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Oct 2010 12:56:12 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Federation Terminology Thread-Index: Actp87OoorXO4vRjTDKvGK2a2u9q0w== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Oct 2010 09:55:51.0967 (UTC) FILETIME=[A7943AF0:01CB69F3] Subject: [abfab] Federation Terminology 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, 12 Oct 2010 09:54:46 -0000 Hi guys,=20 I was wondering whether someone of you has some good terminology for the federation concept?=20 In the draft writeup I prepared for the BOF (draft-tschofenig-moonshot-ps) I ran into the problem of not having useful terms. draft-hansen-privacy-terminology talks about identity management but does not touch the topic of federations.=20 I thought it would be useful to ask this group since the term "Federated" appears many times in the charter text... Ciao Hannes From hannes.tschofenig@nsn.com Tue Oct 12 02:59:45 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 069CD3A690B for ; Tue, 12 Oct 2010 02:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.426 X-Spam-Level: X-Spam-Status: No, score=-102.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 GjpQjP9eM+H4 for ; Tue, 12 Oct 2010 02:59:44 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id EF0683A6765 for ; Tue, 12 Oct 2010 02:59:43 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o9CA0t5R020718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Oct 2010 12:00:55 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o9CA0qYm023464 for ; Tue, 12 Oct 2010 12:00:52 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Oct 2010 12:00:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Oct 2010 13:01:12 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B45032D5807@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Tutorial Slides Thread-Index: Actp9GaC/qz+gaVYRJqIgIGFnwzLLA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Oct 2010 10:00:51.0539 (UTC) FILETIME=[5A234A30:01CB69F4] Subject: [abfab] Tutorial Slides 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, 12 Oct 2010 09:59:45 -0000 Hi all,=20 I was wondering whether someone has some tutorial slides about the "Application Bridging for Federated Access Beyond web (abfab)"/Moonshot effort somewhere?=20 Ciao Hannes From hartmans@painless-security.com Tue Oct 12 05:53: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 EF4CE3A696C for ; Tue, 12 Oct 2010 05:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, 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 o9bayqY35D9w for ; Tue, 12 Oct 2010 05:53:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 15C883A6948 for ; Tue, 12 Oct 2010 05:53:27 -0700 (PDT) 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 C226D200B4; Tue, 12 Oct 2010 08:54:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5B02441DD; Tue, 12 Oct 2010 08:54:25 -0400 (EDT) From: Sam Hartman To: "Tschofenig\, Hannes \(NSN - FI\/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B45032D5807@FIESEXC015.nsn-intra.net> Date: Tue, 12 Oct 2010 08:54:25 -0400 In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45032D5807@FIESEXC015.nsn-intra.net> (Hannes Tschofenig's message of "Tue, 12 Oct 2010 13:01:12 +0300") 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] Tutorial Slides 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, 12 Oct 2010 12:53:29 -0000 Hi. All the media we have is collect at www.project-moonshot.org. The slides from the Copenhagen presentation have some useful technical tutorial material. - --Sam From hartmans@painless-security.com Tue Oct 12 05:54:37 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 F3DD83A6948 for ; Tue, 12 Oct 2010 05:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, 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 UtcyJgm9F85U for ; Tue, 12 Oct 2010 05:54:36 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0C0673A696F for ; Tue, 12 Oct 2010 05:54:36 -0700 (PDT) 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 3BBDA20178; Tue, 12 Oct 2010 08:55:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E0D1741DD; Tue, 12 Oct 2010 08:55:34 -0400 (EDT) From: Sam Hartman To: "Tschofenig\, Hannes \(NSN - FI\/Espoo\)" References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> Date: Tue, 12 Oct 2010 08:55:34 -0400 In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> (Hannes Tschofenig's message of "Tue, 12 Oct 2010 12:56:12 +0300") 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] Federation Terminology 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, 12 Oct 2010 12:54:37 -0000 Can you give some examples of the sorts of terminology problems you are running into? I suspect I've been solving some of them by being more verbose and may not have noticed other issues. --Sam From hannes.tschofenig@gmx.net Tue Oct 12 07:56:12 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 309E33A69A0 for ; Tue, 12 Oct 2010 07:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.944 X-Spam-Level: X-Spam-Status: No, score=-100.944 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 KMz8-w2LOGDi for ; Tue, 12 Oct 2010 07:56:11 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id CC17D3A699F for ; Tue, 12 Oct 2010 07:56:10 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2010 14:57:23 -0000 Received: from unknown (EHLO [10.254.0.142]) [192.100.123.77] by mail.gmx.net (mp008) with SMTP; 12 Oct 2010 16:57:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/EuUgmjnnELTRr0JZBWj+AmDds6IMRM+GbXXmyHe C15wQHD/bMWfL9 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 12 Oct 2010 17:57:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> To: Sam Hartman X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: abfab@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 14:56:12 -0000 Give me a good definition for "federation".=20 I searched around and ran into the following definition (based on = Y-2720): " federation: establishing a relationship between two or more entities or = an association comprising=20 any number of service providers and identity providers. " ISO/IEC CD 24760-1 does not have a term for federation but for identity = federation instead. Here is it: identity federation=20 agreement between two or more domains specifying how identity = information will be exchanged and managed for cross-domain = identification purposes. Identity is set of attributes related to an = entity. Entity is an item of interest, inside or outside an ICT system, = such as a person, an organization, a device, a subsystem, or a group of = such items that has recognizably distinct existence I am not happy with both of these terms.=20 Ciao Hannes On Oct 12, 2010, at 3:55 PM, Sam Hartman wrote: > Can you give some examples of the sorts of terminology problems you = are > running into? I suspect I've been solving some of them by being more > verbose and may not have noticed other issues. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Tue Oct 12 07:59: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 E87363A69AE for ; Tue, 12 Oct 2010 07:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, 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 YnQL6TxuhkVi for ; Tue, 12 Oct 2010 07:59:30 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3CEA03A69AC for ; Tue, 12 Oct 2010 07:59:30 -0700 (PDT) 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 5D20E20178; Tue, 12 Oct 2010 11:00:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A01D441DD; Tue, 12 Oct 2010 11:00:21 -0400 (EDT) From: Sam Hartman To: Hannes Tschofenig References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> Date: Tue, 12 Oct 2010 11:00:21 -0400 In-Reply-To: <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> (Hannes Tschofenig's message of "Tue, 12 Oct 2010 17:57:21 +0300") 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, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 14:59:31 -0000 Both of those definitions seem consistent with what we've been doing. So, I don't think we've hit a point yet where they fall apart. --Sam From lear@cisco.com Tue Oct 12 08:04:29 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 BD8083A69AC for ; Tue, 12 Oct 2010 08:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.265 X-Spam-Level: X-Spam-Status: No, score=-109.265 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 0BRmqyTv1l5v for ; Tue, 12 Oct 2010 08:04:25 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 02B063A69A7 for ; Tue, 12 Oct 2010 08:04:24 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4EAL8VtEyQ/khLgWdsb2JhbACDHp4zFQEBCwsiIqIAihuSYYEigzJ0BIpB X-IronPort-AV: E=Sophos;i="4.57,320,1283731200"; d="scan'208";a="66452190" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Oct 2010 15:05:38 +0000 Received: from dhcp-10-61-100-220.cisco.com (dhcp-10-61-100-220.cisco.com [10.61.100.220]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9CF5cdh000660; Tue, 12 Oct 2010 15:05:38 GMT Message-ID: <4CB47963.2070607@cisco.com> Date: Tue, 12 Oct 2010 17:06:11 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Hannes Tschofenig References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> In-Reply-To: <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 15:04:29 -0000 Hi Hannes, > I am not happy with both of these terms. And what makes you unhappy, and does it make you unhappy enough to want to define yet a third set of terms? Eliot From hannes.tschofenig@gmx.net Tue Oct 12 08:34:02 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 C54DA3A68E4 for ; Tue, 12 Oct 2010 08:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.927 X-Spam-Level: X-Spam-Status: No, score=-100.927 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 Id9Gh5sju+BD for ; Tue, 12 Oct 2010 08:34:02 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 11E983A69DA for ; Tue, 12 Oct 2010 08:34:00 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2010 15:35:14 -0000 Received: from unknown (EHLO [10.254.0.142]) [192.100.123.77] by mail.gmx.net (mp057) with SMTP; 12 Oct 2010 17:35:14 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18xmWoJOYMxCS9wnh2TAQo0kt/K/++zv5QnAtbO// fn+XCS3/Pfsn2U Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4CB47963.2070607@cisco.com> Date: Tue, 12 Oct 2010 18:35:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: abfab@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 15:34:02 -0000 Great to hear that you both are pretty easy when it comes to = terminology.=20 Why was I unhappy?=20 I liked the Liberty Alliance definition more: "An association = compromising any number of service providers and identity providers." = maybe adding the AAA specific aspect that there are additional actors, = such as brokers. The aspect that these entities belong to different = administrative domains might also be worth mentioning. I thought it would be useful to select one.=20 Ciao Hannes On Oct 12, 2010, at 6:06 PM, Eliot Lear wrote: > Hi Hannes, >=20 >> I am not happy with both of these terms.=20 >=20 > And what makes you unhappy, and does it make you unhappy enough to = want > to define yet a third set of terms? >=20 > Eliot From Josh.Howlett@ja.net Tue Oct 12 08:45:53 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 D9BFF3A69D6 for ; Tue, 12 Oct 2010 08:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.307 X-Spam-Level: X-Spam-Status: No, score=-100.307 tagged_above=-999 required=5 tests=[AWL=-0.308, BAYES_50=0.001, 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 4sC7luz9Fslc for ; Tue, 12 Oct 2010 08:45:53 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 4461E3A69DB for ; Tue, 12 Oct 2010 08:45:52 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CB2C94A6B6C_CB482F9B; Tue, 12 Oct 2010 15:47:05 +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 BE8264A6B66_CB482F8F; Tue, 12 Oct 2010 15:47:04 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Tue, 12 Oct 2010 16:47:17 +0100 From: Josh Howlett To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "abfab@ietf.org" Thread-Topic: Federation Terminology Thread-Index: Actp87OoorXO4vRjTDKvGK2a2u9q0wALTEfQ Date: Tue, 12 Oct 2010 15:46:59 +0000 Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> 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] Federation Terminology 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, 12 Oct 2010 15:45:53 -0000 > I was wondering whether someone of you has some good terminology for > the federation concept? I think it's most helpful to think about a federation as describing the rel= ationship between two or more actors. It's more of a social/business concep= t, than a technical one - if it's a technical one at all. I tend to think a= bout a federation as a policy regime that allows the participating actors t= o derive some common expectations of each other. 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 From hartmans@painless-security.com Tue Oct 12 08:48:09 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 46D353A69C1 for ; Tue, 12 Oct 2010 08:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 DASHOqT-xWIF for ; Tue, 12 Oct 2010 08:48:08 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 71A853A69BA for ; Tue, 12 Oct 2010 08:48:08 -0700 (PDT) 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 D51A7200B4; Tue, 12 Oct 2010 11:49:22 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7915441DD; Tue, 12 Oct 2010 11:49:05 -0400 (EDT) From: Sam Hartman To: Hannes Tschofenig References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> Date: Tue, 12 Oct 2010 11:49:05 -0400 In-Reply-To: <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> (Hannes Tschofenig's message of "Tue, 12 Oct 2010 18:35:11 +0300") 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, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 15:48:09 -0000 I think I'll start to have an opinion about definitions when I get to a point where one definition seems appropriate and another does not. None of these seem to capture a concept that the Moonshot folks value: a disconnect between the interaction between the subject and IDP and the IDP and SP. As we saw at the BOF, folks familiar with the US's federal bridge CA point out that this disconnect is not necessary to achieve a level of federation. However I'm quite certain that the Moonshot proponents would not be happy with a bridge CA and moderately they would end up requiring the separation in interaction. I'll note that none of these terms really capture that sort of distinction. So, until I understand exactly what we're trying to accomplish with clear terminology, it's difficult for me to develop a strong opinion. I believe every definition you've proposed is within the general area of where we're working. --Sam From Josh.Howlett@ja.net Tue Oct 12 09:02:52 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 CE0673A68D6 for ; Tue, 12 Oct 2010 09:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.583 X-Spam-Level: X-Spam-Status: No, score=-101.583 tagged_above=-999 required=5 tests=[AWL=1.016, 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 rmgAi9nXokDO for ; Tue, 12 Oct 2010 09:02:52 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id E01953A63EB for ; Tue, 12 Oct 2010 09:02:51 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9D76F4A6B3F_CB486F5B; Tue, 12 Oct 2010 16:04:05 +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 81E4C4A6B3C_CB486F2F; Tue, 12 Oct 2010 16:04:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Tue, 12 Oct 2010 17:04:15 +0100 From: Josh Howlett To: Hannes Tschofenig , Eliot Lear Thread-Topic: [abfab] Federation Terminology Thread-Index: AQHLag0BzTPz2rRHjku0Gu79/ogjeZM9Vq2AgAACeICAAAgagIAAFGZw Date: Tue, 12 Oct 2010 16:04:14 +0000 Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> In-Reply-To: <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> 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 , "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 16:02:52 -0000 > I thought it would be useful to select one. I agree we should definitely define 'federated authentication' and probably= also 'federated identity' (FWIW, SAML Glossary defines the latter, but not= the former). I'm not sure if we really need to worry about the broader 'fe= deration' concept, it might be a bit of a rat-hole. 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 From Nicolas.Williams@oracle.com Tue Oct 12 09:08: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 1F1CA3A63EB for ; Tue, 12 Oct 2010 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.035, 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 1D8cDKIg-txo for ; Tue, 12 Oct 2010 09:08:33 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id EE6DE3A6916 for ; Tue, 12 Oct 2010 09:08:32 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9CG9hNk026562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2010 16:09:44 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9CBUGkE012615; Tue, 12 Oct 2010 16:09:42 GMT Received: from abhmt012.oracle.com by acsmt353.oracle.com with ESMTP id 684300281286899780; Tue, 12 Oct 2010 09:09:40 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 09:09:38 -0700 Date: Tue, 12 Oct 2010 11:09:31 -0500 From: Nicolas Williams To: Hannes Tschofenig Message-ID: <20101012160928.GF1635@oracle.com> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 16:08:34 -0000 On Tue, Oct 12, 2010 at 06:35:11PM +0300, Hannes Tschofenig wrote: > I liked the Liberty Alliance definition more: "An association > compromising any number of service providers and identity providers." > maybe adding the AAA specific aspect that there are additional actors, > such as brokers. The aspect that these entities belong to different > administrative domains might also be worth mentioning. Sounds like you want better definitions rather than new terminology. First, a nit: s/compromising/comprising/ :) Second, I don't think mentioning specific technologies or types of technologies in the definition of "federation" is terribly important right now. The essential question is: what do federations provide to their members? Now, "federation" can seem ambiguous, but that may be an advantage because it may be too soon to draw strong distinctions between ongoing, independent efforts in this area. Consider, for example, ABFAB and NFSv4. Here in ABFAB it seems to mean "a collection of distinct administrative domains which arrange for participating services to be able to authenticate users, and obtain authorization-relevant information about them, from participating domains". Over in the NFSv4 WG the term "federated namespace" refers to a global namespace constructed out of DNS SRV RRs, NFSv4 referrals, and conventions for using LDAP to store information that NFSv4 servers need to construct namespaces. This surely seems unrelated to ABFAB but NFSv4 also has an aspect of identification, authentication and authorization that is involved in creating a "federated namespace". Some of us are proposing a method of constructing a federated namespace for NFSv4 that covers the naming of users and groups of users, and which ties authentication and authorization into the picture. As you can see, there's some overlap between the NFSv4 concept of federation and ABFAB's, yet the technologies involved are different. To be fair, I think NFSv4 could use ABFAB as one set or sub-set of technologies in building NFSv4 federations -- after all, NFSv4 uses the GSS-API. But NFSv4 also needs name resolution services so that users can create, view and edit access control lists (ACLs). ABFAB provides no such services. Question: to what extent other ABFAB apps will need name services, and should ABFAB provide them? The slight ambiguity of the term 'federation' has proven useful to me: it's helped me reach the point where I could ask the above question by making me consider the differences and similarities between two conceptions of 'federation'. Nico -- From rlmorgan@washington.edu Tue Oct 12 09:08:53 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 1252A3A69A9 for ; Tue, 12 Oct 2010 09:08:53 -0700 (PDT) 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 MNRk3OGEZ2+X for ; Tue, 12 Oct 2010 09:08:51 -0700 (PDT) Received: from mxout13.cac.washington.edu (mxout13.cac.washington.edu [140.142.32.202]) by core3.amsl.com (Postfix) with ESMTP id BFA013A6982 for ; Tue, 12 Oct 2010 09:08:51 -0700 (PDT) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.34] (may be forged)) by mxout13.cac.washington.edu (8.14.3+UW09.11/8.14.3+UW10.10) with ESMTP id o9CG9kbq027278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Oct 2010 09:09:46 -0700 X-Auth-Received: from D-69-91-163-114.dhcp4.washington.edu (D-69-91-163-114.dhcp4.washington.edu [69.91.163.114]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.3+UW09.11/8.14.3+UW09.11) with ESMTP id o9CG9ktV008458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 12 Oct 2010 09:09:46 -0700 Date: Tue, 12 Oct 2010 09:09:45 -0700 (PDT) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@permafrost To: abfab@ietf.org In-Reply-To: <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2010.10.12.160018 X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1300_1399 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, FROM_NAME_PHRASE 0, INVALID_MSGID_NO_FQDN 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __FRAUD_CONTACT_NAME 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0' Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 16:08:53 -0000 > I liked the Liberty Alliance definition more: "An association > compromising any number of service providers and identity providers." > maybe adding the AAA specific aspect that there are additional actors, > such as brokers. The aspect that these entities belong to different > administrative domains might also be worth mentioning. It has long been a problem that there are two common senses of the term "federation" in this area. One is the pairwise sense you mentioned earlier: a service in one administrative domain relies on identity services from another domain. People say organizations "federate" when they make this pairwise arrangement. The other is the multi-organizational sense you mention above, which is closer to the regular dictionary definition of federation. There are lots of operational federations in this sense (see https://refeds.terena.org/index.php/Federations for a list in the research&education sector). At the technical level that is the concern of abfab I think the pairwise definition is more relevant. Sometimes I use the term "multi-organizational federation" to specifically indicate the second sense. In any case I would suggest using the term "identity federation" for what we're talking about here, since "federation" per se has lots of other uses in IT (eg federated naming). - RL "Bob" From Josh.Howlett@ja.net Tue Oct 12 09:23:55 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 506C33A6927 for ; Tue, 12 Oct 2010 09:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.656 X-Spam-Level: X-Spam-Status: No, score=-101.656 tagged_above=-999 required=5 tests=[AWL=0.943, 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 gQtPdBYHnAJt for ; Tue, 12 Oct 2010 09:23:54 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 5ECC93A63EB for ; Tue, 12 Oct 2010 09:23:54 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6B3E84A6BB1_CB48BE4B; Tue, 12 Oct 2010 16:25:08 +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 537B44A6B50_CB48BE1F; Tue, 12 Oct 2010 16:25:05 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Tue, 12 Oct 2010 17:25:17 +0100 From: Josh Howlett To: Nicolas Williams , Hannes Tschofenig Thread-Topic: [abfab] Federation Terminology Thread-Index: AQHLag0BzTPz2rRHjku0Gu79/ogjeZM9Vq2AgAACeICAAAgagIAACZiAgAAR3QA= Date: Tue, 12 Oct 2010 16:23:02 +0000 Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> In-Reply-To: <20101012160928.GF1635@oracle.com> 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 , "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 16:23:55 -0000 > Over in the NFSv4 WG the term "federated namespace" refers to a global > namespace constructed out of DNS SRV RRs, NFSv4 referrals, and > conventions for using LDAP to store information that NFSv4 servers need > to construct namespaces. This surely seems unrelated to ABFAB Yes, they're unrelated at a technical level. At a business level, the act o= f delegating a set of responsibilities to the other party(ies) is similar. > Question: to what extent other ABFAB apps will need name services, and > should ABFAB provide them? I believe that some apps will need name services. I believe that ABFAB shou= ld provide these, where possible, by leveraging existing related mechanisms= (e.g. SAML and/or RADIUS attributes). 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 From eve@xmlgrrl.com Tue Oct 12 09:30: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 DB91B3A69AE for ; Tue, 12 Oct 2010 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.934 X-Spam-Level: X-Spam-Status: No, score=-0.934 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] 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 CF1qR0yjRDP0 for ; Tue, 12 Oct 2010 09:30:42 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 01E663A63EB for ; Tue, 12 Oct 2010 09:30:41 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o9CGVpba006063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Oct 2010 09:31:51 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: <20101012160928.GF1635@oracle.com> Date: Tue, 12 Oct 2010 09:31:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) Cc: abfab@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 16:30:46 -0000 Here was my own entry into the federation terminology sweepstakes once = upon a time... :-) http://www.xmlgrrl.com/blog/2007/07/17/account-linking-and-the-f-word/ Also note that, while the F-word fits the abfab community comfortably, = there are other communities that don't like the word but gravitate = towards "trust" language more. A bunch of terms relevant to federations = are introduced here, for example: = http://openidentityexchange.org/sites/default/files/the-open-identity-trus= t-framework-model-2010-03.pdf Even more terms are introduced in this old doc: = http://www.oasis-open.org/committees/download.php/6158/sstc-saml-trustmode= ls-2.0-draft-01.pdf Hannes, if you feel inclined to write a federation equivalent of = draft-hansen-privacy-terminology (!), I'm happy to try and help/review. Eve On 12 Oct 2010, at 9:09 AM, Nicolas Williams wrote: > On Tue, Oct 12, 2010 at 06:35:11PM +0300, Hannes Tschofenig wrote: >> I liked the Liberty Alliance definition more: "An association >> compromising any number of service providers and identity providers." >> maybe adding the AAA specific aspect that there are additional = actors, >> such as brokers. The aspect that these entities belong to different >> administrative domains might also be worth mentioning. >=20 > Sounds like you want better definitions rather than new terminology. >=20 > First, a nit: s/compromising/comprising/ :) >=20 > Second, I don't think mentioning specific technologies or types of > technologies in the definition of "federation" is terribly important > right now. The essential question is: what do federations provide to > their members? >=20 > Now, "federation" can seem ambiguous, but that may be an advantage > because it may be too soon to draw strong distinctions between = ongoing, > independent efforts in this area. Consider, for example, ABFAB and > NFSv4. >=20 > Here in ABFAB it seems to mean "a collection of distinct = administrative > domains which arrange for participating services to be able to > authenticate users, and obtain authorization-relevant information = about > them, from participating domains". >=20 > Over in the NFSv4 WG the term "federated namespace" refers to a global > namespace constructed out of DNS SRV RRs, NFSv4 referrals, and > conventions for using LDAP to store information that NFSv4 servers = need > to construct namespaces. This surely seems unrelated to ABFAB but = NFSv4 > also has an aspect of identification, authentication and authorization > that is involved in creating a "federated namespace". >=20 > Some of us are proposing a method of constructing a federated = namespace > for NFSv4 that covers the naming of users and groups of users, and = which > ties authentication and authorization into the picture. >=20 > As you can see, there's some overlap between the NFSv4 concept of > federation and ABFAB's, yet the technologies involved are different. = To > be fair, I think NFSv4 could use ABFAB as one set or sub-set of > technologies in building NFSv4 federations -- after all, NFSv4 uses = the > GSS-API. >=20 > But NFSv4 also needs name resolution services so that users can = create, > view and edit access control lists (ACLs). ABFAB provides no such > services. >=20 > Question: to what extent other ABFAB apps will need name services, and > should ABFAB provide them? >=20 > The slight ambiguity of the term 'federation' has proven useful to me: > it's helped me reach the point where I could ask the above question by > making me consider the differences and similarities between two > conceptions of 'federation'. >=20 > Nico > --=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From Nicolas.Williams@oracle.com Tue Oct 12 09:34:45 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 F24193A68FF for ; Tue, 12 Oct 2010 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.035, 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 7QcE-gzTqfdz for ; Tue, 12 Oct 2010 09:34:43 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5FAD63A68F0 for ; Tue, 12 Oct 2010 09:34:43 -0700 (PDT) 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 o9CGZs3j000932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2010 16:35:55 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 o9CC2I0H010454; Tue, 12 Oct 2010 16:35:53 GMT Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 676449721286901326; Tue, 12 Oct 2010 09:35:26 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 09:35:24 -0700 Date: Tue, 12 Oct 2010 11:35:19 -0500 From: Nicolas Williams To: Josh Howlett Message-ID: <20101012163517.GH1635@oracle.com> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 16:34:45 -0000 On Tue, Oct 12, 2010 at 04:23:02PM +0000, Josh Howlett wrote: > > Over in the NFSv4 WG the term "federated namespace" refers to a global > > namespace constructed out of DNS SRV RRs, NFSv4 referrals, and > > conventions for using LDAP to store information that NFSv4 servers need > > to construct namespaces. This surely seems unrelated to ABFAB > > Yes, they're unrelated at a technical level. At a business level, the > act of delegating a set of responsibilities to the other party(ies) is > similar. Like I said, NFSv4 uses the GSS-API, so the two are not that unrelated. ABFAB federations allow participating services to authenticate users from participating domains and obtain useful authorization-relevant information about such authenticated users. Is that a fair characterization? NFSv4 federations allow at minimum for filesystem namespaces (possibly built from many NFSv4 servers) of participating domains to be accessible from others. NFSv4's concept of federation is quite minimal in that there need not be any sort of business or technical relationship between participating domains other than use of the DNS. But NFSv4 federations can also cover name services for user and group names and determinations of authenticated users' authorization contexts. And this does involve federated authentication (say, via Kerberos, via ABFAB, ...), and name resolution services. In its maximal form, NFSv4 federations don't seem unrelated to ABFAB, not to me. > > Question: to what extent other ABFAB apps will need name services, and > > should ABFAB provide them? > > I believe that some apps will need name services. I believe that ABFAB > should provide these, where possible, by leveraging existing related > mechanisms (e.g. SAML and/or RADIUS attributes). Neither SAML nor RADIUS are remotely like name services... Nico -- From hannes.tschofenig@gmx.net Tue Oct 12 09:42:20 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 D4B943A6931 for ; Tue, 12 Oct 2010 09:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.489 X-Spam-Level: X-Spam-Status: No, score=-101.489 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, 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 vwBUGQQsvMbR for ; Tue, 12 Oct 2010 09:42:19 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 59AAC3A63EB for ; Tue, 12 Oct 2010 09:42:18 -0700 (PDT) Received: (qmail invoked by alias); 12 Oct 2010 16:43:32 -0000 Received: from unknown (EHLO [10.254.0.142]) [192.100.123.77] by mail.gmx.net (mp061) with SMTP; 12 Oct 2010 18:43:32 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/4SZYQo0z45Wn+8NS4GP4gxnPwaIIuRdRn1c9qYK HtxvF6QGVk18LL Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 12 Oct 2010 19:43:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> To: Eve Maler X-Mailer: Apple Mail (2.1081) X-Y-GMX-Trusted: 0 Cc: abfab@ietf.org, "Tschofenig, Hannes \(NSN - FI/Espoo\)" , Nicolas Williams Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 16:42:21 -0000 Hey Eve,=20 I like the OIX writeup and I would use terminology from there but I = wasn't able to spot something that explains a federation. There you seem = to be talking about trust framework instead and that largely without = defined terminology (which makes the document actually quite difficult = to understand and to relate to work outside the OIX environment). I = would also like to understand how far a trust framework (as described in = the OIX document) relates to the federation concept. =20 Ciao Hannes On Oct 12, 2010, at 7:31 PM, Eve Maler wrote: > Here was my own entry into the federation terminology sweepstakes once = upon a time... :-) >=20 > http://www.xmlgrrl.com/blog/2007/07/17/account-linking-and-the-f-word/ >=20 > Also note that, while the F-word fits the abfab community comfortably, = there are other communities that don't like the word but gravitate = towards "trust" language more. A bunch of terms relevant to federations = are introduced here, for example: >=20 > = http://openidentityexchange.org/sites/default/files/the-open-identity-trus= t-framework-model-2010-03.pdf >=20 > Even more terms are introduced in this old doc: >=20 > = http://www.oasis-open.org/committees/download.php/6158/sstc-saml-trustmode= ls-2.0-draft-01.pdf >=20 > Hannes, if you feel inclined to write a federation equivalent of = draft-hansen-privacy-terminology (!), I'm happy to try and help/review. >=20 > Eve >=20 > On 12 Oct 2010, at 9:09 AM, Nicolas Williams wrote: >=20 >> On Tue, Oct 12, 2010 at 06:35:11PM +0300, Hannes Tschofenig wrote: >>> I liked the Liberty Alliance definition more: "An association >>> compromising any number of service providers and identity = providers." >>> maybe adding the AAA specific aspect that there are additional = actors, >>> such as brokers. The aspect that these entities belong to different >>> administrative domains might also be worth mentioning. >>=20 >> Sounds like you want better definitions rather than new terminology. >>=20 >> First, a nit: s/compromising/comprising/ :) >>=20 >> Second, I don't think mentioning specific technologies or types of >> technologies in the definition of "federation" is terribly important >> right now. The essential question is: what do federations provide to >> their members? >>=20 >> Now, "federation" can seem ambiguous, but that may be an advantage >> because it may be too soon to draw strong distinctions between = ongoing, >> independent efforts in this area. Consider, for example, ABFAB and >> NFSv4. >>=20 >> Here in ABFAB it seems to mean "a collection of distinct = administrative >> domains which arrange for participating services to be able to >> authenticate users, and obtain authorization-relevant information = about >> them, from participating domains". >>=20 >> Over in the NFSv4 WG the term "federated namespace" refers to a = global >> namespace constructed out of DNS SRV RRs, NFSv4 referrals, and >> conventions for using LDAP to store information that NFSv4 servers = need >> to construct namespaces. This surely seems unrelated to ABFAB but = NFSv4 >> also has an aspect of identification, authentication and = authorization >> that is involved in creating a "federated namespace". >>=20 >> Some of us are proposing a method of constructing a federated = namespace >> for NFSv4 that covers the naming of users and groups of users, and = which >> ties authentication and authorization into the picture. >>=20 >> As you can see, there's some overlap between the NFSv4 concept of >> federation and ABFAB's, yet the technologies involved are different. = To >> be fair, I think NFSv4 could use ABFAB as one set or sub-set of >> technologies in building NFSv4 federations -- after all, NFSv4 uses = the >> GSS-API. >>=20 >> But NFSv4 also needs name resolution services so that users can = create, >> view and edit access control lists (ACLs). ABFAB provides no such >> services. >>=20 >> Question: to what extent other ABFAB apps will need name services, = and >> should ABFAB provide them? >>=20 >> The slight ambiguity of the term 'federation' has proven useful to = me: >> it's helped me reach the point where I could ask the above question = by >> making me consider the differences and similarities between two >> conceptions of 'federation'. >>=20 >> Nico >> --=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 >=20 > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl >=20 From wwwrun@core3.amsl.com Tue Oct 12 10:03:34 2010 Return-Path: X-Original-To: abfab@ietf.org Delivered-To: abfab@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9741A3A69D0; Tue, 12 Oct 2010 10:03:34 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20101012170334.9741A3A69D0@core3.amsl.com> Date: Tue, 12 Oct 2010 10:03:34 -0700 (PDT) Cc: abfab@ietf.org Subject: [abfab] WG Action: Application Bridging for Federated Access Beyond web (abfab) 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, 12 Oct 2010 17:03:34 -0000 A new IETF working group has been formed in the Security Area. For additional information, please contact the Area Directors or the WG Chairs. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ Current Status: Active Working Group Chairs Leif Johansson Klaas Wierenga Security Area Directors: Sean Turner Tim Polk Security Area Advisor: Sean Turner Mailing Lists: General Discussion: abfab@ietf.org To Subscribe: Archive: Problem Statement Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML). Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML and SAML message formats are used to carry subject information that can be used for authorization and personalization by a relying party. Any change in the choices for these three technical roles is out of scope for this charter. Constraints ----------- Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for Pseudo Random Function (PRF) is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL (RFC 4422) applications, which can use GSS- API mechanisms through GS2 (RFC5081). Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC) and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables ------------ 1. Descriptions of applicable use cases (informational). 2. An architecture that describes how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (informational). 3. A standards-track update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case. 4. A standards-track solution for using EAP methods to provide authentication within the application. 5. A standards-track update to the EMSK root key applicability statement in RFC 5295. 6. A standards-track description of GSS names and name attributes required by the solution. 7. Descriptions of usability and user-interface concerns related to this work (informational). 8. A standards-track protocol for carrying SAML messages in RADIUS and Diameter. Goals and Milestones -------------------- Oct 2010 Submit Internet draft describing applicable use cases as initial WG item. Oct 2010 Submit Internet draft describing the architecture as initial WG item. Oct 2010 Submit Internet draft that updates the EAP applicability statement as initial WG item. Oct 2010 Submit Internet draft for using EAP methods to provide authentication within the application as initial WG item. Oct 2010 Submit Internet draft that updates the EMSK root key applicability statement as initial WG item. Oct 2010 Submit Internet draft that describes GSS names and name attributes as initial WG item. Oct 2010 Submit Internet draft for usability and user-interface concerns as initial WG item. Oct 2010 Submit Internet draft for SAML messages in Radius and Diameter as an initial WG item. Dec 2010 Submit Internet draft describing applicable use cases to the IESG for consideration. Dec 2010 Submit Internet draft describing the architecture to the IESG for consideration. May 2011 Submit Internet draft that updates the EAP applicability statement to the IESG for consideration. May 2011 Submit Internet draft for using EAP methods to provide authentication within the application to the IESG for consideration. Aug 2011 Submit Internet draft that updates the EMSK root key applicability statement to the IESG for consideration. Aug 2011 Submit Internet draft that describes GSS names and name attributes to the IESG for consideration. Aug 2011 Submit Internet draft for usability and user-interface concerns to the IESG for consideration. Dec 2011 Submit Internet draft for SAML messages in Radius and Diameter to the IESG for consideration. From lear@cisco.com Tue Oct 12 10:22:15 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 172D33A69AC for ; Tue, 12 Oct 2010 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.456 X-Spam-Level: X-Spam-Status: No, score=-105.456 tagged_above=-999 required=5 tests=[AWL=-2.857, 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 HRUJH6rYEW2w for ; Tue, 12 Oct 2010 10:22:14 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0332B3A6822 for ; Tue, 12 Oct 2010 10:22:13 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8EAF82tEyQ/khNgWdsb2JhbACDH542FQEBFiIiok2KG5JegSKDMnQEikGLJQ X-IronPort-AV: E=Sophos;i="4.57,321,1283731200"; d="scan'208";a="11176649" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 12 Oct 2010 17:23:28 +0000 Received: from dhcp-10-61-100-220.cisco.com (dhcp-10-61-100-220.cisco.com [10.61.100.220]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o9CHNRlg021782; Tue, 12 Oct 2010 17:23:28 GMT Message-ID: <4CB499B0.30604@cisco.com> Date: Tue, 12 Oct 2010 19:24:00 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "RL 'Bob' Morgan" References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 17:22:15 -0000 Bob, On 10/12/10 6:09 PM, RL 'Bob' Morgan wrote: > At the technical level that is the concern of abfab I think the > pairwise definition is more relevant. Sometimes I use the term > "multi-organizational federation" to specifically indicate the second > sense. Should this be an open question within the working group? Josh has made a convincing argument that, as Mike O'Dell said long ago, the only problem you have to worry about is scale, and the ability to go greater than pairwise would seem a necessary success ingredient. Eliot From lear@cisco.com Tue Oct 12 10:26:05 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 A66363A6990 for ; Tue, 12 Oct 2010 10:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.099 X-Spam-Level: X-Spam-Status: No, score=-105.099 tagged_above=-999 required=5 tests=[AWL=-2.500, 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 GZ1V4wIxy2aC for ; Tue, 12 Oct 2010 10:26:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 8F1913A69AC for ; Tue, 12 Oct 2010 10:26:04 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4EAH83tEyQ/khLgWdsb2JhbACDH542FQEBCwsiIqJqihuSX4EigzJ0BIpB X-IronPort-AV: E=Sophos;i="4.57,320,1283731200"; d="scan'208";a="11177185" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Oct 2010 17:27:18 +0000 Received: from dhcp-10-61-100-220.cisco.com (dhcp-10-61-100-220.cisco.com [10.61.100.220]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o9CHRIRm029270; Tue, 12 Oct 2010 17:27:18 GMT Message-ID: <4CB49A97.3020203@cisco.com> Date: Tue, 12 Oct 2010 19:27:51 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Nicolas Williams References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> In-Reply-To: <20101012163517.GH1635@oracle.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Josh Howlett , "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 17:26:05 -0000 Nico, >> I believe that some apps will need name services. I believe that ABFAB >> should provide these, where possible, by leveraging existing related >> mechanisms (e.g. SAML and/or RADIUS attributes). > Neither SAML nor RADIUS are remotely like name services... > When we say "name services" are we talking about agreements about attribute names and their meanings, and the validity/trustworthiness of the values? SAML can certainly transport All Of That, and so could Radius for that matter, but it's transport, right? Eliot From fenton@cisco.com Tue Oct 12 10:50: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 020583A6A0E for ; Tue, 12 Oct 2010 10:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.885 X-Spam-Level: X-Spam-Status: No, score=-8.885 tagged_above=-999 required=5 tests=[AWL=1.714, 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 jYtWOaRb3CWi for ; Tue, 12 Oct 2010 10:50:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EF3693A6910 for ; Tue, 12 Oct 2010 10:50:54 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMHAKc8tEyrRN+K/2dsb2JhbACTXI19cYgZmhiceYJ0glQEhFKFbw X-IronPort-AV: E=Sophos;i="4.57,321,1283731200"; d="scan'208";a="602869778" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 12 Oct 2010 17:52:09 +0000 Received: from dhcp-171-71-95-32.cisco.com (dhcp-171-71-95-32.cisco.com [171.71.95.32]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o9CHq939006806 for ; Tue, 12 Oct 2010 17:52:09 GMT Message-ID: <4CB4A049.9090801@cisco.com> Date: Tue, 12 Oct 2010 10:52:09 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: abfab@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 17:50:56 -0000 On 10/12/10 9:09 AM, RL 'Bob' Morgan wrote: > >> I liked the Liberty Alliance definition more: "An association >> compromising any number of service providers and identity providers." >> maybe adding the AAA specific aspect that there are additional >> actors, such as brokers. The aspect that these entities belong to >> different administrative domains might also be worth mentioning. > > It has long been a problem that there are two common senses of the > term "federation" in this area. One is the pairwise sense you > mentioned earlier: a service in one administrative domain relies on > identity services from another domain. People say organizations > "federate" when they make this pairwise arrangement. > > The other is the multi-organizational sense you mention above, which > is closer to the regular dictionary definition of federation. There > are lots of operational federations in this sense (see > https://refeds.terena.org/index.php/Federations for a list in the > research&education sector). > > At the technical level that is the concern of abfab I think the > pairwise definition is more relevant. Sometimes I use the term > "multi-organizational federation" to specifically indicate the second > sense. In the case of multi-organizational federation, I think it's also important to distinguish direct federations (where the parties all recognize each other) from indirect federations (where the parties possess a common accreditation, or perhaps belong to a trust framework). There is obviously a severe scaling limitation with direct federations, but that is sufficient for many enterprise use cases. In the indirect case, the parties need to recognize some sort of certificate or verify the relationship with the accreditor or trust framework, and detect and handle revocation of the relationship. This has direct impact on the protocols. > > In any case I would suggest using the term "identity federation" for > what we're talking about here, since "federation" per se has lots of > other uses in IT (eg federated naming). +1. I hope that "federation" does not become as overused as "virtual" or "cloud"! -Jim From Josh.Howlett@ja.net Tue Oct 12 11:21: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 10EC03A69D9 for ; Tue, 12 Oct 2010 11:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.719 X-Spam-Level: X-Spam-Status: No, score=-101.719 tagged_above=-999 required=5 tests=[AWL=0.880, 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 1MqsKMX+5oqQ for ; Tue, 12 Oct 2010 11:21:45 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 1B1203A698A for ; Tue, 12 Oct 2010 11:21:45 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 061394A6B50_CB4A783B; Tue, 12 Oct 2010 18:22:59 +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 DADBF4A6B42_CB4A77FF; Tue, 12 Oct 2010 18:22:55 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Tue, 12 Oct 2010 19:23:08 +0100 From: Josh Howlett To: Nicolas Williams , Hannes Tschofenig Thread-Topic: [abfab] Federation Terminology Thread-Index: AQHLag0BzTPz2rRHjku0Gu79/ogjeZM9Vq2AgAACeICAAAgagIAACZiAgAAR3QA= Date: Tue, 12 Oct 2010 18:23:07 +0000 Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> In-Reply-To: <20101012160928.GF1635@oracle.com> 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 , "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 18:21:46 -0000 > Over in the NFSv4 WG the term "federated namespace" refers to a global > namespace constructed out of DNS SRV RRs, NFSv4 referrals, and > conventions for using LDAP to store information that NFSv4 servers need > to construct namespaces. This surely seems unrelated to ABFAB Yes, they're unrelated at a technical level. At a business level, the act o= f delegating a set of responsibilities to the other party(ies) is similar. > Question: to what extent other ABFAB apps will need name services, and > should ABFAB provide them? I believe that some apps will need name services. I believe that ABFAB shou= ld provide these, where possible, by leveraging existing related mechanisms= (e.g. SAML and/or RADIUS attributes). 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 From cantor.2@osu.edu Tue Oct 12 11:30:16 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 F370C3A6A25 for ; Tue, 12 Oct 2010 11:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=-0.786, 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 lTSaLe9n7rPs for ; Tue, 12 Oct 2010 11:30:15 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id D62AA3A6A2F for ; Tue, 12 Oct 2010 11:30:14 -0700 (PDT) Received: from defang9.it.ohio-state.edu (defang9.it.ohio-state.edu [128.146.216.78]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CIVRr7019223; Tue, 12 Oct 2010 14:31:27 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.160.224]) by defang9.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CIVRoB003110; Tue, 12 Oct 2010 14:31:27 -0400 From: "Scott Cantor" To: "'Jim Fenton'" , References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <4CB4A049.9090801@cisco.com> In-Reply-To: <4CB4A049.9090801@cisco.com> Date: Tue, 12 Oct 2010 14:31:37 -0400 Organization: The Ohio State University Message-ID: <02ec01cb6a3b$b4653f20$1d2fbd60$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL9NE9Rw63FQHGwkiGqEPHFtwd04QN7DDKlAkoHMbgDDo7KFwKnwJSIAapJI0wCDIsn25BgfA8w Content-Language: en-us X-CanIt-Geo: ip=128.146.216.78; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 18:30:16 -0000 > In the indirect case, the parties need to recognize some sort of > certificate or verify the relationship with the accreditor or trust > framework, and detect and handle revocation of the relationship. This > has direct impact on the protocols. It doesn't have to, it's simply there. The verification of that sort of thing can be kept outside of a protocol's "runtime" decision making process so that people can use different trust models with common protocol implementations. Failing to maintain that separation ends up imposing a particular trust model on the credentials used by the parties at runtime, and that usually ends up dictating the credentials themselves, which is where the whole thing blows up. -- Scott From Nicolas.Williams@oracle.com Tue Oct 12 11:47:03 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 D10803A6A1E for ; Tue, 12 Oct 2010 11:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 T8yzFBpcNWhO for ; Tue, 12 Oct 2010 11:47:02 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A2FD13A6A01 for ; Tue, 12 Oct 2010 11:47:02 -0700 (PDT) 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 o9CImEho011986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2010 18:48:15 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9CIhv90000815; Tue, 12 Oct 2010 18:48:13 GMT Received: from abhmt007.oracle.com by acsmt355.oracle.com with ESMTP id 676899811286909249; Tue, 12 Oct 2010 11:47:29 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 11:47:29 -0700 Date: Tue, 12 Oct 2010 13:47:17 -0500 From: Nicolas Williams To: Eliot Lear Message-ID: <20101012184717.GI1635@oracle.com> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CB49A97.3020203@cisco.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: Josh Howlett , "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 18:47:03 -0000 On Tue, Oct 12, 2010 at 07:27:51PM +0200, Eliot Lear wrote: > Nico, > > >> I believe that some apps will need name services. I believe that ABFAB > >> should provide these, where possible, by leveraging existing related > >> mechanisms (e.g. SAML and/or RADIUS attributes). > > Neither SAML nor RADIUS are remotely like name services... > > > > When we say "name services" are we talking about agreements about > attribute names and their meanings, and the validity/trustworthiness of > the values? SAML can certainly transport All Of That, and so could > Radius for that matter, but it's transport, right? Say I want to add to some ACL an entry granting "joe@foo.example" access to some file. The server is likely going to need to resolve that into whatever the primary key[*] might be for joe@foo.example so it can store that on disk. That's a name resolution issue, and there is no place for RADIUS in there. SAML is not a protocol, so SAML can't really fit this either, though a name resolution protocol could very well use SAML. The obvious protocol for name resolution here is LDAP. That's what we'll be using in NFSv4. See: draft-adamson-nfsv4-multi-domain-access-03.txt Nico [*] Or the server could just store joe@foo.example on disk, and hopefully foo.example will never re-use the name "joe" and, preferably, will ensure that joe remains part of joe's authorization context should joe ever get renamed. We can realistically expect administrators never to re-use what I meant by primary keys: SIDs, UIDs, GIDs, employee IDs, etcetera, because that is already a common practice. But expecting them to never re-use names is less realistic, thus an NFSv4 server is likely to prefer storing primary keys over names. In this example the server might prefer to store {joe's ID at foo.example, some ID for foo.example} on disk. From Josh.Howlett@ja.net Tue Oct 12 11:49:52 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 844783A69B6 for ; Tue, 12 Oct 2010 11:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.774 X-Spam-Level: X-Spam-Status: No, score=-101.774 tagged_above=-999 required=5 tests=[AWL=0.825, 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 P0qu6cHXfY+u for ; Tue, 12 Oct 2010 11:49:51 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 8BE0B3A69FF for ; Tue, 12 Oct 2010 11:49:51 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CF7CB4A6B3F_CB4AE19B; Tue, 12 Oct 2010 18:51:05 +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 B97374A6B32_CB4AE16F; Tue, 12 Oct 2010 18:51:02 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Tue, 12 Oct 2010 19:51:15 +0100 From: Josh Howlett To: Nicolas Williams Thread-Topic: [abfab] Federation Terminology Thread-Index: AQHLag0BzTPz2rRHjku0Gu79/ogjeZM9Vq2AgAACeICAAAgagIAACZiAgAAR3QD///VYgIAAMGVg Date: Tue, 12 Oct 2010 18:51:00 +0000 Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> In-Reply-To: <20101012163517.GH1635@oracle.com> 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 , "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 18:49:52 -0000 > Like I said, NFSv4 uses the GSS-API, so the two are not that unrelated. >=20 > ABFAB federations allow participating services to authenticate users > from participating domains and obtain useful authorization-relevant > information about such authenticated users. Is that a fair > characterization? It's one of the best descriptions to date, I think! (I would personally drop the word "federation" because I don't think it add= s anything, and risks introducing unrelated concepts associated with this o= ver-loaded term. But that's just me - if it works for others then that's gr= eat) > In its maximal form, NFSv4 federations don't seem unrelated to ABFAB, > not to me. Definitely in the sense that ABFAB can be a service to NFS. > > I believe that some apps will need name services. I believe that ABFAB > > should provide these, where possible, by leveraging existing related > > mechanisms (e.g. SAML and/or RADIUS attributes). >=20 > Neither SAML nor RADIUS are remotely like name services... Sure, it makes no sense to reinvent name services on these. I meant that th= ese could supply useful data that might inform name services (e.g., identif= iers). 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 From cantor.2@osu.edu Tue Oct 12 11:59:12 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 3B90E3A6A47 for ; Tue, 12 Oct 2010 11:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, 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 H84c1lvsTDx1 for ; Tue, 12 Oct 2010 11:59:11 -0700 (PDT) Received: from defang20.it.ohio-state.edu (defang20.it.ohio-state.edu [128.146.216.134]) by core3.amsl.com (Postfix) with ESMTP id 7E97A3A6A3D for ; Tue, 12 Oct 2010 11:59:10 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang20.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CJ0OPS009247; Tue, 12 Oct 2010 15:00:24 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.160.224]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CJ0N5j029849; Tue, 12 Oct 2010 15:00:24 -0400 From: "Scott Cantor" To: "'Nicolas Williams'" , "'Eliot Lear'" References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> <20101012184717.GI1635@oracle.com> In-Reply-To: <20101012184717.GI1635@oracle.com> Date: Tue, 12 Oct 2010 15:00:33 -0400 Organization: The Ohio State University Message-ID: <02f301cb6a3f$bf55b460$3e011d20$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL9NE9Rw63FQHGwkiGqEPHFtwd04QN7DDKlAkoHMbgDDo7KFwKnwJSIAkdWthACtwmkbQEyINnhAgDm+t4BCN5ZR5A0aVzQ Content-Language: en-us X-CanIt-Geo: ip=128.146.216.79; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.134 Cc: 'Josh Howlett' , abfab@ietf.org, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 18:59:12 -0000 > That's a name resolution issue, and there is no place for RADIUS in > there. SAML is not a protocol, so SAML can't really fit this either, > though a name resolution protocol could very well use SAML. SAML is actually a protocol, and there is a specific protocol in the original "family" of protocol exchanges for NameIDMapping that more or less fits the use case. Just FYI. -- Scott From Nicolas.Williams@oracle.com Tue Oct 12 12:02:19 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 85C5F3A69FF for ; Tue, 12 Oct 2010 12:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.036, 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 JISJdaFsTDOh for ; Tue, 12 Oct 2010 12:02:18 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 549AF3A6A62 for ; Tue, 12 Oct 2010 12:01:57 -0700 (PDT) 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 o9CJ32e1013022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2010 19:03:04 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9CIhv9O000815; Tue, 12 Oct 2010 19:03:02 GMT Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 676941851286910072; Tue, 12 Oct 2010 12:01:12 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 12:01:11 -0700 Date: Tue, 12 Oct 2010 14:01:07 -0500 From: Nicolas Williams To: Josh Howlett Message-ID: <20101012190106.GK1635@oracle.com> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 19:02:19 -0000 On Tue, Oct 12, 2010 at 06:51:00PM +0000, Josh Howlett wrote: > > Like I said, NFSv4 uses the GSS-API, so the two are not that unrelated. > > > > ABFAB federations allow participating services to authenticate users > > from participating domains and obtain useful authorization-relevant > > information about such authenticated users. Is that a fair > > characterization? > > It's one of the best descriptions to date, I think! Er, glad to help then! > (I would personally drop the word "federation" because I don't think > it adds anything, and risks introducing unrelated concepts associated > with this over-loaded term. But that's just me - if it works for > others then that's great) I think right now it's a useful term. Eventually we're going to need to differentiate different kinds of federations enough that we may need to ditch this term and invent a new one, or else qualify it. > > In its maximal form, NFSv4 federations don't seem unrelated to ABFAB, > > not to me. > > Definitely in the sense that ABFAB can be a service to NFS. Right. But see draft-adamson-nfsv4-multi-domain-access, which describes how to do name resolution and, to a lesser extent, ID mapping in a federated namespace. That piece could prove useful to ABFAB. > > > I believe that some apps will need name services. I believe that ABFAB > > > should provide these, where possible, by leveraging existing related > > > mechanisms (e.g. SAML and/or RADIUS attributes). > > > > Neither SAML nor RADIUS are remotely like name services... > > Sure, it makes no sense to reinvent name services on these. I meant > that these could supply useful data that might inform name services > (e.g., identifiers). Agreed. Nico -- From Nicolas.Williams@oracle.com Tue Oct 12 12:02:20 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 024153A6A4F for ; Tue, 12 Oct 2010 12:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.036, 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 n460HRURhGYV for ; Tue, 12 Oct 2010 12:02:19 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DE13D3A6A4E for ; Tue, 12 Oct 2010 12:02:03 -0700 (PDT) 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 o9CJ3GKA014328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2010 19:03:17 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 o9CJ17cc026323; Tue, 12 Oct 2010 19:03:14 GMT Received: from abhmt013.oracle.com by acsmt354.oracle.com with ESMTP id 684804381286910117; Tue, 12 Oct 2010 12:01:57 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 12:01:57 -0700 Date: Tue, 12 Oct 2010 14:01:52 -0500 From: Nicolas Williams To: Scott Cantor Message-ID: <20101012190152.GL1635@oracle.com> References: <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> <20101012184717.GI1635@oracle.com> <02f301cb6a3f$bf55b460$3e011d20$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02f301cb6a3f$bf55b460$3e011d20$@osu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: 'Josh Howlett' , abfab@ietf.org, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 19:02:20 -0000 On Tue, Oct 12, 2010 at 03:00:33PM -0400, Scott Cantor wrote: > > That's a name resolution issue, and there is no place for RADIUS in > > there. SAML is not a protocol, so SAML can't really fit this either, > > though a name resolution protocol could very well use SAML. > > SAML is actually a protocol, and there is a specific protocol in the > original "family" of protocol exchanges for NameIDMapping that more or less > fits the use case. Just FYI. Oh. Could you send me some references? Nico -- From cantor.2@osu.edu Tue Oct 12 12:11: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 F2E653A6A3E for ; Tue, 12 Oct 2010 12:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-0.739, 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 x26+vmdD9uzD for ; Tue, 12 Oct 2010 12:10:54 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by core3.amsl.com (Postfix) with ESMTP id 043533A6A5E for ; Tue, 12 Oct 2010 12:10:38 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CJBrJ5004184; Tue, 12 Oct 2010 15:11:53 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.160.224]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CJBqFd013087; Tue, 12 Oct 2010 15:11:53 -0400 From: "Scott Cantor" To: "'Nicolas Williams'" References: <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> <20101012184717.GI1635@oracle.com> <02f301cb6a3f$bf55b460$3e011d20$@osu.edu> <20101012190152.GL1635@oracle.com> In-Reply-To: <20101012190152.GL1635@oracle.com> Date: Tue, 12 Oct 2010 15:12:02 -0400 Organization: The Ohio State University Message-ID: <02f901cb6a41$5a088f40$0e19adc0$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQN7DDKluvLTn4+O5KecJEjc3Kop/wJKBzG4Aw6OyhcCp8CUiAJHVrYQArcJpG0BMiDZ4QIA5vreAQjeWUcBlfUbzQGijFFKjzrP+/A= Content-Language: en-us X-CanIt-Geo: ip=128.146.216.79; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: abfab@ietf.org Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 19:11:07 -0000 > Oh. Could you send me some references? The abstract protocol layer and the protocols that are actually defined in the original standard are all in the Core spec: http://saml.xml.org/saml-specifications NameID Mapping is sec 3.8. It's just a translation message to turn one name form at an IdP into another. The primary use case was getting encrypted references to a principal at another IdP to do identity cross-walks, but it can translate names at a single IdP. -- Scott From Nicolas.Williams@oracle.com Tue Oct 12 12:42:38 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 45E213A6A63 for ; Tue, 12 Oct 2010 12:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.036, 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 fCA50yMeXoYL for ; Tue, 12 Oct 2010 12:42:37 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 045C13A6A70 for ; Tue, 12 Oct 2010 12:42:01 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9CJhCVp010304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2010 19:43:14 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9CJhBEe006135; Tue, 12 Oct 2010 19:43:11 GMT Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 684936431286912577; Tue, 12 Oct 2010 12:42:57 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 12:42:57 -0700 Date: Tue, 12 Oct 2010 14:42:52 -0500 From: Nicolas Williams To: Scott Cantor Message-ID: <20101012194252.GO1635@oracle.com> References: <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> <20101012184717.GI1635@oracle.com> <02f301cb6a3f$bf55b460$3e011d20$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02f301cb6a3f$bf55b460$3e011d20$@osu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: 'Josh Howlett' , abfab@ietf.org, "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 19:42:38 -0000 On Tue, Oct 12, 2010 at 03:00:33PM -0400, Scott Cantor wrote: > > That's a name resolution issue, and there is no place for RADIUS in > > there. SAML is not a protocol, so SAML can't really fit this either, > > though a name resolution protocol could very well use SAML. > > SAML is actually a protocol, and there is a specific protocol in the > original "family" of protocol exchanges for NameIDMapping that more or less > fits the use case. Just FYI. Incidentally, I tend to think of SAML profiles as protocols, but SAML alone as not. From Nicolas.Williams@oracle.com Tue Oct 12 12:53: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 56E9F3A6A62 for ; Tue, 12 Oct 2010 12:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.563 X-Spam-Level: X-Spam-Status: No, score=-6.563 tagged_above=-999 required=5 tests=[AWL=0.035, 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 AZOZsQV9D165 for ; Tue, 12 Oct 2010 12:53:45 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id DEBC93A6A5B for ; Tue, 12 Oct 2010 12:53:44 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9CJstcd001876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2010 19:54:57 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9CJsrIS009773; Tue, 12 Oct 2010 19:54:54 GMT Received: from abhmt003.oracle.com by acsmt355.oracle.com with ESMTP id 684961181286913198; Tue, 12 Oct 2010 12:53:18 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 12:53:17 -0700 Date: Tue, 12 Oct 2010 14:53:13 -0500 From: Nicolas Williams To: Scott Cantor Message-ID: <20101012195312.GP1635@oracle.com> References: <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> <20101012184717.GI1635@oracle.com> <02f301cb6a3f$bf55b460$3e011d20$@osu.edu> <20101012190152.GL1635@oracle.com> <02f901cb6a41$5a088f40$0e19adc0$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02f901cb6a41$5a088f40$0e19adc0$@osu.edu> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 19:53:46 -0000 On Tue, Oct 12, 2010 at 03:12:02PM -0400, Scott Cantor wrote: > > Oh. Could you send me some references? > > The abstract protocol layer and the protocols that are actually defined in > the original standard are all in the Core spec: > > http://saml.xml.org/saml-specifications > > NameID Mapping is sec 3.8. It's just a translation message to turn one name > form at an IdP into another. The primary use case was getting encrypted > references to a principal at another IdP to do identity cross-walks, but it > can translate names at a single IdP. Thanks. This is quite useful. I'll have to bring this up in discussion of draft-adamson-... and draft-sorce-... One problem is that urn:oasis:names:tc:SAML:2.0:nameid-format:entity has not specified format, so who knows whether what you get back is a SID or something else. There's also urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, whose semantic seems to be that it is a random string, but a persistent one. The other nameid-formats aren't all that useful here. Having nameid-formats specific to "SID", "POSIX UID" and "POSIX GID" would be quite handy. How hard would it be to add such nameid-formats? (My apologies to the list if this starts getting OT.) Nico -- From cantor.2@osu.edu Tue Oct 12 13:04:59 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 BD8603A6A6F for ; Tue, 12 Oct 2010 13:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.307 X-Spam-Level: X-Spam-Status: No, score=-3.307 tagged_above=-999 required=5 tests=[AWL=-0.708, 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 aaQRcPQBZ2PN for ; Tue, 12 Oct 2010 13:04:58 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id B81C83A6A67 for ; Tue, 12 Oct 2010 13:04:58 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CK6D7t005509; Tue, 12 Oct 2010 16:06:13 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.160.224]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CK6CCj011034; Tue, 12 Oct 2010 16:06:12 -0400 From: "Scott Cantor" To: "'Nicolas Williams'" References: <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> <20101012184717.GI1635@oracle.com> <02f301cb6a3f$bf55b460$3e011d20$@osu.edu> <20101012190152.GL1635@oracle.com> <02f901cb6a41$5a088f40$0e19adc0$@osu.edu> <20101012195312.GP1635@oracle.com> In-Reply-To: <20101012195312.GP1635@oracle.com> Date: Tue, 12 Oct 2010 16:06:22 -0400 Organization: The Ohio State University Message-ID: <031101cb6a48$f11ed3b0$d35c7b10$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMOjsoXunZteOWapKigGCC+ZV5P8QKnwJSIAkdWthACtwmkbQEyINnhAgDm+t4BCN5ZRwGV9RvNAaKMUUoCSlvAcwFv85NNkCDMwCA= Content-Language: en-us X-CanIt-Geo: ip=128.146.216.79; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Cc: abfab@ietf.org Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 20:04:59 -0000 > One problem is that urn:oasis:names:tc:SAML:2.0:nameid-format:entity has > not specified format, so who knows whether what you get back is a SID or > something else. No, that format is reserved for SAML entityIDs, typically for identifying SAML services and applications, not users. > There's also urn:oasis:names:tc:SAML:2.0:nameid-format:persistent, whose > semantic seems to be that it is a random string, but a persistent one. That also has a well-defined semantic, and is something akin to what DCE did with the underlying UUID underneath the principals and groups. > Having nameid-formats specific to "SID", "POSIX UID" and "POSIX GID" > would be quite handy. How hard would it be to add such nameid-formats? Formats are just URIs to signal intent, anybody can invent them. > (My apologies to the list if this starts getting OT.) Likewise. -- Scott From Josh.Howlett@ja.net Tue Oct 12 13:08:00 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 0D9933A69EA for ; Tue, 12 Oct 2010 13:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.822 X-Spam-Level: X-Spam-Status: No, score=-101.822 tagged_above=-999 required=5 tests=[AWL=0.777, 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 0SC2iOxoML9H for ; Tue, 12 Oct 2010 13:07:59 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id DB8E63A6A75 for ; Tue, 12 Oct 2010 13:07:58 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CB64F4A6B50_CB4C068B; Tue, 12 Oct 2010 20:09:12 +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 B49B04A6B32_CB4C066F; Tue, 12 Oct 2010 20:09:10 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Tue, 12 Oct 2010 21:09:23 +0100 From: Josh Howlett To: Scott Cantor , 'Jim Fenton' , "abfab@ietf.org" Thread-Topic: [abfab] Federation Terminology Thread-Index: AQHLag0BzTPz2rRHjku0Gu79/ogjeZM9Vq2AgAACeICAAAgagIAACaiAgAAcnYCAAAsGgIAAJFTQ Date: Tue, 12 Oct 2010 20:09:07 +0000 Message-ID: References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <4CB4A049.9090801@cisco.com> <02ec01cb6a3b$b4653f20$1d2fbd60$@osu.edu> In-Reply-To: <02ec01cb6a3b$b4653f20$1d2fbd60$@osu.edu> 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] Federation Terminology 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, 12 Oct 2010 20:08:00 -0000 > > In the indirect case, the parties need to recognize some sort of > > certificate or verify the relationship with the accreditor or trust > > framework, and detect and handle revocation of the relationship. This > > has direct impact on the protocols. >=20 > It doesn't have to, it's simply there. The verification of that sort of > thing can be kept outside of a protocol's "runtime" decision making proce= ss > so that people can use different trust models with common protocol > implementations. >=20 > Failing to maintain that separation ends up imposing a particular trust > model on the credentials used by the parties at runtime, and that usually > ends up dictating the credentials themselves, which is where the whole th= ing > blows up. One of the motivations of the Key Negotiation Protocol (draft-howlett-radse= c-knp), which is a proposed application of AFAB, is to permit the separatio= n of credential technologies; such that two actors can wield entirely unrel= ated types of credential, and yet still arrive at a trust decision at runti= me. This is intended to complement the credential/protocol separation strategy = that Scott describes (and which I think should be axiomatic), by introducin= g a further separation between the credential technologies themselves. 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 From fenton@cisco.com Tue Oct 12 13:44:23 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 F1A1B3A69EE for ; Tue, 12 Oct 2010 13:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.099 X-Spam-Level: X-Spam-Status: No, score=-9.099 tagged_above=-999 required=5 tests=[AWL=1.500, 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 YuVnd73TFKGm for ; Tue, 12 Oct 2010 13:44:22 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 270D63A69B0 for ; Tue, 12 Oct 2010 13:44:22 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAG5ltEyrR7H+/2dsb2JhbAChX3Ghe50EhUgEhFKFb4sl X-IronPort-AV: E=Sophos;i="4.57,321,1283731200"; d="scan'208";a="370326950" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 12 Oct 2010 20:45:37 +0000 Received: from dhcp-171-71-95-32.cisco.com (dhcp-171-71-95-32.cisco.com [171.71.95.32]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9CKjbBO021357; Tue, 12 Oct 2010 20:45:37 GMT Message-ID: <4CB4C8F1.20502@cisco.com> Date: Tue, 12 Oct 2010 13:45:37 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Scott Cantor References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <4CB4A049.9090801@cisco.com> <02ec01cb6a3b$b4653f20$1d2fbd60$@osu.edu> In-Reply-To: <02ec01cb6a3b$b4653f20$1d2fbd60$@osu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 20:44:23 -0000 On 10/12/10 11:31 AM, Scott Cantor wrote: >> In the indirect case, the parties need to recognize some sort of >> certificate or verify the relationship with the accreditor or trust >> framework, and detect and handle revocation of the relationship. This >> has direct impact on the protocols. > It doesn't have to, it's simply there. The verification of that sort of > thing can be kept outside of a protocol's "runtime" decision making process > so that people can use different trust models with common protocol > implementations. > > Failing to maintain that separation ends up imposing a particular trust > model on the credentials used by the parties at runtime, and that usually > ends up dictating the credentials themselves, which is where the whole thing > blows up. I'm assuming the separation between the subject-IDP interaction and the IDP-SP interaction that Sam wrote about a little earlier in this thread. When you have that separation, you avoid dictating the credentials themselves. But you still have the relationships between different SPs that needs to be federated, and there needs to be some basis for deciding who's a member of "the club", and whether anyone has been kicked out. -Jim From cantor.2@osu.edu Tue Oct 12 13:47:51 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 1BAF73A69EE for ; Tue, 12 Oct 2010 13:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=-0.680, 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 eUFcPHJBRKGM for ; Tue, 12 Oct 2010 13:47:50 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by core3.amsl.com (Postfix) with ESMTP id D27063A6A7D for ; Tue, 12 Oct 2010 13:47:48 -0700 (PDT) Received: from defang10.it.ohio-state.edu (defang10.it.ohio-state.edu [128.146.216.79]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CKmq1I001104; Tue, 12 Oct 2010 16:48:52 -0400 Received: from SNOWDOG (SNOWDOG.dyn.cio.osu.edu [164.107.160.224]) by defang10.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id o9CKmpR0020583; Tue, 12 Oct 2010 16:48:51 -0400 From: "Scott Cantor" To: "'Jim Fenton'" References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <4CB4A049.9090801@cisco.com> <02ec01cb6a3b$b4653f20$1d2fbd60$@osu.edu> <4CB4C8F1.20502@cisco.com> In-Reply-To: <4CB4C8F1.20502@cisco.com> Date: Tue, 12 Oct 2010 16:49:01 -0400 Organization: The Ohio State University Message-ID: <032e01cb6a4e$e663bac0$b32b3040$@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL9NE9Rw63FQHGwkiGqEPHFtwd04QN7DDKlAkoHMbgDDo7KFwKnwJSIAapJI0wCDIsn2wIY1O2IASoxnDaQRop0QA== Content-Language: en-us X-CanIt-Geo: ip=128.146.216.79; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Cc: abfab@ietf.org Subject: Re: [abfab] Federation Terminology 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, 12 Oct 2010 20:47:51 -0000 > I'm assuming the separation between the subject-IDP interaction and the > IDP-SP interaction that Sam wrote about a little earlier in this > thread. When you have that separation, you avoid dictating the > credentials themselves. I was talking about the system credentials, not the user credentials. > But you still have the relationships between > different SPs that needs to be federated, and there needs to be some > basis for deciding who's a member of "the club", and whether anyone has > been kicked out. Yes, but if you bind that into the federated protocol itself instead of decoupling it through something like SAML metadata, you have the problem that in order to interfederate and scale, you need to immediately federate the trust mechanism itself. Keeping things layered means you can scale more effectively without running into the problem of needing to juggle ten different server credentials to deal with ten different federations. -- Scott From lukeh@padl.com Tue Oct 12 17:18:22 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 1C45D3A6AB1 for ; Tue, 12 Oct 2010 17:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.782 X-Spam-Level: X-Spam-Status: No, score=-3.782 tagged_above=-999 required=5 tests=[AWL=-1.783, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] 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 wvHDkjB7cSSa for ; Tue, 12 Oct 2010 17:18:15 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 1821E3A6AF5 for ; Tue, 12 Oct 2010 17:18:13 -0700 (PDT) Received: by us.padl.com with ESMTP id o9D0JERm024027; Tue, 12 Oct 2010 20:19:19 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20101012184717.GI1635@oracle.com> Date: Wed, 13 Oct 2010 11:19:18 +1100 Content-Transfer-Encoding: 7bit Message-Id: <40FD4856-825F-47CC-A977-FF1D98B3B94D@padl.com> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> <20101012184717.GI1635@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: Josh Howlett , "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 13 Oct 2010 00:18:22 -0000 > That's a name resolution issue, and there is no place for RADIUS in > there. SAML is not a protocol, so SAML can't really fit this either, > though a name resolution protocol could very well use SAML. Right, see Scott's message. > [*] Or the server could just store joe@foo.example on disk, and > hopefully foo.example will never re-use the name "joe" and, > preferably, will ensure that joe remains part of joe's authorization > context should joe ever get renamed. This is a good point which I had conveniently forgotten. -- Luke From Nicolas.Williams@oracle.com Tue Oct 12 17:37:37 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 ACFC13A6832 for ; Tue, 12 Oct 2010 17:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, 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 0nsdHwhzIPNq for ; Tue, 12 Oct 2010 17:37:36 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9661A3A686E for ; Tue, 12 Oct 2010 17:37:35 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9D0cnD5006579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Oct 2010 00:38:50 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9D0clfZ018239; Wed, 13 Oct 2010 00:38:48 GMT Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 685622741286930314; Tue, 12 Oct 2010 17:38:34 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Oct 2010 17:38:34 -0700 Date: Tue, 12 Oct 2010 19:38:29 -0500 From: Nicolas Williams To: Luke Howard Message-ID: <20101013003829.GB1635@oracle.com> References: <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <20101012163517.GH1635@oracle.com> <4CB49A97.3020203@cisco.com> <20101012184717.GI1635@oracle.com> <40FD4856-825F-47CC-A977-FF1D98B3B94D@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <40FD4856-825F-47CC-A977-FF1D98B3B94D@padl.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: Josh Howlett , "abfab@ietf.org" , "Tschofenig, Hannes \(NSN - FI/Espoo\)" Subject: Re: [abfab] Federation Terminology 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, 13 Oct 2010 00:37:37 -0000 On Wed, Oct 13, 2010 at 11:19:18AM +1100, Luke Howard wrote: > > That's a name resolution issue, and there is no place for RADIUS in > > there. SAML is not a protocol, so SAML can't really fit this either, > > though a name resolution protocol could very well use SAML. > > Right, see Scott's message. Done :) > > [*] Or the server could just store joe@foo.example on disk, and > > hopefully foo.example will never re-use the name "joe" and, > > preferably, will ensure that joe remains part of joe's authorization > > context should joe ever get renamed. > > This is a good point which I had conveniently forgotten. There's several problems with this: a) you can't validate (catch typos, canonicalize, ...), b) you can't re-use names (which not a lot of administrative domains are prepared to do), c) it's harder to deal with this in filesystems (e.g., ZFS interns domain SIDs, now it'd have to intern names, but at least it has a 64-bit namespace for that, whereas other filesystems have much smaller namespaces). (b) is the worst problem in the short-term, while (a) is the worst problem in the long-term. Those are not fatal problems. I'd rather not have to deal with those problems, but in a pinch I'd live with them. Nico -- From leifj@sunet.se Wed Oct 13 09:55:53 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 247983A68E5 for ; Wed, 13 Oct 2010 09:55:53 -0700 (PDT) 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 D5q2q1DzsKNo for ; Wed, 13 Oct 2010 09:55:52 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 9B70C3A6834 for ; Wed, 13 Oct 2010 09:55:51 -0700 (PDT) Received: from [78.65.233.129] (host-78-65-233-129.homerun.telia.com [78.65.233.129]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9DGv5LH007655 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 13 Oct 2010 18:57:07 +0200 (CEST) Message-ID: <4CB5E4E1.4020803@sunet.se> Date: Wed, 13 Oct 2010 18:57:05 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] agenda creation next 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, 13 Oct 2010 16:55:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Klaas and me will start agenda creation in a day or two. Please start to think about what you think should happen in Beijing. Those who have documents proposed as starting-points for the WG should think about revving them to make sure they are not expired so we can bring them in as working group docs easily. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEARECAAYFAky15OEACgkQ8Jx8FtbMZneHngCdEBFNioRm/AQ9edrrmdf0qNWV 8eMAliDINUmykNhI0H3FBBgwKLWPlx0= =bjFj -----END PGP SIGNATURE----- From leifj@sunet.se Wed Oct 13 14:20:24 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 A056B3A69EF for ; Wed, 13 Oct 2010 14:20:24 -0700 (PDT) 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 M+32wgDqAEsJ for ; Wed, 13 Oct 2010 14:20:23 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 75BAF3A69DF for ; Wed, 13 Oct 2010 14:20:21 -0700 (PDT) Received: from [78.65.233.129] (host-78-65-233-129.homerun.telia.com [78.65.233.129]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9DLLZPR002677 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 13 Oct 2010 23:21:37 +0200 (CEST) Message-ID: <4CB622DF.9030505@sunet.se> Date: Wed, 13 Oct 2010 23:21:35 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: abfab@ietf.org References: <4CB5E4E1.4020803@sunet.se> In-Reply-To: <4CB5E4E1.4020803@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] agenda creation next 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, 13 Oct 2010 21:20:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/13/2010 06:57 PM, Leif Johansson wrote: > > Klaas and me will start agenda creation in a day or two. Please start to > think about what you think should happen in Beijing. > > Those who have documents proposed as starting-points for the WG should > think about revving them to make sure they are not expired so we can > bring them in as working group docs easily. > I'd also like for us to make progress on the following charter items: 1. Descriptions of applicable use cases (informational). 2. An architecture that describes how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (informational). Lets get those squared away quickly! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky2It8ACgkQ8Jx8FtbMZnfSfwCeJRkEBctm3IksSX1HDep6XQJq HSgAoJ3z5nyzUUJbqDuPvL4PJdQMeUwF =8e7y -----END PGP SIGNATURE----- From root@core3.amsl.com Wed Oct 13 16:45:05 2010 Return-Path: X-Original-To: abfab@ietf.org Delivered-To: abfab@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4E3873A6A73; Wed, 13 Oct 2010 16:45:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101013234505.4E3873A6A73@core3.amsl.com> Date: Wed, 13 Oct 2010 16:45:05 -0700 (PDT) Cc: abfab@ietf.org Subject: [abfab] I-D ACTION:draft-ietf-abfab-gss-eap-00.txt 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, 13 Oct 2010 23:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : A GSS-API Mechanism for the Extensible Authentication Protocol Author(s) : S. Hartman, J. Howlett Filename : draft-ietf-abfab-gss-eap-00.txt Pages : 19 Date : 2010-10-13 This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-abfab-gss-eap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-13163712.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Oct 13 16:45:07 2010 Return-Path: X-Original-To: abfab@ietf.org Delivered-To: abfab@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 191823A6A76; Wed, 13 Oct 2010 16:45:05 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101013234506.191823A6A76@core3.amsl.com> Date: Wed, 13 Oct 2010 16:45:05 -0700 (PDT) Cc: abfab@ietf.org Subject: [abfab] I-D ACTION:draft-ietf-abfab-gss-eap-naming-00.txt 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, 13 Oct 2010 23:45:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : Name Attributes for the GSS-API EAP mechanism Author(s) : S. Hartman, J. Howlett Filename : draft-ietf-abfab-gss-eap-naming-00.txt Pages : 12 Date : 2010-10-13 The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-naming-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-abfab-gss-eap-naming-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-13164159.I-D@ietf.org> --NextPart-- From hartmans@painless-security.com Wed Oct 13 18:41:23 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 CABE03A6A13 for ; Wed, 13 Oct 2010 18:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 nazteNmliqmZ for ; Wed, 13 Oct 2010 18:41:20 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 82E063A6932 for ; Wed, 13 Oct 2010 18:41:18 -0700 (PDT) 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 9D6C5202FB for ; Wed, 13 Oct 2010 21:42:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E76CC47C5; Wed, 13 Oct 2010 21:42:16 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 13 Oct 2010 21:42:16 -0400 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 Subject: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 01:41:23 -0000 As people have seen I've submitted (with chair approval) two of the drafts called out in the charter. These drafts are unchanged except for the name changes from the 00 versions explicitly listed as starting points in the charter. Obviously, there are changes we wish to make. However, we need to have the necessary WG discussions for those changes. --Sam From leifj@mnt.se Thu Oct 14 02:10:42 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 DCA7E3A68AF for ; Thu, 14 Oct 2010 02:10:41 -0700 (PDT) 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 mVGoY5vT714N for ; Thu, 14 Oct 2010 02:10:36 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 44AA13A68E2 for ; Thu, 14 Oct 2010 02:10:35 -0700 (PDT) Received: from [130.243.28.56] (u46.kks.kau.se [130.243.28.56]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9E9Bf2R010080 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 14 Oct 2010 11:11:44 +0200 (CEST) Message-ID: <4CB6C94D.1030206@mnt.se> Date: Thu, 14 Oct 2010 11:11:41 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 09:10:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/14/2010 03:42 AM, Sam Hartman wrote: > > > As people have seen I've submitted (with chair approval) two of the > drafts called out in the charter. > > These drafts are unchanged except for the name changes from the 00 > versions explicitly listed as starting points in the charter. > > Obviously, there are changes we wish to make. However, we need to have > the necessary WG discussions for those changes. Thanks for getting the ball rolling Sam! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky2yU0ACgkQ8Jx8FtbMZneTnACdHZF3YvRjmnqRFlBBRu1Jy8XW pBQAn14UOQfwxDQ6J2jDU0vZ3H4XCF1+ =g7uR -----END PGP SIGNATURE----- From gabilm@um.es Thu Oct 14 03:23:24 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 B8BB73A6B15 for ; Thu, 14 Oct 2010 03:23:24 -0700 (PDT) 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 Ibe-T8IH0exu for ; Thu, 14 Oct 2010 03:23:22 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by core3.amsl.com (Postfix) with ESMTP id BF8143A6AC6 for ; Thu, 14 Oct 2010 03:23:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 0178B5D486; Thu, 14 Oct 2010 12:23:15 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DL2r4BCsTgbX; Thu, 14 Oct 2010 12:23:14 +0200 (CEST) Received: from inf-205-73.inf.um.es (inf-205-73.inf.um.es [155.54.205.73]) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPA id 460665D47C; Thu, 14 Oct 2010 12:23:08 +0200 (CEST) Message-ID: <4CB6DA5F.4000108@um.es> Date: Thu, 14 Oct 2010 12:24:31 +0200 From: Gabriel Lopez User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 10:23:25 -0000 Without enter in details, two comments on the gss-eap-00 doc: - SAML is mentioned in the introduction, but it is not clearly described what is purpose of using it in the proposed scenario. Indeed, I would suggest to remove SAML from this draft and to focus on the EAP-GSS integration. A more detailed document describing how SAML could fit here, or even in the eap-naming-00 document would be better. If it is a key point in this document, then, it should appear in the document title, something like draft-....-gss-eap-saml-00.txt - SASL is mentioned in 1.1 and 5.1, but it is not clear the role of SASL in the scenario. Is it required? why do you need a SASL registry? Sorry, maybe a should read more about SASL, it is just my feeling reading the doc :) Best regards, Gabi. El 14/10/10 03:42, Sam Hartman escribió: > > As people have seen I've submitted (with chair approval) two of the > drafts called out in the charter. > > These drafts are unchanged except for the name changes from the 00 > versions explicitly listed as starting points in the charter. > > Obviously, there are changes we wish to make. However, we need to have > the necessary WG discussions for those changes. > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel López Millán Departamento de IngenierÌa de la InformaciÛn y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From lukeh@padl.com Thu Oct 14 03:32:45 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 16EC33A68F8 for ; Thu, 14 Oct 2010 03:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.038 X-Spam-Level: X-Spam-Status: No, score=-4.038 tagged_above=-999 required=5 tests=[AWL=-1.439, 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 RQSmdxxFhVsK for ; Thu, 14 Oct 2010 03:32:43 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id BA6E93A6AC7 for ; Thu, 14 Oct 2010 03:32:41 -0700 (PDT) Received: by us.padl.com with ESMTP id o9EAXlfO011395; Thu, 14 Oct 2010 06:33:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Luke Howard In-Reply-To: <4CB6C94D.1030206@mnt.se> Date: Thu, 14 Oct 2010 21:33:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> References: <4CB6C94D.1030206@mnt.se> To: "abfab@ietf.org abfab" X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 10:32:45 -0000 > Thanks for getting the ball rolling Sam! I can also informally document the assumptions I made in building an = implementation, regarding the bits that aren't yet specified. Off the top of my head: * enctype to mechanism OID mapping * RFC 4121 key derivation from MSK * SASL GS2 mechanism names (EAP-AES{128,256}) * format of channel binding token * format of extension tokens (TLV, used to contain CBT) * RADIUS attributes for acceptor names * GSS name attribute format for RADIUS value-pairs * format of exported names (identical to Kerberos so far) * format of exported composite names (this is allowed to be = implementation dependent but may be nice to standardise) * context error token format/codes (added for better error reporting) I'm sure there's more. I should have kept a list. -- Luke= From lukeh@padl.com Thu Oct 14 03:34:48 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 9EBE33A67FA for ; Thu, 14 Oct 2010 03:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.003 X-Spam-Level: X-Spam-Status: No, score=-4.003 tagged_above=-999 required=5 tests=[AWL=-1.404, 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 IjP-QMHaX8FW for ; Thu, 14 Oct 2010 03:34:44 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 3321E3A68FA for ; Thu, 14 Oct 2010 03:34:44 -0700 (PDT) Received: by us.padl.com with ESMTP id o9EAZoxv017823; Thu, 14 Oct 2010 06:35:55 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <4CB6DA5F.4000108@um.es> Date: Thu, 14 Oct 2010 21:35:54 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <67A24F73-6091-40A3-959D-452E116FDCCA@padl.com> References: <4CB6DA5F.4000108@um.es> To: Gabriel Lopez X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 10:34:48 -0000 > - SASL is mentioned in 1.1 and 5.1, but it is not clear the role of = SASL in the scenario. Is it required? why do you need a SASL registry? = Sorry, maybe a should read more about SASL, it is just my feeling = reading the doc :) Should be sufficient just to reference RFC 5801 and indicate the SASL = mechanism names. But this could also be in a separate (very brief) = document. -- Luke= From hartmans@painless-security.com Thu Oct 14 05:30:35 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 EE5FB3A68F8 for ; Thu, 14 Oct 2010 05:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 rJKGL3Bs+4Zy for ; Thu, 14 Oct 2010 05:30:34 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 386ED3A69DC for ; Thu, 14 Oct 2010 05:30:34 -0700 (PDT) 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 7A98D200B4; Thu, 14 Oct 2010 08:31:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CCDB347C5; Thu, 14 Oct 2010 08:31:30 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> Date: Thu, 14 Oct 2010 08:31:30 -0400 In-Reply-To: <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> (Luke Howard's message of "Thu, 14 Oct 2010 21:33:51 +1100") 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 abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 12:30:35 -0000 Luke, Your list aligns fairly well with a list I sent to the chairs yesterday:-) You had a couple of extra items. I may have to go through all the mail I've received from you--that could be fun:-) --Sam From lukeh@padl.com Thu Oct 14 15:42: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 73A2D3A6BF1 for ; Thu, 14 Oct 2010 15:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=-2.820, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, MANGLED_NAIL=2.3] 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 RWn07beas-me for ; Thu, 14 Oct 2010 15:42:29 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id E3E603A66B4 for ; Thu, 14 Oct 2010 15:42:28 -0700 (PDT) Received: by us.padl.com with ESMTP id o9EMhZ8f022311; Thu, 14 Oct 2010 18:43:41 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 15 Oct 2010 09:43:39 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 22:42:30 -0000 Sam, OK, allow me to summarise in a terse form that can be translated by you = more loquacious draft writers. :-) > * enctype to mechanism OID mapping Consists of a OID prefix, currently 1.3.6.1.4.1.5322.22.1, concatenated = with the RFC 3961 encryption type. > * RFC 4121 key derivation from MSK K =3D truncate(L, T1 || T2 || .. || Tn) L =3D output RFC 4121 key size Tn =3D pseudo-random(KMSK, n || "rfc4121-gss-eap") KMSK =3D random-to-key(MSK) > * SASL GS2 mechanism names (EAP-AES{128,256}) EAP-AES128 EAP-AES256 > * format of channel binding token Currently a RFC 4121 wrap token where the input is the application-data = field. Using Unwrap and compare (as opposed to VerifyMIC) allows the = acceptor to ignore the channel bindings information without disturbing = the sequence state. However I'm not opposed to changing this to a MIC = token. The channel binding token is encapsulated in an initiator extension = token. > * format of extension tokens (TLV, used to contain CBT) The last round-trip consists of an exchange of extension tokens, whose = innerContextToken is defined below (EXT_REQ from initiator, EXT_RESP = from acceptor): TOK_ID || E1 || E2 || .. || En TOK_ID =3D EXT_REQ | EXT_RESP EXT_REQ =3D 06 03 EXT_RESP =3D 06 04 En =3D T || L || V T =3D extension type as 32-bit integer in network byte order L =3D extension length as 32-bit integer in network byte order V =3D extension value as octet string Critical extensions have the high bit set. One critical extension type = is defined for channel bindings and has the value zero (not including = the critical bit). > * RADIUS attributes for acceptor names VENDOR UKERNA 25622 BEGIN-VENDOR UKERNA ATTRIBUTE GSS-Acceptor-Service-Name 128 string ATTRIBUTE GSS-Acceptor-Host-Name 129 string ATTRIBUTE GSS-Acceptor-Service-Specific 130 string=20 ATTRIBUTE GSS-Acceptor-Realm-Name 131 string=20 ATTRIBUTE SAML-AAA-Assertion 132 string=20 END-VENDOR UKERNA They should be mostly self explanatory; GSS-Acceptor-Service-Specific is = a slash-separate set of service-specific components. A Kerberos-like = principal name string is assembled as: GSS-Acceptor-Service-Name || "/" GSS-Acceptor-Host-Name [ || "/" = GSS-Acceptor-Service-Specific ] "@" GSS-Acceptor-Realm-Name > * GSS name attribute format for RADIUS value-pairs "urn:ietf:params:gss-eap:radius-avp urn:x-radius:" || attrID where attrID is the string representation of the RADIUS attribute ID. > * format of exported names (identical to Kerberos so far) Identical to Kerberos, as noted. The MECH_OID excludes the last = (encryption type) OID element as names are not specific to encryption = types. > * format of exported composite names (this is allowed to be = implementation dependent but may be nice to standardise) CN =3D TOK_ID || MECH_OID_LEN || MECH_OID || N || A1 || A2 || .. || An TOK_ID =3D 04 02 MECH_OID =3D OID without encryption type N=3D principal name string An =3D T || L || V T =3D attribute type as 32-bit integer in network byte order L =3D attribute length as 32-bit integer in network byte order V =3D attribute value as octet string ie. this is the non-composite exported name with RADIUS attributes = concatenated to the end > * context error token format/codes (added for better error reporting) =20 Error tokens allow the acceptor to indicate a context error to the = initiator. They are not protected because they are omitted before = context establishment, and are informational only; the initiator may = choose to ignore them. TOK_ID || MAJOR || MECH [ || DESC ] TOK_ID =3D 06 06 MAJOR =3D GSS major status code in network byte order MECH =3D GSS EAP mechanism code DESC =3D optional octet string containing more information Mechanism codes to be defined -- Luke= From Nicolas.Williams@oracle.com Thu Oct 14 15:59:23 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 0AA813A6AF5 for ; Thu, 14 Oct 2010 15:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.111 X-Spam-Level: X-Spam-Status: No, score=-5.111 tagged_above=-999 required=5 tests=[AWL=-1.413, BAYES_00=-2.599, J_CHICKENPOX_81=0.6, MANGLED_NAIL=2.3, 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 WX5IZldyea8p for ; Thu, 14 Oct 2010 15:59:20 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D6C793A6C57 for ; Thu, 14 Oct 2010 15:59:18 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9EN0bcn006722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Oct 2010 23:00:38 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9EKPQrn010256; Thu, 14 Oct 2010 23:00:36 GMT Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 685582931287097217; Thu, 14 Oct 2010 16:00:17 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Oct 2010 16:00:16 -0700 Date: Thu, 14 Oct 2010 18:00:12 -0500 From: Nicolas Williams To: Luke Howard Message-ID: <20101014230012.GN1635@oracle.com> References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 22:59:23 -0000 On Fri, Oct 15, 2010 at 09:43:39AM +1100, Luke Howard wrote: > > * enctype to mechanism OID mapping > > Consists of a OID prefix, currently 1.3.6.1.4.1.5322.22.1, > concatenated with the RFC 3961 encryption type. +1. > > * RFC 4121 key derivation from MSK > > K = truncate(L, T1 || T2 || .. || Tn) > L = output RFC 4121 key size > Tn = pseudo-random(KMSK, n || "rfc4121-gss-eap") > KMSK = random-to-key(MSK) The rage in KDFs seems to be to apply an entropy extraction step first; see RFC5869. Now, I don't think that really matters here, but, it's worth considering this now. (It's too late for the rest of Kerberos, including the krb5 GSS PRF.) > > * SASL GS2 mechanism names (EAP-AES{128,256}) > > EAP-AES128 > EAP-AES256 +1. > > * format of channel binding token > > Currently a RFC 4121 wrap token where the input is the > application-data field. Using Unwrap and compare (as opposed to > VerifyMIC) allows the acceptor to ignore the channel bindings > information without disturbing the sequence state. However I'm not > opposed to changing this to a MIC token. > > The channel binding token is encapsulated in an initiator extension > token. +1. Will this mechanism have initiator and acceptor sub-keys, like RFC4121? > > * format of extension tokens (TLV, used to contain CBT) > > The last round-trip consists of an exchange of extension tokens, whose > innerContextToken is defined below (EXT_REQ from initiator, EXT_RESP > from acceptor): > > TOK_ID || E1 || E2 || .. || En > TOK_ID = EXT_REQ | EXT_RESP > EXT_REQ = 06 03 > EXT_RESP = 06 04 > En = T || L || V > T = extension type as 32-bit integer in network byte order > L = extension length as 32-bit integer in network byte order > V = extension value as octet string > > Critical extensions have the high bit set. One critical extension type > is defined for channel bindings and has the value zero (not including > the critical bit). Any way to optimize round-trips away? > > * format of exported names (identical to Kerberos so far) > > Identical to Kerberos, as noted. The MECH_OID excludes the last > (encryption type) OID element as names are not specific to encryption > types. +1. If the exported name token format is identical to RFC1964's but the names are not Kerberos names per-se, then this is fine. > > * format of exported composite names (this is allowed to be > > implementation dependent but may be nice to standardise) Yes. > CN = TOK_ID || MECH_OID_LEN || MECH_OID || N || A1 || A2 || .. || An > TOK_ID = 04 02 > MECH_OID = OID without encryption type > N= principal name string > An = T || L || V > T = attribute type as 32-bit integer in network byte order > L = attribute length as 32-bit integer in network byte order > V = attribute value as octet string > > ie. this is the non-composite exported name with RADIUS attributes > concatenated to the end Is T here from a Radius namespace? If so, you could add a meta-type field for non-Radius attributes, no? > > * context error token format/codes (added for better error reporting) > > Error tokens allow the acceptor to indicate a context error to the > initiator. They are not protected because they are omitted before > context establishment, and are informational only; the initiator may > choose to ignore them. > > TOK_ID || MAJOR || MECH [ || DESC ] > TOK_ID = 06 06 > MAJOR = GSS major status code in network byte order > MECH = GSS EAP mechanism code > DESC = optional octet string containing more information > > Mechanism codes to be defined It'd be nice to be able to protect protectable errors, e.g., errors resulting from policy decisions as opposed to errors resulting from inability to complete key exchange. Nico -- From Nicolas.Williams@oracle.com Thu Oct 14 16:19:57 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 579A23A69D7 for ; Thu, 14 Oct 2010 16:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 LSxZtLOVvRfo for ; Thu, 14 Oct 2010 16:19:56 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 400D53A69E3 for ; Thu, 14 Oct 2010 16:19:56 -0700 (PDT) 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 o9ENLE8o001566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Oct 2010 23:21:15 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9EIhoRv006629; Thu, 14 Oct 2010 23:21:13 GMT Received: from abhmt019.oracle.com by acsmt355.oracle.com with ESMTP id 685639681287098402; Thu, 14 Oct 2010 16:20:02 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Oct 2010 16:20:02 -0700 Date: Thu, 14 Oct 2010 18:19:58 -0500 From: Nicolas Williams To: Luke Howard Message-ID: <20101014231957.GP1635@oracle.com> References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 23:19:57 -0000 On Fri, Oct 15, 2010 at 09:43:39AM +1100, Luke Howard wrote: > > * RADIUS attributes for acceptor names > > VENDOR UKERNA 25622 > > BEGIN-VENDOR UKERNA > > ATTRIBUTE GSS-Acceptor-Service-Name 128 string > ATTRIBUTE GSS-Acceptor-Host-Name 129 string > ATTRIBUTE GSS-Acceptor-Service-Specific 130 string > ATTRIBUTE GSS-Acceptor-Realm-Name 131 string > ATTRIBUTE SAML-AAA-Assertion 132 string > > END-VENDOR UKERNA > > They should be mostly self explanatory; GSS-Acceptor-Service-Specific > is a slash-separate set of service-specific components. A > Kerberos-like principal name string is assembled as: What are "service-specific components"? > GSS-Acceptor-Service-Name || "/" GSS-Acceptor-Host-Name [ || "/" GSS-Acceptor-Service-Specific ] "@" GSS-Acceptor-Realm-Name Presumably the GSS-Acceptor-Host-Name will be an FQDN in general? Also, how is the GSS-Acceptor-Realm-Name determined when a name is imported using GSS_C_NT_HOSTBASED_SERVICE is canonicalized (or passed to gss_init_sec_context() as a targ_name)? > > * GSS name attribute format for RADIUS value-pairs > > "urn:ietf:params:gss-eap:radius-avp urn:x-radius:" || attrID > > where attrID is the string representation of the RADIUS attribute ID. Seems fine to me. Nico -- From hartmans@painless-security.com Thu Oct 14 16:21:11 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 C813F3A6973 for ; Thu, 14 Oct 2010 16:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 3KaUQi3Y6qeF for ; Thu, 14 Oct 2010 16:21:11 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 172803A69AE for ; Thu, 14 Oct 2010 16:21:10 -0700 (PDT) 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 4DEEF202FB; Thu, 14 Oct 2010 19:22:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A5EA47C5; Thu, 14 Oct 2010 19:22:07 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014230012.GN1635@oracle.com> Date: Thu, 14 Oct 2010 19:22:07 -0400 In-Reply-To: <20101014230012.GN1635@oracle.com> (Nicolas Williams's message of "Thu, 14 Oct 2010 18:00:12 -0500") 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 abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 23:21:11 -0000 RFC 5869 says that the extract phase is unneeded if you start with a strong pseudo-random key. That is consistent with my knowledge. I *thought* the EAP MSK was supposed to be such a key, but I think we should ask the EAP community about this. If it is, I think Luke's construction is fine. Otherwise we should look at what we can do. I'm kind of loathed to depend on a hash function though. --Sam From hartmans@painless-security.com Thu Oct 14 16:27:13 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 9B1733A69C1 for ; Thu, 14 Oct 2010 16:27:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 QZ3yGRd-GATh for ; Thu, 14 Oct 2010 16:27:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C2FFA3A6973 for ; Thu, 14 Oct 2010 16:27:12 -0700 (PDT) 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 98698203C0; Thu, 14 Oct 2010 19:28:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 719CD47C5; Thu, 14 Oct 2010 19:28:12 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014231957.GP1635@oracle.com> Date: Thu, 14 Oct 2010 19:28:12 -0400 In-Reply-To: <20101014231957.GP1635@oracle.com> (Nicolas Williams's message of "Thu, 14 Oct 2010 18:19:58 -0500") 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 abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 23:27:13 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> What are "service-specific components"? Name components specific to a particular service type For example the MTP service has the hash of a metadata document as part of the service specific portion along with a URI to that document. If service-specific components are present and the IDP-side AAA proxy does not understand them, it rejects the authentication. Nicolas> Also, how is the GSS-Acceptor-Realm-Name determined when a Nicolas> name is imported using GSS_C_NT_HOSTBASED_SERVICE is Nicolas> canonicalized (or passed to gss_init_sec_context() as a Remember these are AA attributes. They appear in two places: 1) channel bindings from the initiator to the EAP server. There, the realm name is absent if not specified. 2) In AAA attributes from the acceptor to the EAP server via a bunch of proxies. There, we assume the acceptor knows its own realm name. Proxies along the way are responsible for validating the claim the acceptor is implicitly making--namely that the given hostname is part of the claimed realm. --Sam From Nicolas.Williams@oracle.com Thu Oct 14 16:28:16 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 233933A69C1 for ; Thu, 14 Oct 2010 16:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 a6PHfj0Zr1J5 for ; Thu, 14 Oct 2010 16:28:15 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 39E3F3A6973 for ; Thu, 14 Oct 2010 16:28:15 -0700 (PDT) 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 o9ENTXsx014807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Oct 2010 23:29:34 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 o9EMLTsM012089; Thu, 14 Oct 2010 23:29:32 GMT Received: from abhmt009.oracle.com by acsmt355.oracle.com with ESMTP id 685678701287098943; Thu, 14 Oct 2010 16:29:03 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Oct 2010 16:29:03 -0700 Date: Thu, 14 Oct 2010 18:28:58 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20101014232858.GQ1635@oracle.com> References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014230012.GN1635@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 23:28:16 -0000 On Thu, Oct 14, 2010 at 07:22:07PM -0400, Sam Hartman wrote: > RFC 5869 says that the extract phase is unneeded if you start with a > strong pseudo-random key. > That is consistent with my knowledge. Please ignore that. 'Twas a braino. Nico -- From Nicolas.Williams@oracle.com Thu Oct 14 16:32: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 5814C3A6B02 for ; Thu, 14 Oct 2010 16:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 mOnWmQh9kfAK for ; Thu, 14 Oct 2010 16:32:21 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D9E1C3A6A43 for ; Thu, 14 Oct 2010 16:32:20 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9ENXdBI019054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Oct 2010 23:33:40 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9EJTI2W028467; Thu, 14 Oct 2010 23:33:38 GMT Received: from abhmt002.oracle.com by acsmt354.oracle.com with ESMTP id 692124361287099191; Thu, 14 Oct 2010 16:33:11 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 14 Oct 2010 16:33:11 -0700 Date: Thu, 14 Oct 2010 18:33:07 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20101014233306.GR1635@oracle.com> References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014231957.GP1635@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 23:32:25 -0000 On Thu, Oct 14, 2010 at 07:28:12PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > Nicolas> Also, how is the GSS-Acceptor-Realm-Name determined when a > Nicolas> name is imported using GSS_C_NT_HOSTBASED_SERVICE is > Nicolas> canonicalized (or passed to gss_init_sec_context() as a > > Remember these are AA attributes. > They appear in two places: > > 1) channel bindings from the initiator to the EAP server. > There, the realm name is absent if not specified. > > 2) In AAA attributes from the acceptor to the EAP server via a bunch of > proxies. > There, we assume the acceptor knows its own realm name. > > Proxies along the way are responsible for validating the claim the > acceptor is implicitly making--namely that the given hostname is part of > the claimed realm. Understood. But remember that the GSS-API, for better or worse, requires that one be able to canonicalize a name, then export it, and that the resulting exported name token should be the same as the one one would get from exporting the name for the same principal returned by GSS_Inquire_sec_context(). Personally I'm perfectly willing to accept that if you want such behavior then you must import the name with mechanism-specific name type rather than generic name type, and the buffer to be imported must contain a canonical principal name. Nico -- From hartmans@painless-security.com Thu Oct 14 16:35:54 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 1CE793A6A6C for ; Thu, 14 Oct 2010 16:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 HA0rCGBDln64 for ; Thu, 14 Oct 2010 16:35:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4A9583A6A63 for ; Thu, 14 Oct 2010 16:35:53 -0700 (PDT) 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 23385202FB; Thu, 14 Oct 2010 19:37:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B561C47C5; Thu, 14 Oct 2010 19:36:52 -0400 (EDT) From: Sam Hartman To: Nicolas Williams References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014231957.GP1635@oracle.com> <20101014233306.GR1635@oracle.com> Date: Thu, 14 Oct 2010 19:36:52 -0400 In-Reply-To: <20101014233306.GR1635@oracle.com> (Nicolas Williams's message of "Thu, 14 Oct 2010 18:33:07 -0500") 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 abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Thu, 14 Oct 2010 23:35:54 -0000 >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Understood. But remember that the GSS-API, for better or Nicolas> worse, requires that one be able to canonicalize a name, Nicolas> then export it, and that the resulting exported name token Nicolas> should be the same as the one one would get from exporting Nicolas> the name for the same principal returned by Nicolas> GSS_Inquire_sec_context(). I *think* you generally get that. I'm not sure you get the same exported name on the initiator and acceptor for the same principal, but I do believe that the ACL uses of export_name will work. This is certainly something to explore. From lukeh@padl.com Thu Oct 14 18:31:09 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 E75373A686B for ; Thu, 14 Oct 2010 18:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.904 X-Spam-Level: X-Spam-Status: No, score=-3.904 tagged_above=-999 required=5 tests=[AWL=-1.305, 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 YyfNp3YX-PQx for ; Thu, 14 Oct 2010 18:31:08 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 1A8FC3A63EB for ; Thu, 14 Oct 2010 18:31:07 -0700 (PDT) Received: by us.padl.com with ESMTP id o9F1WAwu009726; Thu, 14 Oct 2010 21:32:17 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20101014230012.GN1635@oracle.com> Date: Fri, 15 Oct 2010 12:32:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7054485E-5845-42E7-8245-5E5F31BD0EBF@padl.com> References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014230012.GN1635@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Fri, 15 Oct 2010 01:31:10 -0000 > Will this mechanism have initiator and acceptor sub-keys, like = RFC4121? This was discussed previously, on this list I believe, and the answer = was no. (I will have more to say on this later.) >> Critical extensions have the high bit set. One critical extension = type >> is defined for channel bindings and has the value zero (not including >> the critical bit). >=20 > Any way to optimize round-trips away? We could piggy-back the server extension token to the last EAP message = from the acceptor. Does EAP always have an even number of legs? If not, = then we can (for odd number) piggy-back the client extension token to = the last message from initiator. But I don't know if there's a way to = know this in an abstraction-preserving way. > Is T here from a Radius namespace? If so, you could add a meta-type > field for non-Radius attributes, no? Thinking about this some more, if we really want to standardise this, we = need to encode authenticated-flag, complete-flag and a critical flag = (must be understood by import name). e.g. flags || type || subtype-length || subtype || value-length || value I'm going to argue now in favour of not standardising it unless someone = can come up with a compelling argument why you want to use exported = composite names for anything other than interprocess exchange. If you = want to do attribute-based authorisation, you should extract the = attributes you're interested in explicitly. > It'd be nice to be able to protect protectable errors, e.g., errors > resulting from policy decisions as opposed to errors resulting from > inability to complete key exchange. True. But if we protect the policy error codes, then what's to stop an = attacker removing the MIC and changing the policy error code to a = non-policy one? -- Luke= From lukeh@padl.com Thu Oct 14 18:31: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 5D7673A6956 for ; Thu, 14 Oct 2010 18:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.874 X-Spam-Level: X-Spam-Status: No, score=-3.874 tagged_above=-999 required=5 tests=[AWL=-1.275, 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 PNwLLUohYZQn for ; Thu, 14 Oct 2010 18:31:25 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 8BA6C3A693A for ; Thu, 14 Oct 2010 18:31:23 -0700 (PDT) Received: by us.padl.com with ESMTP id o9F1WAwv009726; Thu, 14 Oct 2010 21:32:37 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20101014231957.GP1635@oracle.com> Date: Fri, 15 Oct 2010 12:32:40 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014231957.GP1635@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Fri, 15 Oct 2010 01:31:28 -0000 >>> * GSS name attribute format for RADIUS value-pairs >> >> "urn:ietf:params:gss-eap:radius-avp urn:x-radius:" || attrID >> >> where attrID is the string representation of the RADIUS attribute ID. > > Seems fine to me. Well, perhaps we should get an assigned URN type for RADIUS attributes. -- Luke From lukeh@padl.com Thu Oct 14 18:38:54 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 122353A686B for ; Thu, 14 Oct 2010 18:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.845 X-Spam-Level: X-Spam-Status: No, score=-3.845 tagged_above=-999 required=5 tests=[AWL=-1.247, BAYES_00=-2.599, HTML_MESSAGE=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 WKL2O44glqc4 for ; Thu, 14 Oct 2010 18:38:53 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 037873A67E2 for ; Thu, 14 Oct 2010 18:38:52 -0700 (PDT) Received: by us.padl.com with ESMTP id o9F1e1uk025934; Thu, 14 Oct 2010 21:40:07 -0400 From: Luke Howard Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-307--438041545 Date: Fri, 15 Oct 2010 12:40:03 +1100 In-Reply-To: To: "abfab@ietf.org abfab" References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014231957.GP1635@oracle.com> <20101014233306.GR1635@oracle.com> Message-Id: <367F32BC-7BF6-4377-A377-E9CF9650FA79@padl.com> X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: Re: [abfab] Two internet drafts submitted 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: Fri, 15 Oct 2010 01:38:54 -0000 --Apple-Mail-307--438041545 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here's a complete list of token types I've used so far, FWIW. enum gss_eap_token_type { TOK_TYPE_NONE =3D 0x0000, /* no token */ TOK_TYPE_MIC =3D 0x0404, /* RFC 4121 MIC token = */ TOK_TYPE_WRAP =3D 0x0504, /* RFC 4121 wrap token = */ TOK_TYPE_EXPORT_NAME =3D 0x0401, /* RFC 2743 exported = name */ TOK_TYPE_EXPORT_NAME_COMPOSITE =3D 0x0402, /* exported composite = name */ TOK_TYPE_DELETE_CONTEXT =3D 0x0405, /* RFC 2743 delete = context */ TOK_TYPE_EAP_RESP =3D 0x0601, /* EAP response */ TOK_TYPE_EAP_REQ =3D 0x0602, /* EAP request */ TOK_TYPE_EXT_REQ =3D 0x0603, /* GSS EAP extensions = request */ TOK_TYPE_EXT_RESP =3D 0x0604, /* GSS EAP extensions = response */ TOK_TYPE_CONTEXT_ERR =3D 0x0606, /* context error */ }; Note: EAP *response* is an initiator token (it's back to front). -- Luke= --Apple-Mail-307--438041545 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii enum gss_eap_token_type {
    TOK_TYPE_NONE =                    =3D = 0x0000,  /* no token */
    TOK_TYPE_MIC   =                   =3D = 0x0404,  /* RFC 4121 MIC token */
   =  TOK_TYPE_WRAP               =      =3D 0x0504,  /* RFC 4121 wrap token = */
    TOK_TYPE_EXPORT_NAME       =       =3D 0x0401,  /* RFC 2743 exported name = */
    TOK_TYPE_EXPORT_NAME_COMPOSITE   =3D = 0x0402,  /* exported composite name */
   =  TOK_TYPE_DELETE_CONTEXT          =3D = 0x0405,  /* RFC 2743 delete context */
   =  TOK_TYPE_EAP_RESP               =  =3D 0x0601,  /* EAP response */
   =  TOK_TYPE_EAP_REQ               =   =3D 0x0602,  /* EAP request */
   =  TOK_TYPE_EXT_REQ               =   =3D 0x0603,  /* GSS EAP extensions request = */
    TOK_TYPE_EXT_RESP         =        =3D 0x0604,  /* GSS EAP extensions = response */
    TOK_TYPE_CONTEXT_ERR     =         =3D 0x0606,  /* context error = */
};

Note: EAP *response* is an = initiator token (it's back to front).

-- = Luke
= --Apple-Mail-307--438041545-- From Nicolas.Williams@oracle.com Fri Oct 15 00:13:42 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 5EB1A3A6C07 for ; Fri, 15 Oct 2010 00:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Y4-866yCxltx for ; Fri, 15 Oct 2010 00:13:39 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 5C3DD3A6ADA for ; Fri, 15 Oct 2010 00:13:39 -0700 (PDT) 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 o9F7EvrT008395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 07:14:59 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 o9F3jKex024106; Fri, 15 Oct 2010 07:14:57 GMT Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 686648901287126822; Fri, 15 Oct 2010 00:13:42 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 00:13:42 -0700 Date: Fri, 15 Oct 2010 02:13:37 -0500 From: Nicolas Williams To: Luke Howard Message-ID: <20101015071337.GY1635@oracle.com> References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014230012.GN1635@oracle.com> <7054485E-5845-42E7-8245-5E5F31BD0EBF@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7054485E-5845-42E7-8245-5E5F31BD0EBF@padl.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Fri, 15 Oct 2010 07:13:42 -0000 On Fri, Oct 15, 2010 at 12:32:14PM +1100, Luke Howard wrote: > > Will this mechanism have initiator and acceptor sub-keys, like RFC4121? > > This was discussed previously, on this list I believe, and the answer > was no. (I will have more to say on this later.) I recall (and recalled when I asked), but wanted to make sure it still was the case. > > Is T here from a Radius namespace? If so, you could add a meta-type > > field for non-Radius attributes, no? > > Thinking about this some more, if we really want to standardise this, > we need to encode authenticated-flag, complete-flag and a critical > flag (must be understood by import name). e.g. > > flags || type || subtype-length || subtype || value-length || value > > I'm going to argue now in favour of not standardising it unless > someone can come up with a compelling argument why you want to use > exported composite names for anything other than interprocess > exchange. If you want to do attribute-based authorisation, you should > extract the attributes you're interested in explicitly. If there's multiple GSS-API implementations, then a standard inter-process token format can add value. > > It'd be nice to be able to protect protectable errors, e.g., errors > > resulting from policy decisions as opposed to errors resulting from > > inability to complete key exchange. > > True. But if we protect the policy error codes, then what's to stop an > attacker removing the MIC and changing the policy error code to a > non-policy one? Nothing, of course. But in the case of Kerberos there are a number of errors which would have been much handier when protected. For example, errors about clock skew would, if protected, provide authenticate time to the client (handy indeed!). (Yes, I know that clients can use the time info in KRB-ERROR to adjust their timestamps and re-try, then they can get authenticated time with second precision.) It's... not a big deal, and less so for this mechanism than for Kerberos. Feel free to say ETOOHARD or EWHOCARES :) Nico -- From lukeh@padl.com Fri Oct 15 00:15:20 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 84FF33A68BC for ; Fri, 15 Oct 2010 00:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.819 X-Spam-Level: X-Spam-Status: No, score=-3.819 tagged_above=-999 required=5 tests=[AWL=-1.220, 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 uCw2gDuEQTfm for ; Fri, 15 Oct 2010 00:15:19 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 43C343A6C5F for ; Fri, 15 Oct 2010 00:15:18 -0700 (PDT) Received: by us.padl.com with ESMTP id o9F7GSeQ028387; Fri, 15 Oct 2010 03:16:33 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <20101015071337.GY1635@oracle.com> Date: Fri, 15 Oct 2010 18:16:32 +1100 Content-Transfer-Encoding: 7bit Message-Id: <7994BF7E-A012-458B-96EB-B46261C736DC@padl.com> References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014230012.GN1635@oracle.com> <7054485E-5845-42E7-8245-5E5F31BD0EBF@padl.com> <20101015071337.GY1635@oracle.com> To: Nicolas Williams X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: "abfab@ietf.org abfab" Subject: Re: [abfab] Two internet drafts submitted 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: Fri, 15 Oct 2010 07:15:20 -0000 > can get authenticated time with second precision.) It's... not a big > deal, and less so for this mechanism than for Kerberos. Feel free to > say ETOOHARD or EWHOCARES :) major_status = GSS_S_UNAVAILABLE; *minor_status = GSSEAP_TOOHARD; :-) -- Luke From eve@xmlgrrl.com Fri Oct 15 10:37:35 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 E3C7B3A6953 for ; Fri, 15 Oct 2010 10:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] 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 9Ni-fr17oBwv for ; Fri, 15 Oct 2010 10:37:34 -0700 (PDT) Received: from mail.promanage-inc.com (eliasisrael.com [98.111.84.13]) by core3.amsl.com (Postfix) with ESMTP id 3DD113A6A90 for ; Fri, 15 Oct 2010 10:37:34 -0700 (PDT) Received: from [192.168.168.198] ([192.168.168.198]) (authenticated bits=0) by mail.promanage-inc.com (8.14.4/8.14.3) with ESMTP id o9FHcqhn002578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Oct 2010 10:38:53 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Eve Maler In-Reply-To: Date: Fri, 15 Oct 2010 10:38:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <09DC8476-E4CB-47BA-860E-ADD20848AFFF@xmlgrrl.com> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1081) Cc: abfab@ietf.org Subject: Re: [abfab] Federation Terminology 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: Fri, 15 Oct 2010 17:37:36 -0000 Sorry for the delayed response! In earlier drafts of the paper we used to talk about "trust = communities", but I guess we ended up taking that language out. In any = case, I was thinking that a trust framework and its members collectively = make up what could be called a federation. The technical, legal, and = operational requirements for exchanges of identity information are (a) = decided on by policymakers, (b) instantiated in a framework that is run = by a trust framework provider (=3D=3D federation operator), and (c) has = members whose compliance to the requirements is measured in some = fashion. (There's no particular additional benefit to using the non-F-word = language, but it's good to know how to translate across to that language = for those who prefer it.) Eve On 12 Oct 2010, at 9:43 AM, Hannes Tschofenig wrote: > Hey Eve,=20 >=20 > I like the OIX writeup and I would use terminology from there but I = wasn't able to spot something that explains a federation. There you seem = to be talking about trust framework instead and that largely without = defined terminology (which makes the document actually quite difficult = to understand and to relate to work outside the OIX environment). I = would also like to understand how far a trust framework (as described in = the OIX document) relates to the federation concept. =20 >=20 > Ciao > Hannes >=20 > On Oct 12, 2010, at 7:31 PM, Eve Maler wrote: >=20 >> Here was my own entry into the federation terminology sweepstakes = once upon a time... :-) >>=20 >> = http://www.xmlgrrl.com/blog/2007/07/17/account-linking-and-the-f-word/ >>=20 >> Also note that, while the F-word fits the abfab community = comfortably, there are other communities that don't like the word but = gravitate towards "trust" language more. A bunch of terms relevant to = federations are introduced here, for example: >>=20 >> = http://openidentityexchange.org/sites/default/files/the-open-identity-trus= t-framework-model-2010-03.pdf >>=20 >> Even more terms are introduced in this old doc: >>=20 >> = http://www.oasis-open.org/committees/download.php/6158/sstc-saml-trustmode= ls-2.0-draft-01.pdf >>=20 >> Hannes, if you feel inclined to write a federation equivalent of = draft-hansen-privacy-terminology (!), I'm happy to try and help/review. >>=20 >> Eve >>=20 >> On 12 Oct 2010, at 9:09 AM, Nicolas Williams wrote: >>=20 >>> On Tue, Oct 12, 2010 at 06:35:11PM +0300, Hannes Tschofenig wrote: >>>> I liked the Liberty Alliance definition more: "An association >>>> compromising any number of service providers and identity = providers." >>>> maybe adding the AAA specific aspect that there are additional = actors, >>>> such as brokers. The aspect that these entities belong to different >>>> administrative domains might also be worth mentioning. >>>=20 >>> Sounds like you want better definitions rather than new terminology. >>>=20 >>> First, a nit: s/compromising/comprising/ :) >>>=20 >>> Second, I don't think mentioning specific technologies or types of >>> technologies in the definition of "federation" is terribly important >>> right now. The essential question is: what do federations provide = to >>> their members? >>>=20 >>> Now, "federation" can seem ambiguous, but that may be an advantage >>> because it may be too soon to draw strong distinctions between = ongoing, >>> independent efforts in this area. Consider, for example, ABFAB and >>> NFSv4. >>>=20 >>> Here in ABFAB it seems to mean "a collection of distinct = administrative >>> domains which arrange for participating services to be able to >>> authenticate users, and obtain authorization-relevant information = about >>> them, from participating domains". >>>=20 >>> Over in the NFSv4 WG the term "federated namespace" refers to a = global >>> namespace constructed out of DNS SRV RRs, NFSv4 referrals, and >>> conventions for using LDAP to store information that NFSv4 servers = need >>> to construct namespaces. This surely seems unrelated to ABFAB but = NFSv4 >>> also has an aspect of identification, authentication and = authorization >>> that is involved in creating a "federated namespace". >>>=20 >>> Some of us are proposing a method of constructing a federated = namespace >>> for NFSv4 that covers the naming of users and groups of users, and = which >>> ties authentication and authorization into the picture. >>>=20 >>> As you can see, there's some overlap between the NFSv4 concept of >>> federation and ABFAB's, yet the technologies involved are different. = To >>> be fair, I think NFSv4 could use ABFAB as one set or sub-set of >>> technologies in building NFSv4 federations -- after all, NFSv4 uses = the >>> GSS-API. >>>=20 >>> But NFSv4 also needs name resolution services so that users can = create, >>> view and edit access control lists (ACLs). ABFAB provides no such >>> services. >>>=20 >>> Question: to what extent other ABFAB apps will need name services, = and >>> should ABFAB provide them? >>>=20 >>> The slight ambiguity of the term 'federation' has proven useful to = me: >>> it's helped me reach the point where I could ask the above question = by >>> making me consider the differences and similarities between two >>> conceptions of 'federation'. >>>=20 >>> Nico >>> --=20 >>> _______________________________________________ Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl From Nicolas.Williams@oracle.com Fri Oct 15 11:29:57 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 D70243A693E for ; Fri, 15 Oct 2010 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 NhiKlPgyBhZT for ; Fri, 15 Oct 2010 11:29:56 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D14BC3A684F for ; Fri, 15 Oct 2010 11:29:56 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o9FIVFwX009997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2010 18:31:16 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o9FFgS12012548; Fri, 15 Oct 2010 18:31:14 GMT Received: from abhmt017.oracle.com by acsmt354.oracle.com with ESMTP id 688738511287167439; Fri, 15 Oct 2010 11:30:39 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 15 Oct 2010 11:30:39 -0700 Date: Fri, 15 Oct 2010 13:30:35 -0500 From: Nicolas Williams To: Eve Maler Message-ID: <20101015183034.GZ1635@oracle.com> References: <3D3C75174CB95F42AD6BCC56E5555B45032D57EE@FIESEXC015.nsn-intra.net> <4C1620F9-14C2-4E70-8EF2-1BA238E36A05@gmx.net> <4CB47963.2070607@cisco.com> <35556ECE-E7CA-4560-BD0D-FBA12CD6E797@gmx.net> <20101012160928.GF1635@oracle.com> <09DC8476-E4CB-47BA-860E-ADD20848AFFF@xmlgrrl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <09DC8476-E4CB-47BA-860E-ADD20848AFFF@xmlgrrl.com> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org, Hannes Tschofenig Subject: Re: [abfab] Federation Terminology 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: Fri, 15 Oct 2010 18:29:57 -0000 On Fri, Oct 15, 2010 at 10:38:52AM -0700, Eve Maler wrote: > In earlier drafts of the paper we used to talk about "trust > communities", but I guess we ended up taking that language out. In > any case, I was thinking that a trust framework and its members > collectively make up what could be called a federation. The > technical, legal, and operational requirements for exchanges of > identity information are (a) decided on by policymakers, (b) > instantiated in a framework that is run by a trust framework provider > (== federation operator), and (c) has members whose compliance to the > requirements is measured in some fashion. The problem with "trust" is that it's become a bad word -- there's too much it could denote, and anyways it's too scary. Federation is much nicer word. Its English language meaning denotes independence in decision making (such as about degrees of trust). Linguistic considerations do matter. After all, we're selling this sort of thing to people who won't know and understand the term-of-art meanings of these terms, so the closer we can their semantics to their natural language counterparts, the better. There is some risk of overusing the F word -- we've overused "trust", after all, and now it's not nearly as useful as it once seemed. > (There's no particular additional benefit to using the non-F-word > language, but it's good to know how to translate across to that > language for those who prefer it.) Yes. Nico -- From lukeh@padl.com Sat Oct 16 04:23: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 611A73A6822 for ; Sat, 16 Oct 2010 04:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.792 X-Spam-Level: X-Spam-Status: No, score=-3.792 tagged_above=-999 required=5 tests=[AWL=-1.194, BAYES_00=-2.599, HTML_MESSAGE=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 dVH89BusuGM5 for ; Sat, 16 Oct 2010 04:23:05 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 55CDD3A6A56 for ; Sat, 16 Oct 2010 04:23:04 -0700 (PDT) Received: by us.padl.com with ESMTP id o9GBOHCT026092; Sat, 16 Oct 2010 07:24:21 -0400 From: Luke Howard Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-427--316583880 Date: Sat, 16 Oct 2010 22:24:21 +1100 In-Reply-To: <7994BF7E-A012-458B-96EB-B46261C736DC@padl.com> To: "abfab@ietf.org abfab" References: <4CB6C94D.1030206@mnt.se> <70DF98D1-8828-4F11-8173-F5CA206EF4FD@padl.com> <20101014230012.GN1635@oracle.com> <7054485E-5845-42E7-8245-5E5F31BD0EBF@padl.com> <20101015071337.GY1635@oracle.com> <7994BF7E-A012-458B-96EB-B46261C736DC@padl.com> Message-Id: X-Mailer: Apple Mail (2.1081) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: Re: [abfab] Two internet drafts submitted 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: Sat, 16 Oct 2010 11:23:06 -0000 --Apple-Mail-427--316583880 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Current implementation protocol error codes, some may move back to = API-only codes (they were retro-fitted to existing code so they = certainly can be refined). success 0 # never seen wrongSize 1 # incorrect buffer size wrongMech 2 # wrong mechanism OID in token badTokenHeader 3 # bad token header tokenTruncated 4 # truncated token badDirection 5 # packet replayed in wrong = direction wrongTokenID 6 # wrong token ID criticalExtensionUnavailable 7 # critical extension unavailable missingRequiredExtension 8 # missing required extension keyUnavailable 9 # MSK not available keyTooShort 10 # MSK too short to derive KMSK radiusAuthenticationFailure 11 # RADIUS authentication failed unknownRadiusResponse 12 # RADIUS authentication unknown = resp missingEapRequest 13 # missing EAP request in RADIUS = resp genericRadiusError 14 # other RADIUS error -- Luke= --Apple-Mail-427--316583880 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii success = 0 = # never seen
wrongSize = 1 = # incorrect buffer size
wrongMech = 2 = # wrong mechanism OID in token
badTokenHeader = 3 = # bad token header
tokenTruncated = 4 = # truncated token
badDirection = 5 = # packet replayed in wrong = direction
wrongTokenID = 6 = # wrong token ID
criticalExtensionUnavailable 7 # = critical extension unavailable
missingRequiredExtension 8 # missing = required extension
keyUnavailable 9 # MSK not = available
keyTooShort 10 # MSK too = short to derive KMSK
radiusAuthenticationFailure 11 # RADIUS authentication = failed
unknownRadiusResponse = 12 = # RADIUS authentication unknown = resp
missingEapRequest 13 # missing = EAP request in RADIUS resp
genericRadiusError 14 # other = RADIUS error

-- = Luke
= --Apple-Mail-427--316583880-- From root@core3.amsl.com Mon Oct 18 11:30:05 2010 Return-Path: X-Original-To: abfab@ietf.org Delivered-To: abfab@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 525423A6B90; Mon, 18 Oct 2010 11:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101018183004.525423A6B90@core3.amsl.com> Date: Mon, 18 Oct 2010 11:30:01 -0700 (PDT) Cc: abfab@ietf.org Subject: [abfab] I-D ACTION:draft-ietf-abfab-aaa-saml-00.txt 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, 18 Oct 2010 18:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : An AAA Attribute for SAML Constructs Author(s) : J. Howlett, S. Hartman Filename : draft-ietf-abfab-aaa-saml-00.txt Pages : 8 Date : 2010-10-18 This document defines the SAML-Construct attribute for use with AAA protocols. This attribute is used for encapsulating Security Assertion Mark-up Language (SAML) constructs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-abfab-aaa-saml-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-18112750.I-D@ietf.org> --NextPart-- From lear@cisco.com Mon Oct 18 11:39:50 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 A14BD3A6B8B for ; Mon, 18 Oct 2010 11:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hvRqwZT+oI0h for ; Mon, 18 Oct 2010 11:39:49 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 72D643A69F0 for ; Mon, 18 Oct 2010 11:39:49 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACIxvEyrR7Ht/2dsb2JhbACDH54OcaN3iiKSJYEigzN0BIpK X-IronPort-AV: E=Sophos;i="4.57,345,1283731200"; d="scan'208";a="243126289" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 Oct 2010 18:41:18 +0000 Received: from ams3-vpn-dhcp1746.cisco.com (ams3-vpn-dhcp1746.cisco.com [10.61.70.210]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o9IIfHOM017356 for ; Mon, 18 Oct 2010 18:41:18 GMT Message-ID: <4CBC94ED.2070803@cisco.com> Date: Mon, 18 Oct 2010 20:41:49 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [abfab] an early draft of an architecture document 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, 18 Oct 2010 18:39:50 -0000 Hi everyone, Sam, Josh, Hannes, and I put out a very early version of an ABFAB architecture. To say this is drafty doesn't quite do justice to drafty! But we are looking for inputs, and I suspect it will get at least mentioned at the meeting in Beijing. You can expect something more fleshed out in the coming weeks, after IETF, however. draft-lear-abfab-architecture-00.txt Eliot From leifj@sunet.se Mon Oct 18 15:18:42 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 DDFB83A6B8F for ; Mon, 18 Oct 2010 15:18:42 -0700 (PDT) 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 V5wpFzrc1Bml for ; Mon, 18 Oct 2010 15:18:41 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 8DCCE3A6AB6 for ; Mon, 18 Oct 2010 15:18:41 -0700 (PDT) Received: from [192.168.177.112] ([217.111.178.142]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9IMK6FE020768 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 19 Oct 2010 00:20:09 +0200 (CEST) Message-ID: <4CBCC815.9080402@sunet.se> Date: Tue, 19 Oct 2010 00:20:05 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Proposed Agenda (v 1) 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, 18 Oct 2010 22:18:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, Here is the first version of the charter. We've allocated lots of time for discussion of our core documents and we've also decided to add a short intro to the subject matter since we're probably going to see some new participants in the room (but also because it is our first WG meeting). Comments? - ------------ 1. Agenda bashing and Note Well (5 min) 2. abfab overview and introduction for newbees (15min) 3. Document status and discussions (45min) 3.1 architecture document (TBD) 3.2 draft-ietf-abfab-gss-eap-0 3.3 draft-ietf-abfab-gss-eap-naming-00 3.4 draft-ietf-abfab-aaa-saml-00 4. Technical discussion (25min) Leif and Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky8yBEACgkQ8Jx8FtbMZneKDACghNx2FwCfEBX/gh0d7VbXlq8F FzsAoIcety1KSk8j049chzyyTCCoOz89 =mFBf -----END PGP SIGNATURE----- From leifj@sunet.se Wed Oct 20 13:23:37 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 2A66F3A67AB for ; Wed, 20 Oct 2010 13:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 yVv-A601Cu8g for ; Wed, 20 Oct 2010 13:23:36 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id DC9233A67A7 for ; Wed, 20 Oct 2010 13:23:35 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9KKP5bA017693 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 20 Oct 2010 22:25:08 +0200 (CEST) Message-ID: <4CBF5021.2010404@sunet.se> Date: Wed, 20 Oct 2010 22:25:05 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: abfab@ietf.org References: <4CBCC815.9080402@sunet.se> In-Reply-To: <4CBCC815.9080402@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Proposed Agenda (v 1) 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, 20 Oct 2010 20:23:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/19/2010 12:20 AM, Leif Johansson wrote: > > Folks, > > Here is the first version of the charter. We've allocated lots of time > for discussion of our core documents and we've also decided to add a > short intro to the subject matter since we're probably going to see > some new participants in the room (but also because it is our first WG > meeting). > > Comments? > > ------------ > > 1. Agenda bashing and Note Well (5 min) > > 2. abfab overview and introduction for newbees (15min) > > 3. Document status and discussions (45min) > > 3.1 architecture document (TBD) > 3.2 draft-ietf-abfab-gss-eap-0 > 3.3 draft-ietf-abfab-gss-eap-naming-00 > 3.4 draft-ietf-abfab-aaa-saml-00 > > 4. Technical discussion (25min) > > I think we'll post this unless there are any comments... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky/UCEACgkQ8Jx8FtbMZndsKwCdFlxqbwERsVtnHbA3bJOB+maa WmYAn1moGFnX4HUJWextUlxCox/fsx4F =WD7N -----END PGP SIGNATURE----- From lear@cisco.com Thu Oct 21 01:02: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 BC7593A68AB for ; Thu, 21 Oct 2010 01:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.466 X-Spam-Level: X-Spam-Status: No, score=-108.466 tagged_above=-999 required=5 tests=[AWL=2.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 tgS+lTDdwbdx for ; Thu, 21 Oct 2010 01:02:05 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 236943A686D for ; Thu, 21 Oct 2010 01:02:04 -0700 (PDT) Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEACWQv0yQ/khMgWdsb2JhbACDHZ45FQEBFiIio3GKKZIIgSKDNHQEiks X-IronPort-AV: E=Sophos;i="4.58,216,1286150400"; d="scan'208";a="67177208" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Oct 2010 08:03:39 +0000 Received: from dhcp-10-61-105-242.cisco.com (dhcp-10-61-105-242.cisco.com [10.61.105.242]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o9L83dZW024872; Thu, 21 Oct 2010 08:03:39 GMT Message-ID: <4CBFF3FA.8020807@cisco.com> Date: Thu, 21 Oct 2010 10:04:10 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: Leif Johansson References: <4CBCC815.9080402@sunet.se> <4CBF5021.2010404@sunet.se> In-Reply-To: <4CBF5021.2010404@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Proposed Agenda (v 1) 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: Thu, 21 Oct 2010 08:02:06 -0000 Just FYI I do not plan to be at Beijing, and so presentation of the architecture draft would have to be from someone else. Also, I'm not sure it's quite ripe enough for presentation. It's there. We need to do more work, though. On 10/20/10 10:25 PM, Leif Johansson wrote: > On 10/19/2010 12:20 AM, Leif Johansson wrote: > > > Folks, > > > Here is the first version of the charter. We've allocated lots of time > > for discussion of our core documents and we've also decided to add a > > short intro to the subject matter since we're probably going to see > > some new participants in the room (but also because it is our first WG > > meeting). > > > Comments? > > > ------------ > > > 1. Agenda bashing and Note Well (5 min) > > > 2. abfab overview and introduction for newbees (15min) > > > 3. Document status and discussions (45min) > > > 3.1 architecture document (TBD) > > 3.2 draft-ietf-abfab-gss-eap-0 > > 3.3 draft-ietf-abfab-gss-eap-naming-00 > > 3.4 draft-ietf-abfab-aaa-saml-00 > > > 4. Technical discussion (25min) > > > > > I think we'll post this unless there are any comments... > > Cheers Leif _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From leifj@mnt.se Thu Oct 21 04:00:14 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 792173A6452 for ; Thu, 21 Oct 2010 04:00:14 -0700 (PDT) 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=[AWL=0.000, 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 vURjPBt0OLNi for ; Thu, 21 Oct 2010 04:00:06 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 789F03A69ED for ; Thu, 21 Oct 2010 04:00:03 -0700 (PDT) Received: from [192.36.125.221] (dhcp.pilsnet.sunet.se [192.36.125.221]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9LB1Zic023000 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 21 Oct 2010 13:01:38 +0200 (CEST) Message-ID: <4CC01D8F.8050008@mnt.se> Date: Thu, 21 Oct 2010 13:01:35 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: abfab@ietf.org References: <4CBCC815.9080402@sunet.se> <4CBF5021.2010404@sunet.se> <4CBFF3FA.8020807@cisco.com> In-Reply-To: <4CBFF3FA.8020807@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Proposed Agenda (v 1) 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: Thu, 21 Oct 2010 11:00:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/21/2010 10:04 AM, Eliot Lear wrote: > Just FYI I do not plan to be at Beijing, and so presentation of the > architecture draft would have to be from someone else. Also, I'm not > sure it's quite ripe enough for presentation. It's there. We need to > do more work, though. ok point taken - unless anyone else steps up maybe we'll drop the item. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzAHY8ACgkQ8Jx8FtbMZncdTACgxCf/CF6B0YyO3ZVSKk1JKk++ AMoAn1cbnHzHMjqLHTScNu4/nNvC8ZhO =sQgA -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Thu Oct 21 06:58:20 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 9DD033A68AD for ; Thu, 21 Oct 2010 06:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.865 X-Spam-Level: X-Spam-Status: No, score=-101.865 tagged_above=-999 required=5 tests=[AWL=0.734, 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 ivNFyvJvW3-r for ; Thu, 21 Oct 2010 06:58:19 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id AB5BD3A67E6 for ; Thu, 21 Oct 2010 06:58:19 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 1E4F14A6B72_CC0475AB; Thu, 21 Oct 2010 13:59:54 +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 F33BD4A6B6C_CC04757F; Thu, 21 Oct 2010 13:59:51 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi; Thu, 21 Oct 2010 15:00:05 +0100 From: Josh Howlett To: Eliot Lear , Leif Johansson Thread-Topic: [abfab] Proposed Agenda (v 1) Thread-Index: AQHLbxLbKedPSfNwcEyq/S3HhSpSe5NKOtmAgADDUgCAAHKGYA== Date: Thu, 21 Oct 2010 13:59:49 +0000 Message-ID: References: <4CBCC815.9080402@sunet.se> <4CBF5021.2010404@sunet.se> <4CBFF3FA.8020807@cisco.com> In-Reply-To: <4CBFF3FA.8020807@cisco.com> 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 , "abfab@ietf.org" Subject: Re: [abfab] Proposed Agenda (v 1) 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: Thu, 21 Oct 2010 13:58:20 -0000 Perhaps we could combine the ABFAB Overview slot with the Architecture draf= t discussion slots? One of the purposes of the draft, after all, is to prov= ide this kind of overview. It may also be useful to get opinions from newbi= es concerning how well the document works for them (or not) while the docum= ent is still at an early stage of development. Josh. > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Eliot Lear > Sent: Thursday, October 21, 2010 9:04 AM > To: Leif Johansson > Cc: abfab@ietf.org > Subject: Re: [abfab] Proposed Agenda (v 1) >=20 > Just FYI I do not plan to be at Beijing, and so presentation of the > architecture draft would have to be from someone else. Also, I'm not > sure it's quite ripe enough for presentation. It's there. We need to > do more work, though. >=20 > On 10/20/10 10:25 PM, Leif Johansson wrote: > > On 10/19/2010 12:20 AM, Leif Johansson wrote: > > > > > Folks, > > > > > Here is the first version of the charter. We've allocated lots of > time > > > for discussion of our core documents and we've also decided to add > a > > > short intro to the subject matter since we're probably going to see > > > some new participants in the room (but also because it is our first > WG > > > meeting). > > > > > Comments? > > > > > ------------ > > > > > 1. Agenda bashing and Note Well (5 min) > > > > > 2. abfab overview and introduction for newbees (15min) > > > > > 3. Document status and discussions (45min) > > > > > 3.1 architecture document (TBD) > > > 3.2 draft-ietf-abfab-gss-eap-0 > > > 3.3 draft-ietf-abfab-gss-eap-naming-00 > > > 3.4 draft-ietf-abfab-aaa-saml-00 > > > > > 4. Technical discussion (25min) > > > > > > > > > > I think we'll post this unless there are any comments... > > > > Cheers Leif > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab >=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab 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 From hartmans@painless-security.com Thu Oct 21 07:07:19 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 096DA3A69F4 for ; Thu, 21 Oct 2010 07:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, 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 EtLVYQoczUCt for ; Thu, 21 Oct 2010 07:07:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2FCF13A698B for ; Thu, 21 Oct 2010 07:07:18 -0700 (PDT) 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 38CE2202FB; Thu, 21 Oct 2010 10:08:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 86D4041CE; Thu, 21 Oct 2010 10:08:18 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: <4CBCC815.9080402@sunet.se> <4CBF5021.2010404@sunet.se> <4CBFF3FA.8020807@cisco.com> Date: Thu, 21 Oct 2010 10:08:18 -0400 In-Reply-To: (Josh Howlett's message of "Thu, 21 Oct 2010 13:59:49 +0000") 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] Proposed Agenda (v 1) 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: Thu, 21 Oct 2010 14:07:19 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> Perhaps we could combine the ABFAB Overview slot with the Josh> Architecture draft discussion slots? One of the purposes of Josh> the draft, after all, is to provide this kind of overview. It Josh> may also be useful to get opinions from newbies concerning how Josh> well the document works for them (or not) while the document Josh> is still at an early stage of development. Josh. I support this. Regardless of whether we make this specific change I'd definitely like to see people discuss the architecture document and would be happy to spend time necessary to make that happen. --Sam From leifj@sunet.se Thu Oct 21 07:13:20 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 9A3333A6A12 for ; Thu, 21 Oct 2010 07:13:20 -0700 (PDT) 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=[AWL=0.000, 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 tbEsj7j6jM4i for ; Thu, 21 Oct 2010 07:13:17 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 7D1253A6A0F for ; Thu, 21 Oct 2010 07:13:17 -0700 (PDT) Received: from [192.36.125.221] (dhcp.pilsnet.sunet.se [192.36.125.221]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9LEEjPc014407 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2010 16:14:48 +0200 (CEST) Message-ID: <4CC04AD5.2000700@sunet.se> Date: Thu, 21 Oct 2010 16:14:45 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Sam Hartman References: <4CBCC815.9080402@sunet.se> <4CBF5021.2010404@sunet.se> <4CBFF3FA.8020807@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] Proposed Agenda (v 1) 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: Thu, 21 Oct 2010 14:13:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/21/2010 04:08 PM, Sam Hartman wrote: >>>>>> "Josh" == Josh Howlett writes: > > Josh> Perhaps we could combine the ABFAB Overview slot with the > Josh> Architecture draft discussion slots? One of the purposes of > Josh> the draft, after all, is to provide this kind of overview. It > Josh> may also be useful to get opinions from newbies concerning how > Josh> well the document works for them (or not) while the document > Josh> is still at an early stage of development. Josh. > > > I support this. Regardless of whether we make this specific change I'd > definitely like to see people discuss the architecture document and > would be happy to spend time necessary to make that happen. > > > --Sam OK - I'll rev the published agenda later tonight with this in mind. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzAStEACgkQ8Jx8FtbMZnf4xgCfTQgW0skZZsn/o9phKyMgYVN7 lOoAoKBP4SUHdgkZtGtR0tWusYN8hEES =EI4J -----END PGP SIGNATURE----- From androsadamson@gmail.com Fri Oct 29 12:18:19 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 0E2F13A683A; Fri, 29 Oct 2010 12:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 QGq-1nWP9W2S; Fri, 29 Oct 2010 12:18:18 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id F2CF03A6821; Fri, 29 Oct 2010 12:18:17 -0700 (PDT) Received: by iwn40 with SMTP id 40so4297653iwn.31 for ; Fri, 29 Oct 2010 12:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=GKzIlCQ9CZ8dgnxr/zmkPBuNRrR9FCzoTcmBUCP8AKc=; b=eKhqjA7s/l7OYkU5kWjIiS9b5yJuEIzZ+l3r9QelC3j7F2WkkkeMRydxKOpiw5TntG cwCM2dvKzqFs2N/ZfoKcQIgf5wHgVISxroy4eGLYWsSrfS30U9p19uU0nmwKMyExTb1E oLtMLBLBtX2a6RsxSh8jrqv481tn9BqUdMrtQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=LYRNtf9lWUI4aAo4OlCXASmFRV8Gb3rpal54gL+pXSqi6s+tZTAphIwe2Rl+WBPP2S LJPDlKOl8KRpNf66ZMmKMppzzbo7rTv5OlCmLFcSfO8MB0sgFZzPmz59tBEPBJNLNWDc HArmPHNF3Ikwhs/b0AzMr4eQoZrvxxqoKJoI0= MIME-Version: 1.0 Received: by 10.231.167.146 with SMTP id q18mr3148670iby.163.1288380012190; Fri, 29 Oct 2010 12:20:12 -0700 (PDT) Received: by 10.220.177.67 with HTTP; Fri, 29 Oct 2010 12:20:12 -0700 (PDT) Date: Fri, 29 Oct 2010 15:20:12 -0400 Message-ID: From: "William A. (Andy) Adamson" To: Spencer Shepler Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 30 Oct 2010 03:51:56 -0700 Cc: ietf-krb-wg@lists.anl.gov, abfab@ietf.org, Jeffrey Hutzelman , NFSv4 Subject: [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: Fri, 29 Oct 2010 19:18:19 -0000 The initial focus of draft-adamson-nfsv4-multi-domain-access was to address the name resolution issues presented by a multi domain NFSv4 file name space; describing methods by which NFSv4 clients and servers can handle principals, users, groups from multiple administrative domains. This work is driven by the federated file system drafts coming to completion in the NFSv4 WG and a desire for a way forward for multi domain federated name spaces. As the work progressed, it has become clear that this work applies to a broader set of protocols - SMB and WebFS to name a few. It might also apply to the federations and use cases that ABFAB WG services, and has some significant cross over with the general PAC work from Simo Sorce, draft-sorce-krbwg-general-pac.00.txt. At the end of the day, we want to ensure that this draft not only is not in conflict with any ABFAB or other drafts, but that the drafts are usable together even if each piece can also be used independently of the other. The question is: which working group is best to move this draft forward, and how do we ensure (no matter which working group takes on the task) that all the work each WG does complements each other. I note that the federated file system drafts that the NFSv4 working group has successfully moved to completion have a similar issue in that the technology also applies to non-NFS protocols. If the NFSv4 working group is willing, I vote for draft-adamson-nfsv4-multi-domain-access to be an NFSv4 WG item. draft-sorce-krbwg-general-pac-00.txt describes a general PAC for Kerberos which includes global identities applicable to cross-realm. There have been discussions on the krb-wg list concerning the two drafts. draft-adamson-nfsv4-multi-domain-access-03.txt talks about PACs but does not specify one, and is independent of the authorization mechanisms. Our draft describes name and authorization context resolution in a federated environment. The ABFAB charter initial focus is on describing a federated identity (GSS-API) mechanism that will include resolution of federated attributes, but (correct me if I'm wrong) no name resolution. I am giving a very high-level 10min talk on draft-adamson-nfsv4-multi-domain-access-03.txt in Beijing at the NFSv4 WG morning session Tuesday November 9th, and I invite your participation. Unfortunately KITTEN meets at the same time as NFSv4. Perhaps we could schedule a few minutes at either ABFAB or KRB-WG? Or find another time to talk? -->Andy From hartmans@painless-security.com Sun Oct 31 12:18:18 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 755F93A6A04; Sun, 31 Oct 2010 12:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599, 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 N5LGY3RlZgTf; Sun, 31 Oct 2010 12:18:17 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 9154F3A6944; Sun, 31 Oct 2010 12:18:17 -0700 (PDT) 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 522C1202E8; Sun, 31 Oct 2010 15:20:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6D0634129; Sun, 31 Oct 2010 15:20:09 -0400 (EDT) From: Sam Hartman To: "William A. \(Andy\) Adamson" References: Date: Sun, 31 Oct 2010 15:20:09 -0400 In-Reply-To: (William A. Adamson's message of "Fri, 29 Oct 2010 15:20:12 -0400") 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: Spencer Shepler , ietf-krb-wg@lists.anl.gov, abfab@ietf.org, NFSv4 , Jeffrey Hutzelman 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: Sun, 31 Oct 2010 19:18:18 -0000 Here's my $0.02 worth on how best to move forward your draft and to involve other people. 1) NFSV4 should drive the effort. Why? You have a real-world constrained use case. Having such a driver makes projects complete more rapidly and helps tie-break questions about scope expansion. 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. 3) Any specification of a PAC or other Kerberos authorization data should happen in krb-wg. So, it's fine for this draft to reference a PAC, or to describe needs for a PAC. However the actual Kerberos work should happen in krb-wg. 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. Anyway, I've briefly examined your draft, and it seems like a good start on a really critical issue. From leifj@sunet.se Sun Oct 31 15:03:53 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 E7CF13A67D6 for ; Sun, 31 Oct 2010 15:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 GHBYHQGKTBk2 for ; Sun, 31 Oct 2010 15:03:52 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 87A8C3A67D3 for ; Sun, 31 Oct 2010 15:03:52 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9VM5htL001981 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 31 Oct 2010 23:05:45 +0100 (CET) Message-ID: <4CCDE837.2050406@sunet.se> Date: Sun, 31 Oct 2010 23:05:43 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: abfab@ietf.org, Andy Adamson References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sun, 31 Oct 2010 22:03:54 -0000 -----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. > > 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 leifj@sunet.se Sun Oct 31 15:15:49 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 C091C3A67E6 for ; Sun, 31 Oct 2010 15:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 rzJekRyq67AY for ; Sun, 31 Oct 2010 15:15:48 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id D07843A67D9 for ; Sun, 31 Oct 2010 15:15:47 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o9VMHig1023017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 31 Oct 2010 23:17:46 +0100 (CET) Message-ID: <4CCDEB08.3020007@sunet.se> Date: Sun, 31 Oct 2010 23:17:44 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: abfab@ietf.org, Andy Adamson References: <4CCDE837.2050406@sunet.se> In-Reply-To: <4CCDE837.2050406@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Sun, 31 Oct 2010 22:15:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > There is an LDAP directory for that sort of stuff - the IESG will give > you guidance. That should have been "LDAP Directorate" (a set of expert reviewers of all things LDAP) - funny how the mind slips up sometimes. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzN6wgACgkQ8Jx8FtbMZneN+ACeLO8czTU+gOWikFQ3+zux4va+ pXQAn3s56sEgBXpQP+N01kEeEmBxagwW =jQlR -----END PGP SIGNATURE----- From Nicolas.Williams@oracle.com Sun Oct 31 21:45: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 6B9853A6852; Sun, 31 Oct 2010 21:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 4J9E3RfRrZPc; Sun, 31 Oct 2010 21:45:38 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 871813A6888; Sun, 31 Oct 2010 21:45:35 -0700 (PDT) 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 oA14jTmZ003935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Nov 2010 04:45:31 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA14MrbF010355; Mon, 1 Nov 2010 04:45:28 GMT Received: from abhmt017.oracle.com by acsmt355.oracle.com with ESMTP id 735842331288586710; Sun, 31 Oct 2010 21:45:10 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 31 Oct 2010 21:45:09 -0700 Date: Sun, 31 Oct 2010 23:45:05 -0500 From: Nicolas Williams To: Sam Hartman Message-ID: <20101101044505.GY6536@oracle.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2010-03-02) Cc: abfab@ietf.org, NFSv4 , Spencer Shepler , ietf-krb-wg@lists.anl.gov, "William A. \(Andy\) Adamson" , Jeffrey Hutzelman 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 04:45:39 -0000 On Sun, Oct 31, 2010 at 03:20:09PM -0400, Sam Hartman wrote: > Here's my $0.02 worth on how best to move forward your draft and to > involve other people. Thank you Sam, I agree completely with all that you've said. I was wondering if the ABFAB community would find the focus on LDAP to be objectionable. You would have said stated such an objection if you'd had it, but others might still... Should that happen I suppose we could generalize the document to include the use of SAML for name services as an option, just as we hear that we need to allow for certain options (e.g., non-standard base DN forms). We still need to hear from others, but it's looking like the next step is to make sure that this work falls in the NFSv4 WG charter, either by interpreting the current charter as encompassing it, or, more likely, by seeking to amend the NFSv4 WG charter. Thanks again, Nico --