From internet-drafts@ietf.org Sun Jun 2 21:25:24 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9691C21F9273; Sun, 2 Jun 2013 21:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.175 X-Spam-Level: X-Spam-Status: No, score=-102.175 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur91FEu-tyUM; Sun, 2 Jun 2013 21:25:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3E621F9232; Sun, 2 Jun 2013 21:25:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130603042523.22108.93822.idtracker@ietfa.amsl.com> Date: Sun, 02 Jun 2013 21:25:23 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-eapapplicability-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 04:25:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Update to the EAP Applicability Statement for ABFAB Author(s) : Stefan Winter Joseph Salowey Filename : draft-ietf-abfab-eapapplicability-03.txt Pages : 7 Date : 2013-06-02 Abstract: This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-eapapplicability-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-eapapplicability-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Jun 3 06:18:23 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DF421F98AC; Mon, 3 Jun 2013 06:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.145 X-Spam-Level: X-Spam-Status: No, score=-102.145 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtHYNWTYqpWC; Mon, 3 Jun 2013 06:18:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C256621F9808; Mon, 3 Jun 2013 06:18:21 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Sender: Message-ID: <20130603131818.13138.22141.idtracker@ietfa.amsl.com> Date: Mon, 03 Jun 2013 06:18:21 -0700 Cc: abfab@ietf.org Subject: [abfab] Last Call: (Update to the EAP Applicability Statement for ABFAB) to Proposed Standard X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:18:23 -0000 The IESG has received a request from the Application Bridging for Federated Access Beyond web WG (abfab) to consider the following document: - 'Update to the EAP Applicability Statement for ABFAB' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-06-17. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document updates the Extensible Authentication Protocol (EAP) applicability statement from RFC3748 to reflect recent usage of the EAP protocol in the Application Bridging for Federated Access Beyond web (ABFAB) architecture. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability/ballot/ No IPR declarations have been submitted directly on this I-D. From Josh.Howlett@ja.net Tue Jun 11 06:52:34 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1353421F99FA for ; Tue, 11 Jun 2013 06:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68CotQjHeD0q for ; Tue, 11 Jun 2013 06:52:27 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 77F5E21F99FB for ; Tue, 11 Jun 2013 06:52:25 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0DF43204184E_1B72B98B for ; Tue, 11 Jun 2013 13:52:24 +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 136102041847_1B72B97F for ; Tue, 11 Jun 2013 13:52:23 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 14:52:22 +0100 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: Naming of SAML and AAA systems Thread-Index: AQHOZqrlNQobE6KmnEeECspOwbUWYw== Date: Tue, 11 Jun 2013 13:52:22 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <8922EDE9D890F940A650079A4C1872CD@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [abfab] Naming of SAML and AAA systems 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, 11 Jun 2013 13:52:34 -0000 I'm currently updating abfab-aaa-saml. The document is a bit unambiguous about the naming of system entities, specifically: 1. There is no attempt to correlate the AAA and SAML entity naming (the transport and message levels respectively). I believe that we need a naming convention such that it is trivial to reliably infer a system entity's AAA or SAML name, given the other name. 2. We don't yet have a mechanism for naming the functional roles of SAML entities within a realm, which I believe is needed to satisfy the attribute request and aggregation use cases. For example, an acceptor wanting additional attributes for an authenticated user from realm Foo from another attribute authority in realm Bar. Here's my proposal: * A SAML system names itself using an entity identifier is a URI that encodes the AAA system's FQDN. For example "abfab:idp.example.com" and "abfab:rp.example.com" would name two hosts with FQDNs of idp.example.com and rp.example.com. For an RP, this entity identifier value (less the abfab prefix) will therefore be equal to the value of the GSS-Acceptor-Host-Name RADIUS attribute. It is worth noting that section 4.3 of RFC3588 specifies a URI scheme for AAA protocols, but it looks a bit elaborate for what we need (and possibly not complete, given the RADIUS transport options today). Irrespective of the convention we choose, RADIUS entities emitting SAML messages MUST use it. * SAML system entities are able to locate SAML entities within other realms using RADIUS by using well-known values for the user fragment of the NAI. For example, a relying party would resolve an attribute authority in realm by using an NAI with value "abfab:aa@example.com". This might return a SAML assertion issued by an entity named "abfab:idp.example.com". Similarly an authorisation PDP might be resolved using "abfab:pdp@example.com". Opinions? Josh. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From d.w.chadwick@kent.ac.uk Fri Jun 14 08:24:34 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463FE21F9BD0 for ; Fri, 14 Jun 2013 08:24:34 -0700 (PDT) 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 L2-RwP7JiHjv for ; Fri, 14 Jun 2013 08:24:29 -0700 (PDT) Received: from mx7.kent.ac.uk (mx7.kent.ac.uk [129.12.21.38]) by ietfa.amsl.com (Postfix) with ESMTP id 5715521F9B8D for ; Fri, 14 Jun 2013 08:24:28 -0700 (PDT) Received: from [87.113.158.158] (helo=[192.168.1.67]) by mx7.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UnVrW-0001ij-Hr; Fri, 14 Jun 2013 16:24:26 +0100 Message-ID: <51BB35AA.4030800@kent.ac.uk> Date: Fri, 14 Jun 2013 16:24:26 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Josh Howlett References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Naming of SAML and AAA systems 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, 14 Jun 2013 15:24:34 -0000 Hi Josh I guess you have two options i) some sort of directory or metadata or config file in which names are listed and there is no requirement for them to be algorithmically related to each other, or ii) having a mandatory naming convention that specifies how related entities are named, and from which you can determine the relationships. Going with ii) suffers from problems if the relationships that are implicitly assumed in the naming convention turn out to be different in practice e.g. you assume 1 to 1 relationships between entities but they turn out to be 1 to n or n to n. Also what happens if new (sub)types of entities arise? You might end up having to change the code base to support them. I think i) is safer, but it has additional costs of requiring support for the directory/discovery mechanism regards David On 11/06/2013 14:52, Josh Howlett wrote: > I'm currently updating abfab-aaa-saml. The document is a bit unambiguous > about the naming of system entities, specifically: > > 1. There is no attempt to correlate the AAA and SAML entity naming (the > transport and message levels respectively). I believe that we need a > naming convention such that it is trivial to reliably infer a system > entity's AAA or SAML name, given the other name. > > 2. We don't yet have a mechanism for naming the functional roles of SAML > entities within a realm, which I believe is needed to satisfy the > attribute request and aggregation use cases. For example, an acceptor > wanting additional attributes for an authenticated user from realm Foo > from another attribute authority in realm Bar. > > Here's my proposal: > > * A SAML system names itself using an entity identifier is a URI that > encodes the AAA system's FQDN. For example "abfab:idp.example.com" and > "abfab:rp.example.com" would name two hosts with FQDNs of idp.example.com > and rp.example.com. For an RP, this entity identifier value (less the > abfab prefix) will therefore be equal to the value of the > GSS-Acceptor-Host-Name RADIUS attribute. It is worth noting that section > 4.3 of RFC3588 specifies a URI scheme for AAA protocols, but it looks a > bit elaborate for what we need (and possibly not complete, given the > RADIUS transport options today). Irrespective of the convention we choose, > RADIUS entities emitting SAML messages MUST use it. > > * SAML system entities are able to locate SAML entities within other > realms using RADIUS by using well-known values for the user fragment of > the NAI. For example, a relying party would resolve an attribute authority > in realm by using an NAI with value "abfab:aa@example.com". This might > return a SAML assertion issued by an entity named "abfab:idp.example.com". > Similarly an authorisation PDP might be resolved using > "abfab:pdp@example.com". > > Opinions? > > Josh. > > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a > not-for-profit company which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From david.black@emc.com Mon Jun 17 19:39:51 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B425F21F9CA1; Mon, 17 Jun 2013 19:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD3-PUlgH65b; Mon, 17 Jun 2013 19:39:47 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id D7E8B21F9C57; Mon, 17 Jun 2013 19:39:46 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5I2djDB011711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Jun 2013 22:39:45 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Mon, 17 Jun 2013 22:39:31 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5I2dUJF026235; Mon, 17 Jun 2013 22:39:31 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub32.corp.emc.com ([128.222.70.172]) with mapi; Mon, 17 Jun 2013 22:39:30 -0400 From: "Black, David" To: "stefan.winter@restena.lu" , "jsalowey@cisco.com" , General Area Review Team Date: Mon, 17 Jun 2013 22:39:28 -0400 Thread-Topic: Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Tue, 18 Jun 2013 01:04:15 -0700 Cc: "abfab@ietf.org" , "ietf@ietf.org" , "Black, David" Subject: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 02:39:51 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-abfab-eapapplicability-03 Reviewer: David L. Black Review Date: June 17, 2003 IETF LC End Date: June 17, 2003 Summary: This draft is on the right track but has open issues, described in the revi= ew. This draft updates the applicability statement for EAP to include usage for application layer access via EAP over GSSAPI. Additional security requirements are introduced for environments in which EAP is used for that purpose. I found one open issue, which is minor, and may be editorial Major issues: None Minor issues: One The next to last paragraph on p.3 begins with this sentence: For these reasons, channel binding MUST be implemented by peers, EAP servers and AAA servers in environments where EAP authentication is used to access application layer services. It appear that this "MUST" requirement applies to all uses of EAP, including network access authentication, not just application layer access authentication. If so, that's not immediately obvious from the text, and an additional sentence should be added to make this clearer. If not, the above sentence needs to exclude network access authentication from that requirement. Nits/editorial comments: The same paragraph (p.3) continues with: In addition, channel binding MUST default to being required by peers for non-network authentication. If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding. What is meant by "non-network authentication" and "other than a network service"? If those mean "other than for network access authentication" as the term "network access authentication" is used in section 1 and RFC 3748, that meaning should be clarified. idnits 2.12.17 generated this comment: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If yo= u have contacted all the original authors and they are all willing to gr= ant the BCP78 rights to the IETF Trust, then this is fine, and you can ign= ore this comment. If not, you may need to add the pre-RFC5378 disclaimer.= =20 (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) idnits appears to be confused ;-). The -00 version of this draft is from 2= 012, and this draft does not contain sufficient material from RFC 3748 that woul= d raise that concern, so this comment should be ok to ignore. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From hartmans@painless-security.com Tue Jun 18 07:19:16 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5177C21F9F12; Tue, 18 Jun 2013 07:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWb5-QCOOfSL; Tue, 18 Jun 2013 07:19:10 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6240121F9EE1; Tue, 18 Jun 2013 07:19:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id BC2032013A; Tue, 18 Jun 2013 10:15:09 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd8b3jpw8fH3; Tue, 18 Jun 2013 10:15:08 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 18 Jun 2013 10:15:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 525ED80046; Tue, 18 Jun 2013 10:18:50 -0400 (EDT) From: Sam Hartman To: "Black\, David" References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> Date: Tue, 18 Jun 2013 10:18:50 -0400 In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> (David Black's message of "Mon, 17 Jun 2013 22:39:28 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: General Area Review Team , "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 14:19:16 -0000 >>>>> "Black," == Black, David writes: Black,> The next to last paragraph on p.3 begins with this sentence: Black,> For these reasons, channel binding MUST be implemented by Black,> peers, EAP servers and AAA servers in environments where EAP Black,> authentication is used to access application layer services. Black,> It appear that this "MUST" requirement applies to all uses Black,> of EAP, including network access authentication, not just Black,> application layer access authentication. If so, that's not Black,> immediately obvious from the text, and an additional Black,> sentence should be added to make this clearer. If not, the Black,> above sentence needs to exclude network access Black,> authentication from that requirement. I know you're correct that AAA servers and EAP servers need to implement channel binding for network access in such environments. I'm not sure whether peers only doing network access SHOULD implement channel binding or MUST implement channel binding. Practically speaking, it will be a while before peers implement channel binding for network access. The sorts of attacks that result without channel binding are attacks where a peer thinks it is doing network access authentication but what it's really doing is helping an attacker access an application. If all the application access peers support channel binding, then you could potentially require the eap-lower-layer attribute or similar for application authentication and work securely in environments where peers for network access have not been updated yet. It's also kind of tempting to stick our head in the sand and just add the clarification that "yes, we mean network access too." --Sam From david.black@emc.com Tue Jun 18 07:43:47 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF5911E80DF; Tue, 18 Jun 2013 07:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOw19EIogZJb; Tue, 18 Jun 2013 07:43:42 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 427E321E8053; Tue, 18 Jun 2013 07:43:38 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IEhaPN032387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jun 2013 10:43:37 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 18 Jun 2013 10:43:06 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IEh5dK006895; Tue, 18 Jun 2013 10:43:05 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Tue, 18 Jun 2013 10:43:05 -0400 From: "Black, David" To: Sam Hartman Date: Tue, 18 Jun 2013 10:43:03 -0400 Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: Ac5sLtL2MQaEvFULRLupG53n6IyQQgAAT1zw Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129826522D@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Tue, 18 Jun 2013 09:00:43 -0700 Cc: General Area Review Team , "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 14:43:47 -0000 Sam, I was concerned that something along these lines was lurking in here :-(. I think this is the crucial "running code" consideration to start from: > Practically speaking, it will be a while before peers implement channel > binding for network access. Assuming that network access does not use channel binding, how does one avoid the proxy attack on network access authentication via application access authentication when the latter is introduced? For environments where EAP is used for network access authentication, the suggestion of a "MUST use" requirement for channel binding with=20 application access authentication sounds like the right approach: > If all the application access peers support channel binding, then you > could potentially require the eap-lower-layer attribute or similar for > application authentication and work securely in environments where peers > for network access have not been updated yet. Is that plausible and reasonable in practice? This would be in addition to the "MUST implement" requirements for AAA servers, EAP serves and peers doing application access: > I know you're correct that AAA servers and EAP servers need to implement > channel binding for network access in such environments. Thanks, --David > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Tuesday, June 18, 2013 10:19 AM > To: Black, David > Cc: stefan.winter@restena.lu; jsalowey@cisco.com; General Area Review Tea= m; > abfab@ietf.org; ietf@ietf.org > Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-= 03 >=20 > >>>>> "Black," =3D=3D Black, David writes: >=20 > Black,> The next to last paragraph on p.3 begins with this sentence: >=20 > Black,> For these reasons, channel binding MUST be implemented by > Black,> peers, EAP servers and AAA servers in environments where EAP > Black,> authentication is used to access application layer services. >=20 > Black,> It appear that this "MUST" requirement applies to all uses > Black,> of EAP, including network access authentication, not just > Black,> application layer access authentication. If so, that's not > Black,> immediately obvious from the text, and an additional > Black,> sentence should be added to make this clearer. If not, the > Black,> above sentence needs to exclude network access > Black,> authentication from that requirement. >=20 >=20 > I know you're correct that AAA servers and EAP servers need to implement > channel binding for network access in such environments. > I'm not sure whether peers only doing network access SHOULD implement > channel binding or MUST implement channel binding. >=20 > Practically speaking, it will be a while before peers implement channel > binding for network access. > The sorts of attacks that result without channel binding are attacks > where a peer thinks it is doing network access authentication but what > it's really doing is helping an attacker access an application. > If all the application access peers support channel binding, then you > could potentially require the eap-lower-layer attribute or similar for > application authentication and work securely in environments where peers > for network access have not been updated yet. > It's also kind of tempting to stick our head in the sand and just add > the clarification that "yes, we mean network access too." >=20 > --Sam From jsalowey@cisco.com Tue Jun 18 10:10:26 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E8611E80F0; Tue, 18 Jun 2013 10:10:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjsZs7F81wtv; Tue, 18 Jun 2013 10:10:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AEC3921F9B7D; Tue, 18 Jun 2013 10:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3564; q=dns/txt; s=iport; t=1371575421; x=1372785021; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+hlGh+C++SrXDUQzquKhgpIyxvVI+lyR41mFbWx3p6c=; b=gfzZQRI498ui8ajAaKuqPEDxRMrYTYCIBzj/rw9Irytkm90faOGjIf5B HjIX8Y5eewwOL3Q0Kb5OhVBKlZOYJgyQxVOgXON/h/OpS4TqYPC7kApuo vzBHWMz5JXYkKJuAWQBwpw9obPjZfu9QTvfMnj1nb/uAWEa+msI9ueyBS c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAAaUwFGtJXG//2dsb2JhbABPCoMJer8PgQIWdIIjAQEBAwE6PwULAgEIIhQQMiUBAQQOBQiIAAa7Eo1/gQkCMQeDAGEDqQSDD4FqJBo X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="224374188" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jun 2013 17:10:20 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5IHAKcY000945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 17:10:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 12:10:19 -0500 From: "Joseph Salowey (jsalowey)" To: Sam Hartman Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgAYb7oMABB0QQA= Date: Tue, 18 Jun 2013 17:10:19 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <4F7AA199DE677B4EBAFAEF02DB1C2F7F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" , "Black, David" , General Area Review Team , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 17:10:26 -0000 On Jun 18, 2013, at 7:18 AM, Sam Hartman wrote: >>>>>> "Black," =3D=3D Black, David writes: >=20 > Black,> The next to last paragraph on p.3 begins with this sentence: >=20 > Black,> For these reasons, channel binding MUST be implemented by > Black,> peers, EAP servers and AAA servers in environments where EAP > Black,> authentication is used to access application layer services. >=20 > Black,> It appear that this "MUST" requirement applies to all uses > Black,> of EAP, including network access authentication, not just > Black,> application layer access authentication. If so, that's not > Black,> immediately obvious from the text, and an additional > Black,> sentence should be added to make this clearer. If not, the > Black,> above sentence needs to exclude network access > Black,> authentication from that requirement. >=20 >=20 > I know you're correct that AAA servers and EAP servers need to implement > channel binding for network access in such environments. > I'm not sure whether peers only doing network access SHOULD implement > channel binding or MUST implement channel binding. >=20 > Practically speaking, it will be a while before peers implement channel > binding for network access. > The sorts of attacks that result without channel binding are attacks > where a peer thinks it is doing network access authentication but what > it's really doing is helping an attacker access an application. > If all the application access peers support channel binding, then you > could potentially require the eap-lower-layer attribute or similar for > application authentication and work securely in environments where peers > for network access have not been updated yet. [Joe] I'm trying to get a handle on the attack mechanism here. In this a= ttack a valid network service is trying to spoof an application service? S= ince it knows the MSK it can do this if the channel-binding of the lower-la= yer into the EAP conversation is not enforced. If the AAA server always en= forces channel bindings for applications then it will catch the spoofing at= tempt. The reverse case may also be an issue where an application service= is trying to spoof a network service. In this case, if the AAA server va= lidates that the application channel binding is not present then it can pre= vent the spoofing. However the server MUST understand channel bindings eve= n if the peers do not. I think the document did try to capture this in th= e following sentence: "If the EAP server is aware that authentication is for something other than a network service, it too MUST default to requiring channel binding." I think we could state this a bit better as something like: "In environments where EAP is used for applications authentication and netw= ork access authentication all EAP servers MUST understand channel bindings = and require that application bindings MUST be present in application authen= tication and that application bindings MUST be absent in network authentica= tion. All network access EAP peer implementations SHOULD support channel = binding to explicitly identify the reason for authentication. Any new usag= e of EAP MUST support channel bindings to prevent confusion with network ac= cess usage. "=20 > It's also kind of tempting to stick our head in the sand and just add > the clarification that "yes, we mean network access too." >=20 > --Sam From david.black@emc.com Tue Jun 18 10:28:44 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C5811E80E3; Tue, 18 Jun 2013 10:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hFsFab+5vvBv; Tue, 18 Jun 2013 10:28:39 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4725111E80E6; Tue, 18 Jun 2013 10:28:38 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IHSaXR016150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jun 2013 13:28:37 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 18 Jun 2013 13:28:19 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IHSIKd002504; Tue, 18 Jun 2013 13:28:18 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 18 Jun 2013 13:28:17 -0400 From: "Black, David" To: "Joseph Salowey (jsalowey)" Date: Tue, 18 Jun 2013 13:28:17 -0400 Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgAYb7oMABB0QQAAClxl4A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: General Area Review Team , "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 17:28:44 -0000 > [Joe] I'm trying to get a handle on the attack mechanism here. In this > attack a valid network service is trying to spoof an application service? > Since it knows the MSK it can do this if the channel-binding of the lower= - > layer into the EAP conversation is not enforced. If the AAA server alway= s > enforces channel bindings for applications then it will catch the spoofin= g > attempt. The reverse case may also be an issue where an application ser= vice > is trying to spoof a network service. While both cases appear to be relevant, my concern started from the reverse case - here's the draft's text describing the attack: One potentially serious attack exists when channel binding is not required and EAP authentication is introduced into an existing non- network service. A device can be created that impersonates a Network Access Service to peers, but actually proxies the authentication to the new application service that accepts EAP authentications. This may decrease the security of this service even for users who previously used non-EAP means of authentication to the service. > In this case, if the AAA server > validates that the application channel binding is not present then it can > prevent the spoofing. However the server MUST understand channel binding= s > even if the peers do not. I think the document did try to capture this = in > the following sentence: >=20 > "If the EAP server is aware that authentication is > for something other than a network service, it too MUST default to > requiring channel binding." >=20 > I think we could state this a bit better as something like: >=20 > "In environments where EAP is used for applications authentication and ne= twork > access authentication all EAP servers MUST understand channel bindings an= d > require that application bindings MUST be present in application > authentication and that application bindings MUST be absent in network > authentication. All network access EAP peer implementations SHOULD supp= ort > channel binding to explicitly identify the reason for authentication. An= y new > usage of EAP MUST support channel bindings to prevent confusion with netw= ork > access usage. " That text is an improvement, and it's headed in the same direction as Sam's comment - "application bindings MUST be present in application authenticati= on" is a "MUST use" requirement, not just a "MUST implement" requirement. OTOH, I'm not clear on what "application bindings" means, as that term's no= t in the current draft. Specifically, I'm a bit unclear on "application bind= ings MUST be absent in network authentication" - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an "application binding", whatever that = is? Thanks, --David > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tuesday, June 18, 2013 1:10 PM > To: Sam Hartman > Cc: Black, David; stefan.winter@restena.lu; General Area Review Team; > abfab@ietf.org; ietf@ietf.org > Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-= 03 >=20 >=20 > On Jun 18, 2013, at 7:18 AM, Sam Hartman > wrote: >=20 > >>>>>> "Black," =3D=3D Black, David writes: > > > > Black,> The next to last paragraph on p.3 begins with this sentence: > > > > Black,> For these reasons, channel binding MUST be implemented by > > Black,> peers, EAP servers and AAA servers in environments where EAP > > Black,> authentication is used to access application layer services. > > > > Black,> It appear that this "MUST" requirement applies to all uses > > Black,> of EAP, including network access authentication, not just > > Black,> application layer access authentication. If so, that's not > > Black,> immediately obvious from the text, and an additional > > Black,> sentence should be added to make this clearer. If not, the > > Black,> above sentence needs to exclude network access > > Black,> authentication from that requirement. > > > > > > I know you're correct that AAA servers and EAP servers need to implemen= t > > channel binding for network access in such environments. > > I'm not sure whether peers only doing network access SHOULD implement > > channel binding or MUST implement channel binding. > > > > Practically speaking, it will be a while before peers implement channel > > binding for network access. > > The sorts of attacks that result without channel binding are attacks > > where a peer thinks it is doing network access authentication but what > > it's really doing is helping an attacker access an application. > > If all the application access peers support channel binding, then you > > could potentially require the eap-lower-layer attribute or similar for > > application authentication and work securely in environments where peer= s > > for network access have not been updated yet. >=20 > [Joe] I'm trying to get a handle on the attack mechanism here. In this > attack a valid network service is trying to spoof an application service? > Since it knows the MSK it can do this if the channel-binding of the lower= - > layer into the EAP conversation is not enforced. If the AAA server alway= s > enforces channel bindings for applications then it will catch the spoofin= g > attempt. The reverse case may also be an issue where an application ser= vice > is trying to spoof a network service. In this case, if the AAA server > validates that the application channel binding is not present then it can > prevent the spoofing. However the server MUST understand channel binding= s > even if the peers do not. I think the document did try to capture this = in > the following sentence: >=20 > "If the EAP server is aware that authentication is > for something other than a network service, it too MUST default to > requiring channel binding." >=20 > I think we could state this a bit better as something like: >=20 > "In environments where EAP is used for applications authentication and ne= twork > access authentication all EAP servers MUST understand channel bindings an= d > require that application bindings MUST be present in application > authentication and that application bindings MUST be absent in network > authentication. All network access EAP peer implementations SHOULD supp= ort > channel binding to explicitly identify the reason for authentication. An= y new > usage of EAP MUST support channel bindings to prevent confusion with netw= ork > access usage. " >=20 >=20 >=20 > > It's also kind of tempting to stick our head in the sand and just add > > the clarification that "yes, we mean network access too." > > > > --Sam >=20 From jsalowey@cisco.com Tue Jun 18 10:47:10 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9523A11E80DF; Tue, 18 Jun 2013 10:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRUCxIPRbfch; Tue, 18 Jun 2013 10:47:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E391C11E80EC; Tue, 18 Jun 2013 10:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2198; q=dns/txt; s=iport; t=1371577625; x=1372787225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Tl0W1XPlBj7Q7T8U4EZPVfIrpXaWB8G9FYDbLyRLqJI=; b=cZvKpaWkdEdheb+GuYb9/qy3lsQVZaaLVXj3eSSn3Hw+I37mNtYzLHxo NXMu5jlhPexVFY2tLTsZIlCdzuUA5yRaZDZb7S1vY1dO11A3Rglkyfptn 2H9TWvQGiFQNm6cd/oc58A2Q+wWE9OT2NQ9Bcn2nE4nXtIDtcun2ixFAS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FALecwFGtJV2d/2dsb2JhbABPCoMJer8PgQIWdIIkAQEEOj8QAgEIIhQQMiUBAQQODYgGuwuNf4EJAjEHgwBhA6kEgw+CKA X-IronPort-AV: E=Sophos;i="4.87,890,1363132800"; d="scan'208";a="224169702" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2013 17:47:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5IHl4iY016128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 17:47:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 12:47:04 -0500 From: "Joseph Salowey (jsalowey)" To: "Black, David" Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgAYb7oMABB0QQAAClxl4P//t2GA Date: Tue, 18 Jun 2013 17:47:03 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <6D250E7F34578C4DB2BC1DE691351E73@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team , "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 17:47:10 -0000 >>=20 >> I think we could state this a bit better as something like: >>=20 >> "In environments where EAP is used for applications authentication and n= etwork >> access authentication all EAP servers MUST understand channel bindings a= nd >> require that application bindings MUST be present in application >> authentication and that application bindings MUST be absent in network >> authentication. All network access EAP peer implementations SHOULD sup= port >> channel binding to explicitly identify the reason for authentication. A= ny new >> usage of EAP MUST support channel bindings to prevent confusion with net= work >> access usage. " >=20 > That text is an improvement, and it's headed in the same direction as Sam= 's > comment - "application bindings MUST be present in application authentica= tion" > is a "MUST use" requirement, not just a "MUST implement" requirement. >=20 > OTOH, I'm not clear on what "application bindings" means, as that term's = not > in the current draft. Specifically, I'm a bit unclear on "application bi= ndings > MUST be absent in network authentication" - does that mean that channel > binding must be absent, or that channel binding is optional, but if chann= el > binding is present, it MUST NOT be an "application binding", whatever tha= t is? >=20 [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access a= uthentication all EAP servers MUST enforce channel bindings. For applicati= on authentication, the EAP server MUST require that the correct EAP lower-l= ayer attribute be present in the channel binding data. For network access= authentication, the EAP server MUST require that if channel bindings are p= resent they MUST contain the correct EAP lower-layer attribute. All netwo= rk access EAP peer implementations SHOULD use channel bindings including th= e EAP lower-layer attribute to explicitly identify the reason for authentic= ation. Any new usage of EAP MUST use channel bindings including the EAP lo= wer-layer attribute to prevent confusion with network access usage. " Does this help? Thanks, Joe From hartmans@painless-security.com Tue Jun 18 11:39:23 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58BD11E80F7; Tue, 18 Jun 2013 11:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvRUC7f+lfIX; Tue, 18 Jun 2013 11:39:18 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A88AE11E80F8; Tue, 18 Jun 2013 11:39:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 36D902013A; Tue, 18 Jun 2013 14:35:24 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAFbtdoguduW; Tue, 18 Jun 2013 14:35:23 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 18 Jun 2013 14:35:23 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2DA9980047; Tue, 18 Jun 2013 14:39:05 -0400 (EDT) From: Sam Hartman To: "Joseph Salowey \(jsalowey\)" References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> Date: Tue, 18 Jun 2013 14:39:05 -0400 In-Reply-To: (Joseph Salowey's message of "Tue, 18 Jun 2013 17:47:03 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" , "Black, David" , General Area Review Team , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 18:39:24 -0000 Joe, eap-lower-layer is not required for application authentication if there's some other attribute that's specific to the lower layer. For example Moonshot sends gss-acceptor-service-name but does not currently send eap-lower-layer, and doing that seems consistent with the requirements of the channel binding spec. Adding a requirement for eap-lower-layer all the time would be new, but might be reasonable. --Sam From david.black@emc.com Tue Jun 18 12:35:26 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DA421E80C1; Tue, 18 Jun 2013 12:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwUFxhG5gcMO; Tue, 18 Jun 2013 12:35:21 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5A18B21E80C0; Tue, 18 Jun 2013 12:35:17 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IJZGCe028823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jun 2013 15:35:16 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 18 Jun 2013 15:34:57 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5IJYhuw023324; Tue, 18 Jun 2013 15:34:55 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Tue, 18 Jun 2013 15:34:45 -0400 From: "Black, David" To: "Joseph Salowey (jsalowey)" Date: Tue, 18 Jun 2013 15:34:44 -0400 Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgAYb7oMABB0QQAAClxl4P//t2GAgAA80uA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298265300@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: General Area Review Team , "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 19:35:26 -0000 > [Joe] Good points, the text can be more specific: >=20 > "In environments where EAP is used for purposes other than network access > authentication all EAP servers MUST enforce channel bindings. For applic= ation > authentication, the EAP server MUST require that the correct EAP lower-la= yer > attribute be present in the channel binding data. For network access > authentication, the EAP server MUST require that if channel bindings are > present they MUST contain the correct EAP lower-layer attribute. All ne= twork > access EAP peer implementations SHOULD use channel bindings including the= EAP > lower-layer attribute to explicitly identify the reason for authenticatio= n. > Any new usage of EAP MUST use channel bindings including the EAP lower-la= yer > attribute to prevent confusion with network access usage. " This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite= , mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): "In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage." Thanks, --David > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Tuesday, June 18, 2013 1:47 PM > To: Black, David > Cc: stefan.winter@restena.lu; General Area Review Team; abfab@ietf.org; > ietf@ietf.org > Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-= 03 >=20 > >> > >> I think we could state this a bit better as something like: > >> > >> "In environments where EAP is used for applications authentication and= network > >> access authentication all EAP servers MUST understand channel bindings= and > >> require that application bindings MUST be present in application > >> authentication and that application bindings MUST be absent in network > >> authentication. All network access EAP peer implementations SHOULD s= upport > >> channel binding to explicitly identify the reason for authentication. = Any new > >> usage of EAP MUST support channel bindings to prevent confusion with n= etwork > >> access usage. " > > > > That text is an improvement, and it's headed in the same direction as S= am's > > comment - "application bindings MUST be present in application authenti= cation" > > is a "MUST use" requirement, not just a "MUST implement" requirement. > > > > OTOH, I'm not clear on what "application bindings" means, as that term'= s not > > in the current draft. Specifically, I'm a bit unclear on "application = bindings > > MUST be absent in network authentication" - does that mean that channel > > binding must be absent, or that channel binding is optional, but if cha= nnel > > binding is present, it MUST NOT be an "application binding", whatever t= hat > is? > > >=20 > [Joe] Good points, the text can be more specific: >=20 > "In environments where EAP is used for purposes other than network access > authentication all EAP servers MUST enforce channel bindings. For applic= ation > authentication, the EAP server MUST require that the correct EAP lower-la= yer > attribute be present in the channel binding data. For network access > authentication, the EAP server MUST require that if channel bindings are > present they MUST contain the correct EAP lower-layer attribute. All ne= twork > access EAP peer implementations SHOULD use channel bindings including the= EAP > lower-layer attribute to explicitly identify the reason for authenticatio= n. > Any new usage of EAP MUST use channel bindings including the EAP lower-la= yer > attribute to prevent confusion with network access usage. " >=20 > Does this help? >=20 > Thanks, >=20 > Joe >=20 From jsalowey@cisco.com Tue Jun 18 13:00:26 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C373021E80B6; Tue, 18 Jun 2013 13:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gr57FFocfblg; Tue, 18 Jun 2013 13:00:20 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DE6D921E80BD; Tue, 18 Jun 2013 13:00:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=868; q=dns/txt; s=iport; t=1371585620; x=1372795220; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eB/jRNm4UWz/7giJ74P44658v9HNsMtyBDBq+TrXiwM=; b=fhA1BWL/N24VkIc2NpKZ1I1UCQWOE7NnH0BjelSKH0U4FPGh91MolZKp ep8B7XujsZ9rA6TgXNeVWZvNafK9Y5nB8TReZ6chOrjolQcXpSbOSQwL2 egt1ykf1chuVSiNydT1cXq17JGr6Z0VALC6Up8cyOtgUQusPHtfMBs3Ht Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4FACS7wFGtJXHA/2dsb2JhbABZgwl6gjq8VYEEFnSCIwEBAQMBOj8FCwIBCCIUEDIlAgQOBQiIAAa6fI8IAjEHgwBhA6kEgw+BaAc5 X-IronPort-AV: E=Sophos;i="4.87,891,1363132800"; d="scan'208";a="224230285" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 18 Jun 2013 20:00:19 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5IK0J4d013814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 20:00:19 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 15:00:18 -0500 From: "Joseph Salowey (jsalowey)" To: Sam Hartman Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: AQHObFMc5Vr98eb9RParuraCHgwUcpk8OBOA Date: Tue, 18 Jun 2013 20:00:17 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <3E45AE4402E8FD46832FA550ED86D443@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" , "Black, David" , General Area Review Team , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 18 Jun 2013 20:00:26 -0000 On Jun 18, 2013, at 11:39 AM, Sam Hartman wrote: > Joe, eap-lower-layer is not required for application authentication if > there's some other attribute that's specific to the lower layer. For > example Moonshot sends gss-acceptor-service-name but does not currently > send eap-lower-layer, and doing that seems consistent with the > requirements of the channel binding spec. >=20 > Adding a requirement for eap-lower-layer all the time would be new, but > might be reasonable. >=20 [Joe] Ah yes, I remember this. It would be simpler to just use eap lower-l= ayer attribute. I think we could massage the text to say something like "e= ap lower-layer layer attribute or equivalent attribute indicating the EAP l= ower layer in use" . Let me see what I can do with the text David provide= d. =20 > --Sam From ietf@augustcellars.com Wed Jun 19 15:18:48 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5F321F9EF1 for ; Wed, 19 Jun 2013 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 WESNrjsFR1Lj for ; Wed, 19 Jun 2013 15:18:43 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 690E421F9EE7 for ; Wed, 19 Jun 2013 15:18:43 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 0922D38F18; Wed, 19 Jun 2013 15:18:42 -0700 (PDT) From: "Jim Schaad" To: "'Josh Howlett'" , References: In-Reply-To: Date: Wed, 19 Jun 2013 15:17:48 -0700 Message-ID: <048901ce6d3a$d52a6820$7f7f3860$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGe+cdcoVMzzZVOGgZcRqdZ5bf4iZmce1ww Subject: Re: [abfab] Naming of SAML and AAA systems 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, 19 Jun 2013 22:18:48 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Josh Howlett > Sent: Tuesday, June 11, 2013 6:52 AM > To: abfab@ietf.org > Subject: [abfab] Naming of SAML and AAA systems > > I'm currently updating abfab-aaa-saml. The document is a bit unambiguous > about the naming of system entities, specifically: > > 1. There is no attempt to correlate the AAA and SAML entity naming (the > transport and message levels respectively). I believe that we need a naming > convention such that it is trivial to reliably infer a system entity's AAA or > SAML name, given the other name. I am not sure what this statement means. We have defined an NAI identifier format for use in SAML certificates so that there is a way to have common naming for the client entities between the two systems. Are you trying to look at how to do naming for the AAA server and the SAML entity server? > > 2. We don't yet have a mechanism for naming the functional roles of SAML > entities within a realm, which I believe is needed to satisfy the attribute > request and aggregation use cases. For example, an acceptor wanting > additional attributes for an authenticated user from realm Foo from another > attribute authority in realm Bar. This is an interesting question, do you have a case where you want to do this? I am also not sure how one would go about sending such a message, are you going to use AAA for routing the SAML request based on the domain you want to send it to? Is there a reason to expect that the AAA server at that location wouldn't just somehow know what to do? Jim > > Here's my proposal: > > * A SAML system names itself using an entity identifier is a URI that encodes > the AAA system's FQDN. For example "abfab:idp.example.com" and > "abfab:rp.example.com" would name two hosts with FQDNs of > idp.example.com and rp.example.com. For an RP, this entity identifier value > (less the abfab prefix) will therefore be equal to the value of the GSS- > Acceptor-Host-Name RADIUS attribute. It is worth noting that section > 4.3 of RFC3588 specifies a URI scheme for AAA protocols, but it looks a bit > elaborate for what we need (and possibly not complete, given the RADIUS > transport options today). Irrespective of the convention we choose, RADIUS > entities emitting SAML messages MUST use it. > > * SAML system entities are able to locate SAML entities within other realms > using RADIUS by using well-known values for the user fragment of the NAI. > For example, a relying party would resolve an attribute authority in realm by > using an NAI with value "abfab:aa@example.com". This might return a SAML > assertion issued by an entity named "abfab:idp.example.com". > Similarly an authorisation PDP might be resolved using > "abfab:pdp@example.com". > > Opinions? > > Josh. > > > > Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for- > profit company which is registered in England under No. 2881024 and whose > Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, > Oxfordshire. OX11 0SG. VAT No. 614944238 > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From jsalowey@cisco.com Wed Jun 19 16:23:11 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E3F21F9D69; Wed, 19 Jun 2013 16:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS54rLKLBgZi; Wed, 19 Jun 2013 16:23:05 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 33D5421F9D5B; Wed, 19 Jun 2013 16:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14139; q=dns/txt; s=iport; t=1371684185; x=1372893785; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UMC3pumKxAdqjVQNgYLKqxTstKU6qCVlVRhqL7fKB1c=; b=i7jhDQctPk04RQa/EoOYrd3s1HH0KfMP18GWAC+yWegrcz8xNKy0LEvq XF/kTlaaO1fItEBefrZcCNRmht503U6giqETf24B3WDXzkf+tHKdXXVIt 7UDQ4QkqBUyKJ9TkiTdN12sxymkJG5CHa8a0NUD1iKHYnlaOmYWocs8O5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEFALY8wlGtJXHA/2dsb2JhbABQCoMJMUm2YYg6gQAWdIIjAQEBBHkMBAIBCBEEAQELHQcyFAkIAgQOBQiIBrwGjgaBCzEHBgOCd2EDmGqKeYUigw+CKA X-IronPort-AV: E=Sophos;i="4.87,900,1363132800"; d="scan'208,217";a="225035286" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 19 Jun 2013 23:23:04 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5JNN4gd009359 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 23:23:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.220]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Wed, 19 Jun 2013 18:23:04 -0500 From: "Joseph Salowey (jsalowey)" To: "Black, David" Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgAYb7oMABB0QQAAClxl4P//t2GAgAA80uCAAbNjgA== Date: Wed, 19 Jun 2013 23:23:03 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71298265300@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71298265300@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.222] Content-Type: multipart/alternative; boundary="_000_A95B4818FD85874D8F16607F1AC7C628D03C96xmbrcdx09ciscocom_" MIME-Version: 1.0 Cc: General Area Review Team , "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 19 Jun 2013 23:23:11 -0000 --_000_A95B4818FD85874D8F16607F1AC7C628D03C96xmbrcdx09ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the text, some revision to address On Jun 18, 2013, at 12:34 PM, "Black, David" > wrote: [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For applicat= ion authentication, the EAP server MUST require that the correct EAP lower-laye= r attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All netw= ork access EAP peer implementations SHOULD use channel bindings including the E= AP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-laye= r attribute to prevent confusion with network access usage. " This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite= , mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): "In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Thanks, --David -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Tuesday, June 18, 2013 1:47 PM To: Black, David Cc: stefan.winter@restena.lu; General Area= Review Team; abfab@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 I think we could state this a bit better as something like: "In environments where EAP is used for applications authentication and netw= ork access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD suppor= t channel binding to explicitly identify the reason for authentication. Any = new usage of EAP MUST support channel bindings to prevent confusion with networ= k access usage. " That text is an improvement, and it's headed in the same direction as Sam's comment - "application bindings MUST be present in application authenticati= on" is a "MUST use" requirement, not just a "MUST implement" requirement. OTOH, I'm not clear on what "application bindings" means, as that term's no= t in the current draft. Specifically, I'm a bit unclear on "application bind= ings MUST be absent in network authentication" - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an "application binding", whatever that is? [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For applicat= ion authentication, the EAP server MUST require that the correct EAP lower-laye= r attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All netw= ork access EAP peer implementations SHOULD use channel bindings including the E= AP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-laye= r attribute to prevent confusion with network access usage. " Does this help? Thanks, Joe --_000_A95B4818FD85874D8F16607F1AC7C628D03C96xmbrcdx09ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Thanks for the text,  some revision to address 
On Jun 18, 2013, at 12:34 PM, "Black, David" <david.black@emc.com> wrote:

