From leifj@mnt.se Sun Dec 1 13:08:12 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32991AE158 for ; Sun, 1 Dec 2013 13:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEBNnaVavsfq for ; Sun, 1 Dec 2013 13:08:11 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D083D1AE13F for ; Sun, 1 Dec 2013 13:08:10 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id ep20so8014086lab.31 for ; Sun, 01 Dec 2013 13:08:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5YPUPRjIztb7Vqj1UA87UXKotkyopLPVwBqxnRpBT88=; b=Z06K4PublhxrlhrhoJXPgfKxHHQaSNr5D/722gxmvDAl2au5pOpbtZKT8UysB8Pwbk w5Re8enOmrOrAsexVH+noa4M7jHbDbRRVTEL3qOwQSvCWCkcDkyk/phsM0lrEpLNu0+d itchO5OeiQGCH38++/5m7MLiLQgUeDg26xKsVEhJdd/NlRN+p+aaDvpkj2HXS4Wb5phY yxed6ecX40tqsak2AnkziSktBUuWtN89tdna8VXTjMtZNr19xEhl5q/I+Er20vfheNUC IywepOi4AdsUv9QWNR9zUe3eRYtZm2J9hdl6aH+yBDi/EXLGVD/xGcJeQ0kloVamna+U 3K6A== X-Gm-Message-State: ALoCoQla6aHHkieHy/0zrPbzANjGTkFDxyA46XlhbXLyyYtFymrirKXG0flxWZUedMCdu3Sf2+FD X-Received: by 10.112.200.170 with SMTP id jt10mr41450756lbc.10.1385932088053; Sun, 01 Dec 2013 13:08:08 -0800 (PST) Received: from [10.0.0.248] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by mx.google.com with ESMTPSA id a8sm35742954lae.5.2013.12.01.13.08.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 01 Dec 2013 13:08:06 -0800 (PST) Message-ID: <529BA534.4050700@mnt.se> Date: Sun, 01 Dec 2013 22:08:04 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: abfab@ietf.org References: <527FF519.4030104@mnt.se> In-Reply-To: <527FF519.4030104@mnt.se> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] WGLC of draft-ietf-abfab-arch-08 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 21:08:13 -0000 On 11/10/2013 10:05 PM, Leif Johansson wrote: > This starts a 2 week Working Group Last Call on draft-ietf-abfab-arch-08. > > The WGLC ends on Monday 25:th of November 2013. Get your comments > on the draft in by then. > > Leif & Klaas > Sorry for missing the end-date by a week but the WGLC has clearly passed wo comments so we'll push this up the stack, thx! Cheers Leif From internet-drafts@ietf.org Fri Dec 6 10:37:42 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F121AE0F6; Fri, 6 Dec 2013 10:37:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnXt3yY0RWkR; Fri, 6 Dec 2013 10:37:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AE31AE37A; Fri, 6 Dec 2013 10:37:40 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131206183740.2213.39582.idtracker@ietfa.amsl.com> Date: Fri, 06 Dec 2013 10:37:40 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:37:42 -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-09.txt Pages : 43 Date : 2013-12-06 Abstract: Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few 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 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leifj@sunet.se Fri Dec 6 10:47:46 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375AE1AC828 for ; Fri, 6 Dec 2013 10:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg_ZRGAMzABc for ; Fri, 6 Dec 2013 10:47:43 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id A693B1AE016 for ; Fri, 6 Dec 2013 10:47:42 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id rB6IlYlp008220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Dec 2013 19:47:34 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id rB6G3uqR023853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Dec 2013 17:03:58 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [10.0.0.248] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.1) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)) for abfab@ietf.org; Fri, 6 Dec 2013 19:47:31 +0100 Message-ID: <52A21BC2.4040208@sunet.se> Date: Fri, 06 Dec 2013 19:47:30 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: abfab@ietf.org References: <20131206183740.2213.39582.idtracker@ietfa.amsl.com> In-Reply-To: <20131206183740.2213.39582.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09KWiLyzt - 54204247820c - 20131206 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] I-D Action: draft-ietf-abfab-arch-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:47:46 -0000 On 12/06/2013 07:37 PM, internet-drafts@ietf.org wrote: > 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. I've submitted this to the IESG with a writeup. > 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-09.txt > Pages : 43 > Date : 2013-12-06 > > Abstract: > Over the last decade a substantial amount of work has occurred in the > space of federated access management. Most of this effort has > focused on two use cases: network access and web-based access. > However, the solutions to these use cases that have been proposed and > deployed tend to have few 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 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-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-arch-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Fri Dec 6 11:08:52 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E831AE08D for ; Fri, 6 Dec 2013 11:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5O53AD7Mphqm for ; Fri, 6 Dec 2013 11:08:50 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id A82761AE0E9 for ; Fri, 6 Dec 2013 11:08:47 -0800 (PST) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id EAB3438F48 for ; Fri, 6 Dec 2013 11:08:43 -0800 (PST) From: "Jim Schaad" To: References: <20131206183740.2213.39582.idtracker@ietfa.amsl.com> In-Reply-To: <20131206183740.2213.39582.idtracker@ietfa.amsl.com> Date: Fri, 6 Dec 2013 11:07:17 -0800 Message-ID: <022c01cef2b6$61d8f060$258ad120$@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: AQJtxvkSy1MJ5IxzJlIo/NHPk2ZPrJkJ3qAQ Content-Language: en-us Subject: [abfab] FW: I-D Action: draft-ietf-abfab-arch-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:08:52 -0000 This version cleans up some NITs dealing with references and accidental 2119 language. There are no significant changes. Jim > -----Original Message----- > From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Friday, December 06, 2013 10:38 AM > To: i-d-announce@ietf.org > Cc: abfab@ietf.org > Subject: [abfab] I-D Action: draft-ietf-abfab-arch-09.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-09.txt > Pages : 43 > Date : 2013-12-06 > > Abstract: > Over the last decade a substantial amount of work has occurred in the > space of federated access management. Most of this effort has > focused on two use cases: network access and web-based access. > However, the solutions to these use cases that have been proposed and > deployed tend to have few 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 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-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-abfab-arch-09 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From juanwei2012@gmail.com Mon Dec 9 18:25:00 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2068D1ADF48 for ; Mon, 9 Dec 2013 18:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.126 X-Spam-Level: X-Spam-Status: No, score=0.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FRT_LOLITA1=1.865, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FRT_LOLITA1=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tbCTgc9pqtSF for ; Mon, 9 Dec 2013 18:24:58 -0800 (PST) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 53A111AE029 for ; Mon, 9 Dec 2013 18:24:58 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id jt11so6610976pbb.36 for ; Mon, 09 Dec 2013 18:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:mime-version:message-id:content-type; bh=QWHOD+ka07Rs2zlc8k59Y7e1X2eUrAmWUe5Mm0X2tMU=; b=m2dUxwKjz/byhO7ZBtXSxEjj+hXVb/oZXPA4541I7KCW8IWiKYzuEx/7Z4Wlbr8C1q gYT871jnYBgmzXsRLURMk/RgTrfL5XxH5p/Bjv8BD2/afONNa8GSeA8wboQYfar2FnUI k78Kw5VHMuqyxOMBbPmH2Nn1eSVqxCi8FUj6bVGZ4xM+6ecEBl7iDQr27V8fqZgJjhYu 7WJ/J53TZEnv6kZOkSFjLQ12es7wZuX9hLGOjWP3rSrOOTVGUJklAAv0yht7+dLpkWxO ZDodR1f3DbE7jVAEBQCa4a9rt/upZo8QUnszQHq68cUE41gVmECVohyZZ3UctotlJvG+ QtYg== X-Received: by 10.66.161.38 with SMTP id xp6mr8288571pab.145.1386642293369; Mon, 09 Dec 2013 18:24:53 -0800 (PST) Received: from PC-201303222330 (openid.szu.edu.cn. [210.39.14.237]) by mx.google.com with ESMTPSA id xs1sm29846081pac.7.2013.12.09.18.24.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Dec 2013 18:24:52 -0800 (PST) Date: Tue, 10 Dec 2013 10:24:49 +0800 From: "Jeanne Wei" To: abfab X-Priority: 3 X-GUID: 63C00239-C605-4055-BC36-568A3547A722 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <201312101024453573296@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart081431153425_=----" Subject: [abfab] Fw: New Version Notification for draft-wei-abfab-differentiation-authn-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 02:25:00 -0000 This is a multi-part message in MIME format. ------=_001_NextPart081431153425_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpIZXJlIGlzIGEgZHJhZnQgb2YgZGlmZmVyZW50aWF0aW9uIGF1dGhlbnRpY2F0 aW9uIGZvciBhYmZhYi4NClBsZWFzZSBraW5kbHkgcmV2aWV3IGFuZCBmZWVsIGZyZWUgdG8gZ2l2 ZSB1cyBhbnkgY29tbWVudHMuIFRoYW5rIHlvdSBpbiBhZHZhbmNlLg0KDQpKZWFubmUuDQoNCg0K SmVhbm5lIEouIFdlaQ0KU2hlbnpoZW4gVW5pdmVyc2l0eSwgQ2hpbmENCk1vYmlsZTorODYgMTM3 NTEwMzk0NTQNCkUtbWFpbDpqdWFud2VpMjAxMkBnbWFpbC5jb20NCg0KDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHMNCkRhdGU6IDIwMTMtMTItMTAgMTA6MTENClRvOiBKdWFuIFdlaTsganVhbndlaTIw MTJAZ21haWwuY29tOyBKdW4gWmhhbmc7IEppYW55b25nIENoZW4NClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2VpLWFiZmFiLWRpZmZlcmVudGlhdGlvbi1hdXRo bi0wMC50eHQNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdlaS1hYmZhYi1kaWZmZXJl bnRpYXRpb24tYXV0aG4tMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IEp1YW4gV2VpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1l OiBkcmFmdC13ZWktYWJmYWItZGlmZmVyZW50aWF0aW9uLWF1dGhuDQpSZXZpc2lvbjogMDANClRp dGxlOiBEaWZmZXJlbnRpYXRpb24gYXV0aGVudGljYXRpb24gZm9yIEFCRkFCDQpDcmVhdGlvbiBk YXRlOiAyMDEzLTEyLTEwDQpHcm91cDogSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2Yg cGFnZXM6IDEwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXdlaS1hYmZhYi1kaWZmZXJlbnRpYXRpb24tYXV0aG4tMDAudHh0DQpTdGF0 dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2VpLWFi ZmFiLWRpZmZlcmVudGlhdGlvbi1hdXRobg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWktYWJmYWItZGlmZmVyZW50aWF0aW9uLWF1dGhuLTAwDQoN Cg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdG8gaW1wbGVtZW50 IHRoZSBkaWZmZXJlbnRpYXRpb24NCiAgIGF1dGhlbnRpY2F0aW9uIHdpdGggTGV2ZWwgb2YgQXNz dXJhbmNlIChMT0EpLiBJbiBvcmRlciB0byBhY2hpZXZlDQogICB0aGUgZ29hbCwgd2UgZGVmaW5l IGEgbmV3IGF1dGhlbnRpY2F0aW9uIGNvbnRleHQgY2xhc3Mgc2NoZW1hIGZvcg0KICAgU0FNTCBW Mi4wIHdoaWNoIGlzIHVzZWQgdG8gc3BlY2lmeSB0aGUgTE9BIHJlcXVpcmVtZW50IG9mIFJlbHlp bmcNCiAgIFByb3ZpZGVyIChSUCksIGEgZnVuY3Rpb24gd2hpY2ggaXMgdXNlZCBieSBJZGVudGl0 eSBQcm92aWRlciAoSWRQKQ0KICAgdG8gdHJhbnNmb3JtIHRoZSByZXF1aXJlZCBMT0EgdG8gc3Bl Y2lmaWMgYXV0aGVudGljYXRpb24gbWV0aG9kKHMpLA0KICAgYW5kIGEgcHJvZmlsZSB3aGljaCBk ZXNjcmliZXMgdGhlIGFwcGxpY2F0aW9uIG9mIHRoaXMgbmV3DQogICBhdXRoZW50aWNhdGlvbiBj b250ZXh0Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhh dCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlz c2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ= ------=_001_NextPart081431153425_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi all,
 
Here is a draft of differentiation= =20 authentication for abfab.
Please kindly review and feel free to g= ive us=20 any comments. Thank you in advance.
 
Jeanne.
Jeanne J. Wei
Shenzhen University, China
Mobile:+86 13751039454
 
 
From: internet-drafts
Date: 2013-12-10 10:11
To: Juan Wei= ; juanwei2012@gmail.com; Jun Zhang; Jianyong Chen
Subject: New Version Notification for=20 draft-wei-abfab-differentiation-authn-00.txt
 
A new version of I-D, draft-wei-abfab-differentiation-authn-00.txt
has been successfully submitted by Juan Wei and posted to the
IETF repository.
 
Filename: draft-wei-abfab-differentiation-authn
Revision: 00
Title: Differentiation authentication for ABFAB
Creation date: 2013-12-10
Group: Individual Submission
Number of pages: 10
URL:           = ; =20 http://www.ietf.org/internet-drafts/draft-wei-abfab-differ= entiation-authn-00.txt
Status:          http://datatracker.ietf.org/doc/draft-wei-abfab-differentiation-authn=
Htmlized:        http://tools.ietf.org/html/draft-wei-abfab-differentiation-authn-00=
 
 
Abstract:
   This document describes how to implement the=20 differentiation
   authentication with Level of Assurance (LOA). In order t= o=20 achieve
   the goal, we define a new authentication context class s= chema=20 for
   SAML V2.0 which is used to specify the LOA requirement o= f=20 Relying
   Provider (RP), a function which is used by Identity Prov= ider=20 (IdP)
   to transform the required LOA to specific authentication= =20 method(s),
   and a profile which describes the application of this=20 new
   authentication context.
 
           &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;       =20
 
 
Please note that it may take a couple of minutes from the time of=20 submission
until the htmlized version and diff are available at tools.ietf.org.<= /DIV>
 
The IETF Secretariat
 
------=_001_NextPart081431153425_=------ From hartmans@painless-security.com Tue Dec 10 07:27:23 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E5F1ADF8B for ; Tue, 10 Dec 2013 07:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFqVT-mb_dGl for ; Tue, 10 Dec 2013 07:27:22 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 59A5D1ADC03 for ; Tue, 10 Dec 2013 07:27:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9FA45205D8; Tue, 10 Dec 2013 10:26:07 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSHh6p4muqvI; Tue, 10 Dec 2013 10:26:07 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 10 Dec 2013 10:26:07 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 413AB91398; Tue, 10 Dec 2013 10:27:16 -0500 (EST) From: Sam Hartman To: "Jeanne Wei" References: <201312101024453573296@gmail.com> Date: Tue, 10 Dec 2013 10:27:16 -0500 In-Reply-To: <201312101024453573296@gmail.com> (Jeanne Wei's message of "Tue, 10 Dec 2013 10:24:49 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab Subject: Re: [abfab] Fw: New Version Notification for draft-wei-abfab-differentiation-authn-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 15:27:23 -0000 Initial comments. In section 4. If you intend this to work with ABFAB, the SAML profile defined in draft-ietf-abfab-aaa-saml is probably a better basis than the web SSO SAML profile. If you think Web SSO is still a better basis then adding text explaining why would be helpful. Section 3: The explanation of the e parameter is more clear. I think we may need more experience to determine whether the parameters to the transform function are correct, but the current draft is much more clear about what you're trying to accomplish than the previous draft. --Sam From juanwei2012@gmail.com Tue Dec 10 19:00:48 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBEB1AE102 for ; Tue, 10 Dec 2013 19:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdp2l5Ya8p6D for ; Tue, 10 Dec 2013 19:00:46 -0800 (PST) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 378581AE112 for ; Tue, 10 Dec 2013 19:00:45 -0800 (PST) Received: by mail-pb0-f52.google.com with SMTP id uo5so9072839pbc.11 for ; Tue, 10 Dec 2013 19:00:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:references:in-reply-to:mime-version :message-id:content-type; bh=dwnEVE52EY1EdN+3KioxrSGFfQC55YyNUzNFi5NWWvI=; b=QFlywO7ZARS8kcav05dQAATtisz/GYV/TjOwsQJ+awUUOlUVQcM3BTDHXYZlf71bq5 fQ2U2tuNtWP3m5MwX7IsSOaXMyzpAnxJPZ2pu1atftlSnKYZvS/CDQEg53A4lbzCMe/o 8GSmeZw0Anhv/xwJBjTOHVBcdFmYlJsq6EOct1po9Z0/nyeSrjd1k1tQNZRbw2BLAjdb KXNXfO9iw/qxWnyO+CvhTkx1xqdLvsZ8YPJ2bSDIiEr+oGgvo7iVLiNXt2mYX2WxKoVG 5EOZUyYnO+RgKdGAtRMAwaq/nZk6GArHeUBSKe6U3n9rShTcmUIHCO0WGn6boaKr5IwA jVhw== X-Received: by 10.68.194.71 with SMTP id hu7mr31430149pbc.68.1386730839969; Tue, 10 Dec 2013 19:00:39 -0800 (PST) Received: from PC-201303222330 ([183.14.156.106]) by mx.google.com with ESMTPSA id ql10sm28939285pbc.44.2013.12.10.19.00.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Dec 2013 19:00:39 -0800 (PST) From: "Jeanne Wei" To: "Sam Hartman" Date: Wed, 11 Dec 2013 11:00:33 +0800 References: <201312101024453573296@gmail.com>, In-Reply-To: <201312101024453573296@gmail.com> (Jeanne Wei's message of "Tue, 10 Dec 2013 10:24:49 +0800") X-Priority: 3 X-GUID: 37DB2412-9954-4F60-BF78-AE4DC23E252D X-Has-Attach: no X-Mailer: Foxmail 7, 1, 3, 52[cn] Mime-Version: 1.0 Message-ID: <201312111100258889877@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart636521847526_=----" Cc: abfab Subject: Re: [abfab] Fw: New Version Notification for draft-wei-abfab-differentiation-authn-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 03:00:48 -0000 This is a multi-part message in MIME format. ------=_001_NextPart636521847526_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5pdGlhbCBjb21tZW50cy4NCg0KSW4gc2VjdGlvbiA0LiAgSWYgeW91IGludGVuZCB0aGlzIHRv IHdvcmsgd2l0aCBBQkZBQiwgdGhlIFNBTUwgcHJvZmlsZQ0KZGVmaW5lZCBpbiBkcmFmdC1pZXRm LWFiZmFiLWFhYS1zYW1sIGlzIHByb2JhYmx5IGEgYmV0dGVyIGJhc2lzIHRoYW4gdGhlDQp3ZWIg U1NPIFNBTUwgcHJvZmlsZS4NCklmIHlvdSB0aGluayBXZWIgU1NPIGlzIHN0aWxsIGEgYmV0dGVy IGJhc2lzICB0aGVuIGFkZGluZyB0ZXh0DQpleHBsYWluaW5nIHdoeSB3b3VsZCBiZSBoZWxwZnVs Lg0KDQpTZWN0aW9uIDM6DQpUaGUgZXhwbGFuYXRpb24gb2YgdGhlIGUgcGFyYW1ldGVyIGlzIG1v cmUgY2xlYXIuDQpJIHRoaW5rIHdlIG1heSBuZWVkIG1vcmUgZXhwZXJpZW5jZSB0byBkZXRlcm1p bmUgd2hldGhlciB0aGUgcGFyYW1ldGVycw0KdG8gdGhlIHRyYW5zZm9ybSBmdW5jdGlvbiBhcmUg Y29ycmVjdCwgYnV0IHRoZSBjdXJyZW50IGRyYWZ0IGlzIG11Y2gNCm1vcmUgY2xlYXIgYWJvdXQg d2hhdCB5b3UncmUgdHJ5aW5nIHRvIGFjY29tcGxpc2ggdGhhbiB0aGUgcHJldmlvdXMNCmRyYWZ0 Lg0KDQotLVNhbQ0K ------=_001_NextPart636521847526_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Sam=EF=BC=8C
First=EF=BC=8C thank you for your comments.
> In section 4.  If you intend this to work with ABFAB, the S= AML profile
> defined in draft-ietf-abfab-aaa-saml is probably a better basis = than the
> web SSO SAML profile.
> If you think Web SSO is still a better basis  then adding t= ext
> explaining why would be helpful.
We do intend this to work with ABFAB. When writing this draft, we&nbs= p; ignore this. So we will modify this in next version.
> Section 3:
> The explanation of the e parameter is more clear.
> I think we may need more experience to determine whether the par= ameters
> to the transform function are correct, but the current draft is = much
> more clear about what you're trying to accomplish than the previ= ous
> draft.
We have thought about this, too. In the further research, we will pro= vide a specific scenario to explain how to use those parameters with the t= ransform function in the form of appendix or other ways.
Jeanne.
 
Jeanne J. Wei
Shenzhen University, China
Mobile:+86 13751039454
 
 
Date: 2013-12-10 23:27
Subject: Re: [abfab] Fw: New Version Notification for dra= ft-wei-abfab-differentiation-authn-00.txt
Initial comments.
 
In section 4.  If you intend this to work with ABFAB, the SAML p= rofile
defined in draft-ietf-abfab-aaa-saml is probably a better basis than = the
web SSO SAML profile.
If you think Web SSO is still a better basis  then adding text
explaining why would be helpful.
 
Section 3:
The explanation of the e parameter is more clear.
I think we may need more experience to determine whether the paramete= rs
to the transform function are correct, but the current draft is much<= /DIV>
more clear about what you're trying to accomplish than the previous
draft.
 
--Sam
------=_001_NextPart636521847526_=------ From stephen.farrell@cs.tcd.ie Mon Dec 16 08:29:04 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C741AE351 for ; Mon, 16 Dec 2013 08:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lw9Xc0yBOMU7 for ; Mon, 16 Dec 2013 08:29:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D5A281AE2F5 for ; Mon, 16 Dec 2013 08:29:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E99A9BE61 for ; Mon, 16 Dec 2013 16:29:00 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31MFbnGHYy1f for ; Mon, 16 Dec 2013 16:29:00 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C6F0CBE5F for ; Mon, 16 Dec 2013 16:29:00 +0000 (GMT) Message-ID: <52AF2A4C.5000304@cs.tcd.ie> Date: Mon, 16 Dec 2013 16:29:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] AD review of draft-ietf-abfab-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:29:04 -0000 Hiya, Thanks for a useful document! I have a few things I'd like to check with the WG before starting IETF LC and a bunch of nits (which can be fixed whenever). I'm not sure if the non-nits will result in changes being needed before IETF LC, but wanted to raise them and will follow the WG chairs' conclusions as to whether a new draft is better or not. Thanks, S. non-nits: (1) Am I reading this right? 4.2.2 says: "The EAP MSK is transported between the IdP and the RP over the AAA infrastructure, for example through RADIUS headers. This is a particularly important privacy consideration, as any AAA Proxy that has access to the EAP MSK is able to decrypt and eavesdrop on any traffic encrypted using that EAP MSK (i.e. all communications between the Client and IdP)." Does that mean that if a client authenticates with a password say, then that password could be read after the fact by any RP or AAA proxy involved in the transaction. Wouldn't that be unacceptable, if e.g. the equivalent of web-bugs or trackers could be inserted into a UI so as to get first-shot before a user has authenticated? And that seems to contradict step 7 in 1.4 unless those messages also go via the RP, which is not shown in the diagram in 1.4. What am I missing? (2) Aside from (1) above, do you need to highlight the issue with MSK leakage more prominently? 6614 is experimental and probably not that widely deployed, so this may be a significant issue. While it will be ok for some applications and will be better than not getting access whilst e.g. roaming, an eduroam user or institution might or might not be happy that a given application (say exam marking) could be vulnerable in this way. And if ABFAB were to be adopted by telcos, then given their history, and the reported lack of deployment of Diameter security, (for which I wish I had a good reference), I think the potential issues with pervasive monitoring that this could create might then be problematic. In 2.1.5, modifying proxies seem to be given similar powers to someone to whom the MSK leaks, and so are probably similarly relevant here. The definition of mutual auth in 3.1 also seems to skirt around this by saying that the initiator and acceptor have the same key but by not saying that nobody else (except an IdP or key server) should know that key. However, I'm not sure where or how handling this would best be done. Has the WG considered that? (I'm not insisting on a super-great answer here, just checking and wondering if more needs to be said.) (3) How should this portray the ABFAB work on Diameter? It seems like that is not going to happen, but 2.1 refers to it as a work-in-progress (without an I-D to reference). I think it'd be better if this document said that Diameter could be used and would work with this architecture but that RADIUS is what is being used. Then you'd tweak the references to Diameter a bit. (4) ABFAB puts together a bunch of generic technologies in a way that can work to allow cool new stuff to be done, which is great. However, it also creates concerns that if I put that same bunch of technologies together in other ways, which is possible, the results might be less good, security-wise or interop-wise. Reading the 3rd last para on page 22 ("The RAIDUS SAML RFC...") highlights this for me. Should something be said about how robust or brittle a system conforming to the ABFAB architecture might be when other variations of these technologies are chosen or considered? If you say, "nope, its fine," I'll buy that and if someone thinks its not fine they can make an IETF LC comment. (5) You mention "the trust router" protocol in various places (some noted as nits, but e.g. 1.2). We don't know if there will be zero or one or more of those (and there's no citation). I think you should maybe fix those so as not to create an apparent dependency on something that's not an agreed piece of IETF work. (6) 1.2: "legal rules" seems wrong, I think you mean non-technical contractual agreements. I'd prefer if the word "legal" was never used as it might be interpreted very differently by different readers in different jurisdictions. In some places, it might have a connotation that the Government say its illegal to not do this, or that its illegal to try access an RP to which you're not authorized or something. Better to avoid that. (This is almost, but not quite, a nit.) (7) 4.x - is there a missing section here about the relationships between different RPs in the same or different realms? To what extent can they cheat on one another, with the various options that exist? nits: abstract: "work has occurred" is passive voice abstract: "common building blocks in common" is odd abstract: Is "GSS" right? I've seen GS2 and GSS-API before but not GSS. intro: "Internet uses ... mechanisms" seems wrong, the IETF (and others) define mechanisms and operators deploy those intro: "This delegation requires technical signaling, trust and a common understanding of semantics between the RP and IdP." I hate to see unqualified uses of the term "trust" but it might be ok here I guess. If its possible to say more about who's trusting whom for what here that'd be better though. intro: Doesn't federated anything really require there to be >1 IdP? If so, why not say so? intro: "Simplified Sign-On" is a new one to me and sounds like a marketing term, if so, it'd be better left out intro: Is the indentation right for "Data minimization.." intro: The last para before 1.1 claims that this will scale to large numbers of everything - is there evidence of that? If not, then better to not make the unfounded claim. 1.1: Predicting problems readers will have is odd. 1.1.1: "provide" naming semantics seems wrong 1.1.1: typos: "mutualtion" "confiduatal" 1.1.1 last para: so I don't get this description. That's not helped by a couple of odd typos, but I think it'd be worth another look at this to try make it clearer. 1.2: "There is a direct relationship between the Client and the Identity Provider by which the entities trust and can securely authenticate each other." reads oddly to me. 1.3: "proliferating" federations seems a bit exaggerated. 1.3: "the use of SMTP and IMAP protocols do not have the ability for the server to get additional information" seems badly phrased. 1.4: step 2 - passive voice - who selects GSS-EAP? Or is that negotiated between client and RP? 1.4: step 5 - the RP only knows which IdP is claimed at this point, not which it "is" - better to clarify? 1.4: it'd be better if the figures were all numbered, the ladder diagram here is not 1.4: ladder diagram (11) spacing is broken 1.5, 1st bullet: s/of a transaction/in a transaction/ maybe better? 1.5, 2nd bullet: decoupled from what? 1.5, 3rd bullet: s/servers/RPs/ more accurate? 1.5, s/excitement/trend/ would be more neutral section 2, 3rd para: wording is not great, maybe s/for encapsulating/to encapsulate/ and s/the usage of// and s/a description of// would be better 2.1: May as well use IdP here and not "Identity Provider" 2.1, last sentence before 2.1.1: better to omit this or add a reference to something (doesn't have to be an I-D, a workshop paper or similar would be fine). 2.1.1: why "Interestingly"? I don't know why you told me that and it makes me wonder if some would claim that this was not successful. 2.1.1: "mileage" is an odd term here, smacks of sales-talk 2.1.1: s/a future document would/a future document could/ 2.1.2: s/criteria/criterion/g in 1st para after 1st bullet list 2.1.4, 1st para: Its mostly yukkie to end a sentence with a preposition like "of" :-) 2.1.4: s/have designed in/include/ 2.1.5: You say that it won't always be possible for an RP to verify a signature on an assertion. I think that was the subject of list discussion, but don't see that reflected here. Should you explain some more about why this is likely to be the case? The reader may wonder otherwise. 2.1.5: Saying "different namespaces assigned to the same name" reads oddly if you don't have SAML stuff at the front of your brain - maybe this could do with some more explanation for those who've forgotten SAML terminology? And maybe a reference to something that goes into the detail would be good too. 2.1.5: modifying proxies - why is it "obvious" that they'd remove signatures - wasn't that also the result of a list discussion that was not obvious? (And in principle the proxies could add to the assertion or add a new assertion or something, leaving the original verifiable.) 2.2.1: I don't get what "where Individuals can correctly identify the entire mechanism on the fly" might mean - can you explain or make it clear? 2.3.1: Wouldn't it be better to distinguish between those GSS-API using applications that are real vs. those where how to use GSS-API is well-defined, but never used? I think for example that 3645 is not really deployed (but correct me if I'm wrong). 2.3.1: Is "no required modifications" really true? While I might not have to modify application layer code, won't I probably have to write new packaging, do new testing and management etc? That's not free either. 2.3.2: s/privacy/confidentiality/ would be better 2.3.3: would s/server/RP/ be right here? If not, then maybe you 3.1, 2nd para: maybe s/it/mutual authentication/ would be better just before the bullets 3.1, last sentence: Be good to add a reference to the anonymous return flag so someone can go figure out what that means in more detail. I just mean a section number of whatever RFC defines this. 3.2: I guess add a ref to 5246 somewhere 3.3: I'm not sure if there are missing references here or if they've all been given earlier - be good to check e.g. are all the RFCs for GSS-API for foo somewhere? And maybe DNSSEC and NAPTR etc are missing refs. 3.3: Is RFC 1964 right for kerberos/GSS or 4121? 3.4: Be nice to add refs for the non-IETF protocols that will use stuff in the near future. 4.1: s/can reside on any/can reside on any or all/ might be better, given recent news. You should also note that nodes might collude or be coerced into colluding. 4.1: Another missing ref to Trust Router. Maybe add ref or delete that. section 7: I wish we could get more comments from Bob Morgan. Makes me sad that we cannot. From hartmans@painless-security.com Mon Dec 16 08:48:33 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46EE01AE062 for ; Mon, 16 Dec 2013 08:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXAFR9eGhQgD for ; Mon, 16 Dec 2013 08:48:30 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C6FDF1ADF50 for ; Mon, 16 Dec 2013 08:48:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 8D0D0205DB; Mon, 16 Dec 2013 11:47:06 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SX4fcZfvMG_A; Mon, 16 Dec 2013 11:47:06 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 16 Dec 2013 11:47:06 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC9A082862; Mon, 16 Dec 2013 11:48:28 -0500 (EST) From: Sam Hartman To: Stephen Farrell References: <52AF2A4C.5000304@cs.tcd.ie> Date: Mon, 16 Dec 2013 11:48:28 -0500 In-Reply-To: <52AF2A4C.5000304@cs.tcd.ie> (Stephen Farrell's message of "Mon, 16 Dec 2013 16:29:00 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "" Subject: Re: [abfab] AD review of draft-ietf-abfab-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 16:48:33 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> (1) Am I reading this right? 4.2.2 says: "The EAP MSK is Stephen> transported between the IdP and the RP over the AAA Stephen> infrastructure, for example through RADIUS headers. This Stephen> is a particularly important privacy consideration, as any Stephen> AAA Proxy that has access to the EAP MSK is able to decrypt Stephen> and eavesdrop on any traffic encrypted using that EAP MSK Stephen> (i.e. all communications between the Client and IdP)." Does Stephen> that mean that if a client authenticates with a password Stephen> say, then that password could be read after the fact by any Stephen> RP or AAA proxy involved in the transaction. Wouldn't that Stephen> be unacceptable, if e.g. the equivalent of web-bugs or Stephen> trackers could be inserted into a UI so as to get Stephen> first-shot before a user has authenticated? And that seems Stephen> to contradict step 7 in 1.4 unless those messages also go Stephen> via the RP, which is not shown in the diagram in 1.4. What Stephen> am I missing? Fortunately, I think you're reading this slightly wrong. Learning the MSK is not sufficient to snoop on traffic between the peer/client and IDP. Only on traffic between the peer/client AND RP. The issue is that if the peer-client use the MSK to encrypt traffic say using the GSS per-message services or the GSS PRF, that an attacker who learns the MSK can decrypt that traffic. They should not (and with EAP methods that are typically used are believed to be unable to) learn keys needed to observe the authentication conversation between peer/client and IDP. honestly, I consider proxies being able to observe session traffic to be quite bad from a perpass standpoint, thus my interest in adding DH between client/peer and RP. From stephen.farrell@cs.tcd.ie Mon Dec 16 09:31:41 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E681ADFE6 for ; Mon, 16 Dec 2013 09:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN3ZnC3Ujnfc for ; Mon, 16 Dec 2013 09:31:37 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ABF581ADFD5 for ; Mon, 16 Dec 2013 09:31:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B5A3BE4C; Mon, 16 Dec 2013 17:31:36 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W1khnACFBP2; Mon, 16 Dec 2013 17:31:36 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49670BE5D; Mon, 16 Dec 2013 17:31:32 +0000 (GMT) Message-ID: <52AF38F4.2000407@cs.tcd.ie> Date: Mon, 16 Dec 2013 17:31:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sam Hartman References: <52AF2A4C.5000304@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [abfab] AD review of draft-ietf-abfab-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:31:41 -0000 Hi Sam, On 12/16/2013 04:48 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > > Stephen> (1) Am I reading this right? 4.2.2 says: "The EAP MSK is > Stephen> transported between the IdP and the RP over the AAA > Stephen> infrastructure, for example through RADIUS headers. This > Stephen> is a particularly important privacy consideration, as any > Stephen> AAA Proxy that has access to the EAP MSK is able to decrypt > Stephen> and eavesdrop on any traffic encrypted using that EAP MSK > Stephen> (i.e. all communications between the Client and IdP)." Does > Stephen> that mean that if a client authenticates with a password > Stephen> say, then that password could be read after the fact by any > Stephen> RP or AAA proxy involved in the transaction. Wouldn't that > Stephen> be unacceptable, if e.g. the equivalent of web-bugs or > Stephen> trackers could be inserted into a UI so as to get > Stephen> first-shot before a user has authenticated? And that seems > Stephen> to contradict step 7 in 1.4 unless those messages also go > Stephen> via the RP, which is not shown in the diagram in 1.4. What > Stephen> am I missing? > > Fortunately, I think you're reading this slightly wrong. > Learning the MSK is not sufficient to snoop on traffic between the > peer/client and IDP. > Only on traffic between the peer/client AND RP. > > The issue is that if the peer-client use the MSK to encrypt traffic say > using the GSS per-message services or the GSS PRF, that an attacker who > learns the MSK can decrypt that traffic. They should not (and with EAP > methods that are typically used are believed to be unable to) learn keys > needed to observe the authentication conversation between peer/client > and IDP. > > honestly, I consider proxies being able to observe session traffic to be > quite bad from a perpass standpoint, thus my interest in adding DH > between client/peer and RP. So when the text says "(i.e. all communications between the Client and IdP)" I don't get what that means. Is it just a typo maybe? S. > > From hartmans@painless-security.com Mon Dec 16 09:39:25 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1434E1AE097 for ; Mon, 16 Dec 2013 09:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A03GMc8GLlYF for ; Mon, 16 Dec 2013 09:39:23 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 203A01AE027 for ; Mon, 16 Dec 2013 09:39:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id F0B71205E5; Mon, 16 Dec 2013 12:37:58 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzk61VnXCLH0; Mon, 16 Dec 2013 12:37:57 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 16 Dec 2013 12:37:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4171B82862; Mon, 16 Dec 2013 12:39:20 -0500 (EST) From: Sam Hartman To: Stephen Farrell References: <52AF2A4C.5000304@cs.tcd.ie> <52AF38F4.2000407@cs.tcd.ie> Date: Mon, 16 Dec 2013 12:39:20 -0500 In-Reply-To: <52AF38F4.2000407@cs.tcd.ie> (Stephen Farrell's message of "Mon, 16 Dec 2013 17:31:32 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "" Subject: Re: [abfab] AD review of draft-ietf-abfab-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:39:25 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> So when the text says "(i.e. all communications between the Stephen> Client and IdP)" I don't get what that means. Is it just a Stephen> typo maybe? O, I thought the I.E. was added by you. Yes, that's just wrong. Sorry I missed that on my review pass. From stephen.farrell@cs.tcd.ie Mon Dec 16 09:40:47 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D3A1AE0B7 for ; Mon, 16 Dec 2013 09:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Riim8lv5hhS for ; Mon, 16 Dec 2013 09:40:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 70D361AE027 for ; Mon, 16 Dec 2013 09:40:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 80B05BE59; Mon, 16 Dec 2013 17:40:44 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAkKqNKVZ8hk; Mon, 16 Dec 2013 17:40:44 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 614FDBE55; Mon, 16 Dec 2013 17:40:44 +0000 (GMT) Message-ID: <52AF3B1C.7000802@cs.tcd.ie> Date: Mon, 16 Dec 2013 17:40:44 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sam Hartman References: <52AF2A4C.5000304@cs.tcd.ie> <52AF38F4.2000407@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [abfab] AD review of draft-ietf-abfab-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Dec 2013 17:40:47 -0000 On 12/16/2013 05:39 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > > Stephen> So when the text says "(i.e. all communications between the > Stephen> Client and IdP)" I don't get what that means. Is it just a > Stephen> typo maybe? > > O, I thought the I.E. was added by you. > Yes, that's just wrong. > Sorry I missed that on my review pass. Ah good. That sorts that one. Probably worth fixing before IETF LC as it might also confuse others. S From ietf@augustcellars.com Mon Dec 16 21:49:03 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDDA1AE0A9 for ; Mon, 16 Dec 2013 21:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xxKyXBvFxFD for ; Mon, 16 Dec 2013 21:49:00 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9F55C1AE0C1 for ; Mon, 16 Dec 2013 21:49:00 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id A949438F03; Mon, 16 Dec 2013 21:48:59 -0800 (PST) From: "Jim Schaad" To: "'Stephen Farrell'" , References: <52AF2A4C.5000304@cs.tcd.ie> In-Reply-To: <52AF2A4C.5000304@cs.tcd.ie> Date: Mon, 16 Dec 2013 21:47:30 -0800 Message-ID: <027c01cefaeb$79b97960$6d2c6c20$@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: AQHbFbFJUK6EilN9jPkcKsvDJq+iOZo/SPSw Content-Language: en-us Subject: Re: [abfab] AD review of draft-ietf-abfab-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 05:49:04 -0000 Try and get my thoughts down before my mind crashes today. > -----Original Message----- > From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Monday, December 16, 2013 8:29 AM > To: > Subject: [abfab] AD review of draft-ietf-abfab-arch-09 > > > Hiya, > > Thanks for a useful document! > > I have a few things I'd like to check with the WG before starting IETF LC and a > bunch of nits (which can be fixed whenever). > > I'm not sure if the non-nits will result in changes being needed before IETF > LC, but wanted to raise them and will follow the WG chairs' conclusions as to > whether a new draft is better or not. > > Thanks, > S. > > non-nits: > > (1) Am I reading this right? 4.2.2 says: "The EAP MSK is transported between > the IdP and the RP over the AAA infrastructure, for example through RADIUS > headers. This is a particularly important privacy consideration, as any AAA > Proxy that has access to the EAP MSK is able to decrypt and eavesdrop on > any traffic encrypted using that EAP MSK (i.e. all communications between > the Client and IdP)." Does that mean that if a client authenticates with a > password say, then that password could be read after the fact by any RP or > AAA proxy involved in the transaction. Wouldn't that be unacceptable, if e.g. > the equivalent of web-bugs or trackers could be inserted into a UI so as to > get first-shot before a user has authenticated? And that seems to contradict > step 7 in > 1.4 unless those messages also go via the RP, which is not shown in the > diagram in 1.4. What am I missing? As noted by Sam, this is just wrong text. However to address the rest of the questions here: All traffic between the client and the IdP are routed through the RP. This means that if you are using a password based EAP method without having a tunnel as part of it, the password is going to be available to the RP and all of the AAA routing structure to read. If you look at Figure 2, then you see all of the messages traveling via the RP. >From the point of view of EAP and the MSK however, a password would never be protected by the MSK as this is created after the password is validated and thus could never protect the password to begin with. It would be used to protect data sent back and forth after the password has been validated. Proposed changes: 1. In the figure of section 1.4 - s/Between Client App and IdP/Between Client App and IdP (via RP)/ 2. In section 4.2.2 s/(i.e. all communications between the Client and the IdP)./(i.e., all communications between the Client and the RP). This problem can be mitigated by applications setting up a tunnel between the Client and the RP and performing a cryptographic binding between the tunnel and the MSK./ > > (2) Aside from (1) above, do you need to highlight the issue with MSK > leakage more prominently? 6614 is experimental and probably not that > widely deployed, so this may be a significant issue. While it will be ok for > some applications and will be better than not getting access whilst e.g. > roaming, an eduroam user or institution might or might not be happy that a > given application (say exam marking) could be vulnerable in this way. And if > ABFAB were to be adopted by telcos, then given their history, and the > reported lack of deployment of Diameter security, (for which I wish I had a > good reference), I think the potential issues with pervasive monitoring that > this could create might then be problematic. In 2.1.5, modifying proxies > seem to be given similar powers to someone to whom the MSK leaks, and so > are probably similarly relevant here. The definition of mutual auth in 3.1 also > seems to skirt around this by saying that the initiator and acceptor have the > same key but by not saying that nobody else (except an IdP or key server) > should know that key. > However, I'm not sure where or how handling this would best be done. Has > the WG considered that? (I'm not insisting on a super-great answer here, > just checking and wondering if more needs to be said.) 6614 is experimental, but there are efforts to put it onto standards track. >From my understanding, it is implemented in most of the major RADIUS implementations. I am not sure what the status of deployment is on this. The fact that there is a draft to help with doing lookup in the RADEXT group would indicate that there are some issues to getting it out for large deployments. However I am not sure that there is anything that we can really say or do to address this issue directly. I think that the mitigation text that I have suggested above will help in addressing the MSK leak as it gives a way to avoid letting entities do the eaves dropping, it is a much more active attack for an entity to decide to replace the RP and get the information in that stream. The problem of monitoring what goes across the backbone is a larger problem than we can address. We have recommended that EAP-TLS be used to reduce the amount of material that can be leaked in terms of the EAP conversations. This would address both RADIUS and Diameter in terms of client/IdP but do nothing about the RP/IdP data. I don't know of any way to fix that except to do point to point security on the backbone (or go direct with something like a trust router). I am not sure that there is anything to be added to the document at this point. > > (3) How should this portray the ABFAB work on Diameter? > It seems like that is not going to happen, but 2.1 refers to it as a work-in- > progress (without an I-D to reference). I think it'd be better if this document > said that Diameter could be used and would work with this architecture but > that RADIUS is what is being used. Then you'd tweak the references to > Diameter a bit. I think that this makes sense to do. It should be a couple of easy changes - I'll try and look at this over the next day or two. > > (4) ABFAB puts together a bunch of generic technologies in a way that can > work to allow cool new stuff to be done, which is great. However, it also > creates concerns that if I put that same bunch of technologies together in > other ways, which is possible, the results might be less good, security-wise or > interop-wise. Reading the 3rd last para on page 22 ("The RAIDUS SAML > RFC...") highlights this for me. Should something be said about how robust or > brittle a system conforming to the ABFAB architecture might be when other > variations of these technologies are chosen or considered? If you say, "nope, > its fine," I'll buy that and if someone thinks its not fine they can make an IETF > LC comment. I would rather not try and do this. To do it in a semi-exhaustive method would be both time consuming and require that we basically describe other ways the pieces could be fit together badly. > > (5) You mention "the trust router" protocol in various places (some noted as > nits, but e.g. 1.2). We don't know if there will be zero or one or more of > those (and there's no citation). I think you should maybe fix those so as not > to create an apparent dependency on something that's not an agreed piece > of IETF work. Currently the phrase "router" is used in two places. Section 1.2 and section 4.1. Oddly enough, the same concept is called a Trust Broker in section 2.1.3. Would you have the same feelings about the term Trust Router if it was turned into Trust Broker (and pointed to section 2.1.3 then)? > > (6) 1.2: "legal rules" seems wrong, I think you mean non-technical contractual > agreements. I'd prefer if the word "legal" was never used as it might be > interpreted very differently by different readers in different jurisdictions. In > some places, it might have a connotation that the Government say its illegal > to not do this, or that its illegal to try access an RP to which you're not > authorized or something. Better to avoid that. > (This is almost, but not quite, a nit.) I have no opinion one way or the other on this issue. > > (7) 4.x - is there a missing section here about the relationships between > different RPs in the same or different realms? To what extent can they cheat > on one another, with the various options that exist? I have vague memories about thinking on this at the time I was trying to get this section figured out. However I don't think I came up with anything that I thought was worth nothing. I'll put it in the back of my brain for a couple of days. Jim > > nits: > > abstract: "work has occurred" is passive voice > > abstract: "common building blocks in common" is odd > > abstract: Is "GSS" right? I've seen GS2 and GSS-API before but not GSS. > > intro: "Internet uses ... mechanisms" seems wrong, the IETF (and others) > define mechanisms and operators deploy those > > intro: "This delegation requires technical signaling, trust and a common > understanding of semantics between the RP and IdP." I hate to see > unqualified uses of the term "trust" but it might be ok here I guess. If its > possible to say more about who's trusting whom for what here that'd be > better though. > > intro: Doesn't federated anything really require there to be >1 IdP? If so, why > not say so? > > intro: "Simplified Sign-On" is a new one to me and sounds like a marketing > term, if so, it'd be better left out > > intro: Is the indentation right for "Data minimization.." > > intro: The last para before 1.1 claims that this will scale to large numbers of > everything - is there evidence of that? If not, then better to not make the > unfounded claim. > > 1.1: Predicting problems readers will have is odd. > > 1.1.1: "provide" naming semantics seems wrong > > 1.1.1: typos: "mutualtion" "confiduatal" > > 1.1.1 last para: so I don't get this description. That's not helped by a couple of > odd typos, but I think it'd be worth another look at this to try make it clearer. > > 1.2: "There is a direct relationship between the Client and the Identity > Provider by which the entities trust and can securely authenticate each > other." reads oddly to me. > > 1.3: "proliferating" federations seems a bit exaggerated. > > 1.3: "the use of SMTP and IMAP protocols do not have the ability for the > server to get additional information" > seems badly phrased. > > 1.4: step 2 - passive voice - who selects GSS-EAP? Or is that negotiated > between client and RP? > > 1.4: step 5 - the RP only knows which IdP is claimed at this point, not which it > "is" - better to clarify? > > 1.4: it'd be better if the figures were all numbered, the ladder diagram here is > not > > 1.4: ladder diagram (11) spacing is broken > > 1.5, 1st bullet: s/of a transaction/in a transaction/ maybe better? > > 1.5, 2nd bullet: decoupled from what? > > 1.5, 3rd bullet: s/servers/RPs/ more accurate? > > 1.5, s/excitement/trend/ would be more neutral > > section 2, 3rd para: wording is not great, maybe s/for encapsulating/to > encapsulate/ and s/the usage of// and s/a description of// would be better > > 2.1: May as well use IdP here and not "Identity Provider" > > 2.1, last sentence before 2.1.1: better to omit this or add a reference to > something (doesn't have to be an I-D, a workshop paper or similar would be > fine). > > 2.1.1: why "Interestingly"? I don't know why you told me that and it makes > me wonder if some would claim that this was not successful. > > 2.1.1: "mileage" is an odd term here, smacks of sales-talk > > 2.1.1: s/a future document would/a future document could/ > > 2.1.2: s/criteria/criterion/g in 1st para after 1st bullet list > > 2.1.4, 1st para: Its mostly yukkie to end a sentence with a preposition like > "of" :-) > > 2.1.4: s/have designed in/include/ > > 2.1.5: You say that it won't always be possible for an RP to verify a signature > on an assertion. I think that was the subject of list discussion, but don't see > that reflected here. Should you explain some more about why this is likely to > be the case? The reader may wonder otherwise. > > 2.1.5: Saying "different namespaces assigned to the same name" reads oddly > if you don't have SAML stuff at the front of your brain - maybe this could do > with some more explanation for those who've forgotten SAML terminology? > And maybe a reference to something that goes into the detail would be good > too. > > 2.1.5: modifying proxies - why is it "obvious" that they'd remove signatures - > wasn't that also the result of a list discussion that was not obvious? (And in > principle the proxies could add to the assertion or add a new assertion or > something, leaving the original verifiable.) > > 2.2.1: I don't get what "where Individuals can correctly identify the entire > mechanism on the fly" might mean - can you explain or make it clear? > > 2.3.1: Wouldn't it be better to distinguish between those GSS-API using > applications that are real vs. those where how to use GSS-API is well- > defined, but never used? I think for example that 3645 is not really deployed > (but correct me if I'm wrong). > > 2.3.1: Is "no required modifications" really true? While I might not have to > modify application layer code, won't I probably have to write new packaging, > do new testing and management etc? That's not free either. > > 2.3.2: s/privacy/confidentiality/ would be better > > 2.3.3: would s/server/RP/ be right here? If not, then maybe you > > 3.1, 2nd para: maybe s/it/mutual authentication/ would be better just before > the bullets > > 3.1, last sentence: Be good to add a reference to the anonymous return flag > so someone can go figure out what that means in more detail. I just mean a > section number of whatever RFC defines this. > > 3.2: I guess add a ref to 5246 somewhere > > 3.3: I'm not sure if there are missing references here or if they've all been > given earlier - be good to check e.g. > are all the RFCs for GSS-API for foo somewhere? And maybe DNSSEC and > NAPTR etc are missing refs. > > 3.3: Is RFC 1964 right for kerberos/GSS or 4121? > > 3.4: Be nice to add refs for the non-IETF protocols that will use stuff in the > near future. > > 4.1: s/can reside on any/can reside on any or all/ might be better, given > recent news. You should also note that nodes might collude or be coerced > into colluding. > > 4.1: Another missing ref to Trust Router. Maybe add ref or delete that. > > section 7: I wish we could get more comments from Bob Morgan. Makes me > sad that we cannot. > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From stephen.farrell@cs.tcd.ie Tue Dec 17 01:58:27 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0039A1ADFD1 for ; Tue, 17 Dec 2013 01:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btOYrU6274h8 for ; Tue, 17 Dec 2013 01:58:22 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 01A431ADFB2 for ; Tue, 17 Dec 2013 01:58:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 799A6BE55; Tue, 17 Dec 2013 09:58:18 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgPxRtJ6se41; Tue, 17 Dec 2013 09:58:18 +0000 (GMT) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 54EE1BE51; Tue, 17 Dec 2013 09:58:18 +0000 (GMT) Message-ID: <52B0203A.1010309@cs.tcd.ie> Date: Tue, 17 Dec 2013 09:58:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Jim Schaad , abfab@ietf.org References: <52AF2A4C.5000304@cs.tcd.ie> <027c01cefaeb$79b97960$6d2c6c20$@augustcellars.com> In-Reply-To: <027c01cefaeb$79b97960$6d2c6c20$@augustcellars.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] AD review of draft-ietf-abfab-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 09:58:27 -0000 Hi Jim, On 12/17/2013 05:47 AM, Jim Schaad wrote: > Try and get my thoughts down before my mind crashes today. I hope it doesn't crash! :-) The trust broker/router thing is fairly minor, but if you can word it so that it reads less like the IETF are already planning to do stuff there, that'd be good. I don't expect that it'll be a deal for IETF LC (but who knows;-). Otherwise your answers look fine, thanks. I assume the plan will be to issue a new rev before IETF LC given the corrections for point 1? FWIW, I'd be fine if you just wanted to fix that and handle the rest of my comments as IETF LC comments if that helps get the new rev out more quickly. S. > >> -----Original Message----- >> From: abfab [mailto:abfab-bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Monday, December 16, 2013 8:29 AM >> To: >> Subject: [abfab] AD review of draft-ietf-abfab-arch-09 >> >> >> Hiya, >> >> Thanks for a useful document! >> >> I have a few things I'd like to check with the WG before starting IETF LC > and a >> bunch of nits (which can be fixed whenever). >> >> I'm not sure if the non-nits will result in changes being needed before > IETF >> LC, but wanted to raise them and will follow the WG chairs' conclusions as > to >> whether a new draft is better or not. >> >> Thanks, >> S. >> >> non-nits: >> >> (1) Am I reading this right? 4.2.2 says: "The EAP MSK is transported > between >> the IdP and the RP over the AAA infrastructure, for example through RADIUS >> headers. This is a particularly important privacy consideration, as any > AAA >> Proxy that has access to the EAP MSK is able to decrypt and eavesdrop on >> any traffic encrypted using that EAP MSK (i.e. all communications between >> the Client and IdP)." Does that mean that if a client authenticates with a >> password say, then that password could be read after the fact by any RP or >> AAA proxy involved in the transaction. Wouldn't that be unacceptable, if > e.g. >> the equivalent of web-bugs or trackers could be inserted into a UI so as > to >> get first-shot before a user has authenticated? And that seems to > contradict >> step 7 in >> 1.4 unless those messages also go via the RP, which is not shown in the >> diagram in 1.4. What am I missing? > > As noted by Sam, this is just wrong text. > > However to address the rest of the questions here: > > All traffic between the client and the IdP are routed through the RP. This > means that if you are using a password based EAP method without having a > tunnel as part of it, the password is going to be available to the RP and > all of the AAA routing structure to read. If you look at Figure 2, then you > see all of the messages traveling via the RP. > >>From the point of view of EAP and the MSK however, a password would never be > protected by the MSK as this is created after the password is validated and > thus could never protect the password to begin with. It would be used to > protect data sent back and forth after the password has been validated. > > Proposed changes: > > 1. In the figure of section 1.4 - s/Between Client App and IdP/Between > Client App and IdP (via RP)/ > > 2. In section 4.2.2 s/(i.e. all communications between the Client and the > IdP)./(i.e., all communications between the Client and the RP). This > problem can be mitigated by applications setting up a tunnel between the > Client and the RP and performing a cryptographic binding between the tunnel > and the MSK./ > >> >> (2) Aside from (1) above, do you need to highlight the issue with MSK >> leakage more prominently? 6614 is experimental and probably not that >> widely deployed, so this may be a significant issue. While it will be ok > for >> some applications and will be better than not getting access whilst e.g. >> roaming, an eduroam user or institution might or might not be happy that a >> given application (say exam marking) could be vulnerable in this way. And > if >> ABFAB were to be adopted by telcos, then given their history, and the >> reported lack of deployment of Diameter security, (for which I wish I had > a >> good reference), I think the potential issues with pervasive monitoring > that >> this could create might then be problematic. In 2.1.5, modifying proxies >> seem to be given similar powers to someone to whom the MSK leaks, and so >> are probably similarly relevant here. The definition of mutual auth in 3.1 > also >> seems to skirt around this by saying that the initiator and acceptor have > the >> same key but by not saying that nobody else (except an IdP or key server) >> should know that key. >> However, I'm not sure where or how handling this would best be done. Has >> the WG considered that? (I'm not insisting on a super-great answer here, >> just checking and wondering if more needs to be said.) > > 6614 is experimental, but there are efforts to put it onto standards track. >>From my understanding, it is implemented in most of the major RADIUS > implementations. I am not sure what the status of deployment is on this. > The fact that there is a draft to help with doing lookup in the RADEXT group > would indicate that there are some issues to getting it out for large > deployments. However I am not sure that there is anything that we can > really say or do to address this issue directly. > > I think that the mitigation text that I have suggested above will help in > addressing the MSK leak as it gives a way to avoid letting entities do the > eaves dropping, it is a much more active attack for an entity to decide to > replace the RP and get the information in that stream. > > The problem of monitoring what goes across the backbone is a larger problem > than we can address. We have recommended that EAP-TLS be used to reduce the > amount of material that can be leaked in terms of the EAP conversations. > This would address both RADIUS and Diameter in terms of client/IdP but do > nothing about the RP/IdP data. I don't know of any way to fix that except > to do point to point security on the backbone (or go direct with something > like a trust router). > > I am not sure that there is anything to be added to the document at this > point. > >> >> (3) How should this portray the ABFAB work on Diameter? >> It seems like that is not going to happen, but 2.1 refers to it as a > work-in- >> progress (without an I-D to reference). I think it'd be better if this > document >> said that Diameter could be used and would work with this architecture but >> that RADIUS is what is being used. Then you'd tweak the references to >> Diameter a bit. > > I think that this makes sense to do. It should be a couple of easy changes > - I'll try and look at this over the next day or two. > >> >> (4) ABFAB puts together a bunch of generic technologies in a way that can >> work to allow cool new stuff to be done, which is great. However, it also >> creates concerns that if I put that same bunch of technologies together in >> other ways, which is possible, the results might be less good, > security-wise or >> interop-wise. Reading the 3rd last para on page 22 ("The RAIDUS SAML >> RFC...") highlights this for me. Should something be said about how > robust or >> brittle a system conforming to the ABFAB architecture might be when other >> variations of these technologies are chosen or considered? If you say, > "nope, >> its fine," I'll buy that and if someone thinks its not fine they can make > an IETF >> LC comment. > > I would rather not try and do this. To do it in a semi-exhaustive method > would be both time consuming and require that we basically describe other > ways the pieces could be fit together badly. > > >> >> (5) You mention "the trust router" protocol in various places (some noted > as >> nits, but e.g. 1.2). We don't know if there will be zero or one or more of >> those (and there's no citation). I think you should maybe fix those so as > not >> to create an apparent dependency on something that's not an agreed piece >> of IETF work. > > Currently the phrase "router" is used in two places. Section 1.2 and section > 4.1. Oddly enough, the same concept is called a Trust Broker in section > 2.1.3. Would you have the same feelings about the term Trust Router if it > was turned into Trust Broker (and pointed to section 2.1.3 then)? > > >> >> (6) 1.2: "legal rules" seems wrong, I think you mean non-technical > contractual >> agreements. I'd prefer if the word "legal" was never used as it might be >> interpreted very differently by different readers in different > jurisdictions. In >> some places, it might have a connotation that the Government say its > illegal >> to not do this, or that its illegal to try access an RP to which you're > not >> authorized or something. Better to avoid that. >> (This is almost, but not quite, a nit.) > > I have no opinion one way or the other on this issue. > >> >> (7) 4.x - is there a missing section here about the relationships between >> different RPs in the same or different realms? To what extent can they > cheat >> on one another, with the various options that exist? > > I have vague memories about thinking on this at the time I was trying to get > this section figured out. However I don't think I came up with anything > that I thought was worth nothing. I'll put it in the back of my brain for a > couple of days. > > Jim > >> >> nits: >> >> abstract: "work has occurred" is passive voice >> >> abstract: "common building blocks in common" is odd >> >> abstract: Is "GSS" right? I've seen GS2 and GSS-API before but not GSS. >> >> intro: "Internet uses ... mechanisms" seems wrong, the IETF (and others) >> define mechanisms and operators deploy those >> >> intro: "This delegation requires technical signaling, trust and a common >> understanding of semantics between the RP and IdP." I hate to see >> unqualified uses of the term "trust" but it might be ok here I guess. If > its >> possible to say more about who's trusting whom for what here that'd be >> better though. >> >> intro: Doesn't federated anything really require there to be >1 IdP? If > so, why >> not say so? >> >> intro: "Simplified Sign-On" is a new one to me and sounds like a marketing >> term, if so, it'd be better left out >> >> intro: Is the indentation right for "Data minimization.." >> >> intro: The last para before 1.1 claims that this will scale to large > numbers of >> everything - is there evidence of that? If not, then better to not make > the >> unfounded claim. >> >> 1.1: Predicting problems readers will have is odd. >> >> 1.1.1: "provide" naming semantics seems wrong >> >> 1.1.1: typos: "mutualtion" "confiduatal" >> >> 1.1.1 last para: so I don't get this description. That's not helped by a > couple of >> odd typos, but I think it'd be worth another look at this to try make it > clearer. >> >> 1.2: "There is a direct relationship between the Client and the Identity >> Provider by which the entities trust and can securely authenticate each >> other." reads oddly to me. >> >> 1.3: "proliferating" federations seems a bit exaggerated. >> >> 1.3: "the use of SMTP and IMAP protocols do not have the ability for the >> server to get additional information" >> seems badly phrased. >> >> 1.4: step 2 - passive voice - who selects GSS-EAP? Or is that negotiated >> between client and RP? >> >> 1.4: step 5 - the RP only knows which IdP is claimed at this point, not > which it >> "is" - better to clarify? >> >> 1.4: it'd be better if the figures were all numbered, the ladder diagram > here is >> not >> >> 1.4: ladder diagram (11) spacing is broken >> >> 1.5, 1st bullet: s/of a transaction/in a transaction/ maybe better? >> >> 1.5, 2nd bullet: decoupled from what? >> >> 1.5, 3rd bullet: s/servers/RPs/ more accurate? >> >> 1.5, s/excitement/trend/ would be more neutral >> >> section 2, 3rd para: wording is not great, maybe s/for encapsulating/to >> encapsulate/ and s/the usage of// and s/a description of// would be better >> >> 2.1: May as well use IdP here and not "Identity Provider" >> >> 2.1, last sentence before 2.1.1: better to omit this or add a reference to >> something (doesn't have to be an I-D, a workshop paper or similar would be >> fine). >> >> 2.1.1: why "Interestingly"? I don't know why you told me that and it makes >> me wonder if some would claim that this was not successful. >> >> 2.1.1: "mileage" is an odd term here, smacks of sales-talk >> >> 2.1.1: s/a future document would/a future document could/ >> >> 2.1.2: s/criteria/criterion/g in 1st para after 1st bullet list >> >> 2.1.4, 1st para: Its mostly yukkie to end a sentence with a preposition > like >> "of" :-) >> >> 2.1.4: s/have designed in/include/ >> >> 2.1.5: You say that it won't always be possible for an RP to verify a > signature >> on an assertion. I think that was the subject of list discussion, but > don't see >> that reflected here. Should you explain some more about why this is > likely to >> be the case? The reader may wonder otherwise. >> >> 2.1.5: Saying "different namespaces assigned to the same name" reads oddly >> if you don't have SAML stuff at the front of your brain - maybe this could > do >> with some more explanation for those who've forgotten SAML terminology? >> And maybe a reference to something that goes into the detail would be good >> too. >> >> 2.1.5: modifying proxies - why is it "obvious" that they'd remove > signatures - >> wasn't that also the result of a list discussion that was not obvious? > (And in >> principle the proxies could add to the assertion or add a new assertion or >> something, leaving the original verifiable.) >> >> 2.2.1: I don't get what "where Individuals can correctly identify the > entire >> mechanism on the fly" might mean - can you explain or make it clear? >> >> 2.3.1: Wouldn't it be better to distinguish between those GSS-API using >> applications that are real vs. those where how to use GSS-API is well- >> defined, but never used? I think for example that 3645 is not really > deployed >> (but correct me if I'm wrong). >> >> 2.3.1: Is "no required modifications" really true? While I might not have > to >> modify application layer code, won't I probably have to write new > packaging, >> do new testing and management etc? That's not free either. >> >> 2.3.2: s/privacy/confidentiality/ would be better >> >> 2.3.3: would s/server/RP/ be right here? If not, then maybe you >> >> 3.1, 2nd para: maybe s/it/mutual authentication/ would be better just > before >> the bullets >> >> 3.1, last sentence: Be good to add a reference to the anonymous return > flag >> so someone can go figure out what that means in more detail. I just mean a >> section number of whatever RFC defines this. >> >> 3.2: I guess add a ref to 5246 somewhere >> >> 3.3: I'm not sure if there are missing references here or if they've all > been >> given earlier - be good to check e.g. >> are all the RFCs for GSS-API for foo somewhere? And maybe DNSSEC and >> NAPTR etc are missing refs. >> >> 3.3: Is RFC 1964 right for kerberos/GSS or 4121? >> >> 3.4: Be nice to add refs for the non-IETF protocols that will use stuff in > the >> near future. >> >> 4.1: s/can reside on any/can reside on any or all/ might be better, given >> recent news. You should also note that nodes might collude or be coerced >> into colluding. >> >> 4.1: Another missing ref to Trust Router. Maybe add ref or delete that. >> >> section 7: I wish we could get more comments from Bob Morgan. Makes me >> sad that we cannot. >> >> >> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > > > From hartmans@painless-security.com Tue Dec 17 11:33:29 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D041AE1A7 for ; Tue, 17 Dec 2013 11:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBRwAcPmVX3i for ; Tue, 17 Dec 2013 11:33:27 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 17DB61AE198 for ; Tue, 17 Dec 2013 11:33:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 17ED3205E9; Tue, 17 Dec 2013 14:32:00 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hf7swnM9G4Ow; Tue, 17 Dec 2013 14:31:59 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 17 Dec 2013 14:31:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2ED0291399; Tue, 17 Dec 2013 14:33:25 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <52AF2A4C.5000304@cs.tcd.ie> <027c01cefaeb$79b97960$6d2c6c20$@augustcellars.com> Date: Tue, 17 Dec 2013 14:33:25 -0500 In-Reply-To: <027c01cefaeb$79b97960$6d2c6c20$@augustcellars.com> (Jim Schaad's message of "Mon, 16 Dec 2013 21:47:30 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 19:33:29 -0000 Couple of points. Note that the MSK is encrypted even if you don't use RADIUS over TLS. The encryption is questionable (md5 as a stream cipher) but might randomly happen to be good enough for encrypting a randomly chosen key. for myself I'll choose to deploy with TLS rather than trusting that:-) I don't mind removing the trust router references, but I also don't think it is problematic to leave them in. This document points out there are multiple ways of solving the trust router solves. I think it's fine to note that people are working on the trust router, one specific manifestation of the trust broker approach for managing the connection between RP and IDP. Other approaches are discussed besides the trust broker deployment pattern. So, I don't think there's a dependency creater or implied. On the other hand, I don't mind removing the reference either. From stephen.farrell@cs.tcd.ie Tue Dec 17 13:03:25 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCB31A1F06 for ; Tue, 17 Dec 2013 13:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE2c3v5kD4Oz for ; Tue, 17 Dec 2013 13:03:22 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 27C541A1F33 for ; Tue, 17 Dec 2013 13:03:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E0A23BE58; Tue, 17 Dec 2013 21:03:19 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv5NB5Wn2wkg; Tue, 17 Dec 2013 21:03:18 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.42.29.6]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 89739BE57; Tue, 17 Dec 2013 21:03:18 +0000 (GMT) Message-ID: <52B0BC16.7030703@cs.tcd.ie> Date: Tue, 17 Dec 2013 21:03:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Sam Hartman , Jim Schaad References: <52AF2A4C.5000304@cs.tcd.ie> <027c01cefaeb$79b97960$6d2c6c20$@augustcellars.com> In-Reply-To: X-Enigmail-Version: 1.6 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-arch-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 21:03:25 -0000 On 12/17/2013 07:33 PM, Sam Hartman wrote: > Couple of points. > > Note that the MSK is encrypted even if you don't use RADIUS over TLS. > The encryption is questionable (md5 as a stream cipher) but might > randomly happen to be good enough for encrypting a randomly chosen key. > for myself I'll choose to deploy with TLS rather than trusting that:-) Yep. > I don't mind removing the trust router references, but I also don't > think it is problematic to leave them in. This document points out > there are multiple ways of solving the trust router solves. I think > it's fine to note that people are working on the trust router, one > specific manifestation of the trust broker approach for managing the > connection between RP and IDP. Other approaches are discussed besides > the trust broker deployment pattern. > So, I don't think there's a dependency creater or implied. > On the other hand, I don't mind removing the reference either. Fair enough. So long as its sorta consistent and doesn't over promise it'll be fine. S. > > From kwiereng@cisco.com Wed Dec 18 01:27:00 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38A351AE0A2 for ; Wed, 18 Dec 2013 01:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGVtaSVkOp62 for ; Wed, 18 Dec 2013 01:26:59 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 88BA51AE333 for ; Wed, 18 Dec 2013 01:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=283; q=dns/txt; s=iport; t=1387358817; x=1388568417; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=xMhzERcBrjqKTEB2wFO8nlra6+27X73VBt/Swy2ouqk=; b=afAC4QbQmS8Lv6csUG0QYtDOdzKIEzHZFWG3slM4SH8MYZSwIbWSkgI/ t7FGWv0adQMiPVonkNLLMWwHm4gqcOQJSo7zqaRN+C/2OXR2cWDE17Z12 z7mqPhoM4XrEFpKftMElYaELk06vsMLPeCb+lnhGPMEcwbSMh78BsmlNM o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFADpqsVKtJXG+/2dsb2JhbABZgwqBDbhYAYEdFnSCLDpRAT5CJwSIF6FoqAcXjj6DfoETBJgWkhSDK4Iq X-IronPort-AV: E=Sophos;i="4.95,506,1384300800"; d="scan'208";a="7590145" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-4.cisco.com with ESMTP; 18 Dec 2013 09:26:43 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBI9QgvW023284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Dec 2013 09:26:42 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 18 Dec 2013 03:26:42 -0600 From: "Klaas Wierenga (kwiereng)" To: "abfab@ietf.org" Thread-Topic: abfab session at IETF London? Thread-Index: AQHO+9NCJoNKfytD4k+Bq3s+c7/qNA== Date: Wed, 18 Dec 2013 09:26:41 +0000 Message-ID: <7FB9C312-6E81-4B3B-AFFB-C3DB12396C80@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.108.147] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [abfab] abfab session at IETF London? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 09:27:00 -0000 Hi, It is the time to put in session requests for the upcoming IETF. We don't h= ave a whole lot of open issues in abfab, so Leif and I would like to hear f= rom you whether we need to request a slot or not, if we don't hear from you= we will skip this one. Klaas & Leif= From hartmans@painless-security.com Wed Dec 18 06:10:21 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27711AE408 for ; Wed, 18 Dec 2013 06:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMxDbBQ0PLfs for ; Wed, 18 Dec 2013 06:10:16 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE9E1AE3EB for ; Wed, 18 Dec 2013 06:10:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 83298205EA; Wed, 18 Dec 2013 09:08:46 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMg500_e0_oX; Wed, 18 Dec 2013 09:08:46 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 18 Dec 2013 09:08:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0CA4F913A8; Wed, 18 Dec 2013 09:10:12 -0500 (EST) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: <7FB9C312-6E81-4B3B-AFFB-C3DB12396C80@cisco.com> Date: Wed, 18 Dec 2013 09:10:12 -0500 In-Reply-To: <7FB9C312-6E81-4B3B-AFFB-C3DB12396C80@cisco.com> (Klaas Wierenga's message of "Wed, 18 Dec 2013 09:26:41 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] abfab session at IETF London? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 14:10:22 -0000 I'd like to discuss two things: 1) Try to come to closure on aaa-saml. It's possible we'll do that before but it's possible we will not 2) I think f2f time on ephemeral DH keing for abfab will be useful. I'll try to see that we have a straw-man draft although I'd prefer not to have to write it. Based on my note to emu and here, I think this is the right place for the work If there are no other issues I'd recommend a 90-minute or 60-minute slot. From kwiereng@cisco.com Thu Dec 19 05:46:59 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051551ADBCF for ; Thu, 19 Dec 2013 05:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.039 X-Spam-Level: X-Spam-Status: No, score=-10.039 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71b3Dtcu7LyO for ; Thu, 19 Dec 2013 05:46:57 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id A98E71AD948 for ; Thu, 19 Dec 2013 05:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=643; q=dns/txt; s=iport; t=1387460816; x=1388670416; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eP3t6eQszm2IJKuiQq8mz+GQhsWyoSUNKwMxWxJmkpc=; b=iZ/9rAV92orUtWIskFdWgTTp+Fr9UAc4Pko30ic6uzIRKIXhA78zHRrx kPVGDqYRoNlxk4I/CslTy0h9pR+QplDKcSvwW9bBvCgS1wGom0+PsqApy 3IeYtrerN68OwZwXd3WWz3W09qq11SZcfF34hIJBeiqMoEnH6gbobETbO k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAC74slKtJV2a/2dsb2JhbABZgwuBDbkqgRQWdIIlAQEBAwE6PwULAgEINhAyJQIEDgWHfAjKRxeOPiEzB4MjgRMBA5gWkhSDK4Iq X-IronPort-AV: E=Sophos;i="4.95,512,1384300800"; d="scan'208";a="7900365" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 19 Dec 2013 13:46:55 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rBJDktHc003304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 13:46:55 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.104]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 19 Dec 2013 07:46:55 -0600 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [abfab] abfab session at IETF London? Thread-Index: AQHO+9NCJoNKfytD4k+Bq3s+c7/qNJpZ/hxNgAHwYAA= Date: Thu, 19 Dec 2013 13:46:54 +0000 Message-ID: References: <7FB9C312-6E81-4B3B-AFFB-C3DB12396C80@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.61.108.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <1BD84A783FC16E4EA96C7529747C6D49@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] abfab session at IETF London? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Dec 2013 13:46:59 -0000 On Dec 18, 2013, at 3:10 PM, Sam Hartman w= rote: Hi Sam, > I'd like to discuss two things: >=20 > 1) Try to come to closure on aaa-saml. It's possible we'll do that > before but it's possible we will not >=20 > 2) I think f2f time on ephemeral DH keing for abfab will be useful. > I'll try to see that we have a straw-man draft although I'd prefer not > to have to write it. > Based on my note to emu and here, I think this is the right place for > the work right, but the discussion we had in Vancouver was pretty inconclusive, so I= 'd like to have at least a strawman.=20 Klaas= From leifj@sunet.se Mon Dec 30 08:08:27 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38DD1AE511 for ; Mon, 30 Dec 2013 08:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.308 X-Spam-Level: X-Spam-Status: No, score=-1.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.538, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMnmFn10ocKx for ; Mon, 30 Dec 2013 08:08:25 -0800 (PST) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) by ietfa.amsl.com (Postfix) with ESMTP id C10641ADF4F for ; Mon, 30 Dec 2013 08:08:24 -0800 (PST) Received: from smtp1.sunet.se (smtp1.sunet.se [IPv6:2001:6b0:8:2::214]) by e-mailfilter01.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id rBUG8G3N026895 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Dec 2013 17:08:17 +0100 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.4/8.14.4) with ESMTP id rBUDOccI004572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Dec 2013 14:24:41 +0100 (CET) X-Footer: c3VuZXQuc2U= Received: from [172.20.10.5] ([2.64.190.127]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 8.2.1) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256 bits)) for abfab@ietf.org; Mon, 30 Dec 2013 17:08:07 +0100 Message-ID: <52C19A63.5010300@sunet.se> Date: Mon, 30 Dec 2013 17:08:03 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: abfab@ietf.org References: <20131230145749.32682.77531.idtracker@ietfa.amsl.com> In-Reply-To: <20131230145749.32682.77531.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20131230145749.32682.77531.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------010009020407040600000901" X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, sunet-se:default, base:default, @@RPTN) X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=62.0000; longitude=15.0000; http://maps.google.com/maps?q=62.0000,15.0000&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09L7Q8hC1 - 4005b59e032c - 20131230 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [abfab] Fwd: abfab - New Meeting Session Request for IETF 89 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 16:08:28 -0000 This is a multi-part message in MIME format. --------------010009020407040600000901 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I requested a 1hr slot but also noted that we don't mind meeting on Friday (seemed like a reasonable offering to the scheduling-gods) Cheers Leif -------- Original Message -------- Subject: abfab - New Meeting Session Request for IETF 89 Date: Mon, 30 Dec 2013 06:57:49 -0800 From: "IETF Meeting Session Request Tool" To: session-request@ietf.org CC: abfab-ads@tools.ietf.org, leifj@sunet.se, kwiereng@cisco.com, leifj@matematik.su.se A new meeting session request has just been submitted by Leif Johansson, a Chair of the abfab working group. --------------------------------------------------------- Working Group Name: Application Bridging for Federated Access Beyond web Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 40 Conflicts to Avoid: First Priority: scim emu jose oauth radext kitten uta dime Special Requests: avoid identity and security BoFs if possible, we have no problem meeting on friday --------------------------------------------------------- --------------010009020407040600000901 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
I requested a 1hr slot but also noted that we don't mind meeting on Friday (seemed like a reasonable offering to the scheduling-gods)

        Cheers Leif

-------- Original Message --------
Subject: abfab - New Meeting Session Request for IETF 89
Date: Mon, 30 Dec 2013 06:57:49 -0800
From: "IETF Meeting Session Request Tool" <session_request_developers@ietf.org>
To: session-request@ietf.org
CC: abfab-ads@tools.ietf.org, leifj@sunet.se, kwiereng@cisco.com, leifj@matematik.su.se 


A new meeting session request has just been submitted by Leif Johansson, a Chair of the abfab working group.


---------------------------------------------------------
Working Group Name: Application Bridging for Federated Access Beyond web
Area Name: Security Area
Session Requester: Leif Johansson

Number of Sessions: 1
Length of Session(s):  1 Hour
Number of Attendees: 40
Conflicts to Avoid: 
 First Priority: scim emu jose oauth radext kitten uta dime




Special Requests:
  avoid identity and security BoFs if possible, we have no problem meeting on friday
---------------------------------------------------------


--------------010009020407040600000901-- From wwwrun@rfc-editor.org Tue Dec 31 09:47:45 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0AD61AE369; Tue, 31 Dec 2013 09:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9L8L-7lowYv; Tue, 31 Dec 2013 09:47:40 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 78E461AE31B; Tue, 31 Dec 2013 09:47:40 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 353427FC175; Tue, 31 Dec 2013 09:47:34 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131231174734.353427FC175@rfc-editor.org> Date: Tue, 31 Dec 2013 09:47:34 -0800 (PST) Cc: drafts-update-ref@iana.org, abfab@ietf.org, rfc-editor@rfc-editor.org Subject: [abfab] RFC 7055 on A GSS-API Mechanism for the Extensible Authentication Protocol X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 17:47:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7055 Title: A GSS-API Mechanism for the Extensible Authentication Protocol Author: S. Hartman, Ed., J. Howlett Status: Standards Track Stream: IETF Date: December 2013 Mailbox: hartmans-ietf@mit.edu, josh.howlett@ja.net Pages: 35 Characters: 87564 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-abfab-gss-eap-09.txt URL: http://www.rfc-editor.org/rfc/rfc7055.txt This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL) applications use the Extensible Authentication Protocol. This document is a product of the Application Bridging for Federated Access Beyond web Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Tue Dec 31 09:48:18 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEF31AE369; Tue, 31 Dec 2013 09:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceB4H-bQY-44; Tue, 31 Dec 2013 09:48:13 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 22AF51AE3B1; Tue, 31 Dec 2013 09:48:12 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F37EB7FC3A1; Tue, 31 Dec 2013 09:48:05 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131231174805.F37EB7FC3A1@rfc-editor.org> Date: Tue, 31 Dec 2013 09:48:05 -0800 (PST) Cc: drafts-update-ref@iana.org, abfab@ietf.org, rfc-editor@rfc-editor.org Subject: [abfab] RFC 7056 on Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 17:48:18 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7056 Title: Name Attributes for the GSS-API Extensible Authentication Protocol (EAP) Mechanism Author: S. Hartman, J. Howlett Status: Standards Track Stream: IETF Date: December 2013 Mailbox: hartmans-ietf@mit.edu, josh.howlett@ja.net Pages: 11 Characters: 24622 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-abfab-gss-eap-naming-07.txt URL: http://www.rfc-editor.org/rfc/rfc7056.txt The naming extensions to the Generic Security Service Application Programming Interface (GSS-API) 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, and Accounting (AAA) peer to provide authorization attributes alongside an authentication response. It also supplies mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes how to use the Naming Extensions API to access that information. This document is a product of the Application Bridging for Federated Access Beyond web Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Tue Dec 31 09:48:48 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D21AE31B; Tue, 31 Dec 2013 09:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es7Ougd-fnJD; Tue, 31 Dec 2013 09:48:43 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE941AE3CC; Tue, 31 Dec 2013 09:48:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5BB247FC3AB; Tue, 31 Dec 2013 09:48:29 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131231174829.5BB247FC3AB@rfc-editor.org> Date: Tue, 31 Dec 2013 09:48:29 -0800 (PST) Cc: drafts-update-ref@iana.org, abfab@ietf.org, rfc-editor@rfc-editor.org Subject: [abfab] RFC 7057 on Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 17:48:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7057 Title: Update to the Extensible Authentication Protocol (EAP) Applicability Statement for Application Bridging for Federated Access Beyond Web (ABFAB) Author: S. Winter, J. Salowey Status: Standards Track Stream: IETF Date: December 2013 Mailbox: stefan.winter@restena.lu, jsalowey@cisco.com Pages: 7 Characters: 16006 Updates: RFC 3748 I-D Tag: draft-ietf-abfab-eapapplicability-06.txt URL: http://www.rfc-editor.org/rfc/rfc7057.txt This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC 3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture. This document is a product of the Application Bridging for Federated Access Beyond web Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From internet-drafts@ietf.org Tue Dec 31 11:41:27 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47E91AE442; Tue, 31 Dec 2013 11:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpW9iGLlq-vp; Tue, 31 Dec 2013 11:41:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 040391AE206; Tue, 31 Dec 2013 11:41:26 -0800 (PST) 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.90 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131231194125.8942.7268.idtracker@ietfa.amsl.com> Date: Tue, 31 Dec 2013 11:41:25 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-10.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 19:41: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 : Application Bridging for Federated Access Beyond = Web (ABFAB) Architecture Authors : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Jim Schaad Filename : draft-ietf-abfab-arch-10.txt Pages : 43 Date : 2013-12-31 Abstract: Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use cases: network access and web-based access. However, the solutions to these use cases that have been proposed and deployed tend to have few 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) the Generic Security Service (GSS), 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf@augustcellars.com Tue Dec 31 11:50:30 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1DB11AE45D for ; Tue, 31 Dec 2013 11:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS86PBraVQzw for ; Tue, 31 Dec 2013 11:50:28 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 425F31AE45C for ; Tue, 31 Dec 2013 11:50:28 -0800 (PST) Received: from Philemon (c-24-17-142-118.hsd1.wa.comcast.net [24.17.142.118]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 28B3F2CA71 for ; Tue, 31 Dec 2013 11:50:22 -0800 (PST) From: "Jim Schaad" To: References: <20131231194126.8942.30471.idtracker@ietfa.amsl.com> In-Reply-To: <20131231194126.8942.30471.idtracker@ietfa.amsl.com> Date: Tue, 31 Dec 2013 11:48:51 -0800 Message-ID: <021201cf0661$54d1be60$fe753b20$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGh7Cl2S0FWyKxWrYOUGr8zxAtodZrI6iEQ Content-Language: en-us Subject: [abfab] FW: New Version Notification for draft-ietf-abfab-arch-10.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 19:50:31 -0000 This version addresses the major issues in the review from the AD. The = nits are being held until the last call and directorate reviews come in. Jim > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, December 31, 2013 11:41 AM > To: Sam Hartman; Hannes Tschofenig; Jim Schaad; Eliot Lear; Sam D. = Hartman; > Josh Howlett; Eliot Lear; Jim Schaad; Josh Howlett; Hannes Tschofenig > Subject: New Version Notification for draft-ietf-abfab-arch-10.txt >=20 >=20 > A new version of I-D, draft-ietf-abfab-arch-10.txt has been = successfully > submitted by Jim Schaad and posted to the IETF repository. >=20 > Name: draft-ietf-abfab-arch > Revision: 10 > Title: Application Bridging for Federated Access Beyond Web > (ABFAB) Architecture > Document date: 2013-12-31 > Group: abfab > Pages: 43 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-abfab-arch-10.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-abfab-arch/ > Htmlized: http://tools.ietf.org/html/draft-ietf-abfab-arch-10 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-arch-10 >=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 access 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) the Generic Security Service (GSS), 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 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat