From leifj@mnt.se Tue Sep 3 06:17:01 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC87521E8143 for ; Tue, 3 Sep 2013 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0iFKLYnnQUY for ; Tue, 3 Sep 2013 06:16:56 -0700 (PDT) Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3BB21E8140 for ; Tue, 3 Sep 2013 06:16:55 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id r7so2075744bkg.22 for ; Tue, 03 Sep 2013 06:16:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Axh9lVa3paoqATxLnXEx0Ka4otXsrfpQnoXSjCN4M5Y=; b=SO3s+zBNLpjdC1rZ01pAzfo5jc6rR+q09OEy2oUrd78Xy/Xxg23/YL4L0cXrCwWSfG RJsM0pGbCS/lgXDLpLZU7nOd21eKjzp3IWa/la3HL6NtPuNUFJdsecFT+Clg/bBI9f7S s8Dw4PyqcAokNThr1lvMOQ4fK2YfaqpjNLO/EQNtmvYH7imEt75QgmbFQWXe5bvs+czO Z1sEuTdO/TPJAdcbexamR/NZSikTa0dttO/jXcNJ3YzvTwxzstPCjK18WlzPxXBdWOxc Y5r+PLsYINPCKYPjBwhfRvGnP+71hOweVstu2W/qubP8RzmDntB7GdLEs4X22gWcit5a 68hw== X-Gm-Message-State: ALoCoQmhyohBqd5TupJw8l62ATKWrELSmiNpXsWw7xhqIXEN61B8N8/JdJJnXus6Ebp1KSWzbxtz X-Received: by 10.204.62.201 with SMTP id y9mr9179573bkh.23.1378214214231; Tue, 03 Sep 2013 06:16:54 -0700 (PDT) Received: from [10.87.167.5] ([88.128.80.6]) by mx.google.com with ESMTPSA id d8sm4604587bkj.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 06:16:53 -0700 (PDT) Message-ID: <5225E13B.7050004@mnt.se> Date: Tue, 03 Sep 2013 15:16:43 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: abfab@ietf.org References: <51F7E114.2090707@sunet.se> In-Reply-To: <51F7E114.2090707@sunet.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] WGLC for draft-ietf-abfab-arch-07.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 03 Sep 2013 13:17:02 -0000 On 07/30/2013 05:51 PM, Leif Johansson wrote: > This message starts a Working-Group Last Call for > draft-ietf-abfab-arch-07.txt > ending on the 20/8. Provide your comments on this draft before that date. > > The WGLC is now past (and then some). We'll progress it up the stack presently. From hartmans@mit.edu Wed Sep 4 06:04:26 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9835321E80C2 for ; Wed, 4 Sep 2013 06:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrRpmFywwmxR for ; Wed, 4 Sep 2013 06:04:20 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A145721E80B7 for ; Wed, 4 Sep 2013 06:04:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5025C2031B for ; Wed, 4 Sep 2013 09:04:17 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sglL9JOGgcwb for ; Wed, 4 Sep 2013 09:04:17 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Wed, 4 Sep 2013 09:04:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 021F687FA8; Wed, 4 Sep 2013 09:04:18 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 04 Sep 2013 09:04:17 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 13:04:26 -0000 --=-=-= Sent from wrong address. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline X-From-Line: nobody Tue Sep 3 18:04:22 2013 From: Sam Hartman To: abfab@ietf.org Subject: comments on draft-ietf-abfab-arch Date: Tue, 03 Sep 2013 18:04:22 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Lines: 30 Xref: permutation-city misc-mail:40021 MIME-Version: 1.0 My apologies for not getting these out in last call. One of these (the re-authentication section comment) is serious enough that I believe it needs to be resolved prior to sending the document on. Section 1.1.1 old: Typically when considering channel binding new: Typicially when considering both EAP and GSS-API channel binding Later in the white board example channel binding should be GSS-API channel binding Section 2.3.3 This is unlikely to survive IETF last call unchallenged. Section 3.4 old: shared private key new: shared session key Section 2.2.2 refers to sectian 6.1 for a description of GSS-API channel binding; that seems wrong --=-=-=-- From leifj@sunet.se Wed Sep 4 06:10:01 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB521E80CB for ; Wed, 4 Sep 2013 06:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g2MI1oFDRH6 for ; Wed, 4 Sep 2013 06:09:45 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAA821F9F40 for ; Wed, 4 Sep 2013 06:09:44 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r84D9geL010270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 4 Sep 2013 15:09:42 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r84D9daL018711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Sep 2013 15:09:41 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [109.105.104.183] ([109.105.104.183]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for abfab@ietf.org; Wed, 4 Sep 2013 15:09:39 +0200 Message-ID: <52273112.5080301@sunet.se> Date: Wed, 04 Sep 2013 15:09:38 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Kl19G5o - 33082ac5a173 - 20130904 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 13:10:01 -0000 Folks - Can I get some quick feedback on this! From mark@painless-security.com Wed Sep 4 14:09:42 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B11A21F9C7B for ; Wed, 4 Sep 2013 14:09: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOEYI26lhI1V for ; Wed, 4 Sep 2013 14:09:37 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6615811E810F for ; Wed, 4 Sep 2013 14:09:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4C1B32031B for ; Wed, 4 Sep 2013 17:09:33 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ5D1eIOg3aU for ; Wed, 4 Sep 2013 17:09:32 -0400 (EDT) Received: from [127.0.0.1] (unknown [10.1.10.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: mark@mail.suchdamage.org) by mail.painless-security.com (Postfix) with ESMTPSA for ; Wed, 4 Sep 2013 17:09:32 -0400 (EDT) Message-ID: <5227A18B.8070007@painless-security.com> Date: Wed, 04 Sep 2013 17:09:31 -0400 From: Mark Donnelly User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [abfab] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 04 Sep 2013 21:09:43 -0000 Hello all! I work with Sam, who asked me to read the arch draft as background to implementing some software around ABFAB. * Section 1.1.1 (Channel Binding) mentions "the authenticator" without referencing that anywhere earlier. Sam tells me that is the EAP term for what ABFAB calls the RP, but that's not included in the table in section 1.1. * In section 1.2, it would be nice for a break to be inserted before the ASCII art graph. * Also in section 1.2, in the section about Federation, there are two almost identical sentences: The federation relationship is governed by a federation agreement. A federation is governed by a federation agreement. If these say the same thing, one should be removed. If they say different things, then the difference is entirely unclear, and it should be explained. * In section 1.4, points 8, 10, and 12 talk about the Master Session Key. As someone new to this, the MSK was referenced here without any text suggesting why it exists. Perhaps a forward reference to Section 4.2.2 or 5 would help, but there really doesn't seem to be a good explanation in the document. * Section 3.2, in the fourth paragraph, has a sentence saying: The client and the TLS need to share a common trust point for the certificate used in validating the server. "TLS" doesn't make sense to me here at all. * Later in section 3.2 there's a sentence: Even when it is checked, if the trust infrastructure behind the TLS authentication is different from the trust infrastructure behind the GSS-API mutual authentication then confirming the end- points using both trust infrastructures is likely to enhance security. The lead-in to that sentence made me expect the opposite result. In essence, this sentence says, "Even when we do the right thing, the right thing happens." I was expecting one of them to be the wrong thing after a lead-in of "Even when." * Section 3.3, paragraph 8 contains a sentence: When Service Records (SRV) and Naming Authority Pointer (NAPTR) records are used to help find a host that provides a service, the security requirements on the referrals is going to interact with the information used in the service name. The minor quibble here is that the subject (requirements) disagrees in number with the verb (is). My larger difficulty is that I have no idea how security requirements might interact with service name information. * The next sentence: If a host name is returned from the DNS referrals, and the host name is to be validated by GS-EAP, then it makes sense that the referrals themselves should be secure. This sentence establishes the need for secure referrals, but nothing is said about how that is to be achieved. Also, the typo of "GS-EAP" should be corrected to "GSS-EAP." * The last sentence of section 3.4 has a typo - 'probably' should be 'probable.' Thanks, --Mark Donnelly From ietf@augustcellars.com Wed Sep 4 21:51:33 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7D21E8095 for ; Wed, 4 Sep 2013 21:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.476 X-Spam-Level: X-Spam-Status: No, score=-3.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Hxfq3qRN5Oo for ; Wed, 4 Sep 2013 21:51:23 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 12B0B21E805D for ; Wed, 4 Sep 2013 21:51:22 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 8AF522CA5A; Wed, 4 Sep 2013 21:51:21 -0700 (PDT) From: "Jim Schaad" To: "'Leif Johansson'" , References: <52273112.5080301@sunet.se> In-Reply-To: <52273112.5080301@sunet.se> Date: Wed, 4 Sep 2013 21:50:11 -0700 Message-ID: <040001cea9f3$67f9bc10$37ed3430$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNh8/g/3Dn/OsA74DmeXHbDLNwJ4gIA7Hqiln/3boA= Content-Language: en-us Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 05 Sep 2013 04:51:34 -0000 It will probably be Sunday before I get to this. > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Leif Johansson > Sent: Wednesday, September 04, 2013 6:10 AM > To: abfab@ietf.org > Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch > > Folks - Can I get some quick feedback on this! > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@sunet.se Thu Sep 5 12:46:03 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6130811E8200 for ; Thu, 5 Sep 2013 12:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QukS+43qtFzm for ; Thu, 5 Sep 2013 12:45:58 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABF911E824D for ; Thu, 5 Sep 2013 12:45:55 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r85JjYLX009476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Sep 2013 21:45:34 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r85JjUpn007139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Sep 2013 21:45:33 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.244] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Thu, 5 Sep 2013 21:45:28 +0200 Message-ID: <5228DF58.3030206@sunet.se> Date: Thu, 05 Sep 2013 21:45:28 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: abfab@ietf.org, Jim Schaad References: <5227A18B.8070007@painless-security.com> In-Reply-To: <5227A18B.8070007@painless-security.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09KlvJynO - 643088d21151 - 20130905 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 05 Sep 2013 19:46:03 -0000 On 09/04/2013 11:09 PM, Mark Donnelly wrote: > Hello all! > > I work with Sam, who asked me to read the arch draft as background to > implementing some software around ABFAB. As usual its preferable to get good reviews *before* WGLC but I guess we'll not stand on form. Jim - your views? > > * Section 1.1.1 (Channel Binding) mentions "the authenticator" without > referencing that anywhere earlier. Sam tells me that is the EAP term > for what ABFAB calls the RP, but that's not included in the table in > section 1.1. > * In section 1.2, it would be nice for a break to be inserted before > the ASCII art graph. > * Also in section 1.2, in the section about Federation, there are two > almost identical sentences: > The federation relationship is governed by a federation agreement. > A federation is governed by a federation agreement. > If these say the same thing, one should be removed. If they say > different things, then the difference is entirely unclear, and it > should be explained. > * In section 1.4, points 8, 10, and 12 talk about the Master Session > Key. As someone new to this, the MSK was referenced here without any > text suggesting why it exists. Perhaps a forward reference to > Section 4.2.2 or 5 would help, but there really doesn't seem to be a > good explanation in the document. > * Section 3.2, in the fourth paragraph, has a sentence saying: > The client and the TLS need to share a common trust point for the > certificate used in validating the server. > "TLS" doesn't make sense to me here at all. > * Later in section 3.2 there's a sentence: > Even when it is checked, if the trust infrastructure behind > the TLS authentication is different from the trust infrastructure > behind the GSS-API mutual authentication then confirming the end- > points using both trust infrastructures is likely to enhance > security. > The lead-in to that sentence made me expect the opposite result. In > essence, this sentence says, "Even when we do the right thing, the > right thing happens." I was expecting one of them to be the wrong > thing after a lead-in of "Even when." > * Section 3.3, paragraph 8 contains a sentence: > When Service Records (SRV) and Naming > Authority Pointer (NAPTR) records are used to help find a host that > provides a service, the security requirements on the referrals is > going to interact with the information used in the service name. > The minor quibble here is that the subject (requirements) disagrees > in number with the verb (is). My larger difficulty is that I have no > idea how security requirements might interact with service name > information. > * The next sentence: > If a host name is returned from the DNS referrals, and the host > name is to be validated by GS-EAP, then it makes sense that the > referrals themselves should be secure. > This sentence establishes the need for secure referrals, but nothing > is said about how that is to be achieved. > Also, the typo of "GS-EAP" should be corrected to "GSS-EAP." > * The last sentence of section 3.4 has a typo - 'probably' should be > 'probable.' > > Thanks, > --Mark Donnelly > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@sunet.se Mon Sep 9 00:57:19 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2769A21F880F for ; Mon, 9 Sep 2013 00:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.35 X-Spam-Level: X-Spam-Status: No, score=0.35 tagged_above=-999 required=5 tests=[HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj2o0fj8ZPt5 for ; Mon, 9 Sep 2013 00:57:06 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id 8B04011E818C for ; Mon, 9 Sep 2013 00:57:04 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r897v3DB001132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 9 Sep 2013 09:57:03 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r897v0kY012456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Sep 2013 09:57:03 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.244] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for abfab@ietf.org; Mon, 9 Sep 2013 09:56:59 +0200 Message-ID: <522D7F4A.4080903@sunet.se> Date: Mon, 09 Sep 2013 09:56:58 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: abfab@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 0aKmTV310 - 435e2a6fb507 - 20130909 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [abfab] meeting in Vancouver X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 07:57:19 -0000 Does the WG want/need to meet in Vancouver? Pls consider this a call for agenda items! Cheers Leif From hartmans@painless-security.com Mon Sep 9 10:30:37 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CD721E808D for ; Mon, 9 Sep 2013 10:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.386 X-Spam-Level: X-Spam-Status: No, score=0.386 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, NO_DNS_FOR_FROM=1.496] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tti+PH8pcId3 for ; Mon, 9 Sep 2013 10:30:31 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B1E6721F9D96 for ; Mon, 9 Sep 2013 10:30:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C96C62021D; Mon, 9 Sep 2013 13:30:09 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKVJLQ4QqE7J; Mon, 9 Sep 2013 13:30:07 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (ma70536d0.tmodns.net [208.54.5.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 9 Sep 2013 13:30:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D570187FE3; Mon, 9 Sep 2013 13:30:18 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <522D7F4A.4080903@sunet.se> Date: Mon, 09 Sep 2013 13:30:18 -0400 In-Reply-To: <522D7F4A.4080903@sunet.se> (Leif Johansson's message of "Mon, 09 Sep 2013 09:56:58 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] meeting in Vancouver X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 17:30:37 -0000 Well, It's possible we won't be done with aa-saml by then. I do have one new agenda item. Several of us were discussing the privacy implications of passive attacks on the network. We thought it might be valuable to add a DH key agreement to gss-eap.. Linus said he'd be interested in working on such a draft; I suspect he could find help. Seo. So, perhaps we could discuss whether this is worth doing and review a proposal? --Sam From leifj@sunet.se Mon Sep 9 10:36:41 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7D711E810E for ; Mon, 9 Sep 2013 10:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.95 X-Spam-Level: X-Spam-Status: No, score=-0.95 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SBO19gFtQdO for ; Mon, 9 Sep 2013 10:36:35 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 76CBA11E8115 for ; Mon, 9 Sep 2013 10:36:33 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r89HaHs0029260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 9 Sep 2013 19:36:17 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r89HaEKp019803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Sep 2013 19:36:16 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.244] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)); Mon, 9 Sep 2013 19:36:12 +0200 Message-ID: <522E070B.8070505@sunet.se> Date: Mon, 09 Sep 2013 19:36:11 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: <522D7F4A.4080903@sunet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09Kn5Ahvw - bf12579bd857 - 20130909 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: abfab@ietf.org Subject: Re: [abfab] meeting in Vancouver X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 09 Sep 2013 17:36:42 -0000 On 09/09/2013 07:30 PM, Sam Hartman wrote: > Well, It's possible we won't be done with aa-saml by then. > > I do have one new agenda item. > Several of us were discussing the privacy implications of passive > attacks on the network. We thought it might be valuable to add a DH key > agreement to gss-eap.. > Linus said he'd be interested in working on such a draft; I suspect he > could find help. > Seo. > So, perhaps we could discuss whether this is worth doing and review a > proposal? > > --Sam OK it sounds like we might have stuff to work on... I'll request 90 minutes. From Smith@cardiff.ac.uk Tue Sep 10 01:03:52 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF05B21E813D for ; Tue, 10 Sep 2013 01:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yA66MzkMxEOK for ; Tue, 10 Sep 2013 01:03:48 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lp0079.outbound.protection.outlook.com [213.199.154.79]) by ietfa.amsl.com (Postfix) with ESMTP id BC42E21E8147 for ; Tue, 10 Sep 2013 01:03:46 -0700 (PDT) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) with Microsoft SMTP Server (TLS) id 15.0.745.25; Tue, 10 Sep 2013 08:03:39 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.38]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.176]) with mapi id 15.00.0745.000; Tue, 10 Sep 2013 08:03:39 +0000 From: Rhys Smith To: Leif Johansson Thread-Topic: [abfab] meeting in Vancouver Thread-Index: AQHOrTJC/FCS0UuoSUG+s/DM87BSPZm+nhsA Date: Tue, 10 Sep 2013 08:03:38 +0000 Message-ID: <9E47732E-43FD-4100-BE57-BB11B2929404@cardiff.ac.uk> References: <522D7F4A.4080903@sunet.se> In-Reply-To: <522D7F4A.4080903@sunet.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [2001:470:1f09:8c6:411a:8cfc:5911:ca7e] x-forefront-prvs: 096507C068 x-forefront-antispam-report: SFV:NSPM; SFS:(24454002)(252514010)(199002)(189002)(4396001)(50986001)(76786001)(76796001)(47976001)(49866001)(47736001)(56816003)(65816001)(16236675002)(77096001)(74706001)(31966008)(80022001)(47446002)(74662001)(74482001)(80976001)(69226001)(51856001)(53806001)(54356001)(63696002)(83322001)(82746002)(76482001)(59766001)(54316002)(56776001)(79102001)(74502001)(77982001)(19580405001)(19580395003)(74366001)(81542001)(36756003)(46102001)(81342001)(33656001)(81686001)(74876001)(81816001)(83072001)(3826001)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR02MB022; H:AMSPR02MB022.eurprd02.prod.outlook.com; CLIP:2001:470:1f09:8c6:411a:8cfc:5911:ca7e; RD:InfoNoRecords; A:1; MX:3; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_DEE1A9D9-BE77-4CEB-8FA2-CC9B2AB8E5D0"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: cardiff.ac.uk Cc: "" Subject: Re: [abfab] meeting in Vancouver X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2013 08:03:52 -0000 --Apple-Mail=_DEE1A9D9-BE77-4CEB-8FA2-CC9B2AB8E5D0 Content-Type: multipart/alternative; boundary="Apple-Mail=_DEA0534F-D89C-4222-923A-E693E12356DF" --Apple-Mail=_DEA0534F-D89C-4222-923A-E693E12356DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Also, I'll be posting an updated UI draft in the next couple of days = (bit longer than hoped due to holidays, but I'm getting there). Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C On 9 Sep 2013, at 08:56, Leif Johansson wrote: >=20 >=20 > Does the WG want/need to meet in Vancouver? Pls consider this a > call for agenda items! >=20 > Cheers Leif >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --Apple-Mail=_DEA0534F-D89C-4222-923A-E693E12356DF Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Also, I'll be posting an updated UI draft in the next couple of days (bit longer than hoped due to holidays, but I'm getting there).

Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet - the UK's research and education network

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: 0xDE2F024C