[Joe] Good points, the text can be more specific:=

"In environments where EAP is used for purposes other than network acc= ess
authentication all EAP servers MUST enforce channel bindings.  For app= lication
authentication, the EAP server MUST require that the correct EAP lower-laye= r
attribute be present in the channel binding data.   For network a= ccess
authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute.  &nbs= p;All network
access EAP peer implementations SHOULD use channel bindings including the E= AP
lower-layer attribute to explicitly identify the reason for authentication.=
Any new usage of EAP MUST use channel bindings including the EAP lower-laye= r
attribute to prevent confusion with network access usage. "

This is looking good, modulo Sam's comment on EAP lower-layer vs. something=
else that I'll leave to you and he to sort out.  I have a suggested re= write,
mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not
intended to change any requirements from what you wrote):

"In environments where EAP is used for purposes other than network acc= ess
authentication:

o All EAP s= ervers and all application access EAP peers MUST
support channel bindin= gs.  All network access EAP peers
SHOULD support channel= bindings.

o Channel b= inding MUST be used for all application authentication.
The EAP server MUST re= quire that the correct EAP lower-layer
attribute be present i= n the channel binding data for
application authentica= tion.
o Channe= l binding MUST be used for all application authentication.
The EAP server M= UST either require that the correct EAP lower-layer
attribute or ano= ther attribute indicating the purpose of the authentication
be pre= sent in the channel binding data for application authentication.


