From ietf@augustcellars.com Thu Dec 8 21:01:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B5511E8096 for ; Thu, 8 Dec 2011 21:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3WHScZnpC7G for ; Thu, 8 Dec 2011 21:01:26 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 19C7411E8093 for ; Thu, 8 Dec 2011 21:01:26 -0800 (PST) Received: from Tobias (unknown [50.46.85.150]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id CA75238EEF for ; Thu, 8 Dec 2011 21:01:24 -0800 (PST) From: "Jim Schaad" To: Date: Thu, 8 Dec 2011 21:00:55 -0800 Message-ID: <004f01ccb62f$88d3ecd0$9a7bc670$@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: Acy2Llto3aKJleIiQRmJJGgLKruHZQ== Content-Language: en-us Subject: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 05:01:26 -0000 As part of the plasma work, one of the things that has been stated as a requirement is that the RP can insist on a level of assurance for the client to be authenticated with. At this point in process, I don't care about the specifics of how the LOA is actually specified, but I am interested in how the data specifying this would be conveyed. At this point I can see two different methods to convey the information: 1. The data is carried in a RADIUS attribute. Such an attribute may already exist, I have not done any type of exhaustive search, and just needs to be documented. I can see other access points wanting to require an LOA in just the straight RADIUS AAA world. 2. The data could be carried in a SAML request. As long as the IdP and the AAA Radius server are co-existent this would not be a problem. But it does mean that the SAML request now needs to be parsed for some information before the EAP processes are run in order to determine which EAP methods are acceptable to the RP. Jim From ietf@augustcellars.com Thu Dec 8 23:28:06 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC44111E808C for ; Thu, 8 Dec 2011 23:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.38 X-Spam-Level: X-Spam-Status: No, score=-3.38 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubwngrPJUO+v for ; Thu, 8 Dec 2011 23:28:06 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 578F011E8081 for ; Thu, 8 Dec 2011 23:28:06 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CD4332CA45 for ; Thu, 8 Dec 2011 23:28:05 -0800 (PST) From: "Jim Schaad" To: References: <004f01ccb62f$88d3ecd0$9a7bc670$@augustcellars.com> In-Reply-To: <004f01ccb62f$88d3ecd0$9a7bc670$@augustcellars.com> Date: Thu, 8 Dec 2011 23:27:36 -0800 Message-ID: <005701ccb644$069ff780$13dfe680$@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: AQKB83wYdxyJkUV9sYjY73JhMr3b95RooMXw Content-Language: en-us Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 07:28:06 -0000 While reading my back log of messages, I discovered the following text: There is no mention in this section that there may be multiple IdPs for a single realm that could be used by the RP and the selection of which IdP it wants to use is going to be based on the set of attributes that the RP needs or a level of authentication that is required by the RP (see [sp800-63-1] NIST SP 800-63-1 "Electronic Authentication Guideline", December 2008 as examples). Is this a real thing and is this something that needs to be handled by having separate AAA proxy and IdP servers. If so does this mean that we need to look at that interface more closely? Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Jim Schaad > Sent: Thursday, December 08, 2011 9:01 PM > To: abfab@ietf.org > Subject: [abfab] Levels of Assurence > > As part of the plasma work, one of the things that has been stated as a > requirement is that the RP can insist on a level of assurance for the client to > be authenticated with. At this point in process, I don't care about the > specifics of how the LOA is actually specified, but I am interested in how the > data specifying this would be conveyed. > > At this point I can see two different methods to convey the information: > > 1. The data is carried in a RADIUS attribute. Such an attribute may already > exist, I have not done any type of exhaustive search, and just needs to be > documented. I can see other access points wanting to require an LOA in just > the straight RADIUS AAA world. > > 2. The data could be carried in a SAML request. As long as the IdP and > the AAA Radius server are co-existent this would not be a problem. But it > does mean that the SAML request now needs to be parsed for some > information before the EAP processes are run in order to determine which > EAP methods are acceptable to the RP. > > Jim > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hannes.tschofenig@nsn.com Fri Dec 9 00:14:30 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7641621F8466 for ; Fri, 9 Dec 2011 00:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.539 X-Spam-Level: X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTaG+PZBy93q for ; Fri, 9 Dec 2011 00:14:29 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2F13C21F8462 for ; Fri, 9 Dec 2011 00:14:29 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pB98E1U0029159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 9 Dec 2011 09:14:01 +0100 Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pB98Dvct029038; Fri, 9 Dec 2011 09:14:01 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Dec 2011 09:14:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Dec 2011 10:13:59 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DDB9CB1@FIESEXC035.nsn-intra.net> In-Reply-To: <005701ccb644$069ff780$13dfe680$@augustcellars.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Levels of Assurence Thread-Index: AQKB83wYdxyJkUV9sYjY73JhMr3b95RooMXwgAAKuhA= References: <004f01ccb62f$88d3ecd0$9a7bc670$@augustcellars.com> <005701ccb644$069ff780$13dfe680$@augustcellars.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Jim Schaad" , X-OriginalArrivalTime: 09 Dec 2011 08:14:00.0316 (UTC) FILETIME=[817C8BC0:01CCB64A] Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 08:14:30 -0000 Hi Jim,=20 Here is the challenge with the level of assurance concept: they are not just a matter of how the user was authenticated but the different levels are reflected in the overall system design.=20 As such, it is not sufficient to just communicate from the IdP to the RP that a specific transaction is, for example, LoA 4. The RP should "know" that since the entire system has to be designed in such a way and the IdP and the RP are likely to have an agreement (out of band) to ensure the RP that the IdP does actually what it is claiming to do. (You may call this "trust relationship".)=20 Having said that NIST SP 800-63 (as it is available today; revision pending) has a serious shortcoming. It focuses with the LoA concept heavily on identity proofing and authentication but does not consider the attribute assurance and privacy concepts that are associated with the release of data. In a complete system, like we are working on in ABFAB, this is very relevant.=20 So, while I like NIST SP 800-63 a lot I am eagerly waiting for an update of their document (which should have been out there already) to see whether we can reference something more complete for the purpose of our discussion. As far as the conveyance of the LoA in RADIUS / Diameter / SAML / etc. concerns I am less convinced about the value.=20 Just yesterday I suggested to the OAuth working group that the different levels of assurance could serve as a good way to describe security properties of a system. See my mail here: http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html Ciao Hannes > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of ext Jim Schaad > Sent: Friday, December 09, 2011 9:28 AM > To: abfab@ietf.org > Subject: Re: [abfab] Levels of Assurence >=20 > While reading my back log of messages, I discovered the following text: >=20 > There is no mention in this section that there may be multiple IdPs for > a > single realm that could be used by the RP and the selection of which > IdP it > wants to use is going to be based on the set of attributes that the RP > needs > or a level of authentication that is required by the RP (see [sp800- > 63-1] > NIST SP 800-63-1 "Electronic Authentication Guideline", December 2008 > as > examples). >=20 > Is this a real thing and is this something that needs to be handled by > having separate AAA proxy and IdP servers. If so does this mean that > we > need to look at that interface more closely? >=20 > Jim >=20 >=20 > > -----Original Message----- > > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On > Behalf > > Of Jim Schaad > > Sent: Thursday, December 08, 2011 9:01 PM > > To: abfab@ietf.org > > Subject: [abfab] Levels of Assurence > > > > As part of the plasma work, one of the things that has been stated as > a > > requirement is that the RP can insist on a level of assurance for the > client to > > be authenticated with. At this point in process, I don't care about > the > > specifics of how the LOA is actually specified, but I am interested > in how > the > > data specifying this would be conveyed. > > > > At this point I can see two different methods to convey the > information: > > > > 1. The data is carried in a RADIUS attribute. Such an attribute may > already > > exist, I have not done any type of exhaustive search, and just needs > to be > > documented. I can see other access points wanting to require an LOA > in > just > > the straight RADIUS AAA world. > > > > 2. The data could be carried in a SAML request. As long as the IdP > and > > the AAA Radius server are co-existent this would not be a problem. > But it > > does mean that the SAML request now needs to be parsed for some > > information before the EAP processes are run in order to determine > which > > EAP methods are acceptable to the RP. > > > > Jim > > > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Fri Dec 9 00:19:39 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60FF411E8090 for ; Fri, 9 Dec 2011 00:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DBGoxhrZqKT for ; Fri, 9 Dec 2011 00:19:38 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id B854211E8073 for ; Fri, 9 Dec 2011 00:19:38 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 3FE9438F17; Fri, 9 Dec 2011 00:19:38 -0800 (PST) From: "Jim Schaad" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <004f01ccb62f$88d3ecd0$9a7bc670$@augustcellars.com> <005701ccb644$069ff780$13dfe680$@augustcellars.com> <999913AB42CC9341B05A99BBF358718DDB9CB1@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DDB9CB1@FIESEXC035.nsn-intra.net> Date: Fri, 9 Dec 2011 00:19:08 -0800 Message-ID: <006001ccb64b$39ca1850$ad5e48f0$@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: AQKB83wYdxyJkUV9sYjY73JhMr3b9wE4hyPXAeNT0KaUT8/0gA== Content-Language: en-us Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 08:19:39 -0000 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Friday, December 09, 2011 12:14 AM > To: ext Jim Schaad; abfab@ietf.org > Subject: RE: [abfab] Levels of Assurence > > Hi Jim, > > Here is the challenge with the level of assurance concept: they are not just a > matter of how the user was authenticated but the different levels are > reflected in the overall system design. > > As such, it is not sufficient to just communicate from the IdP to the RP that a > specific transaction is, for example, LoA 4. The RP should "know" > that since the entire system has to be designed in such a way and the IdP and > the RP are likely to have an agreement (out of band) to ensure the RP that > the IdP does actually what it is claiming to do. (You may call this "trust > relationship".) I think that this may be required in both directions. That is the RP may need to tell the IdP what it wants as well. I completely agree that there is going to need to be an OOB agreement about what the values mean. But I still potentially want to do the selection process. > > Having said that NIST SP 800-63 (as it is available today; revision > pending) has a serious shortcoming. It focuses with the LoA concept heavily > on identity proofing and authentication but does not consider the attribute > assurance and privacy concepts that are associated with the release of data. > In a complete system, like we are working on in ABFAB, this is very relevant. > > So, while I like NIST SP 800-63 a lot I am eagerly waiting for an update of their > document (which should have been out there already) to see whether we > can reference something more complete for the purpose of our discussion. > As far as the conveyance of the LoA in RADIUS / Diameter / SAML / etc. > concerns I am less convinced about the value. > > Just yesterday I suggested to the OAuth working group that the different > levels of assurance could serve as a good way to describe security properties > of a system. See my mail here: > http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html > > Ciao > Hannes > > > > -----Original Message----- > > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > > Of ext Jim Schaad > > Sent: Friday, December 09, 2011 9:28 AM > > To: abfab@ietf.org > > Subject: Re: [abfab] Levels of Assurence > > > > While reading my back log of messages, I discovered the following > text: > > > > There is no mention in this section that there may be multiple IdPs > for > > a > > single realm that could be used by the RP and the selection of which > > IdP it wants to use is going to be based on the set of attributes that > > the RP needs or a level of authentication that is required by the RP > > (see > [sp800- > > 63-1] > > NIST SP 800-63-1 "Electronic Authentication Guideline", December 2008 > > as examples). > > > > Is this a real thing and is this something that needs to be handled by > > having separate AAA proxy and IdP servers. If so does this mean that > > we need to look at that interface more closely? > > > > Jim > > > > > > > -----Original Message----- > > > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On > > Behalf > > > Of Jim Schaad > > > Sent: Thursday, December 08, 2011 9:01 PM > > > To: abfab@ietf.org > > > Subject: [abfab] Levels of Assurence > > > > > > As part of the plasma work, one of the things that has been stated > as > > a > > > requirement is that the RP can insist on a level of assurance for > the > > client to > > > be authenticated with. At this point in process, I don't care about > > the > > > specifics of how the LOA is actually specified, but I am interested > > in how > > the > > > data specifying this would be conveyed. > > > > > > At this point I can see two different methods to convey the > > information: > > > > > > 1. The data is carried in a RADIUS attribute. Such an attribute > may > > already > > > exist, I have not done any type of exhaustive search, and just needs > > to be > > > documented. I can see other access points wanting to require an LOA > > in > > just > > > the straight RADIUS AAA world. > > > > > > 2. The data could be carried in a SAML request. As long as the > IdP > > and > > > the AAA Radius server are co-existent this would not be a problem. > > But it > > > does mean that the SAML request now needs to be parsed for some > > > information before the EAP processes are run in order to determine > > which > > > EAP methods are acceptable to the RP. > > > > > > Jim > > > > > > > > > _______________________________________________ > > > abfab mailing list > > > abfab@ietf.org > > > https://www.ietf.org/mailman/listinfo/abfab > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab From Josh.Howlett@ja.net Fri Dec 9 00:23:24 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3621F847C for ; Fri, 9 Dec 2011 00:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e13C5Uu14BDl for ; Fri, 9 Dec 2011 00:23:23 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6866621F846A for ; Fri, 9 Dec 2011 00:23:23 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id F33C01A9A252_EE1C578B; Fri, 9 Dec 2011 08:23:20 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 842781A9A23F_EE1C578F; Fri, 9 Dec 2011 08:23:20 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Fri, 9 Dec 2011 08:23:14 +0000 From: Josh Howlett To: Jim Schaad , "abfab@ietf.org" Thread-Topic: [abfab] Levels of Assurence Thread-Index: Acy2Llto3aKJleIiQRmJJGgLKruHZQAHJe+A Date: Fri, 9 Dec 2011 08:23:14 +0000 Message-ID: In-Reply-To: <004f01ccb62f$88d3ecd0$9a7bc670$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 08:23:24 -0000 Jim, >1. The data is carried in a RADIUS attribute. Such an attribute may >already exist, I have not done any type of exhaustive search, and just >needs >to be documented. I can see other access points wanting to require an LOA >in just the straight RADIUS AAA world. I'm not aware of any standardised semantics to convey this either. It could always be defined, of course, either within the standard or vendor-specific RADIUS namespaces. >2. The data could be carried in a SAML request. As long as the IdP and >the AAA Radius server are co-existent this would not be a problem. But it >does mean that the SAML request now needs to be parsed for some >information >before the EAP processes are run in order to determine which EAP methods >are >acceptable to the RP. This is certainly reasonable as SAML allows the RP to specify conditions to authentication requests. Any modern RADIUS implementation would support this for the RADIUS attribute case today (we have a FreeRADIUS module for processing SAML requests that could be extended to cover the SAML case that you describe without much difficulty I believe). You also have a third option, which is to infer the LoA from the source of the request. This obviously doesn't help in the case where an RP needs >1 LoA for a particular IdP. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Fri Dec 9 00:44:47 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BA121F854D for ; Fri, 9 Dec 2011 00:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lc7HUBsDgrdY for ; Fri, 9 Dec 2011 00:44:46 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id B448221F8549 for ; Fri, 9 Dec 2011 00:44:46 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D260B1A9C23B_EE1CA7DB; Fri, 9 Dec 2011 08:44:45 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id B75741A9C22B_EE1CA7DF; Fri, 9 Dec 2011 08:44:45 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Fri, 9 Dec 2011 08:44:45 +0000 From: Josh Howlett To: Jim Schaad , "abfab@ietf.org" Thread-Topic: [abfab] Levels of Assurence Thread-Index: Acy2Llto3aKJleIiQRmJJGgLKruHZQAFap8AAAKxVAA= Date: Fri, 9 Dec 2011 08:44:44 +0000 Message-ID: In-Reply-To: <005701ccb644$069ff780$13dfe680$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <71179D42B9FD9344996EEBD22C18E034@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 08:44:47 -0000 >Is this a real thing and is this something that needs to be handled by >having separate AAA proxy and IdP servers. If so does this mean that we >need to look at that interface more closely? Assuming that the request were able to convey AAA or SAML semantics indicating the LoA requirement, I think it is reasonable to expect the IdP domain to apply policy on these semantics for a single IdP NAI realm. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From diego@tid.es Fri Dec 9 00:50:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD93821F8549 for ; Fri, 9 Dec 2011 00:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9jl5rhwSOzQ for ; Fri, 9 Dec 2011 00:50:40 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC9021F84CE for ; Fri, 9 Dec 2011 00:50:39 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LVX00E52HWDPR@tid.hi.inet> for abfab@ietf.org; Fri, 09 Dec 2011 09:50:37 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 0F.A3.21312.DDBC1EE4; Fri, 09 Dec 2011 09:50:37 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LVX00E4ZHWDPR@tid.hi.inet> for abfab@ietf.org; Fri, 09 Dec 2011 09:50:37 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Fri, 09 Dec 2011 09:50:37 +0100 Date: Fri, 09 Dec 2011 09:50:36 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: "abfab@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] Levels of Assurence Thread-index: Acy2T57UwZ4pN8MmQ4G3esgTDOSXlQ== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f1c6d000005340-65-4ee1cbdd1ade X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42Lhivcz1L17+qGfweNdahYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpOn75gLHglXtK3qYGlgXCDcxcjJISFgIvFzyUNWCFtM4sK9 9WxdjFwcQgLbGCWa/kxhhHB+MEpMajvCBFIlJNDIKPH7fG4XIwcHi4CqxLulqSBhNgF1iZaj 31hAbGEBDYnL3WvZQGxOAUOJq1MvsYPYIkDl559/AIvzClhKtP7cxAhhC0r8mHyPBWQkM9Cc KVNyQcLMAuISza03WSBsRYlpixrAyhmB7vx+ag0TxEhNiU03prFA2HoSRzsvs0LUiErcaV/P CPGXgMSSPeeZIWxRiZeP/7FCfGIgseXGZLYJjGKzkFwxC+GKWUiumIXkigWMLKsYxYqTijLT M0pyEzNz0g2M9DIy9TLzUks2MUIiJXMH4/KdKocYBTgYlXh4Jwg99BNiTSwrrsw9xCjJwaQk yssGjDMhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryXjwLleFMSK6tSi/JhUjIcHEoSvN4gbYJF qempFWmZOcB0AJNm4uAEaecBaq8GqeEtLkjMLc5Mh8ifYpSUEucNB0kIgCQySvPgel8xigMd KczLAZLlASYuuK5XQAOZgAZ+yX4AMrAkESEl1cCYdfHWis9fdOWMnCZUXztfnfRHw/hpusT+ 37vLFA457k35n8t68msw71ejJzYbTqbo+O0VjZ/Pampy5uKsdbxb1vokSc7c6P89NsknIWNO qLi84J8EvnXOCk9eNq//p6yy4s2JO56Nq6JuNEuzTNX4VrWMS3JNc5Br+ea2gNM+ZReen+3k mpmkxFKckWioxVxUnAgAliCuchkDAAA= References: Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 08:50:40 -0000 DQpPbiA5IERlYyAyMDExLCBhdCAwOToyMyAsIEpvc2ggSG93bGV0dCB3cm90ZToNCj4+IDEuICBU aGUgZGF0YSBpcyBjYXJyaWVkIGluIGEgUkFESVVTIGF0dHJpYnV0ZS4NCj4gLiAuIC4NCj4gSSdt IG5vdCBhd2FyZSBvZiBhbnkgc3RhbmRhcmRpc2VkIHNlbWFudGljcyB0byBjb252ZXkgdGhpcyBl aXRoZXIuIEl0DQo+IGNvdWxkIGFsd2F5cyBiZSBkZWZpbmVkLCBvZiBjb3Vyc2UsIGVpdGhlciB3 aXRoaW4gdGhlIHN0YW5kYXJkIG9yDQo+IHZlbmRvci1zcGVjaWZpYyBSQURJVVMgbmFtZXNwYWNl cy4NCj4NCj4+IDIuICBUaGUgZGF0YSBjb3VsZCBiZSBjYXJyaWVkIGluIGEgU0FNTCByZXF1ZXN0 Lg0KPiAuIC4gLg0KPiBUaGlzIGlzIGNlcnRhaW5seSByZWFzb25hYmxlIGFzIFNBTUwgYWxsb3dz IHRoZSBSUCB0byBzcGVjaWZ5IGNvbmRpdGlvbnMNCj4gdG8gYXV0aGVudGljYXRpb24gcmVxdWVz dHMuIEFueSBtb2Rlcm4gUkFESVVTIGltcGxlbWVudGF0aW9uIHdvdWxkIHN1cHBvcnQNCj4gdGhp cyBmb3IgdGhlIFJBRElVUyBhdHRyaWJ1dGUgY2FzZSB0b2RheSAod2UgaGF2ZSBhIEZyZWVSQURJ VVMgbW9kdWxlIGZvcg0KPiBwcm9jZXNzaW5nIFNBTUwgcmVxdWVzdHMgdGhhdCBjb3VsZCBiZSBl eHRlbmRlZCB0byBjb3ZlciB0aGUgU0FNTCBjYXNlDQo+IHRoYXQgeW91IGRlc2NyaWJlIHdpdGhv dXQgbXVjaCBkaWZmaWN1bHR5IEkgYmVsaWV2ZSkuDQo+DQo+IFlvdSBhbHNvIGhhdmUgYSB0aGly ZCBvcHRpb24sIHdoaWNoIGlzIHRvIGluZmVyIHRoZSBMb0EgZnJvbSB0aGUgc291cmNlIG9mDQo+ IHRoZSByZXF1ZXN0LiBUaGlzIG9idmlvdXNseSBkb2Vzbid0IGhlbHAgaW4gdGhlIGNhc2Ugd2hl cmUgYW4gUlAgbmVlZHMgPjENCj4gTG9BIGZvciBhIHBhcnRpY3VsYXIgSWRQLg0KDQoNCkkgZG9u J3QgdGhpbmsgdGhlc2Ugb3B0aW9ucyBhcmUgbXV0dWFsbHkgZXhjbHVzaXZlLiBUaGUgQUFBIHNl cnZlciBjYW4gaGF2ZSBzb21lIGxvY2FsIHBvbGljeSByZXF1aXJpbmcgYSBwYXJ0aWN1bGFyIExv QSBmb3Igc3BlY2lmaWMgUlBzLiBJZiB0aGVyZSBpcyBubyBtYXRjaGluZyBsb2NhbCBwb2xpY3kg cnVsZSBvbiB0aGlzLCBpdCBjYW4gbG9vayBmb3IgYSB2YWx1ZSBvZiBhIHBhcnRpY3VsYXIgUkFE SVVTIGF0dHJpYnV0ZS4gSWYgdGhlIGF0dHJpYnV0ZSBpcyBub3QgcHJlc2VudCwgb3IgZXZlbiBz ZXQgdG8gYSB2YWx1ZSBleHBsaWNpdGx5IGluZGljYXRpbmcgdG8gdXNlIHRoZSBTQU1MICBhc3Nl cnRpb24sIGl0IGNhbiBnbyB0aGF0IHdheS4NCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXog bm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVs ZWZvbmljYSBJK0QNCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgICArMzQgOTEzIDEy OSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVu dGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBk ZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNl IHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVs eSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRo ZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdC4NCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BB R0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From trac+abfab@trac.tools.ietf.org Thu Dec 8 22:41:33 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8072821F84C3 for ; Thu, 8 Dec 2011 22:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6YRGsitgJEj for ; Thu, 8 Dec 2011 22:41:33 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DE05221F84C2 for ; Thu, 8 Dec 2011 22:41:32 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYu8q-0002vK-AI; Fri, 09 Dec 2011 01:41:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 06:41:07 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/1 Message-ID: <062.431a4b0baac443ac856e3b95893fa03c@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209064132.DE05221F84C2@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 22:41:32 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #1: NAI needs to be expanded at first instance of use X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 06:41:33 -0000 #1: NAI needs to be expanded at first instance of use NAI either needs to be expanded the first time it is used or put into a glossary at the front of the document -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Thu Dec 8 22:47:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1722B21F8531 for ; Thu, 8 Dec 2011 22:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTV+p5KGKn+6 for ; Thu, 8 Dec 2011 22:47:35 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4BF21F84ED for ; Thu, 8 Dec 2011 22:47:35 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYuEw-0007d3-3D; Fri, 09 Dec 2011 01:47:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 06:47:26 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/2 Message-ID: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209064735.7E4BF21F84ED@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 22:47:35 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is running over X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 06:47:36 -0000 #2: Section 1.4 - No discussion of transport GSS-API is running over This list of steps does not talk about the actual transport used between the client and the RP in any of the steps. I believe that this needs to be included as it is a core part of the architecture for an application implementor or specification writer. -- --------------------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: Active WG Document | Keywords: --------------------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Thu Dec 8 23:02:08 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE221F84ED for ; Thu, 8 Dec 2011 23:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51jJEj-5q9FG for ; Thu, 8 Dec 2011 23:02:08 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id F1A4E21F846B for ; Thu, 8 Dec 2011 23:02:06 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYuT0-0004Dl-4O; Fri, 09 Dec 2011 02:01:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 07:01:58 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/3 Message-ID: <062.b8cd88f598aae5e077dbe8665d81b7a3@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209070207.F1A4E21F846B@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 23:02:06 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #3: Section 1.4 Step 5- GSS/EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 07:02:08 -0000 #3: Section 1.4 Step 5- GSS/EAP Current text: encapsulates a GSS/EAP access request to an IdP This should just be an EAP request as there is no GSS at this point. version 0 -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Thu Dec 8 23:04:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115A51F0C55 for ; Thu, 8 Dec 2011 23:04:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEC1opKPNgHT for ; Thu, 8 Dec 2011 23:04:55 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E05C11F0C52 for ; Thu, 8 Dec 2011 23:04:54 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYuVh-0004En-Pn; Fri, 09 Dec 2011 02:04:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 07:04:45 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/4 Message-ID: <062.46ef602c330d7f6bf2ef0077b9408fdc@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209070454.E05C11F0C52@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 23:04:54 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #4: Section 1.4 - Step 7 - explain endpoints X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 07:04:57 -0000 #4: Section 1.4 - Step 7 - explain endpoints verison -00 Current text A bunch of EAP messages happen between the endpoints Suggested A bunch of EAP messages flow between the RP and the IdP: -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Thu Dec 8 23:13:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679341F0C52 for ; Thu, 8 Dec 2011 23:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdPKU9YllrrP for ; Thu, 8 Dec 2011 23:13:00 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id CB1351F0C50 for ; Thu, 8 Dec 2011 23:13:00 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYudW-0004Jm-1V; Fri, 09 Dec 2011 02:12:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 07:12:50 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/5 Message-ID: <062.e822bf8ba8d5efc7ec13013540b126ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209071300.CB1351F0C50@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 23:13:00 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #5: Section 1.4 - Step 8 - Be more explicit about describing channel binding. X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 07:13:01 -0000 #5: Section 1.4 - Step 8 - Be more explicit about describing channel binding. Verison -00 Current text If the asserted identity of the RP by the principal matches the identity the RP itself asserted, there is some confidence that the RP is now authenticated to the IdP This text is very unclear - it is obviously channel binding that is being talked about. But I find the text as written very obscure. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Thu Dec 8 23:33:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F95B21F846B for ; Thu, 8 Dec 2011 23:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uUxJBGyptmV8 for ; Thu, 8 Dec 2011 23:33:57 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C318021F8468 for ; Thu, 8 Dec 2011 23:33:57 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYuxr-0007WV-4s; Fri, 09 Dec 2011 02:33:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 07:33:51 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/6 Message-ID: <062.7b7594d622efd3b057ab54bfed900ea0@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209073357.C318021F8468@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 23:33:57 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #6: Section 2.2 - bad flow of text for authentication requriements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 07:33:58 -0000 #6: Section 2.2 - bad flow of text for authentication requriements Version -00 Has the sentences " Aside from a valuable secret being exposed, a synchronization problem can also often develop. Since there is no single authentication mechanism that will be used everywhere there is another associated requirement:" I have a couple of issues here. First there is a problem which is stated - i.e. synchronization - but the next sentence does not appear to expand on the problem but rather deals with a different issue. I would like to have the first thought finished before going onto the second one. I think this paragraph is supposed to be talking about issues that we have been taught - but the word Since does not convey this is a separate issue we have dealing with. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Thu Dec 8 23:47:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B35B11E808C for ; Thu, 8 Dec 2011 23:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upldqjaRaBmw for ; Thu, 8 Dec 2011 23:47:57 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1C99A11E808B for ; Thu, 8 Dec 2011 23:47:54 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYvB5-0003UX-M1; Fri, 09 Dec 2011 02:47:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 07:47:30 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/7 Message-ID: <062.ed6d2b9df26895340891c0098bf3b35d@trac.tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209074757.1C99A11E808B@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 23:47:54 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #7: Entity Naming Problems Galore X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 07:47:57 -0000 #7: Entity Naming Problems Galore There are massive problems throughout the document in that we are not using a consistant set of names for each of the entities in the document. Part of this issue is that there are different names for each of these entities in each of the different protocols that we are using. However it also makes the entire document difficult to follow as one needs to keep track of this all of the time. THe following things need to be done: 1. A table that maps from the name used in the document to the name used in each of the different protocols 2. The use of a consistant name for each entity 3. Where feasible, you can do something like RP (Service Provider) so that both names are in the text. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Thu Dec 8 23:48:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16BB11E8095 for ; Thu, 8 Dec 2011 23:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKKnllLP5cfk for ; Thu, 8 Dec 2011 23:48:57 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3659C11E8096 for ; Thu, 8 Dec 2011 23:48:57 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYvCH-0005B5-MA; Fri, 09 Dec 2011 02:48:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 07:48:45 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/8 Message-ID: <062.8c6495cd1dde547981dfb2772cac7faa@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209074857.3659C11E8096@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 23:48:57 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #8: Issues about using a AA rather than an IdP at one end X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 07:48:57 -0000 #8: Issues about using a AA rather than an IdP at one end The document is currently written in terms of dealing with an Identity provider, and I can understand why that is so as without an identity not much will happen. However it seems to me that there is also a desire to be able to talk to an attribute service in much the same way. However it is not clear that there is a need for the End Host to talk to the attribute provider - that communication should be thought of as passing between the IdP, the RP and the AtP. The IdP may need to get a different or better identity proof as part of that conversation. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Thu Dec 8 23:49:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B290411E8090 for ; Thu, 8 Dec 2011 23:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eBkXNzWRAqk for ; Thu, 8 Dec 2011 23:49:40 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 42F6711E808C for ; Thu, 8 Dec 2011 23:49:40 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RYvD6-0006VF-1u; Fri, 09 Dec 2011 02:49:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Fri, 09 Dec 2011 07:49:36 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/9 Message-ID: <062.a1f3c5afc776c1c4522400a4d95e60a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111209074940.42F6711E808C@ietfa.amsl.com> Resent-Date: Thu, 8 Dec 2011 23:49:40 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org X-Mailman-Approved-At: Fri, 09 Dec 2011 04:17:36 -0800 Cc: abfab@ietf.org Subject: [abfab] #9: What goes into a federation agreement? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 07:49:40 -0000 #9: What goes into a federation agreement? I am not sure if there needs to be a discussion on what needs to be a part of a federation agreement. One of the issues that I can see as being troublesome as it does not seem to be vastly expandable is the question of what makes for an equivalent statement. Is it to be expected that the SASL statements are going to be made in terms of the federation agreement attributes, or does there need to be available to the RP some type of mapping statement? This may not be needed, but there are some things that will consistantly need to be present and having some coverage would be useful. -- ---------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: trivial | Milestone: Component: arch | Version: Severity: - | Keywords: ---------------------+------------------------------------- Ticket URL: abfab From hartmans@painless-security.com Fri Dec 9 05:02:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9CC21F8500 for ; Fri, 9 Dec 2011 05:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWYNWfGLxfcF for ; Fri, 9 Dec 2011 05:02:28 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 40C0C21F84FD for ; Fri, 9 Dec 2011 05:02:27 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 56A2B2016B; Fri, 9 Dec 2011 08:02:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B611D42E8; Fri, 9 Dec 2011 08:02:00 -0500 (EST) From: Sam Hartman To: Josh Howlett References: Date: Fri, 09 Dec 2011 08:02:00 -0500 In-Reply-To: (Josh Howlett's message of "Fri, 9 Dec 2011 08:44:44 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 13:02:29 -0000 At least in the Moonshot implementation we plan on handling this through the Communities of Interest concept in draft-mrw-abfab-trust-router. As Hannes points out LOA really implies more of a system concept than just how the user is authenticated. So, some proxies may not be up to carrying particular LOA traffic. So a particular request would enter the system in a community with a particular LOA requirement. That would influence which proxies were considered appropriate and potentially keying between proxies. In some cases there may be a RADIUS hop before trust router starts, or RADIUS hops that carry multiple COIs, similar to how other labeled traffic is handled. We'd need some sort of RADIUS attribute for distinguishing COI in this case. Obviously, this is very specific to our implementation at the moment, and we don't have code for this yet. However it very much is a system property and so aspects of this are easier to think of in a system context like Moonshot than purely in a standardization context in order to see how it all fits together. Obviously it would be great to standardize as much of this as possible. From leifj@sunet.se Fri Dec 9 05:18:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B72021F84C5 for ; Fri, 9 Dec 2011 05:18:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO8Fcm4EZj9C for ; Fri, 9 Dec 2011 05:18:57 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 06C2321F84AB for ; Fri, 9 Dec 2011 05:18:55 -0800 (PST) Received: from [109.105.104.174] (dhcp40.se-tug.nordu.net [109.105.104.174] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB9DIndf008156 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Dec 2011 14:18:52 +0100 (CET) Message-ID: <4EE20AB9.7070805@sunet.se> Date: Fri, 09 Dec 2011 14:18:49 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: abfab@ietf.org References: <004f01ccb62f$88d3ecd0$9a7bc670$@augustcellars.com> <005701ccb644$069ff780$13dfe680$@augustcellars.com> <999913AB42CC9341B05A99BBF358718DDB9CB1@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DDB9CB1@FIESEXC035.nsn-intra.net> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 13:18:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/09/2011 09:13 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Jim, > > Here is the challenge with the level of assurance concept: they are > not just a matter of how the user was authenticated but the > different levels are reflected in the overall system design. If you read 800-63 or iso29115 or the Kantara IAF (or most other trust frameworks sired from 800-63) you will find 4 aspects over which loa is measured: business maturity and stability, identity proofing, credentials management and authentication. It is a common misstake to assume that authentication is the only aspect. > > As such, it is not sufficient to just communicate from the IdP to > the RP that a specific transaction is, for example, LoA 4. The RP > should "know" that since the entire system has to be designed in > such a way and the IdP and the RP are likely to have an agreement > (out of band) to ensure the RP that the IdP does actually what it > is claiming to do. (You may call this "trust relationship".) > Absolutely not. In most real-world situations LoA is "mixed" - users may authenticate with different tokens for the same "identity" thus having different "aggregate" LoA for any given authn event. You *absolutely* have to figure out a way to communicate LoA and both SAML and OpenID Connect have mechanisms for this. > Having said that NIST SP 800-63 (as it is available today; > revision pending) has a serious shortcoming. It focuses with the > LoA concept heavily on identity proofing and authentication but > does not consider the attribute assurance and privacy concepts that > are associated with the release of data. In a complete system, like > we are working on in ABFAB, this is very relevant. This is an area that is seeing increased interest in both OIX and Kantara for instance. However it may be that the gap are not as great as one might think. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7iCrgACgkQ8Jx8FtbMZnf/HwCaApIEUarpoh9+g4aNeUBzhnCw WqwAn3I+kBbGS799X3xfQf4B8wBggXZ7 =sNMU -----END PGP SIGNATURE----- From klaas@cisco.com Fri Dec 9 05:36:38 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E201321F84D7 for ; Fri, 9 Dec 2011 05:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7SF2ZUbP8qe for ; Fri, 9 Dec 2011 05:36:38 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5C221F852E for ; Fri, 9 Dec 2011 05:36:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3342; q=dns/txt; s=iport; t=1323437798; x=1324647398; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=37lu3gojXPMplRSUwLwzlSukoQE2PORp2qs5an/g7YA=; b=dBWEuaiD4Wul+XfuE5Ouxx1jBBf4VMosl52J7qd5/S6V6pMvkPHf60PR T/1VRBKL4UHo8NiYfpwVee96nsvd/f/uC6tnj1RW/NQIWYdNI6tRUqava c+hTnklgkFaQ/YCpo65H96jJAaFGt+czoDo6Zo0mQDFt720cDAKvRsfz4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABEppk6tJV2a/2dsb2JhbACeW3iIcItlkjSGGQSQEY52 X-IronPort-AV: E=Sophos;i="4.71,325,1320624000"; d="scan'208";a="40052673" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 09 Dec 2011 13:36:37 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pB9Daa9W017539; Fri, 9 Dec 2011 13:36:37 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Klaas Wierenga In-Reply-To: <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> Date: Fri, 9 Dec 2011 14:36:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> To: DIEGO LOPEZ GARCIA X-Mailer: Apple Mail (2.1251.1) Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 13:36:39 -0000 Hi, Apologies for reopening a discussion that seems to have concluded (my = only excuse is that I was hovering most of the last 2 weeks 20 meters = below the surface of the Red Sea). But I still need some more convincing that we MUST carry the SAML data = over AAA. It seems to me that using the AAA fabric just to introduce the = parties to each other and do additional attribute exchange = out-of-AAA-band has a number of advantages, most importantly, no issue = with the 4k limit. I find the argument that intermediate nodes may need = to rewrite attributes not very convincing, after all there are many = hub-and-spoke federations in SAML-space that do just that routinely, no = need for AAA intermediaries.=20 In this respect our use is very different from the AAA+EAP for network = access use-case, there we are suffering from the fact that the = supplicant has no layer 3 connectivity yet, but in the abfab case all = actors have IP-connectivty? Or am I just being dense? In that case please enlighten me (beyond "but = doing everything over AAA is a much cleaner solution") Klaas On Nov 29, 2011, at 6:55 PM, DIEGO LOPEZ GARCIA wrote: >=20 > On 29 Nov 2011, at 09:10 , Alejandro Perez Mendez wrote: >> I think that the "more SAML data" attribute proposed by Alan would = work >> also if included in requests. In such a case, the AAA/idP could send = an >> Access-Challenge message (including User-Name and State attributes, = for >> example), waiting for more data to come from the RP. >=20 > As Alan noted, we should aim for a more general name for the = attribute. Though the exchange of SAML data is the main (and probably = unique, at least for the moment) use case, I don't see any hurt in using = something like "more additional data" or "more external data" or "more = authorization data"... >=20 >> Additionally, the "more SAML data" could contain some kind of = "cookie" >> or "nonce" value, in such a way that if returned unmodified in the >> following Request/Response message to the creator, it allows to tie = all >> the messages within a conversation, if other means (e.g. State >> attribute) are finally not enough or not applicable. >=20 > Indeed. I think it would provide not only this tying mechanism, but = also the possiblity of using it to point the conversation (and the = subject of the data being exchanged) to the elements providing those = additional authorization data, and I guess this could satisfy what Josh = called the decoupling of the authentication and assertion roundtrips. >=20 > Be goode, >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D >=20 > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- >=20 >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra pol=EDtica de env=EDo y recepci=F3n de correo = electr=F3nico en el enlace situado m=E1s abajo. > This message is intended exclusively for its addressee. We only send = and receive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From aland@deployingradius.com Fri Dec 9 06:12:24 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B370921F853B for ; Fri, 9 Dec 2011 06:12:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c899ZmlcczN4 for ; Fri, 9 Dec 2011 06:12:24 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 227D121F84DA for ; Fri, 9 Dec 2011 06:12:24 -0800 (PST) Message-ID: <4EE21729.6080808@deployingradius.com> Date: Fri, 09 Dec 2011 15:11:53 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Klaas Wierenga References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> In-Reply-To: <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:12:24 -0000 Klaas Wierenga wrote: > Apologies for reopening a discussion that seems to have concluded (my only excuse is that I was hovering most of the last 2 weeks 20 meters below the surface of the Red Sea). > But I still need some more convincing that we MUST carry the SAML data over AAA. It seems to me that using the AAA fabric just to introduce the parties to each other and do additional attribute exchange out-of-AAA-band has a number of advantages, most importantly, no issue with the 4k limit. I find the argument that intermediate nodes may need to rewrite attributes not very convincing, after all there are many hub-and-spoke federations in SAML-space that do just that routinely, no need for AAA intermediaries. I agree that intermediate nodes do not need to rewrite the attributes. There may still be benefits from using AAA. The simplest is using one technology for everything. The alternative is to put the SAML attributes in HTTP (everything over HTTP), and give a URL to the end host. This brings additional issues of copying the data from AAA server to HTTP server, authenticating the client which gets the SAML data, securing the data transfer, etc. Alan DeKok. From klaas@cisco.com Fri Dec 9 06:56:35 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6A721F856F for ; Fri, 9 Dec 2011 06:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omLzlP1vnKVi for ; Fri, 9 Dec 2011 06:56:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 58EAB21F8560 for ; Fri, 9 Dec 2011 06:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1967; q=dns/txt; s=iport; t=1323442592; x=1324652192; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qh8wfFGRmHCUu7fPuJHcQUYRgbrbAWKkHpQMzCYRpiY=; b=HhRlVIu9c2GAWc4LIqGYgOJqoqaE7K1YxUUXGJDoNGfCBDDmzjD8e7DM gF5F13jK9SFXS7UR8kVZ1mlHCYUFefQ/2Y6XIYEPWhdVT3iyD6UzlRAUj wEnvYLaonxDAiQ2COROhSqni3lCvlfKcAVMH8zCXg3SIIRmEMinBAzIJl c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKsg4k6tJV2Y/2dsb2JhbABDqnmBBYFyAQEBAQIBEgFmBQsLGC5XBgorh2WXcQGeGIsPYwSUcJIo X-IronPort-AV: E=Sophos;i="4.71,326,1320624000"; d="scan'208";a="42575396" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 09 Dec 2011 14:56:32 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pB9EuUAi022592; Fri, 9 Dec 2011 14:56:31 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Klaas Wierenga In-Reply-To: <4EE21729.6080808@deployingradius.com> Date: Fri, 9 Dec 2011 15:56:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1251.1) Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 14:56:36 -0000 On Dec 9, 2011, at 3:11 PM, Alan DeKok wrote: > Klaas Wierenga wrote: >> Apologies for reopening a discussion that seems to have concluded (my = only excuse is that I was hovering most of the last 2 weeks 20 meters = below the surface of the Red Sea). >> But I still need some more convincing that we MUST carry the SAML = data over AAA. It seems to me that using the AAA fabric just to = introduce the parties to each other and do additional attribute exchange = out-of-AAA-band has a number of advantages, most importantly, no issue = with the 4k limit. I find the argument that intermediate nodes may need = to rewrite attributes not very convincing, after all there are many = hub-and-spoke federations in SAML-space that do just that routinely, no = need for AAA intermediaries.=20 >=20 > I agree that intermediate nodes do not need to rewrite the = attributes. >=20 > There may still be benefits from using AAA. The simplest is using = one > technology for everything. yes, that argument I buy, and is in fact the only compelling argument I = was able to come up with. > The alternative is to put the SAML attributes in HTTP (everything = over > HTTP), and give a URL to the end host. This brings additional issues = of > copying the data from AAA server to HTTP server, authenticating the > client which gets the SAML data, securing the data transfer, etc. Well, aren't the SAML IdP and RP already involved? The SAML entities = would act as some sort of Authentication Server backend, Active = Directory with a callback=85. Is it likely that we will have a AAA-only = RP or IdP rather than a generic IdP/RP? I think that in particular for = the IdP that is an unlikely scenario, it will most likely also support = HTTP. And rather than seeing it as a URL I would like to regard it is a = endpoint identifier. I don't care for HTTP in particular, presumably = this could be a case for SAML-ECP=85 Klaas=20= From Josh.Howlett@ja.net Fri Dec 9 07:33:31 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A4FC21F84C2 for ; Fri, 9 Dec 2011 07:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edhTZpr-zQaW for ; Fri, 9 Dec 2011 07:33:30 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8960121F84BA for ; Fri, 9 Dec 2011 07:33:30 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D0D631A9A252_EE22A49B; Fri, 9 Dec 2011 15:33:29 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id B3CC31A9A23F_EE22A49F; Fri, 9 Dec 2011 15:33:29 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Fri, 9 Dec 2011 15:33:29 +0000 From: Josh Howlett To: Sam Hartman , Jim Schaad Thread-Topic: [abfab] Levels of Assurence Thread-Index: Acy2Llto3aKJleIiQRmJJGgLKruHZQAFap8AAAKxVAAACQCrdQAFITCA Date: Fri, 9 Dec 2011 15:33:29 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <979D7DDBC4A4D64889051738A0242439@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 15:33:31 -0000 >At least in the Moonshot implementation we plan on handling this through >the Communities of Interest concept in draft-mrw-abfab-trust-router. Its interesting that Jim has a use case for the multiple communities of interest problem, and so perhaps we can feed this into the 'problem statement' document that was proposed in Taipei. Jim: do you have a fuller description of the requirement (I assume this is rooted in a Plasma use case?), perhaps taking in policy requirements other than LoA? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From nico@cryptonector.com Fri Dec 9 09:25:09 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2F621F84F8 for ; Fri, 9 Dec 2011 09:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.738 X-Spam-Level: X-Spam-Status: No, score=-1.738 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZAhb1RM0ZmS for ; Fri, 9 Dec 2011 09:25:09 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 5663121F84ED for ; Fri, 9 Dec 2011 09:25:09 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id EF41B26406C for ; Fri, 9 Dec 2011 09:25:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=LG+O/4T55Y4xboK892jo6bkKA8vMiPmY0hlGbjoJHSMP JLlCHL1FYWbLNUiFLLC6AkfCK4MB3P+Oy8VLrQHy+a7nEjoQdMvX/AHe+xeF9WAA cnaVI4xkYhk2eGDoxwc1fmEAzvaYYcfPVDf8ArbpMaEiwVN9tsDkS8SH2QzYe/g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type:content-transfer-encoding; s=cryptonector.com; bh=KVP9aWZ2yZxL17pqvwF0qnNGKew=; b=dkmxRKl9F3TxI8GF/yyM4qQBKJao P0fcUIA9giKVY5f9GqbPh8nwFJbR09Umcq41sfRhU7QEC0FvjeDW28N3yr9lzjDl +FyHNWMBkA1dO0phzO9YXCLdnfBB7uQ1V5i1QLFhR37xjLGG8m4LmyOL5/r8hGJq hR2Sx5ogPMxVQqs= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id CFEF926406A for ; Fri, 9 Dec 2011 09:25:08 -0800 (PST) Received: by dajz8 with SMTP id z8so3982776daj.31 for ; Fri, 09 Dec 2011 09:25:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.191.106 with SMTP id gx10mr7401883pbc.60.1323451508463; Fri, 09 Dec 2011 09:25:08 -0800 (PST) Received: by 10.68.73.4 with HTTP; Fri, 9 Dec 2011 09:25:08 -0800 (PST) In-Reply-To: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> References: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> Date: Fri, 9 Dec 2011 11:25:08 -0600 Message-ID: From: Nico Williams To: abfab@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is running over X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 09 Dec 2011 17:25:09 -0000 On Fri, Dec 9, 2011 at 12:47 AM, abfab issue tracker wrote: > #2: Section 1.4 - No discussion of transport GSS-API is running over > > =C2=A0This list of steps does not talk about the actual transport used be= tween > =C2=A0the client and the RP in any of the steps. =C2=A0I believe that thi= s needs to > =C2=A0be included as it is a core part of the architecture for an applica= tion > =C2=A0implementor or specification writer. Huh? Why? Sure, we should recommend the use of TLS and channel binding to it for new applications, but there's nothing special about ABFAB (except for mechanisms that are too weak to use without a secure channel) here -- this is a general recommendation worth making no matter what the GSS mechanism that is in use. But also, existing applications do what they do, and it's not our place to tell them to do something else. We can say that some mechanism or other is not to be used outside a secure channel. Nico -- From cantor.2@osu.edu Fri Dec 9 09:45:38 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234AF21F8801 for ; Fri, 9 Dec 2011 09:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0Mqadc+ggJ7 for ; Fri, 9 Dec 2011 09:45:37 -0800 (PST) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id DA72B21F87D9 for ; Fri, 9 Dec 2011 09:45:35 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pB9HjRlD023812; Fri, 9 Dec 2011 12:45:27 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Fri, 9 Dec 2011 12:45:27 -0500 From: "Cantor, Scott" To: Klaas Wierenga , Alan DeKok Thread-Topic: [abfab] 4K limit Thread-Index: AQHMrb9OaTUm41Y5m0S6yhxfv7JsQJXChc0AgAAWP4CAACgfgIABEN6AgACjkoCAD27cAIAACdyAgAAMdwD//9tcgA== Date: Fri, 9 Dec 2011 17:45:21 +0000 Message-ID: In-Reply-To: <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <64ba96a9-cffe-4424-bc6d-985a82012cac> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; postalcode=43201; latitude=39.9930; longitude=-82.9985; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9930,-82.9985&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 17:45:38 -0000 The basic argument is that you need two trust fabrics, one for AAA and one for SAML. You lose some fairly significant benefit to ABFAB if you need the SAML layer anyway. You could just do SAML alone. Some of us want to pursue that anyway, but in the capacity of an ABFAB comment, that's the issue. -- Scott From ietf@augustcellars.com Fri Dec 9 11:35:16 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D3321F85FF for ; Fri, 9 Dec 2011 11:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8CnzUlMkubv for ; Fri, 9 Dec 2011 11:35:15 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 65CDD21F8541 for ; Fri, 9 Dec 2011 11:35:11 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 96CFD2CAE5; Fri, 9 Dec 2011 11:35:07 -0800 (PST) From: "Jim Schaad" To: "'Nico Williams'" , References: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> In-Reply-To: Date: Fri, 9 Dec 2011 11:34:28 -0800 Message-ID: <006c01ccb6a9$99647e50$cc2d7af0$@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: AQIzop12W1qxFVWplr1ElDJ/dAJYwgEPtgablP2PrQA= Content-Language: en-us Subject: Re: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is running over X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 09 Dec 2011 19:35:16 -0000 Nico, I am not saying that we need to say what the transport is, but if you = have a neophyte looking at the document and trying to figure out what is = happening they are going to start assuming that GSS-API apparently has a = transport as part of it. As we know this is incorrect. Additionally we may want to specify that the transport has some = properties - such as channel binding - that may or may not be of = interest. What are the issues of using a non-secure vs a secure = transport and so forth. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Nico Williams > Sent: Friday, December 09, 2011 9:25 AM > To: abfab@ietf.org > Subject: Re: [abfab] #2: Section 1.4 - No discussion of transport = GSS-API is > running over >=20 > On Fri, Dec 9, 2011 at 12:47 AM, abfab issue tracker > wrote: > > #2: Section 1.4 - No discussion of transport GSS-API is running over > > > > This list of steps does not talk about the actual transport used > > between the client and the RP in any of the steps. I believe that > > this needs to be included as it is a core part of the architecture > > for an application implementor or specification writer. >=20 > Huh? Why? Sure, we should recommend the use of TLS and channel = binding > to it for new applications, but there's nothing special about ABFAB = (except > for mechanisms that are too weak to use without a secure > channel) here -- this is a general recommendation worth making no = matter > what the GSS mechanism that is in use. >=20 > But also, existing applications do what they do, and it's not our = place to tell > them to do something else. We can say that some mechanism or other is = not > to be used outside a secure channel. >=20 > Nico > -- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From cantor.2@osu.edu Fri Dec 9 11:46:54 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7429521F8797 for ; Fri, 9 Dec 2011 11:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTdyw3Swv0WQ for ; Fri, 9 Dec 2011 11:46:54 -0800 (PST) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id D6DA121F8586 for ; Fri, 9 Dec 2011 11:46:53 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pB9JkID4004506; Fri, 9 Dec 2011 14:46:20 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi; Fri, 9 Dec 2011 14:46:19 -0500 From: "Cantor, Scott" To: Jim Schaad , Hannes Tschofenig , "abfab@ietf.org" Thread-Topic: [abfab] Levels of Assurence Thread-Index: Acy2Llto3aKJleIiQRmJJGgLKruHZQAP5NUAAAGes4AAAC4LAAANhT4A Date: Fri, 9 Dec 2011 19:46:16 +0000 Message-ID: In-Reply-To: <006001ccb64b$39ca1850$ad5e48f0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <7b3579ac-fa69-4bb8-aa7e-3a04fbf9f700> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; postalcode=43201; latitude=39.9930; longitude=-82.9985; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9930,-82.9985&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 19:46:54 -0000 On 12/9/11 3:19 AM, "Jim Schaad" wrote: > >I think that this may be required in both directions. That is the RP may >need to tell the IdP what it wants as well. > >I completely agree that there is going to need to be an OOB agreement >about >what the values mean. But I still potentially want to do the selection >process. Note that this is definitely non-trivial, and creates a lot of deployment complexity when you deal with IdPs that support multiple (or the absence of) LOAs, and the reality that many RPs need different LOAs to perform different functions, often from a single client. In practice, the support in SAML for this has been poorly implemented, or not at all, and there's not much deployment experience with it. -- Scott From nico@cryptonector.com Fri Dec 9 12:07:00 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C5721F8AB8 for ; Fri, 9 Dec 2011 12:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MF-34BpIokR for ; Fri, 9 Dec 2011 12:06:59 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 85BD521F8AF4 for ; Fri, 9 Dec 2011 12:06:59 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 43E4394076 for ; Fri, 9 Dec 2011 12:06:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=sAyOxEJcsErpFQqn93EwchDOSNu2pmhSO5RYp7vWha7n w41quQcdv2J+I1Yf+llfnnbaSVyJBryBrFL6q+rhNbgFUzVUgF2mwciw4ovG7++J 8PYidzkoacv5SoHOYwW9Bl1cRgnpMvaM4GT/WtoZsw1anObvghqLMWwPNMcf2SM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=Tsm0mEPykhLFSoQkH6y9nJp7vgI=; b=tv8fQuNOaSz Pt2NdlVMJIS2vbBwAoZm6f/qZbvdR/h/48nDqwQWJQeRA5MCLqWDAN7zpkscS0X4 G4pt+N95YhKnsRf2+zhJ8WsBEOKC+x7zWD/yptp1AMYUIvZtKB7LM3HW9COSnLoT rMFoMvMvvav2gfkyXFJ/tPJrRdBUQqR0= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 26E6494065 for ; Fri, 9 Dec 2011 12:06:59 -0800 (PST) Received: by dajz8 with SMTP id z8so4144746daj.31 for ; Fri, 09 Dec 2011 12:06:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.201.138 with SMTP id ka10mr8957996pbc.26.1323460893187; Fri, 09 Dec 2011 12:01:33 -0800 (PST) Received: by 10.68.73.4 with HTTP; Fri, 9 Dec 2011 12:01:33 -0800 (PST) In-Reply-To: <006c01ccb6a9$99647e50$cc2d7af0$@augustcellars.com> References: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> <006c01ccb6a9$99647e50$cc2d7af0$@augustcellars.com> Date: Fri, 9 Dec 2011 14:01:33 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is running over X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 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, 09 Dec 2011 20:07:00 -0000 On Fri, Dec 9, 2011 at 1:34 PM, Jim Schaad wrote: > I am not saying that we need to say what the transport is, but if you hav= e a neophyte looking at the document and trying to figure out what is happe= ning they are going to start assuming that GSS-API apparently has a transpo= rt as part of it. =C2=A0As we know this is incorrect. It's not incorrect though: GSS per-message tokens do in fact form a secure channel/transport. That's often (but not always) not as convenient as TLS, and for some mechanisms (e.g., ones based on bearer tokens), not secure. > Additionally we may want to specify that the transport has some propertie= s - such as channel binding - that may or may not be of interest. =C2=A0Wha= t are the issues of using a non-secure vs a secure transport and so forth. Sure. I don't mind some text to this effect in the architecture document, but it feels a lot like an update to RFC2743. Nico -- From hartmans@painless-security.com Fri Dec 9 12:43:37 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B224C21F849C for ; Fri, 9 Dec 2011 12:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBIK-RXRLKKD for ; Fri, 9 Dec 2011 12:43:36 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7123521F847C for ; Fri, 9 Dec 2011 12:43:24 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0F37920244; Fri, 9 Dec 2011 15:43:35 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0AAC842E8; Fri, 9 Dec 2011 15:43:10 -0500 (EST) From: Sam Hartman To: Klaas Wierenga References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> Date: Fri, 09 Dec 2011 15:43:10 -0500 In-Reply-To: <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> (Klaas Wierenga's message of "Fri, 9 Dec 2011 15:56:30 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:43:37 -0000 I think it is fairly likely that the IDP and RP will have the software to do normal SAML things, but in some of the deployments we're looking at will not have the provisioning (keys, metadata etc) to do SAML over HTTP. Also, I actually think there will be intermediates that will want to rewrite attributes. From nico@cryptonector.com Fri Dec 9 12:51:18 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADB521F88AB for ; Fri, 9 Dec 2011 12:51:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.757 X-Spam-Level: X-Spam-Status: No, score=-1.757 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1Fncu0Yg4sm for ; Fri, 9 Dec 2011 12:51:17 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5448521F843C for ; Fri, 9 Dec 2011 12:51:17 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 7F0371F008C for ; Fri, 9 Dec 2011 12:50:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=g+3jr0cJbO618TlL2EiIC k9HpT1+ygyH1xfRb6/bHFxp6+dwQChkfCzQ7+oUinDNm7i0wNgypqloQkrzwiYfX 81FEDP+CyKtVjWvnsGgNrgEizCmVlxH1NV8phyNztNxuw9jppZ6qd/ftE6iHvHk5 C6qwPnoab91HqJVStehsFc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XUH/ez2sk1O2iwW1djaY z6/III8=; b=dfb3j3tWraySWUKdW/gqX8bIx9IdOBpDTdr5ayRKOk5H6PajBxQ7 cfU2JOyyWvwTJOM9Y9qBdfTjuwrQqxRt6Yexv4r2TDGZS2VCJ0Z+dDIvQeixWfig CR5icWPEXIcBD9cC+8F8JpPxb0zMytNTEiSpuTrhvTkPAzXqYA5eLqE= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 730271F0087 for ; Fri, 9 Dec 2011 12:50:49 -0800 (PST) Received: by pbbb4 with SMTP id b4so561054pbb.31 for ; Fri, 09 Dec 2011 12:50:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.209.71 with SMTP id mk7mr10015838pbc.9.1323463832651; Fri, 09 Dec 2011 12:50:32 -0800 (PST) Received: by 10.68.73.4 with HTTP; Fri, 9 Dec 2011 12:50:32 -0800 (PST) In-Reply-To: References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> Date: Fri, 9 Dec 2011 14:50:32 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 20:51:18 -0000 On Fri, Dec 9, 2011 at 2:43 PM, Sam Hartman wrote: > I think it is fairly likely that the IDP and RP will have the software > to do normal SAML things, but in some of the deployments we're looking > at will not have the provisioning (keys, metadata etc) to do SAML over > HTTP. And I wouldn't want to encourage reliance on the HTTPS PKI. However, what could be done is that an attribute with a URI could also have a digest of the thing to be fetched via HTTP, and maybe a digest of the server cert or an intermediate CA for it (or perhaps a key that the actual attribute payload will be encrypted in, that way we can use plain HTTP). But this starts sounding hairy. > Also, I actually think there will be intermediates that will want to > rewrite attributes. I imagine so. I can see several reasons: 1) to rewrite attributes understood by one side into attributes understood by the other, 2) to apply privacy policies. (2) might be common in a deployment with a common, trusted trust broker, so to speak. Nico -- From hartmans@painless-security.com Fri Dec 9 13:01:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B7A1F0C4F for ; Fri, 9 Dec 2011 13:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk2LT9werCmi for ; Fri, 9 Dec 2011 13:01:48 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 54D9821F84BD for ; Fri, 9 Dec 2011 13:01:48 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 353FB20244; Fri, 9 Dec 2011 16:01:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 81C8342E8; Fri, 9 Dec 2011 16:01:34 -0500 (EST) From: Sam Hartman To: Nico Williams References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> Date: Fri, 09 Dec 2011 16:01:34 -0500 In-Reply-To: (Nico Williams's message of "Fri, 9 Dec 2011 14:50:32 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 21:01:48 -0000 >>>>> "Nico" == Nico Williams writes: Nico> However, what could be done is that an attribute with a URI Nico> could also have a digest of the thing to be fetched via HTTP, Nico> and maybe a digest of the server cert or an intermediate CA Nico> for it (or perhaps a key that the actual attribute payload Nico> will be encrypted in, that way we can use plain HTTP). But Nico> this starts sounding hairy. We can certainly do this. It starts getting quite involved though and illustrates the value of AAA. From hartmans@painless-security.com Fri Dec 9 13:04:20 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC481F0C5A for ; Fri, 9 Dec 2011 13:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp7fPT+Fxn2M for ; Fri, 9 Dec 2011 13:04:20 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 069051F0C52 for ; Fri, 9 Dec 2011 13:04:20 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E5F5820126; Fri, 9 Dec 2011 16:04:30 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4903942E8; Fri, 9 Dec 2011 16:04:06 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> <006c01ccb6a9$99647e50$cc2d7af0$@augustcellars.com> Date: Fri, 09 Dec 2011 16:04:06 -0500 In-Reply-To: <006c01ccb6a9$99647e50$cc2d7af0$@augustcellars.com> (Jim Schaad's message of "Fri, 9 Dec 2011 11:34:28 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is running over X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2011 21:04:20 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Additionally we may want to specify that the transport has some Jim> properties - such as channel binding - that may or may not be Jim> of interest. What are the issues of using a non-secure vs a Jim> secure transport and so forth. I can't think of any such properties, which is not to object simply to state my current thinking. We definitely do not want to require channel binding. From gabilm@um.es Sat Dec 10 00:13:13 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E2621F863E for ; Sat, 10 Dec 2011 00:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnU7yYc9dgdg for ; Sat, 10 Dec 2011 00:13:12 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 898BC21F8669 for ; Sat, 10 Dec 2011 00:13:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id C48365D513; Sat, 10 Dec 2011 09:13:09 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dfdbr-wYnjsT; Sat, 10 Dec 2011 09:13:09 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.216]) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPA id B775F5D4A1; Sat, 10 Dec 2011 09:13:06 +0100 (CET) Message-ID: <4EE3155C.8020507@um.es> Date: Sat, 10 Dec 2011 09:16:28 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Cantor, Scott" , "abfab@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [abfab] Levels of Assurence X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2011 08:13:13 -0000 El 09/12/11 20:46, Cantor, Scott escribió: > On 12/9/11 3:19 AM, "Jim Schaad" wrote: >> I think that this may be required in both directions. That is the RP may >> need to tell the IdP what it wants as well. >> >> I completely agree that there is going to need to be an OOB agreement >> about >> what the values mean. But I still potentially want to do the selection >> process. > Note that this is definitely non-trivial, and creates a lot of deployment > complexity when you deal with IdPs that support multiple (or the absence > of) LOAs, and the reality that many RPs need different LOAs to perform > different functions, often from a single client. > > In practice, the support in SAML for this has been poorly implemented, or > not at all, and there's not much deployment experience with it. Hi, We made some work some time ago, in the context of the DAMe project, you can find some information here: http://www.item.ntnu.no/europki08/presentations/europki08-lopez.ppt of course, it is out of date, take it like related work regards, Gabi. > > -- Scott > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de Ingenier’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:13:31 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860FC21F84ED for ; Sat, 10 Dec 2011 16:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6BDOV6N2oS6 for ; Sat, 10 Dec 2011 16:13:31 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1074021F84DD for ; Sat, 10 Dec 2011 16:13:30 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZX2M-0000Sk-Bj; Sat, 10 Dec 2011 19:13:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:13:01 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/10 Message-ID: <062.88e33e45a6a7a927b659bb8e1f4f3fc1@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211001331.1074021F84DD@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:13:30 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #10: Defintion of federation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:13:31 -0000 #10: Defintion of federation version -00 Intro para #3 - I want to make sure that your definition of federation is one that you want to make. Specifically it would appear that there can be federations even within a single entity in the event that actor providing the identity information is not the same as the RP. Would you consider a single Kerberos or Windows enterprise to be a federation. In these cases the IdP being the login service and the RP being somebody granting access to a resource (in windows possibly by an RPC). I generally think of federation as being between two different entities rather than within a single entity but using multiple servers. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:17:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9C21F8A91 for ; Sat, 10 Dec 2011 16:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uv8li+7Iobtz for ; Sat, 10 Dec 2011 16:17:25 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFE221F8A64 for ; Sat, 10 Dec 2011 16:17:25 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZX6X-00043Q-9l; Sat, 10 Dec 2011 19:17:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:17:21 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/11 Message-ID: <062.3d51fe0bb3fc047d6a8b3a0f65c89a5f@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211001725.7BFE221F8A64@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:17:25 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #11: Section 1.1 - para 'Provisioning' spelling errors X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:17:26 -0000 #11: Section 1.1 - para 'Provisioning' spelling errors s/subject that an/subject than an/ s/by by/by/ -- ---------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: trivial | Milestone: Component: arch | Version: Severity: - | Keywords: ---------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:32:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3967821F8B04 for ; Sat, 10 Dec 2011 16:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBUETP3Zy460 for ; Sat, 10 Dec 2011 16:32:56 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 026B121F8B01 for ; Sat, 10 Dec 2011 16:32:51 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZXLO-0008IS-GA; Sat, 10 Dec 2011 19:32:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:32:42 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/12 Message-ID: <062.5422dec07d3b886db616f56b37f560ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211003252.026B121F8B01@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:32:51 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #12: Section 1.1. - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:32:57 -0000 #12: Section 1.1. - AAA vs RADIUS vs DIAMETER terms We have defined a IdP as containing a radius server. Issue #1 is should radius always be capitalized? Issue #2 At this point - should we say that we use the term RADIUS as being either RADIUS or DIAMETER? -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:35:55 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DECD21F8B12 for ; Sat, 10 Dec 2011 16:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXj8euP-4iEk for ; Sat, 10 Dec 2011 16:35:54 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 84DAB21F8B10 for ; Sat, 10 Dec 2011 16:35:53 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZXOP-0004xy-SQ; Sat, 10 Dec 2011 19:35:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:35:49 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/13 Message-ID: <062.865878ccb5d78069c4e708463a02f431@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211003554.84DAB21F8B10@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:35:53 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #13: Section 1.2 - language clarity X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:35:55 -0000 #13: Section 1.2 - language clarity version -00 Section 1.2 Old Text: Some deployments are sometimes required to deploy complex technical infrastructure, including message routing intermediaries, to offer the required technical functionality, while in other deployments those are missing. New Text suggestion: I think that the word sometimes should be removed - thus Some deployments are required -- or Deployments are sometimes required -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:36:37 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F1121F8B12 for ; Sat, 10 Dec 2011 16:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ATJVw7L+-rqt for ; Sat, 10 Dec 2011 16:36:36 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 98CE821F8B10 for ; Sat, 10 Dec 2011 16:36:36 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZXP5-0005tZ-QO; Sat, 10 Dec 2011 19:36:31 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:36:31 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/14 Message-ID: <062.50d8e84635cdbf8ba1e83740028d22f4@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211003636.98CE821F8B10@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:36:36 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #14: Section 1.2 -- spelling erro X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:36:37 -0000 #14: Section 1.2 -- spelling erro version -00 Setion 1.2 s/betweem/between/ -- ---------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: trivial | Milestone: Component: arch | Version: Severity: - | Keywords: ---------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:39:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB84C21F85A4 for ; Sat, 10 Dec 2011 16:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waOuYtmOwz73 for ; Sat, 10 Dec 2011 16:39:58 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5117521F853A for ; Sat, 10 Dec 2011 16:39:58 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZXSK-0002Mz-CB; Sat, 10 Dec 2011 19:39:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:39:52 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/15 Message-ID: <062.1c585890bc404658a4dcf3794c9f428b@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211003958.5117521F853A@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:39:58 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #15: Section 1.2 - Suggested new wording X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:39:58 -0000 #15: Section 1.2 - Suggested new wording version -00 Section 1.2 - Next to last paragraph - last sentence Current text: However, federation does not preclude the possibility relationship between the RP and the Subject, should needs dictate. Suggested new text: However, federation does not preclude the possibility of a pre-existing relationship existing between the RP and the Subject, nor that they may use the introduction to create a new long-term relationship independent of the federation. Two issues addressed - 1. some grammatical errors 2. The concept of creating a new independent relationship based on the federation introduction. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:49:28 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639C521F8507 for ; Sat, 10 Dec 2011 16:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xI1OXnG4ePbe for ; Sat, 10 Dec 2011 16:49:27 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D9D8B21F8505 for ; Sat, 10 Dec 2011 16:49:27 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZXbU-00010n-Vd; Sat, 10 Dec 2011 19:49:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:49:20 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/16 Message-ID: <062.d0e290ab8ab36ed3a610453de359878f@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211004927.D9D8B21F8505@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:49:27 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #16: Section 1.3 - Clarifications and grammer X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:49:28 -0000 #16: Section 1.3 - Clarifications and grammer version -00 s/number of such federated/number of federated/ s/has become/can become/ s/For example, a school might provide online access to grades to a parent who is also a teacher. She must clearly distinguish her role upon access./For example, a school might provide online access to a student's grades to their parents for review, and to the student's teacher for modifying the grades. A teacher who is also a parent must clearly distinguish here role upon access./ The later suggestion makes it much clearer who She is. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:52:16 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE0321F8B1D for ; Sat, 10 Dec 2011 16:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHxmGbORcmyX for ; Sat, 10 Dec 2011 16:52:16 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 11BCB21F851A for ; Sat, 10 Dec 2011 16:52:16 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZXeF-0004sv-Gv; Sat, 10 Dec 2011 19:52:11 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:52:11 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/17 Message-ID: <062.27fbd4596011813885f23634b6db806a@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211005216.11BCB21F851A@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:52:16 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #17: Section 1.3 - Clarifications X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:52:16 -0000 #17: Section 1.3 - Clarifications version -00 paragaph #2 s/identity provider a user/identity provider(s) a user/ s/but particularly/but is particularyly/ s/latter ans/latter as/ -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 16:53:07 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4D221F8B1E for ; Sat, 10 Dec 2011 16:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PgKOCbiOeGEQ for ; Sat, 10 Dec 2011 16:53:07 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E8C6C21F851A for ; Sat, 10 Dec 2011 16:53:06 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZXf4-0004tu-7q; Sat, 10 Dec 2011 19:53:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 00:53:02 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/18 Message-ID: <062.e99dde29b852641f69ab022d6955f026@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211005306.E8C6C21F851A@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 16:53:06 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #18: Section 1.3 - Missing issue? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 00:53:07 -0000 #18: Section 1.3 - Missing issue? versin -00 Should the following issue be addressed as well? In the presence of multiple federations, the naming of individuals can become murky especially if one is trying to associate a single individual from different federations. Asking a question such as does John Doe belong to an IdP (in the absence of authentication) may get an answer for the wrong John Doe. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 17:19:46 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B984921F8B10 for ; Sat, 10 Dec 2011 17:19:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRQ5ewET1LRk for ; Sat, 10 Dec 2011 17:19:46 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7B921F8AF9 for ; Sat, 10 Dec 2011 17:19:45 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZY4d-0003BI-CA; Sat, 10 Dec 2011 20:19:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 01:19:26 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/19 Message-ID: <062.3c4f1f3c7db7c1fd9c4316f9034e38c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211011946.0C7B921F8AF9@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 17:19:45 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #19: Setion 1.4 - Overview - X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 01:19:46 -0000 #19: Setion 1.4 - Overview - a) I think you might need to have a step 2a - Client Application creates a channel to the RP. This is not done by the GSS-EAP mechanism as I had originally assumed. Let's make it clear additionally that fact will be needed in order to setup the channel binding at a later time. Note that at some point there will need to be a discussion of the properties of this channel. It should also be noted that the type of channel used potentially provide different issues. b) in step 5 either /forward a RADIUS request/ or /forward RADIUS requests/. AAA ignorance - would message be better than request to avoid confusion between RADISU request and GSS/EAP request? c) Step #5 - I would ignore how the SAML request is encoded at this point. So maybe s/SAML request as a series of attributes/ SAML request for a set of attributes/ s/.././ d) in step 9, I think I have a problem with the last sentence. These policy checks would have been done by the AAA system or the RP and not by the IdP. As such I don't think the title for the paragraph makes sense. e) Step 10, Is the sentence at the end of the paragraph wrong? Is it returned to the subject (not covered by the title) or the RP? The subject should already have the MSK. There is a difference between two types of EAP procedures. One where the MSK is published to the Principle and one where the Principle derives the key (thus allowing for mutual auth to occur). I believe that the trust model is requiring the later. Also note - subject should be principle in this text. f) I don't understand part of step 11 -- It may have information that leads it to make additional attribute queries. I can see it needing to make additional attributes because it needs more information, but not because it has the information it needs. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 17:22:13 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591FF21F8B10 for ; Sat, 10 Dec 2011 17:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud1bPT1kJtKL for ; Sat, 10 Dec 2011 17:22:13 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id E60E821F8AF9 for ; Sat, 10 Dec 2011 17:22:12 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZY7F-0007pL-39; Sat, 10 Dec 2011 20:22:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 01:22:09 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/20 Message-ID: <062.cfa02a9afc09132a4c9e05582acc5b72@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211012212.E60E821F8AF9@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 17:22:12 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #20: Section 1.4 - digaram correction X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 01:22:13 -0000 #20: Section 1.4 - digaram correction version -00 The text "(11)" should be placed in the column for the "Relying Party". -- ---------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: trivial | Milestone: Component: arch | Version: Severity: - | Keywords: ---------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 17:26:30 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 032C321F8B17 for ; Sat, 10 Dec 2011 17:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3uFrLyVC5+K for ; Sat, 10 Dec 2011 17:26:29 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 840A621F8B13 for ; Sat, 10 Dec 2011 17:26:29 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZYBM-0007Bm-5H; Sat, 10 Dec 2011 20:26:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 01:26:24 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/21 Message-ID: <062.8e8ef92949e597f22e96182810416b6c@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211012629.840A621F8B13@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 17:26:29 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #21: Section 2 - clarification needed for 'end party' X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 01:26:30 -0000 #21: Section 2 - clarification needed for 'end party' version -00 In paragraph #2 is the text Although this architecture assumes updates to both the relying party as well as to the end host for application integration What is the end host in this case? THe client or the IdP or the AAA proxy? -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 17:27:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 947DB21F8B2E for ; Sat, 10 Dec 2011 17:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Kwur7oOI-Df for ; Sat, 10 Dec 2011 17:27:10 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA8B21F8B17 for ; Sat, 10 Dec 2011 17:27:10 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZYC3-00019z-FQ; Sat, 10 Dec 2011 20:27:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 01:27:07 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/22 Message-ID: <062.cb320f023c7eba19e248bf6039db1613@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211012710.2CA8B21F8B17@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 17:27:10 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #22: Section 2.1 -- typo X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 01:27:10 -0000 #22: Section 2.1 -- typo version -00 section 2.1 para #1 s/connumication/communication/ -- ---------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: trivial | Milestone: Component: arch | Version: Severity: - | Keywords: ---------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 18:25:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC86321F8AE1 for ; Sat, 10 Dec 2011 18:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WzsseR-ztfY for ; Sat, 10 Dec 2011 18:25:01 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6B59C21F853A for ; Sat, 10 Dec 2011 18:25:01 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZZ5o-0006Xg-RO; Sat, 10 Dec 2011 21:24:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 02:24:43 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 Message-ID: <062.f26fe2a37815bb2e2190faaf5be74b08@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211022501.6B59C21F853A@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 18:25:01 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #23: Section 2.1.1 - Clarifications and typos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 02:25:02 -0000 #23: Section 2.1.1 - Clarifications and typos version -00 1. The rules determinaion in pagraph #2 might want to refer to levels of assurence which is one of th4e ways in figuring out some of these issues. Note that this may need to change how the realm of the NAI is going to be determined if you are looking ath the routing issues in paragraph #1 2. Paragraph #3 is ambigious in at least one respect. I am not clear if the question is one of the RP relying on the IdP in roder to get a decision, or if the text is saying if the IdP is going to agree to talk to the RP. This should be clarified. I believe that both sides of this question need to be covered - but in separate locations. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 18:26:39 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF0021F8B23 for ; Sat, 10 Dec 2011 18:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3GbsTto58fG for ; Sat, 10 Dec 2011 18:26:39 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFCE21F853A for ; Sat, 10 Dec 2011 18:26:39 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZZ7Z-0002g2-QM; Sat, 10 Dec 2011 21:26:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 02:26:33 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/24 Message-ID: <062.43fe269e2b549bf525737a130e8baf4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211022639.6EFCE21F853A@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 18:26:39 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #24: Section 2.3 - typeo X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 02:26:40 -0000 #24: Section 2.3 - typeo version -00 s/support e Simple/support the Simple/ -- ---------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: trivial | Milestone: Component: arch | Version: Severity: - | Keywords: ---------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 18:30:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D0A21F8B2E for ; Sat, 10 Dec 2011 18:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uciOYIqn0WtF for ; Sat, 10 Dec 2011 18:30:29 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7C01921F8B23 for ; Sat, 10 Dec 2011 18:30:29 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZZBJ-0006mj-L1; Sat, 10 Dec 2011 21:30:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 02:30:25 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/25 Message-ID: <062.a452be6f2a3ca8d1b2eaa8a7e3088d4f@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211023029.7C01921F8B23@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 18:30:29 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #25: Section 2.4 - Section title is confusing X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 02:30:30 -0000 #25: Section 2.4 - Section title is confusing I don't understand what the section title is suppose to be refering to. This is esp true since the word personalization does not appear in the section text itself. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 18:31:57 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0DB21F8B37 for ; Sat, 10 Dec 2011 18:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.287 X-Spam-Level: X-Spam-Status: No, score=-102.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5mjvvqwq5gy for ; Sat, 10 Dec 2011 18:31:57 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5429E21F8B36 for ; Sat, 10 Dec 2011 18:31:57 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZZCk-0004ZH-Of; Sat, 10 Dec 2011 21:31:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 02:31:54 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/26 Message-ID: <062.86c3874cfd3d79c73e5f5811bb37ce1a@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211023157.5429E21F8B36@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 18:31:57 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #26: Section 2.5 - Setion contains a picture but no discriptive text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 02:31:58 -0000 #26: Section 2.5 - Setion contains a picture but no discriptive text Descriptive text should be included to talk about figure 2 in some way. Either that or this diagram is in the wrong place. Like maybe it should be at the very front and a discussion of the different parts in a glossary form should be done.l -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 18:35:35 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C96C21F854E for ; Sat, 10 Dec 2011 18:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyzR3Ctxg3z3 for ; Sat, 10 Dec 2011 18:35:34 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8596221F8548 for ; Sat, 10 Dec 2011 18:35:34 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZZGD-00033X-DC; Sat, 10 Dec 2011 21:35:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 02:35:29 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/27 Message-ID: <062.66220d434bcbf9a46583666c519b6576@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211023534.8596221F8548@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 18:35:34 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #27: Setion 3.1 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 02:35:35 -0000 #27: Setion 3.1 version -00 1. I would suggest that the title of this section be changed as it does not say who is being authenticated. Possibly "Server/Client Mutual Authentication" 2. Please expand on the difference between bullets 1 and 2 in this section. It appears to me that the first sentence in both sections are saying the same thing - that the initiator trusts that the name it has given for the target name/acceptor correctly names and describes the acceptor. If there is a difference in these concepts I for one don't understand it from the text. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 18:59:07 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3F821F87E2 for ; Sat, 10 Dec 2011 18:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B0agUantrb6 for ; Sat, 10 Dec 2011 18:59:07 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0321F84E5 for ; Sat, 10 Dec 2011 18:59:06 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZZcw-00040s-Ph; Sat, 10 Dec 2011 21:58:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 02:58:58 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/2#comment:1 Message-ID: <077.1e13983a43418fe5df611c6f1ba6c0f2@trac.tools.ietf.org> References: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <062.7a1a83e17b758967b77b9a91b0ada7b5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211025907.5EF0321F84E5@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 18:59:06 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #2: Section 1.4 - No discussion of transport GSS-API is running over X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 02:59:07 -0000 #2: Section 1.4 - No discussion of transport GSS-API is running over Comment (by ietf@…): Sam suggested a referene to 2743 might satisfy this. I think this is probably the case, but a more detailed reference than just the document would be needed. Current requirements (per sam) The application must transport the context tokens in order otherwise the authentication will fail. There are other implicit requirements like messages that are not received cannot be processed. RFC 2743 talks a bit about potential token sizes and I guess that might be an issue. -- --------------------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: Active WG Document | Resolution: Keywords: | --------------------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 19:12:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B159921F85A8 for ; Sat, 10 Dec 2011 19:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWLDfhbGPQ6R for ; Sat, 10 Dec 2011 19:12:10 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 39C6721F85A7 for ; Sat, 10 Dec 2011 19:12:09 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZZpU-0002Xy-TL; Sat, 10 Dec 2011 22:11:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 03:11:56 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/28 Message-ID: <062.6d0caaa3bde28c503e5a4879aaaf29db@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211031210.39C6721F85A7@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 19:12:09 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #28: Missing Security Consideration - AAA protection of the MSK X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 03:12:10 -0000 #28: Missing Security Consideration - AAA protection of the MSK The document needs to discuss the protections (or lack there of) for the MSK as it travels from the IdP to the RP. Known issues are: 1. In RADIUS the security (encryption and authentication) is hop to hop -so in theory any AAA proxy can decrypt the messages. 2. In Diameter there is no(?) current ability to encrypt either hop to hop or end-to-end. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Dec 10 19:31:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F56621F8AFB for ; Sat, 10 Dec 2011 19:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8eyVTcl81Rr for ; Sat, 10 Dec 2011 19:31:39 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7528E21F8797 for ; Sat, 10 Dec 2011 19:31:38 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RZa8J-0006Sv-Mp; Sat, 10 Dec 2011 22:31:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 11 Dec 2011 03:31:22 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/29 Message-ID: <062.02e3ffc16252077000a0c1c061478ccd@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20111211033139.7528E21F8797@ietfa.amsl.com> Resent-Date: Sat, 10 Dec 2011 19:31:38 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: [abfab] #29: More explicity discussions of the communication channels with the end-points, cryptography and channel binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 03:31:40 -0000 #29: More explicity discussions of the communication channels with the end- points, cryptography and channel binding On May 1 I wrote a message with the following text: I think that I am getting some of the terms straight. What I think I have problems with is the requirements and points at which things occur. The following is a list of the "channels" that I believe exist in the current abfab architecture (Please forgive the names that I am using as they are made up on the spot): 1. Client to RP transport channel - This would be the TLS channel that exists between the client and the RP. The channel binding material is provided by any certificates and the final message (i.e. a cryptographic token for the channel). This will normally be either a one-way authentication of identity (i.e. the client knows who the RP is) or a zero-way authentication of identity (i.e. anonymous on both sides). It could be a mutual authentication, but in that case there would be no reason to involve the entire abfab architecture except potentially for assignment of privileges. 2. Client to RP GSS-API channel - This is slightly weird to think of as a channel as it is going to be a channel between the requestor and the acceptor, but the keying material is provided by a "third party" to both entities. (My understanding is that the client can derive this material on its own, but the RP gets the material from the IdP.) There is no cryptographic binding on this channel until the EAP processing has totally finished and the MSK is transferred from the IdP to the RP - i.e. after the client/IdP authentication has completed. 3. RP to IdP channel - This is the weakest of the communication channels in terms of authentication and security. Most of these hops are going to be point-to-point and anybody in the middle can play with the data that is being transferred in either direction. The base architecture is responsible for providing any authentication assurances between the RP and the IdP. All authentication is fully established prior to the EAP conversation between the client and the IdP. 4. Client to IdP - This is the EAP channel. It has the strongest mutual authentication between that exists. We have stated that the IdP is responsible during this processing to determine that the RP that is communication to the client over channel #3 (Rp to IdP) and the one talking between the client the RP (channel #1?) are going to be the same entity as the client provides the IdP it's version of the RP name during the EAP conversation. Thus it needs to reconcile the name forms between channel #1 and channel #3 during this authentication process. At this point channel #2 and channel #4 are known to have cryptographic protections. Channel #1 and channel #3 may or may not have cryptographic protections. We need to specify what level of services are provided in these channels and how important those services are. ** It was followed up by a couple of notes by sam, myself and nico. I believe that the outcome was that we should get a clear discription of the different communication channels, the set of cryptographic operations/keys offered by each, and the channel binding opertions (type of binding and what it accomplishes) for each channel would be useful. -- --------------------+------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Keywords: --------------------+------------------------------------- Ticket URL: abfab From leifj@sunet.se Sun Dec 11 03:08:03 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6764321F8A67 for ; Sun, 11 Dec 2011 03:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGaXcfINXhen for ; Sun, 11 Dec 2011 03:08:02 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 3180021F89B8 for ; Sun, 11 Dec 2011 03:08:00 -0800 (PST) Received: from [172.20.10.8] (2.67.73.229.mobile.tre.se [2.67.73.229]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBBB7ia5001894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 11 Dec 2011 12:07:51 +0100 (CET) References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> X-Mailer: iPad Mail (8L1) From: Leif Johansson Date: Sun, 11 Dec 2011 12:09:36 +0100 To: Nico Williams Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 11:08:03 -0000 9 dec 2011 kl. 21:50 skrev Nico Williams : > On Fri, Dec 9, 2011 at 2:43 PM, Sam Hartman > wrote: >> I think it is fairly likely that the IDP and RP will have the software >> to do normal SAML things, but in some of the deployments we're looking >> at will not have the provisioning (keys, metadata etc) to do SAML over >> HTTP. >=20 > And I wouldn't want to encourage reliance on the HTTPS PKI. >=20 > However, what could be done is that an attribute with a URI could also > have a digest of the thing to be fetched via HTTP, and maybe a digest > of the server cert or an intermediate CA for it (or perhaps a key that > the actual attribute payload will be encrypted in, that way we can use > plain HTTP). But this starts sounding hairy. >=20 Drop the cert bits and you're essentially describing the way openid connect u= ses a resource token (oauth) to de-reference attributes. >> Also, I actually think there will be intermediates that will want to >> rewrite attributes. >=20 > I imagine so. I can see several reasons: 1) to rewrite attributes > understood by one side into attributes understood by the other, 2) to > apply privacy policies. (2) might be common in a deployment with a > common, trusted trust broker, so to speak. >=20 > Nico > -- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From diego@tid.es Sun Dec 11 09:43:11 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A76621F84B0 for ; Sun, 11 Dec 2011 09:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSqV6s+b0mVb for ; Sun, 11 Dec 2011 09:43:11 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF5121F84AD for ; Sun, 11 Dec 2011 09:43:10 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW10057AVVW9U@tid.hi.inet> for abfab@ietf.org; Sun, 11 Dec 2011 18:43:09 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 0C.25.04893.407F4EE4; Sun, 11 Dec 2011 19:31:32 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LW100573VVW9U@tid.hi.inet> for abfab@ietf.org; Sun, 11 Dec 2011 18:43:08 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Sun, 11 Dec 2011 18:43:08 +0100 Date: Sun, 11 Dec 2011 18:43:07 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> To: Leif Johansson Message-id: <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] 4K limit Thread-index: Acy4LFfjdQLwvQyqQcukshcgEBbCWw== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f4c6d00000131d-a9-4ee4f70414b5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsXCFe/Apcvy/YmfwatJyhYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRs/uC2wFJwQq/p/6zt7AOEGgi5GTQ0LAROLBrv3MELaYxIV7 69m6GLk4hAQ2MEpcXHOJEcL5wSjRtH0aC4TTyCjxu/MqUBkHB4uAqsTlrzUg3WwC6hItR7+x gNjCArISc45vZwWxOQVsJGb0rgTbICKgLLH12n8mkFZmAR+Jnv+cIGFeAUuJif09jBC2oMSP yfdYIErUJaZMyQUJMwuISzS33mSBsBUlpi1qACtnBLr5+6k1YBNFBOQkbi6KgFikJ/H9zn6o ElGJO+3rGSFeFJBYsuc81LuiEi8f/2OFeGo2s8TmN3eZJzCKz0JyxSyEK2YhuWIWkisWMLKs YhQrTirKTM8oyU3MzEk3MNTLyNTLzEst2cQIiaCMHYzLd6ocYhTgYFTi4V2g8NBPiDWxrLgy 9xCjJAeTkigv78snfkJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeO3uAuV4UxIrq1KL8mFSMhwc ShK8714BpQSLUtNTK9Iyc4BpAibNxMEJ0s4D1K7xGqS9uCAxtzgzHSJ/ilFSSpyXGyQhAJLI KM2D633FKA50pDCvPEiWB5jQ4LpeAQ1kAhoYlwI2sCQRISXVwHhQkVl/yof4WP0lnxdeytJQ 2Ol8iVE9Yen2y2z/7cT37kh8b2As+c/wwxnJDXNkZ6Wsy26Z/kb7c+TDpduXlCefO+PIGlDN JPqwZgZnyT7BD0ubFHk+KCsWXYnoDWTepMD9dPO8vNdyv2/tO6DwW6/WzuNeiHcNT9WXN59S vL0WFxV93S5/5YASS3FGoqEWc1FxIgAJ0l0lJQMAAA== References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 17:43:11 -0000 DQpPbiAxMSBEZWMgMjAxMSwgYXQgMTI6MDkgLCBMZWlmIEpvaGFuc3NvbiB3cm90ZToNCj4gOSBk ZWMgMjAxMSBrbC4gMjE6NTAgc2tyZXYgTmljbyBXaWxsaWFtcyA8bmljb0BjcnlwdG9uZWN0b3Iu Y29tPjoNCj4+IEhvd2V2ZXIsIHdoYXQgY291bGQgYmUgZG9uZSBpcyB0aGF0IGFuIGF0dHJpYnV0 ZSB3aXRoIGEgVVJJIGNvdWxkIGFsc28NCj4+IGhhdmUgYSBkaWdlc3Qgb2YgdGhlIHRoaW5nIHRv IGJlIGZldGNoZWQgdmlhIEhUVFAsIGFuZCBtYXliZSBhIGRpZ2VzdA0KPj4gb2YgdGhlIHNlcnZl ciBjZXJ0IG9yIGFuIGludGVybWVkaWF0ZSBDQSBmb3IgaXQgKG9yIHBlcmhhcHMgYSBrZXkgdGhh dA0KPj4gdGhlIGFjdHVhbCBhdHRyaWJ1dGUgcGF5bG9hZCB3aWxsIGJlIGVuY3J5cHRlZCBpbiwg dGhhdCB3YXkgd2UgY2FuIHVzZQ0KPj4gcGxhaW4gSFRUUCkuICBCdXQgdGhpcyBzdGFydHMgc291 bmRpbmcgaGFpcnkuDQo+Pg0KPg0KPiBEcm9wIHRoZSBjZXJ0IGJpdHMgYW5kIHlvdSdyZSBlc3Nl bnRpYWxseSBkZXNjcmliaW5nIHRoZSB3YXkgb3BlbmlkIGNvbm5lY3QgdXNlcyBhIHJlc291cmNl IHRva2VuIChvYXV0aCkgdG8gZGUtcmVmZXJlbmNlIGF0dHJpYnV0ZXMuDQoNCkJ1dCBpbiBPcGVu SUQgQ29ubmVjdCB0aGUgdG9rZW4gaXMgdXNlZCB0byBnZXQgYWNjZXNzIHRvIHRoZSBhdHRyaWJ1 dGVzLCBub3QgZm9yIGVzdGFibGlzaGluZyB0cnVzdCBiZWV0d2VuIHRoZSBSUCAodGhlIGNsaWVu dCBpbiBPcGVuSUQgcGFybGFuY2UpIGFuZCB0aGUgYXR0cmlidXRlIHNvdXJjZS4gQXMgQWxhbiBz dGF0ZWQsIGdvaW5nIHRoaXMgd2F5IHlvdSBjYW5ub3QgZ2V0IHJpZCBvZiB0aGUgbmVlZCBmb3Ig dHdvIHBhcmFsbGVsIHRydXN0IGluZnJhc3RydWN0dXJlcywgYW5kIEkgdGhpbmsgdGhhdCBpcyB0 aGUgZXNzZW50aWFsIGFyZ3VtZW50IGZvciB0cmFuc2ZyZXJyaW5nIHRoZSBTQU1MIGRhdGEgaW5z aWRlIFJBRElVUy4NCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywg RG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCg0K ZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTog KzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5h dGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNl cGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBh YmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJl c3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUg dGVybXMgc2V0IG91dCBhdC4NCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1l ci5hc3B4DQo= From klaas@cisco.com Sun Dec 11 10:56:04 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A72921F84B5 for ; Sun, 11 Dec 2011 10:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-fZvpAOwF4t for ; Sun, 11 Dec 2011 10:56:03 -0800 (PST) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id 45A5E21F84B3 for ; Sun, 11 Dec 2011 10:56:03 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pBBItv3X025965; Sun, 11 Dec 2011 19:55:58 +0100 Received: from rtp-isp-nat1.cisco.com ([64.102.254.33] helo=[10.116.7.36]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RZoXM-0008be-FV; Sun, 11 Dec 2011 19:54:12 +0100 References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> In-Reply-To: <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9A405) From: Klaas Wierenga Date: Sun, 11 Dec 2011 19:55:57 +0100 To: DIEGO LOPEZ GARCIA X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vG7STV2R - 933c91e48b41 - 20111211 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.45 Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2011 18:56:04 -0000 Sent from my iPad On 11 dec. 2011, at 18:43, "DIEGO LOPEZ GARCIA" wrote: >=20 > On 11 Dec 2011, at 12:09 , Leif Johansson wrote: >> 9 dec 2011 kl. 21:50 skrev Nico Williams : >>> However, what could be done is that an attribute with a URI could also >>> have a digest of the thing to be fetched via HTTP, and maybe a digest >>> of the server cert or an intermediate CA for it (or perhaps a key that >>> the actual attribute payload will be encrypted in, that way we can use >>> plain HTTP). But this starts sounding hairy. >>>=20 >>=20 >> Drop the cert bits and you're essentially describing the way openid conne= ct uses a resource token (oauth) to de-reference attributes. >=20 > But in OpenID Connect the token is used to get access to the attributes, n= ot for establishing trust beetwen the RP (the client in OpenID parlance) and= the attribute source. As Alan stated, going this way you cannot get rid of t= he need for two parallel trust infrastructures, and I think that is the esse= ntial argument for transfrerring the SAML data inside RADIUS. Yeah, I guess that makes sense, thanks for indulging.... Klaas >=20 > Be goode, >=20 > -- > "Esta vez no fallaremos, Doctor Infierno" >=20 > Dr Diego R. Lopez > Telefonica I+D >=20 > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- >=20 >=20 > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar n= uestra pol=C3=ADtica de env=C3=ADo y recepci=C3=B3n de correo electr=C3=B3ni= co en el enlace situado m=C3=A1s abajo. > This message is intended exclusively for its addressee. We only send and r= eceive email on the basis of the terms set out at. > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nico@cryptonector.com Sun Dec 11 17:21:52 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B7121F84FA for ; Sun, 11 Dec 2011 17:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.765 X-Spam-Level: X-Spam-Status: No, score=-1.765 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcTiJe83H0nK for ; Sun, 11 Dec 2011 17:21:51 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 447FD21F84D7 for ; Sun, 11 Dec 2011 17:21:51 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id C672F1F0084 for ; Sun, 11 Dec 2011 17:21:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=nr0mr+NFZsvscZiI01sHx/iaDgzMbWrEjhSxcAg+GzgL Tkpgv55Oj4PldWDzaCUeiOmMf9lUs85waKozmJtCf/zkDmeKan/3McT+JionUsiZ dC+GfMCd9VMJyKdnvYYjq06p+vboSYRwVPHNd+RV5uC6teCntZ97zYAthxM17sc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=63jNM7ueJmSmJivBWWrcPzIDJgw=; b=OhiadHDALZc zvi3np0KkjKMjFwSeS5Pc36yOWWxgzAu5ogNaR+lIRj3ZRusAWPBdE0DCe7cE2pN 6evSsW7cWLGAGWrJ1YqKPAKS5KVxn4KjUT7dFxZJUUsy0LhPvnR8ZY9PF1LwO13m eaaGSI5OLr/scMlE+lfQaCVLa3Vt+KAs= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id A67D41F0083 for ; Sun, 11 Dec 2011 17:21:49 -0800 (PST) Received: by dajz8 with SMTP id z8so6122944daj.31 for ; Sun, 11 Dec 2011 17:21:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.8 with SMTP id z8mr28680302pbu.111.1323652909101; Sun, 11 Dec 2011 17:21:49 -0800 (PST) Received: by 10.68.73.4 with HTTP; Sun, 11 Dec 2011 17:21:48 -0800 (PST) In-Reply-To: <062.02e3ffc16252077000a0c1c061478ccd@trac.tools.ietf.org> References: <062.02e3ffc16252077000a0c1c061478ccd@trac.tools.ietf.org> Date: Sun, 11 Dec 2011 19:21:48 -0600 Message-ID: From: Nico Williams To: abfab issue tracker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ietf@augustcellars.com, draft-ietf-abfab-arch@tools.ietf.org, abfab@ietf.org Subject: Re: [abfab] #29: More explicity discussions of the communication channels with the end-points, cryptography and channel binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 01:21:52 -0000 On Sat, Dec 10, 2011 at 9:31 PM, abfab issue tracker wrote: > =C2=A0The following is a list of the "channels" that I believe exist in t= he > =C2=A0current abfab architecture =C2=A0(Please forgive the names that I a= m using as > =C2=A0they are made up on the spot): > > =C2=A01. =C2=A0Client to RP transport channel - This would be the TLS cha= nnel that > =C2=A0exists between the client and the RP. [...] > =C2=A02. =C2=A0Client to RP GSS-API channel - This is slightly weird to t= hink of as a While the GSS-API "security context" (GSS term) is indeed a channel just as much as TLS is a channel, it is best to think of GSS-API w/ channel binding as an extension to TLS. Suppose we were to propose extensions to TLS that provide us with federated mutual authentication and an attribute-based authorization model. It'd be hard enough to get consensus for such extensions to TLS, but then to get those extensions implemented by all the major TLS implementations would take a long time. Then consider that a common design for channels that provide authentication is to separate key exchange from authentication but then bind them (e.g., SSHv2, client certs in TLS, ...). By using GSS and channel binding we achieve almost exactly what could have been a TLS extension, and we do it in much the same sort of way that we might have done it as a TLS extension: separate authentication from key exchange, then bind the two so that the exchanged keys "speak for" the authenticated entities. Also, the GSS channel is thrown away as soon as we're done with setting it up and doing the channel binding operation. Before channel binding we had applications like IMAP and LDAP where there was the option to use *two* channels (TLS and GSS, with GSS being a channel proper when its per-message protection facilities were used). Using two channels, one inside the other, is quite wasteful, both in terms of runtime resources (double the crypto) and software engineering (since it complicates application architecture and requires more code). Worse, there may be no way for the application to securely negotiate among authentication options when using the old SASL/GSSAPI bridge without ending up with nested channels in some cases. This is one critical reason that we pursued SASL/GS2 to replace the old SASL/GSSAPI bridge. Long story short: better to think of GSS w/ CB to TLS as an extension to TL= S. > =C2=A0channel as it is going to be a channel between =C2=A0the requestor = and the > =C2=A0acceptor, but the keying material is provided by a "third party" to= both > =C2=A0entities. =C2=A0(My understanding is that the client can derive thi= s material This depends on the mechanism. Some GSS mechanisms involve a third party and some don't. Federated authentication involves third parties by definition. (Yes, this is a nit.) > =C2=A0on its own, but the RP gets the material from the IdP.) =C2=A0There= is no > =C2=A0cryptographic binding on this channel until the EAP processing has = totally > =C2=A0finished and the MSK is transferred from the IdP to the RP - i.e. a= fter > =C2=A0the client/IdP authentication has completed. I'm not sure what you're getting at with this. A round-trip optimization i= ssue? > =C2=A04. Client to IdP - This is the EAP channel. =C2=A0It has the strong= est mutual > =C2=A0authentication between that exists. =C2=A0We have stated that the I= dP is > =C2=A0responsible during this processing to determine that the RP that is > =C2=A0communication to the client over channel #3 (Rp to IdP) and the one > =C2=A0talking between the client the RP (channel #1?) are going to be the= same > =C2=A0entity as the client provides the IdP it's version of the RP name d= uring > =C2=A0the EAP conversation. =C2=A0Thus it needs to reconcile the name for= ms between > =C2=A0channel #1 and channel #3 during this authentication process. We should not care at all about reconciliation of the RP names from channels #1 and #3. Whenever the GSS mechanism provides acceptable authentication of the RP to the client we can simply ignore the RP name from TLS. And if the GSS mechanism does not provide authentication of the RP to the client then we have no real channel binding, and no need to reconcile RP names anyways. > =C2=A0At this point channel #2 and channel #4 are known to have cryptogra= phic > =C2=A0protections. =C2=A0Channel #1 and channel #3 may or may =C2=A0not h= ave cryptographic > =C2=A0protections. =C2=A0We need to specify what level of services are pr= ovided in > =C2=A0these channels and how important those services are. Channel #1 (TLS) is always going to be providing cryptographic protection (end-to-end) for client<->RP communications. Channel #1 may not provide any authentication -- is that what you meant? > =C2=A0** > > =C2=A0It was followed up by a couple of notes by sam, myself and nico. = =C2=A0I > =C2=A0believe that the outcome was that we should get a clear discription= of the > =C2=A0different communication channels, the set of cryptographic operatio= ns/keys > =C2=A0offered by each, and the channel binding opertions (type of binding= and > =C2=A0what it accomplishes) for each channel would be useful. I agree. The picture is relatively simple if viewed as follows: we have a) TLS providing session services, b) GSS providing client<->RP mutual authentication, and with channel binding to TLS it's almost as if GSS were part of TLS, c) the specific GSS mechanism in our case provides authentication by way of one or more third parties. (a) is really entirely optional for applications, except that we expect it to be part of every application protocol that hews to this architecture, thus (a) is not optional to the architecture, but because (a) and everything we need for exists already, there's nothing to do to make it feasible. Nico -- From nico@cryptonector.com Sun Dec 11 20:33:45 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94CD21F851A for ; Sun, 11 Dec 2011 20:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_41=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZcbdMV5RSxh for ; Sun, 11 Dec 2011 20:33:45 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C621F8508 for ; Sun, 11 Dec 2011 20:33:45 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id CA63D7E4062 for ; Sun, 11 Dec 2011 20:33:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=wwFxqOEMM191xzgIQBQSoSzA527KDL5sNtF0hzgMhfh1 y0OHaVDPOkHDRQgYMy7hy3m/EQq1dVdoqzFMJfNCgDp8/4zYUUzZy7E6cVYvkq20 33wHlfYG+p26xTAgps08QU8Zy509cWcHXSetM98VUuxjTRNnHvgHfDAhZubu6Ag= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=9WTVTcyq4lclJla6UCnV6V7+N1s=; b=kVf8+H1z3vt QU8Y6NN8EbskcXBJ8rdbbNxJntBwlzb1gIKUnNxCfKIzYtVKmNLdu0lXDhzch9wV hwfwz4hG5f1wHLUpzw+q44fBlZDVJ+wEk/n/o7Py/QBj32UkKlxm4dWMg3Nxjczx cqW+J7cCES61OR421qEi2RMIC6qV9HqY= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id AF9447E4058 for ; Sun, 11 Dec 2011 20:33:44 -0800 (PST) Received: by pbbb4 with SMTP id b4so1309073pbb.31 for ; Sun, 11 Dec 2011 20:33:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.75.199 with SMTP id e7mr30304814pbw.128.1323664424162; Sun, 11 Dec 2011 20:33:44 -0800 (PST) Received: by 10.68.73.4 with HTTP; Sun, 11 Dec 2011 20:33:44 -0800 (PST) In-Reply-To: <062.86c3874cfd3d79c73e5f5811bb37ce1a@trac.tools.ietf.org> References: <062.86c3874cfd3d79c73e5f5811bb37ce1a@trac.tools.ietf.org> Date: Sun, 11 Dec 2011 22:33:44 -0600 Message-ID: From: Nico Williams To: abfab issue tracker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ietf@augustcellars.com, draft-ietf-abfab-arch@tools.ietf.org, abfab@ietf.org Subject: Re: [abfab] #26: Section 2.5 - Setion contains a picture but no discriptive text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 04:33:45 -0000 On Sat, Dec 10, 2011 at 8:31 PM, abfab issue tracker wrote: > #26: Section 2.5 - Setion contains a picture but no discriptive text > > =C2=A0Descriptive text should be included to talk about figure 2 in some = way. > =C2=A0Either that or this diagram is in the wrong place. =C2=A0Like maybe= it should > =C2=A0be at the very front and a discussion of the different parts in a g= lossary > =C2=A0form should be done.l Also, the legend is wrong. The end-to-end and hop-by-hop legends are swapp= ed. Nico -- From leifj@sunet.se Mon Dec 12 00:50:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F8621F8AB8 for ; Mon, 12 Dec 2011 00:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx52eB1OSWsN for ; Mon, 12 Dec 2011 00:50:40 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9961821F8AB0 for ; Mon, 12 Dec 2011 00:50:38 -0800 (PST) Received: from [109.105.104.174] (dhcp40.se-tug.nordu.net [109.105.104.174] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBC8oRlv004708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Dec 2011 09:50:30 +0100 (CET) Message-ID: <4EE5C053.9050707@sunet.se> Date: Mon, 12 Dec 2011 09:50:27 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> In-Reply-To: <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 08:50:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2011 06:43 PM, DIEGO LOPEZ GARCIA wrote: > > On 11 Dec 2011, at 12:09 , Leif Johansson wrote: >> 9 dec 2011 kl. 21:50 skrev Nico Williams >> : >>> However, what could be done is that an attribute with a URI >>> could also have a digest of the thing to be fetched via HTTP, >>> and maybe a digest of the server cert or an intermediate CA for >>> it (or perhaps a key that the actual attribute payload will be >>> encrypted in, that way we can use plain HTTP). But this starts >>> sounding hairy. >>> >> >> Drop the cert bits and you're essentially describing the way >> openid connect uses a resource token (oauth) to de-reference >> attributes. > > But in OpenID Connect the token is used to get access to the > attributes, not for establishing trust beetwen the RP (the client > in OpenID parlance) and the attribute source. As Alan stated, going > this way you cannot get rid of the need for two parallel trust > infrastructures, and I think that is the essential argument for > transfrerring the SAML data inside RADIUS. Sorry. I thought dereferencing an attribute handle was exactly what Nico was talking about here. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7lwFMACgkQ8Jx8FtbMZnfkIgCgiBGD9Rm3AaeA//kUF4BnZFvt eEsAoKGyunXcWgU+nX1mQNhYEdwKSANk =fzI7 -----END PGP SIGNATURE----- From nico@cryptonector.com Mon Dec 12 07:59:44 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CD421F8B12 for ; Mon, 12 Dec 2011 07:59:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJSiIPcyyYmW for ; Mon, 12 Dec 2011 07:59:44 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3D09621F8888 for ; Mon, 12 Dec 2011 07:59:44 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id C16DC67C072 for ; Mon, 12 Dec 2011 07:59:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=acRI0GcCswklSTRbjGqAS DfJ/3+/abhVlDe0maxDGjG9cglQ2l1k/zN6OxO4DAsZ1PLRV5bSEQENiREDbGArn frU4N8HrY1aSAux1zMggWNzTMPBLfE4JGhm3fjNChtksoCSdQzVNODUCFJxpEs22 S/CD0IVEJW8tuKUV1wz25Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=zpn+LyCejEw2DfODree1 DQOCpqw=; b=bbm0C8BZa1cYFiMv672xaRSfX7d6CeexwoZuv+NAvTooygwFhYd0 xavNhnOlwlNXI7IpYAEgaxxPhdQaYgYlkpvv7dIvJt1hU514PIEhcaxoOPHUUVMD TsRMoKapUTK1SViPI/atNn3FDR4MHXf09IkkNrgDF26ZH6c2inR8XEw= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id A88D567C06B for ; Mon, 12 Dec 2011 07:59:43 -0800 (PST) Received: by pbbb4 with SMTP id b4so1593449pbb.31 for ; Mon, 12 Dec 2011 07:59:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.75.199 with SMTP id e7mr35338900pbw.128.1323705583286; Mon, 12 Dec 2011 07:59:43 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 12 Dec 2011 07:59:43 -0800 (PST) In-Reply-To: <4EE5C053.9050707@sunet.se> References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> <4EE5C053.9050707@sunet.se> Date: Mon, 12 Dec 2011 09:59:43 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 15:59:44 -0000 On Mon, Dec 12, 2011 at 2:50 AM, Leif Johansson wrote: > On 12/11/2011 06:43 PM, DIEGO LOPEZ GARCIA wrote: >> But in OpenID Connect the token is used to get access to the >> attributes, not for establishing trust beetwen the RP (the client >> in OpenID parlance) and the attribute source. As Alan stated, going >> this way you cannot get rid of the need for two parallel trust >> infrastructures, and I think that is the essential argument for >> transfrerring the SAML data inside RADIUS. > > Sorry. I thought dereferencing an attribute handle was exactly what > Nico was talking about here. Well. I was addressing part of the trust issue as well. Instead of simply getting a URI to dereference you'd also get some cryptographic metadata with which to authenticate either the location or the dereferenced data itself. Nico -- From klaas@cisco.com Mon Dec 12 08:06:48 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68B0321F8B5B for ; Mon, 12 Dec 2011 08:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NS11nG3t9xUo for ; Mon, 12 Dec 2011 08:06:47 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D4EAB21F8B53 for ; Mon, 12 Dec 2011 08:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1180; q=dns/txt; s=iport; t=1323706008; x=1324915608; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=i3OzlBCMkCBld0w0kkoHfqXE48WQW9lZSI+GZGUlMhQ=; b=X6M2NOiIwDF/vcnFXHLLEmrL4gjYqvN5TxA5ugmcTspCvI5QuZz2uLKa eiDbNC8WswHCs3MjJCxAX7fgTiCGBWHHFRv2Bh0JVNx9krmFCd49FGNRn QwFUSZDPRzAVAaqZTXVP61xQHSYE8NfxE1dA2sj2VMgdC6YFOiTGdFoow U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABEppk6tJXG//2dsb2JhbACeW3iIcItlkjSGGQSQEY52 X-IronPort-AV: E=Sophos;i="4.71,339,1320624000"; d="scan'208";a="40717584" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 12 Dec 2011 16:06:47 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pBCG6jie025034; Mon, 12 Dec 2011 16:06:46 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Klaas Wierenga In-Reply-To: Date: Mon, 12 Dec 2011 17:06:44 +0100 Content-Transfer-Encoding: 7bit Message-Id: <7AD16B6A-5A79-498E-ADBA-391102C3564C@cisco.com> References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> <4EE5C053.9050707@sunet.se> To: Nico Williams X-Mailer: Apple Mail (2.1251.1) Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 16:06:48 -0000 On Dec 12, 2011, at 4:59 PM, Nico Williams wrote: > On Mon, Dec 12, 2011 at 2:50 AM, Leif Johansson wrote: >> On 12/11/2011 06:43 PM, DIEGO LOPEZ GARCIA wrote: >>> But in OpenID Connect the token is used to get access to the >>> attributes, not for establishing trust beetwen the RP (the client >>> in OpenID parlance) and the attribute source. As Alan stated, going >>> this way you cannot get rid of the need for two parallel trust >>> infrastructures, and I think that is the essential argument for >>> transfrerring the SAML data inside RADIUS. >> >> Sorry. I thought dereferencing an attribute handle was exactly what >> Nico was talking about here. > > Well. I was addressing part of the trust issue as well. Instead of > simply getting a URI to dereference you'd also get some cryptographic > metadata with which to authenticate either the location or the > dereferenced data itself. yes, that is also what I had in mind when I talked about "trusted introducer" Klaas > > Nico > -- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From diego@tid.es Mon Dec 12 08:20:02 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4221F8B6D for ; Mon, 12 Dec 2011 08:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rm62HsmdKnJ3 for ; Mon, 12 Dec 2011 08:20:02 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA4AA21F8B68 for ; Mon, 12 Dec 2011 08:20:01 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW30072CMPCQA@tid.hi.inet> for abfab@ietf.org; Mon, 12 Dec 2011 17:20:00 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id FF.C2.04893.EF436EE4; Mon, 12 Dec 2011 18:08:14 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LW300727MPCQA@tid.hi.inet> for abfab@ietf.org; Mon, 12 Dec 2011 17:20:00 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 12 Dec 2011 17:19:59 +0100 Date: Mon, 12 Dec 2011 17:19:58 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: <7AD16B6A-5A79-498E-ADBA-391102C3564C@cisco.com> To: Klaas Wierenga Message-id: <2B226DF1-BDA4-420A-8372-84387FDD1985@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US Thread-topic: [abfab] 4K limit Thread-index: Acy46eULvf41azRgQZaYV0W4DQTytg== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f4c6d00000131d-eb-4ee634feec41 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsXCFe/ApfvP5JmfwexbKhYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsQj79gL+vgr1p/czNLAOImni5GTQ0LARKL79zYWCFtM4sK9 9WxdjFwcQgIbGCWaPu5jhHB+MEpc65gL5TQySvzbf4ENpIVFQFVi9+pzYDabgLpEy9FvYKOE BWQl5hzfzgpicwrYSrx5950RxBYRUJHo/3mGuYuRg4NZwEei5z8nSJhXwFJiwaoJ7BC2oMSP yffAxjAL6El8/HObEcIWl2huvQkV15Z48u4C2HhGoKu/n1rDBDJSREBO4uaiCIhNehLLJsxl gSgRlbjTvp4R4kkBiSV7zjND2KISLx//Y4V46yGLxJIHX5knMIrPQnLGLCRnzEJyxiwkZyxg ZFnFKFacVJSZnlGSm5iZk25gqJeRqZeZl1qyiRESRxk7GJfvVDnEKMDBqMTDu0DhoZ8Qa2JZ cWXuIUZJDiYlUV4L9Wd+QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4m7mBcrwpiZVVqUX5MCkZ Dg4lCV45TaCUYFFqempFWmYOMFnApJk4OEHaeYDaxUFqeIsLEnOLM9Mh8qcYJaXEef9rACUE QBIZpXlwva8YxYGOFOaVBGnjAaY1uK5XQAOZgAbGpTwBGViSiJCSamBMdr+jGRqooRm01Pu8 SpxF91M+mesG2rx6PkuyN26MsA64Ej3n9GEtyw2/eOe1Z2eyLH9znlnnq2/Ug/uGm+YEyn6u n2G887ad8EKHX/9mfJKMP/Z3z7GCRbLzD63sPHczdxLHP3+/la6zfpotmPiNo/V5+ceFxuE7 t8RfFpxmp5y42EGVlWeKEktxRqKhFnNRcSIADpzfwigDAAA= References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> <4EE5C053.9050707@sunet.se> <7AD16B6A-5A79-498E-ADBA-391102C3564C@cisco.com> Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 16:20:03 -0000 On 12 Dec 2011, at 17:06 , Klaas Wierenga wrote: > On Dec 12, 2011, at 4:59 PM, Nico Williams wrote: > >> On Mon, Dec 12, 2011 at 2:50 AM, Leif Johansson wrote: >>> On 12/11/2011 06:43 PM, DIEGO LOPEZ GARCIA wrote: >>>> But in OpenID Connect the token is used to get access to the >>>> attributes, not for establishing trust beetwen the RP (the client >>>> in OpenID parlance) and the attribute source. As Alan stated, going >>>> this way you cannot get rid of the need for two parallel trust >>>> infrastructures, and I think that is the essential argument for >>>> transfrerring the SAML data inside RADIUS. >>> >>> Sorry. I thought dereferencing an attribute handle was exactly what >>> Nico was talking about here. >> >> Well. I was addressing part of the trust issue as well. Instead of >> simply getting a URI to dereference you'd also get some cryptographic >> metadata with which to authenticate either the location or the >> dereferenced data itself. > > yes, that is also what I had in mind when I talked about "trusted introdu= cer" The point here is how much information you'd have to put in such a handle t= o establish trust (in both directions) when dereferencing it, and the addit= ional mechanisms at both sides. I guess it was Nico the one that mentioned = that this could become "hairy"=85 Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx From nico@cryptonector.com Mon Dec 12 08:47:45 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9FF21F891D for ; Mon, 12 Dec 2011 08:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOnC4Icav0oH for ; Mon, 12 Dec 2011 08:47:44 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id C9B3621F87FA for ; Mon, 12 Dec 2011 08:47:44 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 69E201F0089 for ; Mon, 12 Dec 2011 08:47:44 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 42D141F001D for ; Mon, 12 Dec 2011 08:47:44 -0800 (PST) Received: by pbbb4 with SMTP id b4so1619233pbb.31 for ; Mon, 12 Dec 2011 08:47:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.75.199 with SMTP id e7mr35648568pbw.128.1323708463848; Mon, 12 Dec 2011 08:47:43 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 12 Dec 2011 08:47:43 -0800 (PST) In-Reply-To: <2B226DF1-BDA4-420A-8372-84387FDD1985@tid.es> References: <4ED49375.9040401@um.es> <9011FC25-2C22-454D-8B57-723DCED8BC95@tid.es> <93B030C0-F7BF-4E9E-94A5-345DF89CEC4D@cisco.com> <4EE21729.6080808@deployingradius.com> <413353E4-DF77-4CB8-ADFB-61EB17551462@cisco.com> <2F058BDB-5800-40D7-836A-F8193B681BEF@sunet.se> <085D55B4-97C7-4914-9FCC-796CE1E9CE1C@tid.es> <4EE5C053.9050707@sunet.se> <7AD16B6A-5A79-498E-ADBA-391102C3564C@cisco.com> <2B226DF1-BDA4-420A-8372-84387FDD1985@tid.es> Date: Mon, 12 Dec 2011 10:47:43 -0600 Message-ID: From: Nico Williams To: DIEGO LOPEZ GARCIA Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "abfab@ietf.org" Subject: Re: [abfab] 4K limit X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 16:47:45 -0000 On Mon, Dec 12, 2011 at 10:19 AM, DIEGO LOPEZ GARCIA wrote: > The point here is how much information you'd have to put in such a handle= to establish trust (in both directions) when dereferencing it, and the add= itional mechanisms at both sides. I guess it was Nico the one that mentione= d that this could become "hairy"=E2=80=A6 If the handle were to include authentication of the referenced data then we'd have synchronization issues. If the handle were to include server authentication data that would be easier, but we'd still have revocation and key rollover issues. But if we do this hop-by-hop then those issues are not new -- it's only if we try to skip hops that we run into new issues. HTTP is just a protocol. I offer it because it doesn't have a payload size limit. Nico -- From nico@cryptonector.com Mon Dec 12 10:21:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10AE821F8538 for ; Mon, 12 Dec 2011 10:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.784 X-Spam-Level: X-Spam-Status: No, score=-1.784 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2njNPAGw95w for ; Mon, 12 Dec 2011 10:21:09 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2C21621F84CC for ; Mon, 12 Dec 2011 10:21:09 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 9E2C167808F for ; Mon, 12 Dec 2011 10:21:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=YVAhzgtHY1HeOwrX71XqDg27U5U8AzfSsE8zcB6ae/uD fcFHsgxHqvovQECPR4Y2HHTeaUy4ZUtQ45tbGf5CqYOr0TYfWUsX9lPcPpn4JRI2 9IZNNyY2w5odTNzW0saTzsoZmy/PUKZXPf3z6g210SDd0kHHuTkOoG9LtmDWap4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=FCzIgojU/7dBOnBF+E27xufBkN8=; b=KbZrgGidpD4 mep75LpnkuudhRrrnv5xzYpl0PuIH1I3+GTvVXbQM90yQS/yCoI0fq1XNR8CtCXB iXSZ2231nxO1Cm4wOXop1fTGrMqzug0qgKkcwowKt2hYWTmYi5DZcTx/c+KkCyE/ OVqgsJwU8WAgWYN+00llYDA5fNpMrpVE= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 18A94678089 for ; Mon, 12 Dec 2011 10:21:05 -0800 (PST) Received: by dajz8 with SMTP id z8so7061224daj.31 for ; Mon, 12 Dec 2011 10:21:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.34 with SMTP id i2mr36246919pbv.43.1323714064955; Mon, 12 Dec 2011 10:21:04 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 12 Dec 2011 10:21:04 -0800 (PST) In-Reply-To: <062.3c4f1f3c7db7c1fd9c4316f9034e38c9@trac.tools.ietf.org> References: <062.3c4f1f3c7db7c1fd9c4316f9034e38c9@trac.tools.ietf.org> Date: Mon, 12 Dec 2011 12:21:04 -0600 Message-ID: From: Nico Williams To: abfab issue tracker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ietf@augustcellars.com, draft-ietf-abfab-arch@tools.ietf.org, abfab@ietf.org Subject: Re: [abfab] #19: Setion 1.4 - Overview - X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 18:21:10 -0000 On Sat, Dec 10, 2011 at 7:19 PM, abfab issue tracker wrote: > #19: Setion 1.4 - Overview - > > =C2=A0a) =C2=A0I think you might need to have a step 2a - Client Applicat= ion creates > =C2=A0a channel to the RP. =C2=A0This is not done by the GSS-EAP mechanis= m as I had > =C2=A0originally assumed. =C2=A0Let's make it clear additionally that fac= t will be > =C2=A0needed in order to setup the channel binding at a later time. =C2= =A0Note that > =C2=A0at some point there will need to be a discussion of the properties = of this > =C2=A0channel. =C2=A0It should also be noted that the type of channel use= d > =C2=A0potentially provide different issues. See my other reply, from yesterday, regarding channels. The TLS channel is optional, not required. True, there cannot be channel binding if there's no channel to bind to, but an application that doesn't do channel binding will presumably be using GSS per-message tokens, thus using GSS itself as a channel. As to desired properties of channels, RFC5056 should suffice. In practice the channel will always be TLS, thus also needed is RFC5929. > =C2=A0b) in step 5 =C2=A0either /forward a RADIUS request/ or /forward RA= DIUS > =C2=A0requests/. =C2=A0AAA ignorance - would message be better than reque= st to avoid > =C2=A0confusion between RADISU request and GSS/EAP request? We should use "security context token", or just "token" to refer to GSS messages in this section. We definitely need to be careful to not confused terminology. Nico -- From ietf@augustcellars.com Mon Dec 12 14:13:18 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D81521F8466 for ; Mon, 12 Dec 2011 14:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7LfmqVPHo3O for ; Mon, 12 Dec 2011 14:13:17 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC8C821F85EF for ; Mon, 12 Dec 2011 14:13:10 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D2B492CA1C; Mon, 12 Dec 2011 14:13:09 -0800 (PST) From: "Jim Schaad" To: "'abfab issue tracker'" References: <062.02e3ffc16252077000a0c1c061478ccd@trac.tools.ietf.org> In-Reply-To: Date: Mon, 12 Dec 2011 14:12:39 -0800 Message-ID: <014f01ccb91b$2a175710$7e460530$@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: AQIAAluefdZ+/kqxTNTEWTm8KzgeeQIAqoJ1lWIsCOA= Content-Language: en-us Cc: abfab@ietf.org, draft-ietf-abfab-arch@tools.ietf.org Subject: Re: [abfab] #29: More explicity discussions of the communication channels with the end-points, cryptography and channel binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2011 22:13:18 -0000 As has been pointed out a couple of times. I should not assuming that = the channel I was describing in 1 (client to RP) is going to be TLS = either. It could be something w/o security. Jim > -----Original Message----- > From: Nico Williams [mailto:nico@cryptonector.com] > Sent: Sunday, December 11, 2011 5:22 PM > To: abfab issue tracker > Cc: draft-ietf-abfab-arch@tools.ietf.org; ietf@augustcellars.com; > abfab@ietf.org > Subject: Re: [abfab] #29: More explicity discussions of the = communication > channels with the end-points, cryptography and channel binding >=20 > On Sat, Dec 10, 2011 at 9:31 PM, abfab issue tracker > wrote: > > The following is a list of the "channels" that I believe exist in = the > > current abfab architecture (Please forgive the names that I am = using > > as they are made up on the spot): > > > > 1. Client to RP transport channel - This would be the TLS channel > > that exists between the client and the RP. [...] >=20 > > 2. Client to RP GSS-API channel - This is slightly weird to think = of > > as a >=20 > While the GSS-API "security context" (GSS term) is indeed a channel = just as > much as TLS is a channel, it is best to think of GSS-API w/ channel = binding as > an extension to TLS. >=20 > Suppose we were to propose extensions to TLS that provide us with > federated mutual authentication and an attribute-based authorization > model. It'd be hard enough to get consensus for such extensions to = TLS, but > then to get those extensions implemented by all the major TLS > implementations would take a long time. >=20 > Then consider that a common design for channels that provide > authentication is to separate key exchange from authentication but = then > bind them (e.g., SSHv2, client certs in TLS, ...). >=20 > By using GSS and channel binding we achieve almost exactly what could = have > been a TLS extension, and we do it in much the same sort of way that = we > might have done it as a TLS extension: separate authentication from = key > exchange, then bind the two so that the exchanged keys "speak for" the > authenticated entities. >=20 > Also, the GSS channel is thrown away as soon as we're done with = setting it up > and doing the channel binding operation. Before channel binding we = had > applications like IMAP and LDAP where there was the option to use = *two* > channels (TLS and GSS, with GSS being a channel proper when its per- > message protection facilities were used). Using two channels, one = inside the > other, is quite wasteful, both in terms of runtime resources (double = the > crypto) and software engineering (since it complicates application > architecture and requires more code). Worse, there may be no way for = the > application to securely negotiate among authentication options when = using > the old SASL/GSSAPI bridge without ending up with nested channels in = some > cases. This is one critical reason that we pursued SASL/GS2 to = replace the old > SASL/GSSAPI bridge. >=20 > Long story short: better to think of GSS w/ CB to TLS as an extension = to TLS. >=20 > > channel as it is going to be a channel between the requestor and = the > > acceptor, but the keying material is provided by a "third party" to > > both entities. (My understanding is that the client can derive = this > > material >=20 > This depends on the mechanism. Some GSS mechanisms involve a third > party and some don't. Federated authentication involves third parties = by > definition. (Yes, this is a nit.) >=20 > > on its own, but the RP gets the material from the IdP.) There is = no > > cryptographic binding on this channel until the EAP processing has > > totally finished and the MSK is transferred from the IdP to the RP = - > > i.e. after the client/IdP authentication has completed. >=20 > I'm not sure what you're getting at with this. A round-trip = optimization issue? >=20 > > 4. Client to IdP - This is the EAP channel. It has the strongest > > mutual authentication between that exists. We have stated that the > > IdP is responsible during this processing to determine that the RP > > that is communication to the client over channel #3 (Rp to IdP) and > > the one talking between the client the RP (channel #1?) are going = to > > be the same entity as the client provides the IdP it's version of = the > > RP name during the EAP conversation. Thus it needs to reconcile = the > > name forms between channel #1 and channel #3 during this = authentication > process. >=20 > We should not care at all about reconciliation of the RP names from = channels > #1 and #3. Whenever the GSS mechanism provides acceptable > authentication of the RP to the client we can simply ignore the RP = name from > TLS. And if the GSS mechanism does not provide authentication of the = RP to > the client then we have no real channel binding, and no need to = reconcile RP > names anyways. >=20 > > At this point channel #2 and channel #4 are known to have > > cryptographic protections. Channel #1 and channel #3 may or may = not > > have cryptographic protections. We need to specify what level of > > services are provided in these channels and how important those = services > are. >=20 > Channel #1 (TLS) is always going to be providing cryptographic = protection > (end-to-end) for client<->RP communications. Channel #1 may not = provide > any authentication -- is that what you meant? >=20 > > ** > > > > It was followed up by a couple of notes by sam, myself and nico. I > > believe that the outcome was that we should get a clear discription > > of the different communication channels, the set of cryptographic > > operations/keys offered by each, and the channel binding opertions > > (type of binding and what it accomplishes) for each channel would = be > useful. >=20 > I agree. The picture is relatively simple if viewed as follows: we = have a) TLS > providing session services, b) GSS providing client<->RP mutual > authentication, and with channel binding to TLS it's almost as if GSS = were part > of TLS, c) the specific GSS mechanism in our case provides = authentication by > way of one or more third parties. (a) is really entirely optional for > applications, except that we expect it to be part of every application = protocol > that hews to this architecture, thus (a) is not optional to the = architecture, but > because (a) and everything we need for exists already, there's nothing = to do > to make it feasible. >=20 > Nico > -- From leifj@mnt.se Tue Dec 13 03:18:17 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7761C21F88B7 for ; Tue, 13 Dec 2011 03:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJwdOraAtIuI for ; Tue, 13 Dec 2011 03:18:16 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 85F6321F88AB for ; Tue, 13 Dec 2011 03:18:15 -0800 (PST) Received: from [192.168.49.23] ([84.35.81.2]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBDBI9NE000306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Dec 2011 12:18:13 +0100 (CET) Message-ID: <4EE73471.1060904@mnt.se> Date: Tue, 13 Dec 2011 12:18:09 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: abfab@ietf.org References: <062.88e33e45a6a7a927b659bb8e1f4f3fc1@trac.tools.ietf.org> In-Reply-To: <062.88e33e45a6a7a927b659bb8e1f4f3fc1@trac.tools.ietf.org> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] #10: Defintion of federation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 11:18:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2011 01:13 AM, abfab issue tracker wrote: > #10: Defintion of federation > > version -00 > > Intro para #3 > > - I want to make sure that your definition of federation is one > that you want to make. Specifically it would appear that there can > be federations even within a single entity in the event that actor > providing the identity information is not the same as the RP. > Would you consider a single Kerberos or Windows enterprise to be a > federation. In these cases the IdP being the login service and the > RP being somebody granting access to a resource (in windows > possibly by an RPC). I generally think of federation as being > between two different entities rather than within a single entity > but using multiple servers. > (Speaking as an individual) I don't think this is a useful distinction. In terms of "deployment count" the internal federation is very common. In a large enterprise internal federations are often the result of M&A and then the amount and complexity of policy isn't even that different from a federation between separate parties. I'd personally close this issue wo change to the text. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7nNHEACgkQ8Jx8FtbMZncmRwCfXvAL53r+E0VtlDc9NOFTBP7b cNAAoIUAzJ7vUHMNdAT7c8wgC073ZOBe =crHn -----END PGP SIGNATURE----- From hartmans@painless-security.com Tue Dec 13 08:27:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389FE21F8B1F for ; Tue, 13 Dec 2011 08:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BLlQRR6MEOn for ; Tue, 13 Dec 2011 08:27:57 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C947721F8B20 for ; Tue, 13 Dec 2011 08:27:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2340F20393; Tue, 13 Dec 2011 11:28:03 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 13E8D4136; Tue, 13 Dec 2011 11:27:36 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <062.88e33e45a6a7a927b659bb8e1f4f3fc1@trac.tools.ietf.org> <4EE73471.1060904@mnt.se> Date: Tue, 13 Dec 2011 11:27:36 -0500 In-Reply-To: <4EE73471.1060904@mnt.se> (Leif Johansson's message of "Tue, 13 Dec 2011 12:18:09 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] #10: Defintion of federation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 16:27:58 -0000 I certainly don't want to preclude deployment of ABFAB technology within an organization. I think new issues come up when your technology may be deployed cross-organization. For example the trust comnsiderations I make are more complex working on ABFAB than Kerberos. From ietf@augustcellars.com Tue Dec 13 09:43:31 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EC921F84F5 for ; Tue, 13 Dec 2011 09:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbGA4Qg3JXf7 for ; Tue, 13 Dec 2011 09:43:30 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9611321F84C2 for ; Tue, 13 Dec 2011 09:43:30 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id C7DF938F74; Tue, 13 Dec 2011 09:43:29 -0800 (PST) From: "Jim Schaad" To: "'Leif Johansson'" , References: <062.88e33e45a6a7a927b659bb8e1f4f3fc1@trac.tools.ietf.org> <4EE73471.1060904@mnt.se> In-Reply-To: <4EE73471.1060904@mnt.se> Date: Tue, 13 Dec 2011 09:43:00 -0800 Message-ID: <01a101ccb9be$a8ec3940$fac4abc0$@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: AQIntpFD/ANgTSY1akUqP9UIl8uYuAF/NMP+lRgVz8A= Content-Language: en-us Subject: Re: [abfab] #10: Defintion of federation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 17:43:31 -0000 I have no objection to closing this issue. I would look at one small change which is not core - Current Text: These aspects are generally managed within a relationship known as a 'federation'. Suggestions: I think that the work 'generally' should be removed. For the purposes of this document they will be managed in a federation. If they are not managed in that way they are out of scope of this document. Either that or the start of the next sentence should be "When done in this manner, this style of..." Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Leif Johansson > Sent: Tuesday, December 13, 2011 3:18 AM > To: abfab@ietf.org > Subject: Re: [abfab] #10: Defintion of federation > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 12/11/2011 01:13 AM, abfab issue tracker wrote: > > #10: Defintion of federation > > > > version -00 > > > > Intro para #3 > > > > - I want to make sure that your definition of federation is one that > > you want to make. Specifically it would appear that there can be > > federations even within a single entity in the event that actor > > providing the identity information is not the same as the RP. > > Would you consider a single Kerberos or Windows enterprise to be a > > federation. In these cases the IdP being the login service and the RP > > being somebody granting access to a resource (in windows possibly by > > an RPC). I generally think of federation as being between two > > different entities rather than within a single entity but using > > multiple servers. > > > > (Speaking as an individual) > > I don't think this is a useful distinction. In terms of "deployment count" the > internal federation is very common. In a large enterprise internal federations > are often the result of M&A and then the amount and complexity of policy > isn't even that different from a federation between separate parties. > > I'd personally close this issue wo change to the text. > > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk7nNHEACgkQ8Jx8FtbMZncmRwCfXvAL53r+E0VtlDc9NOFTBP > 7b > cNAAoIUAzJ7vUHMNdAT7c8wgC073ZOBe > =crHn > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@mnt.se Wed Dec 14 00:38:41 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1D221F8A64 for ; Wed, 14 Dec 2011 00:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGYScCQ3qTqB for ; Wed, 14 Dec 2011 00:38:41 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id E431E21F84B2 for ; Wed, 14 Dec 2011 00:38:40 -0800 (PST) Received: from [192.168.49.23] ([84.35.81.2]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBE8cBb3025169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Dec 2011 09:38:15 +0100 (CET) Message-ID: <4EE86073.2040206@mnt.se> Date: Wed, 14 Dec 2011 09:38:11 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Jim Schaad References: <062.88e33e45a6a7a927b659bb8e1f4f3fc1@trac.tools.ietf.org> <4EE73471.1060904@mnt.se> <01a101ccb9be$a8ec3940$fac4abc0$@augustcellars.com> In-Reply-To: <01a101ccb9be$a8ec3940$fac4abc0$@augustcellars.com> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] #10: Defintion of federation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2011 08:38:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/13/2011 06:43 PM, Jim Schaad wrote: > I have no objection to closing this issue. > > I would look at one small change which is not core - > > Current Text: These aspects are generally managed within a > relationship known as a 'federation'. > > Suggestions: I think that the work 'generally' should be removed. > For the purposes of this document they will be managed in a > federation. If they are not managed in that way they are out of > scope of this document. Either that or the start of the next > sentence should be "When done in this manner, this style of..." I'm fine with this change. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7oYHMACgkQ8Jx8FtbMZnfC2ACdEjiriRt6AHM11vIoFcqRLOCU gxIAnRt9GKJBw7dNMVj0Daw+dAHEKd8o =efr0 -----END PGP SIGNATURE----- From ietf@augustcellars.com Wed Dec 14 21:27:24 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9D1F0C47 for ; Wed, 14 Dec 2011 21:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBBGAcpxgPOc for ; Wed, 14 Dec 2011 21:27:23 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id D07B811E8089 for ; Wed, 14 Dec 2011 21:27:21 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 5C0CF38EEF; Wed, 14 Dec 2011 21:27:16 -0800 (PST) From: "Jim Schaad" To: "'Nico Williams'" Date: Wed, 14 Dec 2011 21:26:43 -0800 Message-ID: <028e01ccbaea$248a2a90$6d9e7fb0$@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: Acy66XaC+ZH+iuKGSqKwHV0e0vwQNA== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Use of anonymous TLS w/ ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 05:27:24 -0000 Nico, This goes out of tracker issue #29. One of the things that I am looking at for the Plasma work is the set of = items which would be required for doing TLS and ABFAB together and what = things can be eased. Normally I would want to have a hard check on the name of the TLS server = and matching w/ the certificate. However, just like one could use ABFAB = for the purpose of doing user authentication, I think that one can use = ABFAB for doing server authentication. That is one could be able to = authenticate either an anonymous TLS server, or a TLS server with whom = you do not have a trust anchor. This would be similar to what you laid out for the use authentication = method. That is one would setup the TLS channel, perform the ABFAB = authentication with the required channel binding from the TLS session = and then throw away the ABFAB work after the ABFAB has completed it = authentication process (i.e. the MIC is checked). At this point one = should have mutual authentication, and the EAP channel binding should = have compared the name the client is looking from (from the TLS = certificate or the URL) with that provided by the ABFAB RP. Does this seem a reasonable approach in some circumstances? Are there = circumstances you can see where this would be unreasonable? Jim From nico@cryptonector.com Thu Dec 15 02:53:16 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB4721F8A97 for ; Thu, 15 Dec 2011 02:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyOILPfXVRf9 for ; Thu, 15 Dec 2011 02:53:12 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id D134421F8A7E for ; Thu, 15 Dec 2011 02:53:12 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 94D972AC073 for ; Thu, 15 Dec 2011 02:53:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=KwLMPDAWElLzU29E80Tsd hPtR8+7wDxzVl7qudfnGRaOCaQvWIxFyH/+4g3IGJ4VK768YlDTyFQUV5HnGC4ct LTV8gIQPz9t9ekL1Dsawb9aMAi1MjD1RzacZirzXgpXba21sn+8aQN4WnQmZ42I5 XhrGusB/oUNbW104NXke38= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Yv3o/zSS4B6UeZarmOwK Iubn61w=; b=NI52WdfnX4jV6N91W9dp1KaYUIJ/x/I6G8gAGI5GM53zc/ZbFdMH QGBH7ZC6DPubjULPk+0BfA5YqbYfdl8VkGRi5zPgxrfhS/EPfF5cdyba0/UASOuY xGgZ+cMKJory4DPgquxn5p8FD85/zt4y/7Gpa95/9EaoeZOMILQkKYI= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 7AE0F2AC06E for ; Thu, 15 Dec 2011 02:53:12 -0800 (PST) Received: by dajz8 with SMTP id z8so1855677daj.31 for ; Thu, 15 Dec 2011 02:53:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.74.69 with SMTP id r5mr9471934pbv.118.1323946392054; Thu, 15 Dec 2011 02:53:12 -0800 (PST) Received: by 10.68.32.227 with HTTP; Thu, 15 Dec 2011 02:53:11 -0800 (PST) Received: by 10.68.32.227 with HTTP; Thu, 15 Dec 2011 02:53:11 -0800 (PST) In-Reply-To: <028e01ccbaea$248a2a90$6d9e7fb0$@augustcellars.com> References: <028e01ccbaea$248a2a90$6d9e7fb0$@augustcellars.com> Date: Thu, 15 Dec 2011 04:53:11 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: multipart/alternative; boundary=bcaec54693e5666cbd04b41f4ac0 Cc: abfab@ietf.org Subject: Re: [abfab] Use of anonymous TLS w/ ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 10:53:17 -0000 --bcaec54693e5666cbd04b41f4ac0 Content-Type: text/plain; charset=UTF-8 On Dec 15, 2011 12:27 AM, "Jim Schaad" wrote: > Normally I would want to have a hard check on the name of the TLS server and matching w/ the certificate. However, just like one could use ABFAB for the purpose of doing user authentication, I think that one can use ABFAB for doing server authentication. That is one could be able to authenticate either an anonymous TLS server, or a TLS server with whom you do not have a trust anchor. The tls-server-end-point channel binding tour does not require that the server cert be valid to any trust anchor, not does out require pre-sharing of self-signed certs, not does it require any particular names our name forms to appear in the server cert. I.e., server certs can be anonymous and pseudonymous if you like. If you don't want to use server certs at all (self-signed our otherwise) you can always use anon DHE cipher suites and use the tls-unique channel binding type. The tls-server-end-point CB type is easy to support almost universally, whereas tls-unique support is a bit harder to come by (not all TLS stacks support it, sadly). > This would be similar to what you laid out for the use authentication method. That is one would setup the TLS channel, perform the ABFAB authentication with the required channel binding from the TLS session and then throw away the ABFAB work after the ABFAB has completed it authentication process (i.e. the MIC is checked). At this point one should have mutual authentication, and the EAP channel binding should have compared the name the client is looking from (from the TLS certificate or the URL) with that provided by the ABFAB RP. > > Does this seem a reasonable approach in some circumstances? Yes, it does. > Are there circumstances you can see where this would be unreasonable? I can't think of any. Nico -- --bcaec54693e5666cbd04b41f4ac0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Dec 15, 2011 12:27 AM, "Jim Schaad" <ietf@augustcellars.com> wrote:
> Normally I would want to have a hard check on the name of the TLS serv= er and matching w/ the certificate. =C2=A0However, just like one could use = ABFAB for the purpose of doing user authentication, I think that one can us= e ABFAB for doing server authentication. =C2=A0That is one could be able to= authenticate either an anonymous TLS server, or a TLS server with whom you= do not have a trust anchor.