On 9 Sep 2013, at 08:56, Leif Johansson <leifj@sunet.se> wrote:



Does the WG want/need to meet in Vancouver? Pls consider this a
call for agenda items!

       Cheers Leif

_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab

--Apple-Mail=_DEA0534F-D89C-4222-923A-E693E12356DF-- --Apple-Mail=_DEE1A9D9-BE77-4CEB-8FA2-CC9B2AB8E5D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlIu0lgACgkQ3fEsO94vAkwf1gCghwmQQeNG3DuX432CXJwC7qTq VZ4AmweFP5obbmM/8Ip9Aeszx68JeAhk =6Kmr -----END PGP SIGNATURE----- --Apple-Mail=_DEE1A9D9-BE77-4CEB-8FA2-CC9B2AB8E5D0-- From leifj@mnt.se Tue Sep 17 23:37:24 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A5011E8145 for ; Tue, 17 Sep 2013 23:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJfpikvex+Mz for ; Tue, 17 Sep 2013 23:37:20 -0700 (PDT) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id C743111E8180 for ; Tue, 17 Sep 2013 23:37:19 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id a15so3240026eae.9 for ; Tue, 17 Sep 2013 23:37:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GwjH+9tqdWhytlVUq6cDeJEb0tVDaID+EWeqLxnqulg=; b=M2hSAxi66LDsUR8wwg9oaf8rmJgWr8wT1rwQGegSnEU36HM04Mom+aLa6/UnaWQlUR /QQqaPjqV+2RDcEXMXnEi9huqvkovzcfZAwMpHAVGQfaeV9g66vSFCNiTzbRpJg5wzMk /77YbL0oZSqgQcaqZws4dEX/lRcBOZWBWQQO31jiWNCbjO8EAAvRWLcU5o2Uc57wybCE 7uFLRjYXd3Y4EAxVAV5Ug7uzw2kocemEokGutfeHgN+jI+xNrbYA+8dooiYjExdddJqi UL4RMqMxym1tX/ghqPnuj+hIxHx6HpNCJVrhVNYmhAXptZD6ENTyQ1By1Vh1GRcEK/dT mcng== X-Gm-Message-State: ALoCoQnYMhfBAZOWRHNJYvG1/CpsWMM8YwhSw0s+jYK+A+B46OXlNNfpsXiBB6sEnOwZNUpfaKPz X-Received: by 10.15.98.194 with SMTP id bj42mr57226851eeb.12.1379486238507; Tue, 17 Sep 2013 23:37:18 -0700 (PDT) Received: from [109.105.104.183] (dhcp49.se-tug.nordu.net. [109.105.104.183]) by mx.google.com with ESMTPSA id h52sm140815eez.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 23:37:17 -0700 (PDT) Message-ID: <52394A1B.10805@mnt.se> Date: Wed, 18 Sep 2013 08:37:15 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: abfab@ietf.org, Jim Schaad References: <5227A18B.8070007@painless-security.com> <5228DF58.3030206@sunet.se> In-Reply-To: <5228DF58.3030206@sunet.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 06:37:24 -0000 On 09/05/2013 09:45 PM, Leif Johansson wrote: > On 09/04/2013 11:09 PM, Mark Donnelly wrote: >> Hello all! >> >> I work with Sam, who asked me to read the arch draft as background to >> implementing some software around ABFAB. > As usual its preferable to get good reviews *before* WGLC but I guess > we'll not stand on form. > > Jim - your views? poke... >> * Section 1.1.1 (Channel Binding) mentions "the authenticator" without >> referencing that anywhere earlier. Sam tells me that is the EAP term >> for what ABFAB calls the RP, but that's not included in the table in >> section 1.1. >> * In section 1.2, it would be nice for a break to be inserted before >> the ASCII art graph. >> * Also in section 1.2, in the section about Federation, there are two >> almost identical sentences: >> The federation relationship is governed by a federation agreement. >> A federation is governed by a federation agreement. >> If these say the same thing, one should be removed. If they say >> different things, then the difference is entirely unclear, and it >> should be explained. >> * In section 1.4, points 8, 10, and 12 talk about the Master Session >> Key. As someone new to this, the MSK was referenced here without any >> text suggesting why it exists. Perhaps a forward reference to >> Section 4.2.2 or 5 would help, but there really doesn't seem to be a >> good explanation in the document. >> * Section 3.2, in the fourth paragraph, has a sentence saying: >> The client and the TLS need to share a common trust point for the >> certificate used in validating the server. >> "TLS" doesn't make sense to me here at all. >> * Later in section 3.2 there's a sentence: >> Even when it is checked, if the trust infrastructure behind >> the TLS authentication is different from the trust infrastructure >> behind the GSS-API mutual authentication then confirming the end- >> points using both trust infrastructures is likely to enhance >> security. >> The lead-in to that sentence made me expect the opposite result. In >> essence, this sentence says, "Even when we do the right thing, the >> right thing happens." I was expecting one of them to be the wrong >> thing after a lead-in of "Even when." >> * Section 3.3, paragraph 8 contains a sentence: >> When Service Records (SRV) and Naming >> Authority Pointer (NAPTR) records are used to help find a host that >> provides a service, the security requirements on the referrals is >> going to interact with the information used in the service name. >> The minor quibble here is that the subject (requirements) disagrees >> in number with the verb (is). My larger difficulty is that I have no >> idea how security requirements might interact with service name >> information. >> * The next sentence: >> If a host name is returned from the DNS referrals, and the host >> name is to be validated by GS-EAP, then it makes sense that the >> referrals themselves should be secure. >> This sentence establishes the need for secure referrals, but nothing >> is said about how that is to be achieved. >> Also, the typo of "GS-EAP" should be corrected to "GSS-EAP." >> * The last sentence of section 3.4 has a typo - 'probably' should be >> 'probable.' >> >> Thanks, >> --Mark Donnelly >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Sun Sep 22 14:40:24 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E06D11E815A for ; Sun, 22 Sep 2013 14:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1dPRHSeUjaE for ; Sun, 22 Sep 2013 14:40:19 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id DCF1211E8153 for ; Sun, 22 Sep 2013 14:40:19 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id EDE012CA33; Sun, 22 Sep 2013 14:40:12 -0700 (PDT) From: "Jim Schaad" To: "'Mark Donnelly'" , References: <5227A18B.8070007@painless-security.com> In-Reply-To: <5227A18B.8070007@painless-security.com> Date: Sun, 22 Sep 2013 14:39:00 -0700 Message-ID: <051501ceb7dc$27218780$75649680$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG9m1Xx6F+j87XIjIlccCQb2ouNLZnuZ6Gw Content-Language: en-us Subject: Re: [abfab] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 22 Sep 2013 21:40:24 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Mark Donnelly > Sent: Wednesday, September 04, 2013 2:10 PM > To: abfab@ietf.org > Subject: [abfab] comments on draft-ietf-abfab-arch > > Hello all! > > I work with Sam, who asked me to read the arch draft as background to > implementing some software around ABFAB. > > * Section 1.1.1 (Channel Binding) mentions "the authenticator" without > referencing that anywhere earlier. Sam tells me that is the EAP term > for what ABFAB calls the RP, but that's not included in the table in > section 1.1. I have put EAP Authenticator into the table and inserted EAP in front of the word authenticator in the four places it occurs > * In section 1.2, it would be nice for a break to be inserted before > the ASCII art graph. Generally page breaks are dealt with during final editing by the RFC editor - we will make sure that the image is on one page at that point in time. > * Also in section 1.2, in the section about Federation, there are two > almost identical sentences: > The federation relationship is governed by a federation agreement. > A federation is governed by a federation agreement. > If these say the same thing, one should be removed. If they say > different things, then the difference is entirely unclear, and it > should be explained. Yeah - I have deleted the second sentence > * In section 1.4, points 8, 10, and 12 talk about the Master Session > Key. As someone new to this, the MSK was referenced here without any > text suggesting why it exists. Perhaps a forward reference to > Section 4.2.2 or 5 would help, but there really doesn't seem to be a > good explanation in the document. Would this change fix the problem for you? Old: As a result, the client and the IdP hold two cryptographic keys: a Master Session Key (MSK), and an Extended MSK (EMSK). New: The EAP authentication process also results in both the client and the IdP having two cryptographic keys: a Master Session Key (MSK) and an Extended MSK (EMSK). (EAP methods which do not derive an MSK cannot be used with ABFAB.) > * Section 3.2, in the fourth paragraph, has a sentence saying: > The client and the TLS need to share a common trust point for the > certificate used in validating the server. > "TLS" doesn't make sense to me here at all. Should be TLS server > * Later in section 3.2 there's a sentence: > Even when it is checked, if the trust infrastructure behind > the TLS authentication is different from the trust infrastructure > behind the GSS-API mutual authentication then confirming the end- > points using both trust infrastructures is likely to enhance > security. > The lead-in to that sentence made me expect the opposite result. In > essence, this sentence says, "Even when we do the right thing, the > right thing happens." I was expecting one of them to be the wrong > thing after a lead-in of "Even when." The sentence now starts When the TLS authentication is checked, ... Does that address your concern? > * Section 3.3, paragraph 8 contains a sentence: > When Service Records (SRV) and Naming > Authority Pointer (NAPTR) records are used to help find a host that > provides a service, the security requirements on the referrals is > going to interact with the information used in the service name. > The minor quibble here is that the subject (requirements) disagrees > in number with the verb (is). My larger difficulty is that I have no > idea how security requirements might interact with service name > information. > * The next sentence: > If a host name is returned from the DNS referrals, and the host > name is to be validated by GS-EAP, then it makes sense that the > referrals themselves should be secure. > This sentence establishes the need for secure referrals, but nothing > is said about how that is to be achieved. > Also, the typo of "GS-EAP" should be corrected to "GSS-EAP." > * The last sentence of section 3.4 has a typo - 'probably' should be > 'probable.' Does the following replacement paragraph address your concerns? Applications may retrieve information about providers of services from DNS. Service Records (SRV) and Naming Authority Pointer (NAPTR) records are used to help find a host that provides a service, however the necessity of having DNSSEC on the queries depends on how the information is going to be used. If the host name returned is not going to be validated by EAP channel binding, because only the service is being validated, then DNSSEC is not required. However, if the host name is going to be validated by EAP channel binding then DNSSEC needs to be used to ensure that the correct host name is validated. In general, if the information that is returned from the DNS query is to be validated, then it needs to be obtained in a secure manner. Jim > > Thanks, > --Mark Donnelly > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Sun Sep 22 21:22:28 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1A921F9CA4 for ; Sun, 22 Sep 2013 21:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=1.382, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnIqlJ6mw8OK for ; Sun, 22 Sep 2013 21:22:23 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 071FD11E80D2 for ; Sun, 22 Sep 2013 21:22:23 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id C37F738F2B; Sun, 22 Sep 2013 21:22:21 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Sun, 22 Sep 2013 21:21:08 -0700 Message-ID: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNh8/g/3Dn/OsA74DmeXHbDLNwJ4palrxmg Content-Language: en-us Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 04:22:28 -0000 My apologies for not getting these out in last call. One of these (the re-authentication section comment) is serious enough that I believe it needs to be resolved prior to sending the document on. Section 1.1.1 old: Typically when considering channel binding new: Typicially when considering both EAP and GSS-API channel binding [JLS] done Later in the white board example channel binding should be GSS-API channel binding [JLS] I don't understand this. The two sentences which talk about the whiteboard do not have the phrase channel binding in them. The next sentence would seem to apply to either GSS-API or EAP channel binding. Which sentence did you think should be changed? Section 2.3.3 This is unlikely to survive IETF last call unchallenged. [JLS] Quite correct - this should say - please present your authentication token ... There are circumstances where the server will want to have the client re-authenticate itself. These include very long sessions, where the original authentication is time limited or cases where in order to complete an operation a different authentication is required. GSS-EAP does not have any mechanism for the server to initiate a re-authentication as all authentication operation start from the client. If a protocol using GSS-EAP needs to support re-authentication that is initiated by the server, then a request from the server to the client for the re-authentication to start needs to be placed in the protocol. Clients can re-use the existing secure connection established by GSS-API to run the new authentication in by calling GSS_Init_sec_context. At this point a full re-authentication will be done. What do you think needs to be added to this? Section 3.4 old: shared private key new: shared session key [JLS] - Fixed Section 2.2.2 refers to sectian 6.1 for a description of GSS-API channel binding; that seems wrong [JLS] Section 6 has disappeared - so I am killing that portion of the section. > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, September 04, 2013 6:04 AM > To: abfab@ietf.org > Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch > > Sent from wrong address. > From d.w.chadwick@kent.ac.uk Sun Sep 22 23:48:33 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882F411E81AC for ; Sun, 22 Sep 2013 23:48:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azD6Y292fkrW for ; Sun, 22 Sep 2013 23:48:28 -0700 (PDT) Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by ietfa.amsl.com (Postfix) with ESMTP id 81FB511E81A7 for ; Sun, 22 Sep 2013 23:48:24 -0700 (PDT) Received: from 252.1.125.91.dyn.plus.net ([91.125.1.252] helo=[192.168.1.68]) by mx3.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1VNzwQ-0007KP-Kc; Mon, 23 Sep 2013 07:48:18 +0100 Message-ID: <523FE430.4040106@kent.ac.uk> Date: Mon, 23 Sep 2013 07:48:16 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jim Schaad References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> In-Reply-To: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, 'Sam Hartman' Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 06:48:33 -0000 Apologies from me as well Sam, here are my comments on draft-ietf-abfab-arch-07.txt Technical Section 1. i) Data Minimization and User Participation: "There is currently no direct client participation in this decision." (i.e. release of identity attributes). We should say at this juncture that this is a major deficiency in existing federated systems, since the user does not have full consent or control over which of his identity attributes are released. This should be fixed in Abfab ii) Section 1.1.1 Authenticator should be defined before it is used. iii) I dont buy into your whiteboard example of single entity authentication, because a hacked whiteboard could trick the user into opening the wrong file, which could be disasterous during an important business meeting. SO mutual authentication is needed here as well. If you want an example where mutual authentication is not important, its one where either the information being accessed is of very little value to the accessor so that it does not matter if it is erroneous information or not, or one where it does not matter who the accessor is i.e. its public information. Editorials Section 1 the Relying Party know specific -> the Relying Party to know specific Section 1.1 the document uses either a the ABFAB term -> the document uses either the ABFAB term The table should be labelled "Table 1. Terminology" Section 1.4 a SAML Attribute Requests -> a SAML Attribute Request Section 2.1.3 to validate theg identities -> to validate the identities The trust mechanism must to ensure that -> The trust mechanism must ensure that An RP can submit a request directly to a federation. -> An RP can submit a request directly to the correct federation. information about given a IdP -> information about a given IdP regards David On 23/09/2013 05:21, Jim Schaad wrote: > My apologies for not getting these out in last call. > One of these (the re-authentication section comment) is serious enough that > I believe it needs to be resolved prior to sending the document on. > > > Section 1.1.1 > > old: Typically when considering channel binding > > new: > > Typicially when considering both EAP and GSS-API channel binding > > [JLS] done > > Later in the white board example > channel binding should be GSS-API channel binding > > [JLS] I don't understand this. The two sentences which talk about the > whiteboard do not have the phrase channel binding in them. The next > sentence would seem to apply to either GSS-API or EAP channel binding. > Which sentence did you think should be changed? > > Section 2.3.3 > > This is unlikely to survive IETF last call unchallenged. > > [JLS] Quite correct - this should say - please present your authentication > token > > ... > > > There are circumstances where the server will want to have the > client re-authenticate itself. > These include very long sessions, where the original > authentication is time limited or cases where in order to complete an > operation a different authentication is required. > GSS-EAP does not have any mechanism for the server to initiate a > re-authentication as all authentication operation start from the client. > If a protocol using GSS-EAP needs to support re-authentication > that is initiated by the server, then a request from the server to the > client for the re-authentication to start needs to be placed in the > protocol. > > > Clients can re-use the existing secure connection established by > GSS-API to run the new authentication in by calling GSS_Init_sec_context. > At this point a full re-authentication will be done. > > > What do you think needs to be added to this? > > Section 3.4 > > old: shared private key > new: shared session key > > [JLS] - Fixed > > Section 2.2.2 refers to sectian 6.1 for a description of GSS-API channel > binding; that seems wrong > > [JLS] Section 6 has disappeared - so I am killing that portion of the > section. > >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf >> Of Sam Hartman >> Sent: Wednesday, September 04, 2013 6:04 AM >> To: abfab@ietf.org >> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >> >> Sent from wrong address. >> > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Mon Sep 23 05:28:06 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E08D21F9F21 for ; Mon, 23 Sep 2013 05:28:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdQfdwgKFBWQ for ; Mon, 23 Sep 2013 05:27:59 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 935B821F9B60 for ; Mon, 23 Sep 2013 05:27:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id D322920438; Mon, 23 Sep 2013 08:26:55 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBcjmU64KXqc; Mon, 23 Sep 2013 08:26:55 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 23 Sep 2013 08:26:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A3DA48833F; Mon, 23 Sep 2013 08:27:39 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> Date: Mon, 23 Sep 2013 08:27:39 -0400 In-Reply-To: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> (Jim Schaad's message of "Sun, 22 Sep 2013 21:21:08 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, 'Sam Hartman' Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 12:28:06 -0000 >>>>> "Jim" == Jim Schaad writes: > Later in the white board example channel binding should be > GSS-API channel binding Jim> [JLS] I don't understand this. The two sentences which talk Jim> about the whiteboard do not have the phrase channel binding in Jim> them. The next sentence would seem to apply to either GSS-API Jim> or EAP channel binding. Which sentence did you think should be Jim> changed? If channel binding is used without mutual authentication, it is effectively . . . I know thatt statement is true for GSS-API channel binding, and that's certainly what the reasoning in the white-board example applies to. I'll admit that I considered not making the comment because it seems to sort of apply to EAP channel binding. However, mutual authentication in EAP applies to peer confidence that it's talking to the right EAP server. Without that, I'm not sure how EAP channel binding gives you confidence you're disclosing anything in the context of a particular NAS. It's more like it gives you confidence that the NAS would like to be thought of in a particular way. That might be useful but doesn't seem much of a security claim. So, I have confidence in the statement for GSS-API channel binding, but am not at all sure it's true for EAP channel binding. Your text for re-authentication seems good to me. I do have one note about your response to Mark on secure lookups in DNS. Previously the text simply said the lookup needed to be secure. Your replacement text to address Mark's concerns specifically introduces discussion of DNSsec. I'm wondering whether that's proscriptive. I guess it's fine, because if you're actually using the DNS protocol that and tsig are the only ways to secure the lookup. So, I'm OK with the proposed text, but I want to call out that we've refined the semantics somewhat. --Sam From hartmans@painless-security.com Mon Sep 23 05:33:56 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E5D21F9B21 for ; Mon, 23 Sep 2013 05:33: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz7s2tUcKRly for ; Mon, 23 Sep 2013 05:33:46 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4621F99F8 for ; Mon, 23 Sep 2013 05:33:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id BC4322042E; Mon, 23 Sep 2013 08:32:52 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKZVdER0YzJA; Mon, 23 Sep 2013 08:32:52 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 23 Sep 2013 08:32:52 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7D71B8833F; Mon, 23 Sep 2013 08:33:36 -0400 (EDT) From: Sam Hartman To: David Chadwick References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> Date: Mon, 23 Sep 2013 08:33:36 -0400 In-Reply-To: <523FE430.4040106@kent.ac.uk> (David Chadwick's message of "Mon, 23 Sep 2013 07:48:16 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , 'Sam Hartman' , abfab@ietf.org Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 12:33:56 -0000 >>>>> "David" == David Chadwick writes: David> Section 1. i) Data Minimization and User Participation: David> "There is currently no direct client participation in this David> decision." (i.e. release of identity attributes). We should David> say at this juncture that this is a major deficiency in David> existing federated systems, since the user does not have full David> consent or control over which of his identity attributes are David> released. This should be fixed in Abfab I do not support this change. There are some cases where this is a major deficiency, but it's not entirely clear whether fixing this at the ABFAB layer is the right approach. I'd argue that trying to fix the concent problem in a general manner at the federation layer may have done more harm over the years than the privacy problem that is trying to be addressed. David> iii) I dont buy into your whiteboard example of single entity David> authentication, because a hacked whiteboard could trick the David> user into opening the wrong file, which could be disasterous David> during an important business meeting. SO mutual David> authentication is needed here as well. If you want an example David> where mutual authentication is not important, its one where David> either the information being accessed is of very little value David> to the accessor so that it does not matter if it is erroneous David> information or not, or one where it does not matter who the David> accessor is i.e. its public information. Most of the tools I'm familiar with for screen sharing etc would not allow the white board to pick the presentation/file. I'd support adding a comment that you don't want to run UI on the white board, but no I think I completely disagree with your proposed constraints on when this is useful. --Sam From leifj@sunet.se Mon Sep 23 07:05:43 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDA021F9BEF for ; Mon, 23 Sep 2013 07:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6fcm3Bb4gH2s for ; Mon, 23 Sep 2013 07:05:38 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1C921F9A5F for ; Mon, 23 Sep 2013 07:05:36 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8NE5KmZ027394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Sep 2013 16:05:20 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r8NE5HQ0010236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 23 Sep 2013 16:05:20 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.244] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for abfab@ietf.org; Mon, 23 Sep 2013 16:05:16 +0200 Message-ID: <52404A9C.5050803@sunet.se> Date: Mon, 23 Sep 2013 16:05:16 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: abfab@ietf.org References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.495 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09KsC5kjs - 2bb532fd31a4 - 20130923 (trained as not-spam) X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 14:05:43 -0000 On 09/23/2013 02:33 PM, Sam Hartman wrote: >>>>>> "David" == David Chadwick writes: > David> Section 1. i) Data Minimization and User Participation: > David> "There is currently no direct client participation in this > David> decision." (i.e. release of identity attributes). We should > David> say at this juncture that this is a major deficiency in > David> existing federated systems, since the user does not have full > David> consent or control over which of his identity attributes are > David> released. This should be fixed in Abfab > > I do not support this change. > > There are some cases where this is a major deficiency, but it's not > entirely clear whether fixing this at the ABFAB layer is the right > approach. > > I'd argue that trying to fix the concent problem in a general manner at > the federation layer may have done more harm over the years than the > privacy problem that is trying to be addressed. With my chair-switch secured in the OFF position: I agree with Sam 100% here. > > > David> iii) I dont buy into your whiteboard example of single entity > David> authentication, because a hacked whiteboard could trick the > David> user into opening the wrong file, which could be disasterous > David> during an important business meeting. SO mutual > David> authentication is needed here as well. If you want an example > David> where mutual authentication is not important, its one where > David> either the information being accessed is of very little value > David> to the accessor so that it does not matter if it is erroneous > David> information or not, or one where it does not matter who the > David> accessor is i.e. its public information. > > Most of the tools I'm familiar with for screen sharing etc would not > allow the white board to pick the presentation/file. > I'd support adding a comment that you don't want to run UI on the white > board, but no I think I completely disagree with your proposed > constraints on when this is useful. > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From d.w.chadwick@kent.ac.uk Mon Sep 23 13:53:12 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972B821F9DC9 for ; Mon, 23 Sep 2013 13:53:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF8M5iZYhTZ2 for ; Mon, 23 Sep 2013 13:52:58 -0700 (PDT) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id D13A521F9DB0 for ; Mon, 23 Sep 2013 13:52:56 -0700 (PDT) Received: from [197.3.0.25] (helo=[172.16.33.134]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1VOD7g-0002P1-2l; Mon, 23 Sep 2013 21:52:48 +0100 Message-ID: <5240AA1C.3060409@kent.ac.uk> Date: Mon, 23 Sep 2013 21:52:44 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Schaad , 'Sam Hartman' , abfab@ietf.org Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 23 Sep 2013 20:53:14 -0000 Hi Sam On 23/09/2013 13:33, Sam Hartman wrote: >>>>>> "David" == David Chadwick writes: > > David> Section 1. i) Data Minimization and User Participation: > David> "There is currently no direct client participation in this > David> decision." (i.e. release of identity attributes). We should > David> say at this juncture that this is a major deficiency in > David> existing federated systems, since the user does not have full > David> consent or control over which of his identity attributes are > David> released. This should be fixed in Abfab > > I do not support this change. Which change do you not support a) saying that this is a major deficiency in existing federated systems b) saying that Abfab should fix this c) both > > There are some cases where this is a major deficiency, but it's not > entirely clear whether fixing this at the ABFAB layer is the right > approach. So it appears that you support a) but not b). So can you simply add a). > > I'd argue that trying to fix the concent problem in a general manner at > the federation layer may have done more harm over the years than the > privacy problem that is trying to be addressed. Actually in my previous research we fixed this in a layer above the federation layer, which we called the attribute aggregation layer. So I agree that it is best to not fix it in the federation layer. > > > David> iii) I dont buy into your whiteboard example of single entity > David> authentication, because a hacked whiteboard could trick the > David> user into opening the wrong file, which could be disasterous > David> during an important business meeting. SO mutual > David> authentication is needed here as well. If you want an example > David> where mutual authentication is not important, its one where > David> either the information being accessed is of very little value > David> to the accessor so that it does not matter if it is erroneous > David> information or not, or one where it does not matter who the > David> accessor is i.e. its public information. > > Most of the tools I'm familiar with for screen sharing etc would not > allow the white board to pick the presentation/file. Meaning that the user sends an already chosen file to the whiteboard? In which case I agree with you. > I'd support adding a comment that you don't want to run UI on the white > board, but no I think I completely disagree with your proposed > constraints on when this is useful. I would be interested to learn of another generic type of use case where you think that mutual authn is not needed regards David > > --Sam > From hartmans@painless-security.com Mon Sep 23 20:38:53 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CC221F9D39 for ; Mon, 23 Sep 2013 20:38: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zi8Cnrb9ODSE for ; Mon, 23 Sep 2013 20:38:37 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 694D921F9D3A for ; Mon, 23 Sep 2013 20:38:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 307752043C; Mon, 23 Sep 2013 23:12:22 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtpMsU-oPZRb; Mon, 23 Sep 2013 23:12:09 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 23 Sep 2013 23:12:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E62718833F; Mon, 23 Sep 2013 23:12:16 -0400 (EDT) From: Sam Hartman To: David Chadwick References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> <5240AA1C.3060409@kent.ac.uk> Date: Mon, 23 Sep 2013 23:12:16 -0400 In-Reply-To: <5240AA1C.3060409@kent.ac.uk> (David Chadwick's message of "Mon, 23 Sep 2013 21:52:44 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , 'Sam Hartman' , abfab@ietf.org Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 03:38:53 -0000 >>>>> "David" == David Chadwick writes: David> Hi Sam David> On 23/09/2013 13:33, Sam Hartman wrote: >>>>>>> "David" == David Chadwick writes: >> >> >> I do not support this change. David> Which change do you not support a) saying that this is a David> major deficiency in existing federated systems b) saying that David> Abfab should fix this c) both >> I do not support either change. I'd be comfortable adding a statement that the ABFAB architecture does not provide a specific way for the user to inform the IDP about the user's requirements for attribute releases. Whether that's a major deficiency depends on what you're doing. I agree there are cases where it is. >> >> I'd argue that trying to fix the concent problem in a general >> manner at the federation layer may have done more harm over the >> years than the privacy problem that is trying to be addressed. David> Actually in my previous research we fixed this in a layer David> above the federation layer, which we called the attribute David> aggregation layer. So I agree that it is best to not fix it David> in the federation layer. >> >> David> iii) I dont buy into your whiteboard example of single entity David> authentication, because a hacked whiteboard could trick the David> user into opening the wrong file, which could be disasterous David> during an important business meeting. SO mutual David> authentication is needed here as well. If you want an example David> where mutual authentication is not important, its one where David> either the information being accessed is of very little value David> to the accessor so that it does not matter if it is erroneous David> information or not, or one where it does not matter who the David> accessor is i.e. its public information. >> >> Most of the tools I'm familiar with for screen sharing etc would >> not allow the white board to pick the presentation/file. David> Meaning that the user sends an already chosen file to the David> whiteboard? In which case I agree with you. Exactly. So, let's make it clear that it's critical that the user's software not trust input from the white board without mutual authentication. --Sam From Smith@cardiff.ac.uk Tue Sep 24 07:59:46 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE63511E8139 for ; Tue, 24 Sep 2013 07:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaB4eP4IIkLM for ; Tue, 24 Sep 2013 07:59:40 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0015.outbound.protection.outlook.com [213.199.154.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAF111E80E8 for ; Tue, 24 Sep 2013 07:59:39 -0700 (PDT) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB021.eurprd02.prod.outlook.com (10.242.81.145) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 14:59:38 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.175]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.175]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 14:59:37 +0000 From: Rhys Smith To: Sam Hartman Thread-Topic: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch Thread-Index: AQHOuNPfQQkTxyn8N0m0X7zeM48s3ZnU+7YA Date: Tue, 24 Sep 2013 14:59:37 +0000 Message-ID: <628336BC-BDDF-41A3-8A5E-C9F695BBCCC9@cardiff.ac.uk> References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> <5240AA1C.3060409@kent.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.251.148.37] x-forefront-prvs: 09796A1B83 x-forefront-antispam-report: SFV:NSPM; SFS:(252514010)(199002)(189002)(24454002)(36756003)(54356001)(16236675002)(33656001)(56816003)(80022001)(77096001)(74876001)(53806001)(77982001)(81542001)(76796001)(74706001)(79102001)(76786001)(50986001)(76482001)(46102001)(51856001)(83072001)(74662001)(81342001)(59766001)(47446002)(47976001)(65816001)(49866001)(19580405001)(19580395003)(69226001)(63696002)(81816001)(66066001)(83322001)(56776001)(54316002)(74366001)(82746002)(74502001)(80976001)(31966008)(81686001)(47736001)(74482001)(4396001)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR02MB021; H:AMSPR02MB022.eurprd02.prod.outlook.com; CLIP:131.251.148.37; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_86AB45D0-4919-41DB-9872-A5F7FDD577FA"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: cardiff.ac.uk Cc: Jim Schaad , Sam Hartman , "" Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 24 Sep 2013 14:59:46 -0000 --Apple-Mail=_86AB45D0-4919-41DB-9872-A5F7FDD577FA Content-Type: multipart/alternative; boundary="Apple-Mail=_47EF43D8-1E4E-4072-A19F-42D543BC93F3" --Apple-Mail=_47EF43D8-1E4E-4072-A19F-42D543BC93F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 24 Sep 2013, at 04:12, Sam Hartman = wrote: > I do not support either change. > I'd be comfortable adding a statement that the ABFAB architecture does > not provide a specific way for the user to inform the IDP about the > user's requirements for attribute releases. > Whether that's a major deficiency depends on what you're doing. > I agree there are cases where it is. +1. Deficiency is in the eye of the beholder and their use case at that = moment in time. In many cases it happens to be a major problem, but it's = not a fundamental deficiency. Calling out that ABFAB doesn't provide a means for this - and making no = judgement on that fact - seems like a good way to go to me. Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_47EF43D8-1E4E-4072-A19F-42D543BC93F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii hartmans@painless-security.= com> wrote:
I do not support either = change.
I'd be comfortable adding a statement = that the ABFAB architecture does
not provide a specific way = for the user to inform the IDP about the
user's requirements for = attribute releases.
Whether that's a major = deficiency depends on what you're doing.
I agree there are cases where = it is.
Rhys.
--
Dr = Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff = University & Janet - the UK's research and education = network

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