o Channel b= inding SHOULD be used for all network access authentication,
and when channel bindi= ng data is present, the EAP server MUST
require that it contai= n the correct EAP lower-layer attribute
to explicitly identify= the reason for authentication.

o Any new u= sage of EAP MUST use channel bindings including the
EAP lower-layer attrib= ute to prevent confusion with network
access usage.

Thanks,
--David


-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
Sent: Tuesday, June 18, 2013 1:47 PM
To: Black, David
Cc: stefan.winter@restena.lu; General Area Review Team; abfab@ietf.org;
ietf@ietf.org
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03=


I think we could state this a bit better as something like:

"In environments where EAP is used for applications authentication and= network
access authentication all EAP servers MUST understand channel bindings and<= br> require that application bindings MUST be present in application
authentication and that application bindings MUST be absent in network
authentication.   All network access EAP peer implementations SHO= ULD support
channel binding to explicitly identify the reason for authentication.  = ;Any new
usage of EAP MUST support channel bindings to prevent confusion with networ= k
access usage. "

That text is an improvement, and it's headed in the same direction as Sam's=
comment - "application bindings MUST be present in application authent= ication"
is a "MUST use" requirement, not just a "MUST implement"= ; requirement.

OTOH, I'm not clear on what "application bindings" means, as that= term's not
in the current draft.  Specifically, I'm a bit unclear on "applic= ation bindings
MUST be absent in network authentication" - does that mean that channe= l
binding must be absent, or that channel binding is optional, but if channel=
binding is present, it MUST NOT be an "application binding", what= ever that
is?