The tls-server-end-point channel binding tour does not require that the = server cert be valid to any trust anchor, not does out require pre-sharing = of self-signed certs, not does it require any particular names our name for= ms to appear in the server cert.=C2=A0 I.e., server certs can be anonymous = and pseudonymous if you like.

If you don't want to use server certs at all (self-signed our otherw= ise) you can always use anon DHE cipher suites and use the tls-unique chann= el binding type.

The tls-server-end-point CB type is easy to support almost universally, = whereas tls-unique support is a bit harder to come by (not all TLS stacks s= upport it, sadly).

> This would be similar to what you laid out for the use authenticati= on method. =C2=A0That is one would setup the TLS channel, perform the ABFAB= authentication with the required channel binding from the TLS session and = then throw away the ABFAB work after the ABFAB has completed it authenticat= ion process (i.e. the MIC is checked). =C2=A0At this point one should have = mutual authentication, and the EAP channel binding should have compared the= name the client is looking from (from the TLS certificate or the URL) with= that provided by the ABFAB RP.
>
> Does this seem a reasonable approach in some circumstances?

Yes, it does.

> =C2=A0Are there circumstances you can see where this would be unrea= sonable?

I can't think of any.

Nico
--

--bcaec54693e5666cbd04b41f4ac0-- From hartmans@painless-security.com Thu Dec 15 03:26:37 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7226421F8505 for ; Thu, 15 Dec 2011 03:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ghbRdqSrdEM0 for ; Thu, 15 Dec 2011 03:26:37 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA4C21F8500 for ; Thu, 15 Dec 2011 03:26:37 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EB80F20198; Thu, 15 Dec 2011 06:26:36 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC73E42F2; Thu, 15 Dec 2011 06:26:06 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <028e01ccbaea$248a2a90$6d9e7fb0$@augustcellars.com> Date: Thu, 15 Dec 2011 06:26:06 -0500 In-Reply-To: <028e01ccbaea$248a2a90$6d9e7fb0$@augustcellars.com> (Jim Schaad's message of "Wed, 14 Dec 2011 21:26:43 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Use of anonymous TLS w/ ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 11:26:37 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Does this seem a reasonable approach in some circumstances? Jim> Are there circumstances you can see where this would be Jim> unreasonable? So, technically it's a lot easier to do this with certs for which you don't share a trust anchor than for TLS with anonymous DH ciphers. Mostly implementation issues at fault; end-point channel bindings are more widely implemented than unique for TLS. The general model is sound and is one Nico and I have been working on for years. It means you're really trusting EAP channel binding. It means whoever runs your ABFAB actually needs to do a quality job of validating servers. However they may have a smaller problem than a global PKI to solve so it may be easir for them to do that. It's unreasonable if you want to validate the server before disclosing what abfab realm you want to talk to. It's unreasonable if your implementation doesn't let you fiddle with TLS validation and defer it until after CB so you can suppress if CB succeeeds. It may be unreasonable if the client machine needs to trust the server independently of the user at the client machine. Often the client machine will not be able to establish trust in the ABFAB architecture. --Sam From diego@tid.es Thu Dec 15 03:37:13 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2485621F846A for ; Thu, 15 Dec 2011 03:37:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kp2BxCx9moQv for ; Thu, 15 Dec 2011 03:37:08 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEBC21F8467 for ; Thu, 15 Dec 2011 03:37:08 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW80070OTLUYA@tid.hi.inet> for abfab@ietf.org; Thu, 15 Dec 2011 12:37:06 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id C7.6C.04893.607E9EE4; Thu, 15 Dec 2011 13:24:38 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LW80070ITLUYA@tid.hi.inet> for abfab@ietf.org; Thu, 15 Dec 2011 12:37:06 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Thu, 15 Dec 2011 12:37:06 +0100 Date: Thu, 15 Dec 2011 12:37:04 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: Sam Hartman Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] Use of anonymous TLS w/ ABFAB Thread-index: Acy7Hd7rTZOi/vkvR1GcOyO1CNXB1w== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f4c6d00000131d-ed-4ee9e706dfb9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsXCFe/Apcv2/KWfwd2J3BYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuyfzxgLVglU3H48ka2B8Qt/FyMnh4SAicT/G5PZIWwxiQv3 1rN1MXJxCAlsYJTYd3Q7I4Tzg1Fic+N6dginkVFixcmjbCAtLAKqErsfNzGC2GwC6hItR7+x dDFycAgLGEkc6xUGCXMKqEm8/vifGcQWETCQmPfqGFgrs4CXRPfUlUwgNq+ApcSvW89ZIWxB iR+T74GNYQYaOWVKLkS5uERz600WCFtRYtqiBrCtjEBHfz+1hgmkXETAWOLvnESITXoSs4/c ZYUoEZW4076eEeJHAYkle84zQ9iiEi8f/2MFaRUSiJZ4/4dlAqP4LCQ3zEK4YRaSG2YhuWEB I8sqRrHipKLM9IyS3MTMnHQDQ72MTL3MvNSSTYyQ+MnYwbh8p8ohRgEORiUe3gvGL/2EWBPL iitzDzFKcjApifKy3QAK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHt2vvCT4g3JbGyKrUoHyYl w8GhJMErehuoTbAoNT21Ii0zB5gkYNJMHJwg7TxA7RwgNbzFBYm5xZnpEPlTjJJS4rzbbgEl BEASGaV5cL2vGMWBjhSGaOMBpjO4rldAA5mABm4PA7mnuCQRISXVwJjrJDJFe1v70kmvFqtz 7Fq8OeZ4jsDnHX/sj3ermB8Vc3fY3rC3VaOj3O5r3F7u7G1r7Txm8MkK2TPEMQZwBn79dOIP a2tQpLnKXsPb0ltm9FZ3ScybkL7rmefpbP6z/uedvxR9vd5+Q9Byruf1r0dvFwau3v81bL5Y 0RNO5Zyo8OkbjZt2+iixFGckGmoxFxUnAgBFgrpqJAMAAA== References: <028e01ccbaea$248a2a90$6d9e7fb0$@augustcellars.com> Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Use of anonymous TLS w/ ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 11:37:13 -0000 DQpPbiAxNSBEZWMgMjAxMSwgYXQgMTI6MjYgLCBTYW0gSGFydG1hbiB3cm90ZToNCg0KPj4+Pj4+ ICJKaW0iID09IEppbSBTY2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyaXRlczoNCj4N Cj4NCj4gICAgSmltPiBEb2VzIHRoaXMgc2VlbSBhIHJlYXNvbmFibGUgYXBwcm9hY2ggaW4gc29t ZSBjaXJjdW1zdGFuY2VzPw0KPiAgICBKaW0+IEFyZSB0aGVyZSBjaXJjdW1zdGFuY2VzIHlvdSBj YW4gc2VlIHdoZXJlIHRoaXMgd291bGQgYmUNCj4gICAgSmltPiB1bnJlYXNvbmFibGU/DQo+DQo+ IFNvLCB0ZWNobmljYWxseSBpdCdzIGEgbG90IGVhc2llciB0byBkbyB0aGlzIHdpdGggY2VydHMg Zm9yIHdoaWNoIHlvdQ0KPiBkb24ndCBzaGFyZSBhIHRydXN0IGFuY2hvciB0aGFuIGZvciBUTFMg d2l0aCBhbm9ueW1vdXMgREggY2lwaGVycy4NCj4gTW9zdGx5IGltcGxlbWVudGF0aW9uIGlzc3Vl cyBhdCBmYXVsdDsgZW5kLXBvaW50IGNoYW5uZWwgYmluZGluZ3MgYXJlDQo+IG1vcmUgd2lkZWx5 IGltcGxlbWVudGVkIHRoYW4gdW5pcXVlIGZvciBUTFMuDQo+DQo+IFRoZSBnZW5lcmFsIG1vZGVs IGlzIHNvdW5kIGFuZCBpcyBvbmUgTmljbyBhbmQgSSBoYXZlIGJlZW4gd29ya2luZyBvbg0KPiBm b3IgeWVhcnMuDQo+DQo+IEl0IG1lYW5zIHlvdSdyZSByZWFsbHkgdHJ1c3RpbmcgRUFQIGNoYW5u ZWwgYmluZGluZy4gSXQgbWVhbnMgd2hvZXZlcg0KPiBydW5zIHlvdXIgQUJGQUIgYWN0dWFsbHkg bmVlZHMgdG8gZG8gYSBxdWFsaXR5IGpvYiBvZiB2YWxpZGF0aW5nDQo+IHNlcnZlcnMuICBIb3dl dmVyIHRoZXkgbWF5IGhhdmUgYSBzbWFsbGVyIHByb2JsZW0gdGhhbiBhIGdsb2JhbCBQS0kgdG8N Cj4gc29sdmUgc28gaXQgbWF5IGJlIGVhc2lyIGZvciB0aGVtIHRvIGRvIHRoYXQuDQoNCg0KV291 bGQgbm90IHRoaXMgYmUgYW4gaW50ZXJlc3RpbmcgdXNlIGNhc2UgZm9yIHRoZSB0cnVzdCByb3V0 ZXI/DQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpE ciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMN ClRlbDogICAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCkVzdGUgbWVuc2FqZSBz ZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRh ciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVj dHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBp cyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFu ZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdC4NCmh0 dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From hartmans@painless-security.com Thu Dec 15 05:57:35 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC49621F8906 for ; Thu, 15 Dec 2011 05:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKSkWIFKwZLI for ; Thu, 15 Dec 2011 05:57:35 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7543221F8753 for ; Thu, 15 Dec 2011 05:57:35 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 817662023F; Thu, 15 Dec 2011 08:57:29 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 78C0842F2; Thu, 15 Dec 2011 08:57:00 -0500 (EST) From: Sam Hartman To: DIEGO LOPEZ GARCIA References: <028e01ccbaea$248a2a90$6d9e7fb0$@augustcellars.com> Date: Thu, 15 Dec 2011 08:57:00 -0500 In-Reply-To: (DIEGO LOPEZ GARCIA's message of "Thu, 15 Dec 2011 12:37:04 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Use of anonymous TLS w/ ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 13:57:36 -0000 >>>>> "DIEGO" == DIEGO LOPEZ GARCIA writes: >> The general model is sound and is one Nico and I have been >> working on for years. >> >> It means you're really trusting EAP channel binding. It means >> whoever runs your ABFAB actually needs to do a quality job of >> validating servers. However they may have a smaller problem than >> a global PKI to solve so it may be easir for them to do that. DIEGO> Would not this be an interesting use case for the trust DIEGO> router? Yes! The trust router is great at allowing you to organize a community that is going to be focused enough to give better trust and security to its members than a general PKI. We're beginning to see that the most interesting value in our architecture of the trust router is exactly that it lets you have a bunch of these little communities running around and manage them effectively and focus the authentication context. From zhou.sujing@zte.com.cn Thu Dec 15 18:18:12 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54C121F8AE9 for ; Thu, 15 Dec 2011 18:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.228 X-Spam-Level: X-Spam-Status: No, score=-100.228 tagged_above=-999 required=5 tests=[AWL=1.610, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW7SDGbmlI7v for ; Thu, 15 Dec 2011 18:18:12 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B2B7A21F8AD9 for ; Thu, 15 Dec 2011 18:18:11 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 56690967931198; Fri, 16 Dec 2011 10:00:39 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 259.967931198; Fri, 16 Dec 2011 10:17:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pBG2HvAb026438 for ; Fri, 16 Dec 2011 10:17:57 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: abfab@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 16 Dec 2011 10:17:43 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-16 10:17:59, Serialize complete at 2011-12-16 10:17:59 Content-Type: multipart/alternative; boundary="=_alternative 000CA22748257968_=" X-MAIL: mse02.zte.com.cn pBG2HvAb026438 Subject: [abfab] a review on draft-ietf-abfab-gss-eap-04 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 02:18:12 -0000 This is a multipart message in MIME format. --=_alternative 000CA22748257968_= Content-Type: text/plain; charset="US-ASCII" Hi,all, the following are questions occured to me when reading draft-ietf-abfab-gss-eap-04: 1. Section 1 "The Extensible Authentication Protocol (EAP) [RFC3748] defines a framework for authenticating a network access client and server in order to gain access to a network." since applicability of EAP is under updating beyond network access, I think the information of Section 7 might as well be indicated here. 2. section 5.4.2 and section 5.7 Why would acceptor name appear in a acceptor name request? 3. section 5.4.3 "Typically this token would only be send if the acceptor name request is absent." Acceptor name response is sent only when no acceptor name request has been received? 4. section 5.6 "After EAP success, the initiator sends a token to the acceptor including additional subtokens that negotiate optional features or provide GSS-API channel binding (see Section 6.1)." According to RFC2743, GSS-API channel binding information is provided as an input to GSS_Init_sec_context(), i.e., before EAP sucess, so how and why send GSS-API channel binding here? 5. "The PROT_READY service is never available with this mechanism." what is PROT_READY service? I cann't find any reference to it. Regards~~~ -Sujing Zhou -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000CA22748257968_= Content-Type: text/html; charset="US-ASCII"
Hi,all, the following are questions occured to me when reading draft-ietf-abfab-gss-eap-04:


1. Section 1
    "The Extensible Authentication Protocol (EAP) [RFC3748] defines a
   framework for authenticating a network access client and server in
   order to gain access to a network."
   
  since applicability of EAP is under updating beyond network access, I think the information of Section 7 might as well be
indicated here.

2.  section 5.4.2 and section 5.7
   Why would acceptor name appear in a acceptor name request?

3.  section 5.4.3
  "Typically this token would only be send if the acceptor name request is absent."
   Acceptor name response is sent only when no acceptor name request has been received?

4. section 5.6
   "After EAP success, the initiator sends a token to the acceptor
   including additional subtokens that negotiate optional features or
   provide GSS-API channel binding (see Section 6.1)."
   
   According to RFC2743, GSS-API channel binding information is provided as an input to GSS_Init_sec_context(), i.e., before
EAP sucess, so how and why send GSS-API channel binding here?


5. "The PROT_READY service is never available with this mechanism."
   what is PROT_READY service? I cann't find any reference to it.




Regards~~~

-Sujing Zhou
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000CA22748257968_=-- From ietf@augustcellars.com Fri Dec 16 00:01:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E405121F8A7B for ; Fri, 16 Dec 2011 00:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCvwaOmpfU40 for ; Fri, 16 Dec 2011 00:01:36 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3F121F8A4E for ; Fri, 16 Dec 2011 00:01:36 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8F3642CA4F for ; Fri, 16 Dec 2011 00:01:35 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 16 Dec 2011 00:01:06 -0800 Message-ID: <02f901ccbbc8$dd761b20$98625160$@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: Acy7u0/mzGLKG977RIeUYZdY9ojHaQ== Content-Language: en-us Subject: [abfab] Trying to get Plasma text correct. X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 08:01:37 -0000 I am starting to try and develop text for the Plasma documents on how to use GSS-API. At least initially, I want to write it to be generic GSS-API and then do specifics for the ABFAB GSS-API/EAP case. To make my life simpler, we are going to require that the client/RP transport method always be TLS. Which means that I will at some point in the future need to worry about cases where path validation is not completely successful. But I am planning to punt that issue for now. So since we always know the name of the entity we are going to be talking to. My assumption is that we are always going to pass an acceptor name into GSS-API. The acceptor name would be "plasma/serverName@domainName". We would say strip the left most dotted name as the server name and leave the rest as the domain name. Thus an example name might be "plasma\mailPDP@windows.example.com". Now we start looking at some fun things. 1. If the url was https://mailPDP.windows.example.com/internalPolicyChecker, should the extra verbage be reflected in the service name string? 2. Do we need to say anything special about walking up domain names when doing checking or during AAA processing? Specifically, should a domain string be truncated when doing the channel binding processing called out in the EMU channel bindings document wrt to the database lookup code? 3. In the current code, one would expect that the client would send the full name to the RP as part of the first GSS-API handshake message. I still feel somewhat uncomfortable with telling the RP what its full name is going to be, but I don't see any way around this with the current GSS-API calling code. That is since I want the channel binding to occur w/ a specific server and domain, there is no way not to let the RP know what they are going to be in advance. I understand that the AAA system will validate that the RP has the right to the name so there should not be any issues, but is there any way to make me feel more comfortable with this? 4. Since I am using TLS, I will need to specify that TLS channel binding will occur (and find the appropriate references about how this works for extraction). I am still trying to debate if I need to include additional channel binding data from my protocol dialog as well. Has anybody written any guidance on when this is recommended and what types of data need to be included? I think I have re-designed my protocol so this is no longer necessary, but I would like some assurance that I am correct. 5. If I get to this point, have I already selected the credential that I will be using with the EAP server, or I have just gotten to the point of saying that I will be using one of a set of credentials? This is an LOA question. I will have already selected the realm that I am going to be authenticated against since I know that goes out in the first GSS-API/EAP message. I also understand that by selecting a realm, I may have restricted the set of possible LOAs that I can be dealing with. Should my protocol allow for some type of re-start of negotiation if a different LOA is needed? I assume that would need to be a total re-start of the GSS-API/EAP negotiation at a minimum although I could leave up the TLS session. 6. Should I be setting up some type of negotiation in my protocol to allow for a different GSS-API mechanism to be selected? I.e. if one is within a single company one could use the Kerberos GSS-API rather than going with the EAP version. Would be think this is of importance or can I just restrict to using the one GSS-API mechanism and be done with it? Can this type of negotiation be done within GSS-API? I don't remember seeing anything of this sort but that does not mean it does not exist. My understanding was that it amounted to configuration information on the client side. Jim From zhou.sujing@zte.com.cn Fri Dec 16 01:26:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DC621F8B23 for ; Fri, 16 Dec 2011 01:26:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.631 X-Spam-Level: X-Spam-Status: No, score=-100.631 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g955dz9X8SGl for ; Fri, 16 Dec 2011 01:26:14 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id BB8CC21F8AE9 for ; Fri, 16 Dec 2011 01:26:13 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690967931198; Fri, 16 Dec 2011 17:08:52 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 95341.2449460320; Fri, 16 Dec 2011 17:25:11 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pBG9OmV5079180; Fri, 16 Dec 2011 17:24:48 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: alex@um.es MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 16 Dec 2011 17:24:36 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-16 17:24:51, Serialize complete at 2011-12-16 17:24:51 Content-Type: multipart/alternative; boundary="=_alternative 0033B74648257968_=" X-MAIL: mse02.zte.com.cn pBG9OmV5079180 Cc: abfab@ietf.org Subject: [abfab] draft-perez-abfab-eap-gss-preauth X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 09:26:14 -0000 This is a multipart message in MIME format. --=_alternative 0033B74648257968_= Content-Type: text/plain; charset="US-ASCII" I don't know why AAA server and IdP both appear in figure 1, since according to the abfab architecture(draft-ietf-abfab-arch-00 ) AAA server means IdP. AAA server itself can authenticate EU , why let an extra IdP do the Assertion? Regards~~~ -Sujing Zhou -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0033B74648257968_= Content-Type: text/html; charset="US-ASCII"
I don't know why AAA server and IdP both appear in figure 1, since according to the abfab architecture(draft-ietf-abfab-arch-00 )
AAA server means IdP. AAA server itself can authenticate EU , why let an extra IdP do the Assertion?





Regards~~~

-Sujing Zhou
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0033B74648257968_=-- From alex@um.es Fri Dec 16 01:31:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1253721F8A70 for ; Fri, 16 Dec 2011 01:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cujqFEMNYVQh for ; Fri, 16 Dec 2011 01:31:55 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 147CF21F888A for ; Fri, 16 Dec 2011 01:31:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 979CF5360D; Fri, 16 Dec 2011 10:31:53 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id y3Bak-4-ntbS; Fri, 16 Dec 2011 10:31:53 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id BD9AF53622; Fri, 16 Dec 2011 10:31:49 +0100 (CET) Message-ID: <4EEB1005.5070205@um.es> Date: Fri, 16 Dec 2011 10:31:49 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: zhou.sujing@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] draft-perez-abfab-eap-gss-preauth X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 09:31:56 -0000 > I don't know why AAA server and IdP both appear in figure 1, since > according to the abfab architecture(draft-ietf-abfab-arch-00 ) > AAA server means IdP. AAA server itself can authenticate EU , why let an > extra IdP do the Assertion? AAA and IdP may be collocated, but it is not a MUST. Regards, Alejandro > > > > > > > Regards~~~ > > -Sujing Zhou > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > From trac+abfab@trac.tools.ietf.org Fri Dec 16 10:30:27 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19E121F8B0D for ; Fri, 16 Dec 2011 10:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNTOF7XtLxpq for ; Fri, 16 Dec 2011 10:30:27 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC8A21F8B05 for ; Fri, 16 Dec 2011 10:30:27 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1RbcY0-0001Gv-EA; Fri, 16 Dec 2011 13:30:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hartmans-ietf@mit.edu X-Trac-Project: abfab Date: Fri, 16 Dec 2011 18:30:19 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/30 Message-ID: <061.d091888868bf30f0d42c3f768a4c581c@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: abfab@ietf.org Subject: [abfab] #30: Decide about EAP applicability text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:30:28 -0000 #30: Decide about EAP applicability text The current section 7 is a placeholder that say we need to decide what to do about EAP applicability. Discussion at IETF 82 indicated that the current applicability document may need to change. suggested that section 7 be merged into section 1. We need to decide how we're going to handle the applicability updatezhou.sujing@zte.com.cn -- -----------------------------+----------------- Reporter: hartmans-ietf@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: gss-eap | Version: Severity: - | Keywords: -----------------------------+----------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Fri Dec 16 10:37:21 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA9521F8B39 for ; Fri, 16 Dec 2011 10:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZdbWEzZrHRi for ; Fri, 16 Dec 2011 10:37:20 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 90DBD21F8B10 for ; Fri, 16 Dec 2011 10:37:20 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1Rbcel-0003mz-V4; Fri, 16 Dec 2011 13:37:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hartmans-ietf@mit.edu X-Trac-Project: abfab Date: Fri, 16 Dec 2011 18:37:19 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/31 Message-ID: <061.0ded2f3783acc385a44c725f6c136b79@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: abfab@ietf.org Subject: [abfab] #31: Error text is a placeholder X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:37:21 -0000 #31: Error text is a placeholder The error codes registry in draft-ietf-gss-eap is a placeholder. -- -----------------------------+----------------- Reporter: hartmans-ietf@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: gss-eap | Version: Severity: - | Keywords: -----------------------------+----------------- Ticket URL: abfab From hartmans@painless-security.com Fri Dec 16 10:38:39 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E42721F8797 for ; Fri, 16 Dec 2011 10:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1F3tvtfR0ghi for ; Fri, 16 Dec 2011 10:38:38 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AECE621F877F for ; Fri, 16 Dec 2011 10:38:38 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 83CC7201F1; Fri, 16 Dec 2011 13:38:37 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1918C42F2; Fri, 16 Dec 2011 13:38:33 -0500 (EST) From: Sam Hartman To: zhou.sujing@zte.com.cn References: Date: Fri, 16 Dec 2011 13:38:33 -0500 In-Reply-To: (zhou sujing's message of "Fri, 16 Dec 2011 10:17:43 +0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] a review on draft-ietf-abfab-gss-eap-04 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 18:38:39 -0000 >>>>> "zhou" == zhou sujing writes: zhou> Hi,all, the following are questions occured to me when reading zhou> draft-ietf-abfab-gss-eap-04: zhou> 1. Section 1 "The Extensible Authentication Protocol (EAP) zhou> [RFC3748] defines a framework for authenticating a network zhou> access client and server in order to gain access to a zhou> network." zhou> since applicability of EAP is under updating beyond network zhou> access, I think the information of Section 7 might as well be zhou> indicated here. I've opened issue #30 to track this. zhou> 2. section 5.4.2 and section 5.7 Why would acceptor name zhou> appear in a acceptor name request? The acceptor name request asks for a particular acceptor if the acceptor is capable of acting as multiple entites/virtual hosts. It's just like the Host header in HTTP or the server-name-indication in TLS. I'd be interested in any clarifications you can suggest so others don't have the same confusion. zhou> 3. section 5.4.3 "Typically this token would only be send if zhou> the acceptor name request is absent." Acceptor name response zhou> is sent only when no acceptor name request has been received? Jim proposed changing this at IETF 82 and I have seen no objections to that change. zhou> 4. section 5.6 "After EAP success, the initiator sends a token zhou> to the acceptor including additional subtokens that negotiate zhou> optional features or provide GSS-API channel binding (see zhou> Section 6.1)." zhou> According to RFC2743, GSS-API channel binding information zhou> is provided as an input to GSS_Init_sec_context(), i.e., zhou> before EAP sucess, so how and why send GSS-API channel binding zhou> here? It's not really true that gss_init_sec_context is before eap success. You call it multiple times. ONe of those times you need to send GSS channel binding data; the section you quote describes how. zhou> 5. "The PROT_READY service is never available with this zhou> mechanism." what is PROT_READY service? I cann't find any zhou> reference to it. Section 1.2.7 of RFC 2743; the document has been updated with this zhou> reference. zhou> Regards~~~ zhou> -Sujing Zhou zhou> -------------------------------------------------------- ZTE zhou> Information Security Notice: The information contained in this zhou> mail is solely property of the sender's organization. This zhou> mail communication is confidential. Recipients named above are zhou> obligated to maintain secrecy and are not permitted to zhou> disclose the contents of this communication to others. This zhou> email and any files transmitted with it are confidential and zhou> intended solely for the use of the individual or entity to zhou> whom they are addressed. If you have received this email in zhou> error please notify the originator of the message. Any views zhou> expressed in this message are those of the individual sender. zhou> This message has been scanned for viruses and Spam by ZTE zhou> Anti-Spam system. zhou> _______________________________________________ abfab mailing zhou> list abfab@ietf.org zhou> https://www.ietf.org/mailman/listinfo/abfab From nico@cryptonector.com Fri Dec 16 11:08:06 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B7311E80AB for ; Fri, 16 Dec 2011 11:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRTXtWhTOSM3 for ; Fri, 16 Dec 2011 11:08:05 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id BD54F11E8089 for ; Fri, 16 Dec 2011 11:08:05 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 6BFC354055 for ; Fri, 16 Dec 2011 11:07:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Qfw5h+bUmgFFVRUQ21ThsS0c03ueR18YS/gkX4Nf47ms fznptg0yEPI4RVWxjqf7lqY4cq2Ww/XMlE0GTJSexqg8mV/jDwI1zY42oS04iylA SqG+TUry/7hCoPYCku/1fMhpv9cp2spGzE6dzKB/6oKima7P0w9UJieOoX+kh0M= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=HoZvpB8xaw58nm7AjQt7I9U5M1w=; b=diZ2L1pNwGm jvH8SINdig8fZU334rZpvlWqla5r9oh2dgyVi2FFzEPiqK7/ZLTlVOjpDCVHdVP+ 02uDv4QqKrfxZueKRWpqUJv1y568qiJX5YJuVrdxr9JidmTE4RcH1Yk6iGjOCD1r mnoCCX2Gg31Kn+oII8RTLu+RzmBwuWcs= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 2FD375408A for ; Fri, 16 Dec 2011 11:07:29 -0800 (PST) Received: by dajz8 with SMTP id z8so3317942daj.31 for ; Fri, 16 Dec 2011 11:07:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr18080477pbv.90.1324062449224; Fri, 16 Dec 2011 11:07:29 -0800 (PST) Received: by 10.68.32.227 with HTTP; Fri, 16 Dec 2011 11:07:29 -0800 (PST) In-Reply-To: <02f901ccbbc8$dd761b20$98625160$@augustcellars.com> References: <02f901ccbbc8$dd761b20$98625160$@augustcellars.com> Date: Fri, 16 Dec 2011 13:07:29 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Trying to get Plasma text correct. X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:08:06 -0000 On Fri, Dec 16, 2011 at 2:01 AM, Jim Schaad wrote: > I am starting to try and develop text for the Plasma documents on how to = use > GSS-API. =C2=A0At least initially, I want to write it to be generic GSS-A= PI and > then do specifics for the ABFAB GSS-API/EAP case. > > To make my life simpler, we are going to require that the client/RP > transport method always be TLS. =C2=A0Which means that I will at some poi= nt in > the future need to worry about cases where path validation is not complet= ely > successful. =C2=A0But I am planning to punt that issue for now. Since we're talking about doing channel binding the simplest thing to do is to say that whatever certificate the server uses, you'll accept -- i.e., simply turn off validation. (Oh, you might want to say that the cert must not be expired, and you'll definitely want to say something about key algorithms and key sizes, but validation? just turn it off.) > So since we always know the name of the entity we are going to be talking > to. =C2=A0My assumption is that we are always going to pass an acceptor n= ame into You always know the name of the RP that you want to be talking to. If you want to do GSS w/ CB to TLS then ignore the RP's name from TLS. Note that CB implies that GSS must authenticate the RP to the client. > GSS-API. =C2=A0The acceptor name would be "plasma/serverName@domainName".= =C2=A0We Something like that, yes. > would say strip the left most dotted name as the server name and leave th= e > rest as the domain name. =C2=A0 Thus an example name might be > "plasma\mailPDP@windows.example.com". The details of this will likely be different. I'd say that you'd use GSS_C_NT_HOSTBASED syntax: service@hostname (FQDN). If a "realm" is needed we'll either inspect the actual target name after authentication completes or we'll use GSS_Set_name_attribute() to set the expected realm name of the target on the client side. The mechanism's translation of this might be service/hostname.fqdn@REALM, e.g., in the case of Kerberos. > Now we start looking at some fun things. > > 1. =C2=A0If the url was > https://mailPDP.windows.example.com/internalPolicyChecker, should the ext= ra > verbage be reflected in the service name string? If the URL's scheme was HTTP and we're usign HTTP/Negotiate then the RP's name should be HTTP@mailPDP.windows.example.com. We could agree to make it different, but that would break the current convention. Or we could use something other than HTTP/Negotiate. > 2. =C2=A0Do we need to say anything special about walking up domain names= when > doing checking or during AAA processing? =C2=A0Specifically, should a dom= ain > string be truncated when doing the channel binding processing called out = in > the EMU channel bindings document wrt to the database lookup code? I don't understand this. Are we talking about EAP channel binding here instead of GSS channel binding? > 3. =C2=A0In the current code, one would expect that the client would send= the > full name to the RP as part of the first GSS-API handshake message. =C2= =A0I still > feel somewhat uncomfortable with telling the RP what its full name is goi= ng > to be, but I don't see any way around this with the current GSS-API calli= ng It is not possible to design an authentication protocol that provides privacy protection (from active attacks) to both peers, not without having a trusted third party to which the two peers authenticate first and which then decides if/what they should be allowed to know each other. Moreover, traffic analysis alone will generally disclose the name of the RP, except in peer-to-peer applications. Is this a p2p application? > code. =C2=A0That is since I want the channel binding to occur w/ a specif= ic > server and domain, there is no way not to let the RP know what they are > going to be in advance. =C2=A0I understand that the AAA system will valid= ate that > the RP has the right to the name so there should not be any issues, but i= s > there any way to make me feel =C2=A0more comfortable with this? What is the problem with the RP knowing what it was called by the client? (I'm not saying there can't be a problem, just that I want to know it :) > 4. =C2=A0Since I am using TLS, I will need to specify that TLS channel bi= nding > will occur (and find the appropriate references about how this works for > extraction). =C2=A0I am still trying to debate if I need to include addit= ional > channel binding data from my protocol dialog as well. =C2=A0Has anybody w= ritten You certainly can! > any guidance on when this is recommended and what types of data need to b= e > included? =C2=A0I think I have re-designed my protocol so this is no long= er > necessary, but I would like some assurance that I am correct. CB can be used to provide [after-the-fact] integrity protection to non-CB data that is sent in the clear before or during the GSS security context token exchange. More later, after lunch, Nico -- From hartmans@painless-security.com Fri Dec 16 11:14:51 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B040D21F84D7 for ; Fri, 16 Dec 2011 11:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_81=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJyqK9uaTpNC for ; Fri, 16 Dec 2011 11:14:51 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 486EE21F84CE for ; Fri, 16 Dec 2011 11:14:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 935D5201F1; Fri, 16 Dec 2011 14:14:48 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 11C3C42F2; Fri, 16 Dec 2011 14:14:45 -0500 (EST) From: Sam Hartman To: Alexey Melnikov References: <4E75ACD5.5000104@isode.com> Date: Fri, 16 Dec 2011 14:14:45 -0500 In-Reply-To: <4E75ACD5.5000104@isode.com> (Alexey Melnikov's message of "Sun, 18 Sep 2011 09:33:25 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 19:14:51 -0000 >>>>> "Alexey" == Alexey Melnikov writes: Alexey> General comment: the document is using terminology for Alexey> multiple technologies (EAP, GSS-API and even SASL). While I Alexey> think the document is correct and it explains most of the Alexey> terms used, some additional references on first use would be Alexey> very helpful in order to improve readability. In particular Alexey> I am thinking about Section 1 and its subsections, Alexey> e.g. Section 1.2. I think we're good on references at this point; please suggest specific text if you believe we need more. I think references have been added since you wrote the review. Alexey> 5.1. Mechanisms and Encryption Types Alexey> 5.2. Processing received tokens Alexey> Implementations of this mechanism maintain a state machine Alexey> for the context establishment process. Both the initiator Alexey> and acceptor start out in the initial state; see Section 5.4 Alexey> for a description of this state. Associated with each state Alexey> are a set of subtoken types that are processed in that state Alexey> and rules for processing these subtoken types. The reciever Alexey> examines the subtokens in order, processing any that are Alexey> appropriate for the current state. Alexey> What happens to the subtokens which are not appropriate for Alexey> the current state? I think it is fine to leave that undefined. I did clearly add a requirement that unknown tokens MUST be ignored. Alexey> 5.4.2. Acceptor Name Request Alexey> The acceptor name request token is sent from the initiator Alexey> to the acceptor indicating that the initiator wishes a Alexey> particular acceptor name. This is similar to TLS Server Alexey> Name Indication. Alexey> This needs an Informative Reference. Can you find the right reference? I spent 10 minutes and failed. Alexey> In Section 5.5: Alexey> o If the acceptor receives an EAP failure, then the Alexey> acceptor sends this in the Eap Request subtoken type. If Alexey> the initiator receives an EAP Failure, it returns GSS Alexey> failure. Alexey> Can you expand on what you mean here. "receive" doesn't mean Alexey> receive over the wire here, right? I think it does. Alexey> Also, what does it mean Alexey> to return a "GSS failure"? That's a return status from a GSS call. Alexey> 5.6.2. Channel Bindings Subtoken Alexey> Again, only the application data is sent in the channel Alexey> binding. The initiator and acceptor addresses are ignored. Alexey> I am not entirely clear on what you mean here by "addresses Alexey> are ignored". They are not included in the subtoken; text clarified in my copy of the draft. Alexey> In 5.6.3: Alexey> The input to GSS_GetMIC is as follows: Alexey> 1. The DER-encoded object identifier of the mechanism in Alexey> use; this value starts with 0x06 (the tag for object Alexey> identifier). When encoded in an RFC 2743 context token, the Alexey> object identifier is preceeded by the tag and length for Alexey> [Application 0] SEQUENCE. This tag and the length of the Alexey> overall token is not inclded; only the tag, length and value Alexey> of the object identifier itself. Alexey> 2. A 16-bit token type in network byte order of the RFC Alexey> 4121 token identifier (0x0601 for initiator, 0x0602 for Alexey> acceptor). Alexey> 3. For each subtoken other than the MIC subtoken itself: Alexey> What is the order of subtokens? same order as in the inner token; text clarified in my copy of the draft. Alexey> Does this cover all Alexey> subtokens sent during the extension phase? Does this cover Alexey> only subtokens sent by the initiator/acceptor respectively? Only subtokens in the current inner token. Alexey> 6. Acceptor Services Alexey> The CRK is derived from the GMSK using the following Alexey> procedur Alexey> Typo: procedure Alexey> Tn = pseudo-random(KMSK, n || "rfc4121-gss-eap") Alexey> How is "n" respresented, in particular how many bytes are Alexey> used to represent it? Alexey> CRK = truncate(L, T1 || T2 || .. || Tn) L = output RFC Alexey> 3961 key size I clarified than n starts at 0 and is 32-bits in network byte order. I believ your other comments have been address trivially or already discussed on the list because someone else brought them up. Section 8.4 still has not been resolved, but that is being tracked by issue #31. From nico@cryptonector.com Fri Dec 16 14:26:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688D21F0C3F for ; Fri, 16 Dec 2011 14:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TijHCZ28an6q for ; Fri, 16 Dec 2011 14:26:00 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id D15DD1F0C53 for ; Fri, 16 Dec 2011 14:26:00 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 748007E4071 for ; Fri, 16 Dec 2011 14:26:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=UEajIgSaHaxrmpScUeDCnb2iKPSoJSHKb44riGbxPxD1 7GyyprW9BLrK+hyQEplB77va96BNuM4EzK9R3ecregOZrhMRr5nZHQNlBQU70DB5 DaCrdt1XxYnyfmtNLcm/HK54k88qZcXzoTnDxbYyONxIs3+vkuydKeJhbWhqCnM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=v95tAjXMKCIBNYQhSVYjz/FlPjc=; b=agZXXCn2mSg BE81uZfIMjPAI1cNMEP8Gos/XsnU1T309Ozpe/jBhDuTNS12b8Bz19K6GwJiOgub aTZ4MP33aoqWtEyIqcpvnLjxvgz0+DuJE2m+f4gt6vP7V4gELMDHi1CqQbPeWSP3 62Q6zF4pGveW3hehzJyfzE153uAmJxy8= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 50C747E4065 for ; Fri, 16 Dec 2011 14:26:00 -0800 (PST) Received: by pbdd12 with SMTP id d12so2649929pbd.31 for ; Fri, 16 Dec 2011 14:25:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.209.3 with SMTP id mi3mr19342962pbc.16.1324074359869; Fri, 16 Dec 2011 14:25:59 -0800 (PST) Received: by 10.68.32.227 with HTTP; Fri, 16 Dec 2011 14:25:59 -0800 (PST) In-Reply-To: <02f901ccbbc8$dd761b20$98625160$@augustcellars.com> References: <02f901ccbbc8$dd761b20$98625160$@augustcellars.com> Date: Fri, 16 Dec 2011 16:25:59 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Trying to get Plasma text correct. X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2011 22:26:01 -0000 On Fri, Dec 16, 2011 at 2:01 AM, Jim Schaad wrote: > 5. =C2=A0If I get to this point, have I already selected the credential t= hat I > will be using with the EAP server, or I have just gotten to the point of > saying that I will be using one of a set of credentials? =C2=A0This is an= LOA > question. =C2=A0I will have already selected the realm that I am going to= be > authenticated against since I know that goes out in the first GSS-API/EAP > message. =C2=A0I also understand that by selecting a realm, I may have re= stricted > the set of possible LOAs that I can be dealing with. =C2=A0Should my prot= ocol > allow for some type of re-start of negotiation if a different LOA is need= ed? It's always nice to be able to restart authentication if it fails. SSHv2 supports multiple userauth attempts, but not multiple key exchange attempts, which means that SSHv2 with GSS key exchange (an option where we do GSS and key exchange in one go) is painful when GSS fails. I strongly recommend that authentication be retriable. I believe HTTP/Negotiate is (you're already using HTTP/1.1 if you're using HTTP/Negotiate with multi-round-trip mechanisms anyways!). Also, I don't think you'll always know the realm of the target a priori. Certainly not in the case of HTTP, not unless the realm directly matches the server's DNS domain. > I assume that would need to be a total re-start of the GSS-API/EAP > negotiation at a minimum although I could leave up the TLS session. Yes, it'd be a restart of GSS, but there'd be no need to restart TLS, unless the application protocol really can't deal with the GSS restart. > 6. =C2=A0Should I be setting up some type of negotiation in my protocol t= o allow > for a different GSS-API mechanism to be selected? =C2=A0I.e. if one is wi= thin a If we're talking about HTTP/Negotiate well, you already have SPNEGO for tha= t. > single company one could use the Kerberos GSS-API rather than going with = the > EAP version. =C2=A0Would be think this is of importance or can I just res= trict to > using the one GSS-API mechanism and be done with it? =C2=A0Can this type = of > negotiation be done within GSS-API? =C2=A0I don't remember seeing anythin= g of > this sort but that does not mean it does not exist. =C2=A0My understandin= g was > that it amounted to configuration information on the client side. SPNEGO is a pseudo-mechanism that negotiates mechanisms, so that's "within = GSS". Some application protocols can do this negotiation themselves. For example: SSHv2. Nico -- From zhou.sujing@zte.com.cn Fri Dec 16 18:13:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0DB11E808A for ; Fri, 16 Dec 2011 18:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.048 X-Spam-Level: X-Spam-Status: No, score=-96.048 tagged_above=-999 required=5 tests=[AWL=-3.858, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3hGMqwwtPH5 for ; Fri, 16 Dec 2011 18:13:00 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 757B31F0C3B for ; Fri, 16 Dec 2011 18:12:59 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 56690967931198; Sat, 17 Dec 2011 09:55:38 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 95341.2340413763; Sat, 17 Dec 2011 10:12:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pBH2Ckqw075706; Sat, 17 Dec 2011 10:12:46 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Sat, 17 Dec 2011 10:12:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-17 10:12:47, Serialize complete at 2011-12-17 10:12:47 Content-Type: multipart/alternative; boundary="=_alternative 000C289C48257969_=" X-MAIL: mse01.zte.com.cn pBH2Ckqw075706 Cc: abfab@ietf.org Subject: [abfab] =?gb2312?b?tPC4tDogUmU6ICBhIHJldmlldyBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWFiZmFiLWdzcy1lYXAtMDQ=?= X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 02:13:01 -0000 This is a multipart message in MIME format. --=_alternative 000C289C48257969_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 UmVnYXJkc35+fg0KDQotU3VqaW5nIFpob3UNCg0KU2FtIEhhcnRtYW4gPGhhcnRtYW5zQHBhaW5s ZXNzLXNlY3VyaXR5LmNvbT4g0LTT2iAyMDExLTEyLTE3IDAyOjM4OjMzOg0KDQo+ID4+Pj4+ICJ6 aG91IiA9PSB6aG91IHN1amluZyA8emhvdS5zdWppbmdAenRlLmNvbS5jbj4gd3JpdGVzOg0KPiAN Cj4gICAgIHpob3U+IEhpLGFsbCwgdGhlIGZvbGxvd2luZyBhcmUgcXVlc3Rpb25zIG9jY3VyZWQg dG8gbWUgd2hlbiByZWFkaW5nDQo+ICAgICB6aG91PiBkcmFmdC1pZXRmLWFiZmFiLWdzcy1lYXAt MDQ6DQo+IA0KPiANCj4gICAgIHpob3U+IDEuIFNlY3Rpb24gMSAiVGhlIEV4dGVuc2libGUgQXV0 aGVudGljYXRpb24gUHJvdG9jb2wgKEVBUCkNCj4gICAgIHpob3U+IFtSRkMzNzQ4XSBkZWZpbmVz IGEgZnJhbWV3b3JrIGZvciBhdXRoZW50aWNhdGluZyBhIG5ldHdvcmsNCj4gICAgIHpob3U+IGFj Y2VzcyBjbGllbnQgYW5kIHNlcnZlciBpbiBvcmRlciB0byBnYWluIGFjY2VzcyB0byBhDQo+ICAg ICB6aG91PiBuZXR3b3JrLiINCj4gDQo+ICAgICB6aG91PiAgIHNpbmNlIGFwcGxpY2FiaWxpdHkg b2YgRUFQIGlzIHVuZGVyIHVwZGF0aW5nIGJleW9uZCBuZXR3b3JrDQo+ICAgICB6aG91PiBhY2Nl c3MsIEkgdGhpbmsgdGhlIGluZm9ybWF0aW9uIG9mIFNlY3Rpb24gNyBtaWdodCBhcyB3ZWxsIGJl DQo+ICAgICB6aG91PiBpbmRpY2F0ZWQgaGVyZS4NCj4gDQo+IEkndmUgb3BlbmVkIGlzc3VlICMz MCB0byB0cmFjayB0aGlzLg0KPiANCj4gDQo+ICAgICB6aG91PiAyLiAgc2VjdGlvbiA1LjQuMiBh bmQgc2VjdGlvbiA1LjcgV2h5IHdvdWxkIGFjY2VwdG9yIG5hbWUNCj4gICAgIHpob3U+IGFwcGVh ciBpbiBhIGFjY2VwdG9yIG5hbWUgcmVxdWVzdD8NCj4gDQo+IFRoZSBhY2NlcHRvciBuYW1lIHJl cXVlc3QgIGFza3MgZm9yIGEgcGFydGljdWxhciBhY2NlcHRvciAgaWYgdGhlDQo+IGFjY2VwdG9y IGlzIGNhcGFibGUgb2YgYWN0aW5nIGFzIG11bHRpcGxlIGVudGl0ZXMvdmlydHVhbCBob3N0cy4N Cj4gSXQncyBqdXN0IGxpa2UgdGhlIEhvc3QgaGVhZGVyIGluIEhUVFAgb3IgdGhlIHNlcnZlci1u YW1lLWluZGljYXRpb24gaW4NCj4gVExTLg0KPiBJJ2QgYmUgaW50ZXJlc3RlZCBpbiBhbnkgY2xh cmlmaWNhdGlvbnMgeW91IGNhbiBzdWdnZXN0IHNvIG90aGVycyBkb24ndA0KPiBoYXZlIHRoZSBz YW1lIGNvbmZ1c2lvbi4NCldoaWxlLCBJIHRoaW5rDQoxLiBpdCBiZXR0ZXIgaGF2ZSBhIHJlZmVy ZW5jZSAoSSBndWVzcyBpdCBpcyBSRkM2MDY2KSBhZnRlciAiIFRoaXMgaXMgDQpzaW1pbGFyIHRv IFRMUyBTZXJ2ZXIgTmFtZSBJbmRpY2F0aW9uIiwgYW5kIGhhdmUgYSBicmllZiBleHBsYWludGF0 aW9uIA0KYWJvdXQgdGhlIHVzZSBvZiBTZXJ2ZXIgbmFtZSBpbmRpY2F0aW9uIHRoZXJlLCBzaW5j ZSBpdCBpcyBub3QgaW5sY3VkZWQgaW4gDQpUTFMgYnV0IGFuIGV4dGVuc2lvbiwgYW5kIG1heSBi ZSBub3Qga25vd24gYnkgbW9zdCBwZW9wbGUgKGxpa2UgbWUgOikgKS4NCjIuIGFuZCBiZXR0ZXIg Y2hhbmdlIHRoZSAiQWNjZXB0b3IgTmFtZSBSZXF1ZXN0IiB0byAiQWNjZXB0b3IgTmFtZSANCklu ZGljYXRpb24iIHNpbmNlIGl0IGlzIFJFQUxMWSBlYXN5IHRvIA0KdGFrZSAiQWNjZXB0b3IgTmFt ZSBSZXF1ZXN0IiBhbmQgIkFjY2VwdG9yIE5hbWUgUmVzcG9uc2UiIGFzIGEgcGFpciBvZiANCnJl cXVlc3RpbmcgYW5kIGFuc3dlcmluZyB0aGUgbmFtZSBvZiBhY2NlcHRvci4NCjMuIHB1dCBzb21l IG1vcmUgZXhwbGFpbmluZyAgd29yZHMgaW4gdGhlIGJlZ2lubmluZyBvZiBTZWN0aW9uIDUuNC4y IA0KDQo+IA0KPiAgICAgemhvdT4gMy4gIHNlY3Rpb24gNS40LjMgIlR5cGljYWxseSB0aGlzIHRv a2VuIHdvdWxkIG9ubHkgYmUgc2VuZCBpZg0KPiAgICAgemhvdT4gdGhlIGFjY2VwdG9yIG5hbWUg cmVxdWVzdCBpcyBhYnNlbnQuIiAgQWNjZXB0b3IgbmFtZSByZXNwb25zZQ0KPiAgICAgemhvdT4g aXMgc2VudCBvbmx5IHdoZW4gbm8gYWNjZXB0b3IgbmFtZSByZXF1ZXN0IGhhcyBiZWVuIHJlY2Vp dmVkPw0KPiANCj4gSmltIHByb3Bvc2VkIGNoYW5naW5nIHRoaXMgYXQgSUVURiA4MiBhbmQgSSBo YXZlIHNlZW4gbm8gb2JqZWN0aW9ucyB0bw0KPiB0aGF0IGNoYW5nZS4NCj4gDQo+ICAgICB6aG91 PiA0LiBzZWN0aW9uIDUuNiAiQWZ0ZXIgRUFQIHN1Y2Nlc3MsIHRoZSBpbml0aWF0b3Igc2VuZHMg YSB0b2tlbg0KPiAgICAgemhvdT4gdG8gdGhlIGFjY2VwdG9yIGluY2x1ZGluZyBhZGRpdGlvbmFs IHN1YnRva2VucyB0aGF0IG5lZ290aWF0ZQ0KPiAgICAgemhvdT4gb3B0aW9uYWwgZmVhdHVyZXMg b3IgcHJvdmlkZSBHU1MtQVBJIGNoYW5uZWwgYmluZGluZyAoc2VlDQo+ICAgICB6aG91PiBTZWN0 aW9uIDYuMSkuIg0KPiANCj4gICAgIHpob3U+ICAgIEFjY29yZGluZyB0byBSRkMyNzQzLCBHU1Mt QVBJIGNoYW5uZWwgYmluZGluZyBpbmZvcm1hdGlvbg0KPiAgICAgemhvdT4gaXMgcHJvdmlkZWQg YXMgYW4gaW5wdXQgdG8gR1NTX0luaXRfc2VjX2NvbnRleHQoKSwgaS5lLiwNCj4gICAgIHpob3U+ IGJlZm9yZSBFQVAgc3VjZXNzLCBzbyBob3cgYW5kIHdoeSBzZW5kIEdTUy1BUEkgY2hhbm5lbCBi aW5kaW5nDQo+ICAgICB6aG91PiBoZXJlPw0KPiANCj4gDQo+IEl0J3Mgbm90IHJlYWxseSB0cnVl IHRoYXQgZ3NzX2luaXRfc2VjX2NvbnRleHQgaXMgYmVmb3JlIGVhcCBzdWNjZXNzLg0KPiBZb3Ug Y2FsbCBpdCBtdWx0aXBsZSB0aW1lcy4NCj4gT05lIG9mIHRob3NlIHRpbWVzIHlvdSBuZWVkIHRv IHNlbmQgR1NTIGNoYW5uZWwgYmluZGluZyBkYXRhOyB0aGUNCj4gc2VjdGlvbiB5b3UgIHF1b3Rl IGRlc2NyaWJlcyBob3cuDQo+IA0KPiANCj4gDQo+ICAgICB6aG91PiA1LiAiVGhlIFBST1RfUkVB RFkgc2VydmljZSBpcyBuZXZlciBhdmFpbGFibGUgd2l0aCB0aGlzDQo+ICAgICB6aG91PiBtZWNo YW5pc20uIiAgd2hhdCBpcyBQUk9UX1JFQURZIHNlcnZpY2U/IEkgY2Fubid0IGZpbmQgYW55DQo+ ICAgICB6aG91PiByZWZlcmVuY2UgdG8gaXQuDQo+IFNlY3Rpb24gMS4yLjcgb2YgUkZDIDI3NDM7 IHRoZSBkb2N1bWVudCBoYXMgYmVlbiB1cGRhdGVkIHdpdGggdGhpcw0KPiAgICAgemhvdT4gcmVm ZXJlbmNlLg0KPiANCj4gDQo+IA0KPiANCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkg cHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmlj YXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0 ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBp bnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRv IHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFu eSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZp ZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 000C289C48257969_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlJlZ2FyZHN+fn48YnI+DQo8YnI+ DQotU3VqaW5nIFpob3U8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5TYW0gSGFy dG1hbiAmbHQ7aGFydG1hbnNAcGFpbmxlc3Mtc2VjdXJpdHkuY29tJmd0Ow0K0LTT2iAyMDExLTEy LTE3IDAyOjM4OjMzOjxicj4NCjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7 emhvdSZxdW90OyA9PSB6aG91IHN1amluZyAmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsN CndyaXRlczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0OyBIaSxh bGwsIHRoZSBmb2xsb3dpbmcgYXJlIHF1ZXN0aW9ucyBvY2N1cmVkDQp0byBtZSB3aGVuIHJlYWRp bmc8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgemhvdSZndDsgZHJhZnQtaWV0Zi1hYmZhYi1nc3Mt ZWFwLTA0Ojxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgemhv dSZndDsgMS4gU2VjdGlvbiAxICZxdW90O1RoZSBFeHRlbnNpYmxlIEF1dGhlbnRpY2F0aW9uDQpQ cm90b2NvbCAoRUFQKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0OyBbUkZDMzc0OF0g ZGVmaW5lcyBhIGZyYW1ld29yayBmb3IgYXV0aGVudGljYXRpbmcNCmEgbmV0d29yazxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0OyBhY2Nlc3MgY2xpZW50IGFuZCBzZXJ2ZXIgaW4gb3Jk ZXIgdG8gZ2FpbiBhY2Nlc3MNCnRvIGE8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgemhvdSZndDsg bmV0d29yay4mcXVvdDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgemhvdSZndDsgJm5ic3A7IHNpbmNlIGFwcGxpY2FiaWxpdHkgb2YgRUFQIGlzIHVuZGVy DQp1cGRhdGluZyBiZXlvbmQgbmV0d29yazxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0 OyBhY2Nlc3MsIEkgdGhpbmsgdGhlIGluZm9ybWF0aW9uIG9mIFNlY3Rpb24NCjcgbWlnaHQgYXMg d2VsbCBiZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0OyBpbmRpY2F0ZWQgaGVyZS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSd2ZSBvcGVuZWQgaXNzdWUgIzMwIHRvIHRyYWNrIHRoaXMu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0OyAy LiAmbmJzcDtzZWN0aW9uIDUuNC4yIGFuZCBzZWN0aW9uIDUuNyBXaHkNCndvdWxkIGFjY2VwdG9y IG5hbWU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgemhvdSZndDsgYXBwZWFyIGluIGEgYWNjZXB0 b3IgbmFtZSByZXF1ZXN0Pzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgYWNjZXB0b3IgbmFtZSBy ZXF1ZXN0ICZuYnNwO2Fza3MgZm9yIGEgcGFydGljdWxhciBhY2NlcHRvciAmbmJzcDtpZg0KdGhl PGJyPg0KJmd0OyBhY2NlcHRvciBpcyBjYXBhYmxlIG9mIGFjdGluZyBhcyBtdWx0aXBsZSBlbnRp dGVzL3ZpcnR1YWwgaG9zdHMuPGJyPg0KJmd0OyBJdCdzIGp1c3QgbGlrZSB0aGUgSG9zdCBoZWFk ZXIgaW4gSFRUUCBvciB0aGUgc2VydmVyLW5hbWUtaW5kaWNhdGlvbg0KaW48YnI+DQomZ3Q7IFRM Uy48YnI+DQomZ3Q7IEknZCBiZSBpbnRlcmVzdGVkIGluIGFueSBjbGFyaWZpY2F0aW9ucyB5b3Ug Y2FuIHN1Z2dlc3Qgc28gb3RoZXJzDQpkb24ndDxicj4NCiZndDsgaGF2ZSB0aGUgc2FtZSBjb25m dXNpb24uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5XaGlsZSwgSSB0aGluazwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+MS4gaXQgYmV0dGVyIGhhdmUgYSByZWZl cmVuY2UgKEkgZ3Vlc3MgaXQgaXMgUkZDNjA2NikNCmFmdGVyICZxdW90OyBUaGlzIGlzIHNpbWls YXIgdG8gVExTIFNlcnZlciBOYW1lIEluZGljYXRpb24mcXVvdDssIGFuZCBoYXZlDQphIGJyaWVm IGV4cGxhaW50YXRpb24gYWJvdXQgdGhlIHVzZSBvZiBTZXJ2ZXIgbmFtZSBpbmRpY2F0aW9uIHRo ZXJlLCBzaW5jZQ0KaXQgaXMgbm90IGlubGN1ZGVkIGluIFRMUyBidXQgYW4gZXh0ZW5zaW9uLCBh bmQgbWF5IGJlIG5vdCBrbm93biBieSBtb3N0DQpwZW9wbGUgKGxpa2UgbWUgOikgKS48L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjIuIGFuZCBiZXR0ZXIgY2hhbmdlIHRoZSAmcXVv dDtBY2NlcHRvciBOYW1lIFJlcXVlc3QmcXVvdDsNCnRvICZxdW90O0FjY2VwdG9yIE5hbWUgSW5k aWNhdGlvbiZxdW90OyBzaW5jZSBpdCBpcyBSRUFMTFkgZWFzeSB0byA8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPnRha2UgJnF1b3Q7QWNjZXB0b3IgTmFtZSBSZXF1ZXN0JnF1b3Q7 IGFuZCAmcXVvdDtBY2NlcHRvcg0KTmFtZSBSZXNwb25zZSZxdW90OyBhcyBhIHBhaXIgb2YgcmVx dWVzdGluZyBhbmQgYW5zd2VyaW5nIHRoZSBuYW1lIG9mIGFjY2VwdG9yLjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+My4gcHV0IHNvbWUgbW9yZSBleHBsYWluaW5nICZuYnNwO3dv cmRzIGluIHRoZSBiZWdpbm5pbmcNCm9mIFNlY3Rpb24gNS40LjIgPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB6aG91 Jmd0OyAzLiAmbmJzcDtzZWN0aW9uIDUuNC4zICZxdW90O1R5cGljYWxseSB0aGlzDQp0b2tlbiB3 b3VsZCBvbmx5IGJlIHNlbmQgaWY8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgemhvdSZndDsgdGhl IGFjY2VwdG9yIG5hbWUgcmVxdWVzdCBpcyBhYnNlbnQuJnF1b3Q7DQombmJzcDtBY2NlcHRvciBu YW1lIHJlc3BvbnNlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHpob3UmZ3Q7IGlzIHNlbnQgb25s eSB3aGVuIG5vIGFjY2VwdG9yIG5hbWUgcmVxdWVzdA0KaGFzIGJlZW4gcmVjZWl2ZWQ/PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEppbSBwcm9wb3NlZCBjaGFuZ2luZyB0aGlzIGF0IElFVEYgODIgYW5k IEkgaGF2ZSBzZWVuIG5vIG9iamVjdGlvbnMNCnRvPGJyPg0KJmd0OyB0aGF0IGNoYW5nZS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0OyA0LiBzZWN0aW9uIDUuNiAm cXVvdDtBZnRlciBFQVAgc3VjY2VzcywgdGhlDQppbml0aWF0b3Igc2VuZHMgYSB0b2tlbjxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0OyB0byB0aGUgYWNjZXB0b3IgaW5jbHVkaW5nIGFk ZGl0aW9uYWwgc3VidG9rZW5zDQp0aGF0IG5lZ290aWF0ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyB6aG91Jmd0OyBvcHRpb25hbCBmZWF0dXJlcyBvciBwcm92aWRlIEdTUy1BUEkgY2hhbm5lbA0K YmluZGluZyAoc2VlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHpob3UmZ3Q7IFNlY3Rpb24gNi4x KS4mcXVvdDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsg emhvdSZndDsgJm5ic3A7ICZuYnNwO0FjY29yZGluZyB0byBSRkMyNzQzLCBHU1MtQVBJDQpjaGFu bmVsIGJpbmRpbmcgaW5mb3JtYXRpb248YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgemhvdSZndDsg aXMgcHJvdmlkZWQgYXMgYW4gaW5wdXQgdG8gR1NTX0luaXRfc2VjX2NvbnRleHQoKSwNCmkuZS4s PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHpob3UmZ3Q7IGJlZm9yZSBFQVAgc3VjZXNzLCBzbyBo b3cgYW5kIHdoeSBzZW5kIEdTUy1BUEkNCmNoYW5uZWwgYmluZGluZzxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyB6aG91Jmd0OyBoZXJlPzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0 J3Mgbm90IHJlYWxseSB0cnVlIHRoYXQgZ3NzX2luaXRfc2VjX2NvbnRleHQgaXMgYmVmb3JlIGVh cCBzdWNjZXNzLjxicj4NCiZndDsgWW91IGNhbGwgaXQgbXVsdGlwbGUgdGltZXMuPGJyPg0KJmd0 OyBPTmUgb2YgdGhvc2UgdGltZXMgeW91IG5lZWQgdG8gc2VuZCBHU1MgY2hhbm5lbCBiaW5kaW5n IGRhdGE7IHRoZTxicj4NCiZndDsgc2VjdGlvbiB5b3UgJm5ic3A7cXVvdGUgZGVzY3JpYmVzIGhv dy48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgemhvdSZndDsgNS4gJnF1b3Q7VGhlIFBST1RfUkVBRFkgc2VydmljZSBpcyBuZXZlciBhdmFp bGFibGUNCndpdGggdGhpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyB6aG91Jmd0OyBtZWNoYW5p c20uJnF1b3Q7ICZuYnNwO3doYXQgaXMgUFJPVF9SRUFEWSBzZXJ2aWNlPw0KSSBjYW5uJ3QgZmlu ZCBhbnk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgemhvdSZndDsgcmVmZXJlbmNlIHRvIGl0Ljxi cj4NCiZndDsgU2VjdGlvbiAxLjIuNyBvZiBSRkMgMjc0MzsgdGhlIGRvY3VtZW50IGhhcyBiZWVu IHVwZGF0ZWQgd2l0aCB0aGlzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7IHpob3UmZ3Q7IHJlZmVy ZW5jZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwv Zm9udD48L3R0Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0 eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZu YnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3Bl cnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJz cDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVu dGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNw O29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5i c3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNw O3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZu YnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5i c3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNw O2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9y Jm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7 b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7 YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7 dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlm eSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2Uu Jm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2 aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4m bmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJz cDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 000C289C48257969_=-- From hannes.tschofenig@nsn.com Sat Dec 17 07:18:50 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C89521F84B3 for ; Sat, 17 Dec 2011 07:18:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6UIWOKCX6z4 for ; Sat, 17 Dec 2011 07:18:49 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1CE21F8AD8 for ; Sat, 17 Dec 2011 07:18:48 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBHFIilQ005999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Dec 2011 16:18:44 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBHFIg0i023195 for ; Sat, 17 Dec 2011 16:18:44 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Dec 2011 16:18:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBCCF.29325A21" Date: Sat, 17 Dec 2011 17:20:37 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 12 - AAA vs RADIUS vs DIAMETER terms Thread-Index: Acy8z23LJXP1+sO7TuGe+2q5tYGe3Q== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Dec 2011 15:18:42.0549 (UTC) FILETIME=[2962BA50:01CCBCCF] Subject: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 15:18:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBCCF.29325A21 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim,=20 thank you for your detailed review. In issue 12 http://trac.tools.ietf.org/wg/abfab/trac/ticket/12 you wrote: " We have defined a IdP as containing a radius server.=20 Issue #1 is should radius always be capitalized? Issue #2 At this point - should we say that we use the term RADIUS as being either RADIUS or DIAMETER? " Yes, RADIUS should be capitalized. Diameter is not capitalized.=20 Regarding item #2 we have two options: a) We could instead of using the term RADIUS use AAA to refer to both RADIUS and Diameter. b) We could, as you indicate, state that we use the term RADIUS without any loss of generality.=20 I think the question ultimately boils down to what our audience better understands. I don't really know but I prefer (a) since that's what I have done in other docs. Ciao Hannes ------_=_NextPart_001_01CCBCCF.29325A21 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 12 - AAA vs RADIUS vs DIAMETER terms