= --Apple-Mail=_47EF43D8-1E4E-4072-A19F-42D543BC93F3-- --Apple-Mail=_86AB45D0-4919-41DB-9872-A5F7FDD577FA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJBqNgACgkQ3fEsO94vAkwR+gCg1Ed+snZ5yn1aD5iUz0CpAgN9 b0IAoKZvHtDxtqNoriikx9vQynnnSTNg =Ni38 -----END PGP SIGNATURE----- --Apple-Mail=_86AB45D0-4919-41DB-9872-A5F7FDD577FA-- From Smith@cardiff.ac.uk Wed Sep 25 10:30:57 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9F0A11E8134 for ; Wed, 25 Sep 2013 10:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLnJySDSsqQD for ; Wed, 25 Sep 2013 10:30:52 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) by ietfa.amsl.com (Postfix) with ESMTP id 89F8A11E812D for ; Wed, 25 Sep 2013 10:30:51 -0700 (PDT) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 25 Sep 2013 17:30:49 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.175]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.175]) with mapi id 15.00.0775.005; Wed, 25 Sep 2013 17:30:49 +0000 From: Rhys Smith To: Jim Schaad Thread-Topic: Comments on draft-smith-abfab-usability-ui-considerations-03 Thread-Index: AQHOgjFZR8V3U9M5d0azBJxFGnjBApnXJY6A Date: Wed, 25 Sep 2013 17:30:48 +0000 Message-ID: <4AD53B48-7169-49D6-A369-BE8F2585FBC1@cardiff.ac.uk> References: <03a101ce16a9$ab322f40$01968dc0$@augustcellars.com> In-Reply-To: <03a101ce16a9$ab322f40$01968dc0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [109.145.150.203] x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(252514010)(77096001)(51856001)(47736001)(46102001)(36756003)(74482001)(74662001)(47446002)(54356001)(19580405001)(4396001)(56816003)(81686001)(74366001)(19580395003)(83322001)(82746002)(81816001)(80976001)(49866001)(50986001)(47976001)(74706001)(76796001)(76786001)(76482001)(79102001)(56776001)(81342001)(33656001)(69226001)(74876001)(66066001)(83072001)(63696002)(81542001)(65816001)(53806001)(74502001)(59766001)(31966008)(54316002)(77982001)(80022001)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR02MB022; H:AMSPR02MB022.eurprd02.prod.outlook.com; CLIP:109.145.150.203; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <19645D646F2C304D9E2D2AB6FD380B76@eurprd02.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: cardiff.ac.uk Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-smith-abfab-usability-ui-considerations-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 17:30:58 -0000 Jim, all, Assume all points addressed in -04 to be submitted shortly, apart from thos= e I have specific comments about below: On 1 Mar 2013, at 19:21, Jim Schaad wrote: > 6. Section 6.1 - Is the issuing organization always going to be derivabl= e > from the NAI of the user? Under what circumstances would this not be the > case? Actually, I don't think this is needed at all. If we're saying that we MUST= store an NAI, then that contains both the username and realm to use for id= entifying the particular IdP. And then the friendly name for the identity w= ould be the place to store a human-friendly name (e.g. Janet or Cardiff Uni= versity). > 10 Section 7 - Identity selection by calling application rather than GSS-= API Sorry, not sure what part of Section 7 this comment is referring to? > 11 Section 7 - last paragraph - last sentence - should this be an > "automatic" option on some types of authentication failures? Good point. I've removed discussion of it being manual at all in that para,= and amended section 7.4 to include the idea of manual and automated disass= ociation. > 12. Section 7.3 - why should the association only be doable after > authentication? Esp for manual authentications. I think it's advisable that this would be the case as it would make interac= ting with the user easier if the attempt failed, as it could happen JIT as = the user attempts to make the connection. If they'd previously made it and,= say, only tried to actually use that service weeks later, it would be less= obvious to the user as to what the problem might be, I think=85 I've chang= ed the language though so as to not rule that out. > 13. Section 7.3.1 - It would be beneficial to list the types of things t= hat > are selections. I don't know that it is necessary to know the realm in a= ll > cases. Do we know what these things would be? Actually, wouldn't it just be the GSS Acceptor Name of the service? > 15. Section 8 - should applications attempt to use multiple names if the= re > are multiple names associated with the service. Need to discuss possible > privacy implications of this approach in terms of association of multiple > names together. Sorry, not sure what this is referring to in sec 8? or is this suggesting a= new topic that should be in the error handling section? Best, Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C From Smith@cardiff.ac.uk Wed Sep 25 10:31:33 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF9F11E812F for ; Wed, 25 Sep 2013 10:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.743 X-Spam-Level: X-Spam-Status: No, score=-2.743 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPppzNNBnJhu for ; Wed, 25 Sep 2013 10:31:27 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0013.outbound.protection.outlook.com [213.199.154.13]) by ietfa.amsl.com (Postfix) with ESMTP id 64D0011E8132 for ; Wed, 25 Sep 2013 10:31:23 -0700 (PDT) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB021.eurprd02.prod.outlook.com (10.242.81.145) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 25 Sep 2013 17:31:17 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.175]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.175]) with mapi id 15.00.0775.005; Wed, 25 Sep 2013 17:31:16 +0000 From: Rhys Smith To: Stefan Winter Thread-Topic: [abfab] Review of draft-smith-abfab-usability-ui-considerations-03 Thread-Index: AQHOk1ViYNjtSJqV50meGBgFSx/6XZnXA2eA Date: Wed, 25 Sep 2013 17:31:16 +0000 Message-ID: References: <52021B67.9030306@restena.lu> In-Reply-To: <52021B67.9030306@restena.lu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [109.145.150.203] x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(252514010)(199002)(189002)(24454002)(33656001)(54356001)(47736001)(47976001)(81542001)(4396001)(81342001)(49866001)(69226001)(83072001)(80022001)(74502001)(80976001)(19580395003)(65816001)(36756003)(76796001)(56816003)(77096001)(566174002)(50986001)(74482001)(66066001)(31966008)(76786001)(47446002)(74662001)(19580405001)(83322001)(81816001)(63696002)(74706001)(74876001)(51856001)(81686001)(76482001)(74366001)(54316002)(56776001)(53806001)(59766001)(77982001)(551544002)(79102001)(82746002)(46102001)(16236675002)(80792004); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR02MB021; H:AMSPR02MB022.eurprd02.prod.outlook.com; CLIP:109.145.150.203; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_AF2E95F8-02EC-4003-88B7-D2DC48338E6A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: cardiff.ac.uk Cc: "" Subject: Re: [abfab] Review of draft-smith-abfab-usability-ui-considerations-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 17:31:33 -0000 --Apple-Mail=_AF2E95F8-02EC-4003-88B7-D2DC48338E6A Content-Type: multipart/alternative; boundary="Apple-Mail=_E1A641AA-A2C5-421A-A376-5303E0A636FC" --Apple-Mail=_E1A641AA-A2C5-421A-A376-5303E0A636FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Comments below... On 7 Aug 2013, at 11:03, Stefan Winter wrote: > Hi, >=20 > as promised at IETF87, I gave the above draft a read. Since it has > expired and a new rev is pending, I'm not digging into nits, but = remain > on a conceptual layer: Thanks :-) > 5.1 Identity > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > contains the advice > " Implementors of an identity selector will need to carefully = consider > their indended audience for both their level of technical capability > and the existing terminology that they may have been exposed to." >=20 > That is a nice thought, but IMHO won't help in reality. The = implementer > of an Identity Selector does not know in which contexts his software = is > going to be used. > If you think on the probably widest scale: you implement a built-in > identity selector for an extremely popular Operating System with > millions of users: >=20 > - Your "target audience" is every human who is able to power on a > computer; levels of technical capability will vary from total > incompetence to extremely skilled. >=20 > - You also do not know which terminology all those users have been > exposed to. I think this advice can only be aimed at anyone implementing an identity = selector for a particular target audience. If you're an OS vendor and = your target audience is "all humans" then yes, I agree totally. But I = think it's good advice if you're implementing for a much more specific = set of people. The R&E community that Moonshot is targeting is probably close enough to = "all humans" that we can't do much here, but if say the high energy = physics world using CERN (to use a random example) were to develop their = own ID selector they might be able to. > 5.2 Services > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This section is rather thin, and could use some more text. I for one = see > the identity selector as an EAP supplicant; yes it does ABFAB-specific > things, but it needs not be a separate entity from a network-enabling > EAP supplicant. I think it's worth mentioning that one of the services > the identity selector could provide is the "Network Login Service"; > converging the network and other-service logins into one. The document currently really doesn't talk about what the services might = be at all, the use cases document does that. My +1 is for not talking = about this at all, since others with interests in other kinds of = services might want their use cases called out as well. But, I don't feel massively strongly about this, so I could do so if you = and others think strongly about this=85 >=20 > 6.1, first bullet, your TODO remark > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Especially since we do not know the level of skill on the user side, > forcing the id to be a realm seems inappropriate to me. A friendly = name > is understood by everybody; a cryptic @foo.bar.baz construct much less = so. Unfortunately this is a technical requirement of ABFAB and needs to be a = realm so that the correct IdP can be identified. There is a friendly = name in the SHOULD in the next para. The MUST may well be the NAI, = password, and trust anchor. > 6.1, fourth bullet > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > The trust anchor is not necessarily a certificate. At least in the > network use case, it is most often the tuple of (trusted root > certificate; server name as in Subject or subjectAltName). >=20 > The fact that it's a tuple has consequences for UI: it needs to = provide > input fields and/or provisioning mechanisms for both parts. Good point. Text amended. >=20 > 6.1 last two bullets > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Since these are optional, probably not worth discussing a lot, just a > question: "Reset Password" is typically a helpdesk operation; so with > Helpdesk URL I don't see much use for a separate Password Change URL? Users tend to like direct links to a password change URL, rather than = having to go to a general helpdesk page. > 6.2.1 Manual Addition > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > In EAP supplicants we often see a bad behaviour in that supplicants > default to "don't verify server identity" or "allow to continue > connecting even if server identity doesn't match". >=20 > I would suggest adding text that the UI should force the user as much = as > possible towards a secure setting. I.e. verification of server = identity > should be on by default, and if the user just "clicks next" the UI = will > not allow him to go to the next step unless he's either finalised > entering trust anchor information - or - explicitly configures that he > wants an insecure config (I imagine a big fat signal-colour warning on > screen when he checks that option). Yes. Good stuff. Text added. >=20 > 6.2.2 second bullet > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The text is okay, but I believe it is misplaced here. Even with manual > provisioning, the same question needs to be settled (and arguably also > in fully automated addition). So it's more like a general requirement > for an identity selector to ask this question and belongs to section > 6.1. It is a question that's probably best asked in the moment when = the > user uses a service for the first time, and the decision is = subsequently > memorised by the ID selector. Not sure=85 I would imagine the provisioning process would include that = information. The user should hopefully then be able to go and override = that. In an enterprise provisioning scenario, you want to interact with = the user as little as possible. >=20 > 6.4 Verifying an identity > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > It might make sense for the identity provider to set up a "test" = service > along with his RADIUS/ABFAB/SAML server. The identity selector could > then (if a login URL or so is provided with UI or automated > provisioning) check for a successful identity setup immediately after > the identity is added. Being able to specify the test service URL is > then required for UI. This is way cooler than with network access; you > can only test that if you are near a hotspot or ethernet plug of that > network. But with ABFAB, having an IP address is enough to do a test. = I > believe this should be exploited. That's a pretty cool idea, but not sure we can make this a requirement = on all UIs. It's certainly something deployers (such as us Moonshot = folks) might want to think about though... >=20 > 7 Mappings > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I'm not sure a full "many to many" relationship is needed to be > configurable or visible in UI. >=20 > A user would likely configure "Identity A is good for services m and = n" > (a 1 to n relationship); or "I have accounts with identity B and C for > service x" (a n to 1 relationship). >=20 > If all these relationships are configured, it may be that the > consequence is that several of the identities are good for several of > the services; but that is nothing that needs to be communicated to the > user. The UI should IMHO steer clear of explaining the user's full = mesh > of mappings to him. >=20 > I could imagine a user clicking on one identity and be shown the > services he has configured for it; or clicking on a service, and be > shown which identities are good for that service. I don't see how > presenting a tree, or even forest, of graphs with the full mesh is in > any way helpful (or even comprehensible) to a user. I don't the section suggests displaying many to many anywhere - it just = points out that the many to many relationship exists. I don't think I = even conceived of the idea of trying to do so, since it would be, as you = point out, pretty horrendous. If you think the text implied that, then = it certainly didn't mean to, and I can change the text to try to make = that clear if you think it's worth doing... >=20 > 7.4 Disassociating Mappings > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Why would this be a MUST requirement? The whole process of > dis-associating seems like an action without consequences for me. It > would not change anything on the service side (i.e. account details = are > not deprovisioned when dis-associating - right?). > And even if disassociated, the user could visit the service later = again > and re-associate at any time. >=20 > So, what changes when disassociating an identity from a service? Is it > more than UI hygiene, i.e. is the effect more significant than just > removing bloat from the list of services locally? It MUST be a MUST because if the user can't disassociate an identity = from a service in any way, then they have no way to change their mind = about the identity to use (or to not use ABFAB at all) for that service = without completely removing the whole identity and all of its mappings. = Which seems like bad UI design to me. > 9.1 Success on First Use Reporting > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > You write "depending on the service" here; which begs the question: = how > is the identity selector supposed to know if a given service is among > those that should be reported as success to the user. This would IMHO > require the identity selector to have metadata to that end about the > service; which doesn't seem like a good idea to me. Good point. But it is a good idea. Maybe this should become a stronger = statement. I've made that change. > And now I'm leaving you to those large empty TODO sections in the > document :-) Why thank you=85 I'm submitting a new version with Jim and your changes as 04. -05 will = start to address some of the currently empty suggestions=85 -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C --Apple-Mail=_E1A641AA-A2C5-421A-A376-5303E0A636FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Comments below...




On 7 Aug 2013, at 11:03, Stefan Winter <stefan.winter@restena.lu> = wrote:

Hi,

as promised at IETF87, I gave the above draft a = read. Since it has
expired and a new rev is pending, I'm not digging = into nits, but remain
on a conceptual = layer:

Thanks = :-)


5.1 = Identity
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

contains the = advice
"  Implementors of an identity selector will need to = carefully consider
  their indended audience for both = their level of technical capability
  and the existing = terminology that they may have been exposed to."

That is a nice = thought, but IMHO won't help in reality. The implementer
of an = Identity Selector does not know in which contexts his software = is
going to be used.
If you think on the probably widest scale: = you implement a built-in
identity selector for an extremely popular = Operating System with
millions of users:

- Your "target = audience" is every human who is able to power on a
computer; levels = of technical capability will vary from total
incompetence to = extremely skilled.

- You also do not know which terminology all = those users have been
exposed = to.

I think this advice can only be = aimed at anyone implementing an identity selector for a particular = target audience. If you're an OS vendor and your target audience is "all = humans" then yes, I agree totally. But I think it's good advice if = you're implementing for a much more specific set of = people.

The R&E community that Moonshot is = targeting is probably close enough to "all humans" that we can't do much = here, but if say the high energy physics world using CERN (to use a = random example) were to develop their own ID selector they might be able = to.



5.2 Services
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= This section is rather thin, and could use some more text. I for one = see
the identity selector as an EAP supplicant; yes it does = ABFAB-specific
things, but it needs not be a separate entity from a = network-enabling
EAP supplicant. I think it's worth mentioning that = one of the services
the identity selector could provide is the = "Network Login Service";
converging the network and other-service = logins into one.

The document = currently really doesn't talk about what the services might be at all, = the use cases document does that. My +1 is for not talking about this at = all, since others with interests in other kinds of services might want = their use cases called out as well.

But, I = don't feel massively strongly about this, so I could do so if you and = others think strongly about = this=85




<= blockquote type=3D"cite">
6.1, first bullet, your TODO = remark
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Especially since we do = not know the level of skill on the user side,
forcing the id to be a = realm seems inappropriate to me. A friendly name
is understood by = everybody; a cryptic @foo.bar.baz construct much less = so.

Unfortunately this is a = technical requirement of ABFAB and needs to be a realm so that the = correct IdP can be identified. There is a friendly name in the SHOULD in = the next para. The MUST may well be the NAI, password, and trust = anchor.


6.1, fourth = bullet
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Th= e trust anchor is not necessarily a certificate. At least in = the
network use case, it is most often the tuple of (trusted = root
certificate; server name as in Subject or = subjectAltName).

The fact that it's a tuple has consequences for = UI: it needs to provide
input fields and/or provisioning mechanisms = for both parts.

Good point. Text = amended.



6.1 last two bullets
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Since these are optional, probably not = worth discussing a lot, just a
question: "Reset Password" is = typically a helpdesk operation; so with
Helpdesk URL I don't see much = use for a separate Password Change = URL?

Users tend to like direct links = to a password change URL, rather than having to go to a general helpdesk = page.



6.2.1 Manual Addition
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
In EAP supplicants we often see a bad = behaviour in that supplicants
default to "don't verify server = identity" or "allow to continue
connecting even if server identity = doesn't match".

I would suggest adding text that the UI should = force the user as much as
possible towards a secure setting. I.e. = verification of server identity
should be on by default, and if the = user just "clicks next" the UI will
not allow him to go to the next = step unless he's either finalised
entering trust anchor information - = or - explicitly configures that he
wants an insecure config (I = imagine a big fat signal-colour warning on
screen when he checks that = option).

Yes. Good stuff. Text = added.



6.2.2 second bullet
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
The text is okay, but I believe it is = misplaced here. Even with manual
provisioning, the same question = needs to be settled (and arguably also
in fully automated addition). = So it's more like a general requirement
for an identity selector to = ask this question and belongs to section
6.1. It is a question that's = probably best asked in the moment when the
user uses a service for = the first time, and the decision is subsequently
memorised by the ID = selector.

Not sure=85 I would imagine the = provisioning process would include that information. The user should = hopefully then be able to go and override that. In an enterprise = provisioning scenario, you want to interact with the user as little as = possible.



6.4 = Verifying an identity
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
It might make sense for the identity = provider to set up a "test" service
along with his RADIUS/ABFAB/SAML = server. The identity selector could
then (if a login URL or so is = provided with UI or automated
provisioning) check for a successful = identity setup immediately after
the identity is added. Being able to = specify the test service URL is
then required for UI. This is way = cooler than with network access; you
can only test that if you are = near a hotspot or ethernet plug of that
network. But with ABFAB, = having an IP address is enough to do a test. I
believe this should be = exploited.

That's a pretty cool = idea, but not sure we can make this a requirement on all UIs. It's = certainly something deployers (such as us Moonshot folks) might want to = think about = though...





7 Mappings
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
I'm = not sure a full "many to many" relationship is needed to = be
configurable or visible in UI.

A user would likely configure "Identity A is good for = services m and n"
(a 1 to n relationship); or "I have accounts with = identity B and C for
service x" (a n to 1 relationship).

If = all these relationships are configured, it may be that = the
consequence is that several of the identities are good for = several of
the services; but that is nothing that needs to be = communicated to the
user. The UI should IMHO steer clear of = explaining the user's full mesh
of mappings to him.

I could = imagine a user clicking on one identity and be shown the
services he = has configured for it; or clicking on a service, and be
shown which = identities are good for that service. I don't see how
presenting a = tree, or even forest, of graphs with the full mesh is in
any way = helpful (or even comprehensible) to a = user.

I don't the section suggests = displaying many to many anywhere - it just points out that the many to = many relationship exists. I don't think I even conceived of the idea of = trying to do so, since it would be, as you point out, pretty horrendous. = If you think the text implied that, then it certainly didn't mean to, = and I can change the text to try to make that clear if you think it's = worth doing...



7.4 = Disassociating Mappings
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Why would this be a MUST = requirement? The whole process of
dis-associating seems like an = action without consequences for me. It
would not change anything on = the service side (i.e. account details are
not deprovisioned when = dis-associating - right?).
And even if disassociated, the user could = visit the service later again
and re-associate at any = time.

So, what changes when disassociating an identity from a = service? Is it
more than UI hygiene, i.e. is the effect more = significant than just
removing bloat from the list of services = locally?

It MUST be a MUST because = if the user can't disassociate an identity from a service in any way, = then they have no way to change their mind about the identity to use (or = to not use ABFAB at all) for that service without completely removing = the whole identity and all of its mappings. Which seems like bad UI = design to me.


9.1 = Success on First Use = Reporting
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
You write "depending on the = service" here; which begs the question: how
is the identity selector = supposed to know if a given service is among
those that should be = reported as success to the user. This would IMHO
require the identity = selector to have metadata to that end about the
service; which = doesn't seem like a good idea to = me.

Good point. But it is a good = idea. Maybe this should become a stronger statement. I've made that = change.




And now I'm leaving you to those large empty TODO sections = in the
document :-)

Why thank = you=85

I'm submitting a new version with Jim = and your changes as 04. -05 will start to address some of the currently = empty suggestions=85


--
Dr= Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff = University & Janet - the UK's research and education = network

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

= --Apple-Mail=_E1A641AA-A2C5-421A-A376-5303E0A636FC-- --Apple-Mail=_AF2E95F8-02EC-4003-88B7-D2DC48338E6A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJDHeMACgkQ3fEsO94vAkw7TQCfYufooT28yTTzh/AhAemSCcET ansAoJzTkr0jHtSBEYKpygZEboj8o4Em =y8bY -----END PGP SIGNATURE----- --Apple-Mail=_AF2E95F8-02EC-4003-88B7-D2DC48338E6A-- From Smith@cardiff.ac.uk Wed Sep 25 10:38:09 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0950121F9CC8 for ; Wed, 25 Sep 2013 10:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pl5rmgvIFS81 for ; Wed, 25 Sep 2013 10:38:03 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0014.outbound.protection.outlook.com [213.199.154.14]) by ietfa.amsl.com (Postfix) with ESMTP id 29F5121F9D94 for ; Wed, 25 Sep 2013 10:38:02 -0700 (PDT) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB023.eurprd02.prod.outlook.com (10.242.81.151) with Microsoft SMTP Server (TLS) id 15.0.775.9; Wed, 25 Sep 2013 17:37:56 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.175]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.175]) with mapi id 15.00.0775.005; Wed, 25 Sep 2013 17:37:56 +0000 From: Rhys Smith To: "" Thread-Topic: New Version Notification for draft-smith-abfab-usability-ui-considerations-04.txt Thread-Index: AQHOuhWvUaIVzPbIc0Cm7MFHj3/Z+Q== Date: Wed, 25 Sep 2013 17:37:56 +0000 Message-ID: <070D3E5F-A6E9-4A07-94A4-6673DE804F0C@cardiff.ac.uk> References: <20130925173537.29986.48412.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [109.145.150.203] x-forefront-prvs: 098076C36C x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377424004)(2473001)(252514010)(53806001)(551934002)(16236675002)(79102001)(19580395003)(19580405001)(83322001)(46102001)(56776001)(54316002)(81686001)(51856001)(74366001)(59766001)(77982001)(81816001)(82746002)(76482001)(74876001)(15975445006)(74706001)(63696002)(80976001)(56816003)(74662001)(77096001)(47446002)(74482001)(74502001)(49866001)(76786001)(76796001)(4396001)(36756003)(66066001)(15202345003)(81342001)(31966008)(14971765001)(47736001)(69226001)(80022001)(65816001)(33656001)(50986001)(47976001)(54356001)(81542001)(16601075003)(83072001)(80792004)(491001); DIR:OUT; SFP:; SCL:1; SRVR:AMSPR02MB023; H:AMSPR02MB022.eurprd02.prod.outlook.com; CLIP:109.145.150.203; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_A5B65BF1-5BAE-4AB2-B08C-B66A7856EE4F"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: cardiff.ac.uk Subject: [abfab] Fwd: New Version Notification for draft-smith-abfab-usability-ui-considerations-04.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 17:38:09 -0000 --Apple-Mail=_A5B65BF1-5BAE-4AB2-B08C-B66A7856EE4F Content-Type: multipart/alternative; boundary="Apple-Mail=_93138C99-813F-4ED5-8C0B-9474518254C3" --Apple-Mail=_93138C99-813F-4ED5-8C0B-9474518254C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 And here is the -04 draft updated as per Jim and Stefan's comments, as = promised. If you didn't know, "a couple of days" is around 15 of the little = blighters in Wales=85 Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C Begin forwarded message: > From: > Subject: New Version Notification for = draft-smith-abfab-usability-ui-considerations-04.txt > Date: 25 September 2013 18:35:37 BST > To: Rhys Smith >=20 >=20 > A new version of I-D, = draft-smith-abfab-usability-ui-considerations-04.txt > has been successfully submitted by Rhys Smith and posted to the > IETF repository. >=20 > Filename: draft-smith-abfab-usability-ui-considerations > Revision: 04 > Title: Application Bridging for Federated Access = Beyond web (ABFAB) Usability and User Interface Considerations > Creation date: 2013-09-25 > Group: Individual Submission > Number of pages: 16 > URL: = http://www.ietf.org/internet-drafts/draft-smith-abfab-usability-ui-conside= rations-04.txt > Status: = http://datatracker.ietf.org/doc/draft-smith-abfab-usability-ui-considerati= ons > Htmlized: = http://tools.ietf.org/html/draft-smith-abfab-usability-ui-considerations-0= 4 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-abfab-usability-ui-consider= ations-04 >=20 > Abstract: > The use of ABFAB-based technologies requires that each user's device > is configured with the user's identities that they wish to use in > ABFAB transactions. This will require something on that device, > either built into the operating system or a standalone utility, that > will manage the user's identities and identity to service mappings. > Anyone designing that "something" will face the same set of > challenges. This document aims to document these challenges with = the > aim of producing well-thought out UIs with some degree of > consistency. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_93138C99-813F-4ED5-8C0B-9474518254C3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 And = here is the -04 draft updated as per Jim and Stefan's comments, as = promised.

