From internet-drafts@ietf.org Tue Feb 11 11:11:28 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8B71A0707; Tue, 11 Feb 2014 11:11:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4xrTEHT0xQY; Tue, 11 Feb 2014 11:11:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A74511A0713; Tue, 11 Feb 2014 11:11:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140211191116.30042.44506.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 11:11:16 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-11.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:11:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond Web (ABFAB) Architecture Authors : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Jim Schaad Filename : draft-ietf-abfab-arch-11.txt Pages : 44 Date : 2014-02-11 Abstract: Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-arch-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-arch-11 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Tue Feb 11 11:15:32 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF11A06E4 for ; Tue, 11 Feb 2014 11:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kP6jmd0ETSMi for ; Tue, 11 Feb 2014 11:15:30 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7811A06D0 for ; Tue, 11 Feb 2014 11:15:30 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 1291838EEE for ; Tue, 11 Feb 2014 11:15:30 -0800 (PST) From: "Jim Schaad" To: References: <20140211191116.30042.73681.idtracker@ietfa.amsl.com> In-Reply-To: <20140211191116.30042.73681.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2014 11:13:50 -0800 Message-ID: <005101cf275d$65725ff0$30571fd0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQB+gkQ2ABjX5pgdDWE19aJD/t5kLZ1RthvA Content-Language: en-us Subject: [abfab] FW: New Version Notification - draft-ietf-abfab-arch-11.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 19:15:32 -0000 This update deals with comments from the AD, the SecDir review and IETF = last call comments. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, February 11, 2014 11:11 AM > To: abfab-chairs@tools.ietf.org; draft-ietf-abfab-arch@tools.ietf.org; > stephen.farrell@cs.tcd.ie > Subject: New Version Notification - draft-ietf-abfab-arch-11.txt >=20 >=20 > A new version (-11) has been submitted for draft-ietf-abfab-arch: > http://www.ietf.org/internet-drafts/draft-ietf-abfab-arch-11.txt >=20 > Sub state has been changed to AD Followup from Revised ID Needed >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-11 >=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 > IETF Secretariat. From linus@nordberg.se Tue Feb 11 13:38:59 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF9A1A076E for ; Tue, 11 Feb 2014 13:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9DyDTCpl-Ji for ; Tue, 11 Feb 2014 13:38:56 -0800 (PST) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id 211741A0770 for ; Tue, 11 Feb 2014 13:38:55 -0800 (PST) Received: from tool.nordberg.se (h158n2-asp-a13.ias.bredband.telia.com [217.210.64.158]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id 01EA511527; Tue, 11 Feb 2014 22:38:53 +0100 (CET) From: Linus Nordberg To: "Jim Schaad" References: <20140211191116.30042.73681.idtracker@ietfa.amsl.com> <005101cf275d$65725ff0$30571fd0$@augustcellars.com> Date: Tue, 11 Feb 2014 22:38:53 +0100 In-Reply-To: <005101cf275d$65725ff0$30571fd0$@augustcellars.com> (Jim Schaad's message of "Tue, 11 Feb 2014 11:13:50 -0800") Message-ID: <87ha85cosy.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Cc: abfab@ietf.org Subject: Re: [abfab] FW: New Version Notification - draft-ietf-abfab-arch-11.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 21:38:59 -0000 "Jim Schaad" wrote Tue, 11 Feb 2014 11:13:50 -0800: | This update deals with comments from the AD, the SecDir review and IETF last call comments. Nits new to -11: - s/the ability to support channel binding those cses where/the ability to support channel binding in those cases where/1 - maybe s/needs to validate it is talking to the correct RP/needs to validate that it is talking to the correct RP/1 - s|http://www.eduroam.org|https://www.eduroam.org/1 Old nits (doh! sorry for being late): - s/I-D.ietf-radext-dtls/RFC6614/g - s/was"/was/1 - s/from the IDP to the RP/from the IdP to the RP/1 - s/per-\nmessage services will limit/per-\nmessage security services will limit/1 From ietf@augustcellars.com Tue Feb 11 14:05:46 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01601A07A8 for ; Tue, 11 Feb 2014 14:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO8sH3GaeUDR for ; Tue, 11 Feb 2014 14:05:44 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A749E1A07A4 for ; Tue, 11 Feb 2014 14:05:42 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (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 2FA2E38E6A; Tue, 11 Feb 2014 14:05:42 -0800 (PST) From: "Jim Schaad" To: "'Linus Nordberg'" References: <20140211191116.30042.73681.idtracker@ietfa.amsl.com> <005101cf275d$65725ff0$30571fd0$@augustcellars.com> <87ha85cosy.fsf@nordberg.se> In-Reply-To: <87ha85cosy.fsf@nordberg.se> Date: Tue, 11 Feb 2014 14:04:00 -0800 Message-ID: <006f01cf2775$2c8515d0$858f4170$@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: AQB+gkQ2ABjX5pgdDWE19aJD/t5kLQGurx5AAqrN6/edLxnPYA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] FW: New Version Notification - draft-ietf-abfab-arch-11.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2014 22:05:47 -0000 > -----Original Message----- > From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Linus Nordberg > Sent: Tuesday, February 11, 2014 1:39 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] FW: New Version Notification - draft-ietf-abfab-arch- > 11.txt > > "Jim Schaad" wrote Tue, 11 Feb 2014 11:13:50 - > 0800: > > | This update deals with comments from the AD, the SecDir review and IETF > last call comments. > > Nits new to -11: > > - s/the ability to support channel binding those cses where/the ability to > support channel binding in those cases where/1 > > - maybe s/needs to validate it is talking to the correct RP/needs to validate > that it is talking to the correct RP/1 > > - s|http://www.eduroam.org|https://www.eduroam.org/1 > > Old nits (doh! sorry for being late): > > - s/I-D.ietf-radext-dtls/RFC6614/g RFC 6614 is for tls not dtls. Jim > > - s/was"/was/1 > > - s/from the IDP to the RP/from the IdP to the RP/1 > > - s/per-\nmessage services will limit/per-\nmessage security services will > limit/1 > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From linus@nordberg.se Wed Feb 12 08:16:16 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BED1A099C for ; Wed, 12 Feb 2014 08:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSBgrGxggvyB for ; Wed, 12 Feb 2014 08:16:14 -0800 (PST) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id D8C111A0458 for ; Wed, 12 Feb 2014 08:16:13 -0800 (PST) Received: from tool.nordberg.se (dhcp50.se-tug.nordu.net [109.105.104.184]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id 745D7114F3 for ; Wed, 12 Feb 2014 17:16:12 +0100 (CET) From: Linus Nordberg To: abfab@ietf.org Date: Wed, 12 Feb 2014 17:16:12 +0100 Message-ID: <87ha84488j.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Subject: [abfab] RFC 7055 backward incompatible changes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 16:16:17 -0000 Hi, What does the wg think about changes to RFC 7055 that would break backward compatibility? Ephemeral keying complexity could be kept lower if this was allowed. At least one bid-down attack would also be avoided. Thanks, Linus From leifj@sunet.se Wed Feb 12 08:19:15 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D791A050B for ; Wed, 12 Feb 2014 08:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.319 X-Spam-Level: X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8W8wsbEKXY4 for ; Wed, 12 Feb 2014 08:19:13 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id 072461A040E for ; Wed, 12 Feb 2014 08:19:12 -0800 (PST) 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 s1CGJAbM014682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 12 Feb 2014 17:19:10 +0100 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 s1CGJ7Lk007204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Feb 2014 17:19:10 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [77.72.227.166] ([77.72.227.166]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.2) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)) for abfab@ietf.org; Wed, 12 Feb 2014 17:19:07 +0100 Message-ID: <52FB9EFB.6070104@sunet.se> Date: Wed, 12 Feb 2014 17:19:07 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: abfab@ietf.org References: <87ha84488j.fsf@nordberg.se> In-Reply-To: <87ha84488j.fsf@nordberg.se> X-Enigmail-Version: 1.6 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: 09Lpsjaki - 15066bc86c85 - 20140212 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] RFC 7055 backward incompatible changes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 12 Feb 2014 16:19:15 -0000 On 2014-02-12 17:16, Linus Nordberg wrote: > Hi, > > What does the wg think about changes to RFC 7055 that would break > backward compatibility? > > Ephemeral keying complexity could be kept lower if this was allowed. > At least one bid-down attack would also be avoided. > > There is still only a single implementation afaik... but the RFC would need to grow a bis in any case. Cheers Leif From nobody Thu Feb 13 12:17:08 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF16D1A0439; Thu, 13 Feb 2014 12:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGf-dn8QlZh9; Thu, 13 Feb 2014 12:16:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F23BA1A0454; Thu, 13 Feb 2014 12:16:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140213201657.13711.66789.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 12:16:57 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/4dvn6hKVY8Fogm0ijL70abEFQqc Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-12.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:17:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond Web (ABFAB) Architecture Authors : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Jim Schaad Filename : draft-ietf-abfab-arch-12.txt Pages : 44 Date : 2014-02-13 Abstract: Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) the Generic Security Service Application Program Interface (GSS-API), the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-arch-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-arch-12 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 13 13:04:48 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4B51A048C for ; Thu, 13 Feb 2014 13:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9UezjdXRW0p for ; Thu, 13 Feb 2014 13:04:37 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A24081A0376 for ; Thu, 13 Feb 2014 13:04:37 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (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 917FB2CA27 for ; Thu, 13 Feb 2014 13:04:36 -0800 (PST) From: "Jim Schaad" To: References: <20140213201658.13711.94428.idtracker@ietfa.amsl.com> In-Reply-To: <20140213201658.13711.94428.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 13:02:52 -0800 Message-ID: <02d801cf28fe$f81bcf10$e8536d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDk4KJGI12oMMk3JALZHvl4BhKHJJyIPItg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/4UexZ7xvveLWjV6S0yZDW287s28 Subject: [abfab] FW: New Version Notification - draft-ietf-abfab-arch-12.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2014 21:04:42 -0000 This update deals with the latest set of nits found. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, February 13, 2014 12:17 PM > To: abfab-chairs@tools.ietf.org; draft-ietf-abfab-arch@tools.ietf.org; > stephen.farrell@cs.tcd.ie > Subject: New Version Notification - draft-ietf-abfab-arch-12.txt >=20 >=20 > A new version (-12) has been submitted for draft-ietf-abfab-arch: > http://www.ietf.org/internet-drafts/draft-ietf-abfab-arch-12.txt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-12 >=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 > IETF Secretariat. From nobody Fri Feb 14 01:09:10 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE87A1A01B3; Fri, 14 Feb 2014 01:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9THqM4nzcoF; Fri, 14 Feb 2014 01:09:00 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 847311A0115; Fri, 14 Feb 2014 01:08:59 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D40DA10580; Fri, 14 Feb 2014 10:08:57 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id C1A231057E; Fri, 14 Feb 2014 10:08:57 +0100 (CET) Message-ID: <52FDDD10.1050306@restena.lu> Date: Fri, 14 Feb 2014 10:08:32 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> In-Reply-To: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Forwarded-Message-Id: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P" X-Virus-Scanned: ClamAV Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/ZgLNbNdqd6hguqLnnLloLamnhwE Cc: abfab@ietf.org, "dime@ietf.org" , "" Subject: [abfab] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 09:09:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P Content-Type: multipart/mixed; boundary="------------010603070305000203040701" This is a multi-part message in MIME format. --------------010603070305000203040701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I've just submitted an -00 on a topic that we've been struggling with in ABFAB recently (but which exists in every EAP-over-AAA scenario, not limited to ABFAB). http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapide= ntity-00.txt Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. The issue touches multiple areas and working groups (EAP, EAP methods, RADIUS, Diameter) so I had to do a guesstimate for a proper home. I would think radext is the best match, cc'ing abfab and dime, and also emu even though it's shutting down). If you recall those in-depth discussions about fixing either EAP methods to use UTF-8, or why EAP Identity would need to be restrained to UTF-8 even if a method doesn't do it, then yes: the draft is about that. In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057: "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." Which was enough to get the document through IESG, but this should better be fixed more generally for every EAP use case; hence this new dra= ft. It's short and concise - I'd appreciate if you could give it a read and comment. If there's still free time on the agenda, I would also merrily discuss it in London. Greetings, Stefan Winter P.S.: Don't miss my other submission about an EAP Configuration File Format, which I've been told to submit to ops-area/opsawg: http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ Annoucement here: http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html -------- Original Message -------- Subject: New Version Notification for draft-winter-radext-populating-eapidentity-00.txt Date: Fri, 14 Feb 2014 00:43:29 -0800 From: internet-drafts@ietf.org To: Stefan Winter , "Stefan Winter" A new version of I-D, draft-winter-radext-populating-eapidentity-00.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Name: draft-winter-radext-populating-eapidentity Revision: 00 Title: Considerations regarding the correct use of EAP-Response/Identity= Document date: 2014-02-14 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapide= ntity-00.txt Status: https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidenti= ty/ Htmlized: http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00 Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------010603070305000203040701 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------010603070305000203040701-- --kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS/d0RAAoJEMDeajWKOdxmUIoP/2H8SlgdcBJ5j3fRtpG9xaFY FgWs/hdm2cHVRySVM7MvGyvs+/RU1qbNVDodzQcmDrXW1IWT1oPqt0/YGK9PCNIf X8w3qiHwJt7A79+LlMwb1I6bmVzUxpAJuL+Ya+E4Z9/WF4c5RMkbmMGR3z6xwO2P ou+o4/R6IqZGkz5l8ZSqpBW25NqxxBFyI4phMKH/Ap/9XDM4QzOlf7J2AP3uoLk2 Jywo7IrM+THqvZzDcU5lwXlL3YwGVQ/lFgkZnyHSHlmUDSc0v45OShnDZF3Y+YRt 7rmloG4NopJWB8fA/rFVrFa9kyDEP2nTVxMrlf5SBHg0oKpXUzqE/Bis+XmiW+3D yxsUz2vc6CI1CUSf6qQLnc8Mt7ntTKV5kwuTeJW3l4zfMrEhqvad2g7UIc3uWqhh Ei8F03ZShOX33Og7EX8aPVGO7x5/VNr4SJC53rn1nP2GPogFTX3Yv0LXe/R0JR/Z YBtfwAmJk1kvcVi1yNz/Bknfa+8rOV4ow16NR5fSeO2UWcX3I9ocJDuTevRbmBNQ GXovUncKbKjdQ5Fwkj4JD+2QQ26njrM3knSp39v6ij2fIZa2bK+NltN6GvFO1i0H /80Hy0fSvD/DtTfsgEIzzouL4/sJPWuktNxb/amnJzA626KH+5HCeJ/bH5o3gVSg qhVa1A5pJ50NqEJ8pBEz =6yo0 -----END PGP SIGNATURE----- --kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P-- From nobody Fri Feb 14 07:58:27 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EA91A026E; Fri, 14 Feb 2014 07:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUgfZlXaYkge; Fri, 14 Feb 2014 07:58:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 668F01A02C2; Fri, 14 Feb 2014 07:58:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214155822.7941.22922.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 07:58:22 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/434KqahKsW5jpVIjV9PYOFgqMBg Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:58:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for SAML Authors : Josh Howlett Sam Hartman Filename : draft-ietf-abfab-aaa-saml-09.txt Pages : 24 Date : 2014-02-14 Abstract: This document describes the use of the Security Assertion Mark-up Language (SAML) with RADIUS in the context of the ABFAB architecture. It defines two RADIUS attributes, a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML confirmation methods. The RADIUS attributes permit encapsulation of SAML assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion query/request, enabling a Relying Party to request authentication of, or assertions for, user or machine principals. These principals may be named using an NAI name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. These artifacts have been defined to permit application in AAA scenarios other than ABFAB, such as network access. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-aaa-saml/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-aaa-saml-09 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 08:05:50 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBE401A02D8; Fri, 14 Feb 2014 08:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 938WPaLOtlki; Fri, 14 Feb 2014 08:05:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 090491A02EB; Fri, 14 Feb 2014 08:05:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 08:05:22 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/uGWxjpJhQFsTDzrTJR5bTjWY3y8 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:05:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond web (ABFAB) Usability and User Interface Considerations Author : Rhys Smith Filename : draft-ietf-abfab-usability-ui-considerations-00.txt Pages : 18 Date : 2014-02-13 Abstract: The use of ABFAB-based technologies requires that the identities to be used to authenticate are configured on the client device. Achieving this requires software on that device (either built into the operating system or a standalone utility) that will interact with the user, and manage the user's identities and credential-to-service mappings. Anyone designing that software 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-usability-ui-considerations/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-usability-ui-considerations-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 08:11:34 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250A21A02AF; Fri, 14 Feb 2014 08:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8IA8fJyqrna; Fri, 14 Feb 2014 08:11:25 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C47C81A02ED; Fri, 14 Feb 2014 08:11:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 15B5B20680; Fri, 14 Feb 2014 11:07:36 -0500 (EST) 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 DfFT4m4NwPMr; Fri, 14 Feb 2014 11:07:35 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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; Fri, 14 Feb 2014 11:07:35 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 960CB83E59; Fri, 14 Feb 2014 11:11:15 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> Date: Fri, 14 Feb 2014 11:11:15 -0500 In-Reply-To: <52FDDD10.1050306@restena.lu> (Stefan Winter's message of "Fri, 14 Feb 2014 10:08: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 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/nfe0Dez8dML3AfzYb1tuaKqmZKQ Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2014 16:11:31 -0000 Hi. My life has been hectic, and I completely dropped the ball on this! Thanks for doing this. From nobody Sat Feb 15 15:03:12 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0621A02F1; Sat, 15 Feb 2014 15:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mbIDKgxaEOC; Sat, 15 Feb 2014 15:03:06 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD261A00F5; Sat, 15 Feb 2014 15:03:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D7118224017A; Sun, 16 Feb 2014 00:03:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugd6qGcOh1Du; Sun, 16 Feb 2014 00:03:03 +0100 (CET) Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id 717112240128; Sun, 16 Feb 2014 00:03:02 +0100 (CET) Message-ID: <52FFF22A.5010802@deployingradius.com> Date: Sat, 15 Feb 2014 18:03:06 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> In-Reply-To: <52FDDD10.1050306@restena.lu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/2VGqG1SivvBy4MZiRjOdE-ND-Nw Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 15 Feb 2014 23:03:08 -0000 Some comments: Section 3: ... EAP- Response/Identity does not carry encoding information itself, so a conversion between a non-UTF-8 encoding and UTF-8 is not possible for the AAA entity doing the EAP-Response/Identity to User-Name copying. I'm unsure about this. The EAP-Response/Identity field is *supposed* to be UTF-8. So if it's not, the supplicant is non-compliant, and anything can happen. I think the recommendation here for EAP to RADIUS gateways (e.g. Access Points) is to do as little translation as possible. They should just copy the Identity blob into the User-Name attribute. The next paragraph does explain why this is a problem, but the quoted text above seems misleading to me. The AAA entity *can* copy the EAP-Response/Identity to User-Name. It's just data, so that copying is always possible. Consequence: If an EAP method's username is not encoded in UTF-8, and I would suggest "user identifier", to avoid confusion with User-Name. the EAP peer verbatimly uses that method's notion of a username for its EAP-Response/Identity field, then the AAA entity is forced to violate its own specification because it has to, but can not use UTF-8 for its own User-Name attribute. This jeopardizes the subsequent EAP authentication as a whole; request routing may fail or lead to a wrong destinationi, or the AAA payload may be discarded by the recipient due to the malformedness of the User-Name attribute. That is all true. I would note that the EAP-Response/Identity field does *not* have to be taken from the EAP methods user identifier field. They can be completely different. That should be noted here. Where the EAP methods user identifier field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible string for the EAP-Response/Identity field. How it gets that string is implementation dependent. :( Section 4: Where usernames between configured EAP types in an EAP peer differ, the EAP peer can not rely on the EAP type negotiation mechanism alone to provide useful results. If an EAP authentication gets rejected, the EAP peer SHOULD re-try the authentication using a different EAP- Response/Identity than before. The EAP peer SHOULD try all usernames from the entire set of configured EAP types before declaring final authentication failure. I see why this can be necessary, but it's ugly. EAP peers need to maintain state on the encoding of the usernames which are used in their locally configured EAP types. When constructing an EAP-Response/Identity from that username information, they SHOULD (re-)encode that username as UTF-8 and use the resulting value for the EAP-Response/Identity. If the EAP type is configured for the use of anonymous outer identities, the desired outer identity should also be (re-)encoded in UTF-8 encoding before being put into the EAP-Response/Identity. I would add "or allow the provisioning of an EAP-Response/Identity field independent form the EAP method user identifier" Section 5 It may be worth noting that supplicants should try the most secure EAP methods first (i.e. ones with anonymous outer identity). If those fail, they should proceed to more insecure methods. This prevents leakage. Also, supplicants could cache information about successful authentications. If the system appears to be "the same" as one where EAP method X previously worked, it makes sense to start off with EAP method X. How the supplicant determines that this is "the same" system is a subject for discussion. Alan DeKok. From nobody Mon Feb 17 01:02:51 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1961A0148; Mon, 17 Feb 2014 01:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.548, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKl3Z80X3Cp0; Mon, 17 Feb 2014 01:02:46 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id AACFC1A02C3; Mon, 17 Feb 2014 01:02:45 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id EC64E10580; Mon, 17 Feb 2014 10:02:41 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id D12F91057E; Mon, 17 Feb 2014 10:02:41 +0100 (CET) Message-ID: <5301D017.8060302@restena.lu> Date: Mon, 17 Feb 2014 10:02:15 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alan DeKok References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> In-Reply-To: <52FFF22A.5010802@deployingradius.com> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K" X-Virus-Scanned: ClamAV Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/9ay9wj3AsmpVguZ39vH03dEzuz8 Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 09:02:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K Content-Type: multipart/mixed; boundary="------------050000050108010500010704" This is a multi-part message in MIME format. --------------050000050108010500010704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, > Section 3: >=20 > ... EAP- > Response/Identity does not carry encoding information itself, so a > conversion between a non-UTF-8 encoding and UTF-8 is not possible fo= r > the AAA entity doing the EAP-Response/Identity to User-Name copying.= >=20 > I'm unsure about this. The EAP-Response/Identity field is *supposed*= > to be UTF-8. So if it's not, the supplicant is non-compliant, and > anything can happen. Unfortunately, that is not how I read the EAP spec. RFC3748 section 5.1 on the "Identity" packet does not mention UTF-8 for the *Response* at all= =2E It mentions that the *request* MAY contain displayable text, which needs to be UTF-8 if present. For response, no encoding is mandated. The RFC even mentions weirdnesses such as an intermediate NUL character followed by "various options" - but only notes them, they are not forbidden. The use of such a construct breaks the UTF-8 requirement. I totally agree that anything besides UTF-8 in the Response is a bad idea, and these days hopefully a seldom find - but it should be said someplace that it's outright forbidden. Which reminds me that my text speaks of SHOULD NOT in the recommendations (given that I've preliminarily aimed for BCP status, I found a MUST NOT not to be fitting; but maybe it is more spot on nontheless). > I think the recommendation here for EAP to RADIUS gateways (e.g. > Access Points) is to do as little translation as possible. They should= > just copy the Identity blob into the User-Name attribute. And do what if they find that the blob is not UTF-8? Drop the packet? Forward anyway? > The next paragraph does explain why this is a problem, but the quoted= > text above seems misleading to me. The AAA entity *can* copy the > EAP-Response/Identity to User-Name. It's just data, so that copying is= > always possible. Sure; but you create a malformed packet with it - so everybody who consumes that data is at a gamble. > Consequence: If an EAP method's username is not encoded in UTF-8, an= d >=20 > I would suggest "user identifier", to avoid confusion with User-Name.= Sure, no problem. > the EAP peer verbatimly uses that method's notion of a username for > its EAP-Response/Identity field, then the AAA entity is forced to > violate its own specification because it has to, but can not use > UTF-8 for its own User-Name attribute. This jeopardizes the > subsequent EAP authentication as a whole; request routing may fail o= r > lead to a wrong destinationi, or the AAA payload may be discarded by= > the recipient due to the malformedness of the User-Name attribute. >=20 >=20 > That is all true. I would note that the EAP-Response/Identity field > does *not* have to be taken from the EAP methods user identifier field.= > They can be completely different. Will do (the completely different content would be the outer identity). > That should be noted here. Where the EAP methods user identifier > field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible > string for the EAP-Response/Identity field. How it gets that string is= > implementation dependent. :( Yes, that's why I wrote the (somewhat hollow) statement that it "needs to maintain state of the encoding used". How it does that... no spec can mandate. > Section 4: >=20 > Where usernames between configured EAP types in an EAP peer differ, > the EAP peer can not rely on the EAP type negotiation mechanism alon= e > to provide useful results. If an EAP authentication gets rejected, > the EAP peer SHOULD re-try the authentication using a different EAP-= > Response/Identity than before. The EAP peer SHOULD try all username= s > from the entire set of configured EAP types before declaring final > authentication failure. >=20 > I see why this can be necessary, but it's ugly. I totally agree that it's ugly. Adding "Note: That is ugly." to the spec doesn't provide much added value though :-) I feel strong about stating the problem though. We had an actual real-life support case from a device manufacturer whose handset customers couldn't use eduroam and the manufacturer said our RADIUS infrastructure is broken, because it always rejects before they can even try the configured EAP-TTLS that the user sets. It was totally unthinkable for them that someone would not have a business relationship with 3GPP and that always trying the same 3GPP user identifier when starting EAP would lead nowhere. After a lot of explaining and escalation to some senior engineering, we could make that clear, and the firmware got a fix. Having this described in an RFC to point to will certainly help if such states of mind pop up again someplace in the future. > EAP peers need to maintain state on the encoding of the usernames > which are used in their locally configured EAP types. When > constructing an EAP-Response/Identity from that username information= , > they SHOULD (re-)encode that username as UTF-8 and use the resulting= > value for the EAP-Response/Identity. If the EAP type is configured > for the use of anonymous outer identities, the desired outer identit= y > should also be (re-)encoded in UTF-8 encoding before being put into > the EAP-Response/Identity. >=20 > I would add "or allow the provisioning of an EAP-Response/Identity > field independent form the EAP method user identifier" Well... that degree of freedom exists - outer ID *is* independent from the EAP method's user identifier. I'm not sure what the effect of this (third!) notion of (non-)identity could add? The example of the 3GPP vs. realm.example shows that there may well be *no* common EAP-Response/Identity which actually fits all configured EAP types. > Section 5 >=20 > It may be worth noting that supplicants should try the most secure EA= P > methods first (i.e. ones with anonymous outer identity). If those fail= , > they should proceed to more insecure methods. This prevents leakage. Good idea! > Also, supplicants could cache information about successful > authentications. If the system appears to be "the same" as one where > EAP method X previously worked, it makes sense to start off with EAP > method X. >=20 > How the supplicant determines that this is "the same" system is a > subject for discussion. Interesting thought, and a bit complex. I suggest we discuss this when the draft gets adopted in ... "some" working group. Suggestions welcome := -) Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------050000050108010500010704 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------050000050108010500010704-- --gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTAdAXAAoJEMDeajWKOdxmX44P/jsmlCv0nGs46+wfLCtki4yv ++3m3QiE8jk5KW1Vd2YV0ybTljPCbkZCD+w35cZmFY3yGGeyM8jxvo+GHiInmnf3 BKuK4yI2FpgjE0PZUpPNqYXKRr6FlKEUnPPqsr70xPCie/g+d8M+9MW+fOIwpxqt J24O7M98jDv6cJfLS2GbEDcqg4s/PjGIeSogveQKLsoaQaDaoMRhJmdzt2CyXbZt UyA4CxjxiBEgKVNjkXsM0XW74a5RMOJCelLNXYGAflp2RAoQ2kzg/qJJdXz2d3ZX 6L6AF6Qs5fH2haLq+zj0lVUlyUN+6RlN1yEuZQxOzqGhvpf1fIyM1tKnivEwtq4x KdCPE7/EoNkSVkKEfeHkqOHulKuL3WeYcDrHJTCq24CMYSM1H+8WKkLcDDSrNmqy IQhdkdjoi2cZba4UP1MVeTi6yCdEx68yYfd/CyaUdw5Kdqg1ydnEgdf8e+TuCr4O oqrE136Py9qXahfs7DT0f84pE1n9k6Bl99zVy8NkBVHx0z+PyEftyRsIcwVn48ED zx9DPfT6KCgT2eP4d0f+5Vt9cIZJHoiJKVJhUmqFdXXhyV3aRShIlHRQToybqUHu R/tshmg5A30Mwe6wgAqPEpAP31SRYbv/hS4QEsVk0RclAvkP4ShAXOmUrK/ODrZ+ HNGDPwAa+s1R8Fhlvtrk =s/V4 -----END PGP SIGNATURE----- --gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K-- From nobody Mon Feb 17 04:02:26 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67051A04B9 for ; Mon, 17 Feb 2014 04:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAFO0raGquui for ; Mon, 17 Feb 2014 04:02:14 -0800 (PST) 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 513071A04B7 for ; Mon, 17 Feb 2014 04:02:12 -0800 (PST) Received: from AMSPR02MB022.eurprd02.prod.outlook.com (10.242.81.150) by AMSPR02MB024.eurprd02.prod.outlook.com (10.242.81.153) with Microsoft SMTP Server (TLS) id 15.0.878.16; Mon, 17 Feb 2014 12:02:09 +0000 Received: from AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.56]) by AMSPR02MB022.eurprd02.prod.outlook.com ([169.254.8.56]) with mapi id 15.00.0878.008; Mon, 17 Feb 2014 12:02:08 +0000 From: Rhys Smith To: "" Thread-Topic: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt Thread-Index: AQHPKZ6tIQui810jAEqfLC2WJP8UwQ== Date: Mon, 17 Feb 2014 12:02:08 +0000 Message-ID: <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> References: <20140214160522.2435.49474.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: [86.183.105.175] x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(199002)(189002)(51704005)(2473001)(69234005)(377424004)(252514010)(51856001)(76796001)(76786001)(15975445006)(74366001)(54356001)(53806001)(94316002)(81342001)(77096001)(81816001)(69226001)(33656001)(95416001)(95666001)(94946001)(56776001)(54316002)(74706001)(93136001)(76482001)(81686001)(93516002)(74876001)(82746002)(36756003)(86362001)(80976001)(87936001)(4396001)(63696002)(92726001)(15202345003)(87266001)(85306002)(49866001)(56816005)(83322001)(19580405001)(19580395003)(47446002)(74502001)(74482001)(80022001)(92566001)(65816001)(2656002)(90146001)(46102001)(81542001)(66066001)(59766001)(50986001)(31966008)(85852003)(83716003)(74662001)(47736001)(79102001)(47976001)(77982001)(83072002)(24704002)(80792004)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR02MB024; H:AMSPR02MB022.eurprd02.prod.outlook.com; CLIP:86.183.105.175; FPR:BCFFDDFD.AFF6A789.B9F2DE3B.4E2F95D.2034E; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_A9504038-183A-4D2D-A191-9EA545BFE192"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: cardiff.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/DV3xCc1i0od83PwFdX8WgyPbASM Subject: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 12:02:22 -0000 --Apple-Mail=_A9504038-183A-4D2D-A191-9EA545BFE192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, this update includes changes made based on various bits of = feedback. The only substantive bits missing are the errors section, and = security/privacy considerations sections which still needs to be worked = out. 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: I-D Action: = draft-ietf-abfab-usability-ui-considerations-00.txt > Date: 14 February 2014 16:05:22 GMT > To: > Cc: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Application Bridging for Federated = Access Beyond web Working Group of the IETF. >=20 > Title : Application Bridging for Federated Access = Beyond web (ABFAB) Usability and User Interface Considerations > Author : Rhys Smith > Filename : = draft-ietf-abfab-usability-ui-considerations-00.txt > Pages : 18 > Date : 2014-02-13 >=20 > Abstract: > The use of ABFAB-based technologies requires that the identities to > be used to authenticate are configured on the client device. > Achieving this requires software on that device (either built into > the operating system or a standalone utility) that will interact = with > the user, and manage the user's identities and credential-to-service > mappings. Anyone designing that software 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 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-ietf-abfab-usability-ui-considerati= ons/ >=20 > There's also a htmlized version available at: > = http://tools.ietf.org/html/draft-ietf-abfab-usability-ui-considerations-00= >=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 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail=_A9504038-183A-4D2D-A191-9EA545BFE192 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 iEYEARECAAYFAlMB+j8ACgkQ3fEsO94vAkyfBgCglc4IvJwRhSkorv9bwrQy4Nqe K6QAn0ip0cLde56HUdxc7MU91O56QmkO =5xNY -----END PGP SIGNATURE----- --Apple-Mail=_A9504038-183A-4D2D-A191-9EA545BFE192-- From nobody Mon Feb 17 04:45:17 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE21E1A01D4 for ; Mon, 17 Feb 2014 04:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36xWjFt2LJbk for ; Mon, 17 Feb 2014 04:45:14 -0800 (PST) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by ietfa.amsl.com (Postfix) with ESMTP id C506E1A01CC for ; Mon, 17 Feb 2014 04:45:13 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id q8so11414106lbi.0 for ; Mon, 17 Feb 2014 04:45:10 -0800 (PST) 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=bNGE7Y4RAoKvHl6qj6Za/dZPm7hOisKJh9eMNXFfFUs=; b=aVGtDNMBi/GSSxNZLPOFC33YXblL3a4+V4fIzAH4Ka9WFAk82myrCfyl5IHvYA/0eG Gg1grULmka3x4wi7v0DFj8CET3sheBvpgyX+tm8bs0RqYxUPCJIg1b59vP1xk12nuIWd wD8MQe9dIGYeF7bKoVkgBRrmvSiWxFJszRac3YRVr2uiMvOibU2hAE2u2IZp9A0bedL6 UWLlM4TDnG+OFaEBC+OwgPoRLZFuCkKr7yFSaUZBam5Yzn9relS197wtftcN33Y10QRa WZfdnAYzg++Mbh3UUC0cJRdLqMhrRRmX95q3pVZnbqQWes4NEx1pWiNmGSR3CWOi+u8I rj1Q== X-Gm-Message-State: ALoCoQkX19Z2QMf6S1hAW4r3PxXIFk82PvXobGSUqdFvireeNj8A5DY1stqZcOjIoPd6dH5CHSnV X-Received: by 10.112.64.37 with SMTP id l5mr1452262lbs.49.1392641110534; Mon, 17 Feb 2014 04:45:10 -0800 (PST) Received: from [193.10.94.118] ([193.10.94.118]) by mx.google.com with ESMTPSA id mo3sm18746081lbb.17.2014.02.17.04.45.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 04:45:09 -0800 (PST) Message-ID: <53020454.8090907@mnt.se> Date: Mon, 17 Feb 2014 13:45:08 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: abfab@ietf.org References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> In-Reply-To: <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/Qc7MWCOgdFYWt_2E6ZPqIK_qS-M Subject: Re: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 12:45:16 -0000 On 2014-02-17 13:02, Rhys Smith wrote: > FYI, this update includes changes made based on various bits of feedback. The only substantive bits missing are the errors section, and security/privacy considerations sections which still needs to be worked out. > > I'd like to get *some* review of this asap! Volunteers? From nobody Mon Feb 17 05:37:12 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE9C1A04D8; Mon, 17 Feb 2014 05:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtfUAvyaNWGU; Mon, 17 Feb 2014 05:37:03 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 082B21A01EA; Mon, 17 Feb 2014 05:37:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8817D2240186; Mon, 17 Feb 2014 14:36:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nmzz3aXNsDPi; Mon, 17 Feb 2014 14:36:28 +0100 (CET) Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id 39D6C22400A9; Mon, 17 Feb 2014 14:36:27 +0100 (CET) Message-ID: <5302105C.6070103@deployingradius.com> Date: Mon, 17 Feb 2014 08:36:28 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu> In-Reply-To: <5301D017.8060302@restena.lu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/cDHMAWIfNz7-WtGhoZPV1y9cJZU Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 13:37:06 -0000 Stefan Winter wrote: > Unfortunately, that is not how I read the EAP spec. RFC3748 section 5.1 > on the "Identity" packet does not mention UTF-8 for the *Response* at all. > > It mentions that the *request* MAY contain displayable text, which needs > to be UTF-8 if present. That's worse than I remembered. > For response, no encoding is mandated. The RFC even mentions weirdnesses > such as an intermediate NUL character followed by "various options" - > but only notes them, they are not forbidden. The use of such a construct > breaks the UTF-8 requirement. > > I totally agree that anything besides UTF-8 in the Response is a bad > idea, and these days hopefully a seldom find - but it should be said > someplace that it's outright forbidden. I agree. >> I think the recommendation here for EAP to RADIUS gateways (e.g. >> Access Points) is to do as little translation as possible. They should >> just copy the Identity blob into the User-Name attribute. > > And do what if they find that the blob is not UTF-8? Drop the packet? > Forward anyway? Forward anyways. It's what they do now. We can't mandate that 10^9 EAP supplicants upgrade. It's probably easier to fix the AAA infrastructure to work with broken clients. > I feel strong about stating the problem though. We had an actual > real-life support case from a device manufacturer whose handset > customers couldn't use eduroam and the manufacturer said our RADIUS > infrastructure is broken, because it always rejects before they can even > try the configured EAP-TTLS that the user sets. Weird. > It was totally unthinkable for them that someone would not have a > business relationship with 3GPP and that always trying the same 3GPP > user identifier when starting EAP would lead nowhere. That's just dumb. The way sane vendors deal with this is that they allow the user to choose which identity to use. It's ridiculous for the vendor to force a particular identity on the user / device. > After a lot of explaining and escalation to some senior engineering, we > could make that clear, and the firmware got a fix. Having this described > in an RFC to point to will certainly help if such states of mind pop up > again someplace in the future. Yes. The RFCs are unfortunately silent on a wide variety of topics. RFC 2865 even says: The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged. Because I ran into a vendor who didn't allow admins to set a shared secret... and always used a zero-length string. It *was* allowed in RFC 2158. I poked the RADIUS WG, and everyone was appalled. >> I would add "or allow the provisioning of an EAP-Response/Identity >> field independent form the EAP method user identifier" > > Well... that degree of freedom exists - outer ID *is* independent from > the EAP method's user identifier. The idea was to allow *provisioning* of the Response/Identity. Automatically deriving it from the method-specific "user identity" is just as bad as automatically using a 3GPP identity. > Interesting thought, and a bit complex. I suggest we discuss this when > the draft gets adopted in ... "some" working group. Suggestions welcome :-) I'd support a "roaming inter-operations" WG. Some of the documents now in RADEXT could move there, and maybe DIME. This document could live there. The goal for the WG would be to define inter-domain standards for authentication, accounting, EAP, etc. Alan DeKok. From nobody Mon Feb 17 08:33:54 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EC11A0405; Mon, 17 Feb 2014 08:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KAtie8bmloj; Mon, 17 Feb 2014 08:33:50 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 401751A03FF; Mon, 17 Feb 2014 08:33:50 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D71261A9CA0A_30239EAB; Mon, 17 Feb 2014 16:33:46 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id AC36F1A9CA0E_30239EAF; Mon, 17 Feb 2014 16:33:46 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 16:33:46 +0000 From: Josh Howlett To: Alan DeKok , Stefan Winter Thread-Topic: [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt Thread-Index: AQHPK792HMF1Fx9jgkuwstO/NcK195q5cwYAgAAxggA= Date: Mon, 17 Feb 2014 16:33:45 +0000 Message-ID: References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu> <5302105C.6070103@deployingradius.com> In-Reply-To: <5302105C.6070103@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B98CB3B6689F04E92AEB0557FCCB94F@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/ElvUcFl2EnkMLdp5PfPqwKdZhEU Cc: "radext@ietf.org" , "abfab@ietf.org" , "dime@ietf.org" , "" Subject: Re: [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 16:33:52 -0000 > >> Interesting thought, and a bit complex. I suggest we discuss this when >> the draft gets adopted in ... "some" working group. Suggestions welcome >>:-) > > I'd support a "roaming inter-operations" WG. Some of the documents >now in RADEXT could move there, and maybe DIME. This document could >live there. > > The goal for the WG would be to define inter-domain standards for >authentication, accounting, EAP, etc. +1, excellent idea. draft-wierenga-ietf-eduroam, if generalised, could provide a good basis on which to define the issues that need addressing. If it were broader than "roaming" then ABFAB could also fall into scope. Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From nobody Mon Feb 17 14:12:35 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489421A0295 for ; Mon, 17 Feb 2014 14:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PvIvpYFIL_S for ; Mon, 17 Feb 2014 14:12:30 -0800 (PST) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id 555A91A02AD for ; Mon, 17 Feb 2014 14:12:30 -0800 (PST) Received: from amnesia.nordberg.se (2.shulgin.dc1.nl.tor.exit.node.qwertyoruiop.com [93.174.90.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id 0DF5711517 for ; Mon, 17 Feb 2014 23:12:22 +0100 (CET) From: Linus Nordberg To: abfab@ietf.org Date: Mon, 17 Feb 2014 22:11:59 +0000 Message-ID: <87k3ctqths.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/fpQBNrEjzp4hLcgAPoaIop8vd1s Subject: [abfab] I-D Action: draft-linus-abfab-ephemeral-keying-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 17 Feb 2014 22:12:33 -0000 --=-=-= Content-Type: text/plain Hi, This is a somewhat incomplete draft of how the the client <--> RP traffic could be protected. Comments highly appreciated. Hoping to be able to have some discussions about this in London. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Path: news.gmane.org!not-for-mail From: internet-drafts@ietf.org Newsgroups: gmane.ietf.announce Subject: I-D Action: draft-linus-abfab-ephemeral-keying-00.txt Date: Fri, 14 Feb 2014 12:28:56 -0800 Approved: news@gmane.org Message-ID: <20140214202856.26105.76748.idtracker__36784.8085742027$1392409753$gmane$org@ietfa.amsl.com> Reply-To: internet-drafts@ietf.org NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1392409739 12827 80.91.229.3 (14 Feb 2014 20:28:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 20:28:59 +0000 (UTC) To: i-d-announce@ietf.org Original-X-From: i-d-announce-bounces@ietf.org Fri Feb 14 21:29:09 2014 Return-path: Envelope-to: gia-ietf-announce@gmane.org Original-Received: from mail.ietf.org ([4.31.198.44]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WEPNe-0004HK-Kv for gia-ietf-announce@gmane.org; Fri, 14 Feb 2014 21:29:02 +0100 Original-Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B22A01A03FA; Fri, 14 Feb 2014 12:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1392409742; bh=4oZZsoFw79GE4KBqz9NPk5jIqNARKljYGNCaBuhgN8M=; h=MIME-Version:From:To:Subject:Message-ID:Date:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=Mn8yqNyYy8NtZaUVg8Ak1SBnRLlY+LgKPPXQTxlYPlGDzorEFEDS5UJvbEjTKYiCS 6CecVoyWzglNKgv6anom3HUGDNSQ0lw72oBi6UPTif0f2xEky/Vlc0/7O5tQwNThpe XtDP+61Yg4GqZHI31pNpTqRJRnlsCxdRTFLVPNHU= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Original-Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D78E1A0404 for ; Fri, 14 Feb 2014 12:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Original-Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-trhyLO_xgS for ; Fri, 14 Feb 2014 12:28:56 -0800 (PST) Original-Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B7F1A03E7 for ; Fri, 14 Feb 2014 12:28:56 -0800 (PST) X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Archived-At: http://mailarchive.ietf.org/arch/msg/i-d-announce/_NHFAPUxFzuDVnP1XbihXEW-xzU X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.15 List-Id: Internet Draft Announcements only List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org Original-Sender: "I-D-Announce" Archived-At: MIME-Version: 1.0 Content-Type: text/plain A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Ephemeral keying for ABFAB Authors : Linus Nordberg Josh Howlett Filename : draft-linus-abfab-ephemeral-keying-00.txt Pages : 13 Date : 2014-02-14 Abstract: This document describes how EAP-GSS provides forward secrecy by encrypting each session in an ephemeral key generated in the initial state of the context establishment. This Diffie-Hellman key is shared by the initiator (EAP peer) and acceptor (EAP authenticator). The goal is to stop a passive attacker with access to the traffic between an ABFAB user and the service she uses (Relying Party), from getting access to key material and information linkable to the user or from being able to fingerprint the user. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-linus-abfab-ephemeral-keying/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-linus-abfab-ephemeral-keying-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --=-=-=-- From nobody Mon Feb 17 23:29:41 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B071A0447 for ; Mon, 17 Feb 2014 23:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwkP17XCIB-s for ; Mon, 17 Feb 2014 23:29:38 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id D9C281A0043 for ; Mon, 17 Feb 2014 23:29:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 639413F8DA for ; Tue, 18 Feb 2014 08:29:34 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fDqvfT6DR3oe for ; Tue, 18 Feb 2014 08:29:34 +0100 (CET) Received: from [10.42.0.19] (84.124.131.72.dyn.user.ono.com [84.124.131.72]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 2D91F3FAE4 for ; Tue, 18 Feb 2014 08:29:33 +0100 (CET) Message-ID: <53030BDC.7020209@um.es> Date: Tue, 18 Feb 2014 08:29:32 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: abfab@ietf.org References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> <53020454.8090907@mnt.se> In-Reply-To: <53020454.8090907@mnt.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/1Y9zjqlzAsH0n_gRI7cEP400v9U Subject: Re: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 07:29:40 -0000 El 17/02/14 13:45, Leif Johansson escribió: > On 2014-02-17 13:02, Rhys Smith wrote: >> FYI, this update includes changes made based on various bits of feedback. The only substantive bits missing are the errors section, and security/privacy considerations sections which still needs to be worked out. >> >> > I'd like to get *some* review of this asap! > > Volunteers? I will review it. Regards, Alejandro > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Mon Feb 17 23:33:05 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 102E31A0043 for ; Mon, 17 Feb 2014 23:33:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rA-98QznY545 for ; Mon, 17 Feb 2014 23:33:00 -0800 (PST) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 5022F1A002D for ; Mon, 17 Feb 2014 23:33:00 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so11811986lbi.21 for ; Mon, 17 Feb 2014 23:32:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=86m6NT9cr8mDDcsIMa2fy56kNOL/ve88raPAhTje/6w=; b=bneL7rXtszR9O/F0qcH0hHYvP0kgXziBJAtdP/J+iYBTi30gGwFPC/d0QhBoz46yrO SMQwXUK2IvVRFKA9GLRc34Mxtw9QewCSA1dBvMRLKB7Em5Tj8GAYLuetoVmYv2xpeOhb I4kPRpn/6dOnIb1uiYl+5dlI844uW8wZKbYcSSybTuZDNEWmiSnyVvtfBQuhKVg3StPg Qb8on2Ctlm5nJs3vBMattTRp+elZG3/D1T4tFTxxyfQFi3DKFhei3txovQVnpHucDpxX fKHHQdHXtd34f5vFjbC1KwaNFyl6rj32wNv4Qras6Pi213FybENqTt1XDMH+og/C2xn6 GCvQ== X-Gm-Message-State: ALoCoQmjceAWU3W23ADT2q4vR5eVEmFMMuUHsQh1HM9Rox2KYz5vrQ6XV1Pi4cZx42L0j3hUp9Zq X-Received: by 10.112.33.108 with SMTP id q12mr19646909lbi.8.1392708776737; Mon, 17 Feb 2014 23:32:56 -0800 (PST) Received: from [2.70.147.45] (2.70.147.45.mobile.tre.se. [2.70.147.45]) by mx.google.com with ESMTPSA id k1sm22416208lbc.5.2014.02.17.23.32.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Feb 2014 23:32:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Leif Johansson X-Mailer: iPhone Mail (11B601) In-Reply-To: <53030BDC.7020209@um.es> Date: Tue, 18 Feb 2014 08:32:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> <53020454.8090907@mnt.se> <53030BDC.7020209@um.es> To: Alejandro Perez Mendez Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/jxHi5iYPNYVyDI8tbXLKwrLp870 Cc: "abfab@ietf.org" Subject: Re: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 07:33:03 -0000 thank you!! > 18 feb 2014 kl. 08:29 skrev Alejandro Perez Mendez : >=20 >=20 > El 17/02/14 13:45, Leif Johansson escribi=C3=B3: >> On 2014-02-17 13:02, Rhys Smith wrote: >>> FYI, this update includes changes made based on various bits of feedback= . The only substantive bits missing are the errors section, and security/pri= vacy considerations sections which still needs to be worked out. >> I'd like to get *some* review of this asap! >>=20 >> Volunteers? >=20 > I will review it. >=20 > Regards, > Alejandro >=20 >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Tue Feb 18 07:20:10 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D051A0692; Tue, 18 Feb 2014 07:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C0VS2oHqUD4; Tue, 18 Feb 2014 07:20:02 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 670A61A0209; Tue, 18 Feb 2014 07:20:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 61D4C20686; Tue, 18 Feb 2014 10:16:04 -0500 (EST) 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 5lSYdUSYgdp2; Tue, 18 Feb 2014 10:16:02 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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; Tue, 18 Feb 2014 10:16:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B49F1837F1; Tue, 18 Feb 2014 10:19:53 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu> <5302105C.6070103@deployingradius.com> Date: Tue, 18 Feb 2014 10:19:53 -0500 In-Reply-To: <5302105C.6070103@deployingradius.com> (Alan DeKok's message of "Mon, 17 Feb 2014 08:36:28 -0500") 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 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/_a953ddrw1RvBo_dKx1Mijh-dRw Cc: abfab@ietf.org, "dime@ietf.org" , "" , "radext@ietf.org" Subject: Re: [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 15:20:08 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> The idea was to allow *provisioning* of the Alan> Response/Identity. Automatically deriving it from the Alan> method-specific "user identity" is just as bad as Alan> automatically using a 3GPP identity. Unfortunately in contexts like ABFAB, you're only going to have one username. I appreciate that there are environments where you need a different outer username, but I think we want to be moving towards anonymous outer usernames derived from the realm, and I do not support a spec that would make that more difficult. From nobody Tue Feb 18 11:15:09 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953301A0150 for ; Tue, 18 Feb 2014 11:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5o85C57Cu_S for ; Tue, 18 Feb 2014 11:15:03 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 80E731A03F6 for ; Tue, 18 Feb 2014 11:14:53 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (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 878122CA39; Tue, 18 Feb 2014 11:14:50 -0800 (PST) From: "Jim Schaad" To: Date: Tue, 18 Feb 2014 11:13:09 -0800 Message-ID: <07af01cf2cdd$761361d0$623a2570$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07B0_01CF2C9A.67F0BE10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac8s2X9TP8oSuloLQG2zwaVvrAmrbw== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/xkdW42fOD09PrXy-IbcW9-itLVk Cc: abfab@ietf.org Subject: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2014 19:15:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07B0_01CF2C9A.67F0BE10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 2. - I am not sure if you are trying to restrict to the conversation between the initiator and the acceptor based on the fact that you are throwing in RADIUS. There is no RADIUS spoken here. Section 2.1 - para #2 - The first sentence is just wrong. No matter what type of RADIUS you are using, intermediates always have access to the EAP MSK. The difference between RADIUS/UDP and RADIUS/TLS or RADIUS/DTLS is the question of how much passive intermediaries are going to be able to see based on the use of a long term shared secret. Section 2.2 - Passive observers may also be able to fingerprint the client based on TLS restart information. Section 2.3 - This should include exposing the realm of the user (or the full user name in bad implementations). You say [ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method ] could solve the problem of AAA proxies learning the MSK, impersonating the RP ] I would be very interested in seeing how you think there could possibly be a solution in this space. I can't see one. There probably needs to be a nod to using an application level tunnel as well. While I think that it might be nice to have this in the GSS-EAP layer, we cannot ignore this as an option. Jim ------=_NextPart_000_07B0_01CF2C9A.67F0BE10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 2. = – I am not sure if you are trying to restrict to the conversation = between the initiator and the acceptor based on the fact that you are = throwing in RADIUS.  There is no RADIUS spoken here.  =

 