Hi Jim,

thank you for = your detailed review.

In issue 12 http://trac.tools.ietf.org/wg/abfab/trac/ticket/12 you wrote:

“

We have defined a IdP as containing a radius server. =

Issue = #1 is should radius always be = capitalized?

Issue = #2 At this point - should we say = that we use the term RADIUS as being either RADIUS or = DIAMETER?

“

Yes, RADIUS = should be capitalized. Diameter is not = capitalized. =

Regarding item #2 we have two = options:

a)      We could instead of using the = term RADIUS use AAA to refer to both RADIUS = and Diameter.

b)      We could, as you = indicate, = state that we = use the term RADIUS without any loss of = generality.

I think the = question ultimately boils down to what our = audience better understands.

I don’t really = know but I prefer (a) since = that’s what I have done in other = docs.

Ciao

Hannes

------_=_NextPart_001_01CCBCCF.29325A21-- From hannes.tschofenig@nsn.com Sat Dec 17 08:02:17 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A07A21F8AC3 for ; Sat, 17 Dec 2011 08:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.561 X-Spam-Level: X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS08jkaBcaGv for ; Sat, 17 Dec 2011 08:02:16 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 52A4C21F8ABD for ; Sat, 17 Dec 2011 08:02:16 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBHG2AG7007552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Dec 2011 17:02:12 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBHG26Lb007813 for ; Sat, 17 Dec 2011 17:02:10 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Dec 2011 17:00:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {BC33AE29-C990-49EE-A8B4-4B5904BDADC9} x-cr-hashedpuzzle: MKo= AvsH CmSZ DSVU DWDS ENo7 EuTq EvS4 Hu5f I1DT I8gF I++Z JDRH KM6l KU+D KZj0; 1; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {BC33AE29-C990-49EE-A8B4-4B5904BDADC9}; aABhAG4AbgBlAHMALgB0AHMAYwBoAG8AZgBlAG4AaQBnAEAAbgBzAG4ALgBjAG8AbQA=; Sat, 17 Dec 2011 16:02:36 GMT; SQBzAHMAdQBlACAAIwA2ACAALQAgAGIAYQBkACAAZgBsAG8AdwAgAG8AZgAgAHQAZQB4AHQAIABmAG8AcgAgAGEAdQB0AGgAZQBuAHQAaQBjAGEAdABpAG8AbgAgAHIAZQBxAHUAcgBpAGUAbQBlAG4AdABzAA== Content-class: urn:content-classes:message Date: Sat, 17 Dec 2011 18:02:36 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3802B@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue #6 - bad flow of text for authentication requriements Thread-Index: Acy81Usb9om037DGT62RUgUzgkvb1g== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Dec 2011 16:00:48.0585 (UTC) FILETIME=[0B053B90:01CCBCD5] Subject: [abfab] Issue #6 - bad flow of text for authentication requriements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 16:02:17 -0000 Hi Jim,=20 for issue#6 http://trac.tools.ietf.org/wg/abfab/trac/ticket/6 you wrote: " Has the sentences " Aside from a valuable secret being exposed, a synchronization problem can also often develop. Since there is no single authentication mechanism that will be used everywhere there is another associated requirement:" I have a couple of issues here. First there is a problem which is stated - i.e. synchronization - but the next sentence does not appear to expand on the problem but rather deals with a different issue. I would like to have the first thought finished before going onto the second one. I think this paragraph is supposed to be talking about issues that we have been taught - but the word Since does not convey this is a separate issue we have dealing with. " Here is the text from the draft: " 2.2. Subject To Identity Provider Traditional web federation does not describe how a subject communicates with an identity provider. As a result, this communication is not standardized. There are several disadvantages to this approach. It is difficult to have subjects that are machines rather than humans that use some sort of programatic credential. In addition, use of browsers for authentication restricts the deployment of more secure forms of authentication beyond plaintext username and password known by the server. In a number of cases the authentication interface may be presented before the subject has adequately validated they are talking to the intended server. By giving control of the authentication interface to a potential attacker, then the security of the system may be reduced and phishing opportunities introduced. As a result, it is desirable to choose some standardized approach for communication between the subject's end-host and the identity provider. There are a number of requirements this approach must meet. Experience has taught us one key security and scalability requirement: it is important that the relying party not get in possession of the long-term secret of the entity being authenticated by the AAA server. Aside from a valuable secret being exposed, a synchronization problem can also often develop. Since there is no single authentication mechanism that will be used everywhere there is another associated requirement: The authentication framework must allow for the flexible integration of authentication mechanisms. For instance, some identity providers may require hardware tokens while others may use passwords. A service provider would want to support both sorts of federations, and others. Fortunately, these requirements can be met by utilizing standardized and successfully deployed technology, namely by the Extensible Authentication Protocol (EAP) framework [RFC3748]. Figure 2 illustrates the integration graphically. EAP is an end-to-end framework; it provides for two-way communication between a peer (i.e,service client or principal) through the authenticator (i.e., service provider) to the back-end (i.e., identity provider). Conveniently, this is precisely the communication path that is needed for federated identity. Although EAP support is already integrated in AAA systems (see [RFC3579] and [RFC4072]) several challenges remain: one is to carry EAP payloads from the end host to the relying party. Another is to verify statements the relying party has made to the subject, confirm these statements are consistent with statements made to the identity provider and confirm all the above are consistent with the federation and any federation-specific policy or configuration. Another challenge is choosing which identity provider to use for which service. " The sentence you are referring to, namely "Aside from a valuable secret being exposed, a synchronization problem can also often develop." should be deleted. I understand that there may be a synchronization problem when you cache your distribute your long term secret everywhere but that's only secondary (and less important). If we avoid exposing the long term secret to the RP, which we do in the document by using the AAA infrastructure, then we do not have to worry about the synchronization issue.=20 There is a problem with the readability of the section in general. Here the text refers to the authentication protocol executed between the application used by the data subject and the identity provider, which is indeed left out-of-scope by many standardized Web identity management protocols, but it does not refer to any other steps the data subject may need to take as well in order to actually get the credentials provisioned at the IdP and to perform the steps for identity proofing. Ciao Hannes From hannes.tschofenig@nsn.com Sat Dec 17 08:30:04 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BAC21F8AAA for ; Sat, 17 Dec 2011 08:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.565 X-Spam-Level: X-Spam-Status: No, score=-106.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqSNeYV7mMca for ; Sat, 17 Dec 2011 08:30:02 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5655F21F8AA9 for ; Sat, 17 Dec 2011 08:30:01 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBHGU1TF027458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Dec 2011 17:30:01 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBHGTx0r003650 for ; Sat, 17 Dec 2011 17:30:00 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Dec 2011 17:29:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBCD9.1E51DC73" Date: Sat, 17 Dec 2011 18:31:53 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3802D@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 7 - Entity Naming Problems Galore Thread-Index: Acy82WK+j4RWGfL0QbugDV666qq4oQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Dec 2011 16:29:59.0327 (UTC) FILETIME=[1E8B42F0:01CCBCD9] Subject: [abfab] Issue 7 - Entity Naming Problems Galore X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 16:30:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBCD9.1E51DC73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim,=20 in issue #7 you raise the following issue: http://trac.tools.ietf.org/wg/abfab/trac/ticket/7 " There are massive problems throughout the document in that we are not using a consistant set of names for each of the entities in the document. Part of this issue is that there are different names for each of these entities in each of the different protocols that we are using. However it also makes the entire document difficult to follow as one needs to keep track of this all of the time.=20 THe following things need to be done: 1. A table that maps from the name used in the document to the name used in each of the different protocols=20 2. The use of a consistant name for each entity=20 3. Where feasible, you can do something like RP (Service Provider) so that both names are in the text.=20 " I agree with the challenge regarding the identity terminology in general and the problem of how the existing terminology used in various protocols aligns with the other protocols and the overall framework. Your suggestion will be difficult to implement, I believe, if you think about the figures and the message flows. A direct mapping isn't easy either.=20 In fact what we do most of the time in the document is use abstract concepts (like RP, IdP) and then instantiate them for our use case. In our architecture the IdP is using the AAA protocols (and as part of it EAP). =20 I am curious whether we could get away with better defining the abstract terms and in the other parts of the document where it matters focus on the technology only. For example, when we talk about the relying party we would that for it hosts the AAA client.=20 Does this make any sense to you? Ciao Hannes ------_=_NextPart_001_01CCBCD9.1E51DC73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 7 - Entity Naming Problems Galore