If you didn't know, "a couple of days" is = around 15 of the little blighters in = Wales=85

Rhys.
--
Dr Rhys Smith
Identity, = Access, and Middleware Specialist
Cardiff University & Janet - = the UK's research and education network

email: smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C



Begin forwarded message:

Subject: New Version Notification for = draft-smith-abfab-usability-ui-considerations-04.txt
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">Date: 25 September 2013 = 18:35:37 BST
To: Rhys Smith <smith@cardiff.ac.uk>
=


A new version of I-D, = draft-smith-abfab-usability-ui-considerations-04.txt
has been = successfully submitted by Rhys Smith and posted to the
IETF = repository.

Filename: = draft-smith-abfab-usability-ui-considerations
Revision: = 04
Title: = = Application Bridging for Federated Access Beyond web (ABFAB) = Usability and User Interface Considerations
Creation date: = 2013-09-25
Group: Individual Submission
Number = of pages: 16
URL: =             http://www.ietf.org/internet-drafts/draft-smith-ab= fab-usability-ui-considerations-04.txt
Status: =          http://datatracker.ietf.org/doc/draft-smith-abfab-usability-u= i-considerations
Htmlized: =        http://tools.ietf.org/html/draft-smith-abfab-usability-ui-consi= derations-04
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-smith-abfab-us= ability-ui-considerations-04

Abstract:
  The = use of ABFAB-based technologies requires that each user's device
=   is configured with the user's identities that they wish to = use in
  ABFAB transactions.  This will require = something on that device,
  either built into the = operating system or a standalone utility, that
  will = manage the user's identities and identity to service mappings.
=   Anyone designing that "something" will face the same set = of
  challenges.  This document aims to document = these challenges with the
  aim of producing well-thought = out UIs with some degree of
=   consistency.




Please note that it may take = a couple of minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_93138C99-813F-4ED5-8C0B-9474518254C3-- --Apple-Mail=_A5B65BF1-5BAE-4AB2-B08C-B66A7856EE4F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJDH3MACgkQ3fEsO94vAkwtJACgwiQvWQwKPa8gjWzeyMHM2xNI r6wAoIAXEWulmXE8I3wHRFM4j2wV5/bR =vd3L -----END PGP SIGNATURE----- --Apple-Mail=_A5B65BF1-5BAE-4AB2-B08C-B66A7856EE4F-- From ietf@augustcellars.com Wed Sep 25 11:47:45 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D00A21F9AEF for ; Wed, 25 Sep 2013 11:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=1.701, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7ZlVbwgNuaO for ; Wed, 25 Sep 2013 11:47:39 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 40F5521F9DCE for ; Wed, 25 Sep 2013 11:47:37 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id B6A1938F1C; Wed, 25 Sep 2013 11:47:35 -0700 (PDT) From: "Jim Schaad" To: "'Rhys Smith'" References: <03a101ce16a9$ab322f40$01968dc0$@augustcellars.com> <4AD53B48-7169-49D6-A369-BE8F2585FBC1@cardiff.ac.uk> In-Reply-To: <4AD53B48-7169-49D6-A369-BE8F2585FBC1@cardiff.ac.uk> Date: Wed, 25 Sep 2013 11:46:23 -0700 Message-ID: <078a01ceba1f$88db0290$9a9107b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLM8fOCqCt8Rw0e/ik6boRv4/sYtwHtjyV9l8rszVA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-smith-abfab-usability-ui-considerations-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 25 Sep 2013 18:47:45 -0000 You really expect me to remember after this long? > -----Original Message----- > From: Rhys Smith [mailto:Smith@cardiff.ac.uk] > Sent: Wednesday, September 25, 2013 10:31 AM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: Comments on draft-smith-abfab-usability-ui-considerations-03 > > Jim, all, > > Assume all points addressed in -04 to be submitted shortly, apart from those I > have specific comments about below: > > > On 1 Mar 2013, at 19:21, Jim Schaad wrote: > > 6. Section 6.1 - Is the issuing organization always going to be > > derivable from the NAI of the user? Under what circumstances would > > this not be the case? > > Actually, I don't think this is needed at all. If we're saying that we MUST store > an NAI, then that contains both the username and realm to use for identifying > the particular IdP. And then the friendly name for the identity would be the > place to store a human-friendly name (e.g. Janet or Cardiff University). > > > > > > 10 Section 7 - Identity selection by calling application rather than > > GSS-API > > Sorry, not sure what part of Section 7 this comment is referring to? > My best guess as to what I meant here, is that there should be a discussion about the application that is requesting a server either be able to provide its own mapping, rather than using the GSS-API internals for doing the mapping. Or that it should be able to do some filtering of the identities that are displayed. > > > 11 Section 7 - last paragraph - last sentence - should this be an > > "automatic" option on some types of authentication failures? > > Good point. I've removed discussion of it being manual at all in that para, and > amended section 7.4 to include the idea of manual and automated > disassociation. > > > > 12. Section 7.3 - why should the association only be doable after > > authentication? Esp for manual authentications. > > I think it's advisable that this would be the case as it would make interacting > with the user easier if the attempt failed, as it could happen JIT as the user > attempts to make the connection. If they'd previously made it and, say, only > tried to actually use that service weeks later, it would be less obvious to the > user as to what the problem might be, I think. I've changed the language > though so as to not rule that out. > > > > 13. Section 7.3.1 - It would be beneficial to list the types of > > things that are selections. I don't know that it is necessary to know > > the realm in all cases. > > Do we know what these things would be? > > Actually, wouldn't it just be the GSS Acceptor Name of the service? Yes, but it would be the full name with all of its parameters and just the name of the machine plus the service name. > > > > 15. Section 8 - should applications attempt to use multiple names if > > there are multiple names associated with the service. Need to discuss > > possible privacy implications of this approach in terms of association > > of multiple names together. > > Sorry, not sure what this is referring to in sec 8? or is this suggesting a new > topic that should be in the error handling section? This was triggered in my mind on handling of errors, but it might not belong in this section. Consider the case where I have two distinct identities associated with the generic smtp service (i.e. not associated with any server name). Is there a privacy concern about providing the first one if it fails but the second one works. Should the use be told that which of the two succeeded or should that be a hidden error? Jim > > > Best, > Rhys. > -- > Dr Rhys Smith > Identity, Access, and Middleware Specialist Cardiff University & Janet - the > UK's research and education network > > email: smith@cardiff.ac.uk / rhys.smith@ja.net > GPG: 0xDE2F024C From juanwei2012@gmail.com Wed Sep 25 18:11:26 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFC621F9AA2 for ; Wed, 25 Sep 2013 18:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=5 tests=[AWL=0.724, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyCGKAI25lko for ; Wed, 25 Sep 2013 18:11:25 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4C121F9BD0 for ; Wed, 25 Sep 2013 18:11:25 -0700 (PDT) Received: by mail-pa0-f53.google.com with SMTP id kq14so562405pab.26 for ; Wed, 25 Sep 2013 18:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:mime-version:message-id:content-type; bh=DNFAMFkAZQAYwpEabHslgln6KciELgWWd3c49JkrLq0=; b=Dr83JyItLh2DW3sEQ1fdsCM22GlKkemKUXapR5cd+8DZr4DfU9TLK1Y7JFgwX+xK8I +q23207IIyW7is9gbjOgcox9dAYBOjMIaMHZGfKMH//gu8QPBkgFGDtg8F/1gVVff9jo 7FkqqknOZi0Ywg//SJncqreBqGllMyYtsX0tN13092YWFfwJBA8UEu+AvN2L/zpaI2Lk yiS7NPld1SyiLlpr1Cd8iRNfGS91qDfKdz+9e+rFmn3r2xP5bESzr9lqGivGFPurzLkN 3b4ozaqIWhZmDLgNVtvszs3y5SqYRAQUdeUD5Hk+ZNgm6CznlMa4+gTgRKxs8EmTPitD xx2Q== X-Received: by 10.68.218.6 with SMTP id pc6mr232462pbc.187.1380157884230; Wed, 25 Sep 2013 18:11:24 -0700 (PDT) Received: from PC-201303222330 (openid.szu.edu.cn. [210.39.14.237]) by mx.google.com with ESMTPSA id wd6sm1014861pab.3.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 18:11:23 -0700 (PDT) Date: Thu, 26 Sep 2013 09:11:20 +0800 From: "Wei Juan" To: abfab X-Priority: 3 X-GUID: CD70D84D-B81B-4EDC-8032-89135579A421 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <2013092609111720898326@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart023405333583_=----" Subject: [abfab] I-D Action: draft-wei-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 01:11:26 -0000 This is a multi-part message in MIME format. ------=_001_NextPart023405333583_=---- Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 DQpEZWFyIGFsbCwNCg0KV2UganVzdCBzdWJtaXR0ZWQgYW4gSS1EIHRvIElFVEYgcmVnYXJkaW5n IHRoZSBzZWN1cml0eSBvZiAgZmVkZXJhdGVkIGlkZW50aXRpeSBtYW5hZ21lbnQgaW4gQUJGQUIg ZmV3IGRheXMgYWdvLiBQbGVhc2Uga2luZGx5IHJldmlldyBhbmQgZmVlbCBmcmVlIHRvIGdpdmUg dXMgYW55IGNvbW1lbnRzLiBUaGFuayB5b3UgaW4gYWR2YW5jZS4NCg0KS2V5IHBvaW50cyAmIFJl cXVpcmVtZW50cyBBbmFseXNpcw0KVGhpcyBJLUQgZGVzY3JpYmVzIHR3byB1c2UgY2FzZXMgaW4g QUJGQUIuICBUaGUgbWFpbiBpZGVhIGlzIHRvIGRpZmZlcmVudGlhdGUgdGhlIGxldmVsIG9mIGFz c3VyYW5jZSBmb3IgYXV0aGVudGljYXRpb24gYW5kIHRvIGNsYXNzaWZ5IHRoZSBhdXRoZW50aWNp dHkgb2YgYXR0cmlidXRlcyBpbiBvcmRlciB0byBpbXByb3ZlIHRoZSBzZWN1cml0eSBhbmQgdXNh YmlsaXR5IG9mIGZlZGVyYXRpb24gaWRlbnRpdHkgbWFuYWdlbWVudCBvbiBBQkZBQiBhcmNoaXRl Y3R1cmUuDQoNClRoZSBmb3JtZXIgaXMgdXN1YWxseSB1c2VkIGZvciBtZWV0aW5nIHRoZSByZXF1 aXJlbWVudHMgb2YgbXVsdGlwbGUgdGVybWluYWxzIGFjY2Vzc2luZyBuZXR3b3JrIGFuZCBjb21w bGV4aXR5ICBvZiBuZXR3b3JrIGVudmlyb25tZW50LiBUbyBkaWZmZXJlbnRpYXRlIGF1dGhlbnRp Y2F0aW9uIGxldmVsIGNhbiBtYWtlIGEgdHJhZGUtb2ZmIGJldHdlZW4gdXNhYmlsaXR5IGFuZCBz ZWN1cml0eS4gVGhlIGxhdHRlciBpcyB0eXBpY2FsbHkgdXNlZCB0byBhc3Npc3Qgc2VydmljZSBw cm92aWRlcnMgdG8gbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucywgdGhhdCBpcyBzZXJ2aWNl IHByb3ZpZGVycyBjYW4gZ3JhbnQgc3BlY2lmaWMgcHJvdGVjdGVkIHJlc291cmNlcyB0byByZXF1 ZXN0b3JzIGFjY29yZGluZyAgdGhlIHRydXN0d29ydGhpbmVzcyBvZiB0aGVpciBpZGVudGl0eSBh dHRyaWJ1dGVzIHdpdGhvdXQgY29tcHJvbWlzaW5nIHRoZSBzZWN1cml0eSBvZiByZXNvdXJjZXMu DQoNCkFsdGhvdWdoIEFCRkFCIGFyY2hpdGVjdHVyZSBjYW4gc3VwcG9ydCBtdWx0aXBsZSBhdXRo ZW50aWNhdGlvbiBtZWNoYW5pc21zIGFuZCBhdHRyaWJ1dGVzIHRyYW5zbWlzc2lvbiwgaXQgZG9l cyBub3QgZ2l2ZSBhIGZpbmUtZ3JhaW5lZCBjbGFzc2lmaWNhdGlvbiB3aGljaCBjYW4gc2F0aXNm eSByZXF1aXJlbWVudHMgaW4gcmVhbCB3b3JsZCBiZXR0ZXIuDQoNCkJlc3Qgd2lzaGVzLCBKdWFu DQoNCiANCg0KDQoNCldlaSBKdWFu ------=_001_NextPart023405333583_=---- Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: quoted-printable
 
Dear all,
 
We just submitted an I-D to IETF regarding the security of  fede= rated=20 identitiy managment in ABFAB few days ago. Please kindly review and feel f= ree to=20 give us any comments. Thank you in advance.
 
Key points & Requirements Analysis
This I-D describes two use cases in ABFAB.  The main idea is to=20 differentiate the level of assurance for authentication and=20 to classify the authenticity of attributes in order to=20 improve the security and usability of federation identity management = on=20 ABFAB architecture.
 
The former is usually used for meeting the requirements of multiple=20 terminals accessing network and complexity  of network environment. T= o=20 differentiate authentication level can make a trade-off between usability = and=20 security. The latter is typically used to assist service providers to make= =20 authorization decisions, that is service providers can grant specific prot= ected=20 resources to requestors according  the trustworthiness of their ident= ity=20 attributes without compromising the security of resources.
 
Although ABFAB architecture can support multiple authentication mecha= nisms=20 and attributes transmission, it does not give a fine-grained classificatio= n=20 which can satisfy requirements in real world better.
 
Best wishes, Juan
 
 
Wei Juan
 
