From lear@cisco.com Sun Jul 1 01:32:05 2012 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 16D3D21F84FF for ; Sun, 1 Jul 2012 01:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.508 X-Spam-Level: X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 4yYYDKik06eo for ; Sun, 1 Jul 2012 01:32:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5C621F84FE for ; Sun, 1 Jul 2012 01:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=934; q=dns/txt; s=iport; t=1341131526; x=1342341126; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0c7GlF0vOQ/YBf2WLIkLcstgYnCrNbGwU4YG9MdxgTQ=; b=C8HwaZp1ivqSptN3kjUnTr1N68jukVJyZg36kKkCW3pAzcOxdMcWRTw4 j8TIWtjq5CMiGYn7pLvNkZs/okilsYovIDe+WTsZqyaKi73ekvcUKtomI NjUa2afPc50s1MdwsjgmV6HBvuhVUu2bejDwk1iQZ+H3A7NwipEp95pD3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUJAIUJ8E+Q/khL/2dsb2JhbABFhVqvTQQEgSmBB4IYAQEBBAEBAQ8BEEsKARALGAICBRYLAgIJAwIBAgEVMAYNAQUCAQEeh2kLm2GNGZF4BIEgjyOBEgOVNI4dgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,504,1336348800"; d="scan'208";a="74998369" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Jul 2012 08:32:04 +0000 Received: from ams3-vpn-dhcp4162.cisco.com (ams3-vpn-dhcp4162.cisco.com [10.61.80.65]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q618W47T019849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 1 Jul 2012 08:32:04 GMT Message-ID: <4FF00B03.3040104@cisco.com> Date: Sun, 01 Jul 2012 10:32:03 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Jim Schaad References: <029001cd56f2$d9551a80$8bff4f80$@augustcellars.com> In-Reply-To: <029001cd56f2$d9551a80$8bff4f80$@augustcellars.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, Sam Hartman Subject: Re: [abfab] SAML Draft and SAML 1.0 vs SAML 2.0 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 08:32:05 -0000 In the various work in Kitten we specifically call out SAML 2.0. Although I hazard a guess that the likelihood of substantial incompatibility would be low, since you can't tell what will happen with a new version of ANYTHING, as a general rule it is best to be specific (IMHO). Eliot On 6/30/12 9:02 PM, Jim Schaad wrote: > SAML 2.0 is the latest and best version of SAML. Is there/should there be a > restriction in the SAML document about using just SAML 2.0 and higher? If a > new version of SAML is produced, does there need to be a different set of > messages defined or should the current set of messages be sufficient > (assuming that the entire protocol world is not radically overhauled). > > Does any of this need to be put into the document? > > Jim > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > > From leifj@sunet.se Sun Jul 1 07:37:49 2012 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 C7E9921F890D for ; Sun, 1 Jul 2012 07:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 JZjv9q1mA00S for ; Sun, 1 Jul 2012 07:37:49 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id CE5FB21F88F4 for ; Sun, 1 Jul 2012 07:37:48 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q61Ebi2N021826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 1 Jul 2012 16:37:47 +0200 (CEST) Message-ID: <4FF060B6.7090707@sunet.se> Date: Sun, 01 Jul 2012 16:37:42 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <029001cd56f2$d9551a80$8bff4f80$@augustcellars.com> In-Reply-To: <029001cd56f2$d9551a80$8bff4f80$@augustcellars.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] SAML Draft and SAML 1.0 vs SAML 2.0 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jul 2012 14:37:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/30/2012 09:02 PM, Jim Schaad wrote: > SAML 2.0 is the latest and best version of SAML. Is there/should > there be a restriction in the SAML document about using just SAML > 2.0 and higher? If a new version of SAML is produced, does there > need to be a different set of messages defined or should the > current set of messages be sufficient (assuming that the entire > protocol world is not radically overhauled). > > Does any of this need to be put into the document? I think (as individual) that calling out SAML 2 is fine. There will probably be a 2.1 in our lifetime but whatever 3.0 looks like it is unlikely that it is automatically applicable to ABFAB. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/wYLIACgkQ8Jx8FtbMZndCiwCgxqWSjVAe40w34CPuvJeriWv1 I98AnRYsrce88WR9tfiaHbGVTWnu56jf =yKqx -----END PGP SIGNATURE----- From leifj@mnt.se Sun Jul 8 07:37:34 2012 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 95C7821F8567; Sun, 8 Jul 2012 07:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=-0.540, 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 ALPTpTShK1hG; Sun, 8 Jul 2012 07:37:33 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 666A021F8562; Sun, 8 Jul 2012 07:37:33 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q68EbmSQ003431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2012 16:37:52 +0200 (CEST) Message-ID: <4FF99B3C.1060807@mnt.se> Date: Sun, 08 Jul 2012 16:37:48 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: scim WG , "abf >> \"abfab@ietf.org\"" References: In-Reply-To: X-Enigmail-Version: 1.4.2 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Fwd: Fwd: NomCom 2012-13 Call for Volunteers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 14:37:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: Fwd: NomCom 2012-13 Call for Volunteers Date: Sat, 7 Jul 2012 14:44:36 -0400 From: Barry Leiba To: app-chairs@tools.ietf.org Please consider posting this to your working group mailing lists. The NomCom process is extremely important to the IETF, and willing volunteers are necessary for the success of the NomCom. Thanks, Barry - ---------- Forwarded message ---------- From: *NomCom Chair* Date: Friday, July 6, 2012 Subject: NomCom 2012-13 Call for Volunteers To: IETF Announcement List > The IETF nominating committee process for 2012-13 has begun. The IETF nominating committee appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. The 10 nominating committee members are selected randomly from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. The details of the operation of the nomcom can be found in RFC 3777. To be eligible, volunteers for the nomcom need to have attended 3 of the past 5 IETF meetings as of the time this announcement goes out. That is, 3 meetings from IETF 79 (Beijing) - IETF 83 (Paris). If you qualify, and if you will not be seeking appointment to any of the open positions that this nomcom will be filling, please consider volunteering. The list of people whose terms end with the March 2013 IETF meeting, and thus the positions for which the nominating committee is responsible for filling, are as follows: IAOC: - -------- Dave Crocker IAB: - -------- Alissa Cooper Joel Halpern David Kessens Danny McPherson Jon Peterson Dave Thaler IESG: - -------- Russ Housley (General Area) Pete Resnick (Applications Area) Ralph Droms (Internet Area) Ronald Bonica (Operations and Management Area) Robert Sparks (Real-Time Applications and Infrastructure Area) Adrian Farrel (Routing Area) Stephen Farrell (Security Area) Wesley Eddy (Transport Area) The primary activity for this nomcom will begin in August 2012 and should be completed in January 2013. The nomcom will be collecting requirements from the community, as well as talking to candidates and obtaining feedback from community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. Please volunteer by sending an email before 11:59 pm EDT (UTC - 4 hours) August 5, 2012 as follows: To: mlepinski.ietf@gmail.com Subject: Nomcom 2012-13 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form [] // // For confirmation if selected Please expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the nomcom is a good way of contributing toward that goal. I will be publishing a more detailed timetable for nomcom activities, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you, Matthew Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/5mzcACgkQ8Jx8FtbMZnd8mACffOPeYkH9A3qAvDdDNao7jTHn tpIAn2pxB68GShW0DMuGKaRaj8/I2kCb =+Mg9 -----END PGP SIGNATURE----- From leifj@mnt.se Sun Jul 8 13:04:19 2012 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 6258421F8668 for ; Sun, 8 Jul 2012 13:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.09 X-Spam-Level: X-Spam-Status: No, score=-3.09 tagged_above=-999 required=5 tests=[AWL=-0.491, 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 XvVN7kdGstXM for ; Sun, 8 Jul 2012 13:04:18 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC8421F869D for ; Sun, 8 Jul 2012 13:04:17 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q68K4Y34008009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Jul 2012 22:04:39 +0200 (CEST) Message-ID: <4FF9E7D2.9000307@mnt.se> Date: Sun, 08 Jul 2012 22:04:34 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <4FE08777.7000802@cisco.com> In-Reply-To: <4FE08777.7000802@cisco.com> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] WGLC on draft-ietf-abfab-usecases-03 (ending July 4th 2012) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 20:04:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/19/2012 04:06 PM, Klaas Wierenga wrote: > Hi, > > The chairs believe that draft-ietf-abfab-usecases-03 is ready for > last call and that any remaining issues can be addressed during the > WGLC. > > This is then a WGLC on draft-ietf-abfab-usecases-03 > (http://tools.ietf.org/html/draft-ietf-abfab-usecases-03). Please > provide comments and/or feedback by July 4th 2012. The WGLC has neded and there were no comments. We'll submit this to the IESG for publication asap. Klaas & Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/5580ACgkQ8Jx8FtbMZne3IQCfRQQ98Vi2suk/QQLfY4OwRyUz WNsAoMpdwiWOrfkrLyhGhrq6yrhEVqW8 =zU11 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Mon Jul 9 10:14:09 2012 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 4077B11E8122; Mon, 9 Jul 2012 10:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 92RH-KliqxWv; Mon, 9 Jul 2012 10:14:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB1F11E8140; Mon, 9 Jul 2012 10:14:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120709171408.20328.2523.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 10:14:08 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-03.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: Mon, 09 Jul 2012 17:14:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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 (AB= FAB) Architecture Author(s) : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Jim Schaad Filename : draft-ietf-abfab-arch-03.txt Pages : 44 Date : 2012-07-09 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 and web-based access. However, the solutions to these use-cases that have been proposed and deployed tend to have few common 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) and the Diameter protocol, the Generic Security Service (GSS), the GS2 family, 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-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Mon Jul 9 11:57:57 2012 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 534CE11E813E for ; Mon, 9 Jul 2012 11:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpWJkexy75ej for ; Mon, 9 Jul 2012 11:57:56 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5035511E8138 for ; Mon, 9 Jul 2012 11:57:56 -0700 (PDT) Received: from Tobias (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id E68D62CA6C for ; Mon, 9 Jul 2012 11:58:21 -0700 (PDT) From: "Jim Schaad" To: References: <20120709171408.20328.2523.idtracker@ietfa.amsl.com> In-Reply-To: <20120709171408.20328.2523.idtracker@ietfa.amsl.com> Date: Mon, 9 Jul 2012 11:57:02 -0700 Message-ID: <00d501cd5e04$a11c50c0$e354f240$@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: AQLJxlFrd1efHP7K+Lb7/Atairar/5UofFOw Content-Language: en-us Subject: [abfab] FW: I-D Action: draft-ietf-abfab-arch-03.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: Mon, 09 Jul 2012 18:57:57 -0000 This version has had a substantial rewrite on section 2. The new version makes it more clear what protocols are used where and gives some of the reasoning behind the selection of the protocol. Comments and suggestions are gladly welcomed. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: Monday, July 09, 2012 10:14 AM > To: i-d-announce@ietf.org > Cc: abfab@ietf.org > Subject: [abfab] I-D Action: draft-ietf-abfab-arch-03.txt > > > 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 > Author(s) : Josh Howlett > Sam Hartman > Hannes Tschofenig > Eliot Lear > Jim Schaad > Filename : draft-ietf-abfab-arch-03.txt > Pages : 44 > Date : 2012-07-09 > > 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 and web-based access. However, the > solutions to these use-cases that have been proposed and deployed > tend to have few common 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) and the Diameter protocol, the Generic > Security Service (GSS), the GS2 family, 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-03 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-ietf-abfab-arch-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From smith@Cardiff.ac.uk Mon Jul 9 12:29:00 2012 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 4A14811E81F7 for ; Mon, 9 Jul 2012 12:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVgdXawgxzPL for ; Mon, 9 Jul 2012 12:28:59 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0311E81F9 for ; Mon, 9 Jul 2012 12:28:59 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1SoJe7-0006jP-OJ for abfab@ietf.org; Mon, 09 Jul 2012 20:29:23 +0100 Received: from [86.135.80.61] (helo=penfold.home) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SoJe7-0006gf-L2 for abfab@ietf.org; Mon, 09 Jul 2012 20:29:23 +0100 From: Rhys Smith Content-Type: multipart/alternative; boundary="Apple-Mail=_4325423E-8BA2-4AE7-97EB-F99BB099A81D" Date: Mon, 9 Jul 2012 20:29:24 +0100 References: <20120709192301.27550.87624.idtracker@ietfa.amsl.com> To: abfab@ietf.org Message-Id: <78B33A20-4540-47EF-A098-7C4CD2B54D87@cardiff.ac.uk> Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] Fwd: New Version Notification for draft-smith-abfab-usability-ui-considerations-02.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: Mon, 09 Jul 2012 19:29:00 -0000 --Apple-Mail=_4325423E-8BA2-4AE7-97EB-F99BB099A81D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii -02 of my UI draft has been posted, see below. All of the major sections = are now pretty much complete apart from the handling of errors section, = and a few little bits and pieces here and there. Note that I re-posed -01 on here a while ago inviting comments but = haven't had any so far. It'd be great if a few people could have a = glance through it and provide some feedback; it would be great to have = it adopted by the WG in vancouver - it's still currently an individual = submission but is on the WG charter. Then post-Vancouver we can fix the = last bits and get the document moving! Thanks all, Rhys. N.B. I'm going on vacation tomorrow for 2 weeks so won't be able to = address any comments immediately, so if I don't reply I'm not ignoring = you, honest :-). -- 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: internet-drafts@ietf.org > Subject: New Version Notification for = draft-smith-abfab-usability-ui-considerations-02.txt > Date: 9 July 2012 20:23:01 GMT+01:00 > To: smith@cardiff.ac.uk >=20 >=20 > A new version of I-D, = draft-smith-abfab-usability-ui-considerations-02.txt > has been successfully submitted by Rhys Smith and posted to the > IETF repository. >=20 > Filename: draft-smith-abfab-usability-ui-considerations > Revision: 02 > Title: Application Bridging for Federated Access = Beyond web (ABFAB) Usability and User Interface Considerations > Creation date: 2012-07-09 > WG ID: Individual Submission > Number of pages: 15 > URL: = http://www.ietf.org/internet-drafts/draft-smith-abfab-usability-ui-conside= rations-02.txt > Status: = http://datatracker.ietf.org/doc/draft-smith-abfab-usability-ui-considerati= ons > Htmlized: = http://tools.ietf.org/html/draft-smith-abfab-usability-ui-considerations-0= 2 > Diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-smith-abfab-usability-ui-consid= erations-02 >=20 > Abstract: > The use of ABFAB-based technologies requires that each user's device > is configured with the user's identities that they wish to use in > ABFAB transactions. This will require something on that device, > either built into the operating system or a standalone utility, that > will manage the user's identities and identity to service mappings. > Anyone designing that "something" will face the same set of > challenges. This document aims to document these challenges with = the > aim of producing well-thought out UIs with some degree of > consistency. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_4325423E-8BA2-4AE7-97EB-F99BB099A81D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii -02 = of my UI draft has been posted, see below. All of the major sections are = now pretty much complete apart from the handling of errors section, and = a few little bits and pieces here and there.

Note = that I re-posed -01 on here a while ago inviting comments but haven't = had any so far. It'd be great if a few people could have a glance = through it and provide some feedback; it would be great to have it = adopted by the WG in vancouver - it's still currently an individual = submission but is on the WG charter. Then post-Vancouver we can fix the = last bits and get the document moving!

Thanks = all,
Rhys.

N.B. I'm going on vacation = tomorrow for 2 weeks so won't be able to address any comments = immediately, so if I don't reply I'm not ignoring you, honest = :-).
--
Dr Rhys Smith
Identity, Access, and = Middleware Specialist
Cardiff University & Janet - the UK's = research and education network
smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

Begin forwarded message:

Subject: New Version Notification for = draft-smith-abfab-usability-ui-considerations-02.txt
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">Date: 9 July 2012 = 20:23:01 GMT+01:00
To: smith@cardiff.ac.uk


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

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

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




The IETF = Secretariat