Hi Jim,

in issue #7 you = raise the following issue:

http://trac.tools.ietf.org/wg/abfab/trac/ticket/7=

“

There are massive problems = throughout the document in that we are not using a consistant set of = names for each of the entities in the document. Part of this issue is = that there are different names for each of these entities in each of the = different protocols that we are using. However it also makes the entire = document difficult to follow as one needs to keep track of this all of = the time.

THe = following things need to be done:

1.      A table that maps from the name used in the document to the name = used in each of the different protocols

2.      The use of a consistant = name for each entity

3.      Where feasible, you can = do something like RP (Service Provider) so that both names are in the = text.

“

I agree with the challenge = regarding the identity terminology in general and the problem of how the = existing terminology used in various protocols aligns with the other = protocols and the overall framework. Your suggestion will be difficult = to implement, I believe, = if you think about the figures and the message flows. A direct mapping = isn’t easy either.

In fact = what we do most of the time in the document is use abstract concepts = (like RP, IdP) and then instantiate them for our use = case. = In our architecture the IdP is using the AAA protocols (and as part of = it EAP). 

I am curious whether we = could get away with better defining the abstract terms = and in the other parts of the = document where it matters focus on the technology only. For example, = when we talk about the relying party we would that for it hosts the AAA client. =

Does = this make any sense to you?