[Joe] Good points, the text can be more specific:

"In environments where EAP is used for purposes other than network acc= ess
authentication all EAP servers MUST enforce channel bindings.  For app= lication
authentication, the EAP server MUST require that the correct EAP lower-laye= r
attribute be present in the channel binding data.   For network a= ccess
authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute.  &nbs= p;All network
access EAP peer implementations SHOULD use channel bindings including the E= AP
lower-layer attribute to explicitly identify the reason for authentication.=
Any new usage of EAP MUST use channel bindings including the EAP lower-laye= r
attribute to prevent confusion with network access usage. "

Does this help?

Thanks,

Joe



--_000_A95B4818FD85874D8F16607F1AC7C628D03C96xmbrcdx09ciscocom_-- From d.w.chadwick@kent.ac.uk Thu Jun 20 00:39:39 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235B621F96FE for ; Thu, 20 Jun 2013 00:39:39 -0700 (PDT) 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_54=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 Pj8tJwjeUKKx for ; Thu, 20 Jun 2013 00:39:33 -0700 (PDT) Received: from mx3.kent.ac.uk (mx3.kent.ac.uk [129.12.21.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3324921E80DE for ; Thu, 20 Jun 2013 00:39:32 -0700 (PDT) Received: from 43.86.112.87.dyn.plus.net ([87.112.86.43] helo=[192.168.1.67]) by mx3.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UpZSp-0002C5-Gt; Thu, 20 Jun 2013 08:39:27 +0100 Message-ID: <51C2B1AA.7000105@kent.ac.uk> Date: Thu, 20 Jun 2013 08:39:22 +0100 From: David Chadwick User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jim Schaad References: <048901ce6d3a$d52a6820$7f7f3860$@augustcellars.com> In-Reply-To: <048901ce6d3a$d52a6820$7f7f3860$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Naming of SAML and AAA systems 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, 20 Jun 2013 07:39:39 -0000 On 19/06/2013 23:17, Jim Schaad wrote: >> 2. We don't yet have a mechanism for naming the functional roles of SAML >> >entities within a realm, which I believe is needed to satisfy the > attribute >> >request and aggregation use cases. For example, an acceptor wanting >> >additional attributes for an authenticated user from realm Foo from > another >> >attribute authority in realm Bar. I believe the only way you can do this is by having global role names, and knowledge about who issues which roles. (In general there is a many to many mapping of roles to issuers.) Hierarchical role naming such as realm.role is one way of achieving this for locally named roles, but those roles that are already globally named dont need this hierarchical naming, and re-naming a global role (say globalrole) realm1.globalrole and realm2.globalrole would not be correct. David From hartmans@painless-security.com Thu Jun 20 02:56:35 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288CA11E8116; Thu, 20 Jun 2013 02:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlneuKxmBuI6; Thu, 20 Jun 2013 02:56:29 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4802221F9FFD; Thu, 20 Jun 2013 02:56:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 70C6C20127; Thu, 20 Jun 2013 05:52:31 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPqBf-X0ASKW; Thu, 20 Jun 2013 05:52:31 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 20 Jun 2013 05:52:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 75C24807E8; Thu, 20 Jun 2013 05:56:12 -0400 (EDT) From: Sam Hartman To: "Joseph Salowey \(jsalowey\)" References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71298265300@MX15A.corp.emc.com> Date: Thu, 20 Jun 2013 05:56:12 -0400 In-Reply-To: (Joseph Salowey's message of "Wed, 19 Jun 2013 23:23:03 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" , "Black, David" , General Area Review Team , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 20 Jun 2013 09:56:35 -0000 I'm fine with this text. Either with eap-lower-layer as a MUST or the more complex version. From david.black@emc.com Thu Jun 20 05:32:39 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC1E21F9C02; Thu, 20 Jun 2013 05:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZZcakcQMArg; Thu, 20 Jun 2013 05:32:34 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9929F21F9BFF; Thu, 20 Jun 2013 05:32:34 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5KCWW9l005691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Jun 2013 08:32:33 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd06.lss.emc.com [10.254.222.130]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Thu, 20 Jun 2013 08:32:13 -0400 Received: from mxhub33.corp.emc.com (mxhub33.corp.emc.com [10.254.93.81]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r5KCW1eU006337; Thu, 20 Jun 2013 08:32:12 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub33.corp.emc.com ([::1]) with mapi; Thu, 20 Jun 2013 08:32:02 -0400 From: "Black, David" To: "Joseph Salowey (jsalowey)" Date: Thu, 20 Jun 2013 08:32:00 -0400 Thread-Topic: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thread-Index: Ac5rzQ3h5Vr98eb9RParuraCHgwUcgAYb7oMABB0QQAAClxl4P//t2GAgAA80uCAAbNjgP//eC/w Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298265674@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71298265158@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE712982652A5@MX15A.corp.emc.com> <8D3D17ACE214DC429325B2B98F3AE71298265300@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71298265674MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: General Area Review Team , "abfab@ietf.org" , "ietf@ietf.org" Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 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, 20 Jun 2013 12:32:40 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71298265674MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think this is ok, but my email client isn't distinguishing the new vs. ol= d text. If it's just changes to produce this new bullet, I have a small edit: o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. "MUST either require that" --> "MUST require that either" Thanks, --David From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Wednesday, June 19, 2013 7:23 PM To: Black, David Cc: stefan.winter@restena.lu; General Area Review Team; abfab@ietf.org; iet= f@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 Thanks for the text, some revision to address On Jun 18, 2013, at 12:34 PM, "Black, David" > wrote: [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For applicat= ion authentication, the EAP server MUST require that the correct EAP lower-laye= r attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All netw= ork access EAP peer implementations SHOULD use channel bindings including the E= AP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-laye= r attribute to prevent confusion with network access usage. " This is looking good, modulo Sam's comment on EAP lower-layer vs. something else that I'll leave to you and he to sort out. I have a suggested rewrite= , mostly to clarify MUST vs. SHOULD requirements for support vs. usage, and to reformat into a structured bullet list of requirements (this is not intended to change any requirements from what you wrote): "In environments where EAP is used for purposes other than network access authentication: o All EAP servers and all application access EAP peers MUST support channel bindings. All network access EAP peers SHOULD support channel bindings. o Channel binding MUST be used for all application authentication. The EAP server MUST require that the correct EAP lower-layer attribute be present in the channel binding data for application authentication. o Channel binding MUST be used for all application authentication. The EAP server MUST either require that the correct EAP lower-layer attribute or another attribute indicating the purpose of the authentication be present in the channel binding data for application authentication. o Channel binding SHOULD be used for all network access authentication, and when channel binding data is present, the EAP server MUST require that it contain the correct EAP lower-layer attribute to explicitly identify the reason for authentication. o Any new usage of EAP MUST use channel bindings including the EAP lower-layer attribute to prevent confusion with network access usage. Thanks, --David -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] Sent: Tuesday, June 18, 2013 1:47 PM To: Black, David Cc: stefan.winter@restena.lu; General Area= Review Team; abfab@ietf.org; ietf@ietf.org Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicability-03 I think we could state this a bit better as something like: "In environments where EAP is used for applications authentication and netw= ork access authentication all EAP servers MUST understand channel bindings and require that application bindings MUST be present in application authentication and that application bindings MUST be absent in network authentication. All network access EAP peer implementations SHOULD suppor= t channel binding to explicitly identify the reason for authentication. Any = new usage of EAP MUST support channel bindings to prevent confusion with networ= k access usage. " That text is an improvement, and it's headed in the same direction as Sam's comment - "application bindings MUST be present in application authenticati= on" is a "MUST use" requirement, not just a "MUST implement" requirement. OTOH, I'm not clear on what "application bindings" means, as that term's no= t in the current draft. Specifically, I'm a bit unclear on "application bind= ings MUST be absent in network authentication" - does that mean that channel binding must be absent, or that channel binding is optional, but if channel binding is present, it MUST NOT be an "application binding", whatever that is? [Joe] Good points, the text can be more specific: "In environments where EAP is used for purposes other than network access authentication all EAP servers MUST enforce channel bindings. For applicat= ion authentication, the EAP server MUST require that the correct EAP lower-laye= r attribute be present in the channel binding data. For network access authentication, the EAP server MUST require that if channel bindings are present they MUST contain the correct EAP lower-layer attribute. All netw= ork access EAP peer implementations SHOULD use channel bindings including the E= AP lower-layer attribute to explicitly identify the reason for authentication. Any new usage of EAP MUST use channel bindings including the EAP lower-laye= r attribute to prevent confusion with network access usage. " Does this help? Thanks, Joe --_000_8D3D17ACE214DC429325B2B98F3AE71298265674MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I think this is ok, but my email client isn’t distinguishing the new = vs. old text.

 

If it’s just changes to produce this new bullet= , I have a small edit:

 

o Channel binding MUST be used for all appli= cation authentication.

The EAP server MUST either require that the correct EAP lower-= layer
attribute or another attribute indicating the purpose of the authe= ntication

= be present in the channel binding data for application authentication.=

 

“MUST either require that” --> “MUST require = that either”

 <= /span>

Thanks,
--David

 

From: Joseph Salowey (jsalowey) [mailto:jsalo= wey@cisco.com]
Sent: Wednesday, June 19, 2013 7:23 PM
To:<= /b> Black, David
Cc: stefan.winter@restena.lu; General Area Revie= w Team; abfab@ietf.org; ietf@ietf.org
Subject: Re: [abfab] Gen-AR= T review of draft-ietf-abfab-eapapplicability-03

 

Thank= s for the text,  some revision to address 

On Jun 18, 2013, at 12:34 PM, "Black, David&quo= t; <david.black@emc.com> w= rote:



= [Joe] Good points, the text can be more specific:

"In environme= nts where EAP is used for purposes other than network access
authenticat= ion all EAP servers MUST enforce channel bindings.  For applicationauthentication, the EAP server MUST require that the correct EAP lower-lay= er
attribute be present in the channel binding data.   For net= work access
authentication, the EAP server MUST require that if channel = bindings are
present they MUST contain the correct EAP lower-layer attri= bute.   All network
access EAP peer implementations SHOULD use= channel bindings including the EAP
lower-layer attribute to explicitly = identify the reason for authentication.
Any new usage of EAP MUST use ch= annel bindings including the EAP lower-layer
attribute to prevent confus= ion with network access usage. "


This is looking good, modulo Sam's comment on EAP lower-la= yer vs. something
else that I'll leave to you and he to sort out.  = I have a suggested rewrite,
mostly to clarify MUST vs. SHOULD requiremen= ts for support vs. usage, and
to reformat into a structured bullet list = of requirements (this is not
intended to change any requirements from wh= at you wrote):

"In environments where EAP is used for purposes = other than network access
authentication:

o All EAP servers and a= ll application access EAP peers MUST
support channel bindings.  All= network access EAP peers
SHOULD support channel bindings.

o Chan= nel binding MUST be used for all application authentication.
The EAP ser= ver MUST require that the correct EAP lower-layer
attribute be present i= n the channel binding data for
application authentication.



o Channel binding MUST be used for all app= lication authentication.

The EAP= server MUST either require that the correct EAP lower-layer

attribute or another attribute indicating the = purpose of the authentication

be present in the channel binding data for application authentication= .




o Channel binding SHOULD be used for all network access au= thentication,
and when channel binding data is present, the EAP server M= UST
require that it contain the correct EAP lower-layer attribute
to = explicitly identify the reason for authentication.

o Any new usage o= f EAP MUST use channel bindings including the
EAP lower-layer attribute = to prevent confusion with network
access usage.

Thanks,
--Davi= d



-----Original Message-= ----
From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]
Sent: Tuesday, June 18, 2013 1:47 PM
To: Bl= ack, David
Cc: stefan.winter= @restena.lu; General Area Review Team; abfab@ietf.org;
ietf@ietf.org=
Subject: Re: [abfab] Gen-ART review of draft-ietf-abfab-eapapplicabilit= y-03



I think we could state this a bit b= etter as something like:

"In environments where EAP is used for= applications authentication and network
access authentication all EAP s= ervers MUST understand channel bindings and
require that application bin= dings MUST be present in application
authentication and that application= bindings MUST be absent in network
authentication.   All netw= ork access EAP peer implementations SHOULD support
channel binding to ex= plicitly identify the reason for authentication.  Any new
usage of = EAP MUST support channel bindings to prevent confusion with network
acce= ss usage. "


That t= ext is an improvement, and it's headed in the same direction as Sam's
co= mment - "application bindings MUST be present in application authentic= ation"
is a "MUST use" requirement, not just a "MUST= implement" requirement.

OTOH, I'm not clear on what "appl= ication bindings" means, as that term's not
in the current draft. &= nbsp;Specifically, I'm a bit unclear on "application bindings
MUST = be absent in network authentication" - does that mean that channel
= binding must be absent, or that channel binding is optional, but if channel=
binding is present, it MUST NOT be an "application binding", = whatever that

is?

=

 


[Joe] Good points, the text can be more specific:
"In environments where EAP is used for purposes other than networ= k access
authentication all EAP servers MUST enforce channel bindings. &= nbsp;For application
authentication, the EAP server MUST require that th= e correct EAP lower-layer
attribute be present in the channel binding da= ta.   For network access
authentication, the EAP server MUST r= equire that if channel bindings are
present they MUST contain the correc= t EAP lower-layer attribute.   All network
access EAP peer imp= lementations SHOULD use channel bindings including the EAP
lower-layer a= ttribute to explicitly identify the reason for authentication.
Any new u= sage of EAP MUST use channel bindings including the EAP lower-layer
attr= ibute to prevent confusion with network access usage. "

Does th= is help?

Thanks,

Joe

=  

 

= --_000_8D3D17ACE214DC429325B2B98F3AE71298265674MX15Acorpemccom_-- From hartmans@painless-security.com Thu Jun 20 07:16:39 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011ED21F9BF0 for ; Thu, 20 Jun 2013 07:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McTX-gGwF8ux for ; Thu, 20 Jun 2013 07:16:32 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 56BD621F9BCB for ; Thu, 20 Jun 2013 07:16:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B712120163; Thu, 20 Jun 2013 10:12:33 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LeLeVar75-yG; Thu, 20 Jun 2013 10:12:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 20 Jun 2013 10:12:33 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F0CF8807EF; Thu, 20 Jun 2013 10:16:14 -0400 (EDT) From: Sam Hartman To: David Chadwick References: <048901ce6d3a$d52a6820$7f7f3860$@augustcellars.com> <51C2B1AA.7000105@kent.ac.uk> Date: Thu, 20 Jun 2013 10:16:14 -0400 In-Reply-To: <51C2B1AA.7000105@kent.ac.uk> (David Chadwick's message of "Thu, 20 Jun 2013 08:39:22 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] Naming of SAML and AAA systems 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, 20 Jun 2013 14:16:39 -0000 Josh, in the case where someone is deploying SAML infrastructure specifically to work with ABFAB, I think it ought to be relatively easy to map naming between AAA and SAML. However, I don't understand how to do this in the case where we're using existing SAML infrastructure for ABFAB. --Sam From leifj@mnt.se Thu Jun 20 07:21:09 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3E421F90CC for ; Thu, 20 Jun 2013 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im0wCTDOZK+F for ; Thu, 20 Jun 2013 07:21:09 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id F36D021F8FF3 for ; Thu, 20 Jun 2013 07:21:08 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id mz10so2913845bkb.22 for ; Thu, 20 Jun 2013 07:21:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=SGNTnXmP3mKIQjTMVFegJB/2y0sYO0O/++/LN2zfPA0=; b=O2W2nvI9wYzRG7HbO9uva1M9h2Ns+zTD+/s2g1qqcavwFLyaYZ4knD8orkTfOg81Ap JOnzjzB80mMqE3owF0Pqv/y/rjisHmpT/BwK8QUdiA2mQ3hp67Tgh+DDGXFRVakyZoRF kZD8DSLmgHJZVieYsXOv+f1qG+1tu2lJYL01+EdnRel3faltw8qWrJqb43nh+KLfkMd7 KO1EbPdubCWWPmOMi2LmaTZdh7Y6+dAvjtpQw7uiZsahd+KPdWlNXDV1ORHVe86N100o rfUQfa6twJ/+jizkTjeLXvo9w8I0TJo95EVPat2VMK8crb2lhaws3y9f7Y5aHK59GO49 7RQw== X-Received: by 10.205.3.5 with SMTP id nw5mr1153061bkb.137.1371738060819; Thu, 20 Jun 2013 07:21:00 -0700 (PDT) Received: from [109.105.104.183] (dhcp49.se-tug.nordu.net. [109.105.104.183]) by mx.google.com with ESMTPSA id rj6sm285868bkb.12.2013.06.20.07.20.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 07:21:00 -0700 (PDT) Message-ID: <51C30FCA.9090103@mnt.se> Date: Thu, 20 Jun 2013 16:20:58 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: abfab@ietf.org References: <048901ce6d3a$d52a6820$7f7f3860$@augustcellars.com> <51C2B1AA.7000105@kent.ac.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnoIHcwylqlRYXfGJ2yEyd357ku1dweXMfFuGxoA3w7FyJ5Zl1dZLshuPgcGnYAjWjIHAR0 Subject: Re: [abfab] Naming of SAML and AAA systems 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, 20 Jun 2013 14:21:09 -0000 On 06/20/2013 04:16 PM, Sam Hartman wrote: > Josh, in the case where someone is deploying SAML infrastructure > specifically to work with ABFAB, I think it ought to be relatively easy > to map naming between AAA and SAML. > > However, I don't understand how to do this in the case where we're > using existing SAML infrastructure for ABFAB. This gets you into SAML metadata territory. From hartmans@painless-security.com Thu Jun 20 11:03:10 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE1221F9FFF for ; Thu, 20 Jun 2013 11:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVbMeZPqp785 for ; Thu, 20 Jun 2013 11:03:05 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A569F21F9E0D for ; Thu, 20 Jun 2013 11:03:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A9E6A20120; Thu, 20 Jun 2013 13:59:06 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NM1gAWJYe3A; Thu, 20 Jun 2013 13:59:05 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 20 Jun 2013 13:59:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 14BAE80809; Thu, 20 Jun 2013 14:02:47 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <048901ce6d3a$d52a6820$7f7f3860$@augustcellars.com> <51C2B1AA.7000105@kent.ac.uk> <51C30FCA.9090103@mnt.se> Date: Thu, 20 Jun 2013 14:02:47 -0400 In-Reply-To: <51C30FCA.9090103@mnt.se> (Leif Johansson's message of "Thu, 20 Jun 2013 16:20:58 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Naming of SAML and AAA systems 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, 20 Jun 2013 18:03:10 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> On 06/20/2013 04:16 PM, Sam Hartman wrote: >> Josh, in the case where someone is deploying SAML infrastructure >> specifically to work with ABFAB, I think it ought to be >> relatively easy to map naming between AAA and SAML. >> >> However, I don't understand how to do this in the case where >> we're using existing SAML infrastructure for ABFAB. Leif> This gets you into SAML metadata territory. I think Josh was looking for something structural. From leifj@sunet.se Fri Jun 21 13:30:42 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F175421F9D53 for ; Fri, 21 Jun 2013 13:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKuQAEnpfMDm for ; Fri, 21 Jun 2013 13:30:42 -0700 (PDT) Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) by ietfa.amsl.com (Postfix) with ESMTP id 1DAA421F9D02 for ; Fri, 21 Jun 2013 13:30:41 -0700 (PDT) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by e-mailfilter02.sunet.se (8.14.3/8.14.3/Debian-9.4) with ESMTP id r5LKUc4Y027580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Jun 2013 22:30:38 +0200 Received: from [10.0.0.244] (tb62-102-145-131.cust.teknikbyran.com [62.102.145.131]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r5LKUU63025061 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 21 Jun 2013 20:30:38 GMT Message-ID: <51C4B7E6.4040803@sunet.se> Date: Fri, 21 Jun 2013 22:30:30 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: abfab@ietf.org References: <048901ce6d3a$d52a6820$7f7f3860$@augustcellars.com> <51C2B1AA.7000105@kent.ac.uk> <51C30FCA.9090103@mnt.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0, tokens from: outbound, nordu-net:default, base:default, @@RPTN) X-p0f-Info: os=unknown unknown, link=Ethernet or modem X-CanIt-Geo: ip=62.102.145.131; country=SE; region=26; city=Vallentuna; latitude=59.5333; longitude=18.0833; http://maps.google.com/maps?q=59.5333,18.0833&z=6 X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default) X-Canit-Stats-ID: 0aJP8uC8q - ef9e64cfcfcb - 20130621 X-Antispam-Training-Forget: https://mailfilter.nordu.net/canit/b.php?i=0aJP8uC8q&m=ef9e64cfcfcb&t=20130621&c=f X-Antispam-Training-Nonspam: https://mailfilter.nordu.net/canit/b.php?i=0aJP8uC8q&m=ef9e64cfcfcb&t=20130621&c=n X-Antispam-Training-Spam: https://mailfilter.nordu.net/canit/b.php?i=0aJP8uC8q&m=ef9e64cfcfcb&t=20130621&c=s X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: Re: [abfab] Naming of SAML and AAA systems 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, 21 Jun 2013 20:30:43 -0000 On 06/20/2013 08:02 PM, Sam Hartman wrote: >>>>>> "Leif" == Leif Johansson writes: > Leif> On 06/20/2013 04:16 PM, Sam Hartman wrote: > >> Josh, in the case where someone is deploying SAML infrastructure > >> specifically to work with ABFAB, I think it ought to be > >> relatively easy to map naming between AAA and SAML. > >> > >> However, I don't understand how to do this in the case where > >> we're using existing SAML infrastructure for ABFAB. > Leif> This gets you into SAML metadata territory. > > I think Josh was looking for something structural. > _______________________________________________ > SAML metadata is plenty structural :-) From ietf@augustcellars.com Fri Jun 21 14:58:09 2013 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B7921F9E33 for ; Fri, 21 Jun 2013 14:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 Wvx6T2DGW3Wp for ; Fri, 21 Jun 2013 14:58:05 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4D76F21F9E27 for ; Fri, 21 Jun 2013 14:58:05 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id DD74A38F34; Fri, 21 Jun 2013 14:58:04 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Leif Johansson'" References: <048901ce6d3a$d52a6820$7f7f3860$@augustcellars.com> <51C2B1AA.7000105@kent.ac.uk> <51C30FCA.9090103@mnt.se> In-Reply-To: Date: Fri, 21 Jun 2013 14:57:10 -0700 Message-ID: <06c301ce6eca$4800bc60$d8023520$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQGe+cdcoVMzzZVOGgZcRqdZ5bf4iQKP4nWZAsQaxu0BHVuuhgFQU34mAY6VqYKZVR7ZgA== Cc: abfab@ietf.org Subject: Re: [abfab] Naming of SAML and AAA systems 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, 21 Jun 2013 21:58:10 -0000 Yes - but we still don't know what type of problem he thinks he is solving. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Thursday, June 20, 2013 11:03 AM > To: Leif Johansson > Cc: abfab@ietf.org > Subject: Re: [abfab] Naming of SAML and AAA systems > > >>>>> "Leif" == Leif Johansson writes: > > Leif> On 06/20/2013 04:16 PM, Sam Hartman wrote: > >> Josh, in the case where someone is deploying SAML infrastructure > >> specifically to work with ABFAB, I think it ought to be > >> relatively easy to map naming between AAA and SAML. > >> > >> However, I don't understand how to do this in the case where > >> we're using existing SAML infrastructure for ABFAB. > Leif> This gets you into SAML metadata territory. > > I think Josh was looking for something structural. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab