From hartmans@painless-security.com Sun Apr 1 00:45:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4970921F86AD for ; Sun, 1 Apr 2012 00:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqC0GKUuhtD9 for ; Sun, 1 Apr 2012 00:45:02 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D321F21F86AA for ; Sun, 1 Apr 2012 00:45:02 -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 42EF62023F; Sun, 1 Apr 2012 03:44:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E677C4766; Sun, 1 Apr 2012 03:44:59 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4F74405A.3010802@deployingradius.com> <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> <4F76BFF2.3060902@deployingradius.com> Date: Sun, 01 Apr 2012 03:44:59 -0400 In-Reply-To: <4F76BFF2.3060902@deployingradius.com> (Alan DeKok's message of "Sat, 31 Mar 2012 10:27:30 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Trust router work X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 07:45:03 -0000 There were some discussions after the meeting. Klaas suggested defining the problems in terms of the two that came up in Alan's discussion: 1) B shares credentials with A and C. A would like to talk to C. 2) A would like to be able to discover a set of introductions to talk to some realm Z. Those two problems are not sufficient to interest me. If all I got were solutions to those, I would not be able to meet my customer requirements. The wording above implies somewhat of an anti-PKI bias. For those two problems that is because I couldn't come up with a clear technology-neutral statement in 30 seconds or less. However it's a starting point for a direction. I'd like to thank Klaas and Alan for getting us this far. It's going to be a bit before we get back to the problem statement because we need to focus on the base specs and because at least within the Moonshot context we need to flesh out our solution more. From hartmans@painless-security.com Sun Apr 1 01:11:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723B821F8680; Sun, 1 Apr 2012 01:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xkTk7EdEoKkT; Sun, 1 Apr 2012 01:11:05 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AB8FF21F867F; Sun, 1 Apr 2012 01:10:57 -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 011652024B; Sun, 1 Apr 2012 04:10:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BAC104766; Sun, 1 Apr 2012 04:10:49 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4F76C4D8.9080804@deployingradius.com> Date: Sun, 01 Apr 2012 04:10:49 -0400 In-Reply-To: <4F76C4D8.9080804@deployingradius.com> (Alan DeKok's message of "Sat, 31 Mar 2012 10:48:24 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Fragmentation in RADIUS X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 08:11:05 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> The draft proposes that the proxies obtain *all* of the data Alan> before re-writing it. This involves no changes to RADIUS. It Alan> does, however, require changes to implementations. These Alan> changes are documented, so that everyone is aware of the costs Alan> and benefits of the solution. And, so that the Alan> implementations are guided to a method that works. Alan, I want to confirm my understanding. Am I correct in believing that you only need to implement these complex changes if you want to rewrite these new fragmented packets? --Sam From kwiereng@cisco.com Sun Apr 1 02:38:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD6821F86A2 for ; Sun, 1 Apr 2012 02:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.136 X-Spam-Level: X-Spam-Status: No, score=-7.136 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G16AovpmCW8y for ; Sun, 1 Apr 2012 02:38:54 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6B47021F869F for ; Sun, 1 Apr 2012 02:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=2615; q=dns/txt; s=iport; t=1333273134; x=1334482734; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=sRmUB0aej1AwAF60fYVNGI2jrNLu9FmQ+AtN+zJkgkk=; b=WIyAY5XoWEz2el02sdAvHcU4Sn+SY2PtKt6ejglK68aglnCQ8i+vC6TB XOMUtMbj5nIAE+i/dxBn4Kx2Vnn09mG7L9lMvkYxeiP/EJSRkyoSdLFNJ lDNkLIwCzX5/xXBe+nROwObosr1+NdagDPmJhicos4CY+ez54x8MEPdyj Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsKABIheE+Q/khR/2dsb2JhbABEigqucQKBB4IJAQEBAwESASc4BxACAQhGVwEBBBMbB4diBZs8nhmQOWMElWGOR4Fogmk X-IronPort-AV: E=Sophos;i="4.75,352,1330905600"; d="scan'208";a="69836752" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2012 09:38:53 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q319cr3e025681; Sun, 1 Apr 2012 09:38:53 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 1 Apr 2012 11:38:53 +0200 Received: from 72.163.62.136 ([72.163.62.136]) by XMB-AMS-101.cisco.com ([144.254.74.76]) with Microsoft Exchange Server HTTP-DAV ; Sun, 1 Apr 2012 09:38:52 +0000 References: <4F74405A.3010802@deployingradius.com> <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> <4F76BFF2.3060902@deployingradius.com> Content-Transfer-Encoding: quoted-printable From: "Klaas Wierenga (kwiereng)" Content-Type: text/plain; charset="us-ascii" In-Reply-To: thread-topic: [abfab] Trust router work Message-ID: <76968C6D-51B2-40DD-A437-840E23C637B1@cisco.com> thread-index: Ac0P6z9aE0ByCdorT1GdQBWAnlHpPg== Date: Sun, 1 Apr 2012 11:38:49 +0200 To: "Sam Hartman" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 01 Apr 2012 09:38:53.0137 (UTC) FILETIME=[4022DC10:01CD0FEB] Cc: abfab@ietf.org Subject: Re: [abfab] Trust router work X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 09:38:55 -0000 Hi Sam, On 1 apr. 2012, at 09:45, "Sam Hartman" wro= te: >=20 > There were some discussions after the meeting. > Klaas suggested defining the problems in terms of the two that came up > in Alan's discussion: >=20 > 1) B shares credentials with A and C. A would like to talk to C. >=20 > 2) A would like to be able to discover a set of introductions to talk to > some realm Z. >=20 > Those two problems are not sufficient to interest me. If all I got were > solutions to those, I would not be able to meet my customer > requirements. >=20 > The wording above implies somewhat of an anti-PKI bias. For those two > problems that is because I couldn't come up with a clear > technology-neutral statement in 30 seconds or less. Ehm, I don't understand the wording about anti-PKI, I don't read that in it.= But to reiterate my point, I really think we need to understand the problem= before assessing the solution. If we were able to cut the problem up in sma= ller problems that would make for a good divide and conquer approach.=20 It may be my lack of understanding of the problem you are trying to solve, b= ut I had understood it in terms of finding a "trust path" between 2 arbitrar= y entities and getting an introduction to the next hop on that trust path. I= am thinking about it in terms of a path in a graph. - A wants to talk to Z, A has a trust relation with B - A discovers a path A, B, C, D, ..., Z - A asks B for an introduction to C - A asks C for an introduction to D .... - A gets an introduction to Z from Y So I see basically 2 approaches to that problem: A) find all paths between vertices A and Z and then for all of these paths t= ry to establish trust between any 2 connected vertices=20 B) the edges between any 2 vertices denote an existing trust relation, so th= e problem consist of finding a path between vertices A and Z Both approaches are pretty much standard graph problems.... so I must be mis= sing something.... >=20 > However it's a starting point for a direction. I'd like to thank Klaas > and Alan for getting us this far. >=20 >=20 > It's going to be a bit before we get back to the problem statement because= we need to focus > on the base specs and because at least within the Moonshot context we > need to flesh out our solution more. Then let's start with the Moonshot context and see how that is not captured b= y above clauses, perhaps we can generalize from that. It seems bad design pr= actice to work out a solution to an unknown problem....... Klaas= From aland@deployingradius.com Sun Apr 1 02:42:24 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9066621F86A2; Sun, 1 Apr 2012 02:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1ep79l-3297; Sun, 1 Apr 2012 02:42:24 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1525321F8681; Sun, 1 Apr 2012 02:42:24 -0700 (PDT) Message-ID: <4F7822E2.5050308@deployingradius.com> Date: Sun, 01 Apr 2012 11:41:54 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4F76C4D8.9080804@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Fragmentation in RADIUS X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 09:42:24 -0000 Sam Hartman wrote: > Alan, I want to confirm my understanding. Am I correct in believing > that you only need to implement these complex changes if you want to > rewrite these new fragmented packets? Yes. Alan DeKok. From aland@deployingradius.com Sun Apr 1 03:35:26 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA8921F8697 for ; Sun, 1 Apr 2012 03:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5hyyEjEkn8n for ; Sun, 1 Apr 2012 03:35:25 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id AA46A21F86A5 for ; Sun, 1 Apr 2012 03:35:25 -0700 (PDT) Message-ID: <4F782F52.7090302@deployingradius.com> Date: Sun, 01 Apr 2012 12:34:58 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4F74405A.3010802@deployingradius.com> <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> <4F76BFF2.3060902@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Trust router work X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 10:35:26 -0000 Sam Hartman wrote: > Those two problems are not sufficient to interest me. If all I got were > solutions to those, I would not be able to meet my customer > requirements. I'm presuming that they're part of the solution. If so, what *else* is required? > It's going to be a bit before we get back to the problem statement because we need to focus > on the base specs and because at least within the Moonshot context we > need to flesh out our solution more. I'd like a clear problem statement. From what I've seen of your requirements, you want the ability to have multiple "groups". What you call communities of interest. i.e. a realm is tied to a specific home AAA server. But that realm can exist in different contexts, and have different routing properties. e.g. foo.edu belongs to eduraom, but ALSO has a commercial agreement with a roaming provider. It wants to inject different routes into those two different routing fabrics. If that's true, then the first points you raised are only steps 1 and 2 of the solution. Step 3 would be to have a registrar which would coordinate group membership. I think the confusion for me is that I don't see why additional complexity is needed. Roaming operators already do roaming by realm, in a particular context. e.g. "example.com gets routed through the wireless broadband alliance" For me, it looks like step (3) is widely deployed. That's why I'm interested in talkiing about steps (1) and (2). Alan DeKok. From hartmans@painless-security.com Mon Apr 2 03:14:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8097421F88AB for ; Mon, 2 Apr 2012 03:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.966 X-Spam-Level: X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br4joE+GnW6q for ; Mon, 2 Apr 2012 03:14:11 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A9E2F21F88AA for ; Mon, 2 Apr 2012 03:14:11 -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 1516B2024B; Mon, 2 Apr 2012 06:13:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 12B2F4766; Mon, 2 Apr 2012 06:14:06 -0400 (EDT) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: <4F74405A.3010802@deployingradius.com> <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> <4F76BFF2.3060902@deployingradius.com> <76968C6D-51B2-40DD-A437-840E23C637B1@cisco.com> Date: Mon, 02 Apr 2012 06:14:06 -0400 In-Reply-To: <76968C6D-51B2-40DD-A437-840E23C637B1@cisco.com> (Klaas Wierenga's message of "Sun, 1 Apr 2012 11:38:49 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Trust router work X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:14:12 -0000 >>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: To clarify, I think the next step on this space for me to take in the ABFAB context is to explain what the above two problems don't capture from my customer requirements. That is to say what additional problems I'd need to solve to build a system that I believe people might want to deploy. It's going to be a while before I get to that. There are ABFAb base spec issues and limited time on my part that will get in the way. From leifj@sunet.se Mon Apr 2 03:51:23 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A9121F8799 for ; Mon, 2 Apr 2012 03:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alNYg+mduU1M for ; Mon, 2 Apr 2012 03:51:22 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 34BF521F8798 for ; Mon, 2 Apr 2012 03:51:22 -0700 (PDT) Received: from [192.36.125.227] (dhcp.pilsnet.sunet.se [192.36.125.227]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q32ApGlk027069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 2 Apr 2012 12:51:20 +0200 (CEST) Message-ID: <4F7984A4.7080101@sunet.se> Date: Mon, 02 Apr 2012 12:51:16 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: abfab@ietf.org References: <4F74405A.3010802@deployingradius.com> <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> <4F76BFF2.3060902@deployingradius.com> <76968C6D-51B2-40DD-A437-840E23C637B1@cisco.com> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Trust router work X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 10:51:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/02/2012 12:14 PM, Sam Hartman wrote: >>>>>> "Klaas" == Klaas Wierenga (kwiereng) >>>>>> writes: > > > > To clarify, I think the next step on this space for me to take in > the ABFAB context is to explain what the above two problems don't > capture from my customer requirements. That is to say what > additional problems I'd need to solve to build a system that I > believe people might want to deploy. > > It's going to be a while before I get to that. There are ABFAb base > spec issues and limited time on my part that will get in the way. Thank you for your summary Sam. I think your priorities are the right ones. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk95hKQACgkQ8Jx8FtbMZnfsXQCcCyR3SXsQcORFtUq1Us8LD5tL /lUAoLTSe/EQFS4UoNmJwyrB2Q9ThYKM =3BNH -----END PGP SIGNATURE----- From diego@tid.es Mon Apr 2 22:39:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E9A21F86E8 for ; Mon, 2 Apr 2012 22:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=2.001, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mJkYk5oF4lg for ; Mon, 2 Apr 2012 22:39:13 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7615921F86BE for ; Mon, 2 Apr 2012 22:39:12 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M1W0006G2DBIJ@tid.hi.inet> for abfab@ietf.org; Tue, 03 Apr 2012 07:39:11 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 94.83.02597.FFC8A7F4; Tue, 03 Apr 2012 07:39:11 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M1W0006C2DAIJ@tid.hi.inet> for abfab@ietf.org; Tue, 03 Apr 2012 07:39:10 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Tue, 03 Apr 2012 07:39:10 +0200 Date: Tue, 03 Apr 2012 07:39:08 +0200 From: DIEGO LOPEZ GARCIA In-reply-to: <4F7984A4.7080101@sunet.se> To: Leif Johansson Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] Trust router work Thread-index: Ac0RXBgQ0BuoCGvIRvOU3PgebrIgXg== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f4d6d000000a25-ef-4f7a8cff2335 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCKsWRmVeSWpSXmKPExsXCFe9nqPu/p8rf4MAZdouP198wOjB6LFny kymAMYrLJiU1J7MstUjfLoEro+tyP2PBN/6KldNbmRoYD/B3MXJySAiYSEz68ZkJwhaTuHBv PVsXIxeHkMB2Romm9Q9YIZyfjBI3Tk6GchoZJRYv2A3kcHCwCKhK3DhXANLNJqAu0XL0GwuI LSygJrFiynFmEJtTQEOi985hNhBbREBZYuu1/2DbmIFa305cwApi8wpYSuzrPgNlC0r8mHyP BWQ8M9DMKVNyIcrFJZpbb7JA2IoS0xY1MILYjEBHfz+1hglivLrEhlObmCFsPYl7f2cyQdSI StxpX88I8aSAxJI955khbFGJl4//Qb01gUli5cdvjBMYxWchOWMWwhmzkJwxC8kZCxhZVjGK FScVZaZnlOQmZuakGxjpZWTqZeallmxihERR5g7G5TtVDjEKcDAq8fBuuFjpL8SaWFZcmXuI UZKDSUmU90R3lb8QX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd6HL4DKeVMSK6tSi/JhUjIcHEoS vK7AiBcSLEpNT61Iy8wBpgqYNBMHJ0g7D1B7FUgNb3FBYm5xZjpE/hSjpJQ4byhIQgAkkVGa B9f7ilEc6Ehh3kqQLA8wqcF1vQIayAQ08NXfcpCBJYkIKakGRovFVeEbTqhxPq5lXcczX63a zmOyZPamOs3yfVm3T+4Xn+LRcm9pu5/9rrO+lx8u19vbrTTHxCCt8jXnx9S0w3N+82aIRu45 z8XyVE5M+Yim4vQ8lQW2RrqVN1ML/v5RYr1/YUfso+2dXLNvLLpr/Tdjm7nFN4vS0jifKBPF i/8LLtbx/H75U4mlOCPRUIu5qDgRAJDcES4nAwAA References: <4F74405A.3010802@deployingradius.com> <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> <4F76BFF2.3060902@deployingradius.com> <76968C6D-51B2-40DD-A437-840E23C637B1@cisco.com> <4F7984A4.7080101@sunet.se> Cc: "abfab@ietf.org" Subject: Re: [abfab] Trust router work 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, 03 Apr 2012 05:39:14 -0000 DQpPbiAyIEFwciAyMDEyLCBhdCAxMjo1MSAsIExlaWYgSm9oYW5zc29uIHdyb3RlOg0KDQo+IE9u IDA0LzAyLzIwMTIgMTI6MTQgUE0sIFNhbSBIYXJ0bWFuIHdyb3RlOg0KPiA+Pj4+Pj4gIktsYWFz IiA9PSBLbGFhcyBXaWVyZW5nYSAoa3dpZXJlbmcpIDxrd2llcmVuZ0BjaXNjby5jb20+DQo+ID4+ Pj4+PiB3cml0ZXM6DQo+ID4NCj4gPiBUbyBjbGFyaWZ5LCBJIHRoaW5rIHRoZSBuZXh0IHN0ZXAg b24gdGhpcyBzcGFjZSBmb3IgbWUgdG8gdGFrZSBpbg0KPiA+IHRoZSBBQkZBQiBjb250ZXh0IGlz IHRvIGV4cGxhaW4gd2hhdCB0aGUgYWJvdmUgdHdvIHByb2JsZW1zIGRvbid0DQo+ID4gY2FwdHVy ZSBmcm9tIG15IGN1c3RvbWVyIHJlcXVpcmVtZW50cy4gVGhhdCBpcyB0byBzYXkgd2hhdA0KPiA+ IGFkZGl0aW9uYWwgcHJvYmxlbXMgSSdkIG5lZWQgdG8gc29sdmUgdG8gYnVpbGQgYSBzeXN0ZW0g dGhhdCBJDQo+ID4gYmVsaWV2ZSBwZW9wbGUgbWlnaHQgd2FudCB0byBkZXBsb3kuDQo+ID4NCj4g PiBJdCdzIGdvaW5nIHRvIGJlIGEgd2hpbGUgYmVmb3JlIEkgZ2V0IHRvIHRoYXQuIFRoZXJlIGFy ZSBBQkZBYiBiYXNlDQo+ID4gc3BlYyBpc3N1ZXMgYW5kIGxpbWl0ZWQgdGltZSBvbiBteSBwYXJ0 IHRoYXQgd2lsbCBnZXQgaW4gdGhlIHdheS4NCj4NCj4gVGhhbmsgeW91IGZvciB5b3VyIHN1bW1h cnkgU2FtLiBJIHRoaW5rIHlvdXIgcHJpb3JpdGllcyBhcmUgdGhlIHJpZ2h0DQo+IG9uZXMuDQoN Cg0KSW4gdGhlIG1lYW50aW1lLCB0aGVyZSBpcyBhIHBvdGVudGlhbCB1c2UgY2FzZSBpbiBhIHBy b2plY3QgSSdtIGludm9sdmVkDQppbi4gSWYgSSBtYW5hZ2UgdG8gbW92ZSB0aGUgaWRlYSBmb3J3 YXJkLCBJJ2xsIGtlZXAgdGhlIGxpc3QgdXBkYXRlZC4NCg0KQmUgZ29vZGUsDQoNCi0tDQoiRXN0 YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bl eg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQpl LW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0 IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFy aW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNp w7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFq by4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3Nl ZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVy bXMgc2V0IG91dCBhdA0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFz cHgNCg== From trac+abfab@trac.tools.ietf.org Thu Apr 5 14:45:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4014C21F8694 for ; Thu, 5 Apr 2012 14:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrwiLX3mb6mt for ; Thu, 5 Apr 2012 14:45:24 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 97F9A21F8668 for ; Thu, 5 Apr 2012 14:45:24 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SFuUS-00035G-MU; Thu, 05 Apr 2012 17:45:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hartmans-ietf@mit.edu X-Trac-Project: abfab Date: Thu, 05 Apr 2012 21:45:12 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/33 Message-ID: <061.40bdd1435a3f78620c0b27ca3b0bef6b@trac.tools.ietf.org> X-Trac-Ticket-ID: 33 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, kevin.wasserman@painless-security.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: abfab@ietf.org, kevin.wasserman@painless-security.com Subject: [abfab] #33: Example token has wrong OID X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 21:45:25 -0000 #33: Example token has wrong OID After we updated to use IETF OIDs, we need to update the example token to use the correct OID. -- -----------------------------+----------------- Reporter: hartmans-ietf@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: gss-eap | Version: Severity: - | Keywords: -----------------------------+----------------- Ticket URL: abfab From hartmans@painless-security.com Fri Apr 6 13:12:37 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC0D11E8099 for ; Fri, 6 Apr 2012 13:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6JIHOtdEr0H for ; Fri, 6 Apr 2012 13:12:36 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id CA57511E8098 for ; Fri, 6 Apr 2012 13:12:36 -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 EF36C2024B; Fri, 6 Apr 2012 16:11:40 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 60C394766; Fri, 6 Apr 2012 16:12:21 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org, raeburn@mit.edu, lukeh@padl.com Date: Fri, 06 Apr 2012 16:12:21 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] gss-eap: empty channel bindings 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, 06 Apr 2012 20:12:37 -0000 Hi folks. I noticed that under the current draft a mechanism should use the RFC 3961 GetMIC operation on an empty token buffer if an application passes in NULL channel bindings to gss_init_sec_context. I also noticed that this is not what the Moonshot code does. Instead, the moonshot code skips the channel binding subtoken entirely if the application passes in no channel bindings. RFC 3961 says that you can pass in any length data to that operation, which presumably includes 0. I think our checksums are well-defined for 0-length inputs. It's not a widely tested code path, but it probably works and we can work through any bugs relatively quickly. Greg Hudson at MIT did check the aes128 code path and that seems to work. On the other hand, I think what the Moonshot code does is secure. If an attacker removes a channel bindings subtoken the MIC token should detect this. My assumption is that unless there's a consensus to change the draft should remain as-is and Moonshot should change its code. However I'd like to call out the issue and get opinions on whether we want to: 1) Send a MIC of a empty buffer or 2) Omit the token entirely As far as I can tell 1 exercises a not-often-used code path, but is probably fine and 2 is probably fine. From raeburn@mit.edu Fri Apr 6 19:51:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79E511E808C for ; Fri, 6 Apr 2012 19:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fq9naj01McOn for ; Fri, 6 Apr 2012 19:51:46 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id CDA5711E8086 for ; Fri, 6 Apr 2012 19:51:45 -0700 (PDT) X-AuditID: 1209190d-b7fbf6d0000008ba-2a-4f7fabc0f076 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 62.35.02234.0CBAF7F4; Fri, 6 Apr 2012 22:51:44 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id q372piJ3005812; Fri, 6 Apr 2012 22:51:44 -0400 Received: from squish.raeburn.org (c-66-31-202-94.hsd1.ma.comcast.net [66.31.202.94]) (authenticated bits=0) (User authenticated as raeburn@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q372pgDH019081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 6 Apr 2012 22:51:43 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Ken Raeburn In-Reply-To: Date: Fri, 6 Apr 2012 22:51:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1257) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hRV1j2wut7fYPZOQ4uP198wWsz0tLh7 6T+7A7PHkiU/mTzmfpjG4jH7WytjAHMUl01Kak5mWWqRvl0CV8bTi/MZC7ZzVmxsn8HSwLiL vYuRk0NCwETi2sPvTBC2mMSFe+vZuhi5OIQE9jFK3G68zg7hrGeUeDD5HiuEc55JYvO8qywg LcICOhKnD91jBLF5BQwlZr5qZwWxmQX0JHZc/wVmswkoSzz9ugushlNATWLatW3MIDaLgIrE 50ezWSDqlSSmN76A6tWWWLbwNTPETCuJiTfug/UKCahKPJkygw3EFhEwkJj36hgbxNmyErcP 7meawCg4C8kZs5CcMQvJ2AWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0jfRyM0v0UlNKNzGC Q1qSdwfju4NKhxgFOBiVeHgD+er9hVgTy4orcw8xSnIwKYnyBiwGCvEl5adUZiQWZ8QXleak Fh9ilOBgVhLh/f26zl+INyWxsiq1KB8mJc3BoiTOq6r1zk9IID2xJDU7NbUgtQgmK8PBoSTB +2kV0FDBotT01Iq0zJwShDQTByfIcB6g4TdAaniLCxJzizPTIfKnGHU57j3uvcIoxJKXn5cq Jc77AKRIAKQoozQPbg4sFb1iFAd6S5j3A0gVDzCNwU16BbSECWjJya/VIEtKEhFSUg2MBZES LH6/2TbO/FxyTbT0r0TZ9QsbglI5t4S3tRvO84hWmWx1JLnXW4MxhXHmhrWnj7/bV6uZ+oTb 3dhh/u2Tf8ukf8hd27Tl3ZI5s3Y51VjVsvQ92se79EZPaJtK7b8gjiNL1INPtR+LOuASkT35 8sLP93p3LIjdeGvZYWONHbsC51yNstt8TYmlOCPRUIu5qDgRAF12+FYgAwAA X-Mailman-Approved-At: Sun, 08 Apr 2012 05:32:58 -0700 Cc: abfab@ietf.org Subject: Re: [abfab] gss-eap: empty channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2012 02:51:46 -0000 On Apr 6, 2012, at 16:12, Sam Hartman wrote: > RFC 3961 says that you can pass in any length data to that operation, > which presumably includes 0. I think our checksums are well-defined = for > 0-length inputs. It's not a widely tested code path, but it probably > works and we can work through any bugs relatively quickly. Greg Hudson > at MIT did check the aes128 code path and that seems to work. It does say "any length". On the other hand, we did explicitly rule out = empty messages for encryption, and I don't recall whether we thought as = hard about the checksum case. I don't think des-mac-k is well-defined for a zero-length message. For = a zero-length message, the length is a multiple of 8 octets, so no = padding bytes are added. With a zero-length input, we get zero bytes = out of the CBC-mode encryption=85 and then we're supposed to use the = last block of that output as the MIC. However, it was described as "no = longer recommended" even in RFC 1510, and between that and the = des-die-die-die draft, I'm not inclined to worry about it too much. The rest appear to support zero-length messages. It's something to keep in mind for 3961bis. :-) Ken= From internet-drafts@ietf.org Mon Apr 9 10:22:44 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B512521F87B5; Mon, 9 Apr 2012 10:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2x94hTRlMvB; Mon, 9 Apr 2012 10:22:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A69FE21F87AF; Mon, 9 Apr 2012 10:22:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120409172243.25740.10331.idtracker@ietfa.amsl.com> Date: Mon, 09 Apr 2012 10:22:43 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-06.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:22:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Ac= cess Beyond web Working Group of the IETF. Title : A GSS-API Mechanism for the Extensible Authentication Pr= otocol Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-06.txt Pages : 40 Date : 2012-04-09 This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-06.txt From hartmans@painless-security.com Mon Apr 9 10:30:10 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB021F873B for ; Mon, 9 Apr 2012 10:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.005 X-Spam-Level: X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fm4nr+GfPIB1 for ; Mon, 9 Apr 2012 10:30:10 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0F121F8733 for ; Mon, 9 Apr 2012 10:30:10 -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 22652207D4 for ; Mon, 9 Apr 2012 13:29:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 15D134766; Mon, 9 Apr 2012 13:29:46 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Mon, 09 Apr 2012 13:29:46 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] draft-ietf-abfab-gss-eap-06 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:30:11 -0000 Hi folks. I've posted a new version of the gss-eap draft: * Fold in the OId registry * Fix Jim's comment * Add some security considerations text for channel binding issues * Add an IANA registry for the flags subtoken * Add IANA text for RADIUS attributes My recommendation is that despite the following issues the chairs should last call this version within the WG. 1) The examp/le token has not beend updated to take advantage of the new OID. I think that's a fine thing to fix before submitted to the IESG and a few other matters have gotten in the way of producing a new example token. 2) The question of whether to send no GSS channel binding token or wether to send a token that is a MIC of an empty token is still being discussed. I think that's a fine question to settle during last call. Please note that immediately after submitting I discovered the acknowledgements section requires an update. First, I acknowledge Rhys for the OId registry text. Second, I realize I didn't have a funding acknowledgement indicating that my work on this document has been funded by JANET. These changes are editorial and can be made along with updating the example token. From hartmans@mit.edu Mon Apr 9 10:35:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4421F876A for ; Mon, 9 Apr 2012 10:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.029 X-Spam-Level: X-Spam-Status: No, score=-2.029 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RUw6ud6AAEo for ; Mon, 9 Apr 2012 10:35:04 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 94BD221F8769 for ; Mon, 9 Apr 2012 10:35:04 -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 5BB232014A; Mon, 9 Apr 2012 13:34:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B71DA4766; Mon, 9 Apr 2012 13:34:43 -0400 (EDT) From: Sam Hartman To: Ken Raeburn References: Date: Mon, 09 Apr 2012 13:34:43 -0400 In-Reply-To: (Ken Raeburn's message of "Fri, 6 Apr 2012 22:51:41 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] gss-eap: empty channel bindings X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Apr 2012 17:35:05 -0000 After reading Luke's mail and Ken's mail my preference is to chang ethe draft to do what the Moonshot code does. In particular I propose that the channel binding code is critical but not required. It MUSt be sent when non-empty application channel bindings are passed in and MUST NOT be sent when empty application channel bindings are passed into gss_init_sec_context. I'd appreciate someone besides me analyzing the protocol and confirming that doing this is secure. I think that leaves Luke, Ken and I preferring a change and no other opinions expressed so far. I'm holding we can fold a decision on this into a last call. From lukeh@padl.com Mon Apr 9 23:22:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092B521F8796 for ; Mon, 9 Apr 2012 23:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1KBhyMqJwQq for ; Mon, 9 Apr 2012 23:22:04 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF8521F8759 for ; Mon, 9 Apr 2012 23:22:04 -0700 (PDT) Received: by us.padl.com with ESMTP id q3A6Lwfw021655; Tue, 10 Apr 2012 02:22:02 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Tue, 10 Apr 2012 08:21:59 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3257624D-D9FB-46E4-A27F-C195FF1C5057@padl.com> References: To: Sam Hartman X-Mailer: Apple Mail (2.1257) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_DYNAMIC,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: abfab@ietf.org Subject: Re: [abfab] draft-ietf-abfab-gss-eap-06 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, 10 Apr 2012 06:22:05 -0000 Typo in 3.1: GSS_EAP_NT_EAP_NAMe -- Luke From leifj@sunet.se Tue Apr 17 02:43:34 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A696421F85A5 for ; Tue, 17 Apr 2012 02:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slHo8XH3fXf4 for ; Tue, 17 Apr 2012 02:43:29 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 345AD21F85A8 for ; Tue, 17 Apr 2012 02:43:28 -0700 (PDT) Received: from [192.36.125.245] (dhcp.pilsnet.sunet.se [192.36.125.245] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q3H9hNWv021617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 11:43:27 +0200 (CEST) Message-ID: <4F8D3B3B.30506@sunet.se> Date: Tue, 17 Apr 2012 11:43:23 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] WGLC draft-ietf-abfab-gss-eap-06 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 09:43:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The chairs believe that draft-ietf-abfab-gss-eap-06 is ready for last call and that any remaining issues including the nits already identified by Sam can be addressed during the WGLC. This is then a WGLC on draft-ietf-abfab-gss-eap-06. Please provide comments and/or feedback by 1/5 2012. Best R Leif & Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+NOzsACgkQ8Jx8FtbMZndbVACfQvxhpH19c2Mo77kftS0Lz+sz on4An0Toy+/LPZDVnALnBZUVk+sDhDYt =PncL -----END PGP SIGNATURE----- From simon@josefsson.org Tue Apr 17 03:24:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308DB21F85A0 for ; Tue, 17 Apr 2012 03:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.924 X-Spam-Level: X-Spam-Status: No, score=-98.924 tagged_above=-999 required=5 tests=[AWL=-0.874, BAYES_20=-0.74, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnV3h8vMc5St for ; Tue, 17 Apr 2012 03:24:30 -0700 (PDT) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 687A921F859F for ; Tue, 17 Apr 2012 03:24:29 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q3HAOLHI003216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 17 Apr 2012 12:24:22 +0200 From: Simon Josefsson To: "abfab\@ietf.org" References: <4F8D3B3B.30506@sunet.se> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:120417:leifj@sunet.se::08ZKWxq3Fz35+Ewk:WAV X-Hashcash: 1:22:120417:abfab@ietf.org::HQoN4dDy55E5AY8M:1oAC Date: Tue, 17 Apr 2012 12:24:21 +0200 In-Reply-To: <4F8D3B3B.30506@sunet.se> (Leif Johansson's message of "Tue, 17 Apr 2012 11:43:23 +0200") Message-ID: <87aa2afyga.fsf@latte.josefsson.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Subject: Re: [abfab] WGLC draft-ietf-abfab-gss-eap-06 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 10:24:31 -0000 I believe it would be prudent to ask for review by the Kitten WG since the document specify new GSS-API and SASL mechanisms. Perhaps the Kerberos WG too, since it creates an IANA registry for RFC 4121 token types. Section 5.8 contains: Open issue: handling of lifetime parameters. Should that be removed, or is there something to address here? The phrase "Section 7.1" in this sentence looks a bit weird: If the null name type or the GSS_EAP_NT_EAP_NAMe (OID 1.3.6.1.5.5.15.2.1) Section 7.1 is imported, then the string representation above should be directly imported. Note also the typo; s/EAP_NAMe/EAP_NAME/. "GSS_Init_sec_context" and "GSS_Accept_sec_context" has inconsistent capitalization throughout the document. Section 7.5: the SASL mechanism name "eap-aes128-cts-hmac-sha1-96" does not follow the syntax rules in RFC 4422: sasl-mech = 1*20mech-char mech-char = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE ; mech-char is restricted to A-Z (uppercase only), 0-9, -, and _ ; from ASCII character set. You may want to register the GS2 -PLUS variant name as well, compare RFC 5802. One approach is to register a SASL family that would encode all EAP variants implicitly, i.e., by registering EAP-* where * is derived as B32(DER(OID)) from the EAP-GSS mechanism OID. Compare how RFC 5801 derives SASL mechanism names. You could also fall back on the GS2-X construction that is already specified. Are there implementations of the mechanism that can be tested remotely on an interop-server? /Simon From hartmans@painless-security.com Tue Apr 17 12:41:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEE611E80D5 for ; Tue, 17 Apr 2012 12:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig5cZkdFdtq6 for ; Tue, 17 Apr 2012 12:41:39 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF7C11E80D0 for ; Tue, 17 Apr 2012 12:41:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [203.41.199.122]) (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 8540B2053A; Tue, 17 Apr 2012 15:37:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 73E2F4766; Tue, 17 Apr 2012 15:41:36 -0400 (EDT) From: Sam Hartman To: Simon Josefsson References: <4F8D3B3B.30506@sunet.se> <87aa2afyga.fsf@latte.josefsson.org> Date: Tue, 17 Apr 2012 15:41:36 -0400 In-Reply-To: <87aa2afyga.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 17 Apr 2012 12:24:21 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] WGLC draft-ietf-abfab-gss-eap-06 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:41:39 -0000 Hi. I think the review in kitten and krb-wg would be good. I think we already have a consensus that we want to register short SASL names; I will look into doing it like scram. Sorry for the sloppiness there. It also looks like we left lifetimes as a todo. Whatever we do I think it should be a MAY or SHOULD implement, not a MUSt implement. It looks like on the acceptor we could support RADIUS session time limits (if there is such a thing). On the initiator there's not much we can do. Thanks for your review! From leifj@mnt.se Tue Apr 17 12:58:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BACC21F84AE for ; Tue, 17 Apr 2012 12:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDSUMyGn396n for ; Tue, 17 Apr 2012 12:57:58 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B8AB021F84B8 for ; Tue, 17 Apr 2012 12:57:57 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q3HJvoqs015270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Apr 2012 21:57:55 +0200 (CEST) Message-ID: <4F8DCB3E.9020505@mnt.se> Date: Tue, 17 Apr 2012 21:57:50 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: abfab@ietf.org References: <4F8D3B3B.30506@sunet.se> <87aa2afyga.fsf@latte.josefsson.org> In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] WGLC draft-ietf-abfab-gss-eap-06 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 19:58:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/17/2012 09:41 PM, Sam Hartman wrote: > Hi. I think the review in kitten and krb-wg would be good. > So the chairs would be happy to go and ask for that review unless anyone else comes forward and volunteers as couriers :-) Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Nyz4ACgkQ8Jx8FtbMZndosACdFvR9rP3zlJdKu00Q6T8ZceJe W2UAn337RgGEs3aFlZ9mNS7M73MoR1ev =dztx -----END PGP SIGNATURE----- From ietf@augustcellars.com Wed Apr 18 13:02:57 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DA311E809D; Wed, 18 Apr 2012 13:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_05=-1.11, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1ak0od+6MjK; Wed, 18 Apr 2012 13:02:53 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23311E80A4; Wed, 18 Apr 2012 13:02:53 -0700 (PDT) Received: from Tobias (50-54-163-224.evrt.wa.frontiernet.net [50.54.163.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 0C37438F1D; Wed, 18 Apr 2012 13:02:52 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 18 Apr 2012 13:01:58 -0700 Message-ID: <021d01cd1d9e$1ce43ad0$56acb070$@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: Ac0dnMTcJAXpzyj2TqGISxbEO8pbog== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Delegation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 20:02:57 -0000 In the Plasma work effort we have spent much of the last month thinking about and doing some discussions on the question of delegated access. In the process we have located the following SAML document http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-delegation-cs-01. pdf which discusses how to create a SAML statement which has the delegation information built in. This gives us what we need in order to do the evaluation on the RP about what delegation has occurred. The problem is that there is currently no way to discuss the questions of delegation in the EAP protocols that I know of. This has not been a problem when we were looking at just the question of accessing a network; however the additional resources that we are now looking at because of ABFAB are now starting to make this an interesting question to looking at. The questions that I would have for the EMU group are: 1. Is there any interest in looking at the issues of how one requests a delegated access to occur? 2. What set of restrictions are going to be necessary for doing delegation. At present, since the only cases that I care about are going to be the ABFAB cases all I would actually need to the ability to say in one of the tunneled messages a simple statement to the effect that "I want delegate access to " which would either be granted or denied. 3. If we do delegated access, what things other than the SAML statement returned in the ABFAB context need to be changed? 4. Do we need to be able to do both delegation, where the delegation process is understood by the RP, and impersonation where the RP may not be able to tell that the authenticated entity is not really the same as the named entity returned to the RP from the IdP. 5. Are there other issues that need to be discussed? Jim From hartmans@painless-security.com Fri Apr 20 08:42:08 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5965121F8726 for ; Fri, 20 Apr 2012 08:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.048 X-Spam-Level: X-Spam-Status: No, score=-2.048 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4sVui9io21e for ; Fri, 20 Apr 2012 08:42:08 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E16F521F865B for ; Fri, 20 Apr 2012 08:42:07 -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 B6A4F20244; Fri, 20 Apr 2012 11:37:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 854B84765; Fri, 20 Apr 2012 11:42:03 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <021d01cd1d9e$1ce43ad0$56acb070$@augustcellars.com> Date: Fri, 20 Apr 2012 11:42:03 -0400 In-Reply-To: <021d01cd1d9e$1ce43ad0$56acb070$@augustcellars.com> (Jim Schaad's message of "Wed, 18 Apr 2012 13:01:58 -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] Delegation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 15:42:08 -0000 We've started some discussions of delegation in the moonshot project as well. We're focusing more on the RP side of it. That is, how an RP obtains a credential to act as a delegated user, rather than the question of how we indicate to a down-stream RP that delegation has occurred. we were thinking of providing a RADIUS attribute for an RP to ask for a delegation credential. If that is supplied in an access-request then an IDP/AAA server MAY supply a credential and key in an access-accept. That credential could be used as an EAP credential (say with some PSK method--possibly TEAP with a PSK cipher) to attempt to act as a user. Then the IDP would be in a position to decide whether the delegation is permitted. This covers as much of delegation as AD gives you today. It does not have a rich conversation between the user and IDP about what delegation is required; for that you'd need to involve EMU in some way. Also, note that this is a form of cross-domain delegation. Within in a resource domain, I think it makes more sense for the RP to end up with a Kerberos ticket (in many cases at least). Just letting you know some thoughts going on elsewhere. From cantor.2@osu.edu Fri Apr 20 08:56:58 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928BF21F86AF for ; Fri, 20 Apr 2012 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwBbindR20sD for ; Fri, 20 Apr 2012 08:56:58 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id E828A21F866A for ; Fri, 20 Apr 2012 08:56:57 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q3KFuijs001108; Fri, 20 Apr 2012 11:56:54 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 11:56:44 -0400 From: "Cantor, Scott" To: Sam Hartman , Jim Schaad Thread-Topic: [abfab] Delegation Thread-Index: AQHNHwwtd/6ctziwHE+Uu1KjNHqsfpaj3kMA Date: Fri, 20 Apr 2012 15:56:44 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-ID: <57484E9B07A0DB41B6C59DB1284BB172@exchange.osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "abfab@ietf.org" Subject: Re: [abfab] Delegation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 15:56:58 -0000 On 4/20/12 11:42 AM, "Sam Hartman" wrote: > >Just letting you know some thoughts going on elsewhere. In this vein... I expect, if it goes anywhere, that SAML-EC will eventually support SAML-based delegation in the manner implemented by the Shibboleth project. I don't have the experience yet to understand how to specify that in conjunction with GSS, but it should be straightforward. I'm not expecting that Moonshot would involve a SAML request in its delegation model, but if that comes into play, it would be good to align that work. (For the record, this is done traditionally by including an Audience condition in the AuthnRquest.) -- Scott From hartmans@painless-security.com Fri Apr 20 09:08:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6169A21F8773 for ; Fri, 20 Apr 2012 09:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR1-85WTRuWT for ; Fri, 20 Apr 2012 09:08:14 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AD40421F85AD for ; Fri, 20 Apr 2012 09:08:11 -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 1E1E72053A; Fri, 20 Apr 2012 12:03:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2C45F4765; Fri, 20 Apr 2012 12:08:07 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Fri, 20 Apr 2012 12:08:07 -0400 In-Reply-To: (Scott Cantor's message of "Fri, 20 Apr 2012 15:56:44 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Delegation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 16:08:15 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 4/20/12 11:42 AM, "Sam Hartman" wrote: >> >Just letting you know some thoughts going on elsewhere. Cantor,> In this vein... Cantor,> I expect, if it goes anywhere, that SAML-EC will eventually Cantor,> support SAML-based delegation in the manner implemented by Cantor,> the Shibboleth project. I don't have the experience yet to Cantor,> understand how to specify that in conjunction with GSS, but Cantor,> it should be straightforward. The delegated credential handle coming out of gss_accept_sec_context should include a credential element with the appropriate delegation. As far as how you request the delegation, we don't currently have a good story for that. From lukeh@padl.com Fri Apr 20 16:19:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2595121E8084 for ; Fri, 20 Apr 2012 16:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1psqwDDR691J for ; Fri, 20 Apr 2012 16:19:04 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 5482021E804B for ; Fri, 20 Apr 2012 16:19:03 -0700 (PDT) Received: by us.padl.com with ESMTP id q3KNIuSD008161; Fri, 20 Apr 2012 19:19:00 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Sat, 21 Apr 2012 01:18:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1257) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, RCVD_IN_PBL, RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.2 Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Delegation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 23:19:05 -0000 On 20/04/2012, at 6:08 PM, Sam Hartman wrote: > The delegated credential handle coming out of gss_accept_sec_context > should include a credential element with the appropriate delegation. > As far as how you request the delegation, we don't currently have a = good > story for that. You can defer the delegation until you try to initiate a security = context with the delegated credential handle. That's the design for = S4U2Proxy in MIT (Nico's idea, not mine). Or are you talking about something else... I guess this doesn't work if = you need to know you'll delegate at the time of the initial = authentication. -- Luke= From hartmans@painless-security.com Mon Apr 23 05:51:36 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE3A21F84EC for ; Mon, 23 Apr 2012 05:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OaDGw0w669J for ; Mon, 23 Apr 2012 05:51:34 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4F84721F84B3 for ; Mon, 23 Apr 2012 05:51:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (m992436d0.tmodns.net [208.54.36.153]) (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 047F020464; Mon, 23 Apr 2012 08:47:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7F74D4765; Mon, 23 Apr 2012 08:51:27 -0400 (EDT) From: Sam Hartman To: Luke Howard References: Date: Mon, 23 Apr 2012 08:51:27 -0400 In-Reply-To: (Luke Howard's message of "Sat, 21 Apr 2012 01:18:55 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] Delegation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 12:51:36 -0000 >>>>> "Luke" == Luke Howard writes: Luke> On 20/04/2012, at 6:08 PM, Sam Hartman wrote: > The delegated credential handle coming out of gss_accept_sec_context >> should include a credential element with the appropriate >> delegation. As far as how you request the delegation, we don't >> currently have a good story for that. Luke> You can defer the delegation until you try to initiate a Luke> security context with the delegated credential handle. That's Luke> the design for S4U2Proxy in MIT (Nico's idea, not mine). Luke> Or are you talking about something else... I guess this Luke> doesn't work if you need to know you'll delegate at the time Luke> of the initial authentication. was assuming you needed to know at time of initial auth. However, I don't know whether that is tru for SAML. From ietf@augustcellars.com Tue Apr 24 15:26:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108F221F8681 for ; Tue, 24 Apr 2012 15:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZFuqenKyKaw for ; Tue, 24 Apr 2012 15:26:01 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6E121F8680 for ; Tue, 24 Apr 2012 15:26:01 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 095362CA1C; Tue, 24 Apr 2012 15:26:00 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <021d01cd1d9e$1ce43ad0$56acb070$@augustcellars.com> In-Reply-To: Date: Tue, 24 Apr 2012 15:25:02 -0700 Message-ID: <014301cd2269$193a8b30$4bafa190$@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: AQH20ZPDMhEnKbceEhosMGP3UIVCuwIybrZ9lkPoIFA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Delegation 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, 24 Apr 2012 22:26:03 -0000 The first is what you are looking at, that is how to allow for an RP to act as a delegate of the original user. The second is how to allow user 1 to act as a delegate of user 2. The second is the one that I am more interested in at the moment. However looking at the first case there are some questions that I think are interesting. 1. Should the fact that a delegation is occurring - and perhaps what delegation is occurring - be something that the user should be able to see and thus be a candidate for channel bindings? 2. At what point will the RP know that a delegation operation is needed. I think that there may be many cases where this is not known at the start as noted in your last message. It is also possible that different delegation statements may be needed to talk to different entities. What RP2 and RP3 will accept may not be quite the same SAML statements. Thus it is possible that multiple delegation statements may be required. 3. The delegated SAML statement is quite probably not going to be the same as the SAML statement about the subject. The set of attributes may be restricted in several different ways. I think that this means that there may be a requirement for a request of a delegated SAML statement that would be independent of a request for a new SAML statement with additional attributes. I believe that the second is doable through Josh's draft but the first has no standardization at all. 4. I would be very reluctant to standardize asking for delegation as a Radius attribute. That being said I don't see any reason that Moonshot could not do it internally. 5. For Moonshot - how much of the delegation can be done via Kerberos rather than SAML? Back to my issue. Part of what I need can be done via configuration, but I am not sure that all of it can be. I can think of cases where a delegation SAML statement is going to be required and as there is no standardized way of asking for one it is going to be problematic until that is developed. What can be done with active directory currently is done via either RP delegation or configuration work on the resource. Exchange has this complex system of marking who a mailbox owner is and who else can play in the mailbox and then turning that information into RFC822 header information that almost nobody can follow. This means that in many cases the necessary information can be put into either attributes in the original message (Bob is Alice's executive assistant) and then the enforcement policies can be directly written to deal with looking for all of the different types of roles that people can be playing and who they are playing for. The think I don't like about this is that somebody doing a temp placement needs to have a different type of role and a different set of rules. This makes the configuration half hard no matter what you do. Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Friday, April 20, 2012 8:42 AM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Delegation > > > We've started some discussions of delegation in the moonshot project as > well. > > We're focusing more on the RP side of it. That is, how an RP obtains a > credential to act as a delegated user, rather than the question of how we > indicate to a down-stream RP that delegation has occurred. > > we were thinking of providing a RADIUS attribute for an RP to ask for a > delegation credential. If that is supplied in an access-request then an > IDP/AAA server MAY supply a credential and key in an access-accept. > That credential could be used as an EAP credential (say with some PSK > method--possibly TEAP with a PSK cipher) to attempt to act as a user. > Then the IDP would be in a position to decide whether the delegation is > permitted. > > > This covers as much of delegation as AD gives you today. > It does not have a rich conversation between the user and IDP about what > delegation is required; for that you'd need to involve EMU in some way. > > Also, note that this is a form of cross-domain delegation. Within in a resource > domain, I think it makes more sense for the RP to end up with a Kerberos > ticket (in many cases at least). > > Just letting you know some thoughts going on elsewhere. From nico@cryptonector.com Tue Apr 24 19:49:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1AC11E8075 for ; Tue, 24 Apr 2012 19:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2Vzs8xl2w5A for ; Tue, 24 Apr 2012 19:49:03 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id C021B11E8074 for ; Tue, 24 Apr 2012 19:49:03 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id BF87326C05E for ; Tue, 24 Apr 2012 19:49:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Io4CZ+nN4fPcVR6dWlAqPa9cogf8qyBdRfClWdagWRrs SJFAzpm376BzHJlwO6GYjcMLigzePjAu6cksSp6QEqt4Csu7xxWVXbj+ofcYy4YL Tq75EZ0aEcMUQZQ7t8qhIuOrJEii+C/b9oGvphxPzP1yjnLwdhCfkyLf6m5NTe8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=B8Hu5vk3ltBd5oOFDn0e88xzhLY=; b=HoN6E6hQzhV 86yMvNwJYKO4mwxaAtYeSdrmguXgM10D5Uzh7j2cddmFrgJldgU2XUEfiVkqD5Vi +WvLo9YCwJEylSvIJK69FAu/k70Xz2//rkhhuqWs0iwGS7iluRdfCeTnyhzWQMap 75W0HXEGIwUrDMaD8Hh5ysZn6T0g5i44= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id A548C26C058 for ; Tue, 24 Apr 2012 19:49:02 -0700 (PDT) Received: by dady13 with SMTP id y13so2416634dad.27 for ; Tue, 24 Apr 2012 19:49:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.135.40 with SMTP id pp8mr3563634pbb.13.1335322142201; Tue, 24 Apr 2012 19:49:02 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 24 Apr 2012 19:49:01 -0700 (PDT) In-Reply-To: <014301cd2269$193a8b30$4bafa190$@augustcellars.com> References: <021d01cd1d9e$1ce43ad0$56acb070$@augustcellars.com> <014301cd2269$193a8b30$4bafa190$@augustcellars.com> Date: Tue, 24 Apr 2012 21:49:01 -0500 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Delegation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 02:49:04 -0000 On Tue, Apr 24, 2012 at 5:25 PM, Jim Schaad wrote: > The first is what you are looking at, that is how to allow for an RP to a= ct > as a delegate of the original user. =C2=A0The second is how to allow user= 1 to > act as a delegate of user 2. =C2=A0 The second is the one that I am more > interested in at the moment. There are several authorization decisions to make. Is a given client principal allowed to delegate credentials? to what target principals? and what third principals can those targets impersonate the client to? and does the client get to decide or influence the answer to the previous question? > However looking at the first case there are some questions that I think a= re > interesting. > > 1. =C2=A0Should the fact that a delegation is occurring - and perhaps wha= t > delegation is occurring - be something that the user should be able to se= e > and thus be a candidate for channel bindings? In the Microsoft S4U model the user doesn't get to know that the target principal will be impersonating the user. I've considered (and still may implement) a GSS-equivalent of the ssh-agent as a way to delegate credentials by proxying back to the client. This approach allows real-time auditing UIs for the user, but the client has to be online as long as those "delegated" credentials are needed (this is both, a feature and a bug). Whether the user should get to see an audit trail of some (which?), all, or no impersonation events is itself an authorization issue. (Since the user could always use a "gss-agent" the user could always see an audit trail, but, of course, only if the target supports/allows this). > 2. =C2=A0At what point will the RP know that a delegation operation is ne= eded. =C2=A0I > think that there may be many cases where this is not known at the start a= s > noted in your last message. =C2=A0 It is also possible that different del= egation > statements may be needed to talk to different entities. =C2=A0What RP2 an= d RP3 > will accept may not be quite the same SAML statements. =C2=A0Thus it is p= ossible > that multiple delegation statements may be required. In the GSS-API the simplest thing to do is to pretend that the client principal did delegate credentials to the acceptor, and the acceptor will find out to what extent those credentials work when... it tries to initiate security contexts with them. Trying to represent constrained credentials in more detail is something we could attempt if need be, but most likely will be a dead end (e.g., there is nothing a Kerberos acceptor can do to get, say, a list of principals that an S4U2Proxy credential can be used for). In other words: the best we can do is probably to pretend the acceptor has a full delegated credential even though it may fail in some, most, or even all cases. > 3. =C2=A0The delegated SAML statement is quite probably not going to be t= he same > as the SAML statement about the subject. =C2=A0The set of attributes may = be > restricted in several different ways. =C2=A0I think that this means that = there > may be a requirement for a request of a delegated SAML statement that wou= ld > be independent of a request for a new SAML statement with additional > attributes. =C2=A0I believe that the second is doable through Josh's draf= t but > the first has no standardization at all. A delegated credential allows for impersonation, so, yes, a delegated GSS-EAP credential necessarily has to be different than a typical SAML statement. A RADIUS request for delegated credentials is very much akin to Kerberos S4= U. > 4. =C2=A0I would be very reluctant to standardize asking for delegation a= s a > Radius attribute. =C2=A0That being said I don't see any reason that Moons= hot > could not do it internally. Why be reluctant? > 5. =C2=A0For Moonshot - how much of the delegation can be done via Kerber= os > rather than SAML? You could use S4U. Windows uses S4U to transition PKI to Kebreros. EAP to Kerberos would be very, very similar -- the same, actually. But the "delegated" credential that results will have fairly limited scope, such as allowing the RP to impersonate the client to a small number of services in the same realm as the RP, or in an AD forest, but not to arbitrary services all over the Internet, say. Nico -- From hartmans@painless-security.com Wed Apr 25 07:52:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0542021F853E for ; Wed, 25 Apr 2012 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae2mJhm25P5W for ; Wed, 25 Apr 2012 07:52:30 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8935821F8539 for ; Wed, 25 Apr 2012 07:52:30 -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 BD14B2024B; Wed, 25 Apr 2012 10:48:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 661254765; Wed, 25 Apr 2012 10:52:27 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <021d01cd1d9e$1ce43ad0$56acb070$@augustcellars.com> <014301cd2269$193a8b30$4bafa190$@augustcellars.com> Date: Wed, 25 Apr 2012 10:52:27 -0400 In-Reply-To: <014301cd2269$193a8b30$4bafa190$@augustcellars.com> (Jim Schaad's message of "Tue, 24 Apr 2012 15:25:02 -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] Delegation X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 14:52:31 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> The first is what you are looking at, that is how to allow for Jim> an RP to act as a delegate of the original user. The second is Jim> how to allow user 1 to act as a delegate of user 2. The second Jim> is the one that I am more interested in at the moment. I'm confused. In my mind these are not distinct. From trac+abfab@trac.tools.ietf.org Mon Apr 30 17:22:34 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD78E21E804A for ; Mon, 30 Apr 2012 17:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrczTfHCO0lU for ; Mon, 30 Apr 2012 17:22:34 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 661F321E8037 for ; Mon, 30 Apr 2012 17:22:34 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SP0rA-000758-3j; Mon, 30 Apr 2012 20:22:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 01 May 2012 00:22:16 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/9#comment:1 Message-ID: <077.566908a7a394cc1f92acea2a57c4e12b@trac.tools.ietf.org> References: <062.a1f3c5afc776c1c4522400a4d95e60a7@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <062.a1f3c5afc776c1c4522400a4d95e60a7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120501002234.661F321E8037@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 17:22:34 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #9: What goes into a federation agreement? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:22:34 -0000 #9: What goes into a federation agreement? Comment (by ietf@…): Should read SAML assertions not SASL statements. -- ---------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: trivial | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | ---------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Mon Apr 30 17:29:29 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE9D221E8123 for ; Mon, 30 Apr 2012 17:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AB06IJ3Gt3IZ for ; Mon, 30 Apr 2012 17:29:29 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6091121E8122 for ; Mon, 30 Apr 2012 17:29:29 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SP0y5-0002Vf-A0; Mon, 30 Apr 2012 20:29:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 01 May 2012 00:29:25 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/25#comment:2 Message-ID: <077.3b9853a63fbadeb698c3797bd2a9d603@trac.tools.ietf.org> References: <062.a452be6f2a3ca8d1b2eaa8a7e3088d4f@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <062.a452be6f2a3ca8d1b2eaa8a7e3088d4f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120501002929.6091121E8122@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 17:29:29 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #25: Section 2.4 - Section title is confusing X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:29:29 -0000 #25: Section 2.4 - Section title is confusing Changes (by ietf@…): * status: new => closed * resolution: => fixed Comment: Per Josh's mail - this section is no longer relavent and will thus be omitted. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Mon Apr 30 17:33:33 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83BC21F8773 for ; Mon, 30 Apr 2012 17:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq6qgH4OrkNX for ; Mon, 30 Apr 2012 17:33:33 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4B27E21F876D for ; Mon, 30 Apr 2012 17:33:33 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SP11v-0008EO-Rs; Mon, 30 Apr 2012 20:33:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com X-Trac-Project: abfab Date: Tue, 01 May 2012 00:33:23 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/20#comment:3 Message-ID: <077.d9abce552e0cfb878667f547e12f3f61@trac.tools.ietf.org> References: <062.cfa02a9afc09132a4c9e05582acc5b72@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <062.cfa02a9afc09132a4c9e05582acc5b72@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120501003333.4B27E21F876D@ietfa.amsl.com> Resent-Date: Mon, 30 Apr 2012 17:33:33 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #20: Section 1.4 - digaram correction X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 00:33:33 -0000 #20: Section 1.4 - digaram correction Changes (by ietf@…): * status: reopened => closed * resolution: => fixed Comment: Fixed in -02 -- ---------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: trivial | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | ---------------------+-------------------------------------- Ticket URL: abfab