Ciao
Hannes

------_=_NextPart_001_01CCBCD9.1E51DC73-- From hannes.tschofenig@nsn.com Sat Dec 17 08:35:26 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA4221F8AD8 for ; Sat, 17 Dec 2011 08:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.569 X-Spam-Level: X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UewjLfMhtpqW for ; Sat, 17 Dec 2011 08:35:22 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 55F4A21F8AB0 for ; Sat, 17 Dec 2011 08:35:20 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBHGZEcq031175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Dec 2011 17:35:17 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBHGZEek009611 for ; Sat, 17 Dec 2011 17:35:14 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Dec 2011 17:35:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Dec 2011 18:37:03 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3802E@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 18 - Missing issue? Thread-Index: Acy82htjI1BbpSwrRQKhs8H45wPAgg== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Dec 2011 16:35:14.0633 (UTC) FILETIME=[DA7B2390:01CCBCD9] Subject: [abfab] Issue 18 - Missing issue? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 16:35:26 -0000 Hi Jim,=20 in issue #18 http://trac.tools.ietf.org/wg/abfab/trac/ticket/18 you wrote: " Should the following issue be addressed as well? In the presence of multiple federations, the naming of individuals can become murky especially if one is trying to associate a single individual from different federations. Asking a question such as does John Doe belong to an IdP (in the absence of authentication) may get an answer for the wrong John Doe. " In the way we define the architecture this is actually not an issue. All entities are uniquely identified using a NAI and there is no mechanism to query IdPs in the style of "Do you happen to know John Doe?" What is an issue, which is outside the scope of our IETF work - I believe, is the ability to associate user accounts from different IdPs/federations. For example, I know known by one IdP as hannes.tschofenig and another one as user12345 and maybe these two have to be linked together.=20 I would say that we don't worry about these issues since I don't see the implications for our protocol work. I do, however, know that SAML tried to solve some of these account linking use cases and others may have more insight into how useful they had been. Ciao Hannes From hannes.tschofenig@nsn.com Sat Dec 17 08:47:23 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9AE121F8AAC for ; Sat, 17 Dec 2011 08:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mphEzJVE7fBd for ; Sat, 17 Dec 2011 08:47:22 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 72B6621F8AC3 for ; Sat, 17 Dec 2011 08:47:22 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBHGlLfR005519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Dec 2011 17:47:21 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBHGlLQj011137 for ; Sat, 17 Dec 2011 17:47:21 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Dec 2011 17:47:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBCDB.8B4B84AD" x-cr-puzzleid: {9C8BDAE4-293D-4DF1-B426-CB48DF3FCDFF} x-cr-hashedpuzzle: BRjT Brr2 C9J+ DRwk DSI+ D32d EVXb E0iB GGqS GsPk HBEH Iy1z JUAd JteL KHMQ LidV; 1; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {9C8BDAE4-293D-4DF1-B426-CB48DF3FCDFF}; aABhAG4AbgBlAHMALgB0AHMAYwBoAG8AZgBlAG4AaQBnAEAAbgBzAG4ALgBjAG8AbQA=; Sat, 17 Dec 2011 16:49:12 GMT; SQBzAHMAdQBlACAAMgA4ACAALQAgAEEAQQBBACAAcAByAG8AdABlAGMAdABpAG8AbgAgAG8AZgAgAHQAaABlACAATQBTAEsA Content-class: urn:content-classes:message Date: Sat, 17 Dec 2011 18:49:12 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3802F@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 28 - AAA protection of the MSK Thread-Index: Acy8283DodptS02bQ0ieBcDxCpfPaQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Dec 2011 16:47:21.0052 (UTC) FILETIME=[8B75E1C0:01CCBCDB] Subject: [abfab] Issue 28 - AAA protection of the MSK X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 16:47:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBCDB.8B4B84AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim,=20 in issue #28 http://trac.tools.ietf.org/wg/abfab/trac/ticket/28 you wrote: " The document needs to discuss the protections (or lack there of) for the MSK as it travels from the IdP to the RP. Known issues are: 1. In RADIUS the security (encryption and authentication) is hop to hop -so in theory any AAA proxy can decrypt the messages.=20 2. In Diameter there is no(?) current ability to encrypt either hop to hop or end-to-end.=20 "=20 The standardized and deployed security protection in RADIUS and Diameter is hop-by-hop. Hence, the AAA messages can be read by AAA intermediaries, which is the intention for most of the payload but not for the MSK.=20 Luckily, the MSK itself does not help these intermediaries since they do not get to see the data traffic that is protected with the MSK (or keys derived from the MSK). Nevertheless, it may be useful to point to http://tools.ietf.org/html/rfc4962 for a discussion of the security of the AAA key management. It is currently not referenced by the document.=20 Ciao Hannes ------_=_NextPart_001_01CCBCDB.8B4B84AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 28 - AAA protection of the MSK

Hi Jim,

in issue = #28 http://trac.tools.ietf.org/wg/abfab/trac/ticket/28 you = wrote:

“

The document needs to = discuss the protections (or lack there of) for the MSK as it travels = from the IdP to the RP. Known issues = are:

1.      In RADIUS the security (encryption and authentication) is hop to = hop -so in theory any AAA proxy can decrypt the messages. =

2.      In Diameter there is no(?) current ability to encrypt either hop = to hop or end-to-end.

“

The = standardized and deployed security protection in RADIUS and Diameter is = hop-by-hop. Hence, the AAA messages can be read by AAA intermediaries, which = is the intention for most of the payload but not for the MSK.

Luckily, the MSK itself does not = help these intermediaries = since they do not get to see the data traffic that is protected with the MSK (or keys derived from = the MSK).

Nevertheless, = it may be useful to point to http://tools.ietf.org/html/rfc4962 for a discussion of the security = of the AAA key management. It is currently not referenced by the = document. =

Ciao
Hannes

------_=_NextPart_001_01CCBCDB.8B4B84AD-- From hannes.tschofenig@nsn.com Sat Dec 17 09:00:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56A7321F8AD8 for ; Sat, 17 Dec 2011 09:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.273 X-Spam-Level: X-Spam-Status: No, score=-106.273 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z03irkkjRY+m for ; Sat, 17 Dec 2011 09:00:11 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 673DE21F89BA for ; Sat, 17 Dec 2011 09:00:10 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBHH09lC014491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 17 Dec 2011 18:00:09 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBHH06gd032609 for ; Sat, 17 Dec 2011 18:00:09 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Dec 2011 18:00:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBCDD.539E1365" Date: Sat, 17 Dec 2011 19:02:00 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE38030@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 23 - Clarifications and typos Thread-Index: Acy83ZfmJQCxtc/kS5m2WEtqCMSPDA== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 17 Dec 2011 17:00:06.0615 (UTC) FILETIME=[53C58670:01CCBCDD] Subject: [abfab] Issue 23 - Clarifications and typos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 17:00:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBCDD.539E1365 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim,=20 In issue #23 http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 you write: " 1. The rules determinaion in pagraph #2 might want to refer to levels of assurence which is one of th4e ways in figuring out some of these issues. Note that this may need to change how the realm of the NAI is going to be determined if you are looking ath the routing issues in paragraph #1 =20 2. Paragraph #3 is ambigious in at least one respect. I am not clear if the question is one of the RP relying on the IdP in roder to get a decision, or if the text is saying if the IdP is going to agree to talk to the RP. This should be clarified. I believe that both sides of this question need to be covered - but in separate locations.=20 " The current version of the document uses the term "Rules determination" as a way to indicate that the RP has to make a decision of where to route the AAA mechanism. This term is confusing.=20 I agree with you that the writeup is a bit short with regard to what are the decision criteria. In fact, there is a separate document (which is not yet a working group item) that discusses these aspects in much more detail, see=20 http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02 I suggest to reference that document.=20 I agree that the LoA may have an impact on the routing, particularly when it comes to the broader question of assessing the operational security of some of the providers.=20 Here is paragraph #3: Rules determination covers a broad range of decisions about the exchange. One of these is whether the given RP is permitted to talk to the IDP using a given federation at all, so rules determination encompasses the basic authorization decision. Other factors are included, such as what policies govern release of information about the principal to the RP and what policies govern the RP's use of this information. While rules determination is ultimately a business function, it has significant impact on the technical exchanges. The protocols need to communicate the result of authorization. When multiple sets of rules are possible, the protocol must disambiguate which set of rules are in play. Some rules have technical enforcement mechanisms; for example in some federations intermediates validate information that is being communicated within the federation. I agree with you that the writeup is confusing. I believe it needs to take some of the work we did afterwards, such as with the document I mentioned above, into consideration.=20 Ciao Hannes ------_=_NextPart_001_01CCBCDD.539E1365 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 23 - Clarifications and typos

Hi Jim,

In issue = #23 http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 you write:

“

1.      The rules determinaion in pagraph #2 might want to refer to levels of = assurence which is one of th4e ways in figuring out some of these = issues. Note that this may need to change = how the realm of the NAI is going to be determined if you are looking = ath the routing issues in paragraph = #1

2.      = Paragraph = #3 is ambigious in at least one = respect. I am not clear if the question is one of the RP relying on the = IdP in roder to get a decision, or if the = text is saying if the IdP is going to agree to talk to the RP. This = should be clarified. I believe that both sides of this question need to = be covered - but in separate locations.

“

The current version = of the document uses the term “Rules = determination” as a way to = indicate that the RP has to make = a decision of where to route the AAA mechanism. This term is confusing. =

I agree with you that the writeup = is a bit short with regard to what are the decision criteria. In fact, = there is a separate document (which is not yet a working group item) that discusses these aspects = in much more detail, see

http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-= 02

I suggest to = reference that document. =

I agree that the LoA may have an impact on the routing, = particularly when it comes to the broader question of assessing the = operational security of some of the providers.

Here is paragraph #3:

   Rules determination covers a = broad range of decisions about the

   exchange.  One of these is whether the given RP = is permitted to talk

   to the IDP using a given federation at all, so rules = determination

   encompasses the basic authorization decision.  = Other factors are

   included, such as what policies govern release of = information about

   the principal to the RP and what policies govern the = RP's use of this

   information.  While rules determination is = ultimately a business

   function, it has significant impact on the technical = exchanges.  The

   protocols need to communicate the result of = authorization.  When

   multiple sets of rules are possible, the protocol must = disambiguate

   which set of rules are in play.  Some rules have = technical

   enforcement mechanisms; for example in some = federations intermediates

   validate information that is being communicated within = the

   federation.

I agree with you that the writeup is confusing. I = believe it needs to take some of the work we did afterwards, such as = with the document I mentioned above, into = consideration.

Ciao
Hannes

------_=_NextPart_001_01CCBCDD.539E1365-- From ietf@augustcellars.com Sat Dec 17 13:01:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432B821F86EC for ; Sat, 17 Dec 2011 13:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07jIy0sBLS89 for ; Sat, 17 Dec 2011 13:01:28 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id F123E21F86D0 for ; Sat, 17 Dec 2011 13:01:27 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 00C1C38EFD; Sat, 17 Dec 2011 13:01:26 -0800 (PST) From: "Jim Schaad" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> Date: Sat, 17 Dec 2011 13:00:56 -0800 Message-ID: <036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_036A_01CCBCBB.EB33F9A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFKYrZAlXF7nCRrq/Coh00IkY6zAJblOBUQ Content-Language: en-us Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 21:01:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_036A_01CCBCBB.EB33F9A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Given that to date we have very explicitly designed things to work w/ RADIUS and have not taken on the work for Diameter, but that we all say that it should work just fine w/ Diameter. I think that making a statement the first time we use RADIUS that it does not preclude the use of Diameter and then always using RADIUS is fine. From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Saturday, December 17, 2011 7:21 AM To: abfab@ietf.org Subject: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms Hi Jim, thank you for your detailed review. In issue 12 http://trac.tools.ietf.org/wg/abfab/trac/ticket/12 you wrote: " We have defined a IdP as containing a radius server. Issue #1 is should radius always be capitalized? Issue #2 At this point - should we say that we use the term RADIUS as being either RADIUS or DIAMETER? " Yes, RADIUS should be capitalized. Diameter is not capitalized. Regarding item #2 we have two options: a) We could instead of using the term RADIUS use AAA to refer to both RADIUS and Diameter. b) We could, as you indicate, state that we use the term RADIUS without any loss of generality. I think the question ultimately boils down to what our audience better understands. I don't really know but I prefer (a) since that's what I have done in other docs. Ciao Hannes ------=_NextPart_000_036A_01CCBCBB.EB33F9A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 12 - AAA vs RADIUS vs DIAMETER terms =

Given that to date we have very explicitly designed things to work w/ = RADIUS and  have not taken on the work for Diameter, but that we = all say that it should work just fine w/ Diameter.   I think = that making a statement the first time we use RADIUS that it does not = preclude the use of Diameter and then always using RADIUS is = fine.

 

From:= = abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of = Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Saturday, = December 17, 2011 7:21 AM
To: = abfab@ietf.org
Subject: [abfab] Issue 12 - AAA vs RADIUS vs = DIAMETER terms

 

Hi Jim, =

thank you for your detailed = review.

In issue 12 http://trac.tools.ietf.org/w= g/abfab/trac/ticket/12 you = wrote:

“

We have defined a IdP as containing a radius server. =

Issue #1 is = should radius always be capitalized?

Issue #2 At = this point - should we say that we use the term RADIUS as being either = RADIUS or DIAMETER?

“

Yes, RADIUS = should be capitalized. Diameter is not = capitalized.

Regarding item #2 we have = two options:

a)    &n= bsp; We = could instead of using the term = RADIUS use AAA to refer to both RADIUS and = Diameter.

b)    &n= bsp; We could, = as you indicate, state that we use = the term RADIUS = without any loss of generality.

I think the question = ultimately boils down to what our audience better = understands.

I don’t really know = but I prefer (a) since that’s what I have done in other = docs.

Ciao

Hannes

=
------=_NextPart_000_036A_01CCBCBB.EB33F9A0-- From ietf@augustcellars.com Sat Dec 17 13:06:32 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E0721F8A91 for ; Sat, 17 Dec 2011 13:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giS+1ZczTilx for ; Sat, 17 Dec 2011 13:06:30 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id E2BB521F8A80 for ; Sat, 17 Dec 2011 13:06:30 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2CBE138EFD; Sat, 17 Dec 2011 13:06:30 -0800 (PST) From: "Jim Schaad" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <999913AB42CC9341B05A99BBF358718DE3802D@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE3802D@FIESEXC035.nsn-intra.net> Date: Sat, 17 Dec 2011 13:06:00 -0800 Message-ID: <036e01ccbcff$ae0187c0$0a049740$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_036F_01CCBCBC.9FE39EF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLGaww24Y80HCWCOzbRkrnBxx/s55PtKLDw Content-Language: en-us Subject: Re: [abfab] Issue 7 - Entity Naming Problems Galore X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2011 21:06:32 -0000 This is a multipart message in MIME format. ------=_NextPart_000_036F_01CCBCBC.9FE39EF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think I would need to see a clearer example, but I don't believe that what you are suggesting is very far from what I suggested so it should work. What I suggested for item 3 could easily be done the first time it is used in a section and then use the "normal" term from that point on. The clearer definition would amount to the table that I suggested. I don't believe that we have any locations currently where a single technology is used more than once and between more than two entities. From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Saturday, December 17, 2011 8:32 AM To: abfab@ietf.org Subject: [abfab] Issue 7 - Entity Naming Problems Galore Hi Jim, in issue #7 you raise the following issue: http://trac.tools.ietf.org/wg/abfab/trac/ticket/7 " There are massive problems throughout the document in that we are not using a consistant set of names for each of the entities in the document. Part of this issue is that there are different names for each of these entities in each of the different protocols that we are using. However it also makes the entire document difficult to follow as one needs to keep track of this all of the time. THe following things need to be done: 1. A table that maps from the name used in the document to the name used in each of the different protocols 2. The use of a consistant name for each entity 3. Where feasible, you can do something like RP (Service Provider) so that both names are in the text. " I agree with the challenge regarding the identity terminology in general and the problem of how the existing terminology used in various protocols aligns with the other protocols and the overall framework. Your suggestion will be difficult to implement, I believe, if you think about the figures and the message flows. A direct mapping isn't easy either. In fact what we do most of the time in the document is use abstract concepts (like RP, IdP) and then instantiate them for our use case. In our architecture the IdP is using the AAA protocols (and as part of it EAP). I am curious whether we could get away with better defining the abstract terms and in the other parts of the document where it matters focus on the technology only. For example, when we talk about the relying party we would that for it hosts the AAA client. Does this make any sense to you? Ciao Hannes ------=_NextPart_000_036F_01CCBCBC.9FE39EF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 7 - Entity Naming Problems = Galore

I think I would need to see a clearer example, but I don’t = believe that what you are suggesting is very far from what I  = suggested so it should work.  What I suggested for item 3 could = easily be done the first time it is used in a section and then use the = “normal” term from that point on.  The clearer = definition would amount to the table that I suggested.  I = don’t believe that we have any locations currently where a single = technology is used more than once and between more than two = entities.

 

From:= = abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of = Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Saturday, = December 17, 2011 8:32 AM
To: = abfab@ietf.org
Subject: [abfab] Issue 7 - Entity Naming = Problems Galore

 

Hi Jim, =

in issue #7 you raise the = following issue:

http://trac.tools.ietf.org/w= g/abfab/trac/ticket/7

“

There are massive problems throughout the document in that we are = not using a consistant set of names for each of the entities in the = document. Part of this issue is that there are different names for each = of these entities in each of the different protocols that we are using. = However it also makes the entire document difficult to follow as one = needs to keep track of this all of the time.

THe = following things need to be = done:

1.      A table that = maps from the name used in the document to the name used in each of the = different protocols

2.      = The use of a consistant name for each entity =

3.      Where feasible, you = can do something like RP (Service Provider) so that both names are in = the text.

“

I agree with the = challenge regarding the identity terminology in general and the problem = of how the existing terminology used in various protocols aligns with = the other protocols and the overall framework. Your suggestion will be = difficult to implement, I believe, if you think about the figures and = the message flows. A direct mapping isn’t easy either. =

In fact what we do most of the time in the document is = use abstract concepts (like RP, IdP) and then instantiate them for our = use case. In our architecture the IdP is using the AAA protocols (and as = part of it EAP). 

I am curious whether we could = get away with better defining the abstract terms and in the other parts = of the document where it matters focus on the technology only. For = example, when we talk about the relying party we would that for it hosts = the AAA client.

Does this make any sense to = you?

Ciao
Hannes

------=_NextPart_000_036F_01CCBCBC.9FE39EF0-- From ietf@augustcellars.com Sat Dec 17 19:59:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9B411E807F for ; Sat, 17 Dec 2011 19:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDGzVde9k33u for ; Sat, 17 Dec 2011 19:59:53 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 98BD921F84A7 for ; Sat, 17 Dec 2011 19:59:43 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0C7BE2CA28 for ; Sat, 17 Dec 2011 19:59:41 -0800 (PST) From: "Jim Schaad" To: References: <999913AB42CC9341B05A99BBF358718DE38030@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE38030@FIESEXC035.nsn-intra.net> Date: Sat, 17 Dec 2011 19:59:11 -0800 Message-ID: <037d01ccbd39$66d56b70$34804250$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_037E_01CCBCF6.58B5FC00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5BOrOfY/xfbwOPQWqAnx/mTrz/pUIYfGA Content-Language: en-us Subject: Re: [abfab] Issue 23 - Clarifications and typos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 03:59:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_037E_01CCBCF6.58B5FC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have to admit this is interesting is that the trust router would provide the ability for an RP to do this. I had managed to insert a different entity into the picture and wonder if I am wrong or of the document is just written odd. I have an RP code that is written on top of GSS-API. At this point I need to be able to do a couple of different things. 1. Is the RP that is my service provider going to talk directly to the AAA proxy that is hosted with the IdP, or is it going to go through some local AAA proxy at my side of the conversation. 2. Since as an RP I am doing all of my talking to the AAA side of the world via GSS-API, I assume that we need to have some set of items for controlling how the routing is going to be done in the GSS-API interface. We currently have a way of getting answers from IdP such as the SAML returned (either in its entirety or in parts.) And I assume we are going to have some way of setting the SAML request. However, is the GSS-API or the RP code itself going to deal with the routing issues? Jim From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Saturday, December 17, 2011 9:02 AM To: abfab@ietf.org Subject: [abfab] Issue 23 - Clarifications and typos Hi Jim, In issue #23 http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 you write: " 1. The rules determinaion in pagraph #2 might want to refer to levels of assurence which is one of th4e ways in figuring out some of these issues. Note that this may need to change how the realm of the NAI is going to be determined if you are looking ath the routing issues in paragraph #1 2. Paragraph #3 is ambigious in at least one respect. I am not clear if the question is one of the RP relying on the IdP in roder to get a decision, or if the text is saying if the IdP is going to agree to talk to the RP. This should be clarified. I believe that both sides of this question need to be covered - but in separate locations. " The current version of the document uses the term "Rules determination" as a way to indicate that the RP has to make a decision of where to route the AAA mechanism. This term is confusing. I agree with you that the writeup is a bit short with regard to what are the decision criteria. In fact, there is a separate document (which is not yet a working group item) that discusses these aspects in much more detail, see http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02 I suggest to reference that document. I agree that the LoA may have an impact on the routing, particularly when it comes to the broader question of assessing the operational security of some of the providers. Here is paragraph #3: Rules determination covers a broad range of decisions about the exchange. One of these is whether the given RP is permitted to talk to the IDP using a given federation at all, so rules determination encompasses the basic authorization decision. Other factors are included, such as what policies govern release of information about the principal to the RP and what policies govern the RP's use of this information. While rules determination is ultimately a business function, it has significant impact on the technical exchanges. The protocols need to communicate the result of authorization. When multiple sets of rules are possible, the protocol must disambiguate which set of rules are in play. Some rules have technical enforcement mechanisms; for example in some federations intermediates validate information that is being communicated within the federation. I agree with you that the writeup is confusing. I believe it needs to take some of the work we did afterwards, such as with the document I mentioned above, into consideration. Ciao Hannes ------=_NextPart_000_037E_01CCBCF6.58B5FC00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 23 - Clarifications and = typos

I have to admit this is interesting is that the trust router would = provide the ability for an RP to do this.  I had managed to insert = a different entity into the picture and wonder if I am wrong or of the = document is just written odd.

 

I have an RP code that is written on top of GSS-API.  At this = point I need to be able to do a couple of different = things.

 

1.       =  Is the RP that is my service provider going to talk directly to = the AAA proxy that is hosted with the IdP, or is it going to go through = some local AAA proxy at my side of the = conversation.

2.       = Since as an RP I am doing all of my talking to the AAA side of the = world via GSS-API, I assume that we need to have some set of items for = controlling how the routing is going to be done in the GSS-API = interface.  We currently have a way of getting answers from IdP = such as the SAML returned (either in its entirety or in parts.)  = And I assume we are going to have some way of setting the SAML = request.  However, is the GSS-API or the RP code itself going to = deal with the routing issues?

 

Jim

 

 

From:= = abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of = Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Saturday, = December 17, 2011 9:02 AM
To: = abfab@ietf.org
Subject: [abfab] Issue 23 - Clarifications and = typos

 

Hi Jim, =

In issue #23 http://trac.tools.ietf.org/w= g/abfab/trac/ticket/23 you = write:

“

1.    &n= bsp; The rules = determinaion in pagraph #2 might want to refer to = levels of assurence which is one of th4e ways in figuring out some of = these issues. Note that this may need to change how the realm of the NAI = is going to be determined if you are looking ath the routing issues in = paragraph #1 =

2.    &n= bsp; Paragraph #3 is ambigious in at least = one respect. I am not clear if the question is one of the RP relying on = the IdP in roder to get a decision, or if the text is saying if the IdP = is going to agree to talk to the RP. This should be clarified. I believe = that both sides of this question need to be covered - but in separate = locations.

“

The = current version of the document uses the term “Rules = determination” as a way to indicate that the RP has to make = a decision of where to route the AAA mechanism. This term is = confusing.

I agree with you that the = writeup is a bit short with regard to what are the decision criteria. In = fact, there is a separate document (which is not yet a working group item) = that discusses these aspects in much more detail, see =

http://tools.ietf.org/html/d= raft-mrw-abfab-multihop-fed-02

I suggest to reference that = document.

I agree that the LoA may = have an impact on the routing, particularly when it comes to the broader = question of assessing the operational security of some of the = providers. =

Here is paragraph = #3:

   Rules = determination covers a broad range of decisions about = the

   = exchange.  One of these is whether the given RP is permitted to = talk

   to the = IDP using a given federation at all, so rules = determination

   = encompasses the basic authorization decision.  Other factors = are

   = included, such as what policies govern release of information = about

   the = principal to the RP and what policies govern the RP's use of = this

   = information.  While rules determination is ultimately a = business

   = function, it has significant impact on the technical exchanges.  = The

   = protocols need to communicate the result of authorization.  = When

   = multiple sets of rules are possible, the protocol must = disambiguate

   which = set of rules are in play.  Some rules have = technical

   = enforcement mechanisms; for example in some federations = intermediates

   = validate information that is being communicated within = the

   = federation.

I agree with you that the = writeup is confusing. I believe it needs to take some of the work we did = afterwards, such as with the document I mentioned above, into = consideration.

Ciao
Hannes

------=_NextPart_000_037E_01CCBCF6.58B5FC00-- From hannes.tschofenig@nsn.com Sun Dec 18 01:47:18 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3109C21F8434 for ; Sun, 18 Dec 2011 01:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.998 X-Spam-Level: X-Spam-Status: No, score=-103.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3wT1r40aAdG for ; Sun, 18 Dec 2011 01:47:14 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 069C321F8433 for ; Sun, 18 Dec 2011 01:47:13 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBI9lCuK017753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 18 Dec 2011 10:47:12 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBI9lCiK011281 for ; Sun, 18 Dec 2011 10:47:12 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Dec 2011 10:47:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBD6A.04176FA5" Date: Sun, 18 Dec 2011 11:48:57 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE38069@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue 29 - More explicity discussions of the communication channels with the end-points, cryptography and channel binding Thread-Index: Acy9akMwRaA+dY+0Qem2h79wp7qWCw== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 18 Dec 2011 09:47:12.0338 (UTC) FILETIME=[044F2320:01CCBD6A] Subject: [abfab] Issue 29 - More explicity discussions of the communication channels with the end-points, cryptography and channel binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 09:47:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBD6A.04176FA5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim in issue #29 http://trac.tools.ietf.org/wg/abfab/trac/ticket/29 you wrote: "=20 On May 1 I wrote a message with the following text: I think that I am getting some of the terms straight. What I think I have problems with is the requirements and points at which things occur. The following is a list of the "channels" that I believe exist in the current abfab architecture (Please forgive the names that I am using as they are made up on the spot): 1. Client to RP transport channel - This would be the TLS channel that exists between the client and the RP. The channel binding material is provided by any certificates and the final message (i.e. a cryptographic token for the channel). This will normally be either a one-way authentication of identity (i.e. the client knows who the RP is) or a zero-way authentication of identity (i.e. anonymous on both sides). It could be a mutual authentication, but in that case there would be no reason to involve the entire abfab architecture except potentially for assignment of privileges.=20 2. Client to RP GSS-API channel - This is slightly weird to think of as a channel as it is going to be a channel between the requestor and the acceptor, but the keying material is provided by a "third party" to both entities. (My understanding is that the client can derive this material on its own, but the RP gets the material from the IdP.) There is no cryptographic binding on this channel until the EAP processing has totally finished and the MSK is transferred from the IdP to the RP - i.e. after the client/IdP authentication has completed.=20 3. RP to IdP channel - This is the weakest of the communication channels in terms of authentication and security. Most of these hops are going to be point-to-point and anybody in the middle can play with the data that is being transferred in either direction. The base architecture is responsible for providing any authentication assurances between the RP and the IdP. All authentication is fully established prior to the EAP conversation between the client and the IdP.=20 4. Client to IdP - This is the EAP channel. It has the strongest mutual authentication between that exists. We have stated that the IdP is responsible during this processing to determine that the RP that is communication to the client over channel #3 (Rp to IdP) and the one talking between the client the RP (channel #1 ?) are going to be the same entity as the client provides the IdP it's version of the RP name during the EAP conversation. Thus it needs to reconcile the name forms between channel #1 and channel #3 during this authentication process.=20 At this point channel #2 and channel #4 are known to have cryptographic protections. Channel #1 and channel #3 may or may not have cryptographic protections. We need to specify what level of services are provided in these channels and how important those services are. It was followed up by a couple of notes by sam, myself and nico. I believe that the outcome was that we should get a clear discription of the different communication channels, the set of cryptographic operations/keys offered by each, and the channel binding opertions (type of binding and what it accomplishes) for each channel would be useful. " A few thoughts come to my mind: 1. The security requirements laid out in http://tools.ietf.org/html/rfc4962 are relevant to this discussion and we should probably be referenced.=20 2. I would be talking about three "channels" rather than four. Channel 1+2 are essentially one component that relates to each other.=20 3. Regarding the cryptographic protection of the individual channels and the overall system your mail exchange regarding Levels of Assurance is of relevance here. Also the debate about trust framework matters, see my notes on this topic in an ENISA publication (page 45ff of http://www.enisa.europa.eu/act/it/library/deliverables/pat-study). >From a write-up point of view there are two aspects to differentiate, namely (a) what are the IETF standardized tools available to those who deploy and (b) what do people really deploy. The ABFAB work is not a Greenfield design and so there is a deployed base to learn from.=20 Regarding the requirements for the different channels let me go through those one by one: 1.) Client-to-RP: Here we obviously have a lot of variation depending on the specific application but we may again be able to point out some basic requirements. I believe there will be some disagreement between the assumptions we are working on. First, there is the question whether we want to assume that TLS will always be the underlying security mechanisms. It would be nice to make that assumption but this rules out scenarios like SSH or NFS. The next question is whether we assume RP-side authentication towards the client takes place. We could also rely purely on an anonymous DH exchange and then use the MSK provided by AAA to do the binding to the EAP exchange. (This will bring along the EAP Channel Binding aspects, see http://tools.ietf.org/html/draft-ietf-emu-chbind-11). Finally, there is the question of how many options we want to offer. 2.) RP-to-IdP: This is the AAA protocol environment where we indeed do not have e2e security, i.e. AAA client to AAA server security protection (neither confidentiality nor integrity). For me the question is whether we should be doing something about this (since it had been attempted in the past already and there was little to no interest) or stick with the work we had been envisioning so far, such as the ability to convey SAML assertions and messages, which may experience a different degree of protection. This does, of course, not lead to any protection of the AAA messages itself. Maybe this is something we should be re-visiting again; potentially in combination with the TrustRouter protocol. 3.) Client-to-IdP: Here we can ask ourselves how well the requirements published in http://www.ietf.org/rfc/rfc4017.txt fit for our purpose. Without having re-read RFC 4017 I believe that our requirements are the same. =20 Ciao Hannes ------_=_NextPart_001_01CCBD6A.04176FA5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 29 - More explicity discussions of the communication = channels with the end-points, cryptography and channel binding

Hi Jim

in issue = #29 http://trac.tools.ietf.org/wg/abfab/trac/ticket/29 you wrote:

“

On May 1 I wrote a message with the following = text:

I think that I am getting some of the = terms straight. What I think I have problems with is the requirements = and points at which things occur.

The following is a list of the = "channels" that I believe exist in the current abfab = architecture (Please forgive the names that I am using as they are made = up on the spot):

1.      Client to RP transport channel - This would be the TLS = channel that exists between the client and the RP. The channel binding = material is provided by any certificates and the final message (i.e. a = cryptographic token for the channel). This = will normally be either a one-way authentication of identity (i.e. the = client knows who the RP is) or a zero-way authentication of identity = (i.e. anonymous on both sides). It could be a mutual authentication, but = in that case there would be no reason to involve the = entire abfab architecture except potentially for assignment of = privileges.

2.      = Client to RP GSS-API channel - This is slightly = weird to think of as a channel as it is going to be a channel between = the requestor and the acceptor, but the keying material is provided by a "third party" = to both entities. (My understanding is that the client can derive this = material on its own, but the RP gets the material from the IdP.) There = is no cryptographic binding on this channel until the EAP = processing = has totally finished and the MSK is transferred from the IdP to the RP - = i.e. after the client/IdP authentication has completed. =

3.      = RP to IdP channel - This is the weakest of the = communication channels in terms of authentication and security. Most of = these hops are going to be point-to-point = and anybody in the middle can play with the data that is being = transferred in either direction. The base architecture is responsible = for providing any authentication assurances between the RP and the IdP. = All authentication is fully established prior to the EAP conversation = between the client and the IdP.

4.      = Client to IdP - This is the EAP channel. It has = the strongest mutual authentication between that exists. We have stated = that the IdP is responsible during this processing to determine that the RP that is communication to = the client over channel #3 (Rp to IdP) and the one talking = between the client the RP (channel #1?) are going to be the same entity = as the client provides the IdP it's version of the RP name during the = EAP conversation. Thus it needs to = reconcile the name forms between channel = #1 and channel #3 during this authentication = process.

At this point channel #2 and channel #4 are known to have cryptographic = protections. Channel #1 and channel #3 may or may not have = cryptographic protections. We need to specify what level of services are = provided in these channels and how important those services = are.

It was followed up by a couple of = notes by sam, myself and nico. I believe that the outcome was that we = should get a clear discription of the different communication channels, = the set of cryptographic operations/keys offered by each, and the = channel binding opertions (type of binding and what it accomplishes) for = each channel would be useful.

“

A few = thoughts come to my mind:

1.      The = security requirements laid out in http://tools.ietf.org/html/rfc4962 = are relevant to this discussion and we should probably be referenced. =

2.      I would be talking about three “channels” rather than four. Channel 1+2 are essentially one = component that relates to each other.

3.      Regarding the cryptographic protection of the individual channels and the overall system = your mail exchange regarding Levels of Assurance is of relevance here. = Also the debate about trust framework matters, see my notes on this = topic in an ENISA publication (page 45ff of http://www.enisa.europa.eu/act/it/library/deliverables/= pat-study). From a write-up point of view there are = two aspects to = differentiate, namely (a) what are the IETF standardized tools available = to those who deploy and (b) what do people really deploy. The ABFAB work is not = a = Greenfield = design and so there is a deployed base to learn from.

Regarding the = requirements for the different channels let me go through those one by = one:

1.)     = Client-to-RP: Here = we obviously have a lot of variation depending on the = specific = application but we may again be able to point out some basic = requirements. I believe there will be some disagreement between the = assumptions we are working on. First, there is the question whether we want to assume = that TLS will = always be the underlying security mechanisms. It would be nice to make = that assumption but = this rules out = scenarios like SSH = or NFS. The next = question is whether we assume RP-side authentication towards the client = takes place. We = could also rely purely on an anonymous DH exchange and then use the MSK = provided by AAA to do the binding to the EAP exchange. (This will bring along the EAP = Channel Binding aspects, see http://tools.ietf.org/html/draft-ietf-emu-chbind-11). Finally, there is the question = of how many options we want to offer.

2.)     RP-to-IdP: This is the AAA protocol environment where we indeed do not = have e2e security, i.e. AAA client to AAA server security protection = (neither confidentiality nor integrity). For me the question is whether = we should be doing something about this (since it had been attempted in = the past already and there was little to no interest) or stick with the work we had been = envisioning so far, such as the ability to convey SAML assertions and = messages, which may experience a different degree of protection. This = does, of course, not lead to any protection of the AAA messages = itself. Maybe this is something we should be re-visiting = again; = potentially in = combination with the TrustRouter protocol.

3.)     = Client-to-IdP: Here we can ask ourselves how well the requirements = published in http://www.ietf.org/rfc/rfc4017.txt fit for our purpose. Without having re-read RFC 4017 I believe that our = requirements are the same. 

Ciao
Hannes

------_=_NextPart_001_01CCBD6A.04176FA5-- From hannes.tschofenig@nsn.com Sun Dec 18 01:53:58 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8122521F8445 for ; Sun, 18 Dec 2011 01:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.948 X-Spam-Level: X-Spam-Status: No, score=-105.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDFx8zkHyQDH for ; Sun, 18 Dec 2011 01:53:57 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6D86221F8442 for ; Sun, 18 Dec 2011 01:53:56 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBI9rUnA020946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Dec 2011 10:53:30 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBI9rTCv020911; Sun, 18 Dec 2011 10:53:30 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Dec 2011 10:53:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCBD6A.E50A2653" Date: Sun, 18 Dec 2011 11:55:24 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3806B@FIESEXC035.nsn-intra.net> In-Reply-To: <036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms Thread-Index: AQFKYrZAlXF7nCRrq/Coh00IkY6zAJblOBUQgADYoOA= References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> <036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Jim Schaad" , X-OriginalArrivalTime: 18 Dec 2011 09:53:29.0824 (UTC) FILETIME=[E54EEE00:01CCBD6A] Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 09:53:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCBD6A.E50A2653 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim,=20 =20 I thought that the chairs will re-issue a call for the Diameter part and then make a decision.=20 Am I wrong?=20 =20 Ciao Hannes =20 =20 From: ext Jim Schaad [mailto:ietf@augustcellars.com]=20 Sent: Saturday, December 17, 2011 11:01 PM To: Tschofenig, Hannes (NSN - FI/Espoo); abfab@ietf.org Subject: RE: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms =20 Given that to date we have very explicitly designed things to work w/ RADIUS and have not taken on the work for Diameter, but that we all say that it should work just fine w/ Diameter. I think that making a statement the first time we use RADIUS that it does not preclude the use of Diameter and then always using RADIUS is fine. =20 From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo) Sent: Saturday, December 17, 2011 7:21 AM To: abfab@ietf.org Subject: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms =20 Hi Jim,=20 thank you for your detailed review. In issue 12 http://trac.tools.ietf.org/wg/abfab/trac/ticket/12 you wrote: " We have defined a IdP as containing a radius server.=20 Issue #1 is should radius always be capitalized? Issue #2 At this point - should we say that we use the term RADIUS as being either RADIUS or DIAMETER? " Yes, RADIUS should be capitalized. Diameter is not capitalized.=20 Regarding item #2 we have two options: a) We could instead of using the term RADIUS use AAA to refer to both RADIUS and Diameter. b) We could, as you indicate, state that we use the term RADIUS without any loss of generality.=20 I think the question ultimately boils down to what our audience better understands. I don't really know but I prefer (a) since that's what I have done in other docs. Ciao Hannes ------_=_NextPart_001_01CCBD6A.E50A2653 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Issue 12 - AAA vs RADIUS vs DIAMETER terms =

Hi Jim,

 

I thought that the chairs will re-issue a call for the Diameter part = and then make a decision.

Am I wrong?

 

Ciao
Hannes

 

 

From:= ext Jim = Schaad [mailto:ietf@augustcellars.com]
Sent: Saturday, = December 17, 2011 11:01 PM
To: Tschofenig, Hannes (NSN - = FI/Espoo); abfab@ietf.org
Subject: RE: [abfab] Issue 12 - AAA = vs RADIUS vs DIAMETER terms

 

Given that to date we have very explicitly designed things to work w/ = RADIUS and  have not taken on the work for Diameter, but that we = all say that it should work just fine w/ Diameter.   I think = that making a statement the first time we use RADIUS that it does not = preclude the use of Diameter and then always using RADIUS is = fine.

 

From:= = abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of = Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Saturday, = December 17, 2011 7:21 AM
To: = abfab@ietf.org
Subject: [abfab] Issue 12 - AAA vs RADIUS vs = DIAMETER terms

 

Hi Jim,

thank you for your detailed = review.

In = issue 12 http://trac.tools.ietf.org/w= g/abfab/trac/ticket/12 you wrote:

“

We have defined = a IdP as containing a radius server.

Issue #1 is = should radius always be capitalized?

Issue #2 At = this point - should we say that we use the term RADIUS as being either = RADIUS or DIAMETER?

“

Yes, RADIUS should be = capitalized. Diameter is not = capitalized.

Regarding item = #2 we have two options:

a)    &n= bsp; We could instead of using the term = RADIUS use AAA to refer to both RADIUS and Diameter.

b)    &n= bsp; We could, as you = indicate, state that we = use the term RADIUS without any = loss of generality.

I think the question = ultimately boils down to what our audience better = understands.

I don’t = really know but I prefer (a) since that’s what I have done in other = docs.

Ciao

Hannes