Section 2.1 – para #2 – The first sentence = is just wrong.  No matter what type of RADIUS you are using, = intermediates always have access to the EAP MSK.  The difference = between RADIUS/UDP and RADIUS/TLS or RADIUS/DTLS is the question of how = much passive intermediaries are going to be able to see based on the use = of a long term shared secret.

 

Section 2.2 = – Passive observers may also be able to fingerprint the client = based on TLS restart information.

 

Section 2.3 = – This should include exposing the realm of the user (or the full = user name in bad implementations).

 

You = say

   [ maybe expand on how TEAP [draf=
t-ietf-emu-eap-tunnel-method] =
could
   solve the problem of AAA proxies =
learning the MSK, impersonating the
   RP =
]

I would be very interested in = seeing how you think there could possibly be a solution in this = space.  I can’t see one.

 

There = probably needs to be a nod to using an application level tunnel as = well.  While I think that it might be nice to have this in the = GSS-EAP layer, we cannot ignore this as an option.

 

Jim

 

------=_NextPart_000_07B0_01CF2C9A.67F0BE10-- From nobody Wed Feb 19 04:32:30 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBF1A047F; Wed, 19 Feb 2014 04:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVeakirrNeCU; Wed, 19 Feb 2014 04:32:24 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 71D691A05A6; Wed, 19 Feb 2014 04:32:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 6D31B3FB60; Wed, 19 Feb 2014 13:32:20 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TU9C1ZrztsuG; Wed, 19 Feb 2014 13:32:20 +0100 (CET) Received: from inf-205-172.inf.um.es (inf-205-172.inf.um.es [155.54.205.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 662313FB5F; Wed, 19 Feb 2014 13:32:16 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Rafa Marin Lopez In-Reply-To: <52FDDD10.1050306@restena.lu> Date: Wed, 19 Feb 2014 13:32:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6347417E-BFC9-426E-B15F-09E9B1C50925@um.es> References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/yRFXmj1ZbtAStGcJqGojX3geD4s Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [abfab] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2014 12:32:28 -0000 Hi Stefan: I have taken a look to this draft. Regarding the conversion to UTF-8 = nothing to say. Regarding=20 "1. The choice of identity to send in EAP-Response/Identity may have detrimental effects on the subsequent EAP type negotiation." as far as I remember, it was discussed long time ago as a problem of = network selection (http://tools.ietf.org/html/rfc5113). See section 2.2. = Identity Selection. Your approach here (if I properly understood) seems = to allow the user to try all the identities before reporting an error = (note that this may imply association/dissociation processes at = link-layer to re-start the whole authentication process). The approach = there is to provide the user with the required information to select the = right username.=20 In the particular case of WiFi networks it would be also good to take a = look to IEEE 802.11u and hotspot 2.0 (e.g. these slides, which you may = already know, are interesting = http://www.terena.org/activities/tf-mobility/meetings/26/07-11u-Dave.pptx)= Just my 0.02 cents. Best Regards. P.D: Btw, I agree with Alan: it would good to have a "roaming = inter-operations" WG.=20 P.D.2: Among other things, it would be also good if some information = about accessible realms from a NAS could be provided in a dynamic way to = the peer.=20 El 14/02/2014, a las 10:08, Stefan Winter = escribi=F3: > Hello, >=20 > I've just submitted an -00 on a topic that we've been struggling with = in > ABFAB recently (but which exists in every EAP-over-AAA scenario, not > limited to ABFAB). >=20 > = http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapiden= tity-00.txt >=20 > Abstract: > There are some subtle considerations for an EAP peer regarding the > content of the EAP-Response/Identity packet when authenticating with > EAP to an EAP server. This document describes two such > considerations and suggests workarounds to the associated problems. >=20 > The issue touches multiple areas and working groups (EAP, EAP methods, > RADIUS, Diameter) so I had to do a guesstimate for a proper home. I > would think radext is the best match, cc'ing abfab and dime, and also > emu even though it's shutting down). >=20 > If you recall those in-depth discussions about fixing either EAP = methods > to use UTF-8, or why EAP Identity would need to be restrained to UTF-8 > even if a method doesn't do it, then yes: the draft is about that. >=20 > In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057: > "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." >=20 > Which was enough to get the document through IESG, but this should > better be fixed more generally for every EAP use case; hence this new = draft. >=20 > It's short and concise - I'd appreciate if you could give it a read = and > comment. >=20 > If there's still free time on the agenda, I would also merrily discuss > it in London. >=20 > Greetings, >=20 > Stefan Winter >=20 > P.S.: Don't miss my other submission about an EAP Configuration File > Format, which I've been told to submit to ops-area/opsawg: >=20 > http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ >=20 > Annoucement here: > http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-winter-radext-populating-eapidentity-00.txt > Date: Fri, 14 Feb 2014 00:43:29 -0800 > From: internet-drafts@ietf.org > To: Stefan Winter , "Stefan Winter" > >=20 >=20 > A new version of I-D, = draft-winter-radext-populating-eapidentity-00.txt > has been successfully submitted by Stefan Winter and posted to the > IETF repository. >=20 > Name: draft-winter-radext-populating-eapidentity > Revision: 00 > Title: Considerations regarding the correct use of = EAP-Response/Identity > Document date: 2014-02-14 > Group: Individual Submission > Pages: 6 > URL: > = http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapiden= tity-00.txt > Status: > = https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidentit= y/ > Htmlized: > = http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00 >=20 >=20 > Abstract: > There are some subtle considerations for an EAP peer regarding the > content of the EAP-Response/Identity packet when authenticating with > EAP to an EAP server. This document describes two such > considerations and suggests workarounds to the associated problems. >=20 >=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 >=20 >=20 > <0x8A39DC66.asc>_______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nobody Thu Feb 20 02:01:14 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B161A0072 for ; Thu, 20 Feb 2014 02:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aoDFyAoXLDR for ; Thu, 20 Feb 2014 02:01:08 -0800 (PST) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 779361A0086 for ; Thu, 20 Feb 2014 02:01:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id EE3AED646 for ; Thu, 20 Feb 2014 11:01:02 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hLspPveixW+d for ; Thu, 20 Feb 2014 11:01:02 +0100 (CET) Received: from [10.42.0.19] (84.124.131.72.dyn.user.ono.com [84.124.131.72]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id A2D76D5DC for ; Thu, 20 Feb 2014 11:01:01 +0100 (CET) Message-ID: <5305D25D.7080904@um.es> Date: Thu, 20 Feb 2014 11:01:01 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "abfab@ietf.org" References: <20140214160522.2435.49474.idtracker@ietfa.amsl.com> <189600F9-F56B-4CDE-B77D-574E27C4DE78@cardiff.ac.uk> <53020454.8090907@mnt.se> <53030BDC.7020209@um.es> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------020005050706000602080200" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/ja4ykrBu4umZlaDY-YPxPfJ85Bo Subject: Re: [abfab] Fwd: I-D Action: draft-ietf-abfab-usability-ui-considerations-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 20 Feb 2014 10:01:12 -0000 This is a multi-part message in MIME format. --------------020005050706000602080200 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi, In mi opinion, this draft is well written and is very comprehensive. It has clarified my ideas on how the Identity Selector works. I have though some comments and questions about it: * P5. Section 4. The draft states: Where there is a requirement for multiple credentials to be supported, there are of course two methods that could be employed to configure identities and associated information: Are you sure these are the two only options available? For example, it could be a set of files instead of one. Or a combination of both options (files and a program that simplifies their manipulation). * P6. Section 5.1. A reference to Microsoft CardSpace might be useful. * P8. Section 6.3 The title and the first part of the section gives the reader the impression that "addition" and "association" of identities refer to the same concept, while in my opinion "addition" relates to the act of introducing a new identity into the Identity Selector; and "association" relates to the act of mapping an identity with a service. Am I right? If so, I would rename the section to "Addition and association of an identity". I would add a brief descritiopn of both processes at the beggining. I would also try to homogenize the use of the term "association" and "mapping", or explain they are synonyms (in case they are). If I am wrong, I think the comment might still apply, as the section may be confusing for some readers (me included). * P8. Section 6.3 The text states that provisioning is not the preferrred term, but it is still used several times in the section. * P10. Section 6.3.2. The text says that: Additionally, the user SHOULD be given the opportunity to: o Indicate whether or not the identity selector should always ask before using services with this identity - to customise the way in which the identity selector interacts with the user with this particular identity; Do you refer to ask before creating a new mapping or before using an existing mapping? (or both). * P10. Section 6.3.2. The text continues that end users SHOULD be given the opportunity to: o Reject the addition of the identity completely - to allow the user to back out of the association process in an intuitive way. IMO, it should say "back out of the addition process" instead, as the user is interacting with the IdP, and not associating the identity with any service yet. * P10. Section 6.3.3. Last paragraph Another option would be to provision all identity information except password. Would that make any sense? It would avoid users confusion, as the Identity Select will still ask them for their password (at least the first time), but trust anchors would be added automatically. * P11. Section 6.4. Would a subsection called "Manually Triggered Automated Modification" make any sense? Once the user updates his password on the web portal (see Password changing URL field), the organization may generate a provisioning file with the updated password. This would avoid to update the password manually twice (portal and Identity Selector), and the frustation of failing accessing a service because you forgot to update the password on the Identity Selector once you did on the web portal. * P11. Section 6.5. Would an identity verification service make any sense? The Identity Selector might include a "verify" button that would launch the ABFAB process using the selected identity with this special service on the IdP. If everything goes right, the identity has been proven to be functional and well configured. This verification service might provide (on failure) a better description to the Identity selector on what went wrong, and so the user can inform his administrators. * P12. Section 7 states that: To further complicate the picture, users may wish for: 1. The identity to service mapping to be stored along with the credential, i.e. the user should always be authenticated to a particular service with a particular identity with no prompting. I thought Identities and mappings where stored separatedly. While the credential would be stored along with the Identities (as explained above in the document), the mapping would never be stored with the credential. In any case, it would indicate whether the credential should be used or not. * P14. Section 7.5. Would it be possible to use two (or more) different identities with the same service at the same time? E.g. access a remote SSH using my university's identity, and in another terminal, access to the same service using my personal identity (e.g. Google one). In that case, text of 7.5 should be updated to "Showing the Identities currently in use". * P15. Section 9.1 Wouldn't be enough confirmation to just being provided with the requested service, and not being informed of any error? I'm personally not a big fan of "success notifications" in my desktop. Regards, Alejandro --------------020005050706000602080200 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi,

In mi opinion, this draft is well written and is very comprehensive. It has clarified my ideas on how the Identity Selector works.
I have though some comments and questions about it:

* P5. Section 4.
The draft states:
 Where there is a requirement for multiple credentials to be
   supported, there are of course two methods that could be employed to
   configure identities and associated information:
Are you sure these are the two only options available? For example, it could be a set of files instead of one. Or a combination of both options (files and a program that simplifies their manipulation).

* P6. Section 5.1.
A reference to Microsoft CardSpace might be useful.

* P8. Section 6.3
The title and the first part of the section gives the reader the impression that "addition" and "association" of identities  refer to the same concept, while in my opinion "addition" relates to the act of introducing a new identity into the Identity Selector; and "association" relates to the act of mapping an identity with a service. Am I right?

If so, I would rename the section to "Addition and association of an identity". I would add a brief descritiopn of both processes at the beggining. I would also try to homogenize the use of the term "association" and "mapping", or explain they are synonyms (in case they are).

If I am wrong, I think the comment might still apply, as the section may be confusing for some readers (me included).

* P8. Section 6.3
The text states that provisioning is not the preferrred term, but it is still used several times in the section.

* P10. Section 6.3.2.
The text says that:
 Additionally, the user SHOULD be given the opportunity to:

   o  Indicate whether or not the identity selector should always ask
      before using services with this identity - to customise the way in
      which the identity selector interacts with the user with this
      particular identity;
Do you refer to ask before creating a new mapping or before using an existing mapping? (or both).

* P10. Section 6.3.2.
The text continues that end users SHOULD be given the opportunity to:
   o  Reject the addition of the identity completely - to allow the user
      to back out of the association process in an intuitive way.
IMO, it should say "back out of the addition process" instead, as the user is interacting with the IdP, and not associating the identity with any service yet.

* P10. Section 6.3.3. Last paragraph
Another option would be to provision all identity information except password. Would that make any sense? It would avoid users confusion, as the Identity Select will still ask them for their password (at least the first time), but trust anchors would be added automatically.

* P11. Section 6.4. Would a subsection called "Manually Triggered Automated Modification" make any sense? Once the user updates his password on the web portal (see Password changing URL field), the organization may generate a provisioning file with the updated password. This would avoid to update the password manually twice (portal and Identity Selector), and the frustation of failing accessing a service because you forgot to update the password on the Identity Selector once you did on the web portal.

* P11. Section 6.5. Would an identity verification service make any sense? The Identity Selector might include a "verify" button that would launch the ABFAB process using the selected identity with this special service on the IdP. If everything goes right, the identity has been proven to be functional and well configured. This verification service might provide (on failure) a better description to the Identity selector on what went wrong, and so the user can inform his administrators.

* P12. Section 7 states that:
To further complicate the picture, users may wish for:

   1.  The identity to service mapping to be stored along with the
       credential, i.e. the user should always be authenticated to a
       particular service with a particular identity with no prompting.
I thought Identities and mappings where stored separatedly. While the credential would  be stored along with the Identities (as explained above in the document), the mapping would never be stored with the credential. In any case, it would indicate whether the credential should be used or not.

* P14. Section 7.5.
Would it be possible to use two (or more) different identities with the same service at the same time? E.g. access a remote SSH using my university's identity, and in another terminal, access to the same service using my personal identity (e.g. Google one). In that case, text of 7.5 should be updated to "Showing the Identities currently in use".

* P15. Section 9.1
Wouldn't be enough confirmation to just being provided with the requested service, and not being informed of any error? I'm personally not a big fan of "success notifications" in my desktop.

Regards,
Alejandro
--------------020005050706000602080200-- From nobody Fri Feb 21 04:36:12 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9E01A002B for ; Fri, 21 Feb 2014 04:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ACdHOq2GElv for ; Fri, 21 Feb 2014 04:36:09 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 2943F1A0034 for ; Fri, 21 Feb 2014 04:36:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2224; q=dns/txt; s=iport; t=1392986165; x=1394195765; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S500NF8lcLjtlVjF4o6FbS//dWdAezf5e5ZCTM1cYYI=; b=Mnuj0ebmw0TvgKvBe/uEIQ1fwLHaPRpTy/G8j39TfRQqBM/PrNEgAfXT LFpiRIHG53VrHdCTP3THxryA+0xkCaV45+9hYXOzARgItol9/Ph+WmzjW VsiSG2zgGzYSd/ktAltZc5Dc9Cw2tEfIbz1urAhlzJt/ASCqSl8+mzEdX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANtGB1OtJXG//2dsb2JhbABZgwY7V8A5gREWdIIlAQEBAwEBAQEkRwsFCwIBCBEDAQIvJwsUCQgCBA4Fh30IDcwgF44QITMHgySBFASYNIEykHWDLYIq X-IronPort-AV: E=Sophos;i="4.97,518,1389744000"; d="scan'208";a="22169006" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-8.cisco.com with ESMTP; 21 Feb 2014 12:36:05 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1LCa4d6016090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Feb 2014 12:36:05 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.200]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 21 Feb 2014 06:36:04 -0600 From: "Klaas Wierenga (kwiereng)" To: Linus Nordberg Thread-Topic: [abfab] I-D Action: draft-linus-abfab-ephemeral-keying-00.txt Thread-Index: AQHPLC1dxyNc8TVBs0u+Tq7ow0CmU5rADzIA Date: Fri, 21 Feb 2014 12:36:04 +0000 Message-ID: <8FA4ECEC-CC02-4D8D-A732-855FB42757DC@cisco.com> References: <87k3ctqths.fsf@nordberg.se> In-Reply-To: <87k3ctqths.fsf@nordberg.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.104.219] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/GMRjALZkoct2SmlXGwf4DDs5iUI Cc: "" Subject: Re: [abfab] I-D Action: draft-linus-abfab-ephemeral-keying-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 21 Feb 2014 12:36:11 -0000 On Feb 17, 2014, at 11:11 PM, Linus Nordberg wrote: > Hi, >=20 > This is a somewhat incomplete draft of how the the client <--> RP > traffic could be protected. Comments highly appreciated. Hoping to be > able to have some discussions about this in London. and hopefully before that on the list=85. Klaas >=20 >=20 > From: > Subject: I-D Action: draft-linus-abfab-ephemeral-keying-00.txt > Date: February 14, 2014 9:28:56 PM GMT+01:00 > To: > Reply-To: >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Ephemeral keying for ABFAB > Authors : Linus Nordberg > Josh Howlett > Filename : draft-linus-abfab-ephemeral-keying-00.txt > Pages : 13 > Date : 2014-02-14 >=20 > Abstract: > This document describes how EAP-GSS provides forward secrecy by > encrypting each session in an ephemeral key generated in the initial > state of the context establishment. This Diffie-Hellman key is > shared by the initiator (EAP peer) and acceptor (EAP authenticator). >=20 > The goal is to stop a passive attacker with access to the traffic > between an ABFAB user and the service she uses (Relying Party), from > getting access to key material and information linkable to the user > or from being able to fingerprint the user. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-linus-abfab-ephemeral-keying/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-linus-abfab-ephemeral-keying-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Sun Feb 23 19:33:37 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C078F1A07E0 for ; Sun, 23 Feb 2014 19:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp2OtHxPBZwA for ; Sun, 23 Feb 2014 19:33:34 -0800 (PST) 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 239B31A027D for ; Sun, 23 Feb 2014 19:33:34 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id kp14so6010582pab.9 for ; Sun, 23 Feb 2014 19:33:33 -0800 (PST) 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=fkrH1GNud5ADz977otXegetXCQwyQwBX8lyK5CUS13s=; b=N+UsC0whZsMTtZMe+RgEQF8xfvKGjhXO29C+228tyolmY9nivszS8/FZi48mYgfZoU A6RDSC7R0cfD3hv8KAp5+R26C3aoC430XcvCII9LtOK7RAPZxcwMMInPSo3VJLhkc0NX XKlyO6z7N0wBdmRcnJvT/NxqmYZ8j4rVDrsbAIJSynII48LkSKRn0PM4sbU0xbRiIxjM eO689ZKxDzcHWeYnuW72/OGudiFOxaCPkoMWcnnogd1TWzqFwe0QJu26mXkziQob46sG EYIABzvU825wENTwBBMRyTHTm5RUsSrmq2w3pgPDYw+EzpcDNMUNd68m4PxEw2NmJpvp 5ZSg== X-Received: by 10.68.194.97 with SMTP id hv1mr11100146pbc.162.1393212813872; Sun, 23 Feb 2014 19:33:33 -0800 (PST) Received: from PC-201303222330 ([210.39.1.1]) by mx.google.com with ESMTPSA id qf7sm108877862pac.14.2014.02.23.19.33.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2014 19:33:33 -0800 (PST) Date: Mon, 24 Feb 2014 11:33:30 +0800 From: "Jeanne Wei" To: "Jim Schaad" References: <20140213201658.13711.94428.idtracker@ietfa.amsl.com>, <02d801cf28fe$f81bcf10$e8536d30$@augustcellars.com> X-Priority: 3 X-GUID: 4A9A4903-889A-4830-BC42-FB812C8F4E13 X-Has-Attach: no X-Mailer: Foxmail 7, 2, 0, 111[cn] Mime-Version: 1.0 Message-ID: <201402241133267821363@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart246635308713_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/F-q4gpzLaq71MoBmKeobk69Mtk4 Cc: abfab Subject: Re: [abfab] FW: New Version Notification - draft-ietf-abfab-arch-12.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2014 03:33:36 -0000 This is a multi-part message in MIME format. ------=_001_NextPart246635308713_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 CgoKCgoKCmEgc2xpcDppbiBzZWN0aW9uIDEuMyBpdCB3cml0ZXMgIkFzIHRoZSBudW1iZXIgb2Yg ZmVkZXJhdGVkIElkUHMgYW5kIFJQcyAoc2VydmljZXMpIHByb2xpZmVyYXRzIiwgdGhlICpwcm9s aWZlcmF0cyogbWF5IGJlICpwcm9saWZlcmF0ZXMqLgrCoAoKCgoKCkplYW5uZSBKLiBXZWkKU2hl bnpoZW4gVW5pdmVyc2l0eSwgQ2hpbmEKRS1tYWlsOmp1YW53ZWkyMDEyQGdtYWlsLmNvbQrCoMKg RnJvbTrCoEppbSBTY2hhYWREYXRlOsKgMjAxNC0wMi0xNMKgMDU6MDJUbzrCoGFiZmFiQGlldGYu b3JnU3ViamVjdDrCoFthYmZhYl0gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0 LWlldGYtYWJmYWItYXJjaC0xMi50eHRUaGlzIHVwZGF0ZSBkZWFscyB3aXRoIHRoZSBsYXRlc3Qg c2V0IG9mIG5pdHMgZm91bmQuCsKgCkppbQrCoArCoAo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXQo+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxMywgMjAxNCAxMjoxNyBQ TQo+IFRvOiBhYmZhYi1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtYWJmYWItYXJj aEB0b29scy5pZXRmLm9yZzsKPiBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllCj4gU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIC0gZHJhZnQtaWV0Zi1hYmZhYi1hcmNoLTEyLnR4dAo+ IAo+IAo+IEEgbmV3IHZlcnNpb24gKC0xMikgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBkcmFmdC1p ZXRmLWFiZmFiLWFyY2g6Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1hYmZhYi1hcmNoLTEyLnR4dAo+IAo+IAo+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHBh Z2UgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1hYmZhYi1hcmNoLwo+IAo+IERpZmYgZnJvbSBwcmV2aW91cyB2 ZXJzaW9uOgo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYWJm YWItYXJjaC0xMgo+IAo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24KPiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLgo+IAo+IElF VEYgU2VjcmV0YXJpYXQuCsKgCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fCmFiZmFiIG1haWxpbmcgbGlzdAphYmZhYkBpZXRmLm9yZwpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FiZmFiCgo= ------=_001_NextPart246635308713_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A=0A
a slip:
in section 1.3 it writes "As the number of federated IdPs and RPs (services) proliferats<= /span>", the *proliferats* may be *proliferates*.
=0A
&= nbsp;
=0A
=0A
=0A
=0A
=0A
Jeanne J. Wei
=0A
Shenzhen University, China=0A=0A
 
 
From: Jim Schaad
Date: 2= 014-02-14 05:02
Subject: [abfab] FW: New V= ersion Notification - draft-ietf-abfab-arch-12.txt
<= div>This update deals with the latest set of nits found.
=0A
&nbs= p;
=0A
Jim
=0A
 
=0A
 
=0A
&= gt; -----Original Message-----
=0A
> From: internet-drafts@iet= f.org [mailto:internet-drafts@ietf.org]
=0A
> Sent: Thursday, = February 13, 2014 12:17 PM
=0A
> To: abfab-chairs@tools.ietf.o= rg; draft-ietf-abfab-arch@tools.ietf.org;
=0A
> stephen.farrel= l@cs.tcd.ie
=0A
> Subject: New Version Notification - draft-ie= tf-abfab-arch-12.txt
=0A
>
=0A
>
=0A
&g= t; A new version (-12) has been submitted for draft-ietf-abfab-arch:
= =0A
> http://www.ietf.org/internet-drafts/draft-ietf-abfab-arch-12.= txt
=0A
>
=0A
>
=0A
> The IETF datat= racker page for this Internet-Draft is:
=0A
> https://datatrac= ker.ietf.org/doc/draft-ietf-abfab-arch/
=0A
>
=0A
&g= t; Diff from previous version:
=0A
> http://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-abfab-arch-12
=0A
>
=0A
> Pl= ease note that it may take a couple of minutes from the time of submission=
=0A
> until the htmlized version and diff are available at to= ols.ietf.org.
=0A
>
=0A
> IETF Secretariat.
= =0A
 
=0A
______________________________________________= _
=0A
abfab mailing list
=0A
abfab@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo/abfab=0A= =0A ------=_001_NextPart246635308713_=------ From nobody Mon Feb 24 05:03:37 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9331A086C for ; Mon, 24 Feb 2014 05:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3gPG_qNUtGM for ; Mon, 24 Feb 2014 05:03:27 -0800 (PST) Received: from out22-ams.mf.surf.net (out22-ams.mf.surf.net [145.0.1.22]) by ietfa.amsl.com (Postfix) with ESMTP id B08BE1A086A for ; Mon, 24 Feb 2014 05:03:26 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s1OD3OUE025032 for ; Mon, 24 Feb 2014 14:03:25 +0100 Received: from 173-38-208-169.cisco.com ([173.38.208.169] helo=dhcp-10-61-106-30.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WHv7J-000MjN-Ph for abfab@ietf.org; Mon, 24 Feb 2014 13:58:41 +0100 From: Klaas Wierenga Content-Type: multipart/signed; boundary="Apple-Mail=_93BAC82F-118C-4F94-A745-C5589FEEC5C3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Message-Id: Date: Mon, 24 Feb 2014 14:03:22 +0100 To: "" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: p-out:default, p:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uLud3pj7 - b86e01e32546 - 20140224 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/FEBXPqulplRvNwDgrHBCxWM2YBE Subject: [abfab] Agenda IETF89 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2014 13:03:33 -0000 --Apple-Mail=_93BAC82F-118C-4F94-A745-C5589FEEC5C3 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Hi, I just uploaded the following agenda: === - Agenda Bashing and Note Well (5 min, Chairs) - Document status & Remaining open issues (45 min) * draft-ietf-abfab-aaa-saml * draft-ietf-abfab-usability-ui-considerations * draft-linus-abfab-ephemeral-keying - Rechartering - future direction - Document status & Open Mic (remaining time) === If you have any additions/requests please let Leif or me know! Klaas --Apple-Mail=_93BAC82F-118C-4F94-A745-C5589FEEC5C3 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 - https://gpgtools.org iEYEARECAAYFAlMLQxoACgkQH2Wy/p4XeFJEHQCfS1gX6vVtSPsEUYh0PD/Dg5WY Gp8An2oR0BEowewNI0RQdtJ285VhMYVU =xRtS -----END PGP SIGNATURE----- --Apple-Mail=_93BAC82F-118C-4F94-A745-C5589FEEC5C3-- From nobody Mon Feb 24 08:41:49 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6DA21A0208 for ; Mon, 24 Feb 2014 08:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWJgrWCg8knz for ; Mon, 24 Feb 2014 08:41:45 -0800 (PST) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id 162281A01E9 for ; Mon, 24 Feb 2014 08:41:44 -0800 (PST) Received: from amnesia.nordberg.se (afo2.torproject.afo-tm.org [62.210.129.149]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id D3F5911550; Mon, 24 Feb 2014 17:41:41 +0100 (CET) From: Linus Nordberg To: "Jim Schaad" References: <07af01cf2cdd$761361d0$623a2570$@augustcellars.com> Date: Mon, 24 Feb 2014 17:41:13 +0000 In-Reply-To: <07af01cf2cdd$761361d0$623a2570$@augustcellars.com> (Jim Schaad's message of "Tue, 18 Feb 2014 11:13:09 -0800") Message-ID: <87vbw4pfwm.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/6FoTupPnlsjsdSXGm1mL2zuZj9Q Cc: draft-linus-abfab-ephemeral-keying@tools.ietf.org, abfab@ietf.org Subject: Re: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2014 16:41:47 -0000 Jim, thanks for the comments and sorry for the delay. Things have improved for me since last week w.r.t. responsiveness. "Jim Schaad" wrote Tue, 18 Feb 2014 11:13:09 -0800: | Section 2. - I am not sure if you are trying to restrict to the conversation | between the initiator and the acceptor based on the fact that you are | throwing in RADIUS. There is no RADIUS spoken here. I agree that this is confusing. Restricting to traffic between initiator and acceptor is not enough in this section even if the suggested solution is limited to adding additional encryption to that stretch. Changing section 2. to read --8<---------------cut here---------------start------------->8--- This section describes the information available to a passive observer of an {{I-D.ietf-abfab-arch}} authentication, working from the lowest layers of the protocol stack upwards. --8<---------------cut here---------------end--------------->8--- | Section 2.1 - para #2 - The first sentence is just wrong. No matter what | type of RADIUS you are using, intermediates always have access to the EAP | MSK. The difference between RADIUS/UDP and RADIUS/TLS or RADIUS/DTLS is the | question of how much passive intermediaries are going to be able to see | based on the use of a long term shared secret. True indeed, slip up. Fixed in upcoming -01. What does the list think of the use of RADIUS rather than AAA here? Should we be more generic? | Section 2.2 - Passive observers may also be able to fingerprint the client | based on TLS restart information. What does "TLS restart" mean in this context? Do you mean a RadSec client re-establishing a torn down connection? Or maybe TLS renegotiation? Or, most probably, something third that I'm not familiar with? | Section 2.3 - This should include exposing the realm of the user (or the | full user name in bad implementations). Do you refer to the "Mechanism Name", as described in RFC7055 section 3.1. or is user realm (and possibly name) carried somewhere else? | You say | | [ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method | ] could | solve the problem of AAA proxies learning the MSK, impersonating the | RP ] | | I would be very interested in seeing how you think there could possibly be a | solution in this space. I can't see one. I will have to attend to this later. | There probably needs to be a nod to using an application level tunnel as | well. While I think that it might be nice to have this in the GSS-EAP | layer, we cannot ignore this as an option. Good idea. From nobody Mon Feb 24 09:14:24 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3015C1A012D for ; Mon, 24 Feb 2014 09:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmvAEw0XVFk0 for ; Mon, 24 Feb 2014 09:14:16 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A018D1A0054 for ; Mon, 24 Feb 2014 09:14:16 -0800 (PST) Received: from Philemon (unknown [107.16.166.39]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 1F9672C9EB; Mon, 24 Feb 2014 09:14:16 -0800 (PST) From: "Jim Schaad" To: "'Linus Nordberg'" References: <07af01cf2cdd$761361d0$623a2570$@augustcellars.com> <87vbw4pfwm.fsf@nordberg.se> In-Reply-To: <87vbw4pfwm.fsf@nordberg.se> Date: Mon, 24 Feb 2014 09:12:32 -0800 Message-ID: <029e01cf3183$9b1f99d0$d15ecd70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQL6G8aeofxfBAVIxsLbum67d6fu1QGecCGamGHbZZA= Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/0m0vGplfet07GIQLBCZDplE2Pnk Cc: draft-linus-abfab-ephemeral-keying@tools.ietf.org, abfab@ietf.org Subject: Re: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 24 Feb 2014 17:14:22 -0000 > -----Original Message----- > From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Linus Nordberg > Sent: Monday, February 24, 2014 9:41 AM > To: Jim Schaad > Cc: draft-linus-abfab-ephemeral-keying@tools.ietf.org; abfab@ietf.org > Subject: Re: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00 > > Jim, thanks for the comments and sorry for the delay. Things have improved > for me since last week w.r.t. responsiveness. > > "Jim Schaad" wrote Tue, 18 Feb 2014 11:13:09 - > 0800: > > | Section 2. - I am not sure if you are trying to restrict to the > | conversation between the initiator and the acceptor based on the fact > | that you are throwing in RADIUS. There is no RADIUS spoken here. > > I agree that this is confusing. Restricting to traffic between initiator and > acceptor is not enough in this section even if the suggested solution is limited > to adding additional encryption to that stretch. > > Changing section 2. to read > > --8<---------------cut here---------------start------------->8--- > This section describes the information available to a passive observer of an > {{I-D.ietf-abfab-arch}} authentication, working from the lowest layers of the > protocol stack upwards. > --8<---------------cut here---------------end--------------->8--- > > > | Section 2.1 - para #2 - The first sentence is just wrong. No matter > | what type of RADIUS you are using, intermediates always have access to > | the EAP MSK. The difference between RADIUS/UDP and RADIUS/TLS or > | RADIUS/DTLS is the question of how much passive intermediaries are > | going to be able to see based on the use of a long term shared secret. > > True indeed, slip up. Fixed in upcoming -01. > > What does the list think of the use of RADIUS rather than AAA here? > Should we be more generic? > > > | Section 2.2 - Passive observers may also be able to fingerprint the > | client based on TLS restart information. > > What does "TLS restart" mean in this context? Do you mean a RadSec client > re-establishing a torn down connection? Or maybe TLS renegotiation? Or, > most probably, something third that I'm not familiar with? Something else - TLS Session Resumption using server State or PAC (see sections 3.2.1 and 3.2.2 of draft-ietf-emu-eap-tunnel-method) > > > | Section 2.3 - This should include exposing the realm of the user (or > | the full user name in bad implementations). > > Do you refer to the "Mechanism Name", as described in RFC7055 section 3.1. > or is user realm (and possibly name) carried somewhere else? I was referring to exposing the user name, for those cases where people don't either tunnel it or don't truncate it to just the realm in the initial EAP message sent to the acceptor. Jim > > > | You say > | > | [ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method > | ] could > | solve the problem of AAA proxies learning the MSK, impersonating the > | RP ] > | > | I would be very interested in seeing how you think there could > | possibly be a solution in this space. I can't see one. > > I will have to attend to this later. > > > | There probably needs to be a nod to using an application level tunnel > | as well. While I think that it might be nice to have this in the > | GSS-EAP layer, we cannot ignore this as an option. > > Good idea. > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nobody Tue Feb 25 07:35:43 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2BD1A0033 for ; Tue, 25 Feb 2014 07:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDqrsagXOrYs for ; Tue, 25 Feb 2014 07:35:37 -0800 (PST) Received: from smtp.nordberg.se (smtp.nordberg.se [193.10.5.87]) by ietfa.amsl.com (Postfix) with ESMTP id BC70B1A0794 for ; Tue, 25 Feb 2014 07:35:25 -0800 (PST) Received: from amnesia.nordberg.se (afo4.torproject.afo-tm.org [85.114.142.168]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.nordberg.se (Postfix) with ESMTPSA id 42B701152E; Tue, 25 Feb 2014 16:35:20 +0100 (CET) From: Linus Nordberg To: "Jim Schaad" References: <07af01cf2cdd$761361d0$623a2570$@augustcellars.com> <87vbw4pfwm.fsf@nordberg.se> <029e01cf3183$9b1f99d0$d15ecd70$@augustcellars.com> Date: Tue, 25 Feb 2014 15:34:41 +0000 In-Reply-To: <029e01cf3183$9b1f99d0$d15ecd70$@augustcellars.com> (Jim Schaad's message of "Mon, 24 Feb 2014 09:12:32 -0800") Message-ID: <877g8jkxym.fsf@nordberg.se> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/qRO_Ww7qCZZp3ZUxRHt8PNrbRbY Cc: draft-linus-abfab-ephemeral-keying@tools.ietf.org, abfab@ietf.org Subject: Re: [abfab] Comments on draft-linus-abfab-ephemeral-keying-00 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2014 15:35:40 -0000 "Jim Schaad" wrote Mon, 24 Feb 2014 09:12:32 -0800: | > | Section 2.2 - Passive observers may also be able to fingerprint the | > | client based on TLS restart information. | > | > What does "TLS restart" mean in this context? Do you mean a RadSec client | > re-establishing a torn down connection? Or maybe TLS renegotiation? Or, | > most probably, something third that I'm not familiar with? | | Something else - TLS Session Resumption using server State or PAC (see | sections 3.2.1 and 3.2.2 of draft-ietf-emu-eap-tunnel-method) Good point. I added the following to upcoming -01. --8<---------------cut here---------------start------------->8--- In cases where a TLS-based EAP method is used, a passive observer may be able to fingerprint the client based on TLS session resumption, for example as described in {{RFC5077}} section 5.8. --8<---------------cut here---------------end--------------->8--- | > | Section 2.3 - This should include exposing the realm of the user (or | > | the full user name in bad implementations). | > | > Do you refer to the "Mechanism Name", as described in RFC7055 section 3.1. | > or is user realm (and possibly name) carried somewhere else? | | I was referring to exposing the user name, for those cases where people | don't either tunnel it or don't truncate it to just the realm in the initial | EAP message sent to the acceptor. This is mentioned in 2.1. One could indeed argue that it should go here instead, or both there and here. | > | [ maybe expand on how TEAP [draft-ietf-emu-eap-tunnel-method | > | ] could | > | solve the problem of AAA proxies learning the MSK, impersonating the | > | RP ] | > | | > | I would be very interested in seeing how you think there could | > | possibly be a solution in this space. I can't see one. I still haven't worked this through really. Please let me know what's wrong with the following sketch. If an EAP peer and server (i.e. ABFAB client and IdP) establish a TLS session using TEAP with a DHE key exchange, they will share an ephemeral key which is not known to any intermediaries. The question is how peer and server authenticate each other. In an ABFAB setting, client and IdP share a secret in the user pass phrase and can use that as a PSK using a TLS_DHE_PSK cipher suite. An alternative authentication method might be TEAP password authentication (Basic-Password-Auth-Req/Resp). Unless it isn't. | > | There probably needs to be a nod to using an application level tunnel | > | as well. While I think that it might be nice to have this in the | > | GSS-EAP layer, we cannot ignore this as an option. What about something like this, as an addition to section 3.1.? --8<---------------cut here---------------start------------->8--- An alternative place to protect ABFAB authentication with a short lived key would be in the application level protocol. While some applications are using protocols already able to protect the GSS-API traffic using a TLS session with an ephemeral key (XMPP, IMAP, SMTP) it's not mandatory to use such a tunnel. Other applications use protocols which might be hard to protect in a tunnel (NFS, SSH). --8<---------------cut here---------------end--------------->8--- From nobody Fri Feb 28 06:31:01 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3EC1A0214 for ; Fri, 28 Feb 2014 06:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.383 X-Spam-Level: * X-Spam-Status: No, score=1.383 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf39qie36_ZY for ; Fri, 28 Feb 2014 06:30:57 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id D95891A01B4 for ; Fri, 28 Feb 2014 06:30:56 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id s1SEUoOd005514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 28 Feb 2014 15:30:50 +0100 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 s1SEUleK028630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 28 Feb 2014 15:30:50 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [10.100.50.167] ([158.230.100.10]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.2) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128 bits)) for abfab@ietf.org; Fri, 28 Feb 2014 15:30:47 +0100 Message-ID: <53109D96.2000700@sunet.se> Date: Fri, 28 Feb 2014 15:30:46 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: Content-Type: multipart/alternative; boundary="------------070303020402040305030900" 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: 09LvOuOTQ - 6e5208c7801e - 20140228 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/THo89Et2UWjEAifq4TtnmlXmYb8 Subject: [abfab] Fwd: review of abfab ui draft X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2014 14:31:00 -0000 This is a multi-part message in MIME format. --------------070303020402040305030900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: review of abfab ui draft Date: Tue, 25 Feb 2014 21:00:34 +0000 From: Ken Klingenstein To: Leif Johansson , Rhys Smith Good doc. Well written, seems to address the issues we understand right now (modulo all the still todo's in the draft.) Once comment on the text below -- trust anchors are more complex -- when we use self-signed certs from the enterprises, the metadata signing key is becomes part of the trust. Not sure how to work that concern in. Have a good session in London. Some of us will miss the warm beer. For the identity selector to be able to verify that the server it is going to talk to and attempt to authenticate against is the server that it is expecting, and that it is not being spoofed in some way. This is likely to be an X.509 certificate [TODO X509 ref], or a tuple of (trusted root certificate, servername in Subject or subjectAltName). Ken --------------070303020402040305030900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit


-------- Original Message --------
Subject: review of abfab ui draft
Date: Tue, 25 Feb 2014 21:00:34 +0000
From: Ken Klingenstein <kjk@internet2.edu>
To: Leif Johansson <leifj@sunet.se>, Rhys Smith <Smith@cardiff.ac.uk>


Good doc. Well written, seems to address the issues we understand right now (modulo all the still todo's in the draft.) Once comment on the text below – trust anchors are more complex – when we use self-signed certs from the enterprises, the metadata signing key is becomes part of the trust. Not sure how to work that concern in.


Have a good session in London. Some of us will miss the warm beer. 


For the identity selector to be able to verify that

the server it is going to talk to and attempt to authenticate

against is the server that it is expecting, and that it is not

being spoofed in some way. This is likely to be an X.509

certificate [TODO X509 ref], or a tuple of (trusted root

certificate, servername in Subject or subjectAltName).

             Ken



--------------070303020402040305030900--