------=_001_NextPart023405333583_=------ From juanwei2012@gmail.com Wed Sep 25 18:26:29 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3306321F9EDA for ; Wed, 25 Sep 2013 18:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[AWL=1.420, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41tdh1FkpZLP for ; Wed, 25 Sep 2013 18:26:28 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id B6D9621F9EE0 for ; Wed, 25 Sep 2013 18:26:26 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so415062pbc.7 for ; Wed, 25 Sep 2013 18:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:mime-version:message-id:content-type; bh=0tV9JukHgt0zCWg/dRMxB1mjwlxsg6tYAYoYuE5TpGc=; b=Gh+urc9+YzuZwRVlT8sctmTf5Vlo2UGo8E+bbOcjCCQapxzXyE4VjokR2MAm+p9Pri CdhWHHtn2kcZYUnHnxX5EbNiIr1UUpIRyOPN40UU5pu8MX6z5hKT95j5Ol5g3wnTN9a/ xWt2BIQDlQkDEYiHZOOXQkGV/fd8qJ7fO/hbuZK71phbmZyiNS6EFgOJUSP77iYQnpw+ q9K/RKEHMAfADMFz+Gr5Ddg8suE8CCpp3Bi1hKtEnvEFRyHZFUaF4er4Gq0mmuq8iicD /vQokZAbB2Gh/FreKx9Yf8tcZTTBMGlHCkPNks5bMVRWNuIuTI0fk3z51XA3l9gO+vIW 0o/g== X-Received: by 10.68.202.38 with SMTP id kf6mr36617905pbc.43.1380158786432; Wed, 25 Sep 2013 18:26:26 -0700 (PDT) Received: from PC-201303222330 (openid.szu.edu.cn. [210.39.14.237]) by mx.google.com with ESMTPSA id nj9sm50598796pbc.13.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 18:26:26 -0700 (PDT) Date: Thu, 26 Sep 2013 09:26:22 +0800 From: "Wei Juan" To: =?UTF-8?B?PGFiZmFiQGlldGYub3JnPg==?= X-Priority: 3 X-GUID: 3896021D-1856-403D-8B6A-4E554E47456C X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <2013092609262067050833@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart874532563274_=----" Subject: [abfab] Fw: New Version Notification for draft-wei-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 01:26:29 -0000 This is a multi-part message in MIME format. ------=_001_NextPart874532563274_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQpEZWFyIGFsbCwNCg0KV2UganVzdCBzdWJtaXR0ZWQgYW4gSS1EIHRvIElFVEYgcmVnYXJkaW5n IHRoZSBzZWN1cml0eSBvZiAgZmVkZXJhdGVkIGlkZW50aXRpeSBtYW5hZ21lbnQgaW4gQUJGQUIg ZmV3IGRheXMgYWdvLiBQbGVhc2Uga2luZGx5IHJldmlldyBhbmQgZmVlbCBmcmVlIHRvIGdpdmUg dXMgYW55IGNvbW1lbnRzLiBUaGFuayB5b3UgaW4gYWR2YW5jZS4NCg0KS2V5IHBvaW50cyAmIFJl cXVpcmVtZW50cyBBbmFseXNpcw0KVGhpcyBJLUQgZGVzY3JpYmVzIHR3byB1c2UgY2FzZXMgaW4g QUJGQUIuICBUaGUgbWFpbiBpZGVhIGlzIHRvIGRpZmZlcmVudGlhdGUgdGhlIGxldmVsIG9mIGFz c3VyYW5jZSBmb3IgYXV0aGVudGljYXRpb24gYW5kIHRvIGNsYXNzaWZ5IHRoZSBhdXRoZW50aWNp dHkgb2YgYXR0cmlidXRlcyBpbiBvcmRlciB0byBpbXByb3ZlIHRoZSBzZWN1cml0eSBhbmQgdXNh YmlsaXR5IG9mIGZlZGVyYXRpb24gaWRlbnRpdHkgbWFuYWdlbWVudCBvbiBBQkZBQiBhcmNoaXRl Y3R1cmUuDQoNClRoZSBmb3JtZXIgaXMgdXN1YWxseSB1c2VkIGZvciBtZWV0aW5nIHRoZSByZXF1 aXJlbWVudHMgb2YgbXVsdGlwbGUgdGVybWluYWxzIGFjY2Vzc2luZyBuZXR3b3JrIGFuZCBjb21w bGV4aXR5ICBvZiBuZXR3b3JrIGVudmlyb25tZW50LiBUbyBkaWZmZXJlbnRpYXRlIGF1dGhlbnRp Y2F0aW9uIGxldmVsIGNhbiBtYWtlIGEgdHJhZGUtb2ZmIGJldHdlZW4gdXNhYmlsaXR5IGFuZCBz ZWN1cml0eS4gVGhlIGxhdHRlciBpcyB0eXBpY2FsbHkgdXNlZCB0byBhc3Npc3Qgc2VydmljZSBw cm92aWRlcnMgdG8gbWFrZSBhdXRob3JpemF0aW9uIGRlY2lzaW9ucywgdGhhdCBpcyBzZXJ2aWNl IHByb3ZpZGVycyBjYW4gZ3JhbnQgc3BlY2lmaWMgcHJvdGVjdGVkIHJlc291cmNlcyB0byByZXF1 ZXN0b3JzIGFjY29yZGluZyAgdGhlIHRydXN0d29ydGhpbmVzcyBvZiB0aGVpciBpZGVudGl0eSBh dHRyaWJ1dGVzIHdpdGhvdXQgY29tcHJvbWlzaW5nIHRoZSBzZWN1cml0eSBvZiByZXNvdXJjZXMu DQoNCkFsdGhvdWdoIEFCRkFCIGFyY2hpdGVjdHVyZSBjYW4gc3VwcG9ydCBtdWx0aXBsZSBhdXRo ZW50aWNhdGlvbiBtZWNoYW5pc21zIGFuZCBhdHRyaWJ1dGVzIHRyYW5zbWlzc2lvbiwgaXQgZG9l cyBub3QgZ2l2ZSBhIGZpbmUtZ3JhaW5lZCBjbGFzc2lmaWNhdGlvbiB3aGljaCBjYW4gc2F0aXNm eSByZXF1aXJlbWVudHMgaW4gcmVhbCB3b3JsZCBiZXR0ZXIuDQoNCkJlc3Qgd2lzaGVzLCBKdWFu DQoNCg0KDQpXZWkgSnVhbg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzDQpEYXRlOiAyMDEzLTA5LTIyIDE3OjMwDQpUbzoganVhbndlaTIwMTJAZ21h aWwuY29tOyBKaWFueW9uZyBDaGVuOyBXZWkgSnVhbjsgSnVuIFpoYW5nDQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdlaS1hYmZhYi11c2VjYXNlcy0wMC50eHQN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdlaS1hYmZhYi11c2VjYXNlcy0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgV2VpIEp1YW4gYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6IGRyYWZ0LXdlaS1hYmZhYi11c2Vj YXNlcw0KUmV2aXNpb246IDAwDQpUaXRsZTogQXBwbGljYXRpb24gQnJpZGdpbmcgZm9yIEZlZGVy YXRlZCBBY2Nlc3MgQmV5b25kIFdlYg0KQ3JlYXRpb24gZGF0ZTogMjAxMy0wOS0yMg0KR3JvdXA6 IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiA3DQpVUkw6ICAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdlaS1hYmZhYi11 c2VjYXNlcy0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC13ZWktYWJmYWItdXNlY2FzZXMNCkh0bWxpemVkOiAgICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2VpLWFiZmFiLXVzZWNhc2VzLTAwDQoNCg0KQWJz dHJhY3Q6DQogICBJZGVudGl0eSBNYW5hZ2VtZW50IFN5c3RlbSBwbGF5cyBhbiBpbXBvcnRhbnQg cm9sZSBpbiBDbG91ZA0KICAgQ29tcHV0aW5nLiBBIGdvb2QgSWRlbnRpdHkgTWFuYWdlbWVudCBT eXN0ZW0gc2hvdWxkIG1lZXQgdGhlIGRpdmVyc2UNCiAgIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBm cm9tIGJvdGggc2VydmljZSBwcm92aWRlcnMgYW5kIHVzZXJzLCBpbXByb3ZlDQogICB1c2FiaWxp dHkgZm9yIHVzZXJzIGFuZCBwcm90ZWN0IHRoZSByZXNvdXJjZXMgZnJvbSB1bmF1dGhvcml6ZWQN CiAgIGFjY2Vzcy4gVGhlIGdvYWwgb2YgdGhlIGRvY3VtZW50IGlzIHRvIGRvY3VtZW50IHRoZSBp bXByb3ZlbWVudCBvZg0KICAgSWRlbnRpdHkgTWFuYWdlbWVudCBTeXN0ZW0gdG8gcHJvdmlkZSB1 c2VycyBhIGZyaWVuZGx5IGV4cGVyaWVuY2UNCiAgIHRocm91Z2ggdGhlIHVzZSBvZiB0ZWNobm9s b2dpZXMgYmFzZWQgb24gdGhlIEFCRkFCIGFyY2hpdGVjdHVyZSBhbmQNCiAgIHNwZWNpZmljYXRp b25zLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ= ------=_001_NextPart874532563274_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
Dear all,
 
We just submitted an I-D to IETF regarding the security of  fede= rated=20 identitiy managment in ABFAB few days ago. Please kindly review and feel f= ree to=20 give us any comments. Thank you in advance.
 
Key points & Requirements Analysis
This I-D describes two use cases in ABFAB.  The main idea is to=20 differentiate the level of assurance for authentication and=20 to classify the authenticity of attributes in order to=20 improve the security and usability of federation identity management = on=20 ABFAB architecture.
 
The former is usually used for meeting the requirements of multiple=20 terminals accessing network and complexity  of network environment. T= o=20 differentiate authentication level can make a trade-off between usability = and=20 security. The latter is typically used to assist service providers to make= =20 authorization decisions, that is service providers can grant specific prot= ected=20 resources to requestors according  the trustworthiness of their ident= ity=20 attributes without compromising the security of resources.
 
Although ABFAB architecture can support multiple authentication mecha= nisms=20 and attributes transmission, it does not give a fine-grained classificatio= n=20 which can satisfy requirements in real world better.
 
Best wishes, Juan
Wei Juan
 
Begin forwarded message:
 
From: internet-drafts
Date: 2013-09-22 17:30
To: juanwei2012@gmail.com; Jianyong Chen; Wei Juan; Jun Zhang
Subject: New Version Notification for=20 draft-wei-abfab-usecases-00.txt
 
A new version of I-D, draft-wei-abfab-usecases-00.txt
has been successfully submitted by Wei Juan and posted to the
IETF repository.
 
Filename: draft-wei-abfab-usecases
Revision: 00
Title: Application Bridging for Federated Access Beyond Web
Creation date: 2013-09-22
Group: Individual Submission
Number of pages: 7
URL:           = ; =20 http://www.ietf.org/internet-drafts/draft-wei-abfab-usecases-00.txt
Status:         =20 http://datatracker.ietf.org/doc/draft-wei-abfab-usecases
Htmlized:       =20 http://tools.ietf.org/html/draft-wei-abfab-usecases-00
 
 
Abstract:
   Identity Management System plays an important role in=20 Cloud
   Computing. A good Identity Management System should meet= the=20 diverse
   security requirements from both service providers and us= ers,=20 improve
   usability for users and protect the resources from=20 unauthorized
   access. The goal of the document is to document the=20 improvement of
   Identity Management System to provide users a friendly=20 experience
   through the use of technologies based on the ABFAB=20 architecture and
   specifications.
 
           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;       =20
 
 
Please note that it may take a couple of minutes from the time of=20 submission
until the htmlized version and diff are available at tools.ietf.org.<= /DIV>
 
The IETF Secretariat
 
------=_001_NextPart874532563274_=------ From hartmans@painless-security.com Thu Sep 26 06:27:33 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4C221F9AD5 for ; Thu, 26 Sep 2013 06:27:30 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+0unLxcuAb0 for ; Thu, 26 Sep 2013 06:27:21 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 129FE21F9F88 for ; Thu, 26 Sep 2013 06:27:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 7E1F02043F; Thu, 26 Sep 2013 09:26:06 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grdLCeLs6MOI; Thu, 26 Sep 2013 09:26:06 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 26 Sep 2013 09:26:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 59C1580D3A; Thu, 26 Sep 2013 09:26:58 -0400 (EDT) From: Sam Hartman To: "Wei Juan" References: <2013092609111720898326@gmail.com> Date: Thu, 26 Sep 2013 09:26:58 -0400 In-Reply-To: <2013092609111720898326@gmail.com> (Wei Juan's message of "Thu, 26 Sep 2013 09:11:20 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab Subject: Re: [abfab] I-D Action: draft-wei-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 13:27:34 -0000 ABFAB is typically used for application authentication rather than say network authentication. However, in your example you suggest that the level of assurance required might depend on what network technology a user is using. I'd like to better understand how that is true in your environment. --Sam From juanwei2012@gmail.com Thu Sep 26 07:00:55 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233A321E8094 for ; Thu, 26 Sep 2013 07:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lgfVoL9A7LZ for ; Thu, 26 Sep 2013 07:00:54 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 00EA921F9F62 for ; Thu, 26 Sep 2013 07:00:37 -0700 (PDT) Received: by mail-pa0-f50.google.com with SMTP id fb1so1362413pad.9 for ; Thu, 26 Sep 2013 07:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:references:mime-version:message-id :content-type; bh=tNDjvKlD8zKpApCnwPwdmZezIEnJDGstyeklmfeq9lw=; b=WRGtc0VipOaWczY07ZOCr+Yt++NOMUl+J4UU6BWSpk2s02yiv95mNkEJnH7Z0KZvTg aT9VvttrwSKSE/jKwrILjf7XCt0iNyzmuOg197/bxVOJzHJCzEqm3/QCnL0VwWDtuI9z YfeWOgyK+wEmAF+gJr706Q8fkvAnvxNEjSquJnoenRQEkIMSM5fdMo7BpA25dDfu+j7m hL79utPrI6Be7xkjM5Stq/DHgzM8OpgV0xYsxgnPSGb5iYm0QY4QTZRHc12LEXThe8k4 y+PtoWMSnIQeGE3OuWRLaRUqXe2TomB9IA33BHqrFh1FVLqGASB1YUhi+oF1P3IG7tf6 ZNsw== X-Received: by 10.66.142.193 with SMTP id ry1mr5620504pab.150.1380204031041; Thu, 26 Sep 2013 07:00:31 -0700 (PDT) Received: from PC-201303222330 ([58.60.63.195]) by mx.google.com with ESMTPSA id va8sm2451575pbc.16.1969.12.31.16.00.00 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Sep 2013 07:00:29 -0700 (PDT) Date: Thu, 26 Sep 2013 22:00:23 +0800 From: "Wei Juan" To: "Sam Hartman" References: <2013092609111720898326@gmail.com>, X-Priority: 3 X-GUID: 65FDD270-6511-4146-9BF3-1D6A876FB915 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <2013092622001731879657@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart772051273325_=----" Cc: abfab Subject: Re: [abfab] I-D Action: draft-wei-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 14:00:55 -0000 This is a multi-part message in MIME format. ------=_001_NextPart772051273325_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpzb3JyeSwgd2hhdCBJIHJlYWxseSB3YW50IHRvIHNheSAgaXMgdGhhdCAgZGlmZmVyZW50IGFw cGxpY2F0aW9ucyBtYXkgcmVxdWlyZSBkaWZmZXJlbnQgbGV2ZWwgb2YgYXNzdXJhbmNlIGZvciBh dXRoZW50aWNhdGlvbi4gRm9yIGV4YW1wbGUsIGEgZmluYW5jaWFsIGFwcGxpY2F0aW9uIHVzdWFs bHkgcmVxdWlyZXMgYSBoaWdoZXIgbGV2ZWwgb2YgYXNzdXJhbmNlIGZvciBhdXRoZW50aWNhdGlv biB3aGlsZSB0aGUgbGV2ZWwgb2YgYXV0aGVudGljYXRpb24gb2YgYSBnZW5lcmFsIGFwcGxpY2F0 aW9uIG1heSBiZSBsb3dlci4gSW4gYWRkdGlvbiwgdGhlIG5ldHdvcmsgdGVjaG5vbG9neSBhIHVz ZXIgaXMgdXNpbmcganVzdCByZXByZXNlbnRzIHRoZSBlbnZpcm9ubWVudCBvZiBhY2Nlc3Npbmcg dGFyZ2V0IGFwcGxpY2F0aW9uLCBhbmQgdGhlIHNhbWUgYXBwbGljYXRpb24gbWF5IHJlcXVpcmUg ZGlmZmVyZW50IGxldmVsIGFzc3VyYW5jZSBmb3IgYXV0aGVudGljYXRpb24gaW4gZGlmZmVyZW50 IGVudmlyb25tZW50IGluIG9yZGVyIHRvIGd1YXJhbnRlZSB0aGUgc2VjdXJpdHkgb2Ygc2Vydmlj ZXMuDQoNCg0KDQpXZWkgSnVhbg0KDQpGcm9tOiBTYW0gSGFydG1hbg0KRGF0ZTogMjAxMy0wOS0y NiAyMToyNg0KVG86IFdlaSBKdWFuDQpDQzogYWJmYWINClN1YmplY3Q6IFJlOiBbYWJmYWJdIEkt RCBBY3Rpb246IGRyYWZ0LXdlaS1hYmZhYi11c2VjYXNlcy0wMC50eHQNCkFCRkFCIGlzIHR5cGlj YWxseSB1c2VkIGZvciBhcHBsaWNhdGlvbiBhdXRoZW50aWNhdGlvbiByYXRoZXIgdGhhbiBzYXkN Cm5ldHdvcmsgYXV0aGVudGljYXRpb24uDQpIb3dldmVyLCBpbiB5b3VyIGV4YW1wbGUgeW91IHN1 Z2dlc3QgdGhhdCB0aGUgbGV2ZWwgb2YgYXNzdXJhbmNlDQpyZXF1aXJlZCBtaWdodCBkZXBlbmQg b24gd2hhdCBuZXR3b3JrIHRlY2hub2xvZ3kgYSB1c2VyIGlzIHVzaW5nLg0KSSdkIGxpa2UgdG8g YmV0dGVyIHVuZGVyc3RhbmQgaG93IHRoYXQgaXMgdHJ1ZSBpbiB5b3VyIGVudmlyb25tZW50Lg0K DQotLVNhbQ== ------=_001_NextPart772051273325_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
sorry, what I really want to say  is=20 that  different applications may require different lev= el of=20 assurance for authentication. For example, a financial application usually= =20 requires a higher level of assurance for authentication while the lev= el of=20 authentication of a general application may be lower. In addtion, the= =20 network technology a user is using just represents the environment of acce= ssing=20 target application, and the same application may require different level=20 assurance for authentication in different environment in order to guarante= e the=20 security of services.
Wei Juan
 
Date: 2013-09-26 21:26
To: Wei Juan=
CC: abfab
Subject: Re: [abfab] I-D Action:=20 draft-wei-abfab-usecases-00.txt
ABFAB is typically used for application authentication rather than=20 say
network authentication.
However, in your example you suggest that the level of assurance
required might depend on what network technology a user is using.
I'd like to better understand how that is true in your environment.
 
--Sam
------=_001_NextPart772051273325_=------ From hartmans@painless-security.com Thu Sep 26 07:27:58 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 510E721F9BF2 for ; Thu, 26 Sep 2013 07:27:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPz3MFhNb91I for ; Thu, 26 Sep 2013 07:27:49 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 61B1521F92E7 for ; Thu, 26 Sep 2013 07:27:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B606120201; Thu, 26 Sep 2013 10:26:50 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsfcRsw8_QJc; Thu, 26 Sep 2013 10:26:50 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 26 Sep 2013 10:26:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9630980D3A; Thu, 26 Sep 2013 10:27:42 -0400 (EDT) From: Sam Hartman To: "Wei Juan" References: <2013092609111720898326@gmail.com> <2013092622001731879657@gmail.com> Date: Thu, 26 Sep 2013 10:27:42 -0400 In-Reply-To: <2013092622001731879657@gmail.com> (Wei Juan's message of "Thu, 26 Sep 2013 22:00:23 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab Subject: Re: [abfab] I-D Action: draft-wei-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 14:27:58 -0000 I think a better example of environment might be location than network technology. At least in enterprize contexts, it's somewhat common to require higher LOA when accessing a resource from off-site than when accessing it from within a secure space. From iesg-secretary@ietf.org Fri Sep 27 07:25:19 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4A221F9385; Fri, 27 Sep 2013 07:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haZ+Nq0+E0dh; Fri, 27 Sep 2013 07:25:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 952A721F9808; Fri, 27 Sep 2013 07:25:17 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130927142517.11230.35151.idtracker@ietfa.amsl.com> Date: Fri, 27 Sep 2013 07:25:17 -0700 Cc: abfab mailing list , abfab chair , RFC Editor Subject: [abfab] Protocol Action: 'Update to the EAP Applicability Statement for ABFAB' to Proposed Standard (draft-ietf-abfab-eapapplicability-06.txt) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 14:25:19 -0000 The IESG has approved the following document: - 'Update to the EAP Applicability Statement for ABFAB' (draft-ietf-abfab-eapapplicability-06.txt) as Proposed Standard This document is the product of the Application Bridging for Federated Access Beyond web Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ Technical Summary The EAP applicability statement in [RFC3748] defines the scope of the Extensible Authentication Protocol to be "for use in network access authentication, where IP layer connectivity may not be available.", and states that "Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED.". While some of the recommendation against usage of EAP for bulk data transport is still valid, some of the other provisions in the applicability statement have turned out to be too narrow. This document describes the applicability of EAP for (certain) application layer access decisions. Working Group Summary The WG (as well as emu) has debated extensively as to whether to revise the EAP-applicability statement completely or to focus on the particular requirements for abfab. It was decided to keep it limited to abfab in the interest of progressing the work items. Document Quality This being an applicability statement, there is no question of implementations. What can be said is that the existing implementations of abfab use the relaxed applicability statement. Personnel Shepherd: Klaas Wierenga AD: Stephen Farell RFC Editor Note Please add a new sentence to the end of section 3 (and the associated informative reference), so: OLD, at the end of section 3: Circumstances might require that applications need to perform conversion of identities from an application specific character set to UTF-8 or another character set required by a particular EAP method. NEW Circumstances might require that applications need to perform conversion of identities from an application specific character set to UTF-8 or another character set required by a particular EAP method. See also [draft-ietf-radext-nai], Section 2.6, for information about normalization of identifiers. NEW, section 7.2: Add [draft-ietf-radext-nai] From ietf@augustcellars.com Fri Sep 27 09:41:05 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43B921E80FD for ; Fri, 27 Sep 2013 09:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJNQzh7n3TbP for ; Fri, 27 Sep 2013 09:41:01 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id F162021F9CB5 for ; Fri, 27 Sep 2013 09:41:00 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 655EB38F63; Fri, 27 Sep 2013 09:40:58 -0700 (PDT) From: "Jim Schaad" To: "'David Chadwick'" References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> In-Reply-To: <523FE430.4040106@kent.ac.uk> Date: Fri, 27 Sep 2013 09:39:44 -0700 Message-ID: <01ee01cebba0$2dc575c0$89506140$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNh8/g/3Dn/OsA74DmeXHbDLNwJ4gKGmmcwAen3FK2WjnpagA== Content-Language: en-us Cc: abfab@ietf.org, 'Sam Hartman' Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 16:41:05 -0000 > -----Original Message----- > From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] > Sent: Sunday, September 22, 2013 11:48 PM > To: Jim Schaad > Cc: 'Sam Hartman'; abfab@ietf.org > Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch > > Apologies from me as well Sam, here are my comments on draft-ietf-abfab- > arch-07.txt > > Technical > > Section 1. > i) Data Minimization and User Participation: "There is currently no direct client > participation in this decision." (i.e. release of identity attributes). We should > say at this juncture that this is a major deficiency in existing federated > systems, since the user does not have full consent or control over which of his > identity attributes are released. This should be fixed in Abfab Based on the current set of abilities, there is no real way to fix this in ABFAB itself. I have thought of a proposed way to deal with this, but am unsure where it would be bested addressed or even what the solution to the problem would include. If I was solving this today, I would define a couple of experimental items in the TEAP protocol to allow for this to be done, however given that this would definitely be experimental and the fact that the EMU group is trying to go away it is not clear that this would be the group to do it. I don't think that ABFAB is really the place to do it either. I think that there needs to be some clear discussions about how this should be attacked as a problem before we even think about it. In some instances it is not clear that that is any solution to the problem, such as when a SAML request goes from the server to the IDP after the EAP authentication has been completed. The only thing that could be possible in this case is for a profile to be agreed on by the client and the IDP at the authentication time and for the IDP to enforce it at a later time. Given how unclear a solution would be for this I don't see any reason to hold this document up over the fact that the ability for the user to fully consent does not exist. This has always been the case for RADIUS and Diameter as well. We can potentially strengthen the language that is present, although I don't really see any need to do that either. At present I do not plan to make any changes to address this issue. > > ii) Section 1.1.1 > Authenticator should be defined before it is used. This has been fixed. > > iii) I dont buy into your whiteboard example of single entity authentication, > because a hacked whiteboard could trick the user into opening the wrong file, > which could be disasterous during an important business meeting. SO mutual > authentication is needed here as well. If you want an example where mutual > authentication is not important, its one where either the information being > accessed is of very little value to the accessor so that it does not matter if it is > erroneous information or not, or one where it does not matter who the > accessor is i.e. its public information. I don't see how having mutual authentication is going to solve anything in the case of a hacked whiteboard getting the user to display the wrong file or stealing credentials from the user in the case that it the initiator. There would be no issue of the file server releasing the file to the whiteboard if authorized by the user in all cases. The only question would be if the file server decided based on the name of the whiteboard that it should not be released, but it would be the user that is authenticated in this case and not the whiteboard so there would not be mutual authentication between the file server and the whiteboard in any case. I will send to the list updated text on this. After a brief exchange with Sam I believe this has some errors in it that need to be clarified. > > > > Editorials > > Section 1 > the Relying Party know specific -> the Relying Party to know specific Fixed > > Section 1.1 > the document uses either a the ABFAB term -> the document uses either the > ABFAB term The table should be labelled "Table 1. Terminology" Fixed > > Section 1.4 > a SAML Attribute Requests -> a SAML Attribute Request Fixed > > Section 2.1.3 > to validate theg identities -> to validate the identities The trust mechanism > must to ensure that -> The trust mechanism must ensure that An RP can > submit a request directly to a federation. -> An RP can submit a request > directly to the correct federation. > information about given a IdP -> information about a given IdP Fixed > > regards > > David > > On 23/09/2013 05:21, Jim Schaad wrote: > > My apologies for not getting these out in last call. > > One of these (the re-authentication section comment) is serious enough > > that I believe it needs to be resolved prior to sending the document on. > > > > > > Section 1.1.1 > > > > old: Typically when considering channel binding > > > > new: > > > > Typicially when considering both EAP and GSS-API channel binding > > > > [JLS] done > > > > Later in the white board example > > channel binding should be GSS-API channel binding > > > > [JLS] I don't understand this. The two sentences which talk about the > > whiteboard do not have the phrase channel binding in them. The next > > sentence would seem to apply to either GSS-API or EAP channel binding. > > Which sentence did you think should be changed? > > > > Section 2.3.3 > > > > This is unlikely to survive IETF last call unchallenged. > > > > [JLS] Quite correct - this should say - please present your > > authentication token > > > > ... > > > > > > There are circumstances where the server will want to > > have the client re-authenticate itself. > > These include very long sessions, where the original > > authentication is time limited or cases where in order to complete an > > operation a different authentication is required. > > GSS-EAP does not have any mechanism for the server to > > initiate a re-authentication as all authentication operation start from the > client. > > If a protocol using GSS-EAP needs to support > > re-authentication that is initiated by the server, then a request from > > the server to the client for the re-authentication to start needs to > > be placed in the protocol. > > > > > > Clients can re-use the existing secure connection > > established by GSS-API to run the new authentication in by calling > GSS_Init_sec_context. > > At this point a full re-authentication will be done. > > > > > > What do you think needs to be added to this? > > > > Section 3.4 > > > > old: shared private key > > new: shared session key > > > > [JLS] - Fixed > > > > Section 2.2.2 refers to sectian 6.1 for a description of GSS-API > > channel binding; that seems wrong > > > > [JLS] Section 6 has disappeared - so I am killing that portion of the > > section. > > > >> -----Original Message----- > >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On > >> Behalf Of Sam Hartman > >> Sent: Wednesday, September 04, 2013 6:04 AM > >> To: abfab@ietf.org > >> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch > >> > >> Sent from wrong address. > >> > > > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab > > From hartmans@painless-security.com Fri Sep 27 10:57:42 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAE411E8109 for ; Fri, 27 Sep 2013 10:57: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7td9rEkWk6BB for ; Fri, 27 Sep 2013 10:57:35 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C2D9C11E8162 for ; Fri, 27 Sep 2013 10:56:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C5EA82031B for ; Fri, 27 Sep 2013 13:55:51 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzGtp0zfz_fa for ; Fri, 27 Sep 2013 13:55:51 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Fri, 27 Sep 2013 13:55:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 244A28074C; Fri, 27 Sep 2013 13:56:47 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 27 Sep 2013 13:56:47 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] Updates to draft-ietf-abfab-gss-eap for eap applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 17:57:42 -0000 Folks, I'm forgetting whether we thought any updates were necessary to the main gss-eap spec based on the applicability changes. I recall that we decided reauthentication could be covered in the arch document. But I don't remember if updates were required for any of the other issues. --Sam From leifj@sunet.se Fri Sep 27 11:44:09 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 397C621F9425 for ; Fri, 27 Sep 2013 11:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-77Hg+yXQlX for ; Fri, 27 Sep 2013 11:44:04 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 355AC21F8319 for ; Fri, 27 Sep 2013 11:44:03 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8RIhkpK007728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 27 Sep 2013 20:43:46 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id r8RIhhvO024508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Sep 2013 20:43:45 +0200 (CEST) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.244] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.1.2) (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for abfab@ietf.org; Fri, 27 Sep 2013 20:43:41 +0200 Message-ID: <5245D1DC.9080100@sunet.se> Date: Fri, 27 Sep 2013 20:43:40 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09KuiHKH0 - 0acff0d5a7a8 - 20130927 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] Updates to draft-ietf-abfab-gss-eap for eap applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 18:44:09 -0000 On 09/27/2013 07:56 PM, Sam Hartman wrote: > > Folks, I'm forgetting whether we thought any updates were necessary to > the main gss-eap spec based on the applicability changes. > > I recall that we decided reauthentication could be covered in the arch > document. > > But I don't remember if updates were required for any of the other > issues. > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab There is an rfc editors note attached. I think that covers everything. From d.w.chadwick@kent.ac.uk Sat Sep 28 05:08:34 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8FA11E812D for ; Sat, 28 Sep 2013 05:08:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nqlU71yoNRN for ; Sat, 28 Sep 2013 05:08:29 -0700 (PDT) Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8C421F8E8E for ; Sat, 28 Sep 2013 05:08:28 -0700 (PDT) Received: from [176.12.107.140] (helo=[10.101.1.208]) by mx3.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1VPtJu-0006Jy-7u; Sat, 28 Sep 2013 13:08:22 +0100 Message-ID: <5246C6B1.9030500@kent.ac.uk> Date: Sat, 28 Sep 2013 13:08:17 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jim Schaad References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> <01ee01cebba0$2dc575c0$89506140$@augustcellars.com> In-Reply-To: <01ee01cebba0$2dc575c0$89506140$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, 'Sam Hartman' Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2013 12:08:34 -0000 Hi Jim thankyou for your long answer. Firstly I agree that the answer is not trivial, especially once you consider that an SP may require attributes from multiple IdPs/AAs. But leaving attribute aggregation aside, lets discuss conceptually what is needed in the simple single IDP case, before trying to figure out how to map this into the ABFAB protocols. 1. The SP is the only entity that knows which attributes are needed to access which of its services 2. The SP may not know this at the time of authn, as the user may not have chosen the service he wants to access at login time (assuming the SP has multiple services requiring different authz attributes). 3. If the user moves between the different services of the SP, using SSO, then different attributes may be needed at different times during the same authn session 4. DP legislation indicates that the SP should minimise the attributes it asks for, so a "grab them all" approach at authn time is not in the spirit of DP, and may be illegal in some juridictions 5. This indicates to me that the SP should be able to send its attribute requirements (or authz policy) to the IdP at arbitrary points in time during the user's session, and that the IDP should be able to send back attribute assertions that match the policy whenever requested to, providing that the user consents to this (and the IDP knows that the user has). Is this challenge something the ABFAB group would like to take on, or should there be a BOF at a future IETF meeting to discuss this? regards David On 27/09/2013 17:39, Jim Schaad wrote: > > >> -----Original Message----- >> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] >> Sent: Sunday, September 22, 2013 11:48 PM >> To: Jim Schaad >> Cc: 'Sam Hartman'; abfab@ietf.org >> Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >> >> Apologies from me as well Sam, here are my comments on draft-ietf-abfab- >> arch-07.txt >> >> Technical >> >> Section 1. >> i) Data Minimization and User Participation: "There is currently no direct > client >> participation in this decision." (i.e. release of identity attributes). We > should >> say at this juncture that this is a major deficiency in existing federated >> systems, since the user does not have full consent or control over which > of his >> identity attributes are released. This should be fixed in Abfab > > Based on the current set of abilities, there is no real way to fix this in > ABFAB itself. I have thought of a proposed way to deal with this, but am > unsure where it would be bested addressed or even what the solution to the > problem would include. > > If I was solving this today, I would define a couple of experimental items > in the TEAP protocol to allow for this to be done, however given that this > would definitely be experimental and the fact that the EMU group is trying > to go away it is not clear that this would be the group to do it. I don't > think that ABFAB is really the place to do it either. I think that there > needs to be some clear discussions about how this should be attacked as a > problem before we even think about it. In some instances it is not clear > that that is any solution to the problem, such as when a SAML request goes > from the server to the IDP after the EAP authentication has been completed. > The only thing that could be possible in this case is for a profile to be > agreed on by the client and the IDP at the authentication time and for the > IDP to enforce it at a later time. > > Given how unclear a solution would be for this I don't see any reason to > hold this document up over the fact that the ability for the user to fully > consent does not exist. This has always been the case for RADIUS and > Diameter as well. > > We can potentially strengthen the language that is present, although I don't > really see any need to do that either. At present I do not plan to make any > changes to address this issue. > >> >> ii) Section 1.1.1 >> Authenticator should be defined before it is used. > > This has been fixed. > >> >> iii) I dont buy into your whiteboard example of single entity > authentication, >> because a hacked whiteboard could trick the user into opening the wrong > file, >> which could be disasterous during an important business meeting. SO mutual >> authentication is needed here as well. If you want an example where mutual >> authentication is not important, its one where either the information > being >> accessed is of very little value to the accessor so that it does not > matter if it is >> erroneous information or not, or one where it does not matter who the >> accessor is i.e. its public information. > > I don't see how having mutual authentication is going to solve anything in > the case of a hacked whiteboard getting the user to display the wrong file > or stealing credentials from the user in the case that it the initiator. > There would be no issue of the file server releasing the file to the > whiteboard if authorized by the user in all cases. The only question would > be if the file server decided based on the name of the whiteboard that it > should not be released, but it would be the user that is authenticated in > this case and not the whiteboard so there would not be mutual authentication > between the file server and the whiteboard in any case. > > I will send to the list updated text on this. After a brief exchange with > Sam I believe this has some errors in it that need to be clarified. > >> >> >> >> Editorials >> >> Section 1 >> the Relying Party know specific -> the Relying Party to know specific > Fixed > >> >> Section 1.1 >> the document uses either a the ABFAB term -> the document uses either the >> ABFAB term The table should be labelled "Table 1. Terminology" > Fixed > >> >> Section 1.4 >> a SAML Attribute Requests -> a SAML Attribute Request > Fixed > >> >> Section 2.1.3 >> to validate theg identities -> to validate the identities The trust > mechanism >> must to ensure that -> The trust mechanism must ensure that An RP can >> submit a request directly to a federation. -> An RP can submit a request >> directly to the correct federation. >> information about given a IdP -> information about a given IdP > > Fixed > >> >> regards >> >> David >> >> On 23/09/2013 05:21, Jim Schaad wrote: >>> My apologies for not getting these out in last call. >>> One of these (the re-authentication section comment) is serious enough >>> that I believe it needs to be resolved prior to sending the document on. >>> >>> >>> Section 1.1.1 >>> >>> old: Typically when considering channel binding >>> >>> new: >>> >>> Typicially when considering both EAP and GSS-API channel binding >>> >>> [JLS] done >>> >>> Later in the white board example >>> channel binding should be GSS-API channel binding >>> >>> [JLS] I don't understand this. The two sentences which talk about the >>> whiteboard do not have the phrase channel binding in them. The next >>> sentence would seem to apply to either GSS-API or EAP channel binding. >>> Which sentence did you think should be changed? >>> >>> Section 2.3.3 >>> >>> This is unlikely to survive IETF last call unchallenged. >>> >>> [JLS] Quite correct - this should say - please present your >>> authentication token >>> >>> ... >>> >>> >>> There are circumstances where the server will want to >>> have the client re-authenticate itself. >>> These include very long sessions, where the original >>> authentication is time limited or cases where in order to complete an >>> operation a different authentication is required. >>> GSS-EAP does not have any mechanism for the server to >>> initiate a re-authentication as all authentication operation start from > the >> client. >>> If a protocol using GSS-EAP needs to support >>> re-authentication that is initiated by the server, then a request from >>> the server to the client for the re-authentication to start needs to >>> be placed in the protocol. >>> >>> >>> Clients can re-use the existing secure connection >>> established by GSS-API to run the new authentication in by calling >> GSS_Init_sec_context. >>> At this point a full re-authentication will be done. >>> >>> >>> What do you think needs to be added to this? >>> >>> Section 3.4 >>> >>> old: shared private key >>> new: shared session key >>> >>> [JLS] - Fixed >>> >>> Section 2.2.2 refers to sectian 6.1 for a description of GSS-API >>> channel binding; that seems wrong >>> >>> [JLS] Section 6 has disappeared - so I am killing that portion of the >>> section. >>> >>>> -----Original Message----- >>>> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On >>>> Behalf Of Sam Hartman >>>> Sent: Wednesday, September 04, 2013 6:04 AM >>>> To: abfab@ietf.org >>>> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >>>> >>>> Sent from wrong address. >>>> >>> >>> >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >>> > From kwiereng@cisco.com Sun Sep 29 00:13:00 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E04E21F9DFC for ; Sun, 29 Sep 2013 00:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGoaP-qvAisO for ; Sun, 29 Sep 2013 00:12:55 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 11BBC21F9EA2 for ; Sun, 29 Sep 2013 00:12:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10710; q=dns/txt; s=iport; t=1380438772; x=1381648372; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yP+V8fyXcw1IBna3OMVEhEnuaw889bgfsbVWaU+hCmI=; b=T4LZqZctv02SrsbdD5aN4c5X+o5PyTeHRo155ByMSmJJQYGaZMiZDIqo xDfDYzT1fScZrNu+6Opj97++hT5631WQOrawvgsyQ3C6lVrUmSWueh8ts CpjLWD9I8eKLJ6P4fp2t7VzWLSRPiU7L9gDTctfsNuNfUDw34ABdMzomt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAOnRR1KtJV2d/2dsb2JhbABRCQ6CeTjBR4EgFnSCJQEBAQMBAQEBJBM0CwUHBAIBCA4DBAEBARYBBwkHJwsUCQgCBA4FG4dlBgy6YwSODwOBDDMHBgwBgwyBAwOUIoNdkXmCZT+BaAIHFwY X-IronPort-AV: E=Sophos;i="4.90,1003,1371081600"; d="scan'208";a="265622891" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 29 Sep 2013 07:12:51 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8T7CoQC021214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Sep 2013 07:12:50 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.246]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Sun, 29 Sep 2013 02:12:50 -0500 From: "Klaas Wierenga (kwiereng)" To: David Chadwick Thread-Topic: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch Thread-Index: AQHOqW9Ljfs4RjzrO0y4Pguxgej5HpnTKZoAgAApGwCABu6VAIABRn2AgADr90E= Date: Sun, 29 Sep 2013 07:12:49 +0000 Message-ID: <4C04F0D0-6105-448A-82EF-C62F6392F828@cisco.com> References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> <01ee01cebba0$2dc575c0$89506140$@augustcellars.com>, <5246C6B1.9030500@kent.ac.uk> In-Reply-To: <5246C6B1.9030500@kent.ac.uk> Accept-Language: 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: Jim Schaad , Sam Hartman , "abfab@ietf.org" Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 07:13:00 -0000 Hi David, > On 28 sep. 2013, at 14:08, "David Chadwick" wro= te: >=20 > Hi Jim >=20 > thankyou for your long answer. Firstly I agree that the answer is not tri= vial, especially once you consider that an SP may require attributes from m= ultiple IdPs/AAs. But leaving attribute aggregation aside, lets discuss con= ceptually what is needed in the simple single IDP case, before trying to fi= gure out how to map this into the ABFAB protocols. >=20 > 1. The SP is the only entity that knows which attributes are needed to ac= cess which of its services > 2. The SP may not know this at the time of authn, as the user may not hav= e chosen the service he wants to access at login time (assuming the SP has = multiple services requiring different authz attributes). > 3. If the user moves between the different services of the SP, using SSO,= then different attributes may be needed at different times during the same= authn session > 4. DP legislation indicates that the SP should minimise the attributes it= asks for, so a "grab them all" approach at authn time is not in the spirit= of DP, and may be illegal in some juridictions > 5. This indicates to me that the SP should be able to send its attribute = requirements (or authz policy) to the IdP at arbitrary points in time durin= g the user's session, and that the IDP should be able to send back attribut= e assertions that match the policy whenever requested to, providing that th= e user consents to this (and the IDP knows that the user has). I believe these are all fair statements and indicative of where we want fed= erated identity systems to be eventually. At the same time, I think this is= beyond the current scope of ABFAB.=20 > Is this challenge something the ABFAB group would like to take on, or sho= uld there be a BOF at a future IETF meeting to discuss this? With my chair hat on I'd say let's finish the current set of documents and = not let the scope creep. Having said that, once we are done I'd welcome a d= iscussion on how to address valid concerns about user consent and privacy, = whether that would lead to concrete ideas and/or a WG (a rechartered ABFAB = or new doesn't really matter to me). Klaas >=20 > regards >=20 > David >=20 >> On 27/09/2013 17:39, Jim Schaad wrote: >>=20 >>=20 >>> -----Original Message----- >>> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] >>> Sent: Sunday, September 22, 2013 11:48 PM >>> To: Jim Schaad >>> Cc: 'Sam Hartman'; abfab@ietf.org >>> Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >>>=20 >>> Apologies from me as well Sam, here are my comments on draft-ietf-abfab= - >>> arch-07.txt >>>=20 >>> Technical >>>=20 >>> Section 1. >>> i) Data Minimization and User Participation: "There is currently no dir= ect >> client >>> participation in this decision." (i.e. release of identity attributes).= We >> should >>> say at this juncture that this is a major deficiency in existing federa= ted >>> systems, since the user does not have full consent or control over whic= h >> of his >>> identity attributes are released. This should be fixed in Abfab >>=20 >> Based on the current set of abilities, there is no real way to fix this = in >> ABFAB itself. I have thought of a proposed way to deal with this, but a= m >> unsure where it would be bested addressed or even what the solution to t= he >> problem would include. >>=20 >> If I was solving this today, I would define a couple of experimental ite= ms >> in the TEAP protocol to allow for this to be done, however given that th= is >> would definitely be experimental and the fact that the EMU group is tryi= ng >> to go away it is not clear that this would be the group to do it. I don= 't >> think that ABFAB is really the place to do it either. I think that ther= e >> needs to be some clear discussions about how this should be attacked as = a >> problem before we even think about it. In some instances it is not clea= r >> that that is any solution to the problem, such as when a SAML request go= es >> from the server to the IDP after the EAP authentication has been complet= ed. >> The only thing that could be possible in this case is for a profile to b= e >> agreed on by the client and the IDP at the authentication time and for t= he >> IDP to enforce it at a later time. >>=20 >> Given how unclear a solution would be for this I don't see any reason to >> hold this document up over the fact that the ability for the user to ful= ly >> consent does not exist. This has always been the case for RADIUS and >> Diameter as well. >>=20 >> We can potentially strengthen the language that is present, although I d= on't >> really see any need to do that either. At present I do not plan to make= any >> changes to address this issue. >>=20 >>>=20 >>> ii) Section 1.1.1 >>> Authenticator should be defined before it is used. >>=20 >> This has been fixed. >>=20 >>>=20 >>> iii) I dont buy into your whiteboard example of single entity >> authentication, >>> because a hacked whiteboard could trick the user into opening the wrong >> file, >>> which could be disasterous during an important business meeting. SO mut= ual >>> authentication is needed here as well. If you want an example where mut= ual >>> authentication is not important, its one where either the information >> being >>> accessed is of very little value to the accessor so that it does not >> matter if it is >>> erroneous information or not, or one where it does not matter who the >>> accessor is i.e. its public information. >>=20 >> I don't see how having mutual authentication is going to solve anything = in >> the case of a hacked whiteboard getting the user to display the wrong fi= le >> or stealing credentials from the user in the case that it the initiator. >> There would be no issue of the file server releasing the file to the >> whiteboard if authorized by the user in all cases. The only question wo= uld >> be if the file server decided based on the name of the whiteboard that i= t >> should not be released, but it would be the user that is authenticated i= n >> this case and not the whiteboard so there would not be mutual authentica= tion >> between the file server and the whiteboard in any case. >>=20 >> I will send to the list updated text on this. After a brief exchange wi= th >> Sam I believe this has some errors in it that need to be clarified. >>=20 >>>=20 >>>=20 >>>=20 >>> Editorials >>>=20 >>> Section 1 >>> the Relying Party know specific -> the Relying Party to know specific >> Fixed >>=20 >>>=20 >>> Section 1.1 >>> the document uses either a the ABFAB term -> the document uses either t= he >>> ABFAB term The table should be labelled "Table 1. Terminology" >> Fixed >>=20 >>>=20 >>> Section 1.4 >>> a SAML Attribute Requests -> a SAML Attribute Request >> Fixed >>=20 >>>=20 >>> Section 2.1.3 >>> to validate theg identities -> to validate the identities The trust >> mechanism >>> must to ensure that -> The trust mechanism must ensure that An RP can >>> submit a request directly to a federation. -> An RP can submit a reques= t >>> directly to the correct federation. >>> information about given a IdP -> information about a given IdP >>=20 >> Fixed >>=20 >>>=20 >>> regards >>>=20 >>> David >>>=20 >>>> On 23/09/2013 05:21, Jim Schaad wrote: >>>> My apologies for not getting these out in last call. >>>> One of these (the re-authentication section comment) is serious enough >>>> that I believe it needs to be resolved prior to sending the document o= n. >>>>=20 >>>>=20 >>>> Section 1.1.1 >>>>=20 >>>> old: Typically when considering channel binding >>>>=20 >>>> new: >>>>=20 >>>> Typicially when considering both EAP and GSS-API channel binding >>>>=20 >>>> [JLS] done >>>>=20 >>>> Later in the white board example >>>> channel binding should be GSS-API channel binding >>>>=20 >>>> [JLS] I don't understand this. The two sentences which talk about t= he >>>> whiteboard do not have the phrase channel binding in them. The next >>>> sentence would seem to apply to either GSS-API or EAP channel binding. >>>> Which sentence did you think should be changed? >>>>=20 >>>> Section 2.3.3 >>>>=20 >>>> This is unlikely to survive IETF last call unchallenged. >>>>=20 >>>> [JLS] Quite correct - this should say - please present your >>>> authentication token >>>>=20 >>>> ... >>>>=20 >>>> >>>> There are circumstances where the server will want to >>>> have the client re-authenticate itself. >>>> These include very long sessions, where the original >>>> authentication is time limited or cases where in order to complete an >>>> operation a different authentication is required. >>>> GSS-EAP does not have any mechanism for the server to >>>> initiate a re-authentication as all authentication operation start fro= m >> the >>> client. >>>> If a protocol using GSS-EAP needs to support >>>> re-authentication that is initiated by the server, then a request from >>>> the server to the client for the re-authentication to start needs to >>>> be placed in the protocol. >>>> >>>> >>>> Clients can re-use the existing secure connection >>>> established by GSS-API to run the new authentication in by calling >>> GSS_Init_sec_context. >>>> At this point a full re-authentication will be done. >>>> >>>>=20 >>>> What do you think needs to be added to this? >>>>=20 >>>> Section 3.4 >>>>=20 >>>> old: shared private key >>>> new: shared session key >>>>=20 >>>> [JLS] - Fixed >>>>=20 >>>> Section 2.2.2 refers to sectian 6.1 for a description of GSS-API >>>> channel binding; that seems wrong >>>>=20 >>>> [JLS] Section 6 has disappeared - so I am killing that portion of the >>>> section. >>>>=20 >>>>> -----Original Message----- >>>>> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On >>>>> Behalf Of Sam Hartman >>>>> Sent: Wednesday, September 04, 2013 6:04 AM >>>>> To: abfab@ietf.org >>>>> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >>>>>=20 >>>>> Sent from wrong address. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> abfab mailing list >>>> abfab@ietf.org >>>> https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From d.w.chadwick@kent.ac.uk Sun Sep 29 12:43:57 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA6B11E810A for ; Sun, 29 Sep 2013 12:43:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id homP+Sr7lqfY for ; Sun, 29 Sep 2013 12:43:53 -0700 (PDT) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id B5E7E11E8101 for ; Sun, 29 Sep 2013 12:43:52 -0700 (PDT) Received: from [176.12.107.140] (helo=[10.101.1.209]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1VQMuA-0001EB-NC; Sun, 29 Sep 2013 20:43:49 +0100 Message-ID: <524882A8.9050003@kent.ac.uk> Date: Sun, 29 Sep 2013 20:42:32 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jim Schaad References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> <01ee01cebba0$2dc575c0$89506140$@augustcellars.com> <5246C6B1.9030500@kent.ac.uk> <00d701cebca3$37ead0f0$a7c072d0$@augutscellars.com> In-Reply-To: <00d701cebca3$37ead0f0$a7c072d0$@augutscellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, Trevor Freeman Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 29 Sep 2013 19:43:57 -0000 I would be interested in giving a presentation about this, but unfortunately I cannot attend the next IETF meeting as it clashes with Openstack in Honk Kong (where I am also giving a presentation on Federation). But the first meeting next year could be suitable regards David On 29/09/2013 00:34, Jim Schaad wrote: > A BOF just to discuss the problem without some idea of a solution would > probably not be very productive. > > I don't think that this problem is restricted to just ABFAB - I think that > it is of interest to other groups and would therefore be reluctant to do > more than a preliminary discussion in the ABFAB group to see if we even > agree on the problem. > > I would suggest you ask the ABFAB chairs if there is room for some type of > presentation if you are interested in doing a short presentation of what you > see as the problem space and why it is not an easy solution. I have added > Trevor because I think that he would be interested in discussing this in the > context of the Plasma work. > > Jim > > >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of >> David Chadwick >> Sent: Saturday, September 28, 2013 5:08 AM >> To: Jim Schaad >> Cc: abfab@ietf.org; 'Sam Hartman' >> Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >> >> Hi Jim >> >> thankyou for your long answer. Firstly I agree that the answer is not > trivial, >> especially once you consider that an SP may require attributes from > multiple >> IdPs/AAs. But leaving attribute aggregation aside, lets discuss > conceptually >> what is needed in the simple single IDP case, before trying to figure out > how >> to map this into the ABFAB protocols. >> >> 1. The SP is the only entity that knows which attributes are needed to > access >> which of its services 2. The SP may not know this at the time of authn, as > the >> user may not have chosen the service he wants to access at login time >> (assuming the SP has multiple services requiring different authz > attributes). >> 3. If the user moves between the different services of the SP, using SSO, > then >> different attributes may be needed at different times during the same > authn >> session 4. DP legislation indicates that the SP should minimise the > attributes it >> asks for, so a "grab them all" approach at authn time is not in the spirit > of DP, >> and may be illegal in some juridictions 5. This indicates to me that the > SP >> should be able to send its attribute requirements (or authz policy) to the > IdP >> at arbitrary points in time during the user's session, and that the IDP > should be >> able to send back attribute assertions that match the policy whenever >> requested to, providing that the user consents to this (and the IDP knows > that >> the user has). >> >> Is this challenge something the ABFAB group would like to take on, or > should >> there be a BOF at a future IETF meeting to discuss this? >> >> regards >> >> David >> >> On 27/09/2013 17:39, Jim Schaad wrote: >>> >>> >>>> -----Original Message----- >>>> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk] >>>> Sent: Sunday, September 22, 2013 11:48 PM >>>> To: Jim Schaad >>>> Cc: 'Sam Hartman'; abfab@ietf.org >>>> Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >>>> >>>> Apologies from me as well Sam, here are my comments on >>>> draft-ietf-abfab- arch-07.txt >>>> >>>> Technical >>>> >>>> Section 1. >>>> i) Data Minimization and User Participation: "There is currently no >>>> direct >>> client >>>> participation in this decision." (i.e. release of identity >>>> attributes). We >>> should >>>> say at this juncture that this is a major deficiency in existing >>>> federated systems, since the user does not have full consent or >>>> control over which >>> of his >>>> identity attributes are released. This should be fixed in Abfab >>> >>> Based on the current set of abilities, there is no real way to fix >>> this in ABFAB itself. I have thought of a proposed way to deal with >>> this, but am unsure where it would be bested addressed or even what >>> the solution to the problem would include. >>> >>> If I was solving this today, I would define a couple of experimental >>> items in the TEAP protocol to allow for this to be done, however given >>> that this would definitely be experimental and the fact that the EMU >>> group is trying to go away it is not clear that this would be the >>> group to do it. I don't think that ABFAB is really the place to do it >>> either. I think that there needs to be some clear discussions about >>> how this should be attacked as a problem before we even think about >>> it. In some instances it is not clear that that is any solution to >>> the problem, such as when a SAML request goes from the server to the IDP >> after the EAP authentication has been completed. >>> The only thing that could be possible in this case is for a profile to >>> be agreed on by the client and the IDP at the authentication time and >>> for the IDP to enforce it at a later time. >>> >>> Given how unclear a solution would be for this I don't see any reason >>> to hold this document up over the fact that the ability for the user >>> to fully consent does not exist. This has always been the case for >>> RADIUS and Diameter as well. >>> >>> We can potentially strengthen the language that is present, although I >>> don't really see any need to do that either. At present I do not plan >>> to make any changes to address this issue. >>> >>>> >>>> ii) Section 1.1.1 >>>> Authenticator should be defined before it is used. >>> >>> This has been fixed. >>> >>>> >>>> iii) I dont buy into your whiteboard example of single entity >>> authentication, >>>> because a hacked whiteboard could trick the user into opening the >>>> wrong >>> file, >>>> which could be disasterous during an important business meeting. SO >>>> mutual authentication is needed here as well. If you want an example >>>> where mutual authentication is not important, its one where either >>>> the information >>> being >>>> accessed is of very little value to the accessor so that it does not >>> matter if it is >>>> erroneous information or not, or one where it does not matter who the >>>> accessor is i.e. its public information. >>> >>> I don't see how having mutual authentication is going to solve >>> anything in the case of a hacked whiteboard getting the user to >>> display the wrong file or stealing credentials from the user in the case > that it >> the initiator. >>> There would be no issue of the file server releasing the file to the >>> whiteboard if authorized by the user in all cases. The only question >>> would be if the file server decided based on the name of the >>> whiteboard that it should not be released, but it would be the user >>> that is authenticated in this case and not the whiteboard so there >>> would not be mutual authentication between the file server and the >> whiteboard in any case. >>> >>> I will send to the list updated text on this. After a brief exchange >>> with Sam I believe this has some errors in it that need to be clarified. >>> >>>> >>>> >>>> >>>> Editorials >>>> >>>> Section 1 >>>> the Relying Party know specific -> the Relying Party to know specific >>> Fixed >>> >>>> >>>> Section 1.1 >>>> the document uses either a the ABFAB term -> the document uses either >>>> the ABFAB term The table should be labelled "Table 1. Terminology" >>> Fixed >>> >>>> >>>> Section 1.4 >>>> a SAML Attribute Requests -> a SAML Attribute Request >>> Fixed >>> >>>> >>>> Section 2.1.3 >>>> to validate theg identities -> to validate the identities The trust >>> mechanism >>>> must to ensure that -> The trust mechanism must ensure that An RP can >>>> submit a request directly to a federation. -> An RP can submit a >>>> request directly to the correct federation. >>>> information about given a IdP -> information about a given IdP >>> >>> Fixed >>> >>>> >>>> regards >>>> >>>> David >>>> >>>> On 23/09/2013 05:21, Jim Schaad wrote: >>>>> My apologies for not getting these out in last call. >>>>> One of these (the re-authentication section comment) is serious >>>>> enough that I believe it needs to be resolved prior to sending the >> document on. >>>>> >>>>> >>>>> Section 1.1.1 >>>>> >>>>> old: Typically when considering channel binding >>>>> >>>>> new: >>>>> >>>>> Typicially when considering both EAP and GSS-API channel binding >>>>> >>>>> [JLS] done >>>>> >>>>> Later in the white board example >>>>> channel binding should be GSS-API channel binding >>>>> >>>>> [JLS] I don't understand this. The two sentences which talk about > the >>>>> whiteboard do not have the phrase channel binding in them. The next >>>>> sentence would seem to apply to either GSS-API or EAP channel binding. >>>>> Which sentence did you think should be changed? >>>>> >>>>> Section 2.3.3 >>>>> >>>>> This is unlikely to survive IETF last call unchallenged. >>>>> >>>>> [JLS] Quite correct - this should say - please present your >>>>> authentication token >>>>> >>>>> ... >>>>> >>>>> >>>>> There are circumstances where the server will want to >>>>> have the client re-authenticate itself. >>>>> These include very long sessions, where the original >>>>> authentication is time limited or cases where in order to complete >>>>> an operation a different authentication is required. >>>>> GSS-EAP does not have any mechanism for the server to >>>>> initiate a re-authentication as all authentication operation start >>>>> from >>> the >>>> client. >>>>> If a protocol using GSS-EAP needs to support >>>>> re-authentication that is initiated by the server, then a request >>>>> from the server to the client for the re-authentication to start >>>>> needs to be placed in the protocol. >>>>> >>>>> >>>>> Clients can re-use the existing secure connection >>>>> established by GSS-API to run the new authentication in by calling >>>> GSS_Init_sec_context. >>>>> At this point a full re-authentication will be done. >>>>> >>>>> >>>>> What do you think needs to be added to this? >>>>> >>>>> Section 3.4 >>>>> >>>>> old: shared private key >>>>> new: shared session key >>>>> >>>>> [JLS] - Fixed >>>>> >>>>> Section 2.2.2 refers to sectian 6.1 for a description of GSS-API >>>>> channel binding; that seems wrong >>>>> >>>>> [JLS] Section 6 has disappeared - so I am killing that portion of >>>>> the section. >>>>> >>>>>> -----Original Message----- >>>>>> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On >>>>>> Behalf Of Sam Hartman >>>>>> Sent: Wednesday, September 04, 2013 6:04 AM >>>>>> To: abfab@ietf.org >>>>>> Subject: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch >>>>>> >>>>>> Sent from wrong address. >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> abfab mailing list >>>>> abfab@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/abfab >>>>> >>> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Mon Sep 30 04:11:40 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3183021F9C36 for ; Mon, 30 Sep 2013 04:11:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPddE9-jyafB for ; Mon, 30 Sep 2013 04:11:24 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC7221F893E for ; Mon, 30 Sep 2013 04:11:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 842612037F; Mon, 30 Sep 2013 07:10:17 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o71nIQZzKwWf; Mon, 30 Sep 2013 07:10:17 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 30 Sep 2013 07:10:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E598C82A83; Mon, 30 Sep 2013 07:11:18 -0400 (EDT) From: Sam Hartman To: David Chadwick References: <052301ceb814$54e4caa0$feae5fe0$@augustcellars.com> <523FE430.4040106@kent.ac.uk> <01ee01cebba0$2dc575c0$89506140$@augustcellars.com> <5246C6B1.9030500@kent.ac.uk> <00d701cebca3$37ead0f0$a7c072d0$@augutscellars.com> <524882A8.9050003@kent.ac.uk> Date: Mon, 30 Sep 2013 07:11:18 -0400 In-Reply-To: <524882A8.9050003@kent.ac.uk> (David Chadwick's message of "Sun, 29 Sep 2013 20:42:32 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Trevor Freeman , abfab@ietf.org, Jim Schaad Subject: Re: [abfab] [Sam Hartman] comments on draft-ietf-abfab-arch X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 11:11:40 -0000 >>>>> "David" == David Chadwick writes: David> I would be interested in giving a presentation about this, David> but unfortunately I cannot attend the next IETF meeting as it David> clashes with Openstack in Honk Kong (where I am also giving a David> presentation on Federation). But the first meeting next year David> could be suitable In preparing a presentation, I'd ask that you focus a lot of effort on David> describing your assumptions. We found when discussing trust David> router that you had a different set of assumptions than the David> rest of the room and until those assumptions were described I David> found myself rather frustrated. I can already tell we're going to have similar issues with this discussion. As an example, in an earlier message, you stated that the SP is the only party that knows what attributes the SP needs. There are cases where that's true, but one of the major motivations behind the COI concept in Moonshot is to move knowledge about what attributes are required around so that the IDP has more information about this. Similarly you propose that authentication happen prior to deciding what service of a multi-service SP is used. That's one approach, but it has a lot of problems. One is that you may want a different federation fabric to use for different services. I believe you're stating things as facts that are simply one decomposition of the problem space. I don't mind examining that decomposition of the problem space. If there are enough folks interested in writing code and specs and reviewing them, I think doing work there could be very interesting. However, I think it's also important to understand that decomposition involves a lot of complexity. There are alternate organizations of the relationship between SP and IDP that may work better in different environments. I think understanding when complexity is necessary is quite desirable. --Sam