From leifj@sunet.se Tue May 14 05:18:12 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EF721F8F32 for ; Tue, 14 May 2013 05:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHnqzkbz6Sl9 for ; Tue, 14 May 2013 05:18:08 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id C0CBE21F8F27 for ; Tue, 14 May 2013 05:18:07 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r4ECI3uB021576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 May 2013 14:18:03 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r4ECI0vf007803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 May 2013 12:18:03 GMT Received: from [192.36.125.241] ([192.36.125.241]) (authenticated user leifj@nordu.net) by kerio.nordu.net (using TLSv1/SSLv3 with cipher AES256-SHA (256 bits)) for abfab@ietf.org; Tue, 14 May 2013 14:18:00 +0200 Message-ID: <51922B77.4020309@sunet.se> Date: Tue, 14 May 2013 14:17:59 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: abfab@ietf.org References: <517E8687.2070205@sunet.se> <517E8823.3050404@mnt.se> In-Reply-To: <517E8823.3050404@mnt.se> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aJzMi3Xp - 59f9f9bb8c77 - 20130514 X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0aJzMi3Xp&m=59f9f9bb8c77&t=20130514&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0aJzMi3Xp&m=59f9f9bb8c77&t=20130514&c=n X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0aJzMi3Xp&m=59f9f9bb8c77&t=20130514&c=s X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] (not) scheduling in Berlin? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 12:18:13 -0000 On 04/29/2013 04:48 PM, Leif Johansson wrote: > On 04/29/2013 04:44 PM, Sam Hartman wrote: >> I'd recommend requesting a 1.5 hour session to discuss aaa-saml, and >> arch. If we end up canceling because we're already done, that would be >> fine, but it would be unfortunate not to have the time on the agenda. >> >> OK, guess I should go give you an answer on usability draft reviews:-) >> > Thx for the quick reply! Others? > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab just to be on the safe side we requested a session but said we were ok for friday - that way ppl won't scream at us if we wind up cancelling From stephen.farrell@cs.tcd.ie Wed May 15 15:36:15 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B2421F8A74 for ; Wed, 15 May 2013 15:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO3-GnXM465V for ; Wed, 15 May 2013 15:36:09 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85F21F89C3 for ; Wed, 15 May 2013 15:36:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3607CBE7D for ; Wed, 15 May 2013 23:35:45 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACKHoRKXBHKy for ; Wed, 15 May 2013 23:35:44 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.60.184]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9CA46BE76 for ; Wed, 15 May 2013 23:35:44 +0100 (IST) Message-ID: <51940DB6.6000200@cs.tcd.ie> Date: Wed, 15 May 2013 23:35:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] AD review of eap-applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 22:36:15 -0000 Hiya, Klaas sent on the publication request and my AD review is below. I don't see any show-stoppers here but would like if the chairs/shepherd/authors/wg would comment before I request IETF LC. Doesn't need loads of discussion but I'd like just to know there's nothing here that the wg didn't consider already. Thanks, S. - Should this update 3748? Current IESG thinking (i.e. want something else and someone will badger you:-) is that if a reader of 3748 really ought also read this, then this should update 3748; if its ok for a reader of 3748 to not have to read this, then this shouldn't update 3748. I'd guess that this should update 3847 but am ok if you say not. I'd like to just double check that before IETF LC since someone might want a 2nd LC otherwise. (Safest is to include it during IETF LC and the updates thing could always be dropped later.) - Mentioning the WG name in the abstract is usually wrong since the WG will go away. Maybe say what abfab does instead, e.g. like the charter does and say "...usage of the EAP protocol as part of a federated identity mechanism for use by Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS." (Same for later mentions of the wg.) - section 2: 2nd last para, last sentence: what does that mean? something is funny there - section 2: last para, 1st sentence: what does "between" mean there? - s2, last para: "an channel binding attributes" - do you mean one or more? (and fix grammar please) - s3, 2nd last para: s/part/party/ - s4, RECOMMENDS use of [I-D.ietf-emu-crypto-bind], doesn't that make it a normative reference? From hartmans@painless-security.com Wed May 15 15:47:48 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0102F21F8443 for ; Wed, 15 May 2013 15:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Foj2a9+ZaaU for ; Wed, 15 May 2013 15:47:43 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 429A611E80BA for ; Wed, 15 May 2013 15:47:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id DA0762057B; Wed, 15 May 2013 18:44:58 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mtxI4GNiA4S; Wed, 15 May 2013 18:44:57 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (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; Wed, 15 May 2013 18:44:57 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C0E8B440A; Wed, 15 May 2013 18:47:40 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <51940DB6.6000200@cs.tcd.ie> Date: Wed, 15 May 2013 18:47:40 -0400 In-Reply-To: <51940DB6.6000200@cs.tcd.ie> (Stephen Farrell's message of "Wed, 15 May 2013 23:35:34 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "" Subject: Re: [abfab] AD review of eap-applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 22:47:48 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> - Should this update 3748? Current IESG thinking (i.e. Stephen> want something else and someone will badger you:-) is that Stephen> if a reader of 3748 really ought also read this, then this Stephen> should update 3748; if its ok for a reader of 3748 to not Stephen> have to read this, then this shouldn't update 3748. I'd Stephen> guess that this should update 3847 but am ok if you say Stephen> not. I'd like to just double check that before IETF LC Stephen> since someone might want a 2nd LC otherwise. (Safest is to Stephen> include it during IETF LC and the updates thing could Stephen> always be dropped later.) This was brought up in WGLC. The conclusion I recall is that we should update 3748 and the document would be changed prior to IETF LC:-) Stephen> - Mentioning the WG name in the abstract is usually wrong Stephen> since the WG will go away. Maybe say what abfab does Stephen> instead, e.g. like the charter does and say "...usage of Stephen> the EAP protocol as part of a federated identity mechanism Stephen> for use by Internet protocols not based on HTML/HTTP, such Stephen> as for instance IMAP, XMPP, SSH and NFS." (Same for later Stephen> mentions of the wg.) I think we're calling the overall architecture ABFAB as well. so I think we're mentioning the technology (which is gss-eap, plus a way of describing naming of attributes, plus SAML rules for RADIUS, plus potentially things in the future) not the WG. Stephen> - s4, RECOMMENDS use of [I-D.ietf-emu-crypto-bind], doesn't Stephen> that make it a normative reference? Stephen> _______________________________________________ abfab Stephen> mailing list abfab@ietf.org Stephen> https://www.ietf.org/mailman/listinfo/abfab Except the emu draft doesn't define a protocol. It describes a mechanism you might want to include when designing EAP methods. So perhaps recommends using that mechanism when available in EAP methods or some such. --Sam From stephen.farrell@cs.tcd.ie Wed May 22 10:17:54 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ED621F961C for ; Wed, 22 May 2013 10:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj4Z5Swq6vvP for ; Wed, 22 May 2013 10:17:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4EB21F961B for ; Wed, 22 May 2013 10:17:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7D73BE97; Wed, 22 May 2013 18:17:22 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPpI-WEZAPAK; Wed, 22 May 2013 18:17:22 +0100 (IST) Received: from [IPv6:2001:770:10:203:69a4:8b70:c217:d77a] (unknown [IPv6:2001:770:10:203:69a4:8b70:c217:d77a]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 84823BE29; Wed, 22 May 2013 18:17:22 +0100 (IST) Message-ID: <519CFDA2.8080704@cs.tcd.ie> Date: Wed, 22 May 2013 18:17:22 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sam Hartman References: <51940DB6.6000200@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [abfab] AD review of eap-applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 17:17:54 -0000 Folks, Given Sam's response and that nobody disagreed I think it'd be best to update the updates thing before IETF LC so I've marked this as revised I-D needed. Please yell at me if that's wrong. Even better, shoot out that revised I-D and I'll start IETF LC. Thanks, S. On 05/15/2013 11:47 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > Stephen> - Should this update 3748? Current IESG thinking (i.e. > Stephen> want something else and someone will badger you:-) is that > Stephen> if a reader of 3748 really ought also read this, then this > Stephen> should update 3748; if its ok for a reader of 3748 to not > Stephen> have to read this, then this shouldn't update 3748. I'd > Stephen> guess that this should update 3847 but am ok if you say > Stephen> not. I'd like to just double check that before IETF LC > Stephen> since someone might want a 2nd LC otherwise. (Safest is to > Stephen> include it during IETF LC and the updates thing could > Stephen> always be dropped later.) > > This was brought up in WGLC. > The conclusion I recall is that we should update 3748 and the document > would be changed prior to IETF LC:-) > > Stephen> - Mentioning the WG name in the abstract is usually wrong > Stephen> since the WG will go away. Maybe say what abfab does > Stephen> instead, e.g. like the charter does and say "...usage of > Stephen> the EAP protocol as part of a federated identity mechanism > Stephen> for use by Internet protocols not based on HTML/HTTP, such > Stephen> as for instance IMAP, XMPP, SSH and NFS." (Same for later > Stephen> mentions of the wg.) > > > I think we're calling the overall architecture ABFAB as well. so I > think we're mentioning the technology (which is gss-eap, plus a way of > describing naming of attributes, plus SAML rules for RADIUS, plus > potentially things in the future) not the WG. > > Stephen> - s4, RECOMMENDS use of [I-D.ietf-emu-crypto-bind], doesn't > Stephen> that make it a normative reference? > Stephen> _______________________________________________ abfab > Stephen> mailing list abfab@ietf.org > Stephen> https://www.ietf.org/mailman/listinfo/abfab > > Except the emu draft doesn't define a protocol. > It describes a mechanism you might want to include when designing EAP > methods. > > So perhaps recommends using that mechanism when available in EAP > methods or some such. > > --Sam > > From yoshihiro.ohba@toshiba.co.jp Wed May 22 15:49:18 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0C521F90DF for ; Wed, 22 May 2013 15:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.422 X-Spam-Level: X-Spam-Status: No, score=-5.422 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeII-M2Y0jjY for ; Wed, 22 May 2013 15:49:12 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 240F321F90D2 for ; Wed, 22 May 2013 15:49:11 -0700 (PDT) Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id r4MMn1ht019065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 07:49:01 +0900 (JST) Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4MMn1Qo009428; Thu, 23 May 2013 07:49:01 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 385; Thu, 23 May 2013 07:49:01 +0900 (JST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id r4MMn1T9009416; Thu, 23 May 2013 07:49:01 +0900 Received: (from root@localhost) by arc1.toshiba.co.jp id r4MMn12e016005; Thu, 23 May 2013 07:49:01 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id HAA16004; Thu, 23 May 2013 07:49:01 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id r4MMn0E0000197; Thu, 23 May 2013 07:49:00 +0900 (JST) Received: from tgxml329.toshiba.local by toshiba.co.jp id r4MMn0aY005371; Thu, 23 May 2013 07:49:00 +0900 (JST) Received: from TGXML338.toshiba.local ([169.254.4.217]) by tgxml329.toshiba.local ([133.199.60.16]) with mapi id 14.03.0123.003; Thu, 23 May 2013 07:48:59 +0900 From: To: , Thread-Topic: [abfab] AD review of eap-applicability Thread-Index: AQHOUbyh9Rc07QG4SUOWajlcwJzrSZkG2P0+gAoNGwCAAPFp0A== Date: Wed, 22 May 2013 22:48:58 +0000 Message-ID: <674F70E5F2BE564CB06B6901FD3DD78B12D10049@tgxml338.toshiba.local> References: <51940DB6.6000200@cs.tcd.ie> <519CFDA2.8080704@cs.tcd.ie> In-Reply-To: <519CFDA2.8080704@cs.tcd.ie> Accept-Language: ja-JP, en-US Content-Language: ja-JP x-originating-ip: [133.199.16.114] msscp.transfermailtomossagent: 103 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: abfab@ietf.org Subject: Re: [abfab] AD review of eap-applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 22:49:18 -0000 If my understanding is correct we agreed that only section 3 of draft-ietf-= abfab-eapapplicability updates the EAP applicability statement in [RFC3748]= . =20 Regards, Yoshihiro Ohba -----Original Message----- From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of S= tephen Farrell Sent: Thursday, May 23, 2013 2:17 AM To: Sam Hartman Cc: Subject: Re: [abfab] AD review of eap-applicability Folks, Given Sam's response and that nobody disagreed I think it'd be best to upda= te the updates thing before IETF LC so I've marked this as revised I-D need= ed. Please yell at me if that's wrong. Even better, shoot out that revised I-D = and I'll start IETF LC. Thanks, S. On 05/15/2013 11:47 PM, Sam Hartman wrote: >>>>>> "Stephen" =3D=3D Stephen Farrell writes: >=20 > Stephen> - Should this update 3748? Current IESG thinking (i.e. > Stephen> want something else and someone will badger you:-) is that > Stephen> if a reader of 3748 really ought also read this, then this > Stephen> should update 3748; if its ok for a reader of 3748 to not > Stephen> have to read this, then this shouldn't update 3748. I'd > Stephen> guess that this should update 3847 but am ok if you say > Stephen> not. I'd like to just double check that before IETF LC > Stephen> since someone might want a 2nd LC otherwise. (Safest is to > Stephen> include it during IETF LC and the updates thing could > Stephen> always be dropped later.) >=20 > This was brought up in WGLC. > The conclusion I recall is that we should update 3748 and the=20 > document would be changed prior to IETF LC:-) >=20 > Stephen> - Mentioning the WG name in the abstract is usually wrong > Stephen> since the WG will go away. Maybe say what abfab does > Stephen> instead, e.g. like the charter does and say "...usage of > Stephen> the EAP protocol as part of a federated identity mechanism > Stephen> for use by Internet protocols not based on HTML/HTTP, such > Stephen> as for instance IMAP, XMPP, SSH and NFS." (Same for later > Stephen> mentions of the wg.) >=20 >=20 > I think we're calling the overall architecture ABFAB as well. so I=20 > think we're mentioning the technology (which is gss-eap, plus a way of=20 > describing naming of attributes, plus SAML rules for RADIUS, plus=20 > potentially things in the future) not the WG. >=20 > Stephen> - s4, RECOMMENDS use of [I-D.ietf-emu-crypto-bind], doesn't > Stephen> that make it a normative reference? > Stephen> _______________________________________________ abfab > Stephen> mailing list abfab@ietf.org > Stephen> https://www.ietf.org/mailman/listinfo/abfab >=20 > Except the emu draft doesn't define a protocol. > It describes a mechanism you might want to include when designing EAP=20 > methods. >=20 > So perhaps recommends using that mechanism when available in EAP=20 > methods or some such. >=20 > --Sam >=20 >=20 _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From stephen.farrell@cs.tcd.ie Wed May 22 16:15:29 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E7B11E8158 for ; Wed, 22 May 2013 16:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYi8eiCsxm23 for ; Wed, 22 May 2013 16:15:25 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A07B011E8151 for ; Wed, 22 May 2013 16:15:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1390DBE75; Thu, 23 May 2013 00:15:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmR9GPwW11HK; Thu, 23 May 2013 00:14:55 +0100 (IST) Received: from [10.87.48.5] (unknown [86.44.67.108]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 04F45BE35; Thu, 23 May 2013 00:14:55 +0100 (IST) Message-ID: <519D5164.5020405@cs.tcd.ie> Date: Thu, 23 May 2013 00:14:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: yoshihiro.ohba@toshiba.co.jp References: <51940DB6.6000200@cs.tcd.ie> <519CFDA2.8080704@cs.tcd.ie> <674F70E5F2BE564CB06B6901FD3DD78B12D10049@tgxml338.toshiba.local> In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D10049@tgxml338.toshiba.local> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] AD review of eap-applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 23:15:29 -0000 On 05/22/2013 11:48 PM, yoshihiro.ohba@toshiba.co.jp wrote: > If my understanding is correct we agreed that only section 3 of draft-ietf-abfab-eapapplicability updates the EAP applicability statement in [RFC3748]. That may be true, but that means that the RFC resulting from this I-D should have an "updates" relationship with 3748. So we ought fix that before IETF LC, just in case. S. > Regards, > Yoshihiro Ohba > > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Thursday, May 23, 2013 2:17 AM > To: Sam Hartman > Cc: > Subject: Re: [abfab] AD review of eap-applicability > > > Folks, > > Given Sam's response and that nobody disagreed I think it'd be best to update the updates thing before IETF LC so I've marked this as revised I-D needed. > > Please yell at me if that's wrong. Even better, shoot out that revised I-D and I'll start IETF LC. > > Thanks, > S. > > On 05/15/2013 11:47 PM, Sam Hartman wrote: >>>>>>> "Stephen" == Stephen Farrell writes: >> >> Stephen> - Should this update 3748? Current IESG thinking (i.e. >> Stephen> want something else and someone will badger you:-) is that >> Stephen> if a reader of 3748 really ought also read this, then this >> Stephen> should update 3748; if its ok for a reader of 3748 to not >> Stephen> have to read this, then this shouldn't update 3748. I'd >> Stephen> guess that this should update 3847 but am ok if you say >> Stephen> not. I'd like to just double check that before IETF LC >> Stephen> since someone might want a 2nd LC otherwise. (Safest is to >> Stephen> include it during IETF LC and the updates thing could >> Stephen> always be dropped later.) >> >> This was brought up in WGLC. >> The conclusion I recall is that we should update 3748 and the >> document would be changed prior to IETF LC:-) >> >> Stephen> - Mentioning the WG name in the abstract is usually wrong >> Stephen> since the WG will go away. Maybe say what abfab does >> Stephen> instead, e.g. like the charter does and say "...usage of >> Stephen> the EAP protocol as part of a federated identity mechanism >> Stephen> for use by Internet protocols not based on HTML/HTTP, such >> Stephen> as for instance IMAP, XMPP, SSH and NFS." (Same for later >> Stephen> mentions of the wg.) >> >> >> I think we're calling the overall architecture ABFAB as well. so I >> think we're mentioning the technology (which is gss-eap, plus a way of >> describing naming of attributes, plus SAML rules for RADIUS, plus >> potentially things in the future) not the WG. >> >> Stephen> - s4, RECOMMENDS use of [I-D.ietf-emu-crypto-bind], doesn't >> Stephen> that make it a normative reference? >> Stephen> _______________________________________________ abfab >> Stephen> mailing list abfab@ietf.org >> Stephen> https://www.ietf.org/mailman/listinfo/abfab >> >> Except the emu draft doesn't define a protocol. >> It describes a mechanism you might want to include when designing EAP >> methods. >> >> So perhaps recommends using that mechanism when available in EAP >> methods or some such. >> >> --Sam >> >> > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > > > From leifj@nordu.net Thu May 23 00:51:10 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9029921F9709 for ; Thu, 23 May 2013 00:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBuA4eCkCdas for ; Thu, 23 May 2013 00:51:02 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id 4625121F96F2 for ; Thu, 23 May 2013 00:51:01 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r4N7oAtw004655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 09:50:10 +0200 Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r4N7o3m4017355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 May 2013 07:50:06 GMT VBR-Info: md=nordu.net; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nordu.net; s=default; t=1369295409; bh=H3kZ/XBJW51odB8YUPzRIJU0oNsrs2daKGlW0wmUfdg=; h=From:Subject:References:In-Reply-To:Date:To:Cc; b=TLIjnX0rq3uoq/FAIiV0vQJ4nkWwiz/l3S9yJkEBYmvbmc7nIB22DbSkMjtgZjy7F 3EpInDZ844hZVJg9UEneE+JVRZ3/57zRhzGnsafqwUCbXy9XxNZ4kENC6GEb7DJfV8 R4nKBkU+/DaE2FVmu+/NGv8LxJ23cpuOY/I+eUac= X-Footer: bm9yZHUubmV0 Received: from [85.36.210.178] ([85.36.210.178]) by kerio.nordu.net; Thu, 23 May 2013 09:50:02 +0200 From: "Leif Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <51940DB6.6000200@cs.tcd.ie> <519CFDA2.8080704@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <519CFDA2.8080704@cs.tcd.ie> Message-Id: Date: Thu, 23 May 2013 09:49:57 +0200 To: Stephen Farrell X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=109.105.110.42; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aJDjOa06 - 6775e98463aa - 20130523 X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0aJDjOa06&m=6775e98463aa&t=20130523&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0aJDjOa06&m=6775e98463aa&t=20130523&c=n X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0aJDjOa06&m=6775e98463aa&t=20130523&c=s X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: "" , Klaas Wierenga Subject: Re: [abfab] AD review of eap-applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 07:51:11 -0000 22 maj 2013 kl. 19:18 skrev "Stephen Farrell" : > > Folks, > > Given Sam's response and that nobody disagreed I think it'd be > best to update the updates thing before IETF LC so I've marked > this as revised I-D needed. > > Please yell at me if that's wrong. Even better, shoot out > that revised I-D and I'll start IETF LC. > To change to 'updates' - yes. > Thanks, > S. > > On 05/15/2013 11:47 PM, Sam Hartman wrote: >>>>>>> "Stephen" == Stephen Farrell writes: >> >> Stephen> - Should this update 3748? Current IESG thinking (i.e. >> Stephen> want something else and someone will badger you:-) is that >> Stephen> if a reader of 3748 really ought also read this, then this >> Stephen> should update 3748; if its ok for a reader of 3748 to not >> Stephen> have to read this, then this shouldn't update 3748. I'd >> Stephen> guess that this should update 3847 but am ok if you say >> Stephen> not. I'd like to just double check that before IETF LC >> Stephen> since someone might want a 2nd LC otherwise. (Safest is to >> Stephen> include it during IETF LC and the updates thing could >> Stephen> always be dropped later.) >> >> This was brought up in WGLC. >> The conclusion I recall is that we should update 3748 and the document >> would be changed prior to IETF LC:-) >> >> Stephen> - Mentioning the WG name in the abstract is usually wrong >> Stephen> since the WG will go away. Maybe say what abfab does >> Stephen> instead, e.g. like the charter does and say "...usage of >> Stephen> the EAP protocol as part of a federated identity mechanism >> Stephen> for use by Internet protocols not based on HTML/HTTP, such >> Stephen> as for instance IMAP, XMPP, SSH and NFS." (Same for later >> Stephen> mentions of the wg.) >> >> >> I think we're calling the overall architecture ABFAB as well. so I >> think we're mentioning the technology (which is gss-eap, plus a way of >> describing naming of attributes, plus SAML rules for RADIUS, plus >> potentially things in the future) not the WG. >> >> Stephen> - s4, RECOMMENDS use of [I-D.ietf-emu-crypto-bind], doesn't >> Stephen> that make it a normative reference? >> Stephen> _______________________________________________ abfab >> Stephen> mailing list abfab@ietf.org >> Stephen> https://www.ietf.org/mailman/listinfo/abfab >> >> Except the emu draft doesn't define a protocol. >> It describes a mechanism you might want to include when designing EAP >> methods. >> >> So perhaps recommends using that mechanism when available in EAP >> methods or some such. >> >> --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu May 23 06:41:58 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88CA21F94A6 for ; Thu, 23 May 2013 06:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa0rv-c8BuQg for ; Thu, 23 May 2013 06:41:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B3B0421F8E76 for ; Thu, 23 May 2013 06:41:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id F3D1C2060A; Thu, 23 May 2013 09:38:50 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O23Mq7_dChKM; Thu, 23 May 2013 09:38:50 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 23 May 2013 09:38:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C1A59440B; Thu, 23 May 2013 09:41:50 -0400 (EDT) From: Sam Hartman To: References: <51940DB6.6000200@cs.tcd.ie> <519CFDA2.8080704@cs.tcd.ie> <674F70E5F2BE564CB06B6901FD3DD78B12D10049@tgxml338.toshiba.local> Date: Thu, 23 May 2013 09:41:50 -0400 In-Reply-To: <674F70E5F2BE564CB06B6901FD3DD78B12D10049@tgxml338.toshiba.local> (yoshihiro ohba's message of "Wed, 22 May 2013 22:48:58 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] AD review of eap-applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:41:59 -0000 >>>>> writes: > If my understanding is correct we agreed that only section 3 of > draft-ietf-abfab-eapapplicability updates the EAP applicability > statement in [RFC3748]. Regards, Yoshihiro Ohba i don't recall a discussion of that point, although it seems reasonably obvious. Only section 3 claims to be an EAp applicability statement. We did discuss the use of 2119 language at various points, but those changes have been made. The question here is whether an updates header should be added. From ietf@augustcellars.com Thu May 30 14:31:52 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5275521F86AE; Thu, 30 May 2013 14:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWWAr8GjTvLh; Thu, 30 May 2013 14:31:47 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 94C7521F8696; Thu, 30 May 2013 14:31:44 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 2A66C2CA20; Thu, 30 May 2013 14:31:44 -0700 (PDT) From: "Jim Schaad" To: References: <20130530211857.10340.69519.idtracker@ietfa.amsl.com> In-Reply-To: <20130530211857.10340.69519.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 14:30:52 -0700 Message-ID: <04ee01ce5d7c$f7c60240$e75206c0$@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: AQGebNoyW1RF+EXbAdPZfyyPhs4Yspl+HVnw Content-Language: en-us Cc: radext@ietf.org, abfab@ietf.org, MOONSHOT-COMMUNITY@JISCMAIL.AC.UK Subject: [abfab] FW: New Version Notification for draft-schaad-trust-router-problem-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 21:31:52 -0000 I present this document for discussion on the IETF Trust Router mailing = list. It is a new and completely different version of the problem statement = from that offered by the Janet people. I think it is a more complete = and more understandable document that the one they have provided. The document was started under an alcoholic haze and frustration over = the fact that the BOF for the group might not occur in Berlin as was = originally envisioned. The primary hope of this document is to try and = get more conversation on this mailing list about the problem itself. = Note that I don't currently care what the solution is. That should be = discussed after the BOF has been completed. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, May 30, 2013 2:19 PM > To: Jim Schaad > Subject: New Version Notification for = draft-schaad-trust-router-problem- > 01.txt >=20 >=20 > A new version of I-D, draft-schaad-trust-router-problem-01.txt > has been successfully submitted by Jim Schaad and posted to the IETF > repository. >=20 > Filename: draft-schaad-trust-router-problem > Revision: 01 > Title: Trust Router Problem Statement > Creation date: 2013-05-30 > Group: Individual Submission > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-schaad-trust-router-problem-01.= txt > Status: = http://datatracker.ietf.org/doc/draft-schaad-trust-router-problem > Htmlized: = http://tools.ietf.org/html/draft-schaad-trust-router-problem-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-schaad-trust-router-problem-01 >=20 > Abstract: > There are a number of problems with using the current AAA framework > for doing access control, this document looks at a number of these > issues and poses some questions about how to create a new trust > router system. >=20 >=20 >=20 >=20 > The IETF Secretariat