= --Apple-Mail=_4325423E-8BA2-4AE7-97EB-F99BB099A81D-- From hartmans@painless-security.com Wed Jul 11 12:20:16 2012 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 3F9EC11E810C for ; Wed, 11 Jul 2012 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Sc4l+h0iDBIN for ; Wed, 11 Jul 2012 12:20:15 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 838EB11E80DB for ; Wed, 11 Jul 2012 12:20:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C9D98203BA; Wed, 11 Jul 2012 15:21:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 012B141F3; Wed, 11 Jul 2012 15:20:31 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <007e01cd039a$e51de140$af59a3c0$@augustcellars.com> Date: Wed, 11 Jul 2012 15:20:31 -0400 In-Reply-To: <007e01cd039a$e51de140$af59a3c0$@augustcellars.com> (Jim Schaad's message of "Fri, 16 Mar 2012 10:33:18 -0700") 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] Comments on abfab-gss-eap-naming-02 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, 11 Jul 2012 19:20:16 -0000 Jim, per our discussion, I've added text to gss-eap-naming-03 indicating that today we're not defining the semantics of setting these attributes. >>>>> "Jim" == Jim Schaad writes: Jim> Sam & Josh, Jim> This document looks good, only a couple of issues most of which are probably Jim> not too contentious. In terms of tone, I am making the assumption that Jim> there is nothing in the naming that prevents a set as well as a get for many Jim> of the properties. I am not sure that it makes any sense to do a set for Jim> SAML Attributes and maybe Name Identifiers, just the entire SAML statement. Jim> That could potentially be done via the RADIUS attribute and just say that Jim> all of the fed-saml-* names are read-only names. I don't know if this is a Jim> GSS-API concept or not. Jim> Jim Jim> Major: Jim> 1. In section 5 - I believe the following text should be added to the last Jim> paragraph. "If more than one attribute for the name exists in the packet, a Jim> multi-valued value is returned." Jim> 2. In section 5 - What text do we need to put in here about the temporal Jim> nature of the values? I assume, but don't know, that all of the values Jim> would be wiped out and a new set of values would be populated when, and if, Jim> a new RADIUS response is received. An alternative would be to state that Jim> only some values are over-written - either a specific set or those with new Jim> values. I do not believe that we generally want to always just append Jim> values together. This would lead to possibly n State attribute values, one Jim> for every RADIUS message pair exchanged. Jim> 3. In section 5 - Is there a need for the Code of the last packet to be Jim> retrievable from the GSS-API interface? This is not currently doable. Jim> 4. In section 5/6.1 - There is a restriction on getting the SAML assertion Jim> via the fed-saml-assertion name. Does the same restriction exist if the Jim> value is retrieved via the radius-attr name? Jim> 5. In section 6 - Is there a need to distinguish between the an empty Jim> AttributeValue and a Nil AttributeValue. There is text in 2.7.3.1 of Jim> SAML-CORE-2.0 that does so, but it is not reflected in section 6.2. Jim> Minor: Jim> 1. In section 4 para #5 - I think that s/MUST not/MUST NOT/ - however - Jim> how would that GSS-API code be able to possibly enforce the requirement? From internet-drafts@ietf.org Wed Jul 11 12:47:27 2012 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 1FA2911E8139; Wed, 11 Jul 2012 12:47:27 -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 lcmRvP29Hspq; Wed, 11 Jul 2012 12:47:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A263C11E80C8; Wed, 11 Jul 2012 12:47:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120711194726.15784.67700.idtracker@ietfa.amsl.com> Date: Wed, 11 Jul 2012 12:47:26 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 19:47:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Name Attributes for the GSS-API EAP mechanism Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-naming-03.txt Pages : 14 Date : 2012-07-11 Abstract: The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming-03 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-gss-eap-naming-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@painless-security.com Wed Jul 11 12:48:39 2012 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 5BCD711E812D for ; Wed, 11 Jul 2012 12:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 mE2-uOusQw6M for ; Wed, 11 Jul 2012 12:48:39 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E0BE411E80C8 for ; Wed, 11 Jul 2012 12:48:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9B8CB203BA for ; Wed, 11 Jul 2012 15:49:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EDE8F41F0; Wed, 11 Jul 2012 15:48:59 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 11 Jul 2012 15:48:59 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] draft-ietf-abfab-gss-eap-naming believed ready for last call 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, 11 Jul 2012 19:48:39 -0000 I believe the version of gss-eap-naming I just posted is ready for WG LC. From ietf@augustcellars.com Fri Jul 13 20:09:46 2012 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 9353F21F86D8 for ; Fri, 13 Jul 2012 20:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 f-sh2G00cNzi for ; Fri, 13 Jul 2012 20:09:41 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id D58B421F86D6 for ; Fri, 13 Jul 2012 20:09:41 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 3076938EEE; Fri, 13 Jul 2012 20:10:18 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Fri, 13 Jul 2012 20:08:59 -0700 Message-ID: <011101cd616e$0400a3a0$0c01eae0$@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: AQItLSFlIDnqLO+ojZBMKe64RR50xpZoecWw Content-Language: en-us Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming believed ready for last call X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jul 2012 03:09:47 -0000 Major NONE - I agree the document is ready for last call and progression Minor 1. Just because I keep having to go and read the SAML document every time, it might be useful to provide an example in paragraph 1 of section 3 about what makes a first part and a second part. I would pass the document without this, it is just a suggestion. 2. In section 3 paragraph 2 - Suggest changing the first occurrence of URI to URN so that sentence 2 and 3 use the same name for this value (URN vs URI). 3. In section 5, I thought we had agreed that there should be a statement that "The values, prior to receiving the access-accept message, are undefined." 4. Section 6.1 - I think this is correct. s/is always authentic when present/is always authenticated when present/ If I am wrong (which is possible) then I am not sure what the word authentic is supposed to be. I don't think it currently makes sense. The argument against the above is the following on sentence which states that a new GSS-API mechanism may allow it to be unauthenticated. 5. Section 6.1 - unclear if this is useful information or not. Might want to say that for GSS-API-EAP, it is the same as "urn:ietf:gss:radius-attribute TBD". 6. Section 5 - the above note just nudged a new one. Does there need to be a DIME attribute as the number space can be larger. Perhaps just a comment to the effect that some DIME space may not be reachable? 7. Section 6.2 -- Possible comment to be added. "If the implementation does discard it, then processing the entire SAML statement will result in a different answer than processing the individual attributes." This might just be a security considerations comment. Nits s/definied/defined/ > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, July 11, 2012 12:49 PM > To: abfab@ietf.org > Subject: [abfab] draft-ietf-abfab-gss-eap-naming believed ready for last call > > > > I believe the version of gss-eap-naming I just posted is ready for WG LC. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From klaas@wierenga.net Tue Jul 17 02:59:46 2012 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 4262021F85C5 for ; Tue, 17 Jul 2012 02:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hd0AxTgmLtY4 for ; Tue, 17 Jul 2012 02:59:45 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A142321F859A for ; Tue, 17 Jul 2012 02:59:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEABA3BVCtJXG9/2dsb2JhbABFuU6BB4I5ASdsfUmHa5sfgSigLI5rgjxgA6NfgWaCYQ X-IronPort-AV: E=Sophos;i="4.77,601,1336348800"; d="scan'208";a="102555125" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 17 Jul 2012 10:00:32 +0000 Received: from rtp-kwiereng-8714.cisco.com (rtp-kwiereng-8714.cisco.com [10.116.7.37]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6HA0V3I026198 for ; Tue, 17 Jul 2012 10:00:31 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2012 12:00:30 +0200 Message-Id: <6935293D-2591-4C39-B8B9-BE947CF609E8@wierenga.net> To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [abfab] Abfab @IETF84 Agenda 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, 17 Jul 2012 09:59:46 -0000 Hi, I have just uploaded below draft agenda. If you have any additions = please let us know. Klaas & Leif =3D=3D=3D - Agenda Bashing and Note Well (Chairs, 5 min) - Document status * Architecture Draft (Jim Schaad, 20 min) * User Interface (Rhys Smith, 10 min) * EAP Applicability (Joe Salowey, 5 min) - Milestones and remaining document status (Chairs, 10 min) - Open Mic (All, 45 min)= From ietf@augustcellars.com Tue Jul 17 10:32:21 2012 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 8B51A21F865C for ; Tue, 17 Jul 2012 10:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 m7m02XVkpSi0 for ; Tue, 17 Jul 2012 10:32:21 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E77C921F85C4 for ; Tue, 17 Jul 2012 10:32:20 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D2DFA2CA10; Tue, 17 Jul 2012 10:33:08 -0700 (PDT) From: "Jim Schaad" To: "'Klaas Wierenga'" , References: <6935293D-2591-4C39-B8B9-BE947CF609E8@wierenga.net> In-Reply-To: <6935293D-2591-4C39-B8B9-BE947CF609E8@wierenga.net> Date: Tue, 17 Jul 2012 10:31:45 -0700 Message-ID: <027b01cd6442$0a3a6270$1eaf2750$@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: AQKHy5Bpoz6m8lbA3mjrxkCZzMvjbJW47OJw Content-Language: en-us Subject: Re: [abfab] Abfab @IETF84 Agenda 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, 17 Jul 2012 17:32:21 -0000 Is there nothing to say about the SAML draft? > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Klaas Wierenga > Sent: Tuesday, July 17, 2012 3:01 AM > To: abfab@ietf.org > Subject: [abfab] Abfab @IETF84 Agenda > > Hi, > > I have just uploaded below draft agenda. If you have any additions please let > us know. > > Klaas & Leif > > === > - Agenda Bashing and Note Well (Chairs, 5 min) > - Document status > * Architecture Draft (Jim Schaad, 20 min) > * User Interface (Rhys Smith, 10 min) > * EAP Applicability (Joe Salowey, 5 min) > - Milestones and remaining document status (Chairs, 10 min) > - Open Mic (All, 45 min) > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Tue Jul 17 13:34:35 2012 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 DD79B21F860F for ; Tue, 17 Jul 2012 13:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, 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 RfcWA4ZLmFXl for ; Tue, 17 Jul 2012 13:34:35 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 6876521F8582 for ; Tue, 17 Jul 2012 13:34:35 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 9FA862CA34; Tue, 17 Jul 2012 13:35:23 -0700 (PDT) From: "Jim Schaad" To: "'Leif Johansson'" References: <6935293D-2591-4C39-B8B9-BE947CF609E8@wierenga.net> <027b01cd6442$0a3a6270$1eaf2750$@augustcellars.com> <6452D235-E41A-48B8-A65A-881B5008509A@nordu.net> In-Reply-To: <6452D235-E41A-48B8-A65A-881B5008509A@nordu.net> Date: Tue, 17 Jul 2012 13:34:00 -0700 Message-ID: <028501cd645b$7fc54a50$7f4fdef0$@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: AQKHy5Bpoz6m8lbA3mjrxkCZzMvjbAHJ5fARAov+/6GVlnCoQA== Content-Language: en-us Cc: abfab@ietf.org, 'Klaas Wierenga' Subject: Re: [abfab] Abfab @IETF84 Agenda 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, 17 Jul 2012 20:34:36 -0000 Yes > -----Original Message----- > From: Leif Johansson [mailto:leifj@nordu.net] > Sent: Tuesday, July 17, 2012 1:30 PM > To: Jim Schaad > Cc: Klaas Wierenga; abfab@ietf.org > Subject: Re: [abfab] Abfab @IETF84 Agenda > > > You mean aaa-saml? > > 17 jul 2012 kl. 19:33 skrev "Jim Schaad" : > > > Is there nothing to say about the SAML draft? > > > >> -----Original Message----- > >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On > >> Behalf Of Klaas Wierenga > >> Sent: Tuesday, July 17, 2012 3:01 AM > >> To: abfab@ietf.org > >> Subject: [abfab] Abfab @IETF84 Agenda > >> > >> Hi, > >> > >> I have just uploaded below draft agenda. If you have any additions > >> please > > let > >> us know. > >> > >> Klaas & Leif > >> > >> === > >> - Agenda Bashing and Note Well (Chairs, 5 min) > >> - Document status > >> * Architecture Draft (Jim Schaad, 20 min) > >> * User Interface (Rhys Smith, 10 min) > >> * EAP Applicability (Joe Salowey, 5 min) > >> - Milestones and remaining document status (Chairs, 10 min) > >> - Open Mic (All, 45 min) > >> _______________________________________________ > >> abfab mailing list > >> abfab@ietf.org > >> https://www.ietf.org/mailman/listinfo/abfab > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab From klaas@wierenga.net Tue Jul 17 14:31:43 2012 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 37B7011E80AD for ; Tue, 17 Jul 2012 14:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 EHUo6wfEZHZ8 for ; Tue, 17 Jul 2012 14:31:42 -0700 (PDT) Received: from out46-ams.mf.surf.net (out46-ams.mf.surf.net [145.0.1.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7425111E80A4 for ; Tue, 17 Jul 2012 14:31:41 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q6HLW5TB004671; Tue, 17 Jul 2012 23:32:05 +0200 Received: from rtp-isp-nat1.cisco.com ([64.102.254.33] helo=[10.116.7.46]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1SrFJt-0006G0-LT; Tue, 17 Jul 2012 23:28:39 +0200 References: <6935293D-2591-4C39-B8B9-BE947CF609E8@wierenga.net> <027b01cd6442$0a3a6270$1eaf2750$@augustcellars.com> <6452D235-E41A-48B8-A65A-881B5008509A@nordu.net> <028501cd645b$7fc54a50$7f4fdef0$@augustcellars.com> In-Reply-To: <028501cd645b$7fc54a50$7f4fdef0$@augustcellars.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <0073125D-A9EE-465F-87CF-9B661E0EB8B1@wierenga.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (9B206) From: Klaas Wierenga Date: Tue, 17 Jul 2012 23:32:00 +0200 To: Jim Schaad X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@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: 0vHzxw5qv - 33218fcfb90f - 20120717 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: "" , Leif Johansson Subject: Re: [abfab] Abfab @IETF84 Agenda 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, 17 Jul 2012 21:31:43 -0000 Well, i think none of the authors are going to be at the meeting, so I thoug= ht it better to cover in the 'other documents update'=20 Sent from my iPhone On 17 jul. 2012, at 22:34, "Jim Schaad" wrote: > Yes >=20 >> -----Original Message----- >> From: Leif Johansson [mailto:leifj@nordu.net] >> Sent: Tuesday, July 17, 2012 1:30 PM >> To: Jim Schaad >> Cc: Klaas Wierenga; abfab@ietf.org >> Subject: Re: [abfab] Abfab @IETF84 Agenda >>=20 >>=20 >> You mean aaa-saml? >>=20 >> 17 jul 2012 kl. 19:33 skrev "Jim Schaad" : >>=20 >>> Is there nothing to say about the SAML draft? >>>=20 >>>> -----Original Message----- >>>> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On >>>> Behalf Of Klaas Wierenga >>>> Sent: Tuesday, July 17, 2012 3:01 AM >>>> To: abfab@ietf.org >>>> Subject: [abfab] Abfab @IETF84 Agenda >>>>=20 >>>> Hi, >>>>=20 >>>> I have just uploaded below draft agenda. If you have any additions >>>> please >>> let >>>> us know. >>>>=20 >>>> Klaas & Leif >>>>=20 >>>> =3D=3D=3D >>>> - Agenda Bashing and Note Well (Chairs, 5 min) >>>> - Document status >>>> * Architecture Draft (Jim Schaad, 20 min) >>>> * User Interface (Rhys Smith, 10 min) >>>> * EAP Applicability (Joe Salowey, 5 min) >>>> - Milestones and remaining document status (Chairs, 10 min) >>>> - Open Mic (All, 45 min) >>>> _______________________________________________ >>>> 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 >=20 From hartmans@mit.edu Wed Jul 18 09:08:30 2012 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 69E1A21F860B for ; Wed, 18 Jul 2012 09:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 rf1nnAuzA-YE for ; Wed, 18 Jul 2012 09:08:28 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E05C521F8678 for ; Wed, 18 Jul 2012 09:08:27 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B86C2203BA for ; Wed, 18 Jul 2012 12:09:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 68D3241F0; Wed, 18 Jul 2012 12:08:53 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 18 Jul 2012 12:08:53 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: [abfab] [Various] [secdir] secdir review of draft-ietf-abfab-gss-eap-08 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 16:08:30 -0000 --=-=-= for the WG's review. a secdir review and my answers. --=-=-= Content-Type: multipart/digest; boundary="==-=-=" --==-=-= Subject: Topics MIME-Version: 1.0 Topics: Re: [secdir] secdir review of draft-ietf-abfab-gss-eap-08 [secdir] secdir review of draft-ietf-abfab-gss-eap-08 --==-=-= Date: Wed, 18 Jul 2012 12:05:29 -0400 From: Sam Hartman To: Jeffrey Hutzelman Cc: draft-ietf-abfab-gss-eap.all@tools.ietf.org, The IESG , secdir Subject: Re: [secdir] secdir review of draft-ietf-abfab-gss-eap-08 Message-ID: References: <1342587005.7190.56.camel@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 [Stephen, I have a new draft ready. I think we'll still need to ask the WG about the escaping issue, but should I publish?] >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Jeffrey> ======================================== Jeffrey> Section 3.1 discusses the format of the GSS-API Mechanism Names (MNs) Jeffrey> used by the family of mechanisms defined in this document. However, it Jeffrey> sort of glosses over the notion that, in GSS-API jargon, "Mechanism Name" Jeffrey> means a name of an initiator or acceptor in a mechanism-specific format, Jeffrey> and _not_ the name of a mechanism, as one might otherwise assume. I Jeffrey> suggest the following change to the first paragraph of this section: Jeffrey> OLD: Jeffrey> Before discussing how the initiator and acceptor names are validated Jeffrey> in the AAA infrastructure, it is necessary to discuss what composes a Jeffrey> name for an EAP GSS-API mechanism. GSS-API permits several types of Jeffrey> generic names to be imported using GSS_Import_name(). Once a Jeffrey> mechanism is chosen, these names are converted into a mechanism name Jeffrey> form. This section first discusses the mechanism name form and then Jeffrey> discusses what name forms are supported. Jeffrey> NEW: Jeffrey> Before discussing how the initiator and acceptor names are validated Jeffrey> in the AAA infrastructure, it is necessary to discuss what composes a Jeffrey> name for an EAP GSS-API mechanism. GSS-API permits several types of Jeffrey> generic names to be imported using GSS_Import_name(). Once a Jeffrey> mechanism is chosen, these names are converted into a Jeffrey> mechanism-specific name form, called a "Mechanism Name". Note that a Jeffrey> Mechanism Name is the name of an initiator or acceptor, not the name Jeffrey> of a mechanism. This section first discusses the mechanism name form Jeffrey> and then discusses what name forms are supported. Jeffrey> ---------------------------------------- I like this change. Jeffrey> At the end of section 3.1, you write "Mechanisms MAY support the Jeffrey> GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form", but not how names of this form Jeffrey> should be converted to GSS-EAP MNs. This results in ambiguities and also Jeffrey> some potential for unexpected results, including importing invalid names. Jeffrey> Some Kerberos principal names will be invalid as EAP-GSS MNs, particularly, Jeffrey> those using principal name forms which contain at-signs or realm name forms Jeffrey> contianing slashes (the latter are not likely to be a practical problem, Jeffrey> but the former might be). Others will be interpreted not as intended, or Jeffrey> may not be appropriate transformations (for example, user "instances" with Jeffrey> multiple principal name components). Jeffrey> To address this, I would recommend the following: Jeffrey> 1) Introduce an escaping syntax, such as the use of backslash as in Jeffrey> RFC1964 section 2.1.1, to allow representation of name-strings which Jeffrey> contain slash and at-sign characters. I think we discussed this between IETF 79 and IETF 80. However I'd appreciate feedback from the abfab chairs on whether we already discussed this and on polling the WG if we did not. Jeffrey> 3) Warn that direct import of Kerberos principal names may have Jeffrey> unintended effects due to differences in name structure, and that this Jeffrey> feature, if implemented, should be used carefully (possibly disabled Jeffrey> by default). Jeffrey> As an alternative to (1), you could continue to simply prohibit names Jeffrey> containing slashes and at-signs as parts of name-strings. In this case, Jeffrey> implementations which support import of GSS_KRB5_NT_KRB5_PRINCIPAL_NAME Jeffrey> names MUST verify that the imported name is valid and otherwise fail the Jeffrey> import. I've added text noting there are difference and indicating that import SHOULD fail if the name is not syntactically valid. That's a SHOULD to give mechanisms flexibility if they have some particular cleanup they want to apply to make some application work. Jeffrey> ---------------------------------------- Jeffrey> I am a bit confused by section 3.2. You seem to be saying that the Jeffrey> representation of names and components of names transported in other Jeffrey> protocols is up to the protocol in question, but that the representation Jeffrey> when a name is sent as part of this protocol is UTF-8. However, the ABNF Jeffrey> in section 3.1 permits only characters up to 0xff. Is it the intent that Jeffrey> MNs be treated as UTF-8 strings? If so, it would be better to specify the Jeffrey> MN form in two laters, first indicating that it is a UTF-8 string and then Jeffrey> using ABNF to define the permitted sequences of Unicode characters. I disagree. I find the current construction easier to follow and would rather not make this change. Jeffrey> ---------------------------------------- Jeffrey> Why define a family of mechanisms parameterized by enctype, instead of Jeffrey> defining a single mechanism, specifying a mandatory-to-implement enctype, Jeffrey> and negotiating the enctype to be used as part of context establishment? Jeffrey> This would also work around a situation with SASL mechanism naming, which Jeffrey> is that you are effectively defining an entire family of GSs-API mechs but Jeffrey> specifying SASL mechanism names for only one member of that family. This Jeffrey> means that either other enctypes cannot be used at all, or else they must Jeffrey> forever have non-friendly names encoded as per RFC5801 section 3.1. Jeffrey> Alternately, you could register a family of SASL mechansim names, of the Jeffrey> form EAP- and EAP--PLUS, where is a numeric enctype. This Jeffrey> is a bit uglier than EAP-AES128[-PLUS], but prevents future Jeffrey> interoperability problems due to SASL mechanism name mismatches and at Jeffrey> least is reversible, unlike the RFC5801 section 3.1 encoding. I think this one is informed WG consensus. One reason to do things as we have is that you run into an interop problem if policy or algorithm evolution ever disables a mandatory enctype. I think the implications have been discussed. Since the SASL registry is FCFS, I don't see a problem with having to register each enctype separately to get a friendly name. Jeffrey> ---------------------------------------- Jeffrey> In section 5.4, may the acceptor's message include a vendor subtoken? Well, if it does, the initiator is required by this spec to ignore it. Jeffrey> ---------------------------------------- Jeffrey> In section 5.5, what is a "protected result indication" ? An EAP term. Meaning you have cryptographic verification of whether the EAP method succeded or failed. Jeffrey> ---------------------------------------- Jeffrey> Is it possible for the Extensions state to involve more than one round trip? Not in this specification. You could of course add an extension advertized either in the initial or extensions state permitting that. So we can get that in the future if we need it, but I see no reason for the complexity now. Jeffrey> ---------------------------------------- Jeffrey> In section 5.6.1, initiators should be REQUIRED to send zeros for all flag Jeffrey> bits other than GSS_C_MUTUAL_FLAG, in order to guarantee that these bits Jeffrey> are available for future extension. Yep, thanks. Jeffrey> ---------------------------------------- Jeffrey> The MIC token described in section 5.6 currently protects only the Jeffrey> extension token containing it. Is there any value to protecting the entire Jeffrey> context establishment exchange? This was extensively discussed in the WG. We went through a couple of different protocols and implementations here. This is where we ended up. Yes, there is value in protecting the exchange, but the state required to do that simply with RFC 3961 operations gets messy. For many of the same reasons we made a similar change in RFC 6113, we went with what we have here. Jeffrey> ---------------------------------------- Jeffrey> In section 6, the descriptions of the derivation of the GMSK and CRK Jeffrey> seem incomplete. In particular... Jeffrey> - What happens if the EAP master session key is not large enough to Jeffrey> satisfy the requirements of the GMSK enctype's Jeffrey> random-to-key? I'm fairly sure for existing RFC 3961 enctypes and for existing key-deriving EAP methods, that never happens. For completness I've added a requirement that in this case authentication MUST fail. Jeffrey> - What is the CRK enctype? The GMSK enctype. Jeffrey> - I think you mean to indicate that the CRK is the result of applying Jeffrey> the CRK enctype's random-to-key to the output of the indicated truncate Jeffrey> call. A mere string of random bits is not an RFC3961 protocol key. Jeffrey> - The definition of L is garbled. I think you mean it is the length of Jeffrey> data required by the CRK enctype's random-to-key. I do for all of these. Fixing. Jeffrey> ---------------------------------------- Jeffrey> It is frequently important to GSS-API initiators that they are talking to Jeffrey> the expected acceptor. In the present mechanism, that requires not only Jeffrey> verifying the acceptor/NAS's identity with the EAP server (by means of EAP Jeffrey> channel bindings), but also verifying that the verified NAS identity agrees Jeffrey> with the GSS-API target name provided by the initiating application, if Jeffrey> any. This issue is discussed in detail in sections 3.4 and 3.5, but could Jeffrey> bear an additional mention in the security considerations. There's a fairly lengthy discussion of channel binding already in the security considerations section. I've added a sentence explaining why channel binding is important. Thanks. I've addressed these where I agree with you. A couple cases I disagreed or decided to leave it to the RFC-editor. _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --==-=-= Date: Wed, 18 Jul 2012 00:50:05 -0400 From: Jeffrey Hutzelman To: The IESG , secdir , draft-ietf-abfab-gss-eap.all@tools.ietf.org Cc: jhutz@cmu.edu Subject: [secdir] secdir review of draft-ietf-abfab-gss-eap-08 Message-ID: <1342587005.7190.56.camel@minbar.fac.cs.cmu.edu> MIME-Version: 1.0 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a family of GSS-API mechanisms which wrap EAP, allowing applications which use GSS-API or SASL for authentiation to take advantage of EAP mechanisms. It is a core part of the ABFAB architecture, which brings mechanism-agile federated authentication to a wide variety of applications without requiring that a user's preferred (required) authentication mechanism be supported by the services that he wishes to use. I've talked with the authors and others a lot about how ABFAB in general and this mechanism in particular are supposed to work, so I'm already comfortable with the general approach. Thus, this review will be confined to particular protocol specifics and some editorial issues. This protocol combines existing security protocols and frameworks in new ways, and thus invokes all of the security issues surrounding EAP, the GSS-API, the per-message services of RFC4121, the cryptographic framework defined in RFC3961, and the AES enctype defined in RFC3962. It also introduces new considerations related to layering, combination, and involving additional parties in the authentication process. Many of these are incorporated by reference to the relevant documents, while others are discussed directly. Overall, I think this is basically done. However, I did find a couple of things, included in my comments below, which the authors should probably address before the document is published. In particular, I believe there is a potential gap in the MN format (though this may be deliberate), an ambiguity in how import of Kerberos principal names should be handled, and a missing step in key derivation. I also make suggestions related to mechanism names and to integrity protection of the context establishment; these may be things which the authors have already considered or don't feel it is appropriate to pursue at this time. -- Jeff ======================================== Section 3.1 discusses the format of the GSS-API Mechanism Names (MNs) used by the family of mechanisms defined in this document. However, it sort of glosses over the notion that, in GSS-API jargon, "Mechanism Name" means a name of an initiator or acceptor in a mechanism-specific format, and _not_ the name of a mechanism, as one might otherwise assume. I suggest the following change to the first paragraph of this section: OLD: Before discussing how the initiator and acceptor names are validated in the AAA infrastructure, it is necessary to discuss what composes a name for an EAP GSS-API mechanism. GSS-API permits several types of generic names to be imported using GSS_Import_name(). Once a mechanism is chosen, these names are converted into a mechanism name form. This section first discusses the mechanism name form and then discusses what name forms are supported. NEW: Before discussing how the initiator and acceptor names are validated in the AAA infrastructure, it is necessary to discuss what composes a name for an EAP GSS-API mechanism. GSS-API permits several types of generic names to be imported using GSS_Import_name(). Once a mechanism is chosen, these names are converted into a mechanism-specific name form, called a "Mechanism Name". Note that a Mechanism Name is the name of an initiator or acceptor, not the name of a mechanism. This section first discusses the mechanism name form and then discusses what name forms are supported. ---------------------------------------- At the end of section 3.1, you write "Mechanisms MAY support the GSS_KRB5_NT_KRB5_PRINCIPAL_NAME name form", but not how names of this form should be converted to GSS-EAP MNs. This results in ambiguities and also some potential for unexpected results, including importing invalid names. Some Kerberos principal names will be invalid as EAP-GSS MNs, particularly, those using principal name forms which contain at-signs or realm name forms contianing slashes (the latter are not likely to be a practical problem, but the former might be). Others will be interpreted not as intended, or may not be appropriate transformations (for example, user "instances" with multiple principal name components). To address this, I would recommend the following: 1) Introduce an escaping syntax, such as the use of backslash as in RFC1964 section 2.1.1, to allow representation of name-strings which contain slash and at-sign characters. 2) Admonish implementations which support importing of names of type GSS_KRB5_NT_KRB5_PRINCIPAL_NAME that when doing so they must process the escaping described in RFC1964 section 2.1.1 and convert to a canonical form in which only slash, backslash, and at-sign are escaped. 3) Warn that direct import of Kerberos principal names may have unintended effects due to differences in name structure, and that this feature, if implemented, should be used carefully (possibly disabled by default). As an alternative to (1), you could continue to simply prohibit names containing slashes and at-signs as parts of name-strings. In this case, implementations which support import of GSS_KRB5_NT_KRB5_PRINCIPAL_NAME names MUST verify that the imported name is valid and otherwise fail the import. ---------------------------------------- I am a bit confused by section 3.2. You seem to be saying that the representation of names and components of names transported in other protocols is up to the protocol in question, but that the representation when a name is sent as part of this protocol is UTF-8. However, the ABNF in section 3.1 permits only characters up to 0xff. Is it the intent that MNs be treated as UTF-8 strings? If so, it would be better to specify the MN form in two laters, first indicating that it is a UTF-8 string and then using ABNF to define the permitted sequences of Unicode characters. ---------------------------------------- Why define a family of mechanisms parameterized by enctype, instead of defining a single mechanism, specifying a mandatory-to-implement enctype, and negotiating the enctype to be used as part of context establishment? This would also work around a situation with SASL mechanism naming, which is that you are effectively defining an entire family of GSs-API mechs but specifying SASL mechanism names for only one member of that family. This means that either other enctypes cannot be used at all, or else they must forever have non-friendly names encoded as per RFC5801 section 3.1. Alternately, you could register a family of SASL mechansim names, of the form EAP- and EAP--PLUS, where is a numeric enctype. This is a bit uglier than EAP-AES128[-PLUS], but prevents future interoperability problems due to SASL mechanism name mismatches and at least is reversible, unlike the RFC5801 section 3.1 encoding. ---------------------------------------- In section 5.4, may the acceptor's message include a vendor subtoken? ---------------------------------------- In section 5.5, what is a "protected result indication" ? ---------------------------------------- Is it possible for the Extensions state to involve more than one round trip? ---------------------------------------- In section 5.6.1, initiators should be REQUIRED to send zeros for all flag bits other than GSS_C_MUTUAL_FLAG, in order to guarantee that these bits are available for future extension. ---------------------------------------- The MIC token described in section 5.6 currently protects only the extension token containing it. Is there any value to protecting the entire context establishment exchange? ---------------------------------------- In section 6, the descriptions of the derivation of the GMSK and CRK seem incomplete. In particular... - What happens if the EAP master session key is not large enough to satisfy the requirements of the GMSK enctype's random-to-key? - What is the CRK enctype? - I think you mean to indicate that the CRK is the result of applying the CRK enctype's random-to-key to the output of the indicated truncate call. A mere string of random bits is not an RFC3961 protocol key. - The definition of L is garbled. I think you mean it is the length of data required by the CRK enctype's random-to-key. ---------------------------------------- It is frequently important to GSS-API initiators that they are talking to the expected acceptor. In the present mechanism, that requires not only verifying the acceptor/NAS's identity with the EAP server (by means of EAP channel bindings), but also verifying that the verified NAS identity agrees with the GSS-API target name provided by the initiating application, if any. This issue is discussed in detail in sections 3.4 and 3.5, but could bear an additional mention in the security considerations. ======================================== I also found a number of editorial issues: Abstract: "... when using the EAP mechanism" should probably be "when using the Extensible Authentication Protocol (EAP)", at which point the second expansion of EAP could be removed. Section 1, graf 6 (page 5): s/prospective/perspective/ Section 1.3, last graf (page 7): The phrase "security association protocols" is used twice, where I believe "secure association protocols" is intended. Section 3.1 ABNF: This attempts to define name-char to match any character except the slash (/) and at-sign (@), which are used to separate name components. However, it incorrectly prohibits uppercase G (decimal 71, hex 0x47) instead of slash (decimal 47, hex 0x2f). Section 3.1, graf 3 (page 10, after ABNF): In "specifications of this mechanism MUST NOT prepare the user-or-service according to these rules", I think you mean "implementations", not "specifications". Section 3.1, bottom of page 10: s/proceeding/preceeding/ Section 3.3, last graf: "canonicalizing it to a mechanism" should be "canonicalizing it to a mechanism name". Section 3.5, graf 4 (bottom of page 13): In "The EAP server MUST assure", s/assure/ensure/. In section 5, the table describing the format of an innerToken shows the first subtoken body as occupying octets 10..10+n, which is a total of n+1 bytes. It should be 10+n-1, and the second subtoken type should be at octets 10+n..10+n+3. Sections 5.5.1, 5.5.2; the subtoken types are missing zeros. Section 5.6; this state is variously called Extension (singular) or Extensions (plural). Section 7.2: The GSS mech parameters registry was indeed created by RFC6542. Also, it might be clearer if the last two entries in the table explicitly referred to "this RFC", so someone doesn't think you mean RFC4121 section 5. Section 7.3: The table should be sorted by type, not defining section. Section 7.4: draft-ietf-radext-radius-extensions is up to -06, and the relevant section is now 10.3, not 9.3. Section 7.5: s/EAP-ES128/EAP-AES128/ Section 10.1: Do you need a normative reference to RFC3962? _______________________________________________ secdir mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --==-=-=-- --=-=-=-- From hartmans@mit.edu Wed Jul 18 10:05:39 2012 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 EB25E21F8739; Wed, 18 Jul 2012 10:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 IoqtIWvzcfz4; Wed, 18 Jul 2012 10:05:39 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 75CD021F8733; Wed, 18 Jul 2012 10:05:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5451C203BA; Wed, 18 Jul 2012 13:06:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1EA5A41F0; Wed, 18 Jul 2012 13:06:05 -0400 (EDT) From: Sam Hartman To: Jeffrey Hutzelman References: <1342587005.7190.56.camel@minbar.fac.cs.cmu.edu> <1342629922.17068.36.camel@destiny.pc.cs.cmu.edu> Date: Wed, 18 Jul 2012 13:06:05 -0400 In-Reply-To: <1342629922.17068.36.camel@destiny.pc.cs.cmu.edu> (Jeffrey Hutzelman's message of "Wed, 18 Jul 2012 12:45:22 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-abfab-gss-eap.all@tools.ietf.org, abfab@ietf.org, Sam Hartman , The IESG , secdir Subject: Re: [abfab] [secdir] secdir review of draft-ietf-abfab-gss-eap-08 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 17:05:40 -0000 >>>>> "Jeffrey" == Jeffrey Hutzelman writes: Yes. >> Jeffrey> Why define a family of mechanisms parameterized by enctype, instead of Jeffrey> defining a single mechanism, specifying a mandatory-to-implement enctype, Jeffrey> and negotiating the enctype to be used as part of context establishment? Jeffrey> This would also work around a situation with SASL mechanism naming, which Jeffrey> is that you are effectively defining an entire family of GSs-API mechs but Jeffrey> specifying SASL mechanism names for only one member of that family. This Jeffrey> means that either other enctypes cannot be used at all, or else they must Jeffrey> forever have non-friendly names encoded as per RFC5801 section 3.1. >> Jeffrey> Alternately, you could register a family of SASL mechansim names, of the Jeffrey> form EAP- and EAP--PLUS, where is a numeric enctype. This Jeffrey> is a bit uglier than EAP-AES128[-PLUS], but prevents future Jeffrey> interoperability problems due to SASL mechanism name mismatches and at Jeffrey> least is reversible, unlike the RFC5801 section 3.1 encoding. >> >> I think this one is informed WG consensus. One reason to do things as we >> have is that you run into an interop problem if policy or algorithm >> evolution ever disables a mandatory enctype. >> I think the implications have been discussed. Jeffrey> OK, fair enough. >> Since the SASL registry is FCFS, I don't see a problem with having to >> register each enctype separately to get a friendly name. Jeffrey> The only problem is that if someone starts using that enctype with this Jeffrey> mechanism before the friendly name is registered, they end up using the Jeffrey> unfriendly name, and then you eventually have a false interop problem, Jeffrey> where two implementations both support that enctype but don't know it. Jeffrey> Avoiding this is why we wanted friendly names registered when the Jeffrey> mechanism is defined, but RFC5801 doesn't really contemplate mechanism Jeffrey> families like this one. My assumption is that a implementation will only include things for which it has a friendly name in indicate_mechs output. From hartmans@painless-security.com Wed Jul 18 13:18:23 2012 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 BDA6011E814A for ; Wed, 18 Jul 2012 13:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 FXdxa9VJgSd2 for ; Wed, 18 Jul 2012 13:18:23 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2A35521F8644 for ; Wed, 18 Jul 2012 13:18:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 43D4F203BA for ; Wed, 18 Jul 2012 16:19:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E9E1641F0; Wed, 18 Jul 2012 16:18:44 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Wed, 18 Jul 2012 16:18:44 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] escaping in ABFAB names X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 20:18:23 -0000 Hi. One of the comments from the secdir review is that we have no way to escape a slash or @ inside an ABFAB name. For reference, Kerberos does have such a mechanism. I think we at least discussed this in a meeting. It's much easier to add an escaping mechanism now if we're going to need it. I can't think of a reason you'd need such an escaping mechanism in practice except: 1) To represent Kerberos enterprise names in ABFAB. I cannot think of why you'd need to do that. 2) To represent pathalogical hostnames or Kerberos names in ABFAB. I cannot think of why you'd need to do that. I think that when this was discussed in a meeting people expressed a preference for simplicity over escaping. Personally I'm a bit nervous that we may regret this decision no matter which way we decide. --Sam From ietf@augustcellars.com Wed Jul 18 16:19:41 2012 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 907AC11E80DF for ; Wed, 18 Jul 2012 16:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 dhd8CM7BqgRj for ; Wed, 18 Jul 2012 16:19:40 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id DB66511E80CE for ; Wed, 18 Jul 2012 16:19:40 -0700 (PDT) Received: from Tobias (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 6126338F30; Wed, 18 Jul 2012 16:20:32 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Wed, 18 Jul 2012 16:19:06 -0700 Message-ID: <02df01cd653b$bad4da80$307e8f80$@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: AQFXyWwDOD1T6vFqkLx+z7UsMVcZYpga46Ww Content-Language: en-us Subject: Re: [abfab] escaping in ABFAB names X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 23:19:41 -0000 The other place that you might need escaping would be in the service specifics. A somewhat contrived example Ietf//pretend=jimsch@nwlink.com@augustcellars.com I don't know if this is even reasonable, but I can see potentially wanting the characters there. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, July 18, 2012 1:19 PM > To: abfab@ietf.org > Subject: [abfab] escaping in ABFAB names > > > Hi. One of the comments from the secdir review is that we have no way to > escape a slash or @ inside an ABFAB name. For reference, Kerberos does > have such a mechanism. > > I think we at least discussed this in a meeting. > > It's much easier to add an escaping mechanism now if we're going to need it. > > I can't think of a reason you'd need such an escaping mechanism in practice > except: > > 1) To represent Kerberos enterprise names in ABFAB. I cannot think of why > you'd need to do that. > > 2) To represent pathalogical hostnames or Kerberos names in ABFAB. I > cannot think of why you'd need to do that. > > I think that when this was discussed in a meeting people expressed a > preference for simplicity over escaping. Personally I'm a bit nervous that we > may regret this decision no matter which way we decide. > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From kwiereng@cisco.com Thu Jul 19 00:18:19 2012 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 17A2121F8673 for ; Thu, 19 Jul 2012 00:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQF1lWmKVUq1 for ; Thu, 19 Jul 2012 00:18:18 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 46E5321F861C for ; Thu, 19 Jul 2012 00:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=1396; q=dns/txt; s=iport; t=1342682351; x=1343891951; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KueXYAxhyhdveNwxoDGYDDCC4OkDuTpX85lvRUG0W84=; b=LadcXkjo+D04wIzngraDSaXpm1hDWucJIta92CnfPc2V+RFUTdw9uleV wSh2wZR6X5ceKKRn2qbcbahwi0M7NkGAW1kZUVOWUkrAy8v2eLZ7avC8M mC0eBx34E1/jmcxX7iAnQJbk0mLm3lShF95i3x5lATgj7yf+D8bgMiOc2 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMuzB1CtJXG8/2dsb2JhbABFuU2BB4IgAQEBAwEBAQEPAVsLEAIBCEYnCyUCBA4FIodlBgueHKAEBItAhjBgA5VEjiOBZoJf X-IronPort-AV: E=Sophos;i="4.77,614,1336348800"; d="scan'208";a="103340961" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 19 Jul 2012 07:19:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6J7JAxj032752 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 07:19:10 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.251]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 02:19:10 -0500 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [abfab] escaping in ABFAB names Thread-Index: AQHNZSKd9v2AJwssV02Q+jMrYbaWSJcwhyCA Date: Thu, 19 Jul 2012 07:19:09 +0000 Message-ID: <0CA1EC99-8C39-4DDB-BA8E-583C634371FF@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.7.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--39.460300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <3B06E20A26652647AF690D26787DCEEC@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [abfab] escaping in ABFAB names 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, 19 Jul 2012 07:18:19 -0000 On Jul 18, 2012, at 10:18 PM, Sam Hartman wrote: Hi Sam, I can not recall having discussed this explicitly in a meeting, but that do= es't mean it didn't happen, it may be that I am just getting old ;-) Is there a compelling reason NOT to add an escaping mechanism apart from si= mplicity? It does not seem to add that much complexity=85. Klaas >=20 > Hi. One of the comments from the secdir review is that we have no way > to escape a slash or @ inside an ABFAB name. For reference, Kerberos > does have such a mechanism. >=20 > I think we at least discussed this in a meeting. >=20 > It's much easier to add an escaping mechanism now if we're going to need > it. >=20 > I can't think of a reason you'd need such an escaping mechanism in > practice except: >=20 > 1) To represent Kerberos enterprise names in ABFAB. I cannot think of > why you'd need to do that. >=20 > 2) To represent pathalogical hostnames or Kerberos names in ABFAB. I > cannot think of why you'd need to do that. >=20 > I think that when this was discussed in a meeting people expressed a > preference for simplicity over escaping. Personally I'm a bit nervous > that we may regret this decision no matter which way we decide. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu Jul 19 03:09:21 2012 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 ACA5A21F86D9 for ; Thu, 19 Jul 2012 03:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 uDtZ4Jygw3Pf for ; Thu, 19 Jul 2012 03:09:20 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id BD44221F8673 for ; Thu, 19 Jul 2012 03:09:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 57F2E203BA; Thu, 19 Jul 2012 06:10:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2A83E41F0; Thu, 19 Jul 2012 06:09:46 -0400 (EDT) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: <0CA1EC99-8C39-4DDB-BA8E-583C634371FF@cisco.com> Date: Thu, 19 Jul 2012 06:09:46 -0400 In-Reply-To: <0CA1EC99-8C39-4DDB-BA8E-583C634371FF@cisco.com> (Klaas Wierenga's message of "Thu, 19 Jul 2012 07:19:09 +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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [abfab] escaping in ABFAB names 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, 19 Jul 2012 10:09:21 -0000 >>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: Klaas> On Jul 18, 2012, at 10:18 PM, Sam Hartman wrote: Klaas> Hi Sam, Klaas> I can not recall having discussed this explicitly in a Klaas> meeting, but that does't mean it didn't happen, it may be Klaas> that I am just getting old ;-) I'm thinking that if it were discussed it was a couple of comments at the mic. So, it was not discussed as much as I thought it had been in my initial response to the secdir comments. my preference is to treat this as something we did not seriously consider and should seriously consider prior to approval. Klaas> Is there a compelling reason NOT to add an escaping mechanism apart from simplicity? It does not seem to add that much complexity…. Klaas> Klaas I can't think of one. I'll note that adopting the krb5 escaping mechanism will be kind of convenient for the Moonshot implementation as we seem to implement it already and it's more convenient than removing the code. If we are going to do an escaping mechanism I'd appreciate it if someone could help me with the ABNF. --Sam From stephen.farrell@cs.tcd.ie Thu Jul 19 03:56:27 2012 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 B2CB121F8683; Thu, 19 Jul 2012 03:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 4yOYI58lCSBg; Thu, 19 Jul 2012 03:56:27 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E40B521F85E3; Thu, 19 Jul 2012 03:56:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 715B4153663; Thu, 19 Jul 2012 11:57:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1342695438; bh=x3Edd7DmQxcE47 grygw+wUXF+aWkYdbPNwlOCDDhPrw=; b=kAktqkvOMcdKna49invQRiBHoN5A2e rh4Op1THOZtDsYXouf3oae0gpKmgr3YuuQYZ8FXy23bdp9I+DRYivewaxNQkWLRK ilzZfHGNP4adzpzBiMZQOGu9tYNOYJosuwKqmzcCANzJfTEEvQ139Mu2tFJ8NvrP NlankxrP3GQbzjkEFdglnRpWxhy2NkFRGDP7ASb5nWkFL6BuejmcZxQ77OKFqyaC QaqhvtPTG9XIf9lzLQbnYok4as5DHtxGxggxiGyqjARY680y/o0tBnw02+ayAzfn /VBR3HYinc5FsENizx7A3MdreDtzwNdqCfEL6HgIAURPjn3nBGrbzoew== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 3xH0ujybs+ir; Thu, 19 Jul 2012 11:57:18 +0100 (IST) Received: from [10.87.48.11] (unknown [86.45.48.236]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9E851153661; Thu, 19 Jul 2012 11:57:16 +0100 (IST) Message-ID: <5007E80C.5070404@cs.tcd.ie> Date: Thu, 19 Jul 2012 11:57:16 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Sam Hartman References: <20120626165832.6142.66386.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org, ietf@ietf.org Subject: Re: [abfab] Last Call: (A GSS-API Mechanism for the Extensible Authentication Protocol) to Proposed Standard 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, 19 Jul 2012 10:56:27 -0000 Sorry, I should've asked this before but I'm sometimes dumb:-) If I put in an RFC editor note adding a normative reference to the new EAP applicability statement [1] would that sort this out and not cause any problems for anyone? S. [1] http://tools.ietf.org/html/draft-winter-abfab-eapapplicability On 06/26/2012 08:14 PM, Sam Hartman wrote: > > EAP (RFC 3748) has a applicability statement scoped very strictly to > network access. > This document provides a mechanism that falls well outside that > applicability statement and permits the use of EAP for general > application authentication. > > When ABFAB was chartered, there was a charter item to update the EAP > applicability statement. I think A number of people in the room at the > BOF, including myself, would have objected to the work being chartered > had that charter item not been present. > > I think that work is important because I believe there are a number of > important concerns that apply to the use of EAP for authentication > beyond network access that need to be documented. > > Unfortunately, the technical specification has gotten ahead of the > applicability statement update. > I'm OK with that provided that we're still firmly committed to an > applicability statement update. As part of approving this document now, > I want to confirm that we have consensus at least within the ABFAB > working group and the IESG to do that update. > If there is any doubt I'd far prefer that this document be held until > the applicability statement catches up. > > --Sam > From hartmans@mit.edu Thu Jul 19 04:18:39 2012 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 AA33321F8595; Thu, 19 Jul 2012 04:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.887 X-Spam-Level: X-Spam-Status: No, score=-102.887 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 bqmP0YIiZZFb; Thu, 19 Jul 2012 04:18:39 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34E21F8594; Thu, 19 Jul 2012 04:18:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 31DB3204BA; Thu, 19 Jul 2012 07:19:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F099441F0; Thu, 19 Jul 2012 07:19:04 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <20120626165832.6142.66386.idtracker@ietfa.amsl.com> <5007E80C.5070404@cs.tcd.ie> Date: Thu, 19 Jul 2012 07:19:04 -0400 In-Reply-To: <5007E80C.5070404@cs.tcd.ie> (Stephen Farrell's message of "Thu, 19 Jul 2012 11:57:16 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, Sam Hartman , ietf@ietf.org Subject: Re: [abfab] Last Call: (A GSS-API Mechanism for the Extensible Authentication Protocol) to Proposed Standard 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, 19 Jul 2012 11:18:39 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> Sorry, I should've asked this before but I'm sometimes dumb:-) Stephen> If I put in an RFC editor note adding a normative reference Stephen> to the new EAP applicability statement [1] would that sort Stephen> this out and not cause any problems for anyone? I don't object to that, but it does hold up the doc. I'm happy letting this doc go forward now so long as we're all on the same page on the applicability stament. I realize we run the risk that somehow the applicability effort derails. Personally, I'm willing to take that risk, so long as we believe today we do intend to publish the applicability statement. If someone on the IESG or in the community wants that normative reference, I support adding it. I'm just not asking for it myself. From kwiereng@cisco.com Thu Jul 19 05:22:38 2012 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 0D8C121F85F8 for ; Thu, 19 Jul 2012 05:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dOW0jVhtYcRS for ; Thu, 19 Jul 2012 05:22:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CBB6821F85F2 for ; Thu, 19 Jul 2012 05:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=1322; q=dns/txt; s=iport; t=1342700610; x=1343910210; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WIgEs3geG/xC6JolD4JbGA9QWsvRKRRP38uQJt4XjyE=; b=Ri4Po+QqR1Q5zi9DMLEhZHxCCxfoeEx91Z53lUVhU/qDCAUgt7qvruzJ m7wuGzXEnqM9zMYYzKdTL2i6R+w4J/Y5di/a7dTvM79r42h8bYFz1mf3z GP90QF+rbFrlIE55I0BUir2Dx58WEhvS98/2Fs1uj5zqeXdRILefBKrRM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEf7B1CtJXG9/2dsb2JhbABFuUCBB4IgAQEBAwESAWYFCwIBCBguMiUCBA4FIodlBp4aoAiLTIYwYAOIGI0sjiOBZoJf X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103393606" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jul 2012 12:23:29 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6JCNTVl009257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 12:23:29 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.251]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0298.004; Thu, 19 Jul 2012 07:23:29 -0500 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [abfab] escaping in ABFAB names Thread-Index: AQHNZalNteC9NB8Cvkm9BGHjLlHfJg== Date: Thu, 19 Jul 2012 12:23:28 +0000 Message-ID: <91CEE264-2E6D-43BD-B4F6-D59AF7475464@cisco.com> References: <0CA1EC99-8C39-4DDB-BA8E-583C634371FF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.7.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--44.863100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7D67542EA9AFAC47A15713C45C40CBD7@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [abfab] escaping in ABFAB names 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, 19 Jul 2012 12:22:38 -0000 Hi, On Jul 19, 2012, at 12:09 PM, Sam Hartman wrote: >>>>>> "Klaas" =3D=3D Klaas Wierenga (kwiereng) writes= : >=20 > Klaas> On Jul 18, 2012, at 10:18 PM, Sam Hartman wrote: >=20 > Klaas> Hi Sam, >=20 > Klaas> I can not recall having discussed this explicitly in a > Klaas> meeting, but that does't mean it didn't happen, it may be > Klaas> that I am just getting old ;-) >=20 > I'm thinking that if it were discussed it was a couple of comments at > the mic. > So, it was not discussed as much as I thought it had been in my initial > response to the secdir comments. >=20 > my preference is to treat this as something we did not seriously > consider and should seriously consider prior to approval. I agree > Klaas> Is there a compelling reason NOT to add an escaping mechanism a= part from simplicity? It does not seem to add that much complexity.. >=20 > Klaas> Klaas >=20 > I can't think of one. >=20 > I'll note that adopting the krb5 escaping mechanism will be kind of > convenient for the Moonshot implementation as we seem to implement it > already and it's more convenient than removing the code. >=20 > If we are going to do an escaping mechanism I'd appreciate it if someone > could help me with the ABNF. sure Klaas= From klaas@cisco.com Thu Jul 19 06:46:06 2012 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 0DC1321F879C for ; Thu, 19 Jul 2012 06:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnoCj2u1KWWo for ; Thu, 19 Jul 2012 06:46:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2A321F8769 for ; Thu, 19 Jul 2012 06:46:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=423; q=dns/txt; s=iport; t=1342705618; x=1343915218; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=UDj4d++ZgjG5lDm5HjejV1ZDeqUmLtRQ+Wtv80vqiF8=; b=P16eSgtgirEuz+/h/vfIcxnUYteBskIz92SeX7If2QDqtBFycG+g/c44 76T9yYncLaK/FX21HdPRY4EhdKewQPDGs3GWwlLJa2e6w85NlAqpx2TOE HDRQj9xkB28RA/0ldPqHcm18fsQqaopIc24FwXVEYCTdVftMdnGgn1cAy 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmUJAE0OCFCtJXHA/2dsb2JhbABFhDC1EYEHgjkBJ4F9NYdrC5x2gSigA4tMhjBgA5VEgRONEIFmgmE X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103209782" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 19 Jul 2012 13:46:52 +0000 Received: from rtp-kwiereng-8714.cisco.com (rtp-kwiereng-8714.cisco.com [10.116.7.37]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q6JDkpGr016426 for ; Thu, 19 Jul 2012 13:46:51 GMT From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Jul 2012 15:46:50 +0200 Message-Id: <81761770-8B74-47E1-A587-66BF36AE0401@cisco.com> To: "" Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Subject: [abfab] WGLC on draft-ietf-abfab-gss-eap-naming-03 (ending August 3d 2012) 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, 19 Jul 2012 13:46:06 -0000 Hi, The chairs believe that draft-ietf-abfab-gss-eap-naming-03 is ready for last call and that any remaining issues can be addressed during the WGLC = (including those previously voiced by Jim Schaad). This is then a WGLC on draft-ietf-abfab-gss-eap-naming-03 (http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming-03). Please provide comments and/or feedback by August 3d 2012. Cheers, Klaas & Leif= From stephen.farrell@cs.tcd.ie Fri Jul 20 06:47:25 2012 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 6BDD621F85F6 for ; Fri, 20 Jul 2012 06:47:25 -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 f0mTHnXKmXSB for ; Fri, 20 Jul 2012 06:47:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 979F321F8610 for ; Fri, 20 Jul 2012 06:47:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 37A281714E4 for ; Fri, 20 Jul 2012 14:48:20 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1342792099; bh=BncPxCeRPW6/BbtZxNYoqKwm UHVGQ+T/5MqLYWumSzw=; b=Ui224sgvFegOViq16wMpjDEdmTLc0VKxj/hX0hs7 hi2S4hlN8phlG0quqIR/u8CKScFaz5r+1pbVj9E8iisZCD1sa+EkWpKsA0aLb5xI CWE+miX67kgmTQHsRQc0nmwEY0Vz/WVP5Z/5N1r14wUIKvxXWPWkxXlRBzvP46/z kJz9rUUhwIwz3hcrX7RIfIgPstFZWB61HReyTvwXCPQjHgpAyBbJQlYw42ZTmXH5 MwVC3QpopCxNSuZHkZdpE0jTAVU0bxIkO7gfAwRiUJjavo8G0mXKhnR1whTXMysb M+IY8WvT0Bo1hulWwdwEJrASY/Vwp2NBmaqpF9A5ftbbug== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id en4d33DwD6hf for ; Fri, 20 Jul 2012 14:48:19 +0100 (IST) Received: from [IPv6:2001:770:10:203:e08f:9c9a:c76d:2d13] (unknown [IPv6:2001:770:10:203:e08f:9c9a:c76d:2d13]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 4FB5F171475 for ; Fri, 20 Jul 2012 14:48:17 +0100 (IST) Message-ID: <500961A2.4060104@cs.tcd.ie> Date: Fri, 20 Jul 2012 14:48:18 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: abfab@ietf.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] EAP applicability statement comment X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 13:47:25 -0000 Hi all, During IESG processing of draft-ietf-abfab-gss-eap we agreed to add a reference to the EAP applicability statement so that when gss-eap becomes an RFC, its clear that we're ok. (The gss-eap draft was approved btw, but we need to get that escaping thing and a few nits sorted before you'll see the announcement.) I asked the IESG if adding that reference and having abfab process the EAP applicability statement was ok and folks were ok with that. I also got the comment below from Bernard Aboba. That looks like it'd be useful to consider as you process the EAP applicability statement which is on your agenda for Vancouver. It doesn't seem to me like this'd raise any nasty problems for abfab, but then what do I know:-) Cheers, S. "There is another issue here, which is the guidance in RFC 4962, in particularly the requirement for a mandatory-to-implement mechanism. In enterprise WLAN network access, where enterprise users are typically provided with access software by their employers -- there is almost always a secure method satisfying the RFC 4017 requirements that is required for access to a given enterprise. Similarly, carrier networks that have deployed EAP (e.g. WiMAX) have also specified a mandatory-to-implement method (e.g., EAP-TLS). However, in other deployment scenarios, such as consumer uses where no AAA server is present and there are typically no EAP methods supported on the device, there is no mechanism for meeting the RFC 4962 requirements. In those scenarios, EAP is not a good fit. The changes to the EAP applicability statement do not obsolve authors advocating new uses of EAP from demonstrating adherence to the RFC 4962 requirements." From hartmans@painless-security.com Fri Jul 20 07:23:18 2012 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 AA11E21F850B for ; Fri, 20 Jul 2012 07:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.232 X-Spam-Level: X-Spam-Status: No, score=-2.232 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 lfWZYtuZmmlr for ; Fri, 20 Jul 2012 07:23:18 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0F46E21F84F5 for ; Fri, 20 Jul 2012 07:23:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E3D72203BA; Fri, 20 Jul 2012 10:24:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2906741F0; Fri, 20 Jul 2012 10:23:45 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <500961A2.4060104@cs.tcd.ie> Date: Fri, 20 Jul 2012 10:23:45 -0400 In-Reply-To: <500961A2.4060104@cs.tcd.ie> (Stephen Farrell's message of "Fri, 20 Jul 2012 14:48:18 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP applicability statement comment X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 14:23:18 -0000 So, I'm really hoping that from a process standpoint we can not look to hard at this. I absolutely agree with Bernard that we need to implement things that meet the 4962 requirements. The implementation I have the most experience with (Moonshot) does implement RFC 4962. We use radsec as the key confidentiality method between AAA server and client. We basically require EAP-TTLS because that's all we're currently implementing channel binding for. The problem is that if we get too picky about IETF process, none of this works. In terms of standardized EAP methods with security, we have EAP-GPSK and EAP-TLS. EAP-TLS doesn't support channel binding and adding it would be difficult. EAP-GPSK probably is something we could use. However, it's the wrong fit for a lot of deployments. RADSEC is a good fit for what we want. Except it's not standards track. Long term, TEAP will be a standards-track method we can move to. Long term, either diameter will catch on, or we'll decide that RADSEC or some other form of security is appropriate for a normative reference from a standards-track spec. I don't think publishing ABFAB is experimental is the right approach. I don't think blocking ABFAB until EAP and RADEXT get done coming up with standards-track mechanisms is the right fix. So, I'm left concluding that being a bit liberal in our process and doing something reasonable with the implementations is the right approach here. So, I think that the right fix for the applicability statement is simply to refer to section 1.2 of RFC 4962 and note that is mandatory-to-implement. From leifj@nordu.net Thu Jul 19 05:35:07 2012 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 D7AB121F8724; Thu, 19 Jul 2012 05:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 O0dOnVVmrSkx; Thu, 19 Jul 2012 05:35:07 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4FA21F8720; Thu, 19 Jul 2012 05:35:06 -0700 (PDT) Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6JCZqnJ009192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 14:35:55 +0200 (CEST) VBR-Info: md=nordu.net; mc=all; mv=dwl.spamhaus.org,swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordu.net; s=default; t=1342701356; bh=W94YJXv/AuY36AQ9QQ4EQCUCaZZ3qQTlVMqJu53+Zr8=; h=From:Subject:Content-Transfer-Encoding:Content-Type:Message-Id: Date:To:Mime-Version; b=E+Jgjn2Ba8QdKQUUjma/G2Wj6LRhgPQAucHGhthLTHhBgdne0GkRitupu6Bfai7ID LIyA6QjRmg3D/2V4+D9205DUAhBEg6ateenOqsq2LxyP/2jzwqMdh8Rl4q7Qyiz0Xl 16NK0G/aqYCQ+VnfewsELuojTtng6coqXI39kXYM= X-Footer: bm9yZHUubmV0 Received: from [2.66.193.56] ([2.66.193.56]) by kerio.nordu.net; Thu, 19 Jul 2012 14:35:51 +0200 From: "Leif Johansson" References: <20120626165832.6142.66386.idtracker@ietfa.amsl.com> <5007E80C.5070404@cs.tcd.ie> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: <65C49A3B-434A-4782-AFB9-FD940E3B12EA@nordu.net> Date: Thu, 19 Jul 2012 14:35:47 +0200 To: Sam Hartman Mime-Version: 1.0 (1.0) X-Mailman-Approved-At: Fri, 20 Jul 2012 09:17:35 -0700 Cc: "abfab@ietf.org" , Sam Hartman , "ietf@ietf.org" Subject: Re: [abfab] Last Call: (A GSS-API.Mechanism for the Extensible Authentication Protocol) to.Proposed Standard 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, 19 Jul 2012 12:41:23 -0000 fyi the applicability stmt version 00 was submitted by joe the other day. 19 jul 2012 kl. 13:19 skrev "Sam Hartman" : >>>>>> "Stephen" == Stephen Farrell writes: > > Stephen> Sorry, I should've asked this before but I'm sometimes dumb:-) > > Stephen> If I put in an RFC editor note adding a normative reference > Stephen> to the new EAP applicability statement [1] would that sort > Stephen> this out and not cause any problems for anyone? > > I don't object to that, but it does hold up the doc. I'm happy letting > this doc go forward now so long as we're all on the same page on the > applicability stament. I realize we run the risk that somehow the > applicability effort derails. Personally, I'm willing to take that > risk, so long as we believe today we do intend to publish the > applicability statement. > > If someone on the IESG or in the community wants that normative > reference, I support adding it. I'm just not asking for it myself. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@nordu.net Fri Jul 20 08:37:56 2012 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 4395121F858A for ; Fri, 20 Jul 2012 08:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 Q-wFaBqV0fLc for ; Fri, 20 Jul 2012 08:37:55 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2F621F857D for ; Fri, 20 Jul 2012 08:37:54 -0700 (PDT) Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6KFcig7011756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2012 17:38:47 +0200 (CEST) VBR-Info: md=nordu.net; mc=all; mv=dwl.spamhaus.org,swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordu.net; s=default; t=1342798728; bh=yy1UHh1pHmp+eUVwS8uOdJwh+ZfnPXIsrxlZmknZ9iQ=; h=From:Subject:Content-Transfer-Encoding:Content-Type:Message-Id: Date:To:Mime-Version; b=GlOy8626Ptug5sxxRk3mWqJRVcmDV8BOhYZEJcj67QLSqM4FbKKfTk0Cp/luqapyO CGJxWkakBarbGjI8eVvgFvw8ZGnR+3zXhfVU7KLP2jH3lkzZjRAOS/DlrH8nn9uyxM nJjZ6kErnqePSpqygMapDRHpyFV34hb0nFJCGR/o= X-Footer: bm9yZHUubmV0 Received: from [2.68.154.170] ([2.68.154.170]) by kerio.nordu.net; Fri, 20 Jul 2012 17:38:42 +0200 From: "Leif Johansson" References: <500961A2.4060104@cs.tcd.ie> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: Date: Fri, 20 Jul 2012 17:38:41 +0200 To: Sam Hartman Mime-Version: 1.0 (1.0) X-Mailman-Approved-At: Fri, 20 Jul 2012 09:17:36 -0700 Cc: "abfab@ietf.org" Subject: Re: [abfab] EAP applicability statement comment X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 15:37:56 -0000 20 jul 2012 kl. 16:24 skrev "Sam Hartman" : > So, I'm really hoping that from a process standpoint we can not look to > hard at this. I absolutely agree with Bernard that we need to implement > things that meet the 4962 requirements. > > The implementation I have the most experience with (Moonshot) does > implement RFC 4962. We use radsec as the key confidentiality method > between AAA server and client. > > We basically require EAP-TTLS because that's all we're currently > implementing channel binding for. > > The problem is that if we get too picky about IETF process, none of this > works. In terms of standardized EAP methods with security, we have > EAP-GPSK and EAP-TLS. > EAP-TLS doesn't support channel binding and adding it would be > difficult. > EAP-GPSK probably is something we could use. However, it's the wrong fit > for a lot of deployments. > > RADSEC is a good fit for what we want. Except it's not standards track. > > Long term, TEAP will be a standards-track method we can move to. > Long term, either diameter will catch on, or we'll decide that RADSEC > or some other form of security is appropriate for a normative reference > from a standards-track spec. > > I don't think publishing ABFAB is experimental is the right approach. > I don't think blocking ABFAB until EAP and RADEXT get done coming up > with standards-track mechanisms is the right fix. > > So, I'm left concluding that being a bit liberal in our process and > doing something reasonable with the implementations is the right > approach here. > > So, I think that the right fix for the applicability statement is simply > to refer to section 1.2 of RFC 4962 and note that is > mandatory-to-implement. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@nordu.net Fri Jul 20 08:40:53 2012 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 B472521F855D for ; Fri, 20 Jul 2012 08:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.681 X-Spam-Level: X-Spam-Status: No, score=-0.681 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] 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 1JB+LiPdOPGs for ; Fri, 20 Jul 2012 08:40:53 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id BAE4F21F8559 for ; Fri, 20 Jul 2012 08:40:52 -0700 (PDT) Received: from kerio.nordu.net (kerio.nordu.net [109.105.110.42]) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6KFfi5S014399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jul 2012 17:41:46 +0200 (CEST) VBR-Info: md=nordu.net; mc=all; mv=dwl.spamhaus.org,swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordu.net; s=default; t=1342798907; bh=3mCdzmUiUuU4XJb1RwQYd5PF96v6eC+6dMT7CF7J+yI=; h=From:Subject:Content-Transfer-Encoding:Content-Type:Message-Id: Date:To:Mime-Version; b=fyDU4AvoBiT9MgrXWLwZUmUWp/cP5XpGXX49oZ2p8y/lgazeHoLvmLoTnSbOHKads KNdi2PLNRATExOdtEQUrT/fivNh3Fm2jVQCuKaY5V9YfBReoAY5qmzJ+mDDy9Fn2BM eIb9YqcZPUVa3bc6EhaUJRUSE/0hbduF3APdQt4s= X-Footer: bm9yZHUubmV0 Received: from [2.68.154.170] ([2.68.154.170]) by kerio.nordu.net; Fri, 20 Jul 2012 17:41:43 +0200 From: "Leif Johansson" References: <500961A2.4060104@cs.tcd.ie> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: Date: Fri, 20 Jul 2012 17:41:33 +0200 To: Sam Hartman Mime-Version: 1.0 (1.0) X-Mailman-Approved-At: Fri, 20 Jul 2012 09:17:36 -0700 Cc: "abfab@ietf.org" Subject: Re: [abfab] EAP applicability statement comment X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 15:40:53 -0000 20 jul 2012 kl. 16:24 skrev "Sam Hartman" : > So, I'm really hoping that from a process standpoint we can not look to > hard at this. I absolutely agree with Bernard that we need to implement > things that meet the 4962 requirements. > > The implementation I have the most experience with (Moonshot) does > implement RFC 4962. We use radsec as the key confidentiality method > between AAA server and client. > > We basically require EAP-TTLS because that's all we're currently > implementing channel binding for. > > The problem is that if we get too picky about IETF process, none of this > works. In terms of standardized EAP methods with security, we have > EAP-GPSK and EAP-TLS. > EAP-TLS doesn't support channel binding and adding it would be > difficult. > EAP-GPSK probably is something we could use. However, it's the wrong fit > for a lot of deployments. > > RADSEC is a good fit for what we want. Except it's not standards track. > > Long term, TEAP will be a standards-track method we can move to. > Long term, either diameter will catch on, or we'll decide that RADSEC > or some other form of security is appropriate for a normative reference > from a standards-track spec. > > I don't think publishing ABFAB is experimental is the right approach. > I don't think blocking ABFAB until EAP and RADEXT get done coming up > with standards-track mechanisms is the right fix. > > So, I'm left concluding that being a bit liberal in our process and > doing something reasonable with the implementations is the right > approach here. > > So, I think that the right fix for the applicability statement is simply > to refer to section 1.2 of RFC 4962 and note that is > mandatory-to-implement. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab This approach sounds reasonable to me too. From stephen.farrell@cs.tcd.ie Fri Jul 20 10:21:20 2012 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 AD17421F850F for ; Fri, 20 Jul 2012 10:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 MOD3al-fJ2pB for ; Fri, 20 Jul 2012 10:21:19 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id DD4A421F850B for ; Fri, 20 Jul 2012 10:21:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 57A2517148B for ; Fri, 20 Jul 2012 18:22:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1342804927; bh=WII9iZq/lp/hWgbXa/KLmIP5 JEXAeE6XFTq6NdWYRls=; b=LjrlCRqt78iBOr5ZLmwWA1PTUi2zsnnRB+353tAW EM2ARRHvj/1A0Sc1FzNGHBJ6iYald/xPf38IEX3JrIpKxGddnZo5R6vV869Om71c peylGKm7JjIPEfmD341VoJoXI7Cfz59P/tlmbIxDtEbWUFmT0LQ2bWeS2VIgcNPA MaaP6y17T4BzD2vR6vnCF8D9Hz+E+PR+RE5wPwuyM1o8TbNwoZLHAppUm+eNJZix FKQQiHUnWTy33AW83XGngHKLxQh7NnuJtCAgC8jUs56xi4IQ/3gDQYJaJQDTO2mx /ft5lUda6PcMVBS9KMzRJgmZ/9sR9mvum7GFtKV0Ceg6MA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id nUTpWqjQ4GSg for ; Fri, 20 Jul 2012 18:22:07 +0100 (IST) Received: from [IPv6:2001:770:10:203:e08f:9c9a:c76d:2d13] (unknown [IPv6:2001:770:10:203:e08f:9c9a:c76d:2d13]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id E795B171475 for ; Fri, 20 Jul 2012 18:22:06 +0100 (IST) Message-ID: <500993C0.7040806@cs.tcd.ie> Date: Fri, 20 Jul 2012 18:22:08 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: abfab@ietf.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] AD review of draft-ietf-abfab-use-cases X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 17:21:20 -0000 Hi all, I've done my AD review of this - comments are below. I'm ok to start IETF LC on this now and you can handle my comments as IETF LC comments, or if you prefer you can spin another version (once submissions re-open) to handle them now. I'll wait for the chairs to let me know whether to start IETF LC or set this to revised ID needed. Thanks, S. 1. In general there are a number of times where this document seems to be wishful thinking. I think it'd be better if you reduced it to the more concrete use-cases where implementation is actually planned and where you can be more authoritative about how abfab will be beneficial. Sections 3.5 and 3.9 in particular seem weak to me and the document might be better if they were deleted - would you really miss them? 2. ID nits says: -- Obsolete informational reference (is this intentional?): RFC 2060 (Obsoleted by RFC 3501) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- No information found for draft-freeman-plasma-requirements - is the name correct? Looks like these should be updated as noted in the writeup. 3. Please expand CRM on 1st use 4. Maybe move the reference to SSH to the end of 3.1, from the start of 3.2, or ideally provide a reference to an "abfab-enabled SSH" if you have one. (And say "secure shell (SSH)" on 1st use.) 5. 2nd last para of 3.3 could do with some references really. 6. The argument in 3.3 that grid admin complexity is really due to X.509 seems weak to me. I'd expect you to get comments about that. And replacing the entire VO thing would be a large task. It'd be better if you had a very specific use-case here I think rather than being so general. 7. Its not clear to me how abfab helps in 3.5 - I think you'd maybe need to say some more about how that'd work. 8. 3.9: is it "smart object" or "smart device" just using one marketing term would be better (zero even moreso;-) 9. 3.9 seems quite far-fetched to me. Do you really expect sensors to use gss-eap? From leifj@sunet.se Fri Jul 20 11:20:01 2012 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 449F411E80CF for ; Fri, 20 Jul 2012 11:20:01 -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 1jKs74XpoFU6 for ; Fri, 20 Jul 2012 11:20:00 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 2195511E80BD for ; Fri, 20 Jul 2012 11:19:59 -0700 (PDT) Received: from [192.168.1.132] ([89.184.152.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6KIKoaH011413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Jul 2012 20:20:53 +0200 (CEST) Message-ID: <5009A181.8060406@sunet.se> Date: Fri, 20 Jul 2012 20:20:49 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: abfab@ietf.org References: <500993C0.7040806@cs.tcd.ie> In-Reply-To: <500993C0.7040806@cs.tcd.ie> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] AD review of draft-ietf-abfab-use-cases X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 18:20:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 9. 3.9 seems quite far-fetched to me. Do you really expect sensors > to use gss-eap? I've seen a couple of examples of sensor nets built using wifi hardware - sensors don't have to be small "toaster-like" objects. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAJoXwACgkQ8Jx8FtbMZnfnawCbBdzebEAYEMS7GA+pP5OhW3RJ v0kAn14hYppBapBTHtvlAP1zW5cJ7uSx =SzsR -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Fri Jul 20 12:30:51 2012 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 A949111E80CB for ; Fri, 20 Jul 2012 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 7kzYGmPZJyAy for ; Fri, 20 Jul 2012 12:30:28 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B74D11E80C4 for ; Fri, 20 Jul 2012 12:30:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 5F91817148B; Fri, 20 Jul 2012 20:31:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1342812682; bh=ZRTs2tNEn3sQ/R p4y77/j+On6/c+Xz0E1Nj1ivnqVUg=; b=385qbeMYzCdla2NlFSQavm7gJ/5qGB UTIrBjOKnuQHujA4fl/oWU7woFsnHnzPAdIoA/IEwol4A88d1Ls5x/yIZO9MyTRG hJKlYQOUEy7EgfYYWsF6a4uxYoczPM0wOJrDzVjpXZBJjarU5ZsnX/dpofJDxjKA aNJ9QHxjYfgTovKG3krkUmZ1cj5HSWXpYUQqVINqcxXd4p/u1I8rX/ncce5BxhYf +BDdo8r/MjvGnR/+uviP2vSmwx353sdeVtIQIQPRuKOodlSjzum4Valz1cfOGEa6 6Oivvt6gnDGPIMdKp7UiorNN15u6YSWoQqXjtfQ7WaxLhrBQukQ9JM3A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id YTH8G8ReKM4r; Fri, 20 Jul 2012 20:31:22 +0100 (IST) Received: from [10.87.48.3] (unknown [86.41.13.69]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 03A9D171475; Fri, 20 Jul 2012 20:31:21 +0100 (IST) Message-ID: <5009B209.3050904@cs.tcd.ie> Date: Fri, 20 Jul 2012 20:31:21 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Leif Johansson References: <500993C0.7040806@cs.tcd.ie> <5009A181.8060406@sunet.se> In-Reply-To: <5009A181.8060406@sunet.se> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-use-cases X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 19:30:51 -0000 On 07/20/2012 07:20 PM, Leif Johansson wrote: > >> 9. 3.9 seems quite far-fetched to me. Do you really expect sensors >> to use gss-eap? > > I've seen a couple of examples of sensor nets built using wifi > hardware - sensors don't have to be small "toaster-like" objects. Sure. I've built a number networks with nodes like that myself, (e.g. [1] :-) Never needed nor considered anything like abfab. Ours are v. small networks of course, but I've also never heard anyone ask for what 3.9 is selling. But like I said, its a comment that the wg can take or leave, before or during IETF LC. S. [1] http://extremecom2012.ee.ethz.ch/papers/6-extremecom2012-Arkko.pdf > > Cheers Leif > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From leifj@sunet.se Mon Jul 23 00:37:57 2012 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 7908221F8697 for ; Mon, 23 Jul 2012 00:37:57 -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 TuovMuyv5AyF for ; Mon, 23 Jul 2012 00:37:56 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 2385121F8679 for ; Mon, 23 Jul 2012 00:37:49 -0700 (PDT) Received: from [172.20.10.2] (2.65.70.36.mobile.tre.se [2.65.70.36]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6N7bZUd015129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 09:37:42 +0200 (CEST) Message-ID: <5009BBEC.3070100@sunet.se> Date: Fri, 20 Jul 2012 22:13:32 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Stephen Farrell References: <500993C0.7040806@cs.tcd.ie> <5009A181.8060406@sunet.se> <5009B209.3050904@cs.tcd.ie> In-Reply-To: <5009B209.3050904@cs.tcd.ie> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-use-cases X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 07:37:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/20/2012 09:31 PM, Stephen Farrell wrote: > > > On 07/20/2012 07:20 PM, Leif Johansson wrote: >> >>> 9. 3.9 seems quite far-fetched to me. Do you really expect >>> sensors to use gss-eap? >> >> I've seen a couple of examples of sensor nets built using wifi >> hardware - sensors don't have to be small "toaster-like" >> objects. > > Sure. I've built a number networks with nodes like that myself, > (e.g. [1] :-) Never needed nor considered anything like abfab. Ours > are v. small networks of course, but I've also never heard anyone > ask for what 3.9 is selling. > > But like I said, its a comment that the wg can take or leave, > before or during IETF LC. > > S. > > [1] > http://extremecom2012.ee.ethz.ch/papers/6-extremecom2012-Arkko.pdf Good - I misunderstood your comment as saying something else! All good. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAJu+cACgkQ8Jx8FtbMZndDgwCfcX7kXlFeucnWXH25Hx8ymXiH Gx0AnjXSiazWFgRDaLMRN/7kvfxGwsHv =75eH -----END PGP SIGNATURE----- From kwiereng@cisco.com Mon Jul 23 01:52:47 2012 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 6124721F8683 for ; Mon, 23 Jul 2012 01:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+L0qMjGcFAv for ; Mon, 23 Jul 2012 01:52:45 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB7821F84F4 for ; Mon, 23 Jul 2012 01:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=1648; q=dns/txt; s=iport; t=1343033565; x=1344243165; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hsNzjY3bSrlW8Am5Te7mGB5YBN8wxEZzA222dnu0r6g=; b=ipM9IPzUfyDB0FXWcYZcShs+vs360hmm7rB33Ix8ywNxjpMiFahUmcXM cuT+QU3X7ri7vscEGoGjA2mXtifczPoygomhVl+kHn1Vp84m7hR5WpxMa mj2iKSSCcIap70zPR9YjFCbQTCb2kwHMI90gblPJUTd76+AqFQVFnl+QH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFYQDVCtJV2d/2dsb2JhbABFuTWBB4IgAQEBAgEBAQEBDwFbCwULAgEIGC4nCyUCBA4FIodlBgueOp8Ui00FFoVYYAOVSYEUjROBZoJf X-IronPort-AV: E=Sophos;i="4.77,638,1336348800"; d="scan'208";a="104311958" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 23 Jul 2012 08:52:40 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6N8qehA029235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jul 2012 08:52:40 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.251]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 03:52:40 -0500 From: "Klaas Wierenga (kwiereng)" To: Stephen Farrell Thread-Topic: [abfab] AD review of draft-ietf-abfab-use-cases Thread-Index: AQHNZpw6M3+JbdhFI0esb+1u9jrjmZcyz1+AgAATtYCABASKAA== Date: Mon, 23 Jul 2012 08:52:39 +0000 Message-ID: <5978D530-FAD5-48F3-B8FB-41CBE5022445@cisco.com> References: <500993C0.7040806@cs.tcd.ie> <5009A181.8060406@sunet.se> <5009B209.3050904@cs.tcd.ie> In-Reply-To: <5009B209.3050904@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.7.37] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.005 x-tm-as-result: No--35.493700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <86DE0D5EEB1B694CA4E6E3570DA1D29D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [abfab] AD review of draft-ietf-abfab-use-cases X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 08:52:47 -0000 On Jul 20, 2012, at 9:31 PM, Stephen Farrell wrote: Stephen, > On 07/20/2012 07:20 PM, Leif Johansson wrote: >>=20 >>> 9. 3.9 seems quite far-fetched to me. Do you really expect sensors >>> to use gss-eap? >>=20 >> I've seen a couple of examples of sensor nets built using wifi >> hardware - sensors don't have to be small "toaster-like" objects. >=20 > Sure. I've built a number networks with nodes like that > myself, (e.g. [1] :-) Never needed nor considered anything > like abfab. Ours are v. small networks of course, but I've > also never heard anyone ask for what 3.9 is selling. ehm, I am not sure it is THAT far fetched. I would argue that in large scal= e sensor networks with sensors of different nature (in terms of processing = power, memory, battery consumption etc.) and connecting to untrusted networ= ks you do want an approach that has authentication agility, can operate in = an environment with delegated trust and that protects authentication creden= tials en route=85. I can think of different ways to achieve that, but I wou= ld not dismiss the abfab approach out of hand=85. Klaas >=20 > But like I said, its a comment that the wg can take or > leave, before or during IETF LC. >=20 > S. >=20 > [1] http://extremecom2012.ee.ethz.ch/papers/6-extremecom2012-Arkko.pdf >=20 >>=20 >> Cheers Leif >> _______________________________________________ >> 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 stephen.farrell@cs.tcd.ie Mon Jul 23 03:50:32 2012 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 067F421F8650 for ; Mon, 23 Jul 2012 03:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.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 fkeId5e3vz7Z for ; Mon, 23 Jul 2012 03:50:31 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id E8E2B21F863C for ; Mon, 23 Jul 2012 03:50:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B22F317148A; Mon, 23 Jul 2012 11:50:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1343040628; bh=41NjKJEHp9bWeF wtAyal7QWOapU38H/X1/io//X7sgg=; b=t4VWz1J43twwOw4jqCx3RmPyGddwyA CoFz5dMHtN6WoNtMW/yJrCE/5NeZMCCmgmXhvA5hFkIoQmDfAYPNFgNZRPhCrRGp 8Vb4x4+5gS4AMXSYMgE6lGHBg8zvlw+gp782yVnH0HXjb0qWRFP42FsheYj4Nw/K HF5R0dUlqrXidWAK8tQ9QIgb4DCETwKpNM1sMHSiWBXXV17sOQ/5ivnQRmNls5M3 PHgtPSIVpPiFOzD8VtS46xUFPkTEP6fxyw2q6pxmP6d9+1I8SWQYFKHP3wTP0Xfj k1qurWQ3plIIm78K5iS03zjjdaWuUETUp/6AdSdrz16hEL4UmYWpYTAg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cMNKaUW-0yyC; Mon, 23 Jul 2012 11:50:28 +0100 (IST) Received: from [10.87.48.8] (unknown [86.45.58.178]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D4760171488; Mon, 23 Jul 2012 11:50:27 +0100 (IST) Message-ID: <500D2C73.5060107@cs.tcd.ie> Date: Mon, 23 Jul 2012 11:50:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "Klaas Wierenga (kwiereng)" References: <500993C0.7040806@cs.tcd.ie> <5009A181.8060406@sunet.se> <5009B209.3050904@cs.tcd.ie> <5978D530-FAD5-48F3-B8FB-41CBE5022445@cisco.com> In-Reply-To: <5978D530-FAD5-48F3-B8FB-41CBE5022445@cisco.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [abfab] AD review of draft-ietf-abfab-use-cases X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 10:50:32 -0000 On 07/23/2012 09:52 AM, Klaas Wierenga (kwiereng) wrote: > > On Jul 20, 2012, at 9:31 PM, Stephen Farrell wrote: > > Stephen, > >> On 07/20/2012 07:20 PM, Leif Johansson wrote: >>> >>>> 9. 3.9 seems quite far-fetched to me. Do you really expect sensors >>>> to use gss-eap? >>> >>> I've seen a couple of examples of sensor nets built using wifi >>> hardware - sensors don't have to be small "toaster-like" objects. >> >> Sure. I've built a number networks with nodes like that >> myself, (e.g. [1] :-) Never needed nor considered anything >> like abfab. Ours are v. small networks of course, but I've >> also never heard anyone ask for what 3.9 is selling. > > ehm, I am not sure it is THAT far fetched. Well, even slightly far-fetched isn't really a good use-case is it? But whatever;-) S. > I would argue that in large scale sensor networks with sensors of different nature (in terms of processing power, memory, battery consumption etc.) and connecting to untrusted networks you do want an approach that has authentication agility, can operate in an environment with delegated trust and that protects authentication credentials en route…. I can think of different ways to achieve that, but I would not dismiss the abfab approach out of hand…. > > Klaas > >> >> But like I said, its a comment that the wg can take or >> leave, before or during IETF LC. >> >> S. >> >> [1] http://extremecom2012.ee.ethz.ch/papers/6-extremecom2012-Arkko.pdf >> >>> >>> Cheers Leif >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >>> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > From iesg-secretary@ietf.org Mon Jul 23 07:48:07 2012 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 21F5511E8086; Mon, 23 Jul 2012 07:48:07 -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 QaUuCn7oNLLo; Mon, 23 Jul 2012 07:48:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4166211E807F; Mon, 23 Jul 2012 07:48:06 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120723144806.14333.18008.idtracker@ietfa.amsl.com> Date: Mon, 23 Jul 2012 07:48:06 -0700 Cc: abfab@ietf.org Subject: [abfab] Last Call: (Application Bridging for Federated Access Beyond web (ABFAB) Use Cases) to Informational RFC X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 14:48:07 -0000 The IESG has received a request from the Application Bridging for Federated Access Beyond web WG (abfab) to consider the following document: - 'Application Bridging for Federated Access Beyond web (ABFAB) Use Cases' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-08-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Federated identity is typically associated with Web-based services at present, but there is growing interest in its application in non Web- based contexts. The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ballot/ Some references need updating: RFC 2060 -> RFC 3501 and RFC 2821 ->RFC 5321. No IPR declarations have been submitted directly on this I-D. From alper.yegin@yegin.org Wed Jul 25 08:57:28 2012 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 CC7EC21F86A7 for ; Wed, 25 Jul 2012 08:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQL7ScNiwej6 for ; Wed, 25 Jul 2012 08:57:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id E843B21F869A for ; Wed, 25 Jul 2012 08:57:27 -0700 (PDT) Received: from [192.168.2.6] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0Md2yY-1TCHIh2HGk-00Hlja; Wed, 25 Jul 2012 11:57:19 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_075102CF-86E6-4E14-8459-B65485760F6C" From: Alper Yegin In-Reply-To: Date: Wed, 25 Jul 2012 18:56:59 +0300 Message-Id: References: <500961A2.4060104@cs.tcd.ie> To: Leif Johansson X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:o8MMUvRS2L27f6djk+zav0iFehPuJQ2tXAQ2CTTv4nx rtQimlQkK9ppOKo6NFcrU0bSWA2w/vsVX1AReek61pJ2i/Hp4I se0uTXOuPMhrBm0Tz0N/zRj/ynDyeUUfo7PL91Cup9iWKhDc2X cwKHgrTxGk931oG1KeRzKI91+zfLTV1d3CDueD0dew4s6M4T3F w2FaEgaF+9mBHGehAmTqu+9ryB9/zCshhKMCyJYF3n52mbqi81 OnNNiL1ah1iTYGg1GCMtA+vsSX/ZHHbKyZszv6aG7300i1aW6c Pyqw8bXy+J8xtV6mCnKu315Q6EQs0Nu+kGzKeQeQ+WFhnD+uIK +h0CbbbcqliMsK4d/qZVIiLrUVNNQ48mTjcyByso8bkM7LPvRv 3rUvwpn+uoAZQ== Cc: "abfab@ietf.org" Subject: Re: [abfab] EAP applicability statement comment X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:57:28 -0000 --Apple-Mail=_075102CF-86E6-4E14-8459-B65485760F6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Another comment: In most network access use cases all access servers that are served by a particular EAP server are providing the same or very similar types of service. The peer does not need to differentiate between different access network services supported by the same EAP server. This is not accurate. In between the EAP peer and the EAP authentication = server, there are zero or more independent service providers (access = network provider, roaming exchange, roaming network provider).=20 It's not like all of the access networks being served by the EAP auth = server belong to the same service provider (that owns the EAP auth = server too). The type of service the mobile device gets differ too (e.g., roaming vs = non-roaming). Shouldn't the channel binding requirements equally apply to network = access and non-network access cases? Alper On Jul 20, 2012, at 6:41 PM, Leif Johansson wrote: >=20 >=20 >=20 > 20 jul 2012 kl. 16:24 skrev "Sam Hartman" = : >=20 >> So, I'm really hoping that from a process standpoint we can not look = to >> hard at this. I absolutely agree with Bernard that we need to = implement >> things that meet the 4962 requirements. >>=20 >> The implementation I have the most experience with (Moonshot) does >> implement RFC 4962. We use radsec as the key confidentiality method >> between AAA server and client. >>=20 >> We basically require EAP-TTLS because that's all we're currently >> implementing channel binding for. >>=20 >> The problem is that if we get too picky about IETF process, none of = this >> works. In terms of standardized EAP methods with security, we have >> EAP-GPSK and EAP-TLS. >> EAP-TLS doesn't support channel binding and adding it would be >> difficult. >> EAP-GPSK probably is something we could use. However, it's the wrong = fit >> for a lot of deployments. >>=20 >> RADSEC is a good fit for what we want. Except it's not standards = track. >>=20 >> Long term, TEAP will be a standards-track method we can move to. >> Long term, either diameter will catch on, or we'll decide that = RADSEC >> or some other form of security is appropriate for a normative = reference >> from a standards-track spec. >>=20 >> I don't think publishing ABFAB is experimental is the right approach. >> I don't think blocking ABFAB until EAP and RADEXT get done coming up >> with standards-track mechanisms is the right fix. >>=20 >> So, I'm left concluding that being a bit liberal in our process and >> doing something reasonable with the implementations is the right >> approach here. >>=20 >> So, I think that the right fix for the applicability statement is = simply >> to refer to section 1.2 of RFC 4962 and note that is >> mandatory-to-implement. >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 >=20 > This approach sounds reasonable to me too. >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --Apple-Mail=_075102CF-86E6-4E14-8459-B65485760F6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
   In most network access use cases all =
access servers
   that are served by a particular EAP server are providing the same or
   very similar types of service.  The peer does not need to
   differentiate between different access network services supported by
   the same EAP =
server.


This is not = accurate. In between the EAP peer and the EAP authentication server, = there are zero or more independent service providers (access network = provider, roaming exchange, roaming network = provider). 
It's not like all of the access networks = being served by the EAP auth server belong to the same service provider = (that owns the EAP auth server too).
The type of service the = mobile device gets differ too (e.g., roaming vs = non-roaming).
Shouldn't the channel binding requirements = equally apply to network access and non-network access = cases?

Alper


<= div>

On Jul 20, 2012, at 6:41 PM, Leif = Johansson wrote:




20 jul 2012 kl. 16:24 skrev "Sam Hartman" = <hartmans@painless-security.= com>:

So, I'm really hoping that = from a process standpoint we can not look to
hard at this.  I absolutely agree with Bernard that = we need to implement
things = that meet the 4962 requirements.

The = implementation I have the most experience with (Moonshot) = does
implement RFC 4962. =  We use radsec as the key confidentiality = method
between AAA server and = client.

We basically = require EAP-TTLS because that's all we're = currently
implementing channel = binding for.

The problem is = that if we get too picky about IETF process, none of = this
works.  In terms of = standardized EAP methods with security, we = have
EAP-GPSK and = EAP-TLS.
EAP-TLS doesn't = support channel binding and adding it would = be
difficult.
EAP-GPSK probably is something we could use. However, it's = the wrong fit
for a lot of = deployments.

RADSEC is a = good fit for what we want. Except it's not standards = track.

Long term, TEAP = will be a standards-track method we can move = to.
Long term,  either = diameter will catch on, or we'll decide that = RADSEC
or some other form of = security is appropriate for a normative = reference
from a = standards-track spec.

I don't think = publishing ABFAB is experimental is the right = approach.
I don't think = blocking ABFAB until EAP and RADEXT get done coming = up
with standards-track = mechanisms is the right fix.

So, I'm left = concluding that  being a bit liberal in our process = and
doing something reasonable = with the implementations is the right
approach here.

So, I think = that the right fix for the applicability statement is = simply
to refer to section 1.2 = of RFC 4962 and note that is
mandatory-to-implement.
_______________________________________________
abfab mailing = list
abfab@ietf.org
https://www.ietf.org/= mailman/listinfo/abfab


This approach sounds = reasonable to me = too.

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

= --Apple-Mail=_075102CF-86E6-4E14-8459-B65485760F6C-- From smith@Cardiff.ac.uk Fri Jul 27 22:58:32 2012 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 ED17821F870B for ; Fri, 27 Jul 2012 22:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.53 X-Spam-Level: X-Spam-Status: No, score=-5.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4kE6dD5R7M6 for ; Fri, 27 Jul 2012 22:58:31 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEB021F86EE for ; Fri, 27 Jul 2012 22:58:31 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1Sv02n-00025x-8v; Sat, 28 Jul 2012 06:58:29 +0100 Received: from [70.79.179.73] (helo=[192.168.0.19]) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Sv02m-0003er-RE; Sat, 28 Jul 2012 06:58:29 +0100 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Rhys Smith In-Reply-To: <00d501cd5e04$a11c50c0$e354f240$@augustcellars.com> Date: Fri, 27 Jul 2012 14:30:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120709171408.20328.2523.idtracker@ietfa.amsl.com> <00d501cd5e04$a11c50c0$e354f240$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-arch-03.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: Sat, 28 Jul 2012 05:58:33 -0000 Some comments from me. Mostly very minor nits, but some larger = questions. Obviously I'm ignoring the bits which are obviously still to = be done. Overall - think it's looking pretty good, all made sense to me, and = described the various components of ABFAB appropriately. But I already = had a pretty good grasp of that so that view my not be independent = enough. Stuff: Abstract, Para 1. "common building blocks in common" - lose the first = "common". Sec 1, Para 3. s/signaling/signalling. Sec 1, Para 3, line 5 - s/protocol/protocols Sec 1.1 Para 4, line 3/4 - a bit informal! "This is due the fact that = the terms used by the different standards we are picking up don't use = the same terms". Perhaps "This is due to the fact that the different = standards in use within the ABFAB architecture use differing, and = sometimes incompatible, terminology". Sec 1.2 Para 8?, line 1 - "The nature of federation dictates that there = is some form of relationship between the identity provider and the = relying party". Not sure this is true at all. There are plenty of = examples I can think of where there is no relationship between IdP and = RP other than they're in the same federation, yet the subjects still = make use of the service - e.g. community managed wikis or whatnot. Sec 1.2 Para 14?, - "that is only Requiems completing" - think something = went horribly wrong here :-). Sec 1.2 Para 14? - "publishing a usage point" - what's "a usage point" = in this context? I'm pretty sure I know what you mean, but many people = may not be... Sec 1.4 Para 1 - "and its the" - think you need to lose a word here... Sec 1.4 Point 1 - should probably include a reference to the = UI/Usability I-D which discusses this kind of thing. Sec 1.4 Point 3 - don't think "setups" is a word :-). "sets up". Sec 1.4 Point 4 - "to determine what IdP" - "to determine which IdP". Sec 1.4 Point 5 - you've used RP in all previous points, now you use = "Relying Party". Suggest you use RP for consistency. Sec 1.4 Point 5 - "Once the RP knows who the IdP is, it (or its agent) = will send a RADIUS/Diameter request to the IdP" - "Once the RP knows = which IdP to use, it (or its agent) will send a RADIUS/Diameter request = to it". Sec 1.4 Point 5 - "At this stage, the RP will likely have no idea who = the client is." - Not sure what you mean by this? Sec 1.4 Point 5 - s/Request//Requests [SAML Attribute Requests] Sec 1.4 Point 7 - "between the EAP peer and the EAP server, i.e., the = client and the IdP in our identity management terminology" - "between = the EAP peer and EAP server (a.k.a. client and IdP) - (this is not = "identity management" terminology). Sec 1.4 Point 7 - "If the IdP is unable to authenticate the client, the = process concludes here." - ...and what happens as far as the user is = concerned? Sec 1.4 Point 7 - "channel bindings" is introduced. Not sure if there = should be a reference here? Not least because there are different kinds = of channel bindings. Sec 1.4 Point 9 - s/what if any/which if any Sec 1.4 Point 11 - "If additional attributes are needed from the IdP the = RP may make a new SAML Request to the IdP"... over AAA? or using a back = channel SAML binding? Sec 1.5 2nd bullet point - s/Means/The means. Sec 1.5 2nd bullet point - do you mean "multiple authentication methods" = as in multi factor authentication, as in agility of a single = authentication mechanism, or both? Sec 1.5 3rd bullet point - "Hence, the architecture requires no sharing = of long term private keys."... is not a design goal, or rather, this = bullet isn't framed as a design goal but states a consequence. Either = put in on the previous bullet point, or frame it as a design goal... Sec 1.5 4th bullet point - "large numbers" maybe should be quantified or = bounded in some way. To some thousands is a large number. To others, = billions... Sec 1.5 - "Despite the increased excitement for layering every protocol = on top of HTTP there are still a number of protocols available that do = not use HTTP-based transports". No nits at all. I just like this = sentence a lot :-). Sec 1.6 Para 1 - "Interestingly, for network access authentication" - = I'd suggest "Interestingly, for federated authentication in the network = access context". Sec 1.6 Para 1 - "was quite successful" - "has been successful" Sec 1.6 Para 1 - s/EDUROAM/Eduroam. Sec 1.6 Para 2 - "By using" - "By reusing". Sec 1.6 1st bullet point - "It already needs a method of doing routing = of requests" - "It already has a method of routing requests". Sec 2 Para 2 - "assumes updates to the relying party" - "assumes updates = to the relying party to support ABFAB" or somesuch. Sec 2 Para 3 - s/ways for/ways of Sec 2 Para 3 - "the usage of the GSS-API was chosen." - "the usage of = the GSS-API was chosen as many of these protocols already support = GSS-API". Sec 2 Fig 1 - We've had discussion about what federations are, but = "federation substrate"? Sec 2 para 1 - s/Part/Party Sec 2.1.1 para 1 - s/exist in RADIUS/exist in the RADIUS Sec 2.1.1 para 1 - s/reasonable/reasonably Sec 2.1.1 para 1 - "These protocols are nicely designed" - "Helpfully, = these protocols are designed". Sec 2.1.1 para 2 - "We leave as a deployment decision, which protocol = will be appropriate" - "We leave the choice of protocol to be used as a = deployment decision". Sec 2.1.4 para 1 - "was an affirmative response from the IdP" - Bit = vague. What do you mean by affirmative response? I know what you mean = but the reader may not. Sec 2.1.4 para 2 - "for our work" - "to achieve our goals". Sec 2.1.4 para 2 - "It will be necessary to update IdPs" - need to be = more specific here about which "IdP you're talking about - i.e. update = the ABFAB IdP (some may read as meaning the SAML IdP). Sec 2.1.4 para 2 - "that need to return SAML assertions to IdPs" - don't = you mean to RPs? Sec 2.1.4 para 4 - "provide origination" - "provide assurance as to the = origin"? Sec 2.1.4 para 5 - "Attributes placed in SAML Assertions can have = different namespaces assigned to the same name." - I think this sentence = needs a bit more explanation for those not familiar with SAML.=20 Sec 2.1.4 para 5 - s/cases a the/cases the Sec 2.1.4 para 5 - |In many, but not all, cases the federation = agreements will determine what attributes can be used in a SAML = statement." - not sure that's really the case. Federations typically = determine a recommended set of common attributes, but "can be used in" = doesn't quite describe that properly. Maybe something more like "will = determine the semantics of a common set of attributes to be regularly = used in a SAML statement"... Sec 2.1.4 para 5 - "into the onces" - "into the ones". Sec 2.1.4 para 5 - "If the proxies are modifying the SAML Assertion, = then will obviously remove any signatures on the SAML Assertions as they = would no longer validate." s/then will obviously/they should obviously" = (note 2 changes - then->they and will->should) Sec 2.2 para 2 - refs to channel bindings docs please. Sec 2.2.1 para 1 - " In addition, use of browsers for authentication = restricts the deployment of more secure forms of authentication beyond = plaintext username and password known by the server." - Not true, you = can do more than username/password authn in a browser... Sec 2.2.1 para 6 - "i.e,service" - "i.e., service" Sec 2.3.1 para 3 (line 4) - s/prospective/perspective Sec 3.3 para 2 (line 6) - s/suchs/such Sec 3.3, various bits - language needs to be tidied up, e.g. "ABFAB = needs to adopt this approach.". Sec 4 - what about cases where the IdP doesn't know the attribute = authority, but the user does? Sec 5 para 1 - "Sharing identity information raises privacy violations" = - I think "Sharing identity information across organisational boundaries = raises the possibility of privacy violations" is a bit more accurate. Sec 5 generally - You've gotten this far through the document without = using the word "user", instead principal, subject, etc. Should carry on = with that for consistency. Sec 5.2 para 1 - "This relationship will be created at the time when the = security credentials are exchange and provisioned". Weird phrasing! = "When the relationship is instantiated (e.g. when a subject is employed = by an organisation) security credentials will typically be exchanged and = credentials provisioned" makes a bit more sense. Sec 5.2 para 1 - s/intermediares/intermediaries=20 Sec 5.2 para 1 - "are typically operate" - change wording. Sec 5.2 para 1 - "The relying party does not have a direct contractual = relationship with the user" - I'd add a typically in there or something, = as it's entirely possible the user might in certain cases. Sec 5.3 para 1 (line 5) - s/like/likely Sec 5.5 para 1 - Sentence starts with "While" but doesn't end = appropriately... -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C On 9 Jul 2012, at 11:57, Jim Schaad wrote: > This version has had a substantial rewrite on section 2. The new = version > makes it more clear what protocols are used where and gives some of = the > reasoning behind the selection of the protocol. >=20 > Comments and suggestions are gladly welcomed. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On = Behalf >> Of internet-drafts@ietf.org >> Sent: Monday, July 09, 2012 10:14 AM >> To: i-d-announce@ietf.org >> Cc: abfab@ietf.org >> Subject: [abfab] I-D Action: draft-ietf-abfab-arch-03.txt >>=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) Architecture >> Author(s) : Josh Howlett >> Sam Hartman >> Hannes Tschofenig >> Eliot Lear >> Jim Schaad >> Filename : draft-ietf-abfab-arch-03.txt >> Pages : 44 >> Date : 2012-07-09 >>=20 >> 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 and web-based access. However, = the >> solutions to these use-cases that have been proposed and deployed >> tend to have few common building blocks in common. >>=20 >> 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) and the Diameter protocol, the Generic >> Security Service (GSS), the GS2 family, 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-abfab-arch >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-abfab-arch-03 >>=20 >> A diff from previous version is available at: >> http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=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 leifj@mnt.se Mon Jul 30 13:33:55 2012 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 72D9E11E8183 for ; Mon, 30 Jul 2012 13:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIkJFCpskf6R for ; Mon, 30 Jul 2012 13:33:55 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id AB7B811E8134 for ; Mon, 30 Jul 2012 13:33:54 -0700 (PDT) Received: from [130.129.18.31] (dhcp-121f.meeting.ietf.org [130.129.18.31]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q6UKXmUj008414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Jul 2012 22:33:53 +0200 (CEST) Message-ID: <5016EFAC.8040802@mnt.se> Date: Mon, 30 Jul 2012 22:33:48 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "abfab@ietf.org" References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [abfab] Fwd: Need volunteers for the NomCom X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 20:33:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: Need volunteers for the NomCom Date: Sun, 29 Jul 2012 20:22:33 -0700 From: NomCom Chair To: Working Group Chairs We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. I understand that not all IETF participants read the IETF announce list frequently. Therefore, if you would be willing to inform active participants in your working groups about this year's call for NomCom volunteers, I would greatly appreciate it. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/ Thank you for your help, - - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAW76wACgkQ8Jx8FtbMZnf7mQCeIZyzSkRDK0MxRpOvIUimcIGD 7ToAoJ9FT7jvjAB5oh8AWbcluGyubENK =jx+I -----END PGP SIGNATURE----- From internet-drafts@ietf.org Mon Jul 30 16:36:38 2012 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 160F311E8109; Mon, 30 Jul 2012 16:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 oo40ZkL7WHpI; Mon, 30 Jul 2012 16:36:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F7211E809A; Mon, 30 Jul 2012 16:36:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120730233637.25681.72960.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 16:36:37 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 23:36:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Update to the EAP Applicability Statement for ABFAB Author(s) : Stefan Winter Joseph Salowey Filename : draft-ietf-abfab-eapapplicability-00.txt Pages : 6 Date : 2012-07-30 Abstract: This document updates the EAP applicability statement from RFC3748 to reflect recent usage of the EAP protocol in application oriented use cases proposed in ABFAB The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-eapapplicability-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Mon Jul 30 18:35:55 2012 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 1FEF221F84B2 for ; Mon, 30 Jul 2012 18:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06lMgiMmGfx4 for ; Mon, 30 Jul 2012 18:35:54 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 985A921F84A7 for ; Mon, 30 Jul 2012 18:35:54 -0700 (PDT) Received: from Tobias (dhcp-10a6.meeting.ietf.org [130.129.16.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 43CA338EA7; Mon, 30 Jul 2012 18:35:54 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 30 Jul 2012 18:34:29 -0700 Message-ID: <00da01cd6ebc$a1768ae0$e463a0a0$@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: Ac1utv9i+ODEwH7RTmyEF7CRtQB3tw== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 01:35:55 -0000 Abstract. 1. Expand the EAP and ABFAB 2. Do you really want to talk about the use cases in the sentence? Uses of EAP for Application-Layer Access 1. It is not clear to me that using channel bindings informs the peer what services are provided by an authenticator. What I think is given is that the peer can validate that A specific service is provided. 2. para #2 says that which service is needed, but the previous paragraph is talking about different services not different qualities of a specific service. I don't think this follows well. 3. Swapping sentences 2 and 3 in para #2 might be reasonable - this describing that the quality of service can be important and then giving an example of why that is true. 4. Do we have the ability to discuss the security implications in channel binding? In order for this to be true you need to have the ability to have a distinct name of the service between the low and high value versions of the same service. This would mean multiple names for the "print" service. It is not clear that this is how people are going to do this. 5. After reading this for a while, I think that part of my problem is that I am picking up a different meaning for the word service. I think of service as a print service, not of as "The high security print service running on machine foo.example.com". If this is the case then that might be the clarification that removes the above comments. 6. I think that you might talk about the cases where channel binding COULD be required even for network authentication. The fact that it is not required does not mean that it cannot be used. One issue is going to be how an IdP identifies a network authentication service from a different service for the purposes of deciding if channel binding is going to be required. 7. Is it just important to prove that the EAP MSK is mutually held, or is it REQUIRED? What are the implications of not doing so? Security Considerations 1. When doing channel binding, it is highly desirable (required?) that the authenticator is not able to modify (and potentially to see?) the channel binding data passed from the peer to the authenticator (or reverse) as part of the authentication process. From trac+abfab@trac.tools.ietf.org Mon Jul 30 19:21:14 2012 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 AE7A411E80CC for ; Mon, 30 Jul 2012 19:21:13 -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 cNegDyCy4ouD for ; Mon, 30 Jul 2012 19:21:13 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1294811E809A for ; Mon, 30 Jul 2012 19:21:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:33607 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Sw24r-00088b-32; Tue, 31 Jul 2012 04:20:53 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 31 Jul 2012 02:20:52 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/abfab/trac/ticket/2#comment:2 Message-ID: <077.bff7f99cbd915d85ff0685a198629d38@trac.tools.ietf.org> References: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hannes.tschofenig@gmx.net, hartmans-ietf@mit.edu, ietf@augustcellars.com, josh.howlett@ja.net, lear@cisco.com Resent-Message-Id: <20120731022113.1294811E809A@ietfa.amsl.com> Resent-Date: Mon, 30 Jul 2012 19:21:13 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is running over X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:21:14 -0000 #2: Section 1.4 - No discussion of transport GSS-API is running over Changes (by ietf@…): * status: new => closed * resolution: => fixed Comment: Fixed in version -02 -- --------------------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Mon Jul 30 19:21:45 2012 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 23A0011E80EA for ; Mon, 30 Jul 2012 19:21:45 -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 sJd1TNrEmfzW for ; Mon, 30 Jul 2012 19:21:44 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E5D7B11E80D2 for ; Mon, 30 Jul 2012 19:21:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:33634 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Sw25Y-0002p1-0o; Tue, 31 Jul 2012 04:21:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 31 Jul 2012 02:21:35 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/5#comment:1 Message-ID: <077.7b9f6dcff4f11e2cf707e09efb558e89@trac.tools.ietf.org> References: <062.e822bf8ba8d5efc7ec13013540b126ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <062.e822bf8ba8d5efc7ec13013540b126ac@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hannes.tschofenig@gmx.net, hartmans-ietf@mit.edu, ietf@augustcellars.com, josh.howlett@ja.net, lear@cisco.com Resent-Message-Id: <20120731022143.E5D7B11E80D2@ietfa.amsl.com> Resent-Date: Mon, 30 Jul 2012 19:21:43 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #5: Section 1.4 - Step 8 - Be more explicit about describing channel binding. X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:21:45 -0000 #5: Section 1.4 - Step 8 - Be more explicit about describing channel binding. Changes (by ietf@…): * status: new => closed * resolution: => fixed Comment: Fixed in versin -02 -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Mon Jul 30 19:22:32 2012 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 9EBC311E80E5 for ; Mon, 30 Jul 2012 19:22:31 -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 16RNYnc6rq9Y for ; Mon, 30 Jul 2012 19:22:31 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id F0A3911E80CC for ; Mon, 30 Jul 2012 19:22:30 -0700 (PDT) Received: from localhost ([127.0.0.1]:33649 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Sw26L-0007Ro-E6; Tue, 31 Jul 2012 04:22:25 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 31 Jul 2012 02:22:25 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/6#comment:1 Message-ID: <077.da951e1ea1a3043d46f3b6e0e21fb648@trac.tools.ietf.org> References: <062.7b7594d622efd3b057ab54bfed900ea0@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <062.7b7594d622efd3b057ab54bfed900ea0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hannes.tschofenig@gmx.net, hartmans-ietf@mit.edu, ietf@augustcellars.com, josh.howlett@ja.net, lear@cisco.com Resent-Message-Id: <20120731022230.F0A3911E80CC@ietfa.amsl.com> Resent-Date: Mon, 30 Jul 2012 19:22:30 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #6: Section 2.2 - bad flow of text for authentication requriements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:22:33 -0000 #6: Section 2.2 - bad flow of text for authentication requriements Changes (by ietf@…): * status: new => closed * resolution: => fixed Comment: Fixed in -02 -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Mon Jul 30 19:23:04 2012 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 B50D211E80EE for ; Mon, 30 Jul 2012 19:23:04 -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 nAJRBHBnSgMq for ; Mon, 30 Jul 2012 19:23:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA4711E809A for ; Mon, 30 Jul 2012 19:23:04 -0700 (PDT) Received: from localhost ([127.0.0.1]:33669 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Sw26t-0001Ka-3R; Tue, 31 Jul 2012 04:22:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 31 Jul 2012 02:22:59 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/19#comment:1 Message-ID: <077.74ae5fce0c8440e4e67ce2c4ae2d9b06@trac.tools.ietf.org> References: <062.3c4f1f3c7db7c1fd9c4316f9034e38c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <062.3c4f1f3c7db7c1fd9c4316f9034e38c9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hannes.tschofenig@gmx.net, hartmans-ietf@mit.edu, ietf@augustcellars.com, josh.howlett@ja.net, lear@cisco.com Resent-Message-Id: <20120731022304.1EA4711E809A@ietfa.amsl.com> Resent-Date: Mon, 30 Jul 2012 19:23:04 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #19: Setion 1.4 - Overview - X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:23:04 -0000 #19: Setion 1.4 - Overview - Changes (by ietf@…): * status: new => closed * resolution: => fixed Comment: Fixed in -02 -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Mon Jul 30 19:23:56 2012 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 471FF11E80D2 for ; Mon, 30 Jul 2012 19:23:56 -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 T1VcFirDpPBV for ; Mon, 30 Jul 2012 19:23:55 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7591E11E80CC for ; Mon, 30 Jul 2012 19:23:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:33687 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Sw27i-0004aw-La; Tue, 31 Jul 2012 04:23:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 31 Jul 2012 02:23:50 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/27#comment:2 Message-ID: <077.5ade0792a045eb3abd154eb8062a0e86@trac.tools.ietf.org> References: <062.66220d434bcbf9a46583666c519b6576@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <062.66220d434bcbf9a46583666c519b6576@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hannes.tschofenig@gmx.net, hartmans-ietf@mit.edu, ietf@augustcellars.com, josh.howlett@ja.net, lear@cisco.com Resent-Message-Id: <20120731022355.7591E11E80CC@ietfa.amsl.com> Resent-Date: Mon, 30 Jul 2012 19:23:55 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #27: Setion 3.1 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:23:56 -0000 #27: Setion 3.1 Changes (by ietf@…): * status: new => closed * resolution: => fixed Comment: Fixed in version -02 -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Mon Jul 30 19:24:56 2012 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 EE26D11E80CC for ; Mon, 30 Jul 2012 19:24:56 -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 HvJay72XtY9r for ; Mon, 30 Jul 2012 19:24:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id C4D3D11E809A for ; Mon, 30 Jul 2012 19:24:55 -0700 (PDT) Received: from localhost ([127.0.0.1]:33710 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Sw28c-0000XO-3J; Tue, 31 Jul 2012 04:24:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 31 Jul 2012 02:24:46 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/28#comment:3 Message-ID: <077.1e9d0502b09021d86847cc05f2136a9d@trac.tools.ietf.org> References: <062.6d0caaa3bde28c503e5a4879aaaf29db@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <062.6d0caaa3bde28c503e5a4879aaaf29db@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: hannes.tschofenig@gmx.net, hartmans-ietf@mit.edu, ietf@augustcellars.com, josh.howlett@ja.net, lear@cisco.com Resent-Message-Id: <20120731022455.C4D3D11E809A@ietfa.amsl.com> Resent-Date: Mon, 30 Jul 2012 19:24:55 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #28: Missing Security Consideration - AAA protection of the MSK X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:24:57 -0000 #28: Missing Security Consideration - AAA protection of the MSK Changes (by ietf@…): * status: reopened => closed * resolution: => fixed Comment: Fixed in version -02 -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab