From klaas@cisco.com Mon Apr 4 07:14:05 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B85B028C100 for ; Mon, 4 Apr 2011 07:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jyLklazzVzz for ; Mon, 4 Apr 2011 07:13:58 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 4AE4E3A67FB for ; Mon, 4 Apr 2011 07:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=11431; q=dns/txt; s=iport; t=1301926540; x=1303136140; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=OZpOSgsB9zlWHf4imwJD+tpZgXTzUHHKOsRnxrNYsaE=; b=dzdpSMH3YrytBBLex2ddnzxfK49VeD0opTKdTB6n2cbmHaRMp/nxD/6o dW8v/50t9WhDzMGzO2gHDmoZN7xnVmOfUlkkIAVXCm4R5mwESZYvk2EYM 3XAaUNnF1SR1Vv9HBY2XL/mePwNs7RF2sJkWLZZC6Jxh+qbiC8tR4kTbG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisEAM3RmU2Q/khMgWdsb2JhbAClYBQBARYmJaQem1CCfoJtBI0j X-IronPort-AV: E=Sophos;i="4.63,297,1299456000"; d="scan'208";a="24365900" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 04 Apr 2011 14:15:39 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p34EFcCO015061 for ; Mon, 4 Apr 2011 14:15:39 GMT Message-ID: <4D99D28A.9040701@cisco.com> Date: Mon, 04 Apr 2011 16:15:38 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] abfab@IETF80 minutes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 04 Apr 2011 14:14:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Please find below the abfab session minutes, with thanks to the note takers and jabber scribes! Klaas & Leif ===== Abfab WG Minutes IETF 80 Prague, Czech Republic Abfab 1: 15.10-16.10 Monday March 28, 2011 Abfab 2: 09.00-11.30 Thursday March 31, 2011 Chairs: Klaas Wierenga Leif Johansson - ---------------------------------------- abfab 1 (monday) - ---------------------------------------- Note well Note taker established (Stefan Winter) Jabber scribe established (Jeffrey Hutzelman) agenda approved ABFAB Architecture draft (Eliot Lear) - ------------------------------------------------- draft-lear-abfab-arch-02 Josh Howlett (Josh) at mic for privacy considerations: most people think of privacy is on "ethical level" Josh thinks along "keep RP/IdP out of prison" - privacy regulations exist User consent one vehicle for privacy - RPs need some attributes; but not others * user-centric paradigm - let the user disclose everything he wants * non-user-centric: third party releases, e.g. IdP technology needs to provide enough privacy support to satisfy regulations Sean Turner at mic: IESG review comments on security considerations, need to be spelt out in detail Sam Hartman (Sam): on coop with kitten: channel bindings in MS are implemented "kinda cool" - but is not possible with GSS. kitten and abfab work is required to to get similar functionality in (issue is: how to handle not being sure if the other end supports channel binding upfront) Leif: do we need to recharter if normative text sneaks into arch document? Sam suggests operational/implementation best-practice document. Individual submissions solicited. Eliot: text is small though; and informative text can have normative lingo. Hummed: in favor of approach (unanimous, overall low participation, to be confirmed on the list). Leif again solicited individual drafts; for later adoption by WG. ABFAB Use-Cases (Rhys Smith) - -------------------------------------------- draft-abfab-usecases-00 Aaron Falk (BBN): Geni project uses federated identity for access to testbeds. Use case: access to networking resources. Aaron will read the draft to see how it fits in. Jim Schaad: plug for plasma BOF. plasma should be building on ABFAB. Use case: distribution of stuff over mail protocol; but need federated access to these. Show of hands: 2 readers of draft; needs more input from community. Leif encourages everybody to read! Presentation of Project Moonshot (Sam Hartman) - ----------------------------------------------------------------- Abfab VM was tried out: proof of concept showed to work indeed Leif: doing UI work is in charter, work waiting to be done - will discuss in abfab2 Sam: SAML is being used differently than usual - leads to authorization question: need to request attributes on behalf of someone else. Sam: not ready for production use at all! Play with it only. - ---------------------------------------- abfab 2 (thursday) - ---------------------------------------- Note well Note taker established (Linus Nordberg) Jabber scribe established (Melinda Shore) agenda approved GSS-EAP (Sam Hartman) - -------------------------------------------- - - slide "name format": Jeffrey Hutzelman (jhutz): there's a bug in the name format - on anonymous: wellknown/ANONYMOUS is used, but sending empty ("") in RADIUS jhutz: make GSS look less like Kerberos Sam: minimizing implementation costs but this anonymous case probably stretches it Jhutz: worth examining to use empty but don't forget the anonymous flag Leif: charter doesn't mention Kerberos Lucy Lynch: abfab is not only about Moonshot. please avoid confusion. Jhutz: 1. the accessor might not know [acceptor?] due to multiple hops Leif: ask kitten to revisit anonymous for gss? sam: not yet. Jhutz: they might take a long time to come up with an answer better than what sam is saying here and what kerberos already has. Leif: moonshot does things that doesn't correspond to anything in the spec? Sam Hartman on the subject of name formats: We will do the following: 1. fix the abnf to note problems with "anonymous" using a slash when you don't have a host component 2. specify anon behavior. empty name is the best. 3. document realm anonymous name and the implications of it 4. dicusss i8n - slide "eap method req" - should we say "always eap channel binding" or only when mutual authn is being done? no reply. sam: please have opinion on list. sam: should i explain it here or? for reasons of time constraints, no. - "proposed solution" - strong opinion on names? no response. - "requirement for MIC" - [RFC 3961 doesn't have an incremental hash -- implementer will have to store full state before being able to send it. client need memory to hold the complete conversation. large cookies might be another the effect.] Jim Schaad: what if i want to carry on a conversation _before_ i've been at an idp? sam: PLASMA case, the blob shouldn't be a part of the request, perhaps only a hash of the blob. Jim: layering problem. Jhutz: application like imap, before sasl gss server says mech support here, then some roundtrips, if imap + starttls and then you want to autn again but you'd have to renegotiate. Leif: PLASMA is an important use case but we need to finish this. please repeat the three options. Sam on the options for MIC: - opt 1. integrity protect each token, f.ex. the flags token - opt 2. signon a hash function, EAP+<3961-enctype>+ - opt 3. use large tokens - opt 4. don't integrity protect large thingies (bad option!) Sam: the maximum complexity for opt 1 might be substantial Luke: opt 5. would be revise 3961 and couldn't we put this in GSS channel binding? Sam: need help from someone who understands RADIUS VSA's and 2. how do i register an entry with IANA - Hannes Tschofenig will help Sam with RADIUS VSA's and how to register with IANA RADIUS atttrib for SAML (Josh Howlett) - -------------------------------------------- - PLASMA is going with either ws-trust or abfab Josh: jim, do do use SAML for your "PDP's"? Jim: this isn't relevant for conversation between client and service Leif: the IdP can combine them Scott Cantor: more than one assertion in a response Luke Howard: standard RADIUS AVP? Josh: yes. * Diameter attributes for SAML (Mark Jones) - -------------------------------------------- - extending diameter EAP with new AVPs - DER: SAML-AuthnRequest AVP - DEV: SAML-AuthnRespnse AVP, SAML-Assertion AVP Josh: difference to radius is you define attributes for specific SAML attribs while we have a generic attrib. reason? Hannes: easier to read, no real semantic difference. Josh: makes sense. we would put it in a AAA binding document, glad for guidance from SAML ppl. scott: re SAML binding, we said only request/response because the binding wasn't supposed to be a protocol. Josh: if "we" took the same position, we're running out of RADIUS attr space (not considering extended attrib proposal). Sam: hop-by-hop trpt layer security? hannes: TLS and IP-sec. Scott: an analogy: in http we have explicit routing thanks to urls. Mark: a proxy should be able to pass along without understanding the payload] Josh: since SAML2 was std 2005 there has been only one new protocol defined Scott: new protocols are not a big deal] Leif (as individual): you will need attribute query Sam: think we should use a single AVP unless there are needs for more Mark: if we return EAP success... sam: in radius we don't have cirticial restrictions on success and if we need it, let's do it together for RADIUS and diameter. Leif calls for hums: 1. more or less in the right direction? 2. adopt as a wg docu? Sam: what if we want to say 1 attrib rather than 2, how do i hum on number 1? Leif: adoption means that change ctrl goes to the wg. Melinda Shore: is this a showstopper for anyone? no replies. Leif: do you want to decide "this" (one or several AVPs for diameter) before huming on adoption? result: no. Leif: humming on adoption. result: yes, wg should adopt. Action: confirm adoption of draft-jones-diameter-abfab as WG document as draft-ietf-abfab-diameter with Mark Jones and Hannes Tschofenig as document editors on list. KNP - Key Negotiaion Protocol (Josh Howlett) - -------------------------------------------- Eliot Lear: flat files laying around? Josh: yes, and that's an administrative problem. Dave Crocker: how can TLS be not hop-by-hop? conclusion: _trust_ is no longer path-based [?]] Sam: the routing has similar properties as bgp, but unlike dns each hop may have policy and do filtering Sam: you shouldn't have to run your own introducer if you're too small Jim: is this really abfab? how do the trusted router fit in the charter? [josh: you _could_ have introducers w/o trust routers but it doesn't buy you much.] Leif: this is an invited presentation and not a question of adoption. this is partially a problem statement document and i suggest splitting the document in two parts Mark: s/radius/radius or diameter/g. Josh: ack. Mark: introducer == broker? Josh: yes. Eliot: useful and interesting presentation, we need ways to deal with larger and higher numbers of federations. NFSv4 (Andy Adamson) - -------------------------------------------- - - Won't happen since Andy isn't in the room and also we're running out of time. Milestones update - -------------------------------------------- Leif: - - emsk will possibly been removed since not used - - eap applicabililty is getting done by Joe Salowey and Stefan Winter - - lacking UI usability doc still. question: anyone done anything re this? Rhys: Janet has some work on UI going on within Moonshot and they will write an IETF document and Rhys will coedit it. Leif stares at Bob. Bob Morgan: i can be persuaded to work with Rhys on this because of kantara ULX involvement. Leif: Will the documents slip? silence means no. result: silence. Rhys: august might be tough. Josh: no, that's fine. [:-)] * OID registry (Rhys Smith) - -------------------------------------------- - - got an oid from iana: 1.3.6.1.5.5.15 Jhutz: why reimplement? Sam: backwards incompat changes. making gss-eap in the next version. - - Rhys asks implementers to let him know when OID's under abfab arc are used. Closing - ------- The chairs close the meeting -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Z0ooACgkQH2Wy/p4XeFJQmQCePoUeJiFFiSfWY/IswVgnWtL6 plAAoL5FeKglPnXPEtyx3srt0bp1EycT =msJK -----END PGP SIGNATURE----- From klaas@cisco.com Fri Apr 8 06:51:14 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F74B28C16B for ; Fri, 8 Apr 2011 06:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-eo446uvZnG for ; Fri, 8 Apr 2011 06:51:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 10F313A690F for ; Fri, 8 Apr 2011 06:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=928; q=dns/txt; s=iport; t=1302270778; x=1303480378; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=mEbzoRbdbNggI3T6kUkHvcqU28dmem5I17oSAtbhl1c=; b=ck30gqjXZBq7G3Yy3nJkxtk5/mMekkj5G3fH4ZI/psr102UmONNMp1pz 4u4I/+8ImDSeFr8ZYNywGB45Fn10ZUDjGMJsRSAAgJhYlDZ0jdu5VACfk YoCwnZaVnTbhDH+ap1bP4JrhY4mn7A7ts6Vh6nkWInWE4NXp49QBwDAM+ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocDAPYRn02Q/khMgWdsb2JhbACmFBQBARYmJaULnDCFbQSNTg X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="scan'208";a="24995937" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Apr 2011 13:52:57 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p38DqvMD026495 for ; Fri, 8 Apr 2011 13:52:57 GMT Message-ID: <4D9F1339.9080609@cisco.com> Date: Fri, 08 Apr 2011 15:52:57 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Call for adoption as an Abfab Work item: "The Diameter ABFAB Application" X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 13:51:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, At IETF 80, the document "The Diameter ABFAB Application" was discussed. To determine whether to adopt this document as WG document, we are now doing a Call for Adoption of this document as an Abfab WG work item. The document is available for inspection here: http://tools.ietf.org/html/draft-jones-diameter-abfab-00 If you have not participated in the consensus call in the WG meeting, please read the document, and respond to this Call for Adoption by 22 April, 2011, indicating whether you favor adoption of the "The Diameter ABFAB Application" document. Klaas & Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2fEzgACgkQH2Wy/p4XeFKN/QCgoA16IW4lsqE7+ycZcBK6rpiA efgAoIqDoTsYyDQnH8hmY/A2VzHIjrOG =wiUN -----END PGP SIGNATURE----- From klaas@cisco.com Fri Apr 8 07:15:56 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB7D3A6A0B for ; Fri, 8 Apr 2011 07:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzJWjpCzkg-2 for ; Fri, 8 Apr 2011 07:15:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id F23003A690C for ; Fri, 8 Apr 2011 07:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1272; q=dns/txt; s=iport; t=1302272260; x=1303481860; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=YoD8lYPhcM+Bm1+DK4OSaJ0drpSaFxcWc9fLAfeZqfE=; b=UGGhYTb2/MSzFbi6SjQklPz296dbtQpkv82RkSmX9YF2cksNtt9y+R+0 V0VqADHVpPWqxP1p0F7cF+i5YzS43YbH3O0jqvrJnWc/uOVWMwbT8wU9j 7BijG6qw2vK8psE4fN7+4J1LsMFByFwo2QF9+LSGcS3eMYpT/UuOO1Iny k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocDAMsXn02Q/khLgWdsb2JhbACmFBQBARYmJaUhnCuFbQSNTg X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="scan'208";a="24999432" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 08 Apr 2011 14:17:39 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p38EHdII019716 for ; Fri, 8 Apr 2011 14:17:39 GMT Message-ID: <4D9F1903.2020902@cisco.com> Date: Fri, 08 Apr 2011 16:17:39 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] consensus call on split of Abfab Architecture document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 08 Apr 2011 14:15:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, We have another consensus call to make... At IETF 80, the document "ABFAB Architecture" was discussed. Strictly speaking this document is still a personal draft, so at this stage this is NOT a call for adoption as WG document. But an Abfab architecture document is part of the Abfab deliverables. At the WG meeting the authors proposed to split the document into a non-normative architecture description and an "Implementation guidelines" document. The current document is available for inspection here: http://tools.ietf.org/html/draft-lear-abfab-arch-02 If you have not participated in the consensus call in the WG meeting, please read the document, and respond to this Call for Consensus by 22 April, 2011, indicating whether you favor splitting the document in 2 separate documents (which would also result into adding an implementation guidelines document as a new deliverable for Abfab). Klaas & Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2fGQMACgkQH2Wy/p4XeFI8cQCffZkuAFjRM5uIaJd8Ve/OPvIp vYAAnRzeculZ30FK0qapxAQxxYbtD/yc =H9fG -----END PGP SIGNATURE----- From lear@cisco.com Mon Apr 11 06:27:11 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C27128C0CE for ; Mon, 11 Apr 2011 06:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIhh0IeOhm5k for ; Mon, 11 Apr 2011 06:27:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5AAF83A6B10 for ; Mon, 11 Apr 2011 06:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1316; q=dns/txt; s=iport; t=1302528431; x=1303738031; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=ILsqDRuRgF7g+7KYNT2RTJ+uHoLEgfL71boVKDDoX8c=; b=NHUHIBR33TSKDu4YUDKB7nvynqxhTQtplSnbbhcACuwcqlE656/ALM+a wsyEXVLo91AHXTFj5G2Mq35gBIos/th84avKMA94aKOmq8Z64Pq626vxv F1Gcb1Jl4jSIoyXls2QB3qwRCoxu24Avre6ZusHUHurPSXBSxTkISzIlT 0=; X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="25252770" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 11 Apr 2011 13:27:10 +0000 Received: from dhcp-10-55-95-3.cisco.com (dhcp-10-55-95-3.cisco.com [10.55.95.3]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3BDR9sB024238; Mon, 11 Apr 2011 13:27:10 GMT Message-ID: <4DA30189.9000804@cisco.com> Date: Mon, 11 Apr 2011 15:26:33 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Klaas Wierenga References: <4D9F1903.2020902@cisco.com> In-Reply-To: <4D9F1903.2020902@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] consensus call on split of Abfab Architecture document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 13:27:11 -0000 Hi Klaas, We're not quite ready for this. I think the authors took an action item to propose the split. We'll follow-up with that proposal. Eliot On 4/8/11 4:17 PM, Klaas Wierenga wrote: > Dear all, > > We have another consensus call to make... > > At IETF 80, the document "ABFAB Architecture" was discussed. > > Strictly speaking this document is still a personal draft, so at this > stage this is NOT a call for adoption as WG document. But an Abfab > architecture document is part of the Abfab deliverables. At the WG > meeting the authors proposed to split the document into a non-normative > architecture description and an "Implementation guidelines" document. > > The current document is available for inspection here: > > http://tools.ietf.org/html/draft-lear-abfab-arch-02 > > If you have not participated in the consensus call in the WG meeting, > please read the document, and respond to this Call for Consensus by 22 > April, 2011, indicating whether you favor splitting the document in 2 > separate documents (which would also result into adding an > implementation guidelines document as a new deliverable for Abfab). > > Klaas & Leif _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab From klaas@cisco.com Mon Apr 11 06:43:55 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F6943A6B17 for ; Mon, 11 Apr 2011 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-pKxMADOpl4 for ; Mon, 11 Apr 2011 06:43:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5502A3A6A18 for ; Mon, 11 Apr 2011 06:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1869; q=dns/txt; s=iport; t=1302529435; x=1303739035; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=BfAVf5EImF6NqgKyJ1/xFw1DTbC1YQxnlznpLP0Nmmk=; b=N3+MD4D9N23lcoj0UooZ8F9Hg86VKoDaLt0fl970Wkrpb7WIGsK3kFs5 yMtTX2u//QpH1vMaMzJa0wchGBpoTRXLbQx7lothQBP6F9zPaHW/EkdEI 9k2UzXudNwRX3tyozi2O/oaOgodNqCg0ORV836Ob7GT9FcsjnVKqgxn53 A=; X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="83081479" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2011 13:43:53 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3BDhrMj022934; Mon, 11 Apr 2011 13:43:53 GMT Message-ID: <4DA30599.9060701@cisco.com> Date: Mon, 11 Apr 2011 15:43:53 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Eliot Lear References: <4D9F1903.2020902@cisco.com> <4DA30189.9000804@cisco.com> In-Reply-To: <4DA30189.9000804@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] consensus call on split of Abfab Architecture document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 13:43:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/11/11 3:26 PM, Eliot Lear wrote: Hi Eliot, > We're not quite ready for this. I think the authors took an action item > to propose the split. We'll follow-up with that proposal. We did have a consensus call in the WG meeting on this, but if the authors feel it is too early still we can postpone. Klaas > > Eliot > > On 4/8/11 4:17 PM, Klaas Wierenga wrote: >> Dear all, >> >> We have another consensus call to make... >> >> At IETF 80, the document "ABFAB Architecture" was discussed. >> >> Strictly speaking this document is still a personal draft, so at this >> stage this is NOT a call for adoption as WG document. But an Abfab >> architecture document is part of the Abfab deliverables. At the WG >> meeting the authors proposed to split the document into a non-normative >> architecture description and an "Implementation guidelines" document. >> >> The current document is available for inspection here: >> >> http://tools.ietf.org/html/draft-lear-abfab-arch-02 >> >> If you have not participated in the consensus call in the WG meeting, >> please read the document, and respond to this Call for Consensus by 22 >> April, 2011, indicating whether you favor splitting the document in 2 >> separate documents (which would also result into adding an >> implementation guidelines document as a new deliverable for Abfab). >> >> Klaas & Leif > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2jBZkACgkQH2Wy/p4XeFJphQCgp/mEQ+xC5WWA2VxGdkaCcRFH goMAoIGNx1l7nRB0c+/YJ8QAacmvmgBL =+c0Y -----END PGP SIGNATURE----- From leifj@mnt.se Mon Apr 11 07:12:21 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CE528C117 for ; Mon, 11 Apr 2011 07:12:21 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fd0hZShXrem for ; Mon, 11 Apr 2011 07:12:20 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 7A16628B23E for ; Mon, 11 Apr 2011 07:12:19 -0700 (PDT) Received: from [130.240.93.191] (pub93-191.pub.luth.se [130.240.93.191]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p3BECGHM005068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 11 Apr 2011 16:12:19 +0200 (CEST) Message-ID: <4DA30C40.6040105@mnt.se> Date: Mon, 11 Apr 2011 16:12:16 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <4D9F1903.2020902@cisco.com> <4DA30189.9000804@cisco.com> <4DA30599.9060701@cisco.com> In-Reply-To: <4DA30599.9060701@cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] consensus call on split of Abfab Architecture document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 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, 11 Apr 2011 14:12:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/11/2011 03:43 PM, Klaas Wierenga wrote: > On 4/11/11 3:26 PM, Eliot Lear wrote: > > Hi Eliot, > >> We're not quite ready for this. I think the authors took an action item >> to propose the split. We'll follow-up with that proposal. > > We did have a consensus call in the WG meeting on this, but if the > authors feel it is too early still we can postpone. Yeah this isn't the consensus call to adopt the result but the consensus call to split. It was asked in the room in Prague and we (the chairs) felt it was important enough to follow up on the list. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2jDDoACgkQ8Jx8FtbMZnc9nQCfb78hPyPYt7cao9vqFda7kMcR SG8AnRQTd0L8lqaX/hBWfHRKqRuiwieU =weXr -----END PGP SIGNATURE----- From hartmans@mit.edu Thu Apr 21 06:03:40 2011 Return-Path: X-Original-To: abfab@ietfc.amsl.com Delivered-To: abfab@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 016DFE0748 for ; Thu, 21 Apr 2011 06:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD01dOi3MmFq for ; Thu, 21 Apr 2011 06:03:39 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id 6FAD6E071E for ; Thu, 21 Apr 2011 06:03:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 362F6203A2 for ; Thu, 21 Apr 2011 09:00:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8E3654541; Thu, 21 Apr 2011 09:03:32 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org References: Date: Thu, 21 Apr 2011 09:03:32 -0400 In-Reply-To: (Sam Hartman's message of "Thu, 31 Mar 2011 08:01:33 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [abfab] Message Integrity for gss-eap 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, 21 Apr 2011 13:03:40 -0000 I'd like to circle back to this conversation. I don't think there seemed to be any clear winners on the technical front. As a comment to Luke, in your comment that RFC 3961 implies a hash function with the mandatory to implement checksum, that's not really true. It happens to be true for the existing enctypes we care about. However an enctype could use a CBC-MAC (or other modern crypto-based MAC) which cannot work at all without a key and for which you cannot perform the iteration prior to the key. So, if we go with the just use a hash option, we do need to negotiate it in our OID at least sometimes. The one option I don't have a good understanding of is the option where we expect extensions to offer a MIC themselves. In this option, each extension token needs to provide any needed protection itself. There is no protection for the conversation as an aggregate; only its parts. This can provide the same level of security; it just makes our job in the IETF harder in terms of doing security review. I'd like to ask some questions: 1) Are we willing to tightly control what extension tokens their are? I.E. do we think standards action or IETF review are appropriate registration policies for extensions? 2) What extensions needing MICs have we identified? Is the mutual flag the only one? We'd presumably also need protection of removed extensions; we could MIC a list of token types sent. --Sam 3) It's my belief that if we protect against removed extension tokens, we can add a conversation level finish message later if we wish. If we chose to do so in a backward compatible way, then we would not be able to have a hash function identifier in the OID. We could have a hash function in the extension token identifier though. Can I get people who understand the technical details in sufficient detail to sanity check me here and confirm that we could add conversation-level protection later if we chose? Thanks, --Sam From lukeh@padl.com Thu Apr 21 09:58:26 2011 Return-Path: X-Original-To: abfab@ietfc.amsl.com Delivered-To: abfab@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C7215E07F6 for ; Thu, 21 Apr 2011 09:58:26 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdHYelnq8L8d for ; Thu, 21 Apr 2011 09:58:26 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfc.amsl.com (Postfix) with ESMTP id 945D1E081A for ; Thu, 21 Apr 2011 09:58:08 -0700 (PDT) Received: by us.padl.com with ESMTP id p3LGvvSU001961; Thu, 21 Apr 2011 12:58:01 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 21 Apr 2011 18:57:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <598858A8-1415-472D-9EE1-117F12349D14@padl.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,FH_HOST_EQ_DYNAMICIP,RCVD_IN_PBL,RDNS_DYNAMIC X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: 0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap 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, 21 Apr 2011 16:58:27 -0000 > 2) What extensions needing MICs have we identified? > Is the mutual flag the only one? * Server name indication * Channel bindings (if we were to send the bindings themselves = unprotected -- not that I'm suggesting that's something we wish to do) In the future, possibly: * Extension type negotiation -- Luke= From jimsch@nwlink.com Thu Apr 21 13:23:19 2011 Return-Path: X-Original-To: abfab@ietfc.amsl.com Delivered-To: abfab@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DE91EE07C7 for ; Thu, 21 Apr 2011 13:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJaSxNtXRhtq for ; Thu, 21 Apr 2011 13:23:18 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfc.amsl.com (Postfix) with ESMTP id 76066E06B9 for ; Thu, 21 Apr 2011 13:23:18 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.pacifier.net (Postfix) with ESMTP id C7D2E6EF63; Thu, 21 Apr 2011 13:23:16 -0700 (PDT) From: "James Schaad" To: , "'Eliot Lear'" Date: Thu, 21 Apr 2011 13:49:15 -0700 Message-ID: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcvzB86PKHuxk61lTvG3EuPqeo+vkQ== Content-Language: en-us X-Mailman-Approved-At: Thu, 21 Apr 2011 13:25:52 -0700 Subject: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 20:23:20 -0000 I do not seem to be getting this finished -- so I will send it as is. Let's get you an updated second round of comments. I should probably go through my last list at some time and see how many were addressed, but I haven't done that yet. I might get some duplication from that list as I haven't read it in a while. 1. Introduction para 3 - I want to make sure that your definition of federation is one that you want to make. Specifically it would appear that there can be federations even within a single entity in the event that actor providing the identity information is not the same as the RP. Would you consider a single Kerberos or Windows enterprise to be a federation. In these cases the IdP being the login service and the RP being somebody granting access to a resource (in windows possibly by an RPC). I generally think of federation as being between two different entities rather than within a single entity but using multiple servers. 2. para 'Provisioning' s/subject that an/subject than an/ s/by by/by/ 3. Section 1.1 - I am still AAA challenged. Is it more correct to say 'a radius or diameter server'? Do you want to put in a generalized statement that says you use radius but it also applies to diameter? 4. Section 1.2 - s/Some deployments are sometimes required/Some deployments are required/ or /Deployments are sometimes required/ 5. s/betweem/between/ 6. Next to last paragraph - However, federation does not preclude the possibility of a pre-existing relationship existing between the RP and the Subject, nor that they may use the introduction to create a new long-term relationship independent of the federation. 7. Section 1.3 - kill the word such s/number of such federated/number of federated/ s/has become/can become/ 8. s/For example, a school might provide online access to grades to a parent who is also a teacher. She must clearly distinguish her role upon access./For example, a school might provide online access to a student's grades to their parents for review, and to the student's teacher for modifying the grades. A teacher who is also a parent must clearly distinguish here role upon access./ 9. next para - s/identity provider a user/identity provider(s) a user/ s/latter ans/latter as/ 10. Possible issue to include here. In the presence of multiple federations, the naming of individuals can become murky especially if one is trying to associate a single individual from different federations. Asking a question such as does John Doe belong to an IdP (in the absence of authentication) may get an answer for the wrong John Doe. 11. Section 1.4 - Overview a) I think you might need to have a step 2a - Client Application creates a channel to the RP. This is not done by the GSS-EAP mechanism as I had originally assumed. Let's make it clear additionally that fact will be needed in order to setup the channel binding at a later time. Note that at some point there will need to be a discussion of the properties of this channel. It should also be noted that the type of channel used potentially provide different issues. b) in step 5 either /forward a RADIUS request/ or /forward RADIUS requests/. AAA ignorance - would message be better than request to avoid confusion between RADISU request and GSS/EAP request? - I would ignore how the SAML request is encoded at this point. So maybe s/SAML request as a series of attributes/ SAML request for a set of attributes/ s/.././ c) request that you go back and use subject rather than principal in this section. The change in terminology is not introduced. d) in step 9, I think I have a problem with the last sentence. These policy checks would have been done by the AAA system or the RP and not by the IdP. As such I don't think the title for the paragraph makes sense. e) Step 10, Do we need to be explicit that the MSK return must be encrypted somehow? Based on the conversations last week there appears to be a problem in that while RADIUS has the ability to return encrypted responses, it is not native to Diameter. Also does this need to be a new attribute or does the attribute already exist (in both systems). Is the sentence at the end of the paragraph wrong? Is it returned to the subject (not covered by the title) or the RP? The subject should already have the MSK f) I don't understand part of step 11 -- It may have information that leads it to make additional attribute queries. I can see it needing to make additional attributes because it needs more information, but not because it has the information it needs. 12. In your diagram, the (11) should be in the RP column. 13. Section 2 - What is this "end host" that is referred to in the second paragraph? Is this the IdP, the subject or some new entity. - Getting all of these names straight without having a glossary is going to kill me eventually.'' s/connumication/communication/ 14. Section 2.1.1 - discovery --- I don't know that I don't have a slight problem with the first sentence in this section. If you are going to tell me that I need to properly identify the end points of the communication, then I want to see more details on what is considered to be proper here. For one thing, I assume that this identification is only true as far as the AAA substrate is concerned. This means that asking for a service at a realm would be considered to be sufficient as oppose to having to know who is providing the service. (i.e. I want some IdP@janice.edu as oppose to a specific one. It might be that additional restrictions are required for a type of idp, but that is not covered here.). How much of the rules determination is to be done by the RP and how much by the AAA substrate? Looking at para 3 - I am wondering if sentence two should be stated as "One of these is whether the given RP is permitted to rely on the IDP using a given federation at all,...". The question is one of does the RP trust the IdP as oppose to does the IdP allow the RP to talk to it. The rules determination is going to be done differently for the two sides. For the AAA Proxy - the last sentence needs to be motivated. I can see flooding routing information but the reason for doing name constraints escapes me at the moment. s/support e Simple/support the Simple/ 15. Section 2.3 - Application to Service -- This section discusses the use of GSS-API, however I believe that it also needs to include a discussion of the channel that is to be used between the application and the server as this is not an implicit part of the GSS-API system. This channel may have some specific requirements that need to be discussed as well. 16. Section 2.4 - I don't understand the title of this section. What does this have to do with personalization? Perhaps Attribute or similar word would be better than personalization. A look forward in this section to the one on privacy might be indicated as this would be a good location to talk about the issues of what information should be released from the IdP to the RP and how much it should be under the control of the federation agreement and how much under the control the subject. 17. Section 2.5 - what happened to the text in this section? 18. Should the section on privacy - i.e. talking about privacy, untraceability, anonymity and so forth be part of section 2? I think that discussion this in the context of the architecture and what the requirements on each section of the architecture are going to be makes sense to me. 19 - section 3.1 - I would suggest a new title as it would be good to suggest who is being mutually authenticated -- yet another name for somebody - who are the initiator and the acceptor Please expand on the difference between bullets 1 and 2 in this section. It appears to me that the first sentence in both sections are saying the same thing - that the initiator trusts that the name it has given for the target name/acceptor correctly names and describes the acceptor. If there is a difference in these concepts I for one don't understand it from the text. 20 - section 3.3 - In the next to last paragraph, would host names work better in the case that secure SRV records w/ DNSSEC are used? I also do not understand how to resolve the decision in paragraph two to say we need to use realm names, but the last paragraph says that we need to support host-based service names. How am I supposed to reconcile these differences. Also does it make a difference in how the channel to the service is created? I.e. it makes much more sense to use host-based server names if one is using TLS as the channel between the application and the channel, but how the RP decides which IdP or federation to use is not going to be based on host-based service names. I guess part of my question is going to be is naming different for the RP (from the point of view of the client) as oppose to the naming of other entities in the system. 21 - Section 3.4 - I need to have an idea of what entities are going to be using the GSS-API per-message security services. There is a difference in how I think about this if this is done between the subject and the RP as oppose to between the RP and the IdP or the subject and the IdP. I also need to come to grips with how many different MSKs are going to be generated in this system. I don't have a good idea of this from this section. From hartmans@painless-security.com Thu Apr 21 14:07:19 2011 Return-Path: X-Original-To: abfab@ietfc.amsl.com Delivered-To: abfab@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C6AF2E070C for ; Thu, 21 Apr 2011 14:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZMRD+H1fcwN for ; Thu, 21 Apr 2011 14:07:19 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id 57BF8E0704 for ; Thu, 21 Apr 2011 14:07:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0580A20465; Thu, 21 Apr 2011 17:03:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 72F2F4541; Thu, 21 Apr 2011 17:07:13 -0400 (EDT) From: Sam Hartman To: "James Schaad" References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> Date: Thu, 21 Apr 2011 17:07:13 -0400 In-Reply-To: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> (James Schaad's message of "Thu, 21 Apr 2011 13:49:15 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, 'Eliot Lear' Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 21:07:19 -0000 I wonder if we can just refer to RFC 2743 for the requirements for the channel between subject and RP? --Sam From ietf@augustcellars.com Thu Apr 21 17:21:56 2011 Return-Path: X-Original-To: abfab@ietfc.amsl.com Delivered-To: abfab@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CE9F5E065C for ; Thu, 21 Apr 2011 17:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TrJyF3LdNi5 for ; Thu, 21 Apr 2011 17:21:56 -0700 (PDT) Received: from new-smtp02.pacifier.net (new-smtp02.pacifier.net [64.255.237.176]) by ietfc.amsl.com (Postfix) with ESMTP id 3E13EE06C4 for ; Thu, 21 Apr 2011 17:21:56 -0700 (PDT) Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp02.pacifier.net (Postfix) with ESMTPSA id 829282CA61; Thu, 21 Apr 2011 17:21:55 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Thu, 21 Apr 2011 17:47:49 -0700 Message-ID: <009801cc0086$eac839f0$c058add0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJAiuFiW86lPJ1g5ikpOXRYnWUepgLlgQBDAb4gyWMCfdgFQpNG1k1g Content-Language: en-us Subject: Re: [abfab] Message Integrity for gss-eap 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, 22 Apr 2011 00:21:56 -0000 > I'd like to ask some questions: > > 1) Are we willing to tightly control what extension tokens their are? > I.E. do we think standards action or IETF review are appropriate registration > policies for extensions? > > 2) What extensions needing MICs have we identified? > Is the mutual flag the only one? > We'd presumably also need protection of removed extensions; we could > MIC a list of token types sent. Some type of extension that allows for validation of external negotiation (i.e. what I send to the RP before setting up the gss-eap session)? > > --Sam > > 3) It's my belief that if we protect against removed extension tokens, we can > add a conversation level finish message later if we wish. If we chose to do so > in a backward compatible way, then we would not be able to have a hash > function identifier in the OID. > We could have a hash function in the extension token identifier though. > Can I get people who understand the technical details in sufficient detail to > sanity check me here and confirm that we could add conversation-level > protection later if we chose? > > Thanks, > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu Apr 21 17:31:26 2011 Return-Path: X-Original-To: abfab@ietfc.amsl.com Delivered-To: abfab@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AD901E0675 for ; Thu, 21 Apr 2011 17:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.987 X-Spam-Level: X-Spam-Status: No, score=-2.987 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpovuwm0LyLW for ; Thu, 21 Apr 2011 17:31:26 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfc.amsl.com (Postfix) with ESMTP id 2E8AEE065C for ; Thu, 21 Apr 2011 17:31:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B31CA20228; Thu, 21 Apr 2011 20:27:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D840F4541; Thu, 21 Apr 2011 20:31:16 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <009801cc0086$eac839f0$c058add0$@augustcellars.com> Date: Thu, 21 Apr 2011 20:31:16 -0400 In-Reply-To: <009801cc0086$eac839f0$c058add0$@augustcellars.com> (Jim Schaad's message of "Thu, 21 Apr 2011 17:47:49 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap 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, 22 Apr 2011 00:31:26 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Some type of extension that allows for validation of external Jim> negotiation (i.e. what I send to the RP before setting up the Jim> gss-eap session)? You can fold that into channel bindings if you like. If you want something more than channel bindings I'm not aware of anything that GSS-API gives you. I think there are a lot of reasons we should not support things that GSS cannot do in our GSS mechanism. From klaas@cisco.com Tue Apr 26 00:57:19 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AECE070F for ; Tue, 26 Apr 2011 00:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18oEwg32mSoS for ; Tue, 26 Apr 2011 00:57:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C3E0701 for ; Tue, 26 Apr 2011 00:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=910; q=dns/txt; s=iport; t=1303804638; x=1305014238; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=mfXYpoMorQSHvr/poScnjyYAnvLtPHcxnfUFMngISe0=; b=BgEn8x17p2I2jQELIms9CdSkTqZBaeu3duzXzFrXmHTTqbS3vzpmV/wb yZX6FTXKar6ceitaLSMVRrPnufRJ/akAzZ4RG8JJeB3xXFE4ykx6CU3sr MEEcyeEg5BLMu3UCHG5P3iZ82gphBBMcUY5hb71VZactuuuF9ik/pslQW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACx6tk2rRDoG/2dsb2JhbAClQXeoSJ0fhXYEjj+OIg X-IronPort-AV: E=Sophos;i="4.64,267,1301875200"; d="scan'208";a="301988822" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-3.cisco.com with ESMTP; 26 Apr 2011 07:57:18 +0000 Received: from macmini.wierenga.net (sjc-vpnasa-491.cisco.com [10.21.105.237]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3Q7vHNh008253 for ; Tue, 26 Apr 2011 07:57:17 GMT Message-ID: <4DB67ADC.3060409@cisco.com> Date: Tue, 26 Apr 2011 09:57:16 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] outcome consensus calls 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, 26 Apr 2011 07:57:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We had 2 calls for consensus ending April 22: To accept "The Diameter ABFAB Application" (http://tools.ietf.org/html/draft-jones-diameter-abfab-00) as WG document and A proposal to split of "ABFAB Architecture" (http://tools.ietf.org/html/draft-lear-abfab-arch-02) into a non-normative architecture description and an "Implementation guidelines" document prior to putting it up as WG document. There have been no responses to the list. Whick means that the consensus established at the WG meeting (both proposals in favor) stands. Cheers, Klaas & Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk22etwACgkQH2Wy/p4XeFL3VACeM/LlQQTD8XOJQl/ftRmbLlmZ vjwAnimsLWyn+Hc5S93HrpK3WBc/2tVz =XP6p -----END PGP SIGNATURE----- From hartmans@painless-security.com Tue Apr 26 02:09:56 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F42E06A1 for ; Tue, 26 Apr 2011 02:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.432 X-Spam-Level: X-Spam-Status: No, score=-4.432 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YeoHHaad3CW for ; Tue, 26 Apr 2011 02:09:54 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 25A54E0676 for ; Tue, 26 Apr 2011 02:09:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6DCD920239; Tue, 26 Apr 2011 05:06:11 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F0A4B478C; Tue, 26 Apr 2011 05:09:32 -0400 (EDT) From: Sam Hartman To: "James Schaad" References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> Date: Tue, 26 Apr 2011 05:09:32 -0400 In-Reply-To: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> (James Schaad's message of "Thu, 21 Apr 2011 13:49:15 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org, 'Eliot Lear' Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2011 09:09:56 -0000 >>>>> "James" == James Schaad writes: James> 1. Introduction para 3 - I want to make sure that your James> definition of federation is one that you want to make. James> Specifically it would appear that there can be federations James> even within a single entity in the event that actor providing James> the identity information is not the same as the RP. Would James> you consider a single Kerberos or Windows enterprise to be a James> federation. In these cases the IdP being the login service James> and the RP being somebody granting access to a resource (in James> windows possibly by an RPC). I generally think of federation James> as being between two different entities rather than within a James> single entity but using multiple servers. I tend to agree with you that a lot of problems show up in the cross-organization case. I think it's important to make it clear we're signing up to that and a solution working within a single organization is not sufficient. I also think it would be honest to indicate we're optimizing for the cross organization case. I don't think we should forbid our technology being used within a single organization nor ignore concerns that happen when that is done. What are your thoughts? James> 3. Section 1.1 - I am still AAA challenged. Is it more James> correct to say 'a radius or diameter server'? Do you want to James> put in a generalized statement that says you use radius but James> it also applies to diameter? We're using RADIUS for the example here. Project Moonshot is only focusing on RADIUS, but ABFAB needs to be/people are working on making it technology neutral. We should clarify in the doc if is this not clear. (And obviously there is no need to mention Moonshot's implementation choices at all in the doc.) James> 10. Possible issue to include here. In the presence of James> multiple federations, the naming of individuals can become James> murky especially if one is trying to associate a single James> individual from different federations. Asking a question James> such as does John Doe belong to an IdP (in the absence of James> authentication) may get an answer for the wrong John Doe. Yes. This is worth mentioning in my opinion. James> 11. Section 1.4 - Overview a) I think you might need to have James> a step 2a - Client Application creates a channel to the RP. James> This is not done by the GSS-EAP mechanism as I had originally James> assumed. Let's make it clear additionally that fact will be James> needed in order to setup the channel binding at a later time. James> b) in step 5 either /forward a RADIUS request/ or /forward James> RADIUS requests/. AAA ignorance - would message be better James> than request to avoid confusion between RADISU request and James> GSS/EAP request? - I think RADIUS message would be OK. The particular type of message is called a request, but we don't need to say that. James> I would ignore how the SAML request is James> encoded at this point. So maybe s/SAML request as a series James> of attributes/ SAML request for a set of attributes/ s/.././ I'd personally just leave it as SAML request. After talking to Rhys and Josh about what you can and cannot do with various types of SAML requests it is better not to get into details here. James> c) request that you go back and use subject rather than James> principal in this section. The change in terminology is not James> introduced. OK. James> d) in step 9, I think I have a problem with the last James> sentence. These policy checks would have been done by the James> AAA system or the RP and not by the IdP. As such I don't James> think the title for the paragraph makes sense. No, I think the IDP makes these checks as well. Consider the PLASMA example. An IDP may well know exactly who its organization permits to be a PLASMA policy point and may forbid others from providing that service. Some IDPs will have very open policy here; some will not. I agree that the AAA and RP may also apply policy. James> e) Step 10, Do we need to be explicit that the MSK return James> must be encrypted somehow? Based on the conversations last James> week there appears to be a problem in that while RADIUS has James> the ability to return encrypted responses, it is not native James> to Diameter. Also does this need to be a new attribute or James> does the attribute already exist (in both systems). AAA keywrap is probably not something we want to go into here. There are a lot of AAA deployments where the attribute is not encrypted at all. I think in our mechanism document we want to make support for encryption mandatory in the GSS acceptor. I think our BCPs we definitely want to make support for implementing this attribute mandatory. I don't think we want to go into that detail here, although if someone provided text discussing the issue for elsewhere in the document that would be good. James> Is the James> sentence at the end of the paragraph wrong? Is it returned James> to the subject (not covered by the title) or the RP? The James> subject should already have the MSK Here it is returned to the RP; the subject definitely already has it. James> f) I don't understand part of step 11 -- It may have James> information that leads it to make additional attribute James> queries. I can see it needing to make additional attributes James> because it needs more information, but not because it has the James> information it needs. I agree with your confusion but don't know what was intended here. James> 13. Section 2 - What is this "end host" that is referred to James> in the second paragraph? Is this the IdP, the subject or James> some new entity. - Getting all of these names straight James> without having a glossary is going to kill me eventually.'' The subject. I think end-host probably wants to get collapsed into subject. James> s/connumication/communication/ James> 14. Section 2.1.1 - discovery --- I don't know that I don't James> have a slight problem with the first sentence in this James> section. If you are going to tell me that I need to properly James> identify the end points of the communication, James> then I want to James> see more details on what is considered to be proper here. James> For one thing, I assume that this identification is only true James> as far as the AAA substrate is concerned. This means that James> asking for a service at a realm would be considered to be James> sufficient as oppose to having to know who is providing the James> service. (i.e. I want some IdP@janice.edu as oppose to a James> specific one. It might be that additional restrictions are James> required for a type of idp, but that is not covered here.). The following sentences attempt to clarify. The realm portion of a NAI identifies a conceptual endpoint for sending a request in AAA. Identifying the endpoint making the request is more complex; how that is handled kind of depends on the specific technical trust mechanism in play. James> How much of the rules determination is to be done by the RP James> and how much by the AAA substrate? This is probably an implementation detail. An RP that has multiple places it can start in the AAA substrate needs to pick one. However conceptually you can think of that combination as an RP plus AAA proxy (possibly all within one process) so I think this is an implementation matter. James> Looking at para 3 - I am wondering if sentence two should be James> stated as "One of these is whether the given RP is permitted James> to rely on the IDP using a given federation at all,...". The James> question is one of does the RP trust the IdP as oppose to James> does the IdP allow the RP to talk to it. The rules James> determination is going to be done differently for the two James> sides. I think either party can decide not to talk to the other party. The use case motivating that sentence was explicitly a case where an IDP was selective in what RPs it permitted and where a federation did not allow all RPs to talk to all IDPs, not the case where the RP had a trust decision to make. Obviously, though, both parties may need to decide something. James> For the AAA Proxy - the last sentence needs to be motivated. James> I can see flooding routing information but the reason for James> doing name constraints escapes me at the moment. Routing information in an AAA fabric is effectively name constraints in both directions. "This way for FOO.COM!" "Messages coming from that direction can claim RPs in realms A, B, C and D!" James> 15. Section 2.3 - Application to Service -- This section James> discusses the use of GSS-API, however I believe that it also James> needs to include a discussion of the channel that is to be James> used between the application and the server as this is not an James> implicit part of the GSS-API system. This channel may have James> some specific requirements that need to be discussed as well. I'd really need to see text here, because I don't know what we'd want to say about the channel. James> 16. Section 2.4 - I don't understand the title of this James> section. What does this have to do with personalization? James> Perhaps Attribute or similar word would be better than James> personalization. A look forward in this section to the one James> on privacy might be indicated as this would be a good James> location to talk about the issues of what information should James> be released from the IdP to the RP and how much it should be James> under the control of the federation agreement and how much James> under the control the subject. I would be fine with both of these changes. James> 17. Section 2.5 - what happened to the text in this section? I don't know. Did it ever have text? James> 19 - section 3.1 - I would suggest a new title as it would be James> good to suggest who is being mutually authenticated -- yet James> another name for somebody - who are the initiator and the James> acceptor Section 3 is all about GSS-API, which only has two endpoints, so I don't see any other options than these two endpoints. initiator is the GSS name for subject; acceptor is the GSS name for RP. James> Please expand on the difference between bullets 1 and 2 in James> this section. It appears to me that the first sentence in James> both sections are saying the same thing - that the initiator James> trusts that the name it has given for the target James> name/acceptor correctly names and describes the acceptor. If James> there is a difference in these concepts I for one don't James> understand it from the text. The second bullet covers the case where the initiator does not supply a target name. I'd be happy to add a sentence to the second bullet that the second bullet is a subset of the first when a target name is provided or otherwise clarify. James> 20 - section 3.3 - In the next to last paragraph, would host James> names work better in the case that secure SRV records w/ James> DNSSEC are used? If you were willing to trust DNS both on the initiator and the RP and do some work on how applications handle these names, you could improve the situation. To me, it seems a big assumption to assume that your application authentication trust and your DNS trust are aligned, especially when you'd need to make that assumptions on both sides of a federation. It's true sometimes and possibly enough of the time to support, but not enough of the time to rely on. James> I also do not understand how to resolve the James> decision in paragraph two to say we need to use realm names, James> but the last paragraph says that we need to support James> host-based service names. How am I supposed to reconcile James> these differences. Putting hosts into a realms is a mechanism for more easily supporting host names. There is more detail on this in the actual mechanism document. James> Also does it make a difference in how the James> channel to the service is created? I.e. it makes much more James> sense to use host-based server names if one is using TLS as James> the channel between the application and the channel, but how James> the RP decides which IdP or federation to use is not going to James> be based on host-based service names. I guess part of my James> question is going to be is naming different for the RP (from James> the point of view of the client) as oppose to the naming of James> other entities in the system. This section is discussing support for host-based names of GSS acceptors. At least as described currently an IDP is not a GSS acceptor. In the KMP presentation we gave in Prague, we proposed creating a GSS acceptor service associated with an IDP, but that is not discussed at all in this document. James> 21 - Section 3.4 - I need to have an idea of what entities James> are going to be using the GSS-API per-message security James> services. There is a difference in how I think about this if James> this is done between the subject and the RP as oppose to James> between the RP and the IdP or the subject and the IdP. I James> also need to come to grips with how many different MSKs are James> going to be generated in this system. I don't have a good James> idea of this from this section. GSS initiator and acceptor use the per-message services. I.E. the IDP and RP. Only one MSK in the entire system. James> _______________________________________________ abfab mailing James> list abfab@ietf.org James> https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Tue Apr 26 20:46:31 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEE2E0686 for ; Tue, 26 Apr 2011 20:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdxkhtkKrDCD for ; Tue, 26 Apr 2011 20:46:31 -0700 (PDT) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8775EE0685 for ; Tue, 26 Apr 2011 20:46:31 -0700 (PDT) Received: from TITUS (50-39-220-175.bvtn.or.frontiernet.net [50.39.220.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by new-smtp01.pacifier.net (Postfix) with ESMTPSA id 47DA02CA4F; Tue, 26 Apr 2011 20:46:31 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <009801cc0086$eac839f0$c058add0$@augustcellars.com> In-Reply-To: Date: Tue, 26 Apr 2011 21:12:41 -0700 Message-ID: <009501cc0491$5acff950$106febf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJAiuFiW86lPJ1g5ikpOXRYnWUepgLlgQBDAb4gyWMCfdgFQgGRby29AdaksMiTM8BnYA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap 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, 27 Apr 2011 03:46:32 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Thursday, April 21, 2011 5:31 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Message Integrity for gss-eap > > >>>>> "Jim" == Jim Schaad writes: > > > Jim> Some type of extension that allows for validation of external > Jim> negotiation (i.e. what I send to the RP before setting up the > Jim> gss-eap session)? > > You can fold that into channel bindings if you like. > If you want something more than channel bindings I'm not aware of anything > that GSS-API gives you. > > I think there are a lot of reasons we should not support things that GSS > cannot do in our GSS mechanism I was not sure if this would be the type of thing that you wanted to put in as an extension or not. Jim . From jimsch@nwlink.com Tue Apr 26 21:38:55 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28665E069C for ; Tue, 26 Apr 2011 21:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bVtzD+A2cLP for ; Tue, 26 Apr 2011 21:38:53 -0700 (PDT) Received: from new-smtp01.pacifier.net (new-smtp01.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 27C61E0690 for ; Tue, 26 Apr 2011 21:38:52 -0700 (PDT) Received: from TITUS (50-39-220-175.bvtn.or.frontiernet.net [50.39.220.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by new-smtp01.pacifier.net (Postfix) with ESMTPS id E9C2D2CA3C; Tue, 26 Apr 2011 21:38:51 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> In-Reply-To: Date: Tue, 26 Apr 2011 22:05:01 -0700 Message-ID: <009601cc0498$aad5f330$0081d990$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI0AuynjYFFecPcDkHdzLf/dRaImAHIzFAvk5LWnpA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 04:38:55 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Tuesday, April 26, 2011 2:10 AM > To: James Schaad > Cc: abfab@ietf.org; 'Eliot Lear' > Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 > > >>>>> "James" == James Schaad writes: > > > James> 1. Introduction para 3 - I want to make sure that your > James> definition of federation is one that you want to make. > James> Specifically it would appear that there can be federations > James> even within a single entity in the event that actor providing > James> the identity information is not the same as the RP. Would > James> you consider a single Kerberos or Windows enterprise to be a > James> federation. In these cases the IdP being the login service > James> and the RP being somebody granting access to a resource (in > James> windows possibly by an RPC). I generally think of federation > James> as being between two different entities rather than within a > James> single entity but using multiple servers. > > I tend to agree with you that a lot of problems show up in the cross- > organization case. I think it's important to make it clear we're signing up to > that and a solution working within a single organization is not sufficient. I also > think it would be honest to indicate we're optimizing for the cross > organization case. I don't think we should forbid our technology being used > within a single organization nor ignore concerns that happen when that is > done. What are your thoughts? > I don't have a problem with a focus on cross-organization cases, I think that is where this document should be focused. I was actually trying to drive at the question of the definition of what a 'federation' was and trying to determine if the one given was both a good one and a viable one. That is a federation is a relationship that defines 'technical signaling, trust and a common understanding of semantics between the RP and IdP'. Nothing in this definition rules out federation within an organization. In that case the second two element should be easy leaving only the first as a problem. The question was more one of is the definition as given potentially so broad as to eliminate, for some people, the concept that a single organization has the elements of a federation within it. The comment was more intended to make you think that to say what is there is wrong. > > James> 3. Section 1.1 - I am still AAA challenged. Is it more > James> correct to say 'a radius or diameter server'? Do you want to > James> put in a generalized statement that says you use radius but > James> it also applies to diameter? > > We're using RADIUS for the example here. Project Moonshot is only > focusing on RADIUS, but ABFAB needs to be/people are working on making it > technology neutral. > We should clarify in the doc if is this not clear. > (And obviously there is no need to mention Moonshot's implementation > choices at all in the doc.) No - you have defined the components of an IdP and did not include Diameter as an option. I think that it needs to be included as part of what an IdP consists of. I think that it would be perfectly acceptable to put a paragraph in here that says "In all places where Radius is used, Diameter could also be used unless otherwise stated." > James> 10. Possible issue to include here. In the presence of > James> multiple federations, the naming of individuals can become > James> murky especially if one is trying to associate a single > James> individual from different federations. Asking a question > James> such as does John Doe belong to an IdP (in the absence of > James> authentication) may get an answer for the wrong John Doe. > > Yes. > This is worth mentioning in my opinion. > > James> 11. Section 1.4 - Overview a) I think you might need to have > James> a step 2a - Client Application creates a channel to the RP. > James> This is not done by the GSS-EAP mechanism as I had originally > James> assumed. Let's make it clear additionally that fact will be > James> needed in order to setup the channel binding at a later time. > > James> b) in step 5 either /forward a RADIUS request/ or /forward > James> RADIUS requests/. AAA ignorance - would message be better > James> than request to avoid confusion between RADISU request and > James> GSS/EAP request? - > > I think RADIUS message would be OK. The particular type of message is called > a request, but we don't need to say that. Please change just to eliminate the redundancy. After re-reading this paragraph I think that the term forward should be replaced with send. The RP 'sends' rather than 'forwards' the RADIUS message as it conceptually creates the RADIUS request for the IdP. > > James> I would ignore how the SAML request is > James> encoded at this point. So maybe s/SAML request as a series > James> of attributes/ SAML request for a set of attributes/ s/.././ > > I'd personally just leave it as SAML request. > After talking to Rhys and Josh about what you can and cannot do with various > types of SAML requests it is better not to get into details here. I agree - better is s/SAML request as a series of attributes/SAML request/ > > James> c) request that you go back and use subject rather than > James> principal in this section. The change in terminology is not > James> introduced. > > OK. > > James> d) in step 9, I think I have a problem with the last > James> sentence. These policy checks would have been done by the > James> AAA system or the RP and not by the IdP. As such I don't > James> think the title for the paragraph makes sense. > No, I think the IDP makes these checks as well. I am not saying that the IdP does not make the policy checks. I am referring to the "Additional policy checks" in the last sentence. Including this here rather than in the discovery process makes the paragraph title problematic. However I do not need a change here. > > Consider the PLASMA example. > An IDP may well know exactly who its organization permits to be a PLASMA > policy point and may forbid others from providing that service. > Some IDPs will have very open policy here; some will not. > > I agree that the AAA and RP may also apply policy. > > > James> e) Step 10, Do we need to be explicit that the MSK return > James> must be encrypted somehow? Based on the conversations last > James> week there appears to be a problem in that while RADIUS has > James> the ability to return encrypted responses, it is not native > James> to Diameter. Also does this need to be a new attribute or > James> does the attribute already exist (in both systems). > > AAA keywrap is probably not something we want to go into here. > There are a lot of AAA deployments where the attribute is not encrypted at > all. > I think in our mechanism document we want to make support for encryption > mandatory in the GSS acceptor. I think our BCPs we definitely want to make > support for implementing this attribute mandatory. > I don't think we want to go into that detail here, although if someone > provided text discussing the issue for elsewhere in the document that would > be good. I can live with this not being covered. It may want to go into something marked security considerations just to make sure it is not lost. How the encryption is done is going to be highly variable, in that I agree. > > James> Is the > James> sentence at the end of the paragraph wrong? Is it returned > James> to the subject (not covered by the title) or the RP? The > James> subject should already have the MSK > > Here it is returned to the RP; the subject definitely already has it. > > James> f) I don't understand part of step 11 -- It may have > James> information that leads it to make additional attribute > James> queries. I can see it needing to make additional attributes > James> because it needs more information, but not because it has the > James> information it needs. > I agree with your confusion but don't know what was intended here. > > James> 13. Section 2 - What is this "end host" that is referred to > James> in the second paragraph? Is this the IdP, the subject or > James> some new entity. - Getting all of these names straight > James> without having a glossary is going to kill me eventually.'' > > The subject. > I think end-host probably wants to get collapsed into subject. Sounds good. As stated the fact that there are multiple names but not a table of those names in the different protocols is confusing. Actually adding that table would probably be both an interesting exercise as well as making a good single point of reference. > > James> s/connumication/communication/ > > James> 14. Section 2.1.1 - discovery --- I don't know that I don't > James> have a slight problem with the first sentence in this > James> section. If you are going to tell me that I need to properly > James> identify the end points of the communication, > James> then I want to > James> see more details on what is considered to be proper here. > James> For one thing, I assume that this identification is only true > James> as far as the AAA substrate is concerned. This means that > James> asking for a service at a realm would be considered to be > James> sufficient as oppose to having to know who is providing the > James> service. (i.e. I want some IdP@janice.edu as oppose to a > James> specific one. It might be that additional restrictions are > James> required for a type of idp, but that is not covered here.). > > The following sentences attempt to clarify. > The realm portion of a NAI identifies a conceptual endpoint for sending a > request in AAA. > Identifying the endpoint making the request is more complex; how that is > handled kind of depends on the specific technical trust mechanism in play. > Yes I think that flows better. > > James> How much of the rules determination is to be done by the RP > James> and how much by the AAA substrate? > > This is probably an implementation detail. > An RP that has multiple places it can start in the AAA substrate needs to pick > one. > However conceptually you can think of that combination as an RP plus AAA > proxy (possibly all within one process) so I think this is an implementation > matter. I agree that it does not need to be covered in this case. > > James> Looking at para 3 - I am wondering if sentence two should be > James> stated as "One of these is whether the given RP is permitted > James> to rely on the IDP using a given federation at all,...". The > James> question is one of does the RP trust the IdP as oppose to > James> does the IdP allow the RP to talk to it. The rules > James> determination is going to be done differently for the two > James> sides. > > I think either party can decide not to talk to the other party. > The use case motivating that sentence was explicitly a case where an IDP was > selective in what RPs it permitted and where a federation did not allow all > RPs to talk to all IDPs, not the case where the RP had a trust decision to > make. > Obviously, though, both parties may need to decide something. >From the text in place, I think that it states just the opposite. I.e. can an RP rely on the IdP. I would assume that the IdP would actually do its own rules determination rather than rely on anything supplied by the RP except as one input to the IdP rules determination process. A such the rules used by the IdP are covered elsewhere? > > James> For the AAA Proxy - the last sentence needs to be motivated. > James> I can see flooding routing information but the reason for > James> doing name constraints escapes me at the moment. > > Routing information in an AAA fabric is effectively name constraints in both > directions. "This way for FOO.COM!" "Messages coming from that direction > can claim RPs in realms A, B, C and D!" How about s/flood naming constraints to/flood naming constraints on routed traffic to/ I think this would make it more clear what you are talking about. > > > James> 15. Section 2.3 - Application to Service -- This section > James> discusses the use of GSS-API, however I believe that it also > James> needs to include a discussion of the channel that is to be > James> used between the application and the server as this is not an > James> implicit part of the GSS-API system. This channel may have > James> some specific requirements that need to be discussed as well. > > I'd really need to see text here, because I don't know what we'd want to say > about the channel. Well I guess the first question is if any channel that is used needs to support channel binding? Also I think that it might be necessary to state that if protocols want a more definitive statement on who the RP is, then this needs to be provided by the channel (actually I am not sure that is the case). There are questions about privacy on the information setup prior to the GSS-EAP mechanism being setup as well as authentication. These may be requirements of the channel. I am not sure at this point what all is needed here. > > James> 16. Section 2.4 - I don't understand the title of this > James> section. What does this have to do with personalization? > James> Perhaps Attribute or similar word would be better than > James> personalization. A look forward in this section to the one > James> on privacy might be indicated as this would be a good > James> location to talk about the issues of what information should > James> be released from the IdP to the RP and how much it should be > James> under the control of the federation agreement and how much > James> under the control the subject. > > I would be fine with both of these changes. > > James> 17. Section 2.5 - what happened to the text in this section? > > I don't know. Did it ever have text? I have no idea. For all I know that section exists just to hold the picture which is odd. If it needs text then it needs to be supplied. > > > James> 19 - section 3.1 - I would suggest a new title as it would be > James> good to suggest who is being mutually authenticated -- yet > James> another name for somebody - who are the initiator and the > James> acceptor > > Section 3 is all about GSS-API, which only has two endpoints, so I don't see > any other options than these two endpoints. > > initiator is the GSS name for subject; acceptor is the GSS name for RP. Ok - either the table of names or a sentence saying 'Mutual authentication occurs between the subject and the RP." Would both address my problem. > > James> Please expand on the difference between bullets 1 and 2 in > James> this section. It appears to me that the first sentence in > James> both sections are saying the same thing - that the initiator > James> trusts that the name it has given for the target > James> name/acceptor correctly names and describes the acceptor. If > James> there is a difference in these concepts I for one don't > James> understand it from the text. > > The second bullet covers the case where the initiator does not supply a > target name. > I'd be happy to add a sentence to the second bullet that the second bullet is > a subset of the first when a target name is provided or otherwise clarify. Sounds good > > James> 20 - section 3.3 - In the next to last paragraph, would host > James> names work better in the case that secure SRV records w/ > James> DNSSEC are used? > > If you were willing to trust DNS both on the initiator and the RP and do some > work on how applications handle these names, you could improve the > situation. > To me, it seems a big assumption to assume that your application > authentication trust and your DNS trust are aligned, especially when you'd > need to make that assumptions on both sides of a federation. > It's true sometimes and possibly enough of the time to support, but not > enough of the time to rely on. It might make sense to change s/other insecure referrals/other referrals/ since in these cases the referrals would be assumed not to be AAA referrals. > > James> I also do not understand how to resolve the > James> decision in paragraph two to say we need to use realm names, > James> but the last paragraph says that we need to support > James> host-based service names. How am I supposed to reconcile > James> these differences. > > Putting hosts into a realms is a mechanism for more easily supporting host > names. > There is more detail on this in the actual mechanism document. > Ok - will read that document again. > James> Also does it make a difference in how the > James> channel to the service is created? I.e. it makes much more > James> sense to use host-based server names if one is using TLS as > James> the channel between the application and the channel, but how > James> the RP decides which IdP or federation to use is not going to > James> be based on host-based service names. I guess part of my > James> question is going to be is naming different for the RP (from > James> the point of view of the client) as oppose to the naming of > James> other entities in the system. > > This section is discussing support for host-based names of GSS acceptors. At > least as described currently an IDP is not a GSS acceptor. In the KMP > presentation we gave in Prague, we proposed creating a GSS acceptor > service associated with an IDP, but that is not discussed at all in this > document. I was more worried about the problems that the client had doing the comparison between what the RP gave to the IdP and what the RP gave to the client as a proper name rather than what the GSS acceptor was using. > > James> 21 - Section 3.4 - I need to have an idea of what entities > James> are going to be using the GSS-API per-message security > James> services. There is a difference in how I think about this if > James> this is done between the subject and the RP as oppose to > James> between the RP and the IdP or the subject and the IdP. I > James> also need to come to grips with how many different MSKs are > James> going to be generated in this system. I don't have a good > James> idea of this from this section. > > GSS initiator and acceptor use the per-message services. I.E. the IDP and RP. > Only one MSK in the entire system. > Is there a GSS key between the client and the RP before the EAP has finished? At what point do messages between the client and the RP become protected w/o the use of a channel which is independently providing protection. Jim > > > James> _______________________________________________ > abfab mailing > James> list abfab@ietf.org > James> https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Apr 27 04:16:21 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B50CE06E5 for ; Wed, 27 Apr 2011 04:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfrbpKneAjik for ; Wed, 27 Apr 2011 04:16:20 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 640F9E06D2 for ; Wed, 27 Apr 2011 04:16:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6864820228; Wed, 27 Apr 2011 07:12:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3633D478C; Wed, 27 Apr 2011 07:16:16 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> <009601cc0498$aad5f330$0081d990$@nwlink.com> Date: Wed, 27 Apr 2011 07:16:16 -0400 In-Reply-To: <009601cc0498$aad5f330$0081d990$@nwlink.com> (Jim Schaad's message of "Tue, 26 Apr 2011 22:05:01 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 11:16:21 -0000 >>>>> "Jim" == Jim Schaad writes: James> Also does it make a difference in how the channel to the James> service is created? I.e. it makes much more sense to use James> host-based server names if one is using TLS as the channel James> between the application and the channel, but how the RP James> decides which IdP or federation to use is not going to be James> based on host-based service names. I guess part of my James> question is going to be is naming different for the RP (from James> the point of view of the client) as oppose to the naming of James> other entities in the system. >> >> This section is discussing support for host-based names of GSS >> acceptors. Jim> At >> least as described currently an IDP is not a GSS acceptor. In >> the KMP presentation we gave in Prague, we proposed creating a >> GSS acceptor service associated with an IDP, but that is not >> discussed at all in this document. Jim> I was more worried about the problems that the client had doing Jim> the comparison between what the RP gave to the IdP and what the Jim> RP gave to the client as a proper name rather than what the GSS Jim> acceptor was using. It's actually the IDP that does this. The client gives its idea of GSS acceptor name to the IDP; the RP gives its idea of the GSS acceptor name to the IDP. In a typical deployment, I'm expecting that some AAA proxy close to the acceptor would verify that the acceptor is authorized to claim whatever host name it actually claims. I'm imagining that the border proxy between the IDP's realm and the acceptor's realm (in a RADSEC style deployment where these entities speak directly) would confirm that the RP is from the realm it claims and that realm is permitted to claim the hostname that the acceptor claimed. This leaves the IDP it self doing a binary comparison of the channel binding attributes the client/subject sent to the ones from the RP. Any attribute sent by the client must be present in the RP set and must compare identically. This all needs to be spelled out: the proxy behavior sections need to be written. I think the IDP behavior is spelled out in the mechanism document. >> James> 21 - Section 3.4 - I need to have an idea of what entities James> are going to be using the GSS-API per-message security James> services. There is a difference in how I think about this if James> this is done between the subject and the RP as oppose to James> between the RP and the IdP or the subject and the IdP. I James> also need to come to grips with how many different MSKs are James> going to be generated in this system. I don't have a good James> idea of this from this section. >> >> GSS initiator and acceptor use the per-message services. I.E. the >> IDP and Jim> RP. >> Only one MSK in the entire system. >> Is there a GSS key between the client and the RP before the EAP has Jim> finished? At what point do messages between the client and the Jim> RP become protected w/o the use of a channel which is Jim> independently providing protection. There is not a key before EAP generates one; typically the RP doesn't learn this key until eap succeeds. Unless we choose to introduce a DH exchange or the like, then things between the initiator and RP are not protected until eap succeeds. Currently the only things sent there are: * the EAP conversation * Initiator's request for RP name or initiator's indication of what RP name it is using * The mutual authentication flag that we need to MIC All of these things would go in the clear in something like TLS. In terms of channel attributes. There are a couple of basic approaches you could use. The GS2 approach is that you never use per-message services, you use a protected channel if you care about security and you perform channel binding. Contrast this with say the approach used by the Kerberos administration service. There the channel is never protected, but gss_wrap is used to protect every message. In this model really you need very little from the channel. I think explicitly describing these two models might help; what do you think? From jimsch@nwlink.com Thu Apr 28 18:32:36 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8B8E06BC for ; Thu, 28 Apr 2011 18:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n2zgbGOA77Z for ; Thu, 28 Apr 2011 18:32:35 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44DA0E062B for ; Thu, 28 Apr 2011 18:32:35 -0700 (PDT) Received: from TITUS (68-185-29-138.static.mdfd.or.charter.com [68.185.29.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.pacifier.net (Postfix) with ESMTP id 8EEF26A46A; Thu, 28 Apr 2011 18:32:34 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> <009601cc0498$aad5f330$0081d990$@nwlink.com> In-Reply-To: Date: Thu, 28 Apr 2011 18:58:42 -0700 Message-ID: <000001cc0610$f924e590$eb6eb0b0$@nwlink.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI0AuynjYFFecPcDkHdzLf/dRaImAHIzFAvAl0dqKsCYbRNCJNuMz1w Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 01:32:36 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Wednesday, April 27, 2011 4:16 AM > To: Jim Schaad > Cc: abfab@ietf.org; 'Eliot Lear' > Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 > > >>>>> "Jim" == Jim Schaad writes: > > James> Also does it make a difference in how the channel to the > James> service is created? I.e. it makes much more sense to use > James> host-based server names if one is using TLS as the channel > James> between the application and the channel, but how the RP > James> decides which IdP or federation to use is not going to be > James> based on host-based service names. I guess part of my > James> question is going to be is naming different for the RP (from > James> the point of view of the client) as oppose to the naming of > James> other entities in the system. > >> > >> This section is discussing support for host-based names of GSS > >> acceptors. > Jim> At > >> least as described currently an IDP is not a GSS acceptor. In > >> the KMP presentation we gave in Prague, we proposed creating a > >> GSS acceptor service associated with an IDP, but that is not > >> discussed at all in this document. > > Jim> I was more worried about the problems that the client had doing > Jim> the comparison between what the RP gave to the IdP and what the > Jim> RP gave to the client as a proper name rather than what the GSS > Jim> acceptor was using. > > It's actually the IDP that does this. > The client gives its idea of GSS acceptor name to the IDP; the RP gives its idea > of the GSS acceptor name to the IDP. > > In a typical deployment, I'm expecting that some AAA proxy close to the > acceptor would verify that the acceptor is authorized to claim whatever host > name it actually claims. I'm imagining that the border proxy between the > IDP's realm and the acceptor's realm (in a RADSEC style deployment where > these entities speak directly) would confirm that the RP is from the realm it > claims and that realm is permitted to claim the hostname that the acceptor > claimed. > This leaves the IDP it self doing a binary comparison of the channel binding > attributes the client/subject sent to the ones from the RP. > Any attribute sent by the client must be present in the RP set and must > compare identically. > > This all needs to be spelled out: the proxy behavior sections need to be > written. I think the IDP behavior is spelled out in the mechanism document. > Ok - so we have here an even more important case to say that the channel between the client and the RP needs to have channel binding. Since we don't have the channel binding data for the IdP to compare unless the channel is going to produce it. There is no channel binding data from the GSS-EAP mechanism until the MSK is created. This would not be an issue if we were comparing text names, but then we have the issue of the difference between the DNS name used by the client and the AAAA realm name used by the RP. However this is leaving me confused about what the acceptor name form and value(s)(?) are supposed to be. I need to go back and review again what the form of the name you had on the screen was so that I can look for the different fields. > >> > James> 21 - Section 3.4 - I need to have an idea of what entities > James> are going to be using the GSS-API per-message security > James> services. There is a difference in how I think about this if > James> this is done between the subject and the RP as oppose to > James> between the RP and the IdP or the subject and the IdP. I > James> also need to come to grips with how many different MSKs are > James> going to be generated in this system. I don't have a good > James> idea of this from this section. > >> > >> GSS initiator and acceptor use the per-message services. I.E. the > >> IDP and > Jim> RP. > >> Only one MSK in the entire system. > >> > > Is there a GSS key between the client and the RP before the EAP has > Jim> finished? At what point do messages between the client and the > Jim> RP become protected w/o the use of a channel which is > Jim> independently providing protection. > > There is not a key before EAP generates one; typically the RP doesn't learn > this key until eap succeeds. Ok - this is what I thought. Any other keys would come from the channel being used. > > Unless we choose to introduce a DH exchange or the like, then things > between the initiator and RP are not protected until eap succeeds. > Currently the only things sent there are: > > * the EAP conversation > * Initiator's request for RP name or initiator's indication of what RP > name it is using > * The mutual authentication flag that we need to MIC > > All of these things would go in the clear in something like TLS. ?? in the clear in or in the clear or ?? > > In terms of channel attributes. > > There are a couple of basic approaches you could use. > > The GS2 approach is that you never use per-message services, you use a > protected channel if you care about security and you perform channel > binding. > > Contrast this with say the approach used by the Kerberos administration > service. There the channel is never protected, but gss_wrap is used to > protect every message. > In this model really you need very little from the channel. > > I think explicitly describing these two models might help; what do you think? Yes I think that this would be useful as two extremes. From hartmans@painless-security.com Fri Apr 29 04:04:42 2011 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3CCE067E for ; Fri, 29 Apr 2011 04:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.987 X-Spam-Level: X-Spam-Status: No, score=-2.987 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHBnYYjWkA+q for ; Fri, 29 Apr 2011 04:04:42 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2F83AE062A for ; Fri, 29 Apr 2011 04:04:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DADDD20222; Fri, 29 Apr 2011 07:00:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BABF54774; Fri, 29 Apr 2011 07:04:29 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <009301cc0065$94173eb0$bc45bc10$@nwlink.com> <009601cc0498$aad5f330$0081d990$@nwlink.com> <000001cc0610$f924e590$eb6eb0b0$@nwlink.com> Date: Fri, 29 Apr 2011 07:04:29 -0400 In-Reply-To: <000001cc0610$f924e590$eb6eb0b0$@nwlink.com> (Jim Schaad's message of "Thu, 28 Apr 2011 18:58:42 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-lear-abfab-arch-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2011 11:04:42 -0000 >>>>> "Jim" == Jim Schaad writes: It's absolutely critical for mutual authentication that we have EAP channel binding. That goes between the peer/initiator/subject and the IDP/EAP server. That is independent of GSS channel binding which goes between the initiator/subject/peer and the RP/acceptor. Jim> Jim> Since we don't have the channel binding data for the IdP to Jim> compare unless the channel is going to produce it. There is no Jim> channel binding data from the GSS-EAP mechanism until the MSK Jim> is created. This would not be an issue if we were comparing Jim> text names, but then we have the issue of the difference Jim> between the DNS name used by the client and the AAAA realm name Jim> used by the RP. OK, so we also have confusion about channels. EAP channel binding describes properties of the EAP lower layer--in our case the GSS exchange. The attributes we care about with regard to this channel are (at least so far) the acceptor name. The other channel, over which we apply GSS channel binding, is between the subject and RP. That's the channel that might be TLS. There', the attributes we care about are things like the server certificate or the hash of the finish messages. GSS and EAP channel binding are even more different than is implied so far. It's not just that the channel is different and the attributes we're talking about are different. GSS channel binding is intended to detect a man-in-the-middle attack. EAP channel binding does make sure that both ends of a connection have a consistent idea of naming. However it's not really about detecting man in the middle attacks, but more about maintaining consistency in a complex multi-party system. Continual apologies for the terminology confusion. The EAP and GSS communities independently came up with the term channel binding and didn't realize the conflict until it was well established in both communities. --Sam