------_=_NextPart_001_01CCBD6A.E50A2653-- From hannes.tschofenig@nsn.com Sun Dec 18 02:02:40 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5BD21F84D7 for ; Sun, 18 Dec 2011 02:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.865 X-Spam-Level: X-Spam-Status: No, score=-104.865 tagged_above=-999 required=5 tests=[AWL=-0.866, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgLXFiw8W6bJ for ; Sun, 18 Dec 2011 02:02:39 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1337B21F8466 for ; Sun, 18 Dec 2011 02:02:38 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBIA2EUi030151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Dec 2011 11:02:14 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBIA2Eps002588; Sun, 18 Dec 2011 11:02:14 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Dec 2011 11:02:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {D1931AD4-7725-45A0-9530-35211385A748} x-cr-hashedpuzzle: ANDc AdpP F4kx IneF JFcm JIY7 Jddj KdOg O3eM PSTZ QZlo QZsw RJnr RR7h TrSj UguJ; 2; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnADsAaQBlAHQAZgBAAGEAdQBnAHUAcwB0AGMAZQBsAGwAYQByAHMALgBjAG8AbQA=; Sosha1_v1; 7; {D1931AD4-7725-45A0-9530-35211385A748}; aABhAG4AbgBlAHMALgB0AHMAYwBoAG8AZgBlAG4AaQBnAEAAbgBzAG4ALgBjAG8AbQA=; Sun, 18 Dec 2011 10:02:07 GMT; UgBFADoAIABbAGEAYgBmAGEAYgBdACAAVAByAHkAaQBuAGcAIAB0AG8AIABnAGUAdAAgAFAAbABhAHMAbQBhACAAdABlAHgAdAAgAGMAbwByAHIAZQBjAHQALgA= Content-class: urn:content-classes:message Date: Sun, 18 Dec 2011 12:02:07 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3806D@FIESEXC035.nsn-intra.net> In-Reply-To: <02f901ccbbc8$dd761b20$98625160$@augustcellars.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Trying to get Plasma text correct. Thread-Index: Acy7u0/mzGLKG977RIeUYZdY9ojHaQBr/PQQ References: <02f901ccbbc8$dd761b20$98625160$@augustcellars.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Jim Schaad" , X-OriginalArrivalTime: 18 Dec 2011 10:02:14.0213 (UTC) FILETIME=[1DDE5750:01CCBD6C] Subject: Re: [abfab] Trying to get Plasma text correct. X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 10:02:40 -0000 Hi Jim,=20 When you say "Plasma" you are referring to "The PoLicy Augmented S/Mime (plasma)" https://www.ietf.org/mailman/listinfo/plasma Correct? To judge whether it is useful to write about that work I have to admit that I am not fully up-to-speed with the latest status of that effort.=20 Can you shed some light on that?=20 Ciao Hannes > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of ext Jim Schaad > Sent: Friday, December 16, 2011 10:01 AM > To: abfab@ietf.org > Subject: [abfab] Trying to get Plasma text correct. >=20 > I am starting to try and develop text for the Plasma documents on how > to use > GSS-API. At least initially, I want to write it to be generic GSS-API > and > then do specifics for the ABFAB GSS-API/EAP case. >=20 > To make my life simpler, we are going to require that the client/RP > transport method always be TLS. Which means that I will at some point > in > the future need to worry about cases where path validation is not > completely > successful. But I am planning to punt that issue for now. >=20 > So since we always know the name of the entity we are going to be > talking > to. My assumption is that we are always going to pass an acceptor name > into > GSS-API. The acceptor name would be "plasma/serverName@domainName". > We > would say strip the left most dotted name as the server name and leave > the > rest as the domain name. Thus an example name might be > "plasma\mailPDP@windows.example.com". >=20 > Now we start looking at some fun things. >=20 > 1. If the url was > https://mailPDP.windows.example.com/internalPolicyChecker, should the > extra > verbage be reflected in the service name string? >=20 > 2. Do we need to say anything special about walking up domain names > when > doing checking or during AAA processing? Specifically, should a domain > string be truncated when doing the channel binding processing called > out in > the EMU channel bindings document wrt to the database lookup code? >=20 > 3. In the current code, one would expect that the client would send > the > full name to the RP as part of the first GSS-API handshake message. I > still > feel somewhat uncomfortable with telling the RP what its full name is > going > to be, but I don't see any way around this with the current GSS-API > calling > code. That is since I want the channel binding to occur w/ a specific > server and domain, there is no way not to let the RP know what they are > going to be in advance. I understand that the AAA system will validate > that > the RP has the right to the name so there should not be any issues, but > is > there any way to make me feel more comfortable with this? >=20 > 4. Since I am using TLS, I will need to specify that TLS channel > binding > will occur (and find the appropriate references about how this works > for > extraction). I am still trying to debate if I need to include > additional > channel binding data from my protocol dialog as well. Has anybody > written > any guidance on when this is recommended and what types of data need to > be > included? I think I have re-designed my protocol so this is no longer > necessary, but I would like some assurance that I am correct. >=20 > 5. If I get to this point, have I already selected the credential that > I > will be using with the EAP server, or I have just gotten to the point > of > saying that I will be using one of a set of credentials? This is an > LOA > question. I will have already selected the realm that I am going to be > authenticated against since I know that goes out in the first GSS- > API/EAP > message. I also understand that by selecting a realm, I may have > restricted > the set of possible LOAs that I can be dealing with. Should my > protocol > allow for some type of re-start of negotiation if a different LOA is > needed? > I assume that would need to be a total re-start of the GSS-API/EAP > negotiation at a minimum although I could leave up the TLS session. >=20 > 6. Should I be setting up some type of negotiation in my protocol to > allow > for a different GSS-API mechanism to be selected? I.e. if one is > within a > single company one could use the Kerberos GSS-API rather than going > with the > EAP version. Would be think this is of importance or can I just > restrict to > using the one GSS-API mechanism and be done with it? Can this type of > negotiation be done within GSS-API? I don't remember seeing anything > of > this sort but that does not mean it does not exist. My understanding > was > that it amounted to configuration information on the client side. >=20 > Jim >=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Sun Dec 18 12:32:51 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130BE21F84A2 for ; Sun, 18 Dec 2011 12:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICsWl2KywbSp for ; Sun, 18 Dec 2011 12:32:50 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5E39821F8496 for ; Sun, 18 Dec 2011 12:32:50 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D677C2CA13; Sun, 18 Dec 2011 12:32:46 -0800 (PST) From: "Jim Schaad" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , References: <02f901ccbbc8$dd761b20$98625160$@augustcellars.com> <999913AB42CC9341B05A99BBF358718DE3806D@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE3806D@FIESEXC035.nsn-intra.net> Date: Sun, 18 Dec 2011 12:32:15 -0800 Message-ID: <03a601ccbdc4$22bbbb70$68333250$@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: AQGDjMdByTcXt88ZCE1XzSgrGhPfhgHkUz28lmVLk+A= Content-Language: en-us Subject: Re: [abfab] Trying to get Plasma text correct. X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 20:32:51 -0000 The set of Plasma people is close to finishing the use case/architecture document and already we have a fairly stable document for how CMS is used. I am currently trying to get finished with a huge set of edits to the client/server protocol document which includes the use of GSS-API as one of the options. However, many of the questions below fall into the category of how do you do things with GSS-API/EAP and thus are not restricted to the Plasma work. Jim > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Sunday, December 18, 2011 2:02 AM > To: ext Jim Schaad; abfab@ietf.org > Subject: RE: [abfab] Trying to get Plasma text correct. > > Hi Jim, > > When you say "Plasma" you are referring to "The PoLicy Augmented S/Mime > (plasma)" > https://www.ietf.org/mailman/listinfo/plasma > > Correct? > > To judge whether it is useful to write about that work I have to admit that I > am not fully up-to-speed with the latest status of that effort. > > Can you shed some light on that? > > Ciao > Hannes > > > -----Original Message----- > > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > > Of ext Jim Schaad > > Sent: Friday, December 16, 2011 10:01 AM > > To: abfab@ietf.org > > Subject: [abfab] Trying to get Plasma text correct. > > > > I am starting to try and develop text for the Plasma documents on how > > to use GSS-API. At least initially, I want to write it to be generic > > GSS-API and then do specifics for the ABFAB GSS-API/EAP case. > > > > To make my life simpler, we are going to require that the client/RP > > transport method always be TLS. Which means that I will at some point > > in the future need to worry about cases where path validation is not > > completely successful. But I am planning to punt that issue for now. > > > > So since we always know the name of the entity we are going to be > > talking to. My assumption is that we are always going to pass an > > acceptor > name > > into > > GSS-API. The acceptor name would be > "plasma/serverName@domainName". > > We > > would say strip the left most dotted name as the server name and leave > > the > > rest as the domain name. Thus an example name might be > > "plasma\mailPDP@windows.example.com". > > > > Now we start looking at some fun things. > > > > 1. If the url was > > https://mailPDP.windows.example.com/internalPolicyChecker, should the > > extra verbage be reflected in the service name string? > > > > 2. Do we need to say anything special about walking up domain names > > when doing checking or during AAA processing? Specifically, should a > domain > > string be truncated when doing the channel binding processing called > > out in the EMU channel bindings document wrt to the database lookup > > code? > > > > 3. In the current code, one would expect that the client would send > > the full name to the RP as part of the first GSS-API handshake > > message. I still feel somewhat uncomfortable with telling the RP what > > its full name is going to be, but I don't see any way around this with > > the current GSS-API calling code. That is since I want the channel > > binding to occur w/ a specific server and domain, there is no way not > > to let the RP know what they > are > > going to be in advance. I understand that the AAA system will > validate > > that > > the RP has the right to the name so there should not be any issues, > but > > is > > there any way to make me feel more comfortable with this? > > > > 4. Since I am using TLS, I will need to specify that TLS channel > > binding will occur (and find the appropriate references about how this > > works for extraction). I am still trying to debate if I need to > > include additional channel binding data from my protocol dialog as > > well. Has anybody written any guidance on when this is recommended > > and what types of data need > to > > be > > included? I think I have re-designed my protocol so this is no longer > > necessary, but I would like some assurance that I am correct. > > > > 5. If I get to this point, have I already selected the credential > that > > I > > will be using with the EAP server, or I have just gotten to the point > > of saying that I will be using one of a set of credentials? This is > > an LOA question. I will have already selected the realm that I am > > going to > be > > authenticated against since I know that goes out in the first GSS- > > API/EAP message. I also understand that by selecting a realm, I may > > have restricted the set of possible LOAs that I can be dealing with. > > Should my protocol allow for some type of re-start of negotiation if a > > different LOA is needed? > > I assume that would need to be a total re-start of the GSS-API/EAP > > negotiation at a minimum although I could leave up the TLS session. > > > > 6. Should I be setting up some type of negotiation in my protocol to > > allow for a different GSS-API mechanism to be selected? I.e. if one > > is within a single company one could use the Kerberos GSS-API rather > > than going with the EAP version. Would be think this is of importance > > or can I just restrict to using the one GSS-API mechanism and be done > > with it? Can this type of negotiation be done within GSS-API? I > > don't remember seeing anything of this sort but that does not mean it > > does not exist. My understanding was that it amounted to > > configuration information on the client side. > > > > Jim > > > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab From nico@cryptonector.com Sun Dec 18 14:07:29 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABD821F84AC for ; Sun, 18 Dec 2011 14:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PnQ++5q9qKs for ; Sun, 18 Dec 2011 14:07:28 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0921F8462 for ; Sun, 18 Dec 2011 14:07:28 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 23311B4065 for ; Sun, 18 Dec 2011 14:07:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=SX9GLWHn2BKVqZeU3RHe1Nix3MXNx8VRKU4EPBQyin2t yZ+D3aiRedBYIZ7AA6SYP94hKyx3Lm72suj+znkHd2cRnXcCPDPgScWvLYfBYRlB eSvGb7hnNLbaVvoGUY91Jr37QHqGJBXMtiIYP8r444uKVRgk0Df8BUWXemXYG8Y= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=yxiuuJH9CgDFeMhMFwu30c0CH8w=; b=rXwejlGZLz3 pCvlGIjpXZBG/5c9J+szPMprBXswxYkfgg3X41o1HiYTpySIhgJt95pK1uANiQx7 gpTldsDZ1zk/TsruEhAEYLdeaxBiUO7gYHYbzuH18f7ZocXEmdcfLPkCv67VMdUa szH7j/911/aZlcexncCUGsX8gc06ZK/U= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 13372B403E for ; Sun, 18 Dec 2011 14:07:28 -0800 (PST) Received: by pbdd12 with SMTP id d12so3750881pbd.31 for ; Sun, 18 Dec 2011 14:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr34282775pbv.90.1324245668147; Sun, 18 Dec 2011 14:01:08 -0800 (PST) Received: by 10.68.32.227 with HTTP; Sun, 18 Dec 2011 14:01:08 -0800 (PST) In-Reply-To: <037d01ccbd39$66d56b70$34804250$@augustcellars.com> References: <999913AB42CC9341B05A99BBF358718DE38030@FIESEXC035.nsn-intra.net> <037d01ccbd39$66d56b70$34804250$@augustcellars.com> Date: Sun, 18 Dec 2011 16:01:08 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Issue 23 - Clarifications and typos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2011 22:07:29 -0000 On Sat, Dec 17, 2011 at 9:59 PM, Jim Schaad wrote: > I have an RP code that is written on top of GSS-API.=C2=A0 At this point = I need > to be able to do a couple of different things. > > 1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Is the RP that is my service= provider going to talk directly to > the AAA proxy that is hosted with the IdP, or is it going to go through s= ome > local AAA proxy at my side of the conversation. A local proxy. > 2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Since as an RP I am doing all of m= y talking to the AAA side of the > world via GSS-API, I assume that we need to have some set of items for > controlling how the routing is going to be done in the GSS-API interface. Well, the RP application is just calling GSS_Accept_sec_context(). The mechanism invoked by GSS_Accept_sec_context() (GSS-EAP) will do all the work of talking AAA under the covers, invisibly to the application. More likely than not the application only really needs to indicate to the GSS-API that for any particular instance of the application it wants to use one or another configuration/profile. In practice there will often be a single configuration/profile anyways, so that nothing is needed here. If the application really does need direct, fine-grained control how trust routing is done we'd likely end up using a GSS extension such as naming extensions (applied to the acceptor NAME object), credential options (applied to the acceptor's CREDENTIAL HANDLE), or security context options. > We currently have a way of getting answers from IdP such as the SAML > returned (either in its entirety or in parts.)=C2=A0 And I assume we are = going to > have some way of setting the SAML request.=C2=A0 However, is the GSS-API = or the > RP code itself going to deal with the routing issues? For the sake of simplicity the GSS mechanism should deal with trust routing. The application should limit itself to inspecting the initiator (client) name returned by the GSS-API, or perhaps the application should ask for specific kinds of attributes that it wants to see, or perhaps it should simply select a profile that tells the mechanism the application's requirements. Nico -- From leifj@mnt.se Mon Dec 19 01:11:14 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5627E21F8B44 for ; Mon, 19 Dec 2011 01:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzQCZQBJu3qC for ; Mon, 19 Dec 2011 01:11:13 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B792F21F8B40 for ; Mon, 19 Dec 2011 01:11:12 -0800 (PST) Received: from [109.105.104.149] (dhcp15.se-tug.nordu.net [109.105.104.149] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBJ9B6Ve010308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2011 10:11:10 +0100 (CET) Message-ID: <4EEEFFAA.2050608@mnt.se> Date: Mon, 19 Dec 2011 10:11:06 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: abfab@ietf.org References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> <036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com> <999913AB42CC9341B05A99BBF358718DE3806B@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE3806B@FIESEXC035.nsn-intra.net> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 09:11:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/18/2011 10:55 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Jim, > > > > I thought that the chairs will re-issue a call for the Diameter > part and then make a decision. > > Am I wrong? Yes :-) and no. We did issue a call to adopt draft-jones-diameter-abfab-00 on 4/8 and got 0 (zero) replies. I don't think we can take silence as acceptance in this case ;-) If we get reactions to this issue we'll re-issue the call. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7u/6kACgkQ8Jx8FtbMZneabACguHfFRnbGSRsXL7Of/SBznjrN jEEAn05SNIxkon9uGCRmwwXnRmlT2i6s =JEoS -----END PGP SIGNATURE----- From hannes.tschofenig@nsn.com Mon Dec 19 01:29:23 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A4721F8B25 for ; Mon, 19 Dec 2011 01:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.111 X-Spam-Level: X-Spam-Status: No, score=-106.111 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxSlG4E0ywj9 for ; Mon, 19 Dec 2011 01:29:23 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A915021F8A7E for ; Mon, 19 Dec 2011 01:29:22 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBJ9TKx5025593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Dec 2011 10:29:21 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBJ9TKHM029063; Mon, 19 Dec 2011 10:29:20 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Dec 2011 10:29:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2011 11:31:13 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3825E@FIESEXC035.nsn-intra.net> In-Reply-To: <4EEEFFAA.2050608@mnt.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms Thread-Index: Acy+LjMSH7e+d2RQT1+W9UXaoVZOvQAAqVpw References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net><036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com><999913AB42CC9341B05A99BBF358718DE3806B@FIESEXC035.nsn-intra.net> <4EEEFFAA.2050608@mnt.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Leif Johansson" , X-OriginalArrivalTime: 19 Dec 2011 09:29:20.0820 (UTC) FILETIME=[B00C3740:01CCBE30] Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 09:29:23 -0000 Hi Leif,=20 I am afraid that I missed the call as well and quite likely the DIME group wasn't aware of it either.=20 Ciao Hannes > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of ext Leif Johansson > Sent: Monday, December 19, 2011 11:11 AM > To: abfab@ietf.org > Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 12/18/2011 10:55 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Hi Jim, > > > > > > > > I thought that the chairs will re-issue a call for the Diameter > > part and then make a decision. > > > > Am I wrong? >=20 > Yes :-) and no. >=20 > We did issue a call to adopt draft-jones-diameter-abfab-00 on 4/8 and > got 0 (zero) replies. >=20 > I don't think we can take silence as acceptance in this case ;-) >=20 > If we get reactions to this issue we'll re-issue the call. >=20 > Cheers Leif > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk7u/6kACgkQ8Jx8FtbMZneabACguHfFRnbGSRsXL7Of/SBznjrN > jEEAn05SNIxkon9uGCRmwwXnRmlT2i6s > =3DJEoS > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From leifj@mnt.se Mon Dec 19 06:48:20 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BF621F8B4C for ; Mon, 19 Dec 2011 06:48:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+dmLd3oK1Z6 for ; Mon, 19 Dec 2011 06:48:19 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 84BC621F8B4A for ; Mon, 19 Dec 2011 06:48:19 -0800 (PST) Received: from [109.105.104.149] (dhcp15.se-tug.nordu.net [109.105.104.149] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBJEmDBd022979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2011 15:48:16 +0100 (CET) Message-ID: <4EEF4EAD.4040203@mnt.se> Date: Mon, 19 Dec 2011 15:48:13 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net><036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com><999913AB42CC9341B05A99BBF358718DE3806B@FIESEXC035.nsn-intra.net> <4EEEFFAA.2050608@mnt.se> <999913AB42CC9341B05A99BBF358718DE3825E@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE3825E@FIESEXC035.nsn-intra.net> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 14:48:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/19/2011 10:31 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Hi Leif, > > I am afraid that I missed the call as well and quite likely the > DIME group wasn't aware of it either. > > Ciao Hannes Well we sort-of assumed you were all for it ;-) I'm more worried that nobody else in the WG chimed in. I'm not sure why we should involve DIME in this work though. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7vTq0ACgkQ8Jx8FtbMZnfhnwCdFd0XfvH8VIRXzcIHGwZfrfu2 0eYAnjQqcZyUWHumHpR4IjVyT1nF5Ccy =L5i1 -----END PGP SIGNATURE----- From hannes.tschofenig@nsn.com Mon Dec 19 07:00:42 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E43721F8B50 for ; Mon, 19 Dec 2011 07:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 968rv+oplDoM for ; Mon, 19 Dec 2011 07:00:41 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7721221F8AC9 for ; Mon, 19 Dec 2011 07:00:40 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBJF0dkL032107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Dec 2011 16:00:39 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBJF0YTL020970; Mon, 19 Dec 2011 16:00:38 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Dec 2011 16:00:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2011 17:02:22 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE3851D@FIESEXC035.nsn-intra.net> In-Reply-To: <4EEF4EAD.4040203@mnt.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms Thread-Index: Acy+XUtoi5jtcQBaT3ilNhvNwmfb/wAAXszg References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net><036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com><999913AB42CC9341B05A99BBF358718DE3806B@FIESEXC035.nsn-intra.net> <4EEEFFAA.2050608@mnt.se> <999913AB42CC9341B05A99BBF358718DE3825E@FIESEXC035.nsn-intra.net> <4EEF4EAD.4040203@mnt.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Leif Johansson" X-OriginalArrivalTime: 19 Dec 2011 15:00:35.0624 (UTC) FILETIME=[F65AA280:01CCBE5E] Cc: abfab@ietf.org Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:00:42 -0000 > I'm more worried that nobody else in the WG chimed in. I'm not sure > why we should involve DIME in this work though. Well. That is where the guys are who work on Diameter.=20 In general, it is worthwhile to reach out to other communities with regard to the generic ABFAB idea.=20 Currently, we seem to be focusing on the education / research community only. Diameter is not widely used in those areas but rather in the telecommunication space, i.e. fixed and mobile operators.=20 Ciao Hannes From leifj@sunet.se Mon Dec 19 07:03:47 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE8D21F8B52 for ; Mon, 19 Dec 2011 07:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhhJMUAbPKUa for ; Mon, 19 Dec 2011 07:03:46 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7C21F8B33 for ; Mon, 19 Dec 2011 07:03:46 -0800 (PST) Received: from [109.105.104.149] (dhcp15.se-tug.nordu.net [109.105.104.149] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBJF3gmg023670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2011 16:03:45 +0100 (CET) Message-ID: <4EEF524E.8030906@sunet.se> Date: Mon, 19 Dec 2011 16:03:42 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: abfab@ietf.org References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net><036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com><999913AB42CC9341B05A99BBF358718DE3806B@FIESEXC035.nsn-intra.net> <4EEEFFAA.2050608@mnt.se> <999913AB42CC9341B05A99BBF358718DE3825E@FIESEXC035.nsn-intra.net> <4EEF4EAD.4040203@mnt.se> <999913AB42CC9341B05A99BBF358718DE3851D@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE3851D@FIESEXC035.nsn-intra.net> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:03:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/19/2011 04:02 PM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> I'm more worried that nobody else in the WG chimed in. I'm not >> sure why we should involve DIME in this work though. > > Well. That is where the guys are who work on Diameter. > > In general, it is worthwhile to reach out to other communities > with regard to the generic ABFAB idea. > > Currently, we seem to be focusing on the education / research > community only. Diameter is not widely used in those areas but > rather in the telecommunication space, i.e. fixed and mobile > operators. I'm still worried that nobody answered. Should we do another call? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7vUk4ACgkQ8Jx8FtbMZneOLQCglNdk7vUSXTjLa3mpzHoY8FAx Ok8An16UCd0SR3iG2YTYffJioS9wKZc1 =zOwO -----END PGP SIGNATURE----- From hartmans@painless-security.com Mon Dec 19 07:05:10 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2528B11E8094 for ; Mon, 19 Dec 2011 07:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLLHCW5w9tFA for ; Mon, 19 Dec 2011 07:05:09 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8EC11E808C for ; Mon, 19 Dec 2011 07:05:09 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5F5D6201CB; Mon, 19 Dec 2011 10:05:05 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B7E4448B; Mon, 19 Dec 2011 10:04:59 -0500 (EST) From: Sam Hartman To: "Tschofenig\, Hannes \(NSN - FI\/Espoo\)" References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> Date: Mon, 19 Dec 2011 10:04:59 -0500 In-Reply-To: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> (Hannes Tschofenig's message of "Sat, 17 Dec 2011 17:20:37 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:05:10 -0000 I also prefer AAA to RADIUS. I think a couple of places for clarity we should say RADIUS or Diameter to indicate common AAOA protocols. If a specific example involves one technology it's fine to use that. From hartmans@painless-security.com Mon Dec 19 07:08:52 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2C41F0C3F for ; Mon, 19 Dec 2011 07:08:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruCAv0+7W0aB for ; Mon, 19 Dec 2011 07:08:52 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E76E821F8B8F for ; Mon, 19 Dec 2011 07:08:51 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F09A5201CB; Mon, 19 Dec 2011 10:08:49 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8D3C5448B; Mon, 19 Dec 2011 10:08:43 -0500 (EST) From: Sam Hartman To: "Tschofenig\, Hannes \(NSN - FI\/Espoo\)" References: <999913AB42CC9341B05A99BBF358718DE3802B@FIESEXC035.nsn-intra.net> Date: Mon, 19 Dec 2011 10:08:43 -0500 In-Reply-To: <999913AB42CC9341B05A99BBF358718DE3802B@FIESEXC035.nsn-intra.net> (Hannes Tschofenig's message of "Sat, 17 Dec 2011 18:02:36 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Issue #6 - bad flow of text for authentication requriements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:08:53 -0000 >>>>> ""Tschofenig," == "Tschofenig, Hannes (NSN <- FI/Espoo)" > writes: "Tschofenig,> The sentence you are referring to, namely "Aside from "Tschofenig,> a valuable secret being exposed, a synchronization "Tschofenig,> problem can also often develop." should be deleted. I "Tschofenig,> understand that there may be a synchronization problem "Tschofenig,> when you cache your distribute your long term secret "Tschofenig,> everywhere but that's only secondary (and less "Tschofenig,> important). I disagree that this synchronization issue is secondary in terms of deployment concerns. I actually think that the synchronization issue drives up support costs and creates a real business case for ABFAB far more than the security issues. So, I'd rather continue to document this issue. --Sam From diego@tid.es Mon Dec 19 08:18:47 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C1D21F86A5 for ; Mon, 19 Dec 2011 08:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-OTf-yB4LAh for ; Mon, 19 Dec 2011 08:18:47 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id CE5BC21F86DD for ; Mon, 19 Dec 2011 08:18:46 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWG00A5FLB9GM@tid.hi.inet> for abfab@ietf.org; Mon, 19 Dec 2011 17:18:45 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 72.55.04893.3EE6FEE4; Mon, 19 Dec 2011 18:05:40 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LWG00A5ALB9GM@tid.hi.inet> for abfab@ietf.org; Mon, 19 Dec 2011 17:18:45 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad2.hi.inet ([192.168.0.2]) with mapi; Mon, 19 Dec 2011 17:18:45 +0100 Date: Mon, 19 Dec 2011 17:18:47 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: Sam Hartman Message-id: <1461F28B-DF1D-42EC-9488-E8AF7BA38419@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms Thread-index: Acy+aeF8cPmRlSq2QNSJzjGDgjLeAg== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f4c6d00000131d-09-4eef6ee3f6fc X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsXCFe/Apfsk772fwYxDjBYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtvOioIdXBUf515ha2CcwtXFyMkhIWAiMentXUYIW0ziwr31 bCC2kMAGRol361i7GLmA7B+MEvu65rJDOI1AzqH7YB0sAqoSH88fZAKx2QTUJVqOfmMBsYUF 7CU2/9oHZnMKqElM2bIHbKqIgIHEvFfHwGxmgSyJn8s6gXo5OHgFLCWmfcgECfMKCEr8mHyP BSTMDDRyypRciGpxiebWmywQtqLEtEUNYBcwAt38/dQaJojpDhJr929nhbD1JHbu384OUSMq cad9PdSPAhJL9pxnhrBFJV4+/scK8W+mxPOdv5knMIrPQnLFLIQrZiG5YhaSKxYwsqxiFCtO KspMzyjJTczMSTcw1MvI1MvMSy3ZxAiJn4wdjMt3qhxiFOBgVOLhNZj62k+INbGsuDL3EKMk B5OSKO/i+Pd+QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4f7x46yfEm5JYWZValA+TkuHgUJLg 1U4GahMsSk1PrUjLzAEmCZg0EwcnSDsPUDtYDW9xQWJucWY6RP4Uo6SUOK8FSEIAJJFRmgfX +4pRHOhIYV4NkCwPMJ3Bdb0CGsgENLAv8A3IwJJEhJRUA6N/5ZeJV9R9Hp7ede7xvRdNHfvS P0yd+9DyyXOWmi2WFf3e2Wkfjj7sivXftK/v5+0jEjfj355zt1jA8ONu+S7FsmuMf24zH+E4 ++F8AltSav/XyuKHFryt3rX9Tmrurz97K395u2MppwCD08Szr1fs4Vgln1tYe6TpFLNvlqow 791LnR/Cqx2VWIozEg21mIuKEwHpMpFTJAMAAA== References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> Cc: "abfab@ietf.org" Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:18:47 -0000 DQpPbiAxOSBEZWMgMjAxMSwgYXQgMTY6MDQgLCBTYW0gSGFydG1hbiB3cm90ZToNCg0KPiBJIGFs c28gcHJlZmVyIEFBQSB0byBSQURJVVMuDQo+IEkgdGhpbmsgYSBjb3VwbGUgb2YgcGxhY2VzIGZv ciBjbGFyaXR5IHdlIHNob3VsZCBzYXkgUkFESVVTIG9yIERpYW1ldGVyDQo+IHRvIGluZGljYXRl IGNvbW1vbiBBQU9BIHByb3RvY29scy4NCj4gSWYgYSBzcGVjaWZpYyBleGFtcGxlIGludm9sdmVz IG9uZSB0ZWNobm9sb2d5IGl0J3MgZmluZSB0byB1c2UgdGhhdC4NCg0KQ29taW5nIGZyb20gdGhl IGFjYWRlbWljIGNvbW11bml0eSBhbmQgYmVpbmcgcGFydCBvZiB0aGUgdGVsY28gc2VjdG9yIHJp Z2h0IG5vdywgSSBjYW5ub3QgYnV0IGZ1bGx5IGFncmVlIHdpdGggU2FtIGFuZCBIYW5uZXMgb24g dGhpcy4NCg0KQmUgZ29vZGUsDQoNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0 b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KDQplLW1h aWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQg NjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJp by4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nD s24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpv Lg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2Vl LiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJt cyBzZXQgb3V0IGF0Lg0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFz cHgNCg== From hannes.tschofenig@nsn.com Mon Dec 19 08:57:02 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39BB11E8089 for ; Mon, 19 Dec 2011 08:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.209 X-Spam-Level: X-Spam-Status: No, score=-106.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqu4Hh4SQ2Ib for ; Mon, 19 Dec 2011 08:57:01 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4512B11E809A for ; Mon, 19 Dec 2011 08:57:01 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBJGv0IF008378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Dec 2011 17:57:00 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBJGv0r6011480; Mon, 19 Dec 2011 17:57:00 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Dec 2011 17:56:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Dec 2011 18:58:50 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE38570@FIESEXC035.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] Issue #6 - bad flow of text for authentication requriements Thread-Index: Acy+YCD4gXlu/9QTSSqQlB/3yQW7QAADHq+g References: <999913AB42CC9341B05A99BBF358718DE3802B@FIESEXC035.nsn-intra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Sam Hartman" X-OriginalArrivalTime: 19 Dec 2011 16:56:59.0918 (UTC) FILETIME=[395152E0:01CCBE6F] Cc: abfab@ietf.org Subject: Re: [abfab] Issue #6 - bad flow of text for authentication requriements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 16:57:02 -0000 Hi Sam, if you want to document it then we may need to provide a bit more text. I could imagine that we find that text in some of the OAuth documents.=20 Ciao Hannes > -----Original Message----- > From: ext Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Monday, December 19, 2011 5:09 PM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: abfab@ietf.org > Subject: Re: [abfab] Issue #6 - bad flow of text for authentication > requriements >=20 > >>>>> ""Tschofenig," =3D=3D "Tschofenig, Hannes (NSN <- FI/Espoo)" > > writes: >=20 > "Tschofenig,> The sentence you are referring to, namely "Aside from > "Tschofenig,> a valuable secret being exposed, a synchronization > "Tschofenig,> problem can also often develop." should be deleted. I > "Tschofenig,> understand that there may be a synchronization > problem > "Tschofenig,> when you cache your distribute your long term secret > "Tschofenig,> everywhere but that's only secondary (and less > "Tschofenig,> important). >=20 > I disagree that this synchronization issue is secondary in terms of > deployment concerns. I actually think that the synchronization issue > drives up support costs and creates a real business case for ABFAB far > more than the security issues. > So, I'd rather continue to document this issue. >=20 > --Sam From hartmans@painless-security.com Mon Dec 19 09:08:17 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9781F0C4B for ; Mon, 19 Dec 2011 09:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XESuVS4N0ajW for ; Mon, 19 Dec 2011 09:08:16 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0271F0C47 for ; Mon, 19 Dec 2011 09:08:16 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 23BE6201CB; Mon, 19 Dec 2011 12:08:14 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 767ED448B; Mon, 19 Dec 2011 12:08:07 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <999913AB42CC9341B05A99BBF358718DE38030@FIESEXC035.nsn-intra.net> <037d01ccbd39$66d56b70$34804250$@augustcellars.com> Date: Mon, 19 Dec 2011 12:08:07 -0500 In-Reply-To: <037d01ccbd39$66d56b70$34804250$@augustcellars.com> (Jim Schaad's message of "Sat, 17 Dec 2011 19:59:11 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Issue 23 - Clarifications and typos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:08:17 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I have to admit this is interesting is that the trust router Jim> would provide the ability for an RP to do this. I had managed Jim> to insert a different entity into the picture and wonder if I Jim> am wrong or of the document is just written odd. Jim> I have an RP code that is written on top of GSS-API. At this Jim> point I need to be able to do a couple of different things. Jim> 1. Is the RP that is my service provider going to talk Jim> directly to the AAA proxy that is hosted with the IdP, or is it Jim> going to go through some local AAA proxy at my side of the Jim> conversation. In our deployment we're assuming that this is a local proxy. Jim> 2. Since as an RP I am doing all of my talking to the AAA side Jim> of the world via GSS-API, I assume that we need to have some Jim> set of items for controlling how the routing is going to be Jim> done in the GSS-API interface. We currently have a way of Jim> getting answers from IdP such as the SAML returned (either in Jim> its entirety or in parts.) And I assume we are going to have Jim> some way of setting the SAML request. However, is the GSS-API Jim> or the RP code itself going to deal with the routing issues? I'm not aware of any proposals for controlling the routing through GSS. I'm not aware of any proposals other than trust router for standardizing controlling the routing. Today that's done through proxy or RP-side config files. From hartmans@painless-security.com Mon Dec 19 09:13:01 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8846E21F8880 for ; Mon, 19 Dec 2011 09:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6VB0JWwNn-k for ; Mon, 19 Dec 2011 09:13:01 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 170DA21F84D5 for ; Mon, 19 Dec 2011 09:13:01 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0CFA0201F1; Mon, 19 Dec 2011 12:12:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9C55A448B; Mon, 19 Dec 2011 12:12:52 -0500 (EST) From: Sam Hartman To: "Tschofenig\, Hannes \(NSN - FI\/Espoo\)" References: <999913AB42CC9341B05A99BBF358718DE3802B@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718DE38570@FIESEXC035.nsn-intra.net> Date: Mon, 19 Dec 2011 12:12:52 -0500 In-Reply-To: <999913AB42CC9341B05A99BBF358718DE38570@FIESEXC035.nsn-intra.net> (Hannes Tschofenig's message of "Mon, 19 Dec 2011 18:58:50 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Issue #6 - bad flow of text for authentication requriements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:13:01 -0000 >>>>> ""Tschofenig," == "Tschofenig, Hannes (NSN <- FI/Espoo)" > writes: "Tschofenig,> Hi Sam, if you want to document it then we may need to "Tschofenig,> provide a bit more text. I could imagine that we find "Tschofenig,> that text in some of the OAuth documents. OK, can you help me understand what's wrong with what is there now? It seems reasonably clear to me, so I'd like to better understand what you and/or Jim find confusing. From hartmans@painless-security.com Mon Dec 19 09:15:11 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC2E11E8097 for ; Mon, 19 Dec 2011 09:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmfRTw7ldqps for ; Mon, 19 Dec 2011 09:15:10 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B886F11E8093 for ; Mon, 19 Dec 2011 09:15:10 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A60E2201CB; Mon, 19 Dec 2011 12:15:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4EEBC448B; Mon, 19 Dec 2011 12:15:02 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <999913AB42CC9341B05A99BBF358718DE3802A@FIESEXC035.nsn-intra.net> <036901ccbcfe$f94c8b40$ebe5a1c0$@augustcellars.com> <999913AB42CC9341B05A99BBF358718DE3806B@FIESEXC035.nsn-intra.net> <4EEEFFAA.2050608@mnt.se> <999913AB42CC9341B05A99BBF358718DE3825E@FIESEXC035.nsn-intra.net> <4EEF4EAD.4040203@mnt.se> <999913AB42CC9341B05A99BBF358718DE3851D@FIESEXC035.nsn-intra.net> <4EEF524E.8030906@sunet.se> Date: Mon, 19 Dec 2011 12:15:02 -0500 In-Reply-To: <4EEF524E.8030906@sunet.se> (Leif Johansson's message of "Mon, 19 Dec 2011 16:03:42 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Issue 12 - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:15:11 -0000 FWIW, I kind of missed the call too. I'd say that if Diameter is going to be used, it would be desirable to use ABFAB with Diameter. I have no current plans to implement ABFAB technology for Diameter. However if people are willing to write the document, I'm happy to review it. If we have enough authors and reviewers, I think the WG should adopt the document I don't think the Diameter document should block other work. --Sam From ietf@augustcellars.com Mon Dec 19 16:36:13 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA5D21F844F for ; Mon, 19 Dec 2011 16:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVmHemp3MgCf for ; Mon, 19 Dec 2011 16:36:13 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 0E47921F844E for ; Mon, 19 Dec 2011 16:36:13 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 9E32538F1F; Mon, 19 Dec 2011 16:36:12 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" References: <999913AB42CC9341B05A99BBF358718DE3802B@FIESEXC035.nsn-intra.net> <999913AB42CC9341B05A99BBF358718DE38570@FIESEXC035.nsn-intra.net> In-Reply-To: Date: Mon, 19 Dec 2011 16:35:40 -0800 Message-ID: <000001ccbeaf$4ebc0180$ec340480$@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: AQHxRHU0xCfcbGkBxo0nOKUaoPfpSwDD2Z03AeWoHFEBIcfZuJV8emGA Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Issue #6 - bad flow of text for authentication requriements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 00:36:13 -0000 If you read my note, it has nothing to do with the issues of synchronization. I completely agree that they are problem and that they should be covered. My issue had to do with how the text was written and flows. In terms of completing the thought, a simple statement that this can lead to the client having the new password and a server having the password and thus they are unable to authenticate" is sufficient for me. My real problem is that the text does not flow and the first sentence appears to want more development but the text skips into a new issue on the next sentence. > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Monday, December 19, 2011 9:13 AM > To: Tschofenig, Hannes (NSN - FI/Espoo) > Cc: abfab@ietf.org > Subject: Re: [abfab] Issue #6 - bad flow of text for authentication > requriements > > >>>>> ""Tschofenig," == "Tschofenig, Hannes (NSN <- FI/Espoo)" > > writes: > > "Tschofenig,> Hi Sam, if you want to document it then we may need to > "Tschofenig,> provide a bit more text. I could imagine that we find > "Tschofenig,> that text in some of the OAuth documents. > > OK, can you help me understand what's wrong with what is there now? > It seems reasonably clear to me, so I'd like to better understand what you > and/or Jim find confusing. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From alexey.melnikov@isode.com Sun Dec 25 06:07:54 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373A021F8511 for ; Sun, 25 Dec 2011 06:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE-kT5Lrn73l for ; Sun, 25 Dec 2011 06:07:53 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7847321F8512 for ; Sun, 25 Dec 2011 06:07:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1324822069; d=isode.com; s=selector; i=@isode.com; bh=8mx5yhAFzpat4jraGWOt9BSCrusw4HFhpd/E1cWIzJc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=wJIcjSWMIvLDI4PUiySwSH6iJxHErjNIaEeKZ9wiisI5Gc5xMwv41+587MmnTnZPSbMRL4 xk88VOTbdGXSGkgDs9cvTE4mNZkL6LEXKRi0bCgxP6UYQaO2VL41ep0ovyP0qfVrjBB52o cCzq14Ztfc67cxstEDhRLZqGfE1Tr1Y=; Received: from [192.168.0.109] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 25 Dec 2011 14:07:49 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4EF71DE1.8020906@isode.com> Date: Sun, 25 Dec 2011 12:58:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Sam Hartman References: <4E75ACD5.5000104@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 14:07:54 -0000 Hi Sam, Commenting on a couple of your replies (I am either Ok or need to double check other things you've mentioned): On 16/12/2011 19:14, Sam Hartman wrote: [...] > Alexey> 5.4.2. Acceptor Name Request > > Alexey> The acceptor name request token is sent from the initiator > Alexey> to the acceptor indicating that the initiator wishes a > Alexey> particular acceptor name. This is similar to TLS Server > Alexey> Name Indication. > > Alexey> This needs an Informative Reference. > > Can you find the right reference? > I spent 10 minutes and failed. I think RFC 6066 is the right reference. > Alexey> In Section 5.5: > > Alexey> o If the acceptor receives an EAP failure, then the > Alexey> acceptor sends this in the Eap Request subtoken type. If > Alexey> the initiator receives an EAP Failure, it returns GSS > Alexey> failure. > > Alexey> Can you expand on what you mean here. "receive" doesn't mean > Alexey> receive over the wire here, right? > > I think it does. It might be worth clarifying to help the first time readers ("sending EAP failure in the EAP Request subtoken type" sounds a bit weird to me.) > Alexey> Also, what does it mean > Alexey> to return a "GSS failure"? > > That's a return status from a GSS call.