From hartmans@painless-security.com Tue Mar 1 07:18:33 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF913A6850 for ; Tue, 1 Mar 2011 07:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqJhCDm0jq1r for ; Tue, 1 Mar 2011 07:18:33 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 87A2D3A68AB for ; Tue, 1 Mar 2011 07:18:22 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 305502011F; Tue, 1 Mar 2011 10:16:53 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9F20F4307; Tue, 1 Mar 2011 10:19:18 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <4D5E2E28.7010406@deployingradius.com> Date: Tue, 01 Mar 2011 10:19:18 -0500 In-Reply-To: <4D5E2E28.7010406@deployingradius.com> (Alan DeKok's message of "Fri, 18 Feb 2011 09:30:32 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] How does the EAP server know proxies did their thing? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 15:18:34 -0000 >>>>> "Alan" == Alan DeKok writes: >> I'm sort of imagining an attribute that the proxy includes >> indicating it has performed some check and the policy applied to >> perform that check. I'm not entirely sure what level of >> granularity is required. I'm wondering if there are participants >> who would be interested in working through details of this? Alan> I think it would be useful. Sharing information is a good Alan> idea. It's important to understand this probably isn't going to be a cryptographic assurance. The intent is to allow phased deployment and to catch configuration errors, not to catch compromised proxies. Alan> For simplicity, it would probably be best if there was no Alan> negotiation. i.e. the proxy just says "I did this". Alan> Any negotiation about which checks need to be done is Alan> probably an issue for contracts, lawyers, etc. I strongly agree that negotiation would be highly problematic here. --Sam From leifj@sunet.se Thu Mar 3 15:38:59 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EFDF3A6872 for ; Thu, 3 Mar 2011 15:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx7mC-LLD63R for ; Thu, 3 Mar 2011 15:38:57 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id E2E103A6816 for ; Thu, 3 Mar 2011 15:38:56 -0800 (PST) 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 p23Ne1ap001499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 4 Mar 2011 00:40:04 +0100 (CET) Message-ID: <4D7026D1.6080407@sunet.se> Date: Fri, 04 Mar 2011 00:40:01 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] scheduling update X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 23:38:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The fortunes may yet be smiling on us... We've been offered a slot on Monday at 15:10 thats opened up. This isn't over though so don't exhale yet. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1wJtEACgkQ8Jx8FtbMZnfGSgCfU0HDlnJP4jQoFvVLH8lth5aE lyQAn1buF5vqi7TmCrJc/kEPE5GwLHqU =b5Il -----END PGP SIGNATURE----- From klaas@cisco.com Fri Mar 4 08:06:37 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674EF3A6802 for ; Fri, 4 Mar 2011 08:06:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1LdHxGVZv+C for ; Fri, 4 Mar 2011 08:06:36 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8683A3A67A1 for ; Fri, 4 Mar 2011 08:06:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=708; q=dns/txt; s=iport; t=1299254866; x=1300464466; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=stvCn0GqgOTDqPi3SkgNltZZeorrWA3paL4z1iNUTe0=; b=Zp41ww+Qfl8D96MdXTDfA9VETEQGA+NVpKB7UFdyB63e7nHOnmrGgWf0 rR8iFsVt4AWLfNS9VqdtEKC8dN5fVCYGnhqm3r6+77zyt8hZmxywUlkxv KQeRtqhWl/xAereS+4j3azP09SlAe4dSaXAvagbshg5F+0xabrPXkk4+9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGqdcE2rR7Hu/2dsb2JhbACmYnSjMZtshWEEjC8 X-IronPort-AV: E=Sophos;i="4.62,264,1297036800"; d="scan'208";a="269631933" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2011 16:07:45 +0000 Received: from macmini.wierenga.net (sjc-vpnasa-338.cisco.com [10.21.105.84]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p24G7jvP013641 for ; Fri, 4 Mar 2011 16:07:45 GMT Message-ID: <4D710E50.6080401@cisco.com> Date: Fri, 04 Mar 2011 17:07:44 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] things are looking good X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:06:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Good news, we do have 2 sessions after all: ABFAB Session 1 (2.5 hours) Thursday, Morning Session I 0900-1130 Room Name: Karlin I - ---------------------------------------------- ABFAB Session 2 (1 hour) Monday, Afternoon Session II 1510-1610 Room Name: Karlin I - ---------------------------------------------- Leif and I will send out an agenda soon. Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1xDlAACgkQH2Wy/p4XeFJ0OgCdEwFhMvinPzb4C4K5gr08qcFv gJsAoL+veR0/AnoTgmJB0USepTFj4W96 =5uoH -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Mon Mar 7 13:14:17 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375F23A6820 for ; Mon, 7 Mar 2011 13:14:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYhmzG8uFtUo for ; Mon, 7 Mar 2011 13:14:16 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by core3.amsl.com (Postfix) with ESMTP id BE0983A680C for ; Mon, 7 Mar 2011 13:14:15 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A7A9C1A9D353_D754AF0B for ; Mon, 7 Mar 2011 21:15:28 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 745631A9A25B_D754AF0F for ; Mon, 7 Mar 2011 21:15:28 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Mon, 7 Mar 2011 21:15:51 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: A proposal for dealing with EU data protection & identifiers Thread-Index: AcvdDMNlRyFe1IYbSWOvnNthpb1JCQ== Date: Mon, 7 Mar 2011 21:15:51 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {B51AD3C5-9538-4DEA-802D-AA7C314DB36C} x-cr-hashedpuzzle: ApWR Ch9g DJMe DWCY F/Nh GHI5 GNal GUD1 GcTK HDNF I1CF JF+c JohH J892 Kpuz K6+N; 1; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {B51AD3C5-9538-4DEA-802D-AA7C314DB36C}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Mon, 07 Mar 2011 21:15:19 GMT; QQAgAHAAcgBvAHAAbwBzAGEAbAAgAGYAbwByACAAZABlAGEAbABpAG4AZwAgAHcAaQB0AGgAIABFAFUAIABkAGEAdABhACAAcAByAG8AdABlAGMAdABpAG8AbgAgACYAIABpAGQAZQBuAHQAaQBmAGkAZQByAHMA x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:14:17 -0000 I admit that this is likely to be something of a minority interest. It's ha= rd to get people excited about privacy and data protection law and identifi= ers. However, I claim that it this an important problem to solve. Unfortunately,= understanding this requirement requires some knowledge of the implications= of EU data protection law on federated identity before. I provide a brief = summary below, before setting out my proposal. ** Problem description ** Very frequently, a relying party will want a unique identifier for a user. = Such identifiers are very useful for recognition (knowing that a user is th= e same as one seen previously) and accountability (so that abuse, etc, can = be tracked). Within federations today, it is common for identity providers to release th= ese identifiers to relying parties. These identifiers may name a user expli= citly (e.g. taking a value of an email address), but other identifiers can = name a user pseudonymously (e.g. by taking an opaque value) to improve priv= acy. The release of these identifiers often have legal implications. The EU data= protection regime treats all such identifiers as 'personally identifiable = information', because it can be linked directly or indirectly to a person. One of the practical consequences of this (within the EU) is that it is hig= hly desirable to have a legal contract between the issuer and consumer of a= n identifier. By default the IdP will be responsible for all misuse of the = identifier by the RP, with civil and/or criminal implications depending on = the EU member state in question. A contract is not an onerous requirement if -- for example -- the RP is for= mally providing some kind of service or content to the IdP organisation; th= ere will generally be a contract to control that business relationship rega= rdless. However, increasingly a user may want access to an RP that his IdP has no r= elationship with; and often that RP will want an identifier. Unfortunately,= addressing the general case (pairwise contracts between all IdPs and all S= Ps in federation) creates a legal scalability problem that people involved = in EU federation policy and governance get fairly exercised about. User consent is sometimes invoked as a mechanism for addressing identifier = release to 'unknown' RPs, but in general it's not a useful strategy within = the EU (though it might be fine in other jurisdictions). There are other approaches that use umbrella legal structures to control th= e risk, but EU member states take different views on the appropriateness of= these structures, and so they are not generally universally applicable. In summary it would be ideal if the RP could be provisioned with an identif= ier without invoking the EU data protection regime, at all. ** Proposal ** It turns out that the EU data protection regime does not have any opinions = about an IdP either confirming or denying if an identifier is associated wi= th a user. Thus, it appears that it is possible to entirely sidestep the data protecti= on regime by having the RP pose the question "please confirm that it is rea= sonable for this user to claim the identifier FOO", rather than the more co= nventional request "please provide an identifier for this user". =20 I don't know if this is true for other jurisdictions other than the EU. If = anyone else also has access to lawyers with DP knowledge of other jurisdict= ions, it would be wonderful if you could bounce this approach off them. I'm= currently working on the assumption that, because the EU DP regime is one = of the more difficult (or so I understand), it should work elsewhere, but t= hat's purely an assumption. The more educated opinions, the better. Therefore, my proposal is that we should seek to model identifier assignmen= t using a 'confirmation' model, rather than the conventional 'release' mode= l. I believe the semantics of the identifier confirmation model should be: Acceptor: "Is the identifier FOO associated with a user that you know about= ?". IdP: "Confirm", "Deny", "Neither Confirm Nor Deny". The value of FOO would be asserted by the initiator to the acceptor. It wou= ld take an opaque value that the IdP can verify is only likely to have been= generated by a user that it knows about. The value should generally be per= manent, but it should also be possible to change it on a per-acceptor basis= if necessary. We have some existing components in the ABFAB toolbox that I believe we can= re-use to avoid creating significant work. Sam and I bounced around a few = ideas earlier this morning, but as a first step we thought it would be usef= ul to know what the WG thinks of this as a general strategy.=20 Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Mon Mar 7 13:45:51 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E8CF3A6863 for ; Mon, 7 Mar 2011 13:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEBi2VRjMXQe for ; Mon, 7 Mar 2011 13:45:50 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id B63F928C0DF for ; Mon, 7 Mar 2011 13:45:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0FCFA2011F; Mon, 7 Mar 2011 16:44:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DCDBE432D; Mon, 7 Mar 2011 16:46:31 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> Date: Mon, 07 Mar 2011 16:46:31 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> (Josh Howlett's message of "Mon, 7 Mar 2011 21:15:51 +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: "abfab@ietf.org" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:45:51 -0000 So, Josh, I'd like to confirm that one consequence of what you're saying is that it would be entirely fine for an implementation to use NAIs including the actual username and for the IDP to only accept the NAI if the email address was correct? I.E. if we don't mind shooting privacy in the head, we have an easy solution already supported by the protocols involved. I'm not recommending that approach, just trying to understand it. From Josh.Howlett@ja.net Mon Mar 7 14:01:47 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2B0328C112 for ; Mon, 7 Mar 2011 14:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.493 X-Spam-Level: X-Spam-Status: No, score=-102.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VMSqGwzdQFg for ; Mon, 7 Mar 2011 14:01:45 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 851C028C0E3 for ; Mon, 7 Mar 2011 14:01:45 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id AFB9E4A6B65_D755612B; Mon, 7 Mar 2011 22:02:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 941DE4A6B5E_D755612F; Mon, 7 Mar 2011 22:02:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Mon, 7 Mar 2011 22:03:22 +0000 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] A proposal for dealing with EU data protection & identifiers Thread-Index: AcvdDMNlRyFe1IYbSWOvnNthpb1JCQABHxj+AAAKi4A= Date: Mon, 7 Mar 2011 22:03:21 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30C82AB@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {43C459C9-AED4-48CD-A3E7-F3CA2D2DEB69} x-cr-hashedpuzzle: AE5S BIup DDtd FrFC H0Ad H7q5 KhoM K9/x MV16 Mzvo PWoe S1w7 UTG6 V/Dj WgwV WkS3; 2; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnADsAaABhAHIAdABtAGEAbgBzAEAAcABhAGkAbgBsAGUAcwBzAC0AcwBlAGMAdQByAGkAdAB5AC4AYwBvAG0A; Sosha1_v1; 7; {43C459C9-AED4-48CD-A3E7-F3CA2D2DEB69}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Mon, 07 Mar 2011 22:02:50 GMT; UgBFADoAIABbAGEAYgBmAGEAYgBdACAAQQAgAHAAcgBvAHAAbwBzAGEAbAAgAGYAbwByACAAZABlAGEAbABpAG4AZwAgAHcAaQB0AGgAIABFAFUAIABkAGEAdABhACAAcAByAG8AdABlAGMAdABpAG8AbgAgACYAIABpAGQAZQBuAHQAaQBmAGkAZQByAHMA x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 22:01:47 -0000 > So, Josh, I'd like to confirm that one consequence of what you're > saying > is that it would be entirely fine for an implementation to use NAIs > including the actual username and for the IDP to only accept the NAI if > the email address was correct? I believe that is correct. When I was discussing this with our regulatory person, I framed the questio= n using a pseudonymous identifier by way of example (because that's how we = normally think about these problems) but he strongly implied that the princ= iple is equivalently applicable to other less privacy-preserving identifier= s. The key point is that the IdP isn't releasing information -- which is th= e legislation's basic test -- only an opinion. However, I'll ask him to exp= licitly ack your example tomorrow. Josh.=20 JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Mon Mar 7 14:09:57 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7158E3A687B for ; Mon, 7 Mar 2011 14:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSrAUErk2v-5 for ; Mon, 7 Mar 2011 14:09:56 -0800 (PST) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) by core3.amsl.com (Postfix) with ESMTP id 2A1083A6877 for ; Mon, 7 Mar 2011 14:09:56 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p27MB8Ok026153; Mon, 7 Mar 2011 23:11:08 +0100 Received: from 5ed00726.cm-7-1a.dynamic.ziggo.nl ([94.208.7.38] helo=[192.168.1.104]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pwidj-000KXW-9q; Mon, 07 Mar 2011 23:10:55 +0100 References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> <55DC663C2F4F9F439F23543E0078E8B30C82AB@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C82AB@EXC001> Mime-Version: 1.0 (iPad Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0D0E3F55-3589-47D3-AE44-54C5DD76EDE9@cisco.com> X-Mailer: iPad Mail (8C148) From: Klaas Wierenga Date: Mon, 7 Mar 2011 23:16:19 +0100 To: Josh Howlett X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vEgmb8EB - 3e47b55cba80 - 20110307 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.45 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 22:09:57 -0000 Hmm, interesting.... I am picturing flows like: - I think this is Sam, can you confirm? - ok, is it Josh then? Etc. Etc. ad nauseam Klaas Sent from my iPad On Mar 7, 2011, at 11:03 PM, "Josh Howlett" wrote: >> So, Josh, I'd like to confirm that one consequence of what you're >> saying >> is that it would be entirely fine for an implementation to use NAIs >> including the actual username and for the IDP to only accept the NAI if >> the email address was correct? >=20 > I believe that is correct. >=20 > When I was discussing this with our regulatory person, I framed the questi= on using a pseudonymous identifier by way of example (because that's how we n= ormally think about these problems) but he strongly implied that the princip= le is equivalently applicable to other less privacy-preserving identifiers. T= he key point is that the IdP isn't releasing information -- which is the leg= islation's basic test -- only an opinion. However, I'll ask him to explicitl= y ack your example tomorrow. >=20 > Josh.=20 >=20 >=20 > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024=20 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Mon Mar 7 15:08:36 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202DF28C121 for ; Mon, 7 Mar 2011 15:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ-16K2GgKPk for ; Mon, 7 Mar 2011 15:08:34 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id ACB5728C107 for ; Mon, 7 Mar 2011 15:08:34 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 459A0203A1; Mon, 7 Mar 2011 18:07:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CDB1F432D; Mon, 7 Mar 2011 18:09:27 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> <55DC663C2F4F9F439F23543E0078E8B30C82AB@EXC001> Date: Mon, 07 Mar 2011 18:09:27 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C82AB@EXC001> (Josh Howlett's message of "Mon, 7 Mar 2011 22:03:21 +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: "abfab@ietf.org" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 23:08:36 -0000 >>>>> "Josh" == Josh Howlett writes: >> So, Josh, I'd like to confirm that one consequence of what you're >> saying is that it would be entirely fine for an implementation to >> use NAIs including the actual username and for the IDP to only >> accept the NAI if the email address was correct? Josh> I believe that is correct. Josh> When I was discussing this with our regulatory person, I Josh> framed the question using a pseudonymous identifier by way of Josh> example (because that's how we normally think about these Josh> problems) but he strongly implied that the principle is Josh> equivalently applicable to other less privacy-preserving Josh> identifiers. The key point is that the IdP isn't releasing Josh> information -- which is the legislation's basic test -- only Josh> an opinion. However, I'll ask him to explicitly ack your Josh> example tomorrow. Does it matter whether the user has control over their machine? I.E. is it OK for an employer to force their employees to install moonshot clients that break their privacy? From Internet-Drafts@ietf.org Mon Mar 7 17:30:05 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE063A69E6; Mon, 7 Mar 2011 17:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySs68SSB4KZN; Mon, 7 Mar 2011 17:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BBD93A69DF; Mon, 7 Mar 2011 17:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110308013002.9905.25701.idtracker@localhost> Date: Mon, 07 Mar 2011 17:30:02 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 01:30:05 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond web (ABFAB) Use Cases Author(s) : R. Smith, et al Filename : draft-ietf-abfab-usecases-00.txt Pages : 7 Date : 2011-03-07 Federated authentication is most commonly associated with Web-based services, but there is growing interest in the application of federated authentication for non-Web services. The goal of this document is to drive the development of requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-abfab-usecases-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-07172119.I-D@ietf.org> --NextPart-- From gabilm@um.es Mon Mar 7 23:35:15 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B53E3A6910 for ; Mon, 7 Mar 2011 23:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-rq9EmHIAeH for ; Mon, 7 Mar 2011 23:35:14 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by core3.amsl.com (Postfix) with ESMTP id B8A353A690F for ; Mon, 7 Mar 2011 23:35:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id E03845D58E for ; Tue, 8 Mar 2011 08:36:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id spvY9EA0XAGq for ; Tue, 8 Mar 2011 08:36:26 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.151]) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPA id 0CDB85D580 for ; Tue, 8 Mar 2011 08:36:23 +0100 (CET) Message-ID: <4D75DCF7.5070903@um.es> Date: Tue, 08 Mar 2011 08:38:31 +0100 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> In-Reply-To: <20110308013002.9905.25701.idtracker@localhost> Content-Type: multipart/alternative; boundary="------------060802010306030000020301" Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 07:35:15 -0000 This is a multi-part message in MIME format. --------------060802010306030000020301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, I always thought in the campus use case like a good example for this wg. I mean, students and professors roaming between universities and requesting federated access to service such as FTP, SSH, SMTP, etc. etc. Something that eduroam is not providing currently. Do you plan on the description of this scenario in the draft? Best regards, Gabi. El 08/03/11 02:30, Internet-Drafts@ietf.org escribió: > A new Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. > > Title : Application Bridging for Federated Access Beyond web (ABFAB) Use Cases > > Author(s) : R. Smith, et al > Filename : draft-ietf-abfab-usecases-00.txt > Pages : 7 > Date : 2011-03-07 > > Federated authentication is most commonly associated with Web-based > services, but there is growing interest in the application of > federated authentication for non-Web services. The goal of this > document is to drive the development of requirements. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --------------060802010306030000020301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

I always thought in the campus use case like a good example for this wg. I mean, students and professors roaming between universities and requesting federated access to service such as FTP, SSH, SMTP, etc. etc. Something that eduroam is not providing currently. Do you plan on the description of this scenario in the draft?

Best regards, Gabi.

El 08/03/11 02:30, Internet-Drafts@ietf.org escribió: 
A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF.

    Title         : Application Bridging for Federated Access Beyond web (ABFAB) Use Cases

    Author(s)     : R. Smith, et al
    Filename      : draft-ietf-abfab-usecases-00.txt
    Pages         : 7
    Date          : 2011-03-07
    
Federated authentication is most commonly associated with Web-based
   services, but there is growing interest in the application of
   federated authentication for non-Web services.  The goal of this
   document is to drive the development of requirements.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.


_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab



-- 
----------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: gabilm@um.es
--------------060802010306030000020301-- From klaas@cisco.com Tue Mar 8 01:40:41 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8D1E3A67FD for ; Tue, 8 Mar 2011 01:40:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVC7eYh9MgF5 for ; Tue, 8 Mar 2011 01:40:40 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 8F4A13A67C0 for ; Tue, 8 Mar 2011 01:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=899; q=dns/txt; s=iport; t=1299577315; x=1300786915; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=WPIhJKo6GHpSrLuZ7xjUPnXo8ZlglBfBX4qC92GVj9c=; b=FGzpvSUDczWA6iomFacZe/Z0yh29v29oQDckDnEremkl0+yeBx2/2Fdq 1XY7MMMOFw1yl99ykjBlMH7tfuUkkqxNMKTVl6lebzZpvUiq52M+5ES6v Z/j+ToWt/9sUBEFDHzNYjoqTzpRDRn1aNvfODwa+qJvE9QCgLoqIx468Q 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEAIWIdU2Q/khMgWdsb2JhbACmPRUBARYiJaICnEOFYgSMMg X-IronPort-AV: E=Sophos;i="4.62,283,1297036800"; d="scan'208";a="20906033" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2011 09:41:54 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p289fsv4002402 for ; Tue, 8 Mar 2011 09:41:54 GMT Message-ID: <4D75F9E2.1000708@cisco.com> Date: Tue, 08 Mar 2011 10:41:54 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] clarification on WG adoption policy X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:40:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, There was a question raised as to what the WG-chairs policy for adoption as WG documents was, given that we accepted the use-cases and diameter draft without explicit consensus by the WG. So just to clarify, we have decided to assume consensus to accept as WG documents those documents that are both: - - explicitly listed as deliverables in the charter - - have WG consensus on the document editor All other drafts will have to go through the normal consensus proces. Hope this clarifies our position (and has the consensus of the WG ;-) Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk11+eIACgkQH2Wy/p4XeFLoKgCdEzlbLcWu4rxRPp4tsr/+R0Yr MrIAoJL6ThNGEo3scAMo1drmZBS+nmI0 =lNoS -----END PGP SIGNATURE----- From lear@cisco.com Tue Mar 8 02:08:58 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B73343A681A for ; Tue, 8 Mar 2011 02:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.583 X-Spam-Level: X-Spam-Status: No, score=-110.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSdxOTzdzPFx for ; Tue, 8 Mar 2011 02:08:58 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id BAA0E3A67B8 for ; Tue, 8 Mar 2011 02:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=749; q=dns/txt; s=iport; t=1299579012; x=1300788612; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=kJLwfuuEuYqi+ued3hFCu+eeTKvgV6LPu5CEnhC3oKI=; b=ZdBp2xvORzPfP7fvSnUnyFslLTPeUUqDaFDX6xIjRaD+8cpABhszlvMp pAQPN63FoJjgflfWZcdXzmMig3MlsYkb9k3WrPGo5xCp1/ZN9vul0RJU7 KR10jga+yN43dOAh/WTx6wW172cXnCPvttuD7xwQoRQj7WEngtimqj/WS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkEAP+LdU2Q/khLgWdsb2JhbACELKIRFQEBFiIloXaLDJE8gSeCBgKBPXYEjDI X-IronPort-AV: E=Sophos;i="4.62,283,1297036800"; d="scan'208";a="20909540" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2011 10:10:11 +0000 Received: from ams3-vpn-dhcp5569.cisco.com (ams3-vpn-dhcp5569.cisco.com [10.61.85.192]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p28AABTA003310; Tue, 8 Mar 2011 10:10:11 GMT Message-ID: <4D760067.7030005@cisco.com> Date: Tue, 08 Mar 2011 11:09:43 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 10:08:58 -0000 Josh, First, I would like to understand more about the situation where the IdP has neither a contract with the service provider nor with the federation to which they both belong. That is- what are the ad hoc circumstances? Thanks, Eliot On 3/7/11 10:15 PM, Josh Howlett wrote: > Acceptor: "Is the identifier FOO associated with a user that you know about?". > IdP: "Confirm", "Deny", "Neither Confirm Nor Deny". > I suspect you would prefer a slightly different question and answer: Acceptor: "Do you authorize the current user (whose credentials you will verify or have verified) to use my local identifier FOO"? Answer: "Yes" / "no" A "yes" answer might be accompanied additional information, as allowed by policy. From leifj@sunet.se Tue Mar 8 02:21:48 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBE013A67ED for ; Tue, 8 Mar 2011 02:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFuJIOI5A5Xm for ; Tue, 8 Mar 2011 02:21:47 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 4EF0B3A67DA for ; Tue, 8 Mar 2011 02:21:47 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p28AMw0s001296 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Mar 2011 11:23:01 +0100 (CET) Message-ID: <4D760382.1060000@sunet.se> Date: Tue, 08 Mar 2011 11:22:58 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 10:21:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, Here is the proposed agenda. The basic idea is that we do use cases and architecture and general interest in the first session and hard-core and new documents in the second session. Bash away! Leif & Klaas abfab1 (monday - 1 hr) - - Agenda bashing and Note Well (5min) - - Core non-normative status (30 min) - draft-lear-abfab-arch-xx - draft-abfab-usecases - - Moonshot implementation status (25 min) abfab2 (thursday - 2.5hrs) - - Agenda bashing and Note Well (5min) - - Core normative status (60min) - draft-ietf-abfab-gss-eap-xx - draft-ietf-abfab-gss-eap-naming-xx - draft-ietf-abfab-aaa-saml-xx - - New documents (40 min) - abfab diameter draft - draft-howlett-radsec-knp - draft-adamson-nfsv4-multi-domain-access (tentative) - - Administrativia and AOB (15 min) - OID management -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk12A34ACgkQ8Jx8FtbMZndYRQCdE77kQBGNcwk1eeTrACNZE7hr O3QAoMNg0gw/SJy8JUWTDm3vO79muPxR =l6Dx -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Tue Mar 8 02:58:15 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 727BB3A6839 for ; Tue, 8 Mar 2011 02:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb91w6pO5+HO for ; Tue, 8 Mar 2011 02:58:14 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 4F4023A67DA for ; Tue, 8 Mar 2011 02:58:14 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 83EA64A6B63_D760C0FB; Tue, 8 Mar 2011 10:59:27 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 6434A4A6B4A_D760C0FF; Tue, 8 Mar 2011 10:59:27 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 8 Mar 2011 10:59:51 +0000 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] agenda Thread-Index: AQHL3XroyONlIKWAKUuW6hEJCP4hdJQjPH2w Date: Tue, 8 Mar 2011 10:59:50 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> References: <4D760382.1060000@sunet.se> In-Reply-To: <4D760382.1060000@sunet.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 10:58:15 -0000 Hi Leif, Thanks for pulling this together. However I'm wondering if it's really nece= ssary to devote nearly 50% of the first session to discussion of an ABFAB i= mplementation. I would be more inclined to spend this time on discussion of= the architecture and use-case documents. Sam will have a better sense of this than I, but I suspect that the things = we've discovered in the course of implementation can be conveyed more effic= iently during the actual document discussions. If the WG is interested in a 'general interest' item, we could do a present= ation on our implementation's UI/UX design; we're expecting to feed our imp= lementation experience and usability analysis into the 'Usability considera= tions' document. We're unlikely to have running UI code by this point, but = we'll have mock-ups. Having said all that, if there really is strong interest from the WG in a M= oonshot implementation status, then we'll be very happy to oblige. =20 Josh. > - - Moonshot implementation status (25 min) >=20 > abfab2 (thursday - 2.5hrs) >=20 > - - Agenda bashing and Note Well (5min) > - - Core normative status (60min) > - draft-ietf-abfab-gss-eap-xx > - draft-ietf-abfab-gss-eap-naming-xx > - draft-ietf-abfab-aaa-saml-xx > - - New documents (40 min) > - abfab diameter draft > - draft-howlett-radsec-knp > - draft-adamson-nfsv4-multi-domain-access (tentative) > - - Administrativia and AOB (15 min) > - OID management > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk12A34ACgkQ8Jx8FtbMZndYRQCdE77kQBGNcwk1eeTrACNZE7hr > O3QAoMNg0gw/SJy8JUWTDm3vO79muPxR > =3Dl6Dx > -----END PGP SIGNATURE----- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Tue Mar 8 03:08:10 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFA03A6834 for ; Tue, 8 Mar 2011 03:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVh3lhaZ1tyS for ; Tue, 8 Mar 2011 03:08:09 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 04C2A3A684A for ; Tue, 8 Mar 2011 03:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=2823; q=dns/txt; s=iport; t=1299582564; x=1300792164; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=LgTW0hvHndyScJXZFbWemzuoN7pBxC+QYOoH4hHAe54=; b=SrccmeYSY8cPtFYNLhHbgWIAuZndGUUPbVrwQ5gghDt8/lyZISEiOFx5 l8BzPwfbiZOKfj13Agw+LHCoFdTzk80HZb2ISyS1qkmzKe7LbU02f7MIt sb4qCcQwNIGgKYOQG4YtA2Ozty3pNsEKgNhvOM6ucN68UjqqhVihv5WA8 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgFAJyddU2Q/khMgWdsb2JhbACYUo1rFQEBFiIlohWcToViBIwy X-IronPort-AV: E=Sophos;i="4.62,283,1297036800"; d="scan'208";a="20916048" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2011 11:09:21 +0000 Received: from macmini.wierenga.net (ams-kwiereng-8712.cisco.com [10.55.220.243]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p28B9LRJ029010 for ; Tue, 8 Mar 2011 11:09:21 GMT Message-ID: <4D760E61.6010706@cisco.com> Date: Tue, 08 Mar 2011 12:09:21 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: abfab@ietf.org References: <4D760382.1060000@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 11:08:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/8/11 11:59 AM, Josh Howlett wrote: Josh, > Thanks for pulling this together. However I'm wondering if it's > really necessary to devote nearly 50% of the first session to > discussion of an ABFAB implementation. I would be more inclined to > spend this time on discussion of the architecture and use-case > documents. Well, one way of saying it is "nearly 50%", the other is "only 25 minutes" ;-) Do you really think you can do with much less than that? Klaas > > Sam will have a better sense of this than I, but I suspect that the > things we've discovered in the course of implementation can be > conveyed more efficiently during the actual document discussions. > > If the WG is interested in a 'general interest' item, we could do a > presentation on our implementation's UI/UX design; we're expecting to > feed our implementation experience and usability analysis into the > 'Usability considerations' document. We're unlikely to have running > UI code by this point, but we'll have mock-ups. > > Having said all that, if there really is strong interest from the WG > in a Moonshot implementation status, then we'll be very happy to > oblige. > > Josh. > >> - - Moonshot implementation status (25 min) >> >> abfab2 (thursday - 2.5hrs) >> >> - - Agenda bashing and Note Well (5min) - - Core normative status >> (60min) - draft-ietf-abfab-gss-eap-xx - >> draft-ietf-abfab-gss-eap-naming-xx - draft-ietf-abfab-aaa-saml-xx - >> - New documents (40 min) - abfab diameter draft - >> draft-howlett-radsec-knp - draft-adamson-nfsv4-multi-domain-access >> (tentative) - - Administrativia and AOB (15 min) - OID management >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk12A34ACgkQ8Jx8FtbMZndYRQCdE77kQBGNcwk1eeTrACNZE7hr >> O3QAoMNg0gw/SJy8JUWTDm3vO79muPxR =l6Dx -----END PGP SIGNATURE----- >> _______________________________________________ abfab mailing list >> abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab > > JANET(UK) is a trading name of The JNT Association, a company > limited by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ abfab mailing list > abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk12DmAACgkQH2Wy/p4XeFIiEwCdF+HNS4PV+z5y2T1NjcVFUeLs 0f0AmwesMoAK79UqL05cTksY8eLb5ftG =LRZL -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Tue Mar 8 03:19:14 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D7E3A684F for ; Tue, 8 Mar 2011 03:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4M0SczK-clU for ; Tue, 8 Mar 2011 03:19:13 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by core3.amsl.com (Postfix) with ESMTP id 655773A6834 for ; Tue, 8 Mar 2011 03:19:13 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 2296E1A9D50B_D7610FBB; Tue, 8 Mar 2011 11:20:27 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 178D31A9D4F8_D7610FBF; Tue, 8 Mar 2011 11:20:27 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 8 Mar 2011 11:20:50 +0000 From: Josh Howlett To: Klaas Wierenga , "abfab@ietf.org" Thread-Topic: [abfab] agenda Thread-Index: AQHL3XroyONlIKWAKUuW6hEJCP4hdJQjPH2wgAALGYCAAAER0A== Date: Tue, 8 Mar 2011 11:20:50 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30C905F@EXC001> References: <4D760382.1060000@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> <4D760E61.6010706@cisco.com> In-Reply-To: <4D760E61.6010706@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 11:19:14 -0000 Klaas, > > Thanks for pulling this together. However I'm wondering if it's > > really necessary to devote nearly 50% of the first session to > > discussion of an ABFAB implementation. I would be more inclined to > > spend this time on discussion of the architecture and use-case > > documents. >=20 > Well, one way of saying it is "nearly 50%", the other is "only 25 > minutes" ;-) Do you really think you can do with much less than that? Well, I'm questioning whether a Moonshot update is appropriate given the de= mands on time. We would be very happy to do an update, but I wouldn't want to consume time= that could be better spent discussing ABFAB documents. Do Eliot and Rhys, as editors of the other two documents, have a view on th= is? I was assuming that discussion of these two docs alone could take 60 mi= nutes, but perhaps not. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From leifj@sunet.se Tue Mar 8 03:33:36 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C23A83A67DA for ; Tue, 8 Mar 2011 03:33:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOo+r3LfsfUq for ; Tue, 8 Mar 2011 03:33:35 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 7E7023A6857 for ; Tue, 8 Mar 2011 03:33:35 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p28BYkZe028000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Mar 2011 12:34:49 +0100 (CET) Message-ID: <4D761456.1010409@sunet.se> Date: Tue, 08 Mar 2011 12:34:46 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <4D760382.1060000@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> <4D760E61.6010706@cisco.com> <55DC663C2F4F9F439F23543E0078E8B30C905F@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C905F@EXC001> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 11:33:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/2011 12:20 PM, Josh Howlett wrote: > Klaas, > >>> Thanks for pulling this together. However I'm wondering if it's >>> really necessary to devote nearly 50% of the first session to >>> discussion of an ABFAB implementation. I would be more inclined to >>> spend this time on discussion of the architecture and use-case >>> documents. >> >> Well, one way of saying it is "nearly 50%", the other is "only 25 >> minutes" ;-) Do you really think you can do with much less than that? > > Well, I'm questioning whether a Moonshot update is appropriate given the demands on time. > > We would be very happy to do an update, but I wouldn't want to consume time that could be better spent discussing ABFAB documents. > > Do Eliot and Rhys, as editors of the other two documents, have a view on this? I was assuming that discussion of these two docs alone could take 60 minutes, but perhaps not. I think we could slim the moonshot update a bit if you like but I also think there should interest from the community in seeing that abfab isn't just an intellectual exercise. How about we give you guys a 15 minute slot at least for an update on the implementation work and devote a 15 minute slot to technical discussion and feedback on the topics covered during the session? In planning this we've looked at a model which has been successful in the yang WG which also separate work into a first session which is more accessible to people who are not deeply involved in the core protocol work and a second session which assumes more deep involvement from participants. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk12FFIACgkQ8Jx8FtbMZndO8wCeImTY4mHb8wO69YA3R099cUtR XYgAoMHN5dsA9pKZQc0WI4y1+iqWttH6 =7zI7 -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Tue Mar 8 03:50:53 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8C973A6843 for ; Tue, 8 Mar 2011 03:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bD5Z6tKXyps2 for ; Tue, 8 Mar 2011 03:50:53 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id E9F493A683E for ; Tue, 8 Mar 2011 03:50:52 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id ED0A34A6B5E_D761866B; Tue, 8 Mar 2011 11:52:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id DD0154A6B3C_D761866F; Tue, 8 Mar 2011 11:52:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 8 Mar 2011 11:52:30 +0000 From: Josh Howlett To: Leif Johansson , "abfab@ietf.org" Thread-Topic: [abfab] agenda Thread-Index: AQHL3XroyONlIKWAKUuW6hEJCP4hdJQjPH2wgAALGYCAAAER0IAABgkAgAADyXA= Date: Tue, 8 Mar 2011 11:52:29 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30C9178@EXC001> References: <4D760382.1060000@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> <4D760E61.6010706@cisco.com> <55DC663C2F4F9F439F23543E0078E8B30C905F@EXC001> <4D761456.1010409@sunet.se> In-Reply-To: <4D761456.1010409@sunet.se> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 11:50:53 -0000 > I think we could slim the moonshot update a bit if you like but I > also think there should interest from the community in seeing that > abfab isn't just an intellectual exercise. Sure, if you think that would be helpful. As it happens we'll have material= s and demo kit from the developer meeting, so we'll have something tangible= to demo. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Mar 8 04:09:49 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35693A6859 for ; Tue, 8 Mar 2011 04:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.245 X-Spam-Level: X-Spam-Status: No, score=-2.245 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgV-QMe8zPMW for ; Tue, 8 Mar 2011 04:09:48 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 400D63A684F for ; Tue, 8 Mar 2011 04:09:48 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 12707201A2; Tue, 8 Mar 2011 07:08:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2647D432D; Tue, 8 Mar 2011 07:10:37 -0500 (EST) From: Sam Hartman To: Klaas Wierenga References: <4D75F9E2.1000708@cisco.com> Date: Tue, 08 Mar 2011 07:10:37 -0500 In-Reply-To: <4D75F9E2.1000708@cisco.com> (Klaas Wierenga's message of "Tue, 08 Mar 2011 10:41:54 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] clarification on WG adoption policy X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 12:09:49 -0000 >>>>> "Klaas" == Klaas Wierenga writes: Klaas> Hi all, There was a question raised as to what the WG-chairs Klaas> policy for adoption as WG documents was, given that we Klaas> accepted the use-cases and diameter draft without explicit Klaas> consensus by the WG. So just to clarify, we have decided to Klaas> assume consensus to accept as WG documents those documents Klaas> that are both: This certainly seems productive to me. It does mean that we'll have to either have a call fairly early on in the lifecycle of a doc like the usecases document to confirm there's a presumption of consensus or not have that presumption. The issue comes up if we cannot get consensus to change a document. If there is a presumption of consensus, the fact that you cannot get consensus to change means that you're left with the existing text. If there is no such presumption--for example, when the WG adopts a document unseen without discussion of the text either during the chartering process or later--then you're stuck if you cannot get consensus either to make the change or to agree to the existing text. Note that what we're doing here is reasonably common in the security area even if not so common say in the Internet or routing area. --Sam From leifj@mnt.se Tue Mar 8 04:12:43 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E694C3A6869 for ; Tue, 8 Mar 2011 04:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldouZZoBUtxa for ; Tue, 8 Mar 2011 04:12:43 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id D3EE93A6839 for ; Tue, 8 Mar 2011 04:12:42 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p28CDrIA008429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Mar 2011 13:13:57 +0100 (CET) Message-ID: <4D761D81.9040405@mnt.se> Date: Tue, 08 Mar 2011 13:13:53 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <4D75F9E2.1000708@cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] clarification on WG adoption policy X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 12:12:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > process or later--then you're stuck if you cannot get consensus either > to make the change or to agree to the existing text. Right - we (the chairs) have to be cluefull enough to detect a possibly contentious submission and not accept it outright. We'll do our very best! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk12HYEACgkQ8Jx8FtbMZnf/vwCfX1lQQJ+IWi7r8vpr2urTGHtK wpkAnjsTtsI4PH+mF+bc/KuYijXWPq1c =psAd -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Tue Mar 8 04:14:52 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED313A6868 for ; Tue, 8 Mar 2011 04:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKA+IL1WK8AS for ; Tue, 8 Mar 2011 04:14:51 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by core3.amsl.com (Postfix) with ESMTP id B4FB93A6821 for ; Tue, 8 Mar 2011 04:14:51 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 17BF91A9D522_D761E06B for ; Tue, 8 Mar 2011 12:16:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 0EF501A9D4D9_D761E06F for ; Tue, 8 Mar 2011 12:16:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 8 Mar 2011 12:16:29 +0000 From: Josh Howlett To: Josh Howlett , "abfab@ietf.org" Thread-Topic: A proposal for dealing with EU data protection & identifiers Thread-Index: AcvdDMNlRyFe1IYbSWOvnNthpb1JCQAevupg Date: Tue, 8 Mar 2011 12:16:29 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30C9275@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {D04F7183-175F-49AA-9C64-6026EC507AF8} x-cr-hashedpuzzle: Bna8 DiJW Dn5i DtG5 EPIH Gpnu Gxff HKA2 HoW2 IihZ IsWp I11r I2MZ JvIb J53+ KOet; 1; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {D04F7183-175F-49AA-9C64-6026EC507AF8}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Tue, 08 Mar 2011 12:15:58 GMT; UgBFADoAIABBACAAcAByAG8AcABvAHMAYQBsACAAZgBvAHIAIABkAGUAYQBsAGkAbgBnACAAdwBpAHQAaAAgAEUAVQAgAGQAYQB0AGEAIABwAHIAbwB0AGUAYwB0AGkAbwBuACAAJgAgAGkAZABlAG4AdABpAGYAaQBlAHIAcwA= x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 12:14:52 -0000 > It turns out that the EU data protection regime does not have any > opinions about an IdP either confirming or denying if an identifier is > associated with a user. Following further discussion, it turns out that life isn't quite so simple,= which largely breaks my proposal and so I retract it. However there is definitely value in the acceptor constructing the initiato= r name from data provided by the initiator, rather than the AAA server. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Mar 8 04:34:11 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F1A3A6810 for ; Tue, 8 Mar 2011 04:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzVLW4LYLija for ; Tue, 8 Mar 2011 04:34:11 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 1DB2B3A63D2 for ; Tue, 8 Mar 2011 04:34:11 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5360720265; Tue, 8 Mar 2011 07:32:45 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 65485432D; Tue, 8 Mar 2011 07:35:04 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <4D760382.1060000@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> <4D760E61.6010706@cisco.com> <55DC663C2F4F9F439F23543E0078E8B30C905F@EXC001> <4D761456.1010409@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C9178@EXC001> Date: Tue, 08 Mar 2011 07:35:04 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C9178@EXC001> (Josh Howlett's message of "Tue, 8 Mar 2011 11:52:29 +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: "abfab@ietf.org" Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 12:34:11 -0000 Remember that we'll have spent a day testing and working on things just before our meeting. I think things will go one of two ways. 1) The sorts of issues we run into will not be related to the ABFAB specs. We'll be discussing how to get code working, how to do application integration. If this happens we'll probably not have more than five minutes of "Hey, here's some code, join our mailing list." 2) The infrastructure works well enough that we actually do a lot of testing. While I think the ABFAB specs are doing well, I also have enough familiarity with the IETF to believe that any first testing event will produce 25 minutes of discussion of the specs that is very on-target and will be well worth our time. Who knows. another implementation may pop up and make things really useful on the spec front. --Sam From hartmans@painless-security.com Tue Mar 8 04:35:19 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC1553A67E4 for ; Tue, 8 Mar 2011 04:35:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYTG96mGh+La for ; Tue, 8 Mar 2011 04:35:19 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id F292C3A63D2 for ; Tue, 8 Mar 2011 04:35:18 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 35134201A2; Tue, 8 Mar 2011 07:33:53 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 37171432D; Tue, 8 Mar 2011 07:36:12 -0500 (EST) From: Sam Hartman To: Gabriel =?iso-8859-1?Q?L=F3pez?= References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> Date: Tue, 08 Mar 2011 07:36:12 -0500 In-Reply-To: <4D75DCF7.5070903@um.es> ("Gabriel =?iso-8859-1?Q?L=F3pez=22'?= =?iso-8859-1?Q?s?= message of "Tue, 08 Mar 2011 08:38:31 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: [abfab] Campus use case X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 12:35:19 -0000 Could we get you to work on some text for this campus use case? Also, do e actually have campuses who have indicated that deploying a new technology to solve this use case would be worthwhile for them? From Josh.Howlett@ja.net Tue Mar 8 04:50:57 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378753A6767 for ; Tue, 8 Mar 2011 04:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLwVME2RkmlK for ; Tue, 8 Mar 2011 04:50:56 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id DDF513A63D2 for ; Tue, 8 Mar 2011 04:50:55 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id B54FC4A6B3C_D762679B; Tue, 8 Mar 2011 12:52:09 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id A84144A6B39_D762679F; Tue, 8 Mar 2011 12:52:09 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 8 Mar 2011 12:52:33 +0000 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] agenda Thread-Index: AQHL3Y0/yONlIKWAKUuW6hEJCP4hdJQjZABg Date: Tue, 8 Mar 2011 12:52:32 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30C943D@EXC001> References: <4D760382.1060000@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> <4D760E61.6010706@cisco.com> <55DC663C2F4F9F439F23543E0078E8B30C905F@EXC001> <4D761456.1010409@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C9178@EXC001> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Howlett , "abfab@ietf.org" , Josh Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 12:50:57 -0000 Leif, Klaas, Seems like I am completely out-voted. We'll take the 25 minutes if it's sti= ll on the table; thank you again :-) Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From lear@cisco.com Tue Mar 8 05:01:30 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10BF3A6839 for ; Tue, 8 Mar 2011 05:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0CYHRLGeRX5 for ; Tue, 8 Mar 2011 05:01:27 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D08C03A6821 for ; Tue, 8 Mar 2011 05:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1581; q=dns/txt; s=iport; t=1299589362; x=1300798962; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pBGVIniNwBWW5rCmK1+jIKxc1Br6//9hQ8wuWADcNIA=; b=Y+dAUOEVf/GWlAmgQn6HhkEPzDocpE7lwkXfd+g60M6PKQ/wpn+nJ4w3 W+RAMA+NVU/gkHhluAAXZZMaOVBk1cjhxlR0Azi6+vT0ZbD3piF1/ec0j YpBBoSBAmcSclIY+UBokmuF9YalQD48/kmMflIQnxXaFScXmKZfD+Z7gW U=; X-IronPort-AV: E=Sophos;i="4.62,284,1297036800"; d="scan'208";a="78306677" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2011 13:02:39 +0000 Received: from ams3-vpn-dhcp5569.cisco.com (ams3-vpn-dhcp5569.cisco.com [10.61.85.192]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p28D2dn4013879; Tue, 8 Mar 2011 13:02:39 GMT Message-ID: <4D7628D2.3060104@cisco.com> Date: Tue, 08 Mar 2011 14:02:10 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Josh Howlett References: <4D760382.1060000@sunet.se> <55DC663C2F4F9F439F23543E0078E8B30C8E85@EXC001> <4D760E61.6010706@cisco.com> <55DC663C2F4F9F439F23543E0078E8B30C905F@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C905F@EXC001> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 13:01:30 -0000 Hi Josh, Here is what I would rather not have happen: we do an update on Moonshot / implementation AND THEN repeat the same issues in document review (or visa versa). So long as that doesn't happen, talking about running code is a good thing. Eliot On 3/8/11 12:20 PM, Josh Howlett wrote: > Klaas, > >>> Thanks for pulling this together. However I'm wondering if it's >>> really necessary to devote nearly 50% of the first session to >>> discussion of an ABFAB implementation. I would be more inclined to >>> spend this time on discussion of the architecture and use-case >>> documents. >> Well, one way of saying it is "nearly 50%", the other is "only 25 >> minutes" ;-) Do you really think you can do with much less than that? > Well, I'm questioning whether a Moonshot update is appropriate given the demands on time. > > We would be very happy to do an update, but I wouldn't want to consume time that could be better spent discussing ABFAB documents. > > Do Eliot and Rhys, as editors of the other two documents, have a view on this? I was assuming that discussion of these two docs alone could take 60 minutes, but perhaps not. > > Josh. > > > > JANET(UK) is a trading name of The JNT Association, a company limited > by guarantee which is registered in England under No. 2881024 > and whose Registered Office is at Lumen House, Library Avenue, > Harwell Oxford, Didcot, Oxfordshire. OX11 0SG > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From cantor.2@osu.edu Tue Mar 8 06:46:17 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAD993A689E for ; Tue, 8 Mar 2011 06:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSNkShvk4E7H for ; Tue, 8 Mar 2011 06:46:17 -0800 (PST) Received: from defang11.it.ohio-state.edu (defang11.it.ohio-state.edu [128.146.216.18]) by core3.amsl.com (Postfix) with ESMTP id C7B9D3A6859 for ; Tue, 8 Mar 2011 06:46:14 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang11.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p28ElRB9001691; Tue, 8 Mar 2011 09:47:27 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Tue, 8 Mar 2011 09:43:29 -0500 From: "Cantor, Scott E." To: Sam Hartman , =?iso-8859-1?Q?Gabriel_L=F3pez?= Thread-Topic: [abfab] Campus use case Thread-Index: AQHL3YzpRglWYN7O/ke2G/kstzObNpQjhBIg Date: Tue, 8 Mar 2011 14:47:36 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100C51DD@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; 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.18 Cc: "abfab@ietf.org" Subject: Re: [abfab] Campus use case X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:46:17 -0000 > Also, do e actually have campuses who have indicated that deploying a > new technology to solve this use case would be worthwhile for them? We have to do something. For some of us that something might be deploying a= SAML solution, or it might be EAP for some, and with ssh it may well just = be pushing keys around, but the current state is a problem. -- Scott From cantor.2@osu.edu Tue Mar 8 07:02:07 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7BE63A68A6 for ; Tue, 8 Mar 2011 07:02:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWUb-KYyK2wR for ; Tue, 8 Mar 2011 07:02:07 -0800 (PST) Received: from defang12.it.ohio-state.edu (defang12.it.ohio-state.edu [128.146.216.21]) by core3.amsl.com (Postfix) with ESMTP id D158E3A689A for ; Tue, 8 Mar 2011 07:02:06 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang12.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p28F3FNv021901; Tue, 8 Mar 2011 10:03:15 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Tue, 8 Mar 2011 09:59:17 -0500 From: "Cantor, Scott E." To: Eliot Lear , Josh Howlett Thread-Topic: [abfab] A proposal for dealing with EU data protection & identifiers Thread-Index: AQHL3aFlbVO9pmPmtUSKlP8hTRM5fA== Date: Tue, 8 Mar 2011 15:03:14 +0000 Message-ID: In-Reply-To: <4D760067.7030005@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <4fb7d322-eddf-4d82-8413-bcb6eb3ac524> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; 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.21 Cc: "abfab@ietf.org" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 15:02:07 -0000 >First, I would like to understand more about the situation where the IdP >has neither a contract with the service provider nor with the federation >to which they both belong. That is- what are the ad hoc circumstances? The contract with the federation doesn't generally address release of data to anybody, so it doesn't address liability of the IdP for doing so. The canonical circumstance is any collaboration across a pair of universities. If we can't figure out how to address that problem with federation, it will get addressed by Google and our users will just ignore all those regulations. -- Scott From hotz@jpl.nasa.gov Tue Mar 8 09:27:18 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C6543A691C for ; Tue, 8 Mar 2011 09:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmnhJSD2djuZ for ; Tue, 8 Mar 2011 09:27:17 -0800 (PST) Received: from mail.jpl.nasa.gov (sentrion3.jpl.nasa.gov [128.149.139.109]) by core3.amsl.com (Postfix) with ESMTP id 2BE783A68F5 for ; Tue, 8 Mar 2011 09:27:16 -0800 (PST) Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Switch-3.4.3/Switch-3.4.3) with ESMTP id p28HSUG0021024 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Tue, 8 Mar 2011 09:28:31 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Henry B. Hotz" In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> Date: Tue, 8 Mar 2011 09:28:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <737C77C3-43A7-4046-9188-C5017A272517@jpl.nasa.gov> References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> To: Josh Howlett X-Mailer: Apple Mail (2.1082) X-Source-IP: laphotz.jpl.nasa.gov [128.149.133.44] X-Source-Sender: hotz@jpl.nasa.gov X-AUTH: Authorized X-Mailman-Approved-At: Tue, 08 Mar 2011 09:28:57 -0800 Cc: "abfab@ietf.org" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 17:27:18 -0000 On Mar 7, 2011, at 1:15 PM, Josh Howlett wrote: > I admit that this is likely to be something of a minority interest. = It's hard to get people excited about privacy and data protection law = and identifiers. To the contrary, I believe that solutions which satisfy not merely the = legal requirements but also maximize the user's privacy are very broadly = of interest. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From Josh.Howlett@ja.net Wed Mar 9 00:28:58 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3BEF3A689E for ; Wed, 9 Mar 2011 00:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GVHMQSlbq4N for ; Wed, 9 Mar 2011 00:28:57 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 94A193A6879 for ; Wed, 9 Mar 2011 00:28:57 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5C30B4A6B6C_D773A94B; Wed, 9 Mar 2011 08:30:12 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 4A72D4A6B39_D773A94F; Wed, 9 Mar 2011 08:30:12 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Wed, 9 Mar 2011 08:30:35 +0000 From: Josh Howlett To: "Henry B. Hotz" Thread-Topic: [abfab] A proposal for dealing with EU data protection & identifiers Thread-Index: AcvdDMNlRyFe1IYbSWOvnNthpb1JCQAqXpYAAB76z7A= Date: Wed, 9 Mar 2011 08:30:35 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30CB89C@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> <737C77C3-43A7-4046-9188-C5017A272517@jpl.nasa.gov> In-Reply-To: <737C77C3-43A7-4046-9188-C5017A272517@jpl.nasa.gov> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {8AE3298F-1D61-409A-891E-AC08F3D9275E} x-cr-hashedpuzzle: ABxK AHiD AzAF BBfc BXTL BfgT Ca5A EF9h F+Cr IuMn JhJk LyJc Od/s QYO7 R0nq S1vC; 2; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnADsAaABvAHQAegBAAGoAcABsAC4AbgBhAHMAYQAuAGcAbwB2AA==; Sosha1_v1; 7; {8AE3298F-1D61-409A-891E-AC08F3D9275E}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Wed, 09 Mar 2011 08:30:04 GMT; UgBFADoAIABbAGEAYgBmAGEAYgBdACAAQQAgAHAAcgBvAHAAbwBzAGEAbAAgAGYAbwByACAAZABlAGEAbABpAG4AZwAgAHcAaQB0AGgAIABFAFUAIABkAGEAdABhACAAcAByAG8AdABlAGMAdABpAG8AbgAgACYAIABpAGQAZQBuAHQAaQBmAGkAZQByAHMA x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 08:28:58 -0000 > To the contrary, I believe that solutions which satisfy not merely the > legal requirements but also maximize the user's privacy are very > broadly of interest. I do hope so. Is there anyone who would be interested in working on definin= g privacy and data protection requirements for ABFAB? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From lear@cisco.com Wed Mar 9 01:04:29 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1303A68D3 for ; Wed, 9 Mar 2011 01:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sI2JUo-ZG2+x for ; Wed, 9 Mar 2011 01:04:28 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 7D95F3A68CB for ; Wed, 9 Mar 2011 01:04:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=268; q=dns/txt; s=iport; t=1299661545; x=1300871145; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TxqazT2Mdnop/XOv6R+ZzBBVDN8vqojhSI3uL82KVmw=; b=QnwULlpeUFkwQJA7cI5IBGfCd7DivPy8enBt9tB7utPrFYkvluKKEIS+ lmjtUVskP57cDOxGn83t678onZLyIYQ9eUvUdr7ryHN8RZHvIAK/dSpND iETAZFeycsOvBXfwtVNZa68PbOcwJM5M0gLiwSM/Nt2SEKI3LEK1AHpd1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQEANDRdk2Q/khNgWdsb2JhbACELKI/FQEBFiIlpluLDJEYgSeDSHYEjDo X-IronPort-AV: E=Sophos;i="4.62,289,1297036800"; d="scan'208";a="20993946" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 09 Mar 2011 09:05:43 +0000 Received: from ams3-vpn-dhcp5569.cisco.com (ams3-vpn-dhcp5569.cisco.com [10.61.85.192]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2995haU015723; Wed, 9 Mar 2011 09:05:43 GMT Message-ID: <4D7742CA.6090501@cisco.com> Date: Wed, 09 Mar 2011 10:05:14 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> <737C77C3-43A7-4046-9188-C5017A272517@jpl.nasa.gov> <55DC663C2F4F9F439F23543E0078E8B30CB89C@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30CB89C@EXC001> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" , "Henry B. Hotz" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 09:04:29 -0000 Josh, > I do hope so. Is there anyone who would be interested in working on defining privacy and data protection requirements for ABFAB? > Goodness I would hope that Hannes will have given us a head start on that in the forthcoming Architecture doc. Eliot From Josh.Howlett@ja.net Wed Mar 9 02:01:12 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 773953A67F1 for ; Wed, 9 Mar 2011 02:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIMCnmWOT8QH for ; Wed, 9 Mar 2011 02:01:11 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 61E423A68D9 for ; Wed, 9 Mar 2011 02:01:10 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 9E2874A6B60_D775031B; Wed, 9 Mar 2011 10:02:25 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 85CFF4A6B5E_D775031F; Wed, 9 Mar 2011 10:02:25 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Wed, 9 Mar 2011 10:02:49 +0000 From: Josh Howlett To: Eliot Lear Thread-Topic: [abfab] A proposal for dealing with EU data protection & identifiers Thread-Index: AcvdDMNlRyFe1IYbSWOvnNthpb1JCQAqXpYAAB76z7AAAbw+AAABR0Ug Date: Wed, 9 Mar 2011 10:02:48 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30CBD01@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B30C818C@EXC001> <737C77C3-43A7-4046-9188-C5017A272517@jpl.nasa.gov> <55DC663C2F4F9F439F23543E0078E8B30CB89C@EXC001> <4D7742CA.6090501@cisco.com> In-Reply-To: <4D7742CA.6090501@cisco.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {07FAE095-21B6-4925-AC82-ABD13FBA67BD} x-cr-hashedpuzzle: CsDR G+2z JKNR MBAp Orcg QPyc RHSI UC0R WVYI aMIn fRx8 fpVv gImT gNWg jLsP jQG5; 3; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnADsAaABvAHQAegBAAGoAcABsAC4AbgBhAHMAYQAuAGcAbwB2ADsAbABlAGEAcgBAAGMAaQBzAGMAbwAuAGMAbwBtAA==; Sosha1_v1; 7; {07FAE095-21B6-4925-AC82-ABD13FBA67BD}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Wed, 09 Mar 2011 10:02:12 GMT; UgBFADoAIABbAGEAYgBmAGEAYgBdACAAQQAgAHAAcgBvAHAAbwBzAGEAbAAgAGYAbwByACAAZABlAGEAbABpAG4AZwAgAHcAaQB0AGgAIABFAFUAIABkAGEAdABhACAAcAByAG8AdABlAGMAdABpAG8AbgAgACYAIABpAGQAZQBuAHQAaQBmAGkAZQByAHMA x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" , "Henry B. Hotz" Subject: Re: [abfab] A proposal for dealing with EU data protection & identifiers X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 10:01:12 -0000 DQo+IEdvb2RuZXNzIEkgd291bGQgaG9wZSB0aGF0IEhhbm5lcyB3aWxsIGhhdmUgZ2l2ZW4gdXMg YSBoZWFkIHN0YXJ0IG9uDQo+IHRoYXQgaW4gdGhlIGZvcnRoY29taW5nIEFyY2hpdGVjdHVyZSBk b2MuDQoNCkRlZmluaXRlbHkhIFdoYXQgSSdkIGxpa2UgdG8gZG8gaXMgZGVmaW5lIGEgc2V0IG9m IHJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gdGhlIGFwcGxpY2FibGUgbGVnaXNsYXRpb24gdGhh dCB3ZSBjYW4gY29tcGFyZSBhZ2FpbnN0IHRoZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIHRoYXQg SGFubmVzIGhhcyBhbHJlYWR5IGVudW1lcmF0ZWQgaW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiBT byB0aGlzIHdvdWxkIGJlIGEgY29tcGxlbWVudGFyeSBleGVyY2lzZSBpbnRlbmRlZCB0byBidWls ZCBjb25maWRlbmNlIHRoYXQgdGhlIGFyY2hpdGVjdHVyZSB3aWxsIHNhdGlzZnkgdGhlc2UgZGF0 YSBwcm90ZWN0aW9uIHJlZ2ltZXMuDQoNCkpvc2guDQoNCgpKQU5FVChVSykgaXMgYSB0cmFkaW5n IG5hbWUgb2YgVGhlIEpOVCBBc3NvY2lhdGlvbiwgYSBjb21wYW55IGxpbWl0ZWQKYnkgZ3VhcmFu dGVlIHdoaWNoIGlzIHJlZ2lzdGVyZWQgaW4gRW5nbGFuZCB1bmRlciBOby4gMjg4MTAyNCAKYW5k IHdob3NlIFJlZ2lzdGVyZWQgT2ZmaWNlIGlzIGF0IEx1bWVuIEhvdXNlLCBMaWJyYXJ5IEF2ZW51 ZSwKSGFyd2VsbCBPeGZvcmQsIERpZGNvdCwgT3hmb3Jkc2hpcmUuIE9YMTEgMFNHCgo= From gabilm@um.es Wed Mar 9 02:51:04 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F1853A68FD for ; Wed, 9 Mar 2011 02:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RN9es9ugQ8fk for ; Wed, 9 Mar 2011 02:51:02 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by core3.amsl.com (Postfix) with ESMTP id 584883A681A for ; Wed, 9 Mar 2011 02:51:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id F33C0537F2; Wed, 9 Mar 2011 11:52:16 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 1JO1lRMT1cOU; Wed, 9 Mar 2011 11:52:14 +0100 (CET) Received: from inf-205-25.inf.um.es (inf-205-25.inf.um.es [155.54.205.25]) (Authenticated sender: gabilm) by xenon11.um.es (Postfix) with ESMTPA id 5E4A553639; Wed, 9 Mar 2011 11:52:10 +0100 (CET) Message-ID: <4D775C5C.1050606@um.es> Date: Wed, 09 Mar 2011 11:54:20 +0100 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Sam Hartman References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Campus use case X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 10:51:04 -0000 El 08/03/11 13:36, Sam Hartman escribió: > Could we get you to work on some text for this campus use case? yes, we can provide some text for this use case > Also, do e actually have campuses who have indicated that deploying a > new technology to solve this use case would be worthwhile for them? As far as I know it was the main objective of the Moonshot proposal (describing Kerberos like an example of technology easily adaptable to provide federated services to federations like eduroam). Indeed, If I'm not wrong it (in general) should be the objective of the moonshot tasks in GN3 :) I have been talking with Diego (RedIris) and it seems there has been interest of some universities for using federated SSH. Indeed, they (RedIris) deployed a proposal (FedSSH) for the Red Española de Supercomputación (Supercomputing Spanish Network). Also, the Internet2 web page (https://spaces.internet2.edu/display/COmanage/Functional+Roadmap) describes future work on a Federated SSH toolset ("[... ] leveraging work within IETF and in Project Moonshot"). Others alternatives that have been taking into account by universities (UMU among them) is to make use of the CAS Proxy for services like IMAP, SSH, SAMBA, etc. In fact, UMU has some of these services running through pamCAS. So, it seems there is interest in this use case. Best regards, Gabi. -- ---------------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email:gabilm@um.es From leifj@sunet.se Wed Mar 9 06:00:55 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADC3A3A69D5 for ; Wed, 9 Mar 2011 06:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txae-bs33u3c for ; Wed, 9 Mar 2011 06:00:54 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 6C8893A69C9 for ; Wed, 9 Mar 2011 06:00:54 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p29E26RN007134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2011 15:02:09 +0100 (CET) Message-ID: <4D77885E.5040702@sunet.se> Date: Wed, 09 Mar 2011 15:02:06 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <4D760382.1060000@sunet.se> In-Reply-To: <4D760382.1060000@sunet.se> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] agenda X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:00:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/08/2011 11:22 AM, Leif Johansson wrote: > > Folks, > > Here is the proposed agenda. The basic idea is that we do use cases and > architecture and general interest in the first session and hard-core > and new documents in the second session. > > Bash away! > > Leif & Klaas Last call... this gets published tomorrow. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk13iF4ACgkQ8Jx8FtbMZnd2CQCgu0aZm8cKvMLaC1yiD02bw7uW 8eYAoI78z/0aNcNo/VbWDJXWspZPe6Ld =E01A -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Wed Mar 9 09:13:41 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA35D3A68CC for ; Wed, 9 Mar 2011 09:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4IX69CJ4YkS for ; Wed, 9 Mar 2011 09:13:41 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by core3.amsl.com (Postfix) with ESMTP id 1F92D3A68B1 for ; Wed, 9 Mar 2011 09:13:41 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id A30E61A9D4FE_D77B590B for ; Wed, 9 Mar 2011 17:14:56 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 991201A9AC45_D77B590F for ; Wed, 9 Mar 2011 17:14:56 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Wed, 9 Mar 2011 17:15:20 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: Soliciting privacy requirements Thread-Index: Acvee6zU7ZJz1DSxTfGQaBEq0nktNQ== Date: Wed, 9 Mar 2011 17:15:19 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30CCBBD@EXC001> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {0632AF94-EC33-4185-BDB9-A979EFC7A101} x-cr-hashedpuzzle: AMJd BkVw CgW6 E9ov FAxb FZ/X Fc2c F3Za GKJ1 Gd3O HSrp Hb91 Hg4a JZ/v MS2x MmrJ; 1; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {0632AF94-EC33-4185-BDB9-A979EFC7A101}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Wed, 09 Mar 2011 17:01:47 GMT; UwBvAGwAaQBjAGkAdABpAG4AZwAgAHAAcgBpAHYAYQBjAHkAIAByAGUAcQB1AGkAcgBlAG0AZQBuAHQAcwA= x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: [abfab] Soliciting privacy requirements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 17:13:41 -0000 I asked a qualified colleague to enumerate the high-level requirements that= would allow a federated identity system to /most comprehensively/ address = the requirements of the EU data protection regime. Here's what he suggested= that the system should ideally provide: a) release of essential information from the IdP to the RP with notificatio= n to user, and b) seeking of user's consent to release of non-essential information from t= he IdP to the RP, and c) provision of information from the user to the RP It would be entirely possible to construct a system that didn't have all of= these properties yet satisfied the EU's DP requirements, but I suggest we = aim high as a starting point and pull back if necessary. Is there anything that anyone would like to add to this list? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Wed Mar 9 11:31:43 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42A03A692B for ; Wed, 9 Mar 2011 11:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.24 X-Spam-Level: X-Spam-Status: No, score=-2.24 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq+t-tv5JzRJ for ; Wed, 9 Mar 2011 11:31:43 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 310B73A6892 for ; Wed, 9 Mar 2011 11:31:42 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 45B5C203BA; Wed, 9 Mar 2011 14:30:17 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1EE46432D; Wed, 9 Mar 2011 14:32:35 -0500 (EST) From: Sam Hartman To: Josh Howlett References: <55DC663C2F4F9F439F23543E0078E8B30CCBBD@EXC001> Date: Wed, 09 Mar 2011 14:32:35 -0500 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30CCBBD@EXC001> (Josh Howlett's message of "Wed, 9 Mar 2011 17:15:19 +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: "abfab@ietf.org" Subject: Re: [abfab] Soliciting privacy requirements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:31:44 -0000 I think it would be really good if we could get someone to give a brief tutorial on why these are requirements. I certainly wouldn't mind reading a hundred pages or so on EU privacy regulations and similar quantities of material on a couple of other legal environments. That's not essential: we can go forward with requirements like this. However I've found that it helps for engineers to understand the requirements and their motivations when evaluating tradeoffs. --Sam From cantor.2@osu.edu Wed Mar 9 11:41:06 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AC73A6A61 for ; Wed, 9 Mar 2011 11:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pcOUd4QOU8vR for ; Wed, 9 Mar 2011 11:41:06 -0800 (PST) Received: from defang8.it.ohio-state.edu (defang8.it.ohio-state.edu [128.146.216.89]) by core3.amsl.com (Postfix) with ESMTP id D90403A692B for ; Wed, 9 Mar 2011 11:41:05 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang8.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p29Jg5Ut017185; Wed, 9 Mar 2011 14:42:15 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::8c6c:9f26:5aa2:4458%25]) with mapi; Wed, 9 Mar 2011 14:39:00 -0500 From: "Cantor, Scott E." To: Josh Howlett , "abfab@ietf.org" Thread-Topic: Soliciting privacy requirements Thread-Index: Acvee6zU7ZJz1DSxTfGQaBEq0nktNQAFe65A Date: Wed, 9 Mar 2011 19:42:12 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100C704A@CIO-KRC-D1MBX01.osuad.osu.edu> References: <55DC663C2F4F9F439F23543E0078E8B30CCBBD@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30CCBBD@EXC001> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" 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.89 Subject: Re: [abfab] Soliciting privacy requirements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:41:06 -0000 > It would be entirely possible to construct a system that didn't have all = of > these properties yet satisfied the EU's DP requirements, but I suggest we > aim high as a starting point and pull back if necessary. >=20 > Is there anything that anyone would like to add to this list? How high? The best feature Cardspace had, but which it implemented in laugh= able fashion, was hiding the user's interactions (meaning what RPs the user= visited) from the IdP.=20 Aiming less high, I think you should at least articulate requirements for p= airwise identification, meaning the system shouldn't unavoidably add any cr= oss-RP correlatable data above and beyond what the network layer already do= es. -- Scott From rlmorgan@washington.edu Wed Mar 9 12:25:10 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DED6D3A6AB5 for ; Wed, 9 Mar 2011 12:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.441 X-Spam-Level: X-Spam-Status: No, score=-5.441 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgHiuKQNcV1g for ; Wed, 9 Mar 2011 12:25:10 -0800 (PST) Received: from mxout12.cac.washington.edu (mxout12.cac.washington.edu [140.142.33.31]) by core3.amsl.com (Postfix) with ESMTP id 253F93A6AA7 for ; Wed, 9 Mar 2011 12:25:09 -0800 (PST) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.204] (may be forged)) by mxout12.cac.washington.edu (8.14.4+UW11.03/8.14.4+UW11.03) with ESMTP id p29KQG2r018435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Mar 2011 12:26:16 -0800 X-Auth-Received: from permafrost (D-69-91-162-126.dhcp4.washington.edu [69.91.162.126]) (authenticated authid=rlmorgan) by smtp.washington.edu (8.14.4+UW11.03/8.14.4+UW11.03) with ESMTP id p29KQGTx030849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 9 Mar 2011 12:26:16 -0800 Date: Wed, 9 Mar 2011 12:26:12 -0800 (PST) From: "RL 'Bob' Morgan" X-X-Sender: rlmorgan@localhost6.localdomain6 To: abfab@ietf.org In-Reply-To: Message-ID: References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-PMX-Version: 5.5.9.388399, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.3.9.201526 X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_600_699 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, FROM_NAME_PHRASE 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Subject: Re: [abfab] Campus use case X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:25:11 -0000 > Also, do we actually have campuses who have indicated that deploying a > new technology to solve this use case would be worthwhile for them? Some interested parties are not central IT organizations at universities but rather research projects, typically e-science, typically very multi-organizational, often called "Virtual Organizations" or VOs. These orgs have their own legacy technology issues but in many cases are very interested in solving these problems, eg making the secure multi-organizational use of ssh more scalable, interested enough to consider new technologies. - RL "Bob" From hartmans@painless-security.com Wed Mar 9 12:31:59 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 005FB3A6AB8 for ; Wed, 9 Mar 2011 12:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfQbLnmoyzAC for ; Wed, 9 Mar 2011 12:31:58 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 4C7FE3A6A44 for ; Wed, 9 Mar 2011 12:31:58 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B4663203A1; Wed, 9 Mar 2011 15:30:30 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8A84A432D; Wed, 9 Mar 2011 15:32:48 -0500 (EST) From: Sam Hartman To: "RL 'Bob' Morgan" References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> Date: Wed, 09 Mar 2011 15:32:48 -0500 In-Reply-To: (RL Morgan's message of "Wed, 9 Mar 2011 12:26:12 -0800 (PST)") 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] Campus use case X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:31:59 -0000 >>>>> "RL" == RL 'Bob' Morgan writes: >> Also, do we actually have campuses who have indicated that >> deploying a new technology to solve this use case would be >> worthwhile for them? RL> Some interested parties are not central IT organizations at RL> universities but rather research projects, typically e-science, RL> typically very multi-organizational, often called "Virtual RL> Organizations" or VOs. These orgs have their own legacy RL> technology issues but in many cases are very interested in RL> solving these problems, eg making the secure RL> multi-organizational use of ssh more scalable, interested enough RL> to consider new technologies. we've definitely seen significant interest from the VO use case. However I'm not entirely sure that's the same as the campus use case. From shore@arsc.edu Wed Mar 9 12:34:40 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD52A3A69FD for ; Wed, 9 Mar 2011 12:34:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3L8kkCxx4e2 for ; Wed, 9 Mar 2011 12:34:39 -0800 (PST) Received: from arsc.edu (mail1.arsc.edu [IPv6:2001:480:150:75::229]) by core3.amsl.com (Postfix) with ESMTP id 287F13A6AB5 for ; Wed, 9 Mar 2011 12:34:37 -0800 (PST) Received: from viking-e0.arsc.edu (viking-e0.arsc.edu [IPv6:2001:480:150:75:223:32ff:feda:4a52]) by arsc.edu (20090828.ARSC) with ESMTP id p29KZpQr003195; Wed, 9 Mar 2011 11:35:51 -0900 (AKST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Melinda Shore In-Reply-To: Date: Wed, 9 Mar 2011 11:35:51 -0900 Content-Transfer-Encoding: 7bit Message-Id: <12C19637-5233-4B45-B83E-138DDF7574B0@arsc.edu> References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1082) X-CanIt-Geo: No geolocation information available for 2001:480:150:75:223:32ff:feda:4a52 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on IPv6:2001:480:150:75::167 Cc: abfab@ietf.org Subject: Re: [abfab] Campus use case X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:34:40 -0000 On Mar 9, 2011, at 11:32 AM, Sam Hartman wrote: > we've definitely seen significant interest from the VO use case. However > I'm not entirely sure that's the same as the campus use case. I don't think so. In the grid context a VO can be pretty dynamic. Might be worth checking out the use cases at the Globus Consortium and the Open Grid Foundation. Melinda From leifj@sunet.se Wed Mar 9 12:57:35 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98BF23A6AB7 for ; Wed, 9 Mar 2011 12:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7domsLZi6Xa for ; Wed, 9 Mar 2011 12:57:34 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 758103A6943 for ; Wed, 9 Mar 2011 12:57:34 -0800 (PST) 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 p29KwkNm007902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Mar 2011 21:58:49 +0100 (CET) Message-ID: <4D77EA06.8010709@sunet.se> Date: Wed, 09 Mar 2011 21:58:46 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <12C19637-5233-4B45-B83E-138DDF7574B0@arsc.edu> In-Reply-To: <12C19637-5233-4B45-B83E-138DDF7574B0@arsc.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Campus use case X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 20:57:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/09/2011 09:35 PM, Melinda Shore wrote: > On Mar 9, 2011, at 11:32 AM, Sam Hartman wrote: >> we've definitely seen significant interest from the VO use case. However >> I'm not entirely sure that's the same as the campus use case. > not speaking as chair in any way... > I don't think so. In the grid context a VO can > be pretty dynamic. Might be worth checking out > the use cases at the Globus Consortium and the > Open Grid Foundation. Right. We touched on this very briefly in China I think. There was a discussion about the need to incorporate attribute authorities that are separate from identity providers in the model. In the WebSSO case this corresponds to an entity that (only) implements attribute SAML query (typically using the SOAP binding). In WebSSO land (and I suspect this will be true for abfab aswell) there are different schools of thought as to how such attribute authorities become part of an authentication flow. One school favors proxy IdPs and one prefers having the service provider query the AA directly. Both have their benefits and drawbacks. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk136gYACgkQ8Jx8FtbMZnfVtACgnoKmrRKR8Va0fC/v5bfe8use IIYAoJ3Dd2MwQ4fRxdLLXbggmH1o94Ig =s8II -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Wed Mar 9 13:32:56 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6933A6ABB for ; Wed, 9 Mar 2011 13:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O79Oy7yMquPG for ; Wed, 9 Mar 2011 13:32:55 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by core3.amsl.com (Postfix) with ESMTP id EFF793A6AB0 for ; Wed, 9 Mar 2011 13:32:54 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3BD011A9D5FF_D77F253B; Wed, 9 Mar 2011 21:34:11 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 2DD271A9D4FE_D77F253F; Wed, 9 Mar 2011 21:34:11 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Wed, 9 Mar 2011 21:34:34 +0000 From: Josh Howlett To: Sam Hartman Thread-Topic: [abfab] Soliciting privacy requirements Thread-Index: Acvee6zU7ZJz1DSxTfGQaBEq0nktNQAFTM8gAAH0QZ4= Date: Wed, 9 Mar 2011 21:34:34 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30CCCFE@EXC001> References: <55DC663C2F4F9F439F23543E0078E8B30CCBBD@EXC001>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Soliciting privacy requirements X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:32:57 -0000 Sam, Here are some good starting points: The UK federation's "Recommendations for Use of Personal Data", which provi= des a high-level overview: http://www.ukfederation.org.uk/library/uploads/Documents/recommendations-fo= r-use-of-personal-data.pdf A set of more general papers discussing the implications of privacy and dat= a protection in the context of federated identity: http://www.terena.org/activities/refeds/data-protection.html The directive itself: http://europa.eu/legislation_summaries/information_society/l14012_en.htm And its UK implementation, by way of an English-language example:=20 http://www.legislation.gov.uk/ukpga/1998/29/contents The good news is that the principles are very simple, and can be explained = in minutes. Unfortunately, although the national implementations are based = on the same directive, there is sufficient variation in interpretation, enf= orcement and culture that can cause some surprises when operating across bo= rders. For example, in the UK we don't have any formal proof of identity (o= ur passport is just a proof of nationality) and tend to take a skeptical vi= ew of such things (the fledging national identity register was actually des= troyed last month), whereas those crazy Swedes use a single ID to link a nu= mber of different public and private services.=20 The directive was established in 1995, and it's definitely showing its age.= There is an on-going effort to update the directive. It's a bit late for Prague, but perhaps we could consider a workshop around= ABFAB & Privacy in Quebec City? Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From lear@cisco.com Wed Mar 9 13:57:03 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9873A6AD9 for ; Wed, 9 Mar 2011 13:57:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.584 X-Spam-Level: X-Spam-Status: No, score=-110.584 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5+ke9KuaIg8 for ; Wed, 9 Mar 2011 13:57:03 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 83E333A6407 for ; Wed, 9 Mar 2011 13:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=2785; q=dns/txt; s=iport; t=1299707899; x=1300917499; h=message-id:date:from:mime-version:to:subject; bh=cZsginVr2TR3alysBRIYJFSJL/0noY1tzArq/6sMHpY=; b=EWK4sPgVF7aIABEz6kmpSrsmXga9JuX1xNe25SIaedBckLhUlxebuz8F T5ONbFsUHMH1KhNHgOXOs5Pob5pSzMfASBNGlJXb3Hvslh1wH0h/gXT5R sXW8gWbFOJz0yG7TnZ6U3rgM0Gh0OErVFY3F72gDnnDyyI0pc51p27V7b w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgEAD+Gd02Q/khMgWdsb2JhbACELZ1thFcVAQEWIiWnKIsSkTOEb3YEjDo X-IronPort-AV: E=Sophos;i="4.62,292,1297036800"; d="scan'208,217";a="21083805" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 09 Mar 2011 21:58:18 +0000 Received: from ams3-vpn-dhcp4980.cisco.com (ams3-vpn-dhcp4980.cisco.com [10.61.83.115]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p29LwI4e008345 for ; Wed, 9 Mar 2011 21:58:18 GMT Message-ID: <4D77F7DC.6030900@cisco.com> Date: Wed, 09 Mar 2011 22:57:48 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110308 Thunderbird/3.3a3pre MIME-Version: 1.0 To: "abfab@ietf.org" Content-Type: multipart/alternative; boundary="------------050608010402010708070705" Subject: [abfab] updated version of draft-lear-abfab-arch posted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 21:57:03 -0000 This is a multi-part message in MIME format. --------------050608010402010708070705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi everyone, An updated version draft-lear-abfab-arch-02 has been posted to the drafts directory. Here are some of the changes: 1. We have completed what we believe to be the ABFAB flow; at least for now (with one exception- see below). 2. Hannes has made an extensive contribution in terms of privacy considerations. 3. Sam has elaborated substantially on the architecture. 4. Josh has provided a number of contributions, including discussion of the personalization layer. Things to be done: * Security considerations; * A few more XXXes * The document does need to be blocked for readability. * Deployment considerations need to be filled in. Also, there is currently some normative language in the doc. It's not my desire that this remain, and Sam has some ideas on how to remove it. But I'll let Sam explain them. http://www.ietf.org/id/draft-lear-abfab-arch-02.txt We look forward to your thoughts and comments. Eliot --------------050608010402010708070705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi everyone,

An updated version draft-lear-abfab-arch-02 has been posted to the drafts directory.  Here are some of the changes:

1.  We have completed what we believe to be the ABFAB flow; at least for now (with one exception- see below).
2.  Hannes has made an extensive contribution in terms of privacy considerations.
3.  Sam has elaborated substantially on the architecture.
4.  Josh has provided a number of contributions, including discussion of the personalization layer.

Things to be done:
  • Security considerations;
  • A few more XXXes
  • The document does need to be blocked for readability.
  • Deployment considerations need to be filled in.
Also, there is currently some normative language in the doc.  It's not my desire that this remain, and Sam has some ideas on how to remove it.  But I'll let Sam explain them.

http://www.ietf.org/id/draft-lear-abfab-arch-02.txt

We look forward to your thoughts and comments.

Eliot
--------------050608010402010708070705-- From leifj@sunet.se Thu Mar 10 02:08:03 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F95A3A68B5 for ; Thu, 10 Mar 2011 02:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJAbPx4CGZat for ; Thu, 10 Mar 2011 02:08:02 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 158A73A6876 for ; Thu, 10 Mar 2011 02:08:01 -0800 (PST) Received: from [172.20.10.2] ([2.64.163.189]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p2AA9FWg011808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Mar 2011 11:09:18 +0100 (CET) Message-ID: <4D78A34A.50601@sunet.se> Date: Thu, 10 Mar 2011 11:09:14 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] agenda posted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 10:08:03 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The agenda has been posted. Please take the time to read and review documents listed. We have lots of interesting things to cover in Prague! http://www.ietf.org/proceedings/80/agenda/abfab.txt Cheers Leif & Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk14o0oACgkQ8Jx8FtbMZncsRACgnZONXtl2qkXfAPdpYICZ8aqw JdcAnjdlg8vfCMxnlGym1USwBBhHKQj3 =EDZz -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Thu Mar 10 13:30:04 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E00563A6A7F; Thu, 10 Mar 2011 13:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z7trFkiccJ1; Thu, 10 Mar 2011 13:30:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A1C3A6AB8; Thu, 10 Mar 2011 13:30:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310213003.19974.24054.idtracker@localhost> Date: Thu, 10 Mar 2011 13:30:03 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action:draft-ietf-abfab-aaa-saml-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:30:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. Title : A RADIUS Attribute for SAML Messages Author(s) : J. Howlett, S. Hartman Filename : draft-ietf-abfab-aaa-saml-01.txt Pages : 6 Date : 2011-03-10 This document defines the SAML-Message attribute for use with the RADIUS protocol. This attribute is used for encapsulating Security Assertion Mark-up Language (SAML) messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-abfab-aaa-saml-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-10132636.I-D@ietf.org> --NextPart-- From Josh.Howlett@ja.net Thu Mar 10 13:49:19 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0693A6ABA for ; Thu, 10 Mar 2011 13:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2DwBEcjbElb2 for ; Thu, 10 Mar 2011 13:49:18 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by core3.amsl.com (Postfix) with ESMTP id 381573A6AB1 for ; Thu, 10 Mar 2011 13:49:18 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 3E3361A9D852_D7947ABB for ; Thu, 10 Mar 2011 21:50:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 341081A9BCF8_D7947ABF for ; Thu, 10 Mar 2011 21:50:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Thu, 10 Mar 2011 21:50:58 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: [abfab] I-D Action:draft-ietf-abfab-aaa-saml-01.txt Thread-Index: AQHL32qezZkHnblFaUKOmzDTe0vBnJQnFmsw Date: Thu, 10 Mar 2011 21:50:58 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30CDFF7@EXC001> References: <20110310213003.19974.24054.idtracker@localhost> In-Reply-To: <20110310213003.19974.24054.idtracker@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [abfab] I-D Action:draft-ietf-abfab-aaa-saml-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 21:49:20 -0000 There's only a few minor changes to this document; the only substantial cha= nge being the loss of the Construct Type field. Of more significance, while updating this document I noticed that we've let= the SAML RADIUS binding slip. This is mentioned in the charter as an item = that requires co-ordination with OASIS SSTC which -- mea culpa -- hasn't ha= ppened. I am hoping that some of the SSTC folks will join the discussion on= Thursday, so we can get this moving again. I was going to include a discus= sion of the SAML RADIUS binding in the attribute draft but, as a passable s= traw-man already exists [1], I've simply included some brief discussion abo= ut how this attribute relates to the binding and provided a pointer. Josh. [1] http://www.project-moonshot.org/sites/default/files/sstc-saml-binding-a= aa-draft-00.pdf JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From Josh.Howlett@ja.net Tue Mar 15 03:45:12 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2C33A6CB7 for ; Tue, 15 Mar 2011 03:45:12 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: illegal encoding [base64] for MIME type message/external-body X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvxXDYK9SO+E for ; Tue, 15 Mar 2011 03:45:11 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id B99DB3A6C5E for ; Tue, 15 Mar 2011 03:45:11 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 222374A6B5A_D7F438BB for ; Tue, 15 Mar 2011 10:46:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 0FE9A4A6B4A_D7F438BF for ; Tue, 15 Mar 2011 10:46:35 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 15 Mar 2011 10:46:59 +0000 From: Josh Howlett To: "abfab@ietf.org" Thread-Topic: I-D Action:draft-howlett-radsec-knp-01.txt Thread-Index: AQHL4pir1+GU6azUlE6uwM5ApcfMJpQuNq6w Date: Tue, 15 Mar 2011 10:46:58 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30D1632@EXC001> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: multipart/mixed; boundary="_002_55DC663C2F4F9F439F23543E0078E8B30D1632EXC001_" MIME-Version: 1.0 Cc: Josh Howlett Subject: [abfab] FW: I-D Action:draft-howlett-radsec-knp-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 10:45:12 -0000 --_002_55DC663C2F4F9F439F23543E0078E8B30D1632EXC001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For discussion during the Thursday meeting in Prague. This version provides additional material describing the motivations for KN= P. The technical material is unchanged. Josh. > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org > Sent: Monday, March 14, 2011 10:30 PM > To: i-d-announce@ietf.org > Subject: I-D Action:draft-howlett-radsec-knp-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 > Title : Key Negotiation Protocol for RadSec (KNP) > Author(s) : J. Howlett, S. Hartman > Filename : draft-howlett-radsec-knp-01.txt > Pages : 15 > Date : 2011-03-14 >=20 > RadSec provides a means to secure the communication between a RADIUS > client and server on the transport layer by using a TLS cipher-suite. > This avoids the security weaknesses inherent in RADIUS' use of the > MD5 algorithm. >=20 > The Key Negotiation Protocol for RadSec enables a RADIUS client and > RADIUS server to derive a key that can be used with a TLS PSK > ciphersuite and applied with a RadSec connection. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-howlett-radsec-knp-01.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG --_002_55DC663C2F4F9F439F23543E0078E8B30D1632EXC001_ Content-Type: message/external-body; name="draft-howlett-radsec-knp-01.url" Content-Description: draft-howlett-radsec-knp-01.url Content-Disposition: attachment; filename="draft-howlett-radsec-knp-01.url"; size=92; creation-date="Mon, 14 Mar 2011 22:39:25 GMT"; modification-date="Mon, 14 Mar 2011 22:39:25 GMT" Content-Transfer-Encoding: base64 W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1ob3dsZXR0LXJhZHNlYy1rbnAtMDEudHh0DQo= --_002_55DC663C2F4F9F439F23543E0078E8B30D1632EXC001_-- From hartmans@painless-security.com Fri Mar 18 03:57:00 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F743A68F0 for ; Fri, 18 Mar 2011 03:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIhHh4wm6v99 for ; Fri, 18 Mar 2011 03:57:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 352593A6842 for ; Fri, 18 Mar 2011 03:56:59 -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 9D40A203BA for ; Fri, 18 Mar 2011 06:55:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9637D4547; Fri, 18 Mar 2011 06:57:45 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 18 Mar 2011 06:57:45 -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] Representation of names without realm X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 10:57:00 -0000 Currently if you have a ABFAB name with no realm it looks lie "foo" or "foo/bar.example.com" not "foo@". For one use (sending the EAP identity response) this is clearly correct. Howere this forbids realm defaulting within the acceptor and the initiator. The AAA infrastructure can still do realm defaulting if it likes, but the GSS code cannot distinguish cases where the realm was intended to be defaulted from cases where the realm was intended to be left to AAA. So long as there are no cases where we hope the GSS infrastructure fills in a default this is fine. I think the current behavior is OK, but want to check with the WG. --Sam From nico@cryptonector.com Fri Mar 18 04:30:04 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3A83A68E3 for ; Fri, 18 Mar 2011 04:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOYrUCqTgWgx for ; Fri, 18 Mar 2011 04:30:03 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 441133A68D8 for ; Fri, 18 Mar 2011 04:30:03 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 1E89959405E for ; Fri, 18 Mar 2011 04:31:32 -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; q=dns; s=cryptonector.com; b=vntHqIenFq4/VZkbJerzO orwF8kMwmSs2LgwJWj0UpbOE5m8w0bvo5CAW76SNLL1jJ8CsLxgbmNFFyI43qz/l YVmFpVmzAnCTswfm0Q1B3/mUJxipV433mLddxGzkDndY58mAgOl7yukZkJCErw0n ia/aylquZZpnzWrlG5KqGQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=X3paQ/TTjsCZOOA+nmFc jGHwuj0=; b=x0ybjSBtBC3mGuJfwOcSAsY2s5yG+inb+8/sT41pJKHKa2wyGrBy sQ5LJF22/EFFYTQWqatXO0TTf4ioK+HEP7uL+c+0SPv5HmZwetTL8U3wLE6UfTvW lfsxBKxSX19yp12X1b60qgTKLnFL0N/5PbDvJVrfb7CbX/LOesTkpGM= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id E2293594059 for ; Fri, 18 Mar 2011 04:31:31 -0700 (PDT) Received: by vws12 with SMTP id 12so4129192vws.31 for ; Fri, 18 Mar 2011 04:31:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.179.69 with SMTP id de5mr966125vdc.304.1300447890612; Fri, 18 Mar 2011 04:31:30 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Fri, 18 Mar 2011 04:31:30 -0700 (PDT) Received: by 10.52.159.4 with HTTP; Fri, 18 Mar 2011 04:31:30 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Mar 2011 06:31:30 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: multipart/alternative; boundary=bcaec5014a3791a23c049ec01e1b Cc: abfab@ietf.org Subject: Re: [abfab] Representation of names without realm X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 11:30:04 -0000 --bcaec5014a3791a23c049ec01e1b Content-Type: text/plain; charset=UTF-8 It'd be OK for canonicalized names (MNs) to have or not have realm name components. However, you might want syntax via which users can specify realm-less-ness [when importing name strings]. Alternatively you could use additional name types for conveying this one bit of information. Nico -- --bcaec5014a3791a23c049ec01e1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

It'd be OK for canonicalized names (MNs) to have or not have realm n= ame components.=C2=A0 However, you might want syntax via which users can sp= ecify realm-less-ness [when importing name strings].=C2=A0 Alternatively yo= u could use additional name types for conveying this one bit of information= .

Nico
--

--bcaec5014a3791a23c049ec01e1b-- From smith@Cardiff.ac.uk Thu Mar 24 03:22:00 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E21473A6860 for ; Thu, 24 Mar 2011 03:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39Z96APcfzqZ for ; Thu, 24 Mar 2011 03:22:00 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by core3.amsl.com (Postfix) with ESMTP id E2ECD3A67F0 for ; Thu, 24 Mar 2011 03:21:58 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Q2hhT-0006BR-T9 for abfab@ietf.org; Thu, 24 Mar 2011 10:23:31 +0000 Received: from [10.255.207.159] (helo=dracadmin12.mwe.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q2hhT-0001yR-RB for abfab@ietf.org; Thu, 24 Mar 2011 10:23:31 +0000 From: Rhys Smith Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Mar 2011 09:47:58 +0000 Message-Id: To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] OID registry X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 10:22:01 -0000 Hi all, I've created a I-D to keep track of OID usage under the assigned ABFAB = arc - iso.org.dod.internet.security.mechanisms.abfab (1.3.6.1.5.5.15). = It's essentially blank at the moment apart from supporting structure - = as currently all OID usage is in private arcs such as Luke's. The first step should probably be to figure out a base structure, and = then we can start moving things over from the private arcs to the = "official" one as and when the time is right. We should probably at = least start thinking about it soon, maybe over some unofficial chats at = Prague, then try to pull something together properly on the list so that = we have something concrete in time for IETF81. N.B. I'll be keeping an eye on documents submitted to the WG to try to = capture all OIDs being used under the abfab arc - but would appreciate = it if document authors could also point out OID usage under that arc to = me explicitly to make absolutely sure we have a complete set recorded. Kind Regards, Rhys. -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From smith@Cardiff.ac.uk Thu Mar 24 03:22:01 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291003A67F0 for ; Thu, 24 Mar 2011 03:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+ADGMljWuO3 for ; Thu, 24 Mar 2011 03:22:00 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by core3.amsl.com (Postfix) with ESMTP id E32A73A685D for ; Thu, 24 Mar 2011 03:21:59 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1Q2hhV-0007L4-FZ for abfab@ietf.org; Thu, 24 Mar 2011 10:23:33 +0000 Received: from [10.255.207.159] (helo=dracadmin12.mwe.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Q2hhV-0001yR-As for abfab@ietf.org; Thu, 24 Mar 2011 10:23:33 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1084) From: Rhys Smith In-Reply-To: <4D75DCF7.5070903@um.es> Date: Thu, 24 Mar 2011 10:01:24 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> To: abfab@ietf.org X-Mailer: Apple Mail (2.1084) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2011 10:22:01 -0000 Obviously happy to receive any additional use case text people think is = important. Federated ssh is something that is a prime factor of the Grid and/or HPC = use-cases already included in the 00 draft - though both use cases don't = currently mention any specific technologies (e.g. the current text of = "federated access to HPC systems" is pretty vague). Those technologies, = including federated SSH, should probably be more specifically enumerated = in the next draft... But a more generic use case discussing federated access to = organisational services such as SSH, SMTP, and whatnot does seem = probably worth including. All text gratefully received! Regards, R. On 8 Mar 2011, at 07:38, Gabriel L=F3pez wrote: >=20 > Hi, >=20 > I always thought in the campus use case like a good example for this = wg. I mean, students and professors roaming between universities and = requesting federated access to service such as FTP, SSH, SMTP, etc. etc. = Something that eduroam is not providing currently. Do you plan on the = description of this scenario in the draft? >=20 > Best regards, Gabi. >=20 > El 08/03/11 02:30, Internet-Drafts@ietf.org escribi=F3: >> A new Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Application Bridging for Federated = Access Beyond web Working Group of the IETF. >>=20 >> Title : Application Bridging for Federated Access Beyond = web (ABFAB) Use Cases >>=20 >> Author(s) : R. Smith, et al >> Filename : draft-ietf-abfab-usecases-00.txt >> Pages : 7 >> Date : 2011-03-07 >> =20 >> Federated authentication is most commonly associated with Web-based >> services, but there is growing interest in the application of >> federated authentication for non-Web services. The goal of this >> document is to drive the development of requirements. >>=20 >> A URL for this Internet-Draft is: >>=20 >> http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-00.txt >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >>=20 >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >>=20 >>=20 >> _______________________________________________ >> abfab mailing list >>=20 >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 >=20 > --=20 > ---------------------------------------------------------------- > Gabriel L=F3pez Mill=E1n > Departamento de Ingenier=EDa de la Informaci=F3n y las Comunicaciones > University of Murcia > Spain > Tel: +34 868888504 > Fax: +34 868884151 > email:=20 > gabilm@um.es > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------------- Dr Rhys Smith e: smith@cardiff.ac.uk Engineering Consultant: Identity & Access Management (GPG:0xDE2F024C) Information Services, Cardiff University, t: +44 (0) 29 2087 0126 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 ---------------------------------------------------------------------- From hbhotz@dslextreme.com Thu Mar 24 17:43:06 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD30A28C11A for ; Thu, 24 Mar 2011 17:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUJTJq4VNKnR for ; Thu, 24 Mar 2011 17:43:05 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id C4A8E28C113 for ; Thu, 24 Mar 2011 17:43:05 -0700 (PDT) Received: by pzk30 with SMTP id 30so94488pzk.31 for ; Thu, 24 Mar 2011 17:44:40 -0700 (PDT) Received: by 10.142.222.17 with SMTP id u17mr117592wfg.423.1301013880631; Thu, 24 Mar 2011 17:44:40 -0700 (PDT) Received: from dhcp-137-79-179-39.jpl.nasa.gov (dhcp-137-79-179-39.jpl.nasa.gov [137.79.179.39]) by mx.google.com with ESMTPS id w27sm562694wfd.4.2011.03.24.17.44.38 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 24 Mar 2011 17:44:39 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: "Henry B. Hotz" In-Reply-To: <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> Date: Thu, 24 Mar 2011 17:44:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> To: Rhys Smith X-Mailer: Apple Mail (2.1082) Cc: abfab@ietf.org Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Henry B. Hotz" List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 00:43:07 -0000 This is totally in left field, and my not make any sense at all, but is = anyone thinking about DBMS access? Nobody seems to do it, but I don't see any reason why a "thick" client = application shouldn't want to use a WAN connection to a DBMS as part of = its operation. On Mar 24, 2011, at 3:01 AM, Rhys Smith wrote: > Obviously happy to receive any additional use case text people think = is important. >=20 > Federated ssh is something that is a prime factor of the Grid and/or = HPC use-cases already included in the 00 draft - though both use cases = don't currently mention any specific technologies (e.g. the current text = of "federated access to HPC systems" is pretty vague). Those = technologies, including federated SSH, should probably be more = specifically enumerated in the next draft... >=20 > But a more generic use case discussing federated access to = organisational services such as SSH, SMTP, and whatnot does seem = probably worth including. All text gratefully received! >=20 > Regards, > R. >=20 >=20 > On 8 Mar 2011, at 07:38, Gabriel L=F3pez wrote: >=20 >>=20 >> Hi, >>=20 >> I always thought in the campus use case like a good example for this = wg. I mean, students and professors roaming between universities and = requesting federated access to service such as FTP, SSH, SMTP, etc. etc. = Something that eduroam is not providing currently. Do you plan on the = description of this scenario in the draft? >>=20 >> Best regards, Gabi. >>=20 >> El 08/03/11 02:30, Internet-Drafts@ietf.org escribi=F3: >>> A new Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Application Bridging for Federated = Access Beyond web Working Group of the IETF. >>>=20 >>> Title : Application Bridging for Federated Access Beyond = web (ABFAB) Use Cases >>>=20 >>> Author(s) : R. Smith, et al >>> Filename : draft-ietf-abfab-usecases-00.txt >>> Pages : 7 >>> Date : 2011-03-07 >>>=20 >>> Federated authentication is most commonly associated with Web-based >>> services, but there is growing interest in the application of >>> federated authentication for non-Web services. The goal of this >>> document is to drive the development of requirements. >>>=20 >>> A URL for this Internet-Draft is: >>>=20 >>> http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-00.txt >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>>=20 >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>>=20 >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>>=20 >>>=20 >>> _______________________________________________ >>> abfab mailing list >>>=20 >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu From hartmans@painless-security.com Sun Mar 27 01:35:15 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D89E3A69BE for ; Sun, 27 Mar 2011 01:35:15 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBCq6MSleykG for ; Sun, 27 Mar 2011 01:35:14 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 7BDA73A688F for ; Sun, 27 Mar 2011 01:35:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-408f.meeting.ietf.org [130.129.64.143]) (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 5B7C5203B1; Sun, 27 Mar 2011 04:33:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 432A24481; Sun, 27 Mar 2011 04:36:48 -0400 (EDT) From: Sam Hartman To: "Henry B. Hotz" References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> Date: Sun, 27 Mar 2011 04:36:48 -0400 In-Reply-To: (Henry B. Hotz's message of "Thu, 24 Mar 2011 17:44:36 -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: Rhys Smith , abfab@ietf.org Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 08:35:15 -0000 Doing something with DBMSes would be interesting. I think using ABFAB with postgres for example would be relatively easy. I guess the interesting challenge is coming up with a specific application where this would be desired. --Sam From leifj@sunet.se Mon Mar 28 02:26:28 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189553A6920 for ; Mon, 28 Mar 2011 02:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id op4xHnkq4t3t for ; Mon, 28 Mar 2011 02:26:27 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 0673F3A681B for ; Mon, 28 Mar 2011 02:26:22 -0700 (PDT) Received: from [130.129.8.61] ([130.129.8.61]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p2S9RtFk025240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Mar 2011 11:27:58 +0200 (CEST) Message-ID: <4D90549B.3000006@sunet.se> Date: Mon, 28 Mar 2011 11:27:55 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Meeting materials updated for todays session X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:26:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, The slide decks are online on the materials page for the abfab session today in Karlin I. The sides are not yet available for Tursday but the week is still young ... See you all in Karlin I this afternoon! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2QVJsACgkQ8Jx8FtbMZncJsACgyl3jblOcd9agziWucTDsu0fl 1g0AoKpHiB0zCj+yfEQ6Km6B/ihtasJJ =1JFw -----END PGP SIGNATURE----- From Tim.Bannister@manchester.ac.uk Mon Mar 28 02:31:53 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6AB33A6A27 for ; Mon, 28 Mar 2011 02:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOj56LwHrPJh for ; Mon, 28 Mar 2011 02:31:48 -0700 (PDT) Received: from serenity.mcc.ac.uk (serenity.mcc.ac.uk [130.88.200.93]) by core3.amsl.com (Postfix) with ESMTP id B21EF3A6A35 for ; Mon, 28 Mar 2011 02:31:47 -0700 (PDT) Received: from rankine.its.manchester.ac.uk ([130.88.25.196]) by serenity.mcc.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72 (FreeBSD)) (envelope-from ) id 1Q48pA-0006jN-4R for abfab@ietf.org; Mon, 28 Mar 2011 10:33:24 +0100 Received: from paraboloid.mc.man.ac.uk ([130.88.202.5]:38638) by rankine.its.manchester.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.73) (envelope-from ) id 1Q48pA-0007T4-0p for abfab@ietf.org; Mon, 28 Mar 2011 10:33:24 +0100 From: Tim Bannister To: abfab@ietf.org In-Reply-To: References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> Content-Type: text/plain; charset="UTF-8" Organization: The University of Manchester Date: Mon, 28 Mar 2011 10:33:23 +0100 Message-ID: <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: Tim Bannister from paraboloid.mc.man.ac.uk [130.88.202.5]:38638 X-Authenticated-From: Tim.Bannister@manchester.ac.uk Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 09:31:53 -0000 On Sun, 2011-03-27 at 04:36, Sam Hartman wrote: > Doing something with DBMSes would be interesting. > I think using ABFAB with postgres for example would be relatively easy. >=20 > I guess the interesting challenge is coming up with a specific > application where this would be desired. How about SPARQL access to a triplestore? Yes, it's typically done over HTTP =E2=80=93 but not necessarily in a web browser. Linked data sets are a= lso commonly provided with open access, but updates and inserts might well require federated authnz. I think this kind of HTTP access is an important use case for the technologies the group will deliver. My other use HTTP-derived use case would be SCEP for online certificate enrollment: http://tools.ietf.org/html/draft-nourse-scep-22 =E2=80=A6but this is a whole new world of careful complexity. I'm mentionin= g it just as an aside. I've got one final protocol. Its origins are in HTTP, it's used on the web, but it's different enough to matter: RTSP. Streaming is another area where Abfab promises new benefits. --=20 Tim Bannister IT Services, The University of Manchester e: Tim.Bannister@manchester.ac.uk w: http://www.manchester.ac.uk/itservices From trscavo@gmail.com Mon Mar 28 05:37:38 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D0943A6A24 for ; Mon, 28 Mar 2011 05:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kI2OoYytGirC for ; Mon, 28 Mar 2011 05:37:37 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 351BA3A6A22 for ; Mon, 28 Mar 2011 05:37:37 -0700 (PDT) Received: by fxm15 with SMTP id 15so2874568fxm.31 for ; Mon, 28 Mar 2011 05:39:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6P/OUy6dXJcZD5qhEh5k9Zy8RUAy9jTfzZVvi2vH7GY=; b=Ek33VaDPp/LaNYbqsTUF9oZEO6mW+tFJQo9UPVRFCrbDgE6qRD/nt11RSkz3/UEZvl 3PlCHMuS80i3mrzAgJS8jn/YReF3HZr780H0C7tG1yH72MDXk51wNI9nDB/CPkjbr22q +km72umxx2t66mYSGmm34viUnJByuEXz/PLxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=awF1fFSFpMgi/H5r07DlgBn14P78DFmKy3T2mkj2By2JXQUvv5v6LUF92nV+Z38hte HbjfYznFzEXLtaRTWG+xx8eC38fimOPkXhje/yaD+DDX+ULCbxKo3e+h6EeB9F8wPWRS LWRAeKP2tgoMqVw+rpJ2jsC+F9CpPZvNeqLDI= MIME-Version: 1.0 Received: by 10.223.97.1 with SMTP id j1mr4417347fan.86.1301315954082; Mon, 28 Mar 2011 05:39:14 -0700 (PDT) Received: by 10.223.87.75 with HTTP; Mon, 28 Mar 2011 05:39:14 -0700 (PDT) In-Reply-To: <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> Date: Mon, 28 Mar 2011 08:39:14 -0400 Message-ID: From: Tom Scavo To: Tim Bannister Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:37:38 -0000 On Mon, Mar 28, 2011 at 5:33 AM, Tim Bannister wrote: > > My other use HTTP-derived use case would be SCEP for online certificate > enrollment: http://tools.ietf.org/html/draft-nourse-scep-22 > =85but this is a whole new world of careful complexity. I'm mentioning it > just as an aside. In some situations, at least, SCEP should be able to leverage browser-based protocol flows just fine (but I haven't done it, so who knows). For instance, it's pretty easy to see how SAML Web Browser SSO can lead right into a SCEP workflow. Cheers, Tom From lukeh@padl.com Mon Mar 28 05:48:13 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56913A6A55 for ; Mon, 28 Mar 2011 05:48:13 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW7fC5leNW5r for ; Mon, 28 Mar 2011 05:48:13 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id DBC5F3A683A for ; Mon, 28 Mar 2011 05:48:01 -0700 (PDT) Received: by us.padl.com with ESMTP id p2SCnSrM012164; Mon, 28 Mar 2011 08:49:31 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> Date: Mon, 28 Mar 2011 23:49:34 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> To: Tim Bannister X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 12:48:13 -0000 > I've got one final protocol. Its origins are in HTTP, it's used on the > web, but it's different enough to matter: RTSP. Streaming is another > area where Abfab promises new benefits. What about SIP? OK, it's a potentially a fairly chatty protocol, but it = seems that at some point VoIP is going to be more used in mobile = devices, and those that support WiFi already have EAP supplicants. I'd = kind of like to get GSS into Asterisk at some point, but I've been = thinking about that for years and haven't done it yet. -- Luke= From leifj@mnt.se Tue Mar 29 00:05:30 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1885E3A6853 for ; Tue, 29 Mar 2011 00:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn-bDwYiZMdM for ; Tue, 29 Mar 2011 00:05:29 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id D041A3A683F for ; Tue, 29 Mar 2011 00:05:28 -0700 (PDT) Received: from [130.129.8.61] (dhcp-903d.meeting.ietf.org [130.129.8.61] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p2T7711o022611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Mar 2011 09:07:05 +0200 (CEST) Message-ID: <4D918515.9030209@mnt.se> Date: Tue, 29 Mar 2011 09:07:01 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> In-Reply-To: <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:05:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/28/2011 02:49 PM, Luke Howard wrote: >> I've got one final protocol. Its origins are in HTTP, it's used on the >> web, but it's different enough to matter: RTSP. Streaming is another >> area where Abfab promises new benefits. > > What about SIP? OK, it's a potentially a fairly chatty protocol, but it seems that at some point VoIP is going to be more used in mobile devices, and those that support WiFi already have EAP supplicants. I'd kind of like to get GSS into Asterisk at some point, but I've been thinking about that for years and haven't done it yet. > I seem to recall that Sam was thinking about how to "port" "Negotiate-NG" to SIP a couple of years ago. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2RhRUACgkQ8Jx8FtbMZndZAACgoPktxIarYt27hD0rKOg1MKoN eiMAoIBIn494nr28UkMYcw6KQPyE9smS =5Xk9 -----END PGP SIGNATURE----- From hartmans@painless-security.com Tue Mar 29 00:37:04 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC55D3A67AC for ; Tue, 29 Mar 2011 00:37:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpWlZggtw4Ea for ; Tue, 29 Mar 2011 00:37:04 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id E981C3A683F for ; Tue, 29 Mar 2011 00:37:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-1233.meeting.ietf.org [130.129.18.51]) (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 2F2BF2034A; Tue, 29 Mar 2011 03:35:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9CC574541; Tue, 29 Mar 2011 03:38:34 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> Date: Tue, 29 Mar 2011 03:38:34 -0400 In-Reply-To: <4D918515.9030209@mnt.se> (Leif Johansson's message of "Tue, 29 Mar 2011 09:07:01 +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] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 07:37:04 -0000 The issue is that SIP has a fairly constrained authentication model today which doesn't meet our needs. We could either use something like draft-howlet-radsec-kmp to key it out-of-band or we could revise the authentication model. --Sam From Josh.Howlett@ja.net Tue Mar 29 01:03:52 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 124633A68E1 for ; Tue, 29 Mar 2011 01:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-W-XyAzQxXQ for ; Tue, 29 Mar 2011 01:03:50 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id 4C1963A68D7 for ; Tue, 29 Mar 2011 01:03:50 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 7AF714A6B73_D9192C6B; Tue, 29 Mar 2011 08:05:26 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 61ED94A6B39_D9192C6F; Tue, 29 Mar 2011 08:05:26 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Tue, 29 Mar 2011 09:05:26 +0100 From: Josh Howlett To: Sam Hartman , Leif Johansson Thread-Topic: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt Thread-Index: AQHL7eROXSloPXIbZE+QlJB9uXG605RD8BBA Date: Tue, 29 Mar 2011 08:05:25 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:03:52 -0000 > The issue is that SIP has a fairly constrained authentication model > today which doesn't meet our needs. Constrained in what sense? Josh. Book your place at Networkshop 2011 http://www.ja.net/networkshop JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Tue Mar 29 01:15:30 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26113A6AB9 for ; Tue, 29 Mar 2011 01:15:30 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-sxnZv9hCup for ; Tue, 29 Mar 2011 01:15:30 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 38EFB3A6A3A for ; Tue, 29 Mar 2011 01:15:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-1233.meeting.ietf.org [130.129.18.51]) (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 C12B32011F; Tue, 29 Mar 2011 04:14:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E9D24541; Tue, 29 Mar 2011 04:17:06 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> Date: Tue, 29 Mar 2011 04:17:06 -0400 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> (Josh Howlett's message of "Tue, 29 Mar 2011 08:05:25 +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: "abfab@ietf.org" Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:15:31 -0000 >>>>> "Josh" == Josh Howlett writes: >> The issue is that SIP has a fairly constrained authentication >> model today which doesn't meet our needs. Josh> Constrained in what sense? Only supports digest. There is a Microsoft-specific thing for GSS-krb5 that is not standardized and that is krb5 specific. From leifj@sunet.se Tue Mar 29 02:33:13 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20ABB3A692D for ; Tue, 29 Mar 2011 02:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldniB51MDuG4 for ; Tue, 29 Mar 2011 02:33:12 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id BA2B83A690E for ; Tue, 29 Mar 2011 02:33:11 -0700 (PDT) Received: from [130.129.8.61] (dhcp-903d.meeting.ietf.org [130.129.8.61] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p2T9YiQF014683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Mar 2011 11:34:47 +0200 (CEST) Message-ID: <4D91A7B4.9050205@sunet.se> Date: Tue, 29 Mar 2011 11:34:44 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 09:33:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/29/2011 10:17 AM, Sam Hartman wrote: >>>>>> "Josh" == Josh Howlett writes: > > >> The issue is that SIP has a fairly constrained authentication > >> model today which doesn't meet our needs. > > Josh> Constrained in what sense? > > Only supports digest. > > There is a Microsoft-specific thing for GSS-krb5 that is not > standardized and that is krb5 specific. Right but can't you shoe-horn something that looks like negotiate onto the SIP request-response model, especially if you do TCP? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Rp7QACgkQ8Jx8FtbMZncrJgCgj69jwcxib/uei9Jwzyv3X575 LjYAnjsm8SQP7YgOQEtTfPpgoTcwbAhs =eqjr -----END PGP SIGNATURE----- From klaas@cisco.com Tue Mar 29 03:05:36 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A303A6836 for ; Tue, 29 Mar 2011 03:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.932 X-Spam-Level: X-Spam-Status: No, score=-10.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89C+B+h35lE3 for ; Tue, 29 Mar 2011 03:05:35 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id BBE923A681B for ; Tue, 29 Mar 2011 03:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=856; q=dns/txt; s=iport; t=1301393234; x=1302602834; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=rS0u3dvm7d/AdS5BPUz60ty+ganU1G/P2LbbTdjxn4A=; b=Y2/LljXhnX0v5R+yMf37Ql2ZVUawJP8nHfcsDkMDGNlEdSoJYAwrwczb WKQTPZKtT8Fp/YrLHlc0O7uZvLxD/Z+JrsLDalLTIcAdbt2qPQcDOyuVD R0ogiNRKwLlXH5N1NODElQIVoqox0LW+RSgfpGkj9bq+u/x9ExZ1tc6nX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgHAKyukU2rRDoJ/2dsb2JhbACYTox3d6c7nD2FagSNAg X-IronPort-AV: E=Sophos;i="4.63,260,1299456000"; d="scan'208";a="284781944" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 29 Mar 2011 10:07:14 +0000 Received: from sjc-vpnasa-532.cisco.com (sjc-vpnasa-532.cisco.com [10.21.106.23]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2TA7DxT030950 for ; Tue, 29 Mar 2011 10:07:13 GMT Message-ID: <4D91AF50.50507@cisco.com> Date: Tue, 29 Mar 2011 12:07:12 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> <4D91A7B4.9050205@sunet.se> In-Reply-To: <4D91A7B4.9050205@sunet.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 10:05:37 -0000 On 3/29/11 11:34 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/29/2011 10:17 AM, Sam Hartman wrote: >>>>>>> "Josh" == Josh Howlett writes: >> >> >> The issue is that SIP has a fairly constrained authentication >> >> model today which doesn't meet our needs. >> >> Josh> Constrained in what sense? >> >> Only supports digest. >> >> There is a Microsoft-specific thing for GSS-krb5 that is not >> standardized and that is krb5 specific. > > Right but can't you shoe-horn something that looks like negotiate > onto the SIP request-response model, especially if you do TCP? I think we should talk to the SIP crowd, it does sound appealing to get in touch with such a large community that does have some (federated) authentication challenges.... Klaas From gabilm@um.es Tue Mar 29 03:16:35 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FAB28C153 for ; Tue, 29 Mar 2011 03:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtFufhe2M0Wl for ; Tue, 29 Mar 2011 03:16:34 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by core3.amsl.com (Postfix) with ESMTP id 891FA28C150 for ; Tue, 29 Mar 2011 03:16:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 757B2538DE for ; Tue, 29 Mar 2011 12:18:09 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ri5re9MfmQmB for ; Tue, 29 Mar 2011 12:18:09 +0200 (CEST) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [84.236.164.151]) (Authenticated sender: gabilm) by xenon11.um.es (Postfix) with ESMTPA id C35C95366F for ; Tue, 29 Mar 2011 12:18:07 +0200 (CEST) Message-ID: <4D91B28C.9040108@um.es> Date: Tue, 29 Mar 2011 12:21:00 +0200 From: =?ISO-8859-1?Q?Gabriel_L=F3pez?= User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> <4D91A7B4.9050205@sunet.se> <4D91AF50.50507@cisco.com> In-Reply-To: <4D91AF50.50507@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 10:16:35 -0000 El 29/03/11 12:07, Klaas Wierenga escribió: > > I think we should talk to the SIP crowd, it does sound appealing to > get in touch with such a large community that does have some > (federated) authentication challenges.... Federated SIP would be interesting if you could allow roaming users to make use of their softphones to issue and receive calls when they roams to visiting institutions. Moreover, you could provide some kind of SSO token to avoid re-registering and re-autentications. SIP proxies could solve this issue directly by redirections but sometimes firewalls filter those calls. Maybe the VoIP operators in such organizations could clarify this scenario. Best regards, Gabi. > > Klaas > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From leifj@mnt.se Tue Mar 29 03:59:59 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDB6D3A6948 for ; Tue, 29 Mar 2011 03:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+8rKNUAbCPJ for ; Tue, 29 Mar 2011 03:59:58 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 713ED3A693E for ; Tue, 29 Mar 2011 03:59:58 -0700 (PDT) Received: from [130.129.8.61] (dhcp-903d.meeting.ietf.org [130.129.8.61] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p2TB1Vl8006629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Mar 2011 13:01:35 +0200 (CEST) Message-ID: <4D91BC0B.3000806@mnt.se> Date: Tue, 29 Mar 2011 13:01:31 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> <4D91A7B4.9050205@sunet.se> <4D91AF50.50507@cisco.com> <4D91B28C.9040108@um.es> In-Reply-To: <4D91B28C.9040108@um.es> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 10:59:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/29/2011 12:21 PM, Gabriel López wrote: > El 29/03/11 12:07, Klaas Wierenga escribió: >> >> I think we should talk to the SIP crowd, it does sound appealing to >> get in touch with such a large community that does have some >> (federated) authentication challenges.... > > Federated SIP would be interesting if you could allow roaming users to > make use of their softphones to issue and receive calls when they roams > to visiting institutions. Moreover, you could provide some kind of SSO > token to avoid re-registering and re-autentications. SIP proxies could > solve this issue directly by redirections but sometimes firewalls filter > those calls. Maybe the VoIP operators in such organizations could > clarify this scenario. (not as chair in any of this thread btw) The "Negotiate-ng" draft had a re-authentication token to be used for that purpose. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2RvAsACgkQ8Jx8FtbMZneT6wCgsBDZoATi+UGigzb9YRZ9YItZ X1IAoL2pj0gm/BNoPHgDf7Vdi1jCcB+v =e2G+ -----END PGP SIGNATURE----- From alex@um.es Tue Mar 29 04:29:13 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3E0A28C0FB for ; Tue, 29 Mar 2011 04:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywHwSplRZQ5I for ; Tue, 29 Mar 2011 04:29:11 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by core3.amsl.com (Postfix) with ESMTP id 0DFD13A67C2 for ; Tue, 29 Mar 2011 04:29:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 34B794BB09 for ; Tue, 29 Mar 2011 13:30:45 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KiAEvN5Q9OdN for ; Tue, 29 Mar 2011 13:30:42 +0200 (CEST) Received: from [155.54.205.224] (inf-205-224.inf.um.es [155.54.205.224]) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPA id ACACB4B8E6 for ; Tue, 29 Mar 2011 13:30:41 +0200 (CEST) Message-ID: <4D91C2E3.70608@um.es> Date: Tue, 29 Mar 2011 13:30:43 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> In-Reply-To: <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 11:29:13 -0000 Hi Rhys, following you can find UMU's first draft for the campus use case. Comments are welcome. CAMPUS USE CASE --------------------------------- Universities usually offer different kind of services to their students and staff, ranging from basic network access to the more advanced campus intranet, passing through services such as remote computing systems, storage, mail and printing services, etc. Access control to these services is usually managed by means of end user’s login and password. Although it is fairly extended that users can make use of the same credentials to access different services, thanks to a central identity information storage center within each university (e.g. LDAP or database), the authentication mechanism usually differs for each service. This heterogeneity leads to deployment and usability problems, as most of the authentication and authorization functionality must be implemented on each service that the university deploys. Usability issues are related with the lack of a Single Sign-On (SSO) service, avoiding users to re-introduce their credentials on each service access, and the existence of several configuration points where the user needs to configure authentication-related aspects (web browser, network supplicant, mail user agent, remote access software, etc...). The issues described above are motivating service administrators to look for access control solutions that can be applied to a wider range of services. An example of this would be the deployment of CAS – Central Authentication Service (http://www.jasig.org/cas) as an authentication and SSO solution suitable for web services, or Kerberos [RFC 4120], broadly used to provide authentication and SSO for services like SSH, SMTP or POP. However, an integrated solution that can be applied to a wider range of services is still missing. Beside, in order to help mobility of students and staff between different universities, there exists an increasing interest to provide these services also to users coming from other universities or organizations. These /foreign /users should be able to access the services at the /remote /institution making use of the credentials provided by their /home/ University, without the need of creating a new user profile for them in the visited one. This interest for federated services has already been demonstrated with the expansion of /eduroam /(_www.eduroam.or _g), the secure international roaming network service that allows users belonging to one institution to get network access when visiting another institution. This federation is based on the deployment of EAP (Extensible Authentication Protocol) for authentication and a hierarchy of RADIUS servers for authorization and accounting. However, eduroam only covers the network access control, but has nothing to do with access control to upper layer services. Besides, several approaches to federate these upper layer services exist (e.g. Shibboleth, OpenID...), and some of them have even been deployed in several universities to manage access to specific services [SIR], but they are intended for web-based oriented services and do not apply to other application services. For example, some universities have shown interest for using federated SSH. RedIris (http://www.rediris.es) deployed a proposal (FedSSH) for the Spanish Supercomputing Network. Also, the Internet2 web page describes future work on a Federated SSH toolset (_https://spaces.internet2.edu/display/COmanage/Functional+Roadmap_). Other federated services of interest, besides SSH and web-based services, are network storage (where students can store files related with different subjects and access them from any place within the campus) based on NFS (Network File System) or CIFS (Common Internet File System). Hence, it is envisioned that universities will be very interested on a solution that can provide an unified and federated access to their services based on the already deployed AAA infrastructure (i.e. eduroam), providing an homogeneous authentication and SSO alternative that, on the one hand, simplifies deployment of new services, and on the other, improves their usability. Best regards, Alejandro > Obviously happy to receive any additional use case text people think is important. > > Federated ssh is something that is a prime factor of the Grid and/or HPC use-cases already included in the 00 draft - though both use cases don't currently mention any specific technologies (e.g. the current text of "federated access to HPC systems" is pretty vague). Those technologies, including federated SSH, should probably be more specifically enumerated in the next draft... > > But a more generic use case discussing federated access to organisational services such as SSH, SMTP, and whatnot does seem probably worth including. All text gratefully received! > > Regards, > R. > > > On 8 Mar 2011, at 07:38, Gabriel López wrote: > >> Hi, >> >> I always thought in the campus use case like a good example for this wg. I mean, students and professors roaming between universities and requesting federated access to service such as FTP, SSH, SMTP, etc. etc. Something that eduroam is not providing currently. Do you plan on the description of this scenario in the draft? >> >> Best regards, Gabi. >> >> El 08/03/11 02:30,Internet-Drafts@ietf.org escribió: >>> A new Internet-Draft is available from the on-line Internet-Drafts directories. >>> This draft is a work item of the Application Bridging for Federated Access Beyond web Working Group of the IETF. >>> >>> Title : Application Bridging for Federated Access Beyond web (ABFAB) Use Cases >>> >>> Author(s) : R. Smith, et al >>> Filename : draft-ietf-abfab-usecases-00.txt >>> Pages : 7 >>> Date : 2011-03-07 >>> >>> Federated authentication is most commonly associated with Web-based >>> services, but there is growing interest in the application of >>> federated authentication for non-Web services. The goal of this >>> document is to drive the development of requirements. >>> >>> A URL for this Internet-Draft is: >>> >>> http://www.ietf.org/internet-drafts/draft-ietf-abfab-usecases-00.txt >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >>> >>> >>> _______________________________________________ >>> abfab mailing list >>> >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >> -- >> ---------------------------------------------------------------- >> Gabriel López Millán >> Departamento de Ingeniería de la Información y las Comunicaciones >> University of Murcia >> Spain >> Tel: +34 868888504 >> Fax: +34 868884151 >> email: >> gabilm@um.es >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > -- > ---------------------------------------------------------------------- > Dr Rhys Smith e:smith@cardiff.ac.uk > Engineering Consultant: Identity& Access Management (GPG:0xDE2F024C) > Information Services, > Cardiff University, t: +44 (0) 29 2087 0126 > 39-41 Park Place, Cardiff, f: +44 (0) 29 2087 4285 > CF10 3BB, United Kingdom. m: +44 (0) 7968 087 821 > ---------------------------------------------------------------------- > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Tue Mar 29 05:33:12 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00C7A3A6781 for ; Tue, 29 Mar 2011 05:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4mFlocBZFld for ; Tue, 29 Mar 2011 05:33:11 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 35DB53A6784 for ; Tue, 29 Mar 2011 05:33:11 -0700 (PDT) Received: by us.padl.com with ESMTP id p2TCYhL5013945; Tue, 29 Mar 2011 08:34:46 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <4D91B28C.9040108@um.es> Date: Tue, 29 Mar 2011 23:34:43 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <127B3EE1-336A-41B9-B216-D2BA63566FE0@padl.com> References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> <4D91A7B4.9050205@sunet.se> <4D91AF50.50507@cisco.com> <4D91B28C.9040108@um.es> To: =?iso-8859-1?Q?Gabriel_L=F3pez?= X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:33:12 -0000 > Federated SIP would be interesting if you could allow roaming users to = make use of their softphones to issue and receive calls when they roams = to visiting institutions. Moreover, you could provide some kind of SSO = token to avoid re-registering and re-autentications. SIP proxies could = solve this issue directly by redirections but sometimes firewalls filter = those calls. Maybe the VoIP operators in such organizations could = clarify this scenario. That sounds like a good idea. We already have a re-authentication token = in mech_eap, see util_reauth.c :-) -- Luke= From lukeh@padl.com Tue Mar 29 05:35:12 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 570483A6784 for ; Tue, 29 Mar 2011 05:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlrHORAY4anp for ; Tue, 29 Mar 2011 05:35:11 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 7425D3A6781 for ; Tue, 29 Mar 2011 05:35:11 -0700 (PDT) Received: by us.padl.com with ESMTP id p2TCYhL7013945; Tue, 29 Mar 2011 08:36:48 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Tue, 29 Mar 2011 23:36:47 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:35:12 -0000 On 29/03/2011, at 7:17 PM, Sam Hartman wrote: >>>>>> "Josh" =3D=3D Josh Howlett writes: >=20 >>> The issue is that SIP has a fairly constrained authentication >>> model today which doesn't meet our needs. >=20 > Josh> Constrained in what sense? >=20 > Only supports digest. >=20 > There is a Microsoft-specific thing for GSS-krb5 that is not > standardized and that is krb5 specific. Unless there are IPR issues can't we just do what Microsoft does in = [MS-SIPAE] and make it mechanism agnostic? -- Luke= From hartmans@painless-security.com Tue Mar 29 06:44:21 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EB713A690F for ; Tue, 29 Mar 2011 06:44:21 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRLaq-LiQFsw for ; Tue, 29 Mar 2011 06:44:20 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id DDBD43A68D6 for ; Tue, 29 Mar 2011 06:44:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [130.129.82.54]) (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 4BF7620198; Tue, 29 Mar 2011 09:42:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 252ED4541; Tue, 29 Mar 2011 09:45:38 -0400 (EDT) From: Sam Hartman To: Luke Howard References: <20110308013002.9905.25701.idtracker@localhost> <4D75DCF7.5070903@um.es> <4908B1EE-FB43-4EED-9809-F454F7C24079@cardiff.ac.uk> <1301304803.18820.94.camel@paraboloid.mc.man.ac.uk> <32C0D5F0-9C5C-417E-82BA-D33BDECF0B40@padl.com> <4D918515.9030209@mnt.se> <55DC663C2F4F9F439F23543E0078E8B30D95FC@EXC001> Date: Tue, 29 Mar 2011 09:45:38 -0400 In-Reply-To: (Luke Howard's message of "Tue, 29 Mar 2011 23:36:47 +1100") 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: Josh Howlett , "abfab@ietf.org" Subject: Re: [abfab] I-D ACTION:draft-ietf-abfab-usecases-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:44:21 -0000 So, you're asking in the IETF context. I don't know how the SIP community would respond to that. We certainly can propose that and see what happens. From leifj@sunet.se Wed Mar 30 08:20:43 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C39C3A6B01 for ; Wed, 30 Mar 2011 08:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXOiR0pBCvpX for ; Wed, 30 Mar 2011 08:20:39 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 00C413A690D for ; Wed, 30 Mar 2011 08:20:38 -0700 (PDT) Received: from [130.129.8.61] ([130.129.8.61]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p2UFMCJc011306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 30 Mar 2011 17:22:16 +0200 (CEST) Message-ID: <4D934AA4.3070905@sunet.se> Date: Wed, 30 Mar 2011 17:22:12 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Reminder: abfab2 tomorrow morning X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:20:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The new slides are up on the materials page. See you all tomorrow morning in Karlin I Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2TSqQACgkQ8Jx8FtbMZnfaAQCfcBQ354lEm14V3pbR5E7MJgTn Y9sAoL6kumX/YBpMY8ftArOQSrDk63w0 =NQkh -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Mar 31 01:01:47 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18293A6C23 for ; Thu, 31 Mar 2011 01:01:47 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EzRAyyqScrp for ; Thu, 31 Mar 2011 01:01:47 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id EE4163A6C19 for ; Thu, 31 Mar 2011 01:01:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-527c.meeting.ietf.org [130.129.82.124]) (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 3D7522043D for ; Thu, 31 Mar 2011 04:00:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 69EF74541; Thu, 31 Mar 2011 04:03:23 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Thu, 31 Mar 2011 04:03:23 -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] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 08:01:47 -0000 Folks, during today's meeting we discussed the need for protecting information exchanged during the context exchange. An example of this need would be protecting context flags from the client to the server. Some server implementations require that certain context flags be set. As an example ssh servers following RFC 4462 require the mutual flag be set. This needs to be integrity protected. There are a number of possible options: 1) Integrity protect each token separately. Down side: more complex especially if tokens need integrity protection that are exchanged before a key is available. 2) Extend our mechanism to depend on a specific hash function. Disadvantage: requires us dealing with crypto primitives directly . Adds complexity to specificiation of the mechanisms. 3) Provide a gss_getmic or similar of the entire conversation. The disadvantage here is that the client needs to maintain state sufficient to hold a copy of the conversation. If there is a stateless server, this ever-increasing state needs to be transported back and forth for each message. --Sam From rafa@um.es Thu Mar 31 02:46:53 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B695C28C127 for ; Thu, 31 Mar 2011 02:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsL166BSNb3T for ; Thu, 31 Mar 2011 02:46:52 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by core3.amsl.com (Postfix) with ESMTP id 36E3828C0FA for ; Thu, 31 Mar 2011 02:46:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 90E705D479; Thu, 31 Mar 2011 11:48:29 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gi22MmJN+gzQ; Thu, 31 Mar 2011 11:48:26 +0200 (CEST) Received: from inf-205-102.inf.um.es (inf-205-102.inf.um.es [155.54.205.102]) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPA id 4A2485D530; Thu, 31 Mar 2011 11:48:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Thu, 31 Mar 2011 11:48:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:46:53 -0000 Hi Sam, I was not able to follow the discussion about this particular topic, but = I would like to ask a question. The use of EAP authentication over an = unprotected link is something we can see over there. In fact, the use of = EAP methods that export key material are used to bootstrap a security = association at EAP lower-layer. I was wondering what are the exact implications of not protecting the = information until the EAP authentication ends up with a key. If certain = particular flags are unset during the conversation because it is not = protected, the negotiation should fail, right?. So some sort of = denial-of-service problem will raise. Is that what you had in mind?.=20 I say this because, as you may know, there are some EAP lower-layers = which does not need to assume that there will be a pre-established = protected channel to exchange EAP.=20 Best regards. El 31/03/2011, a las 10:03, Sam Hartman escribi=F3: >=20 >=20 > Folks, during today's meeting we discussed the need for protecting > information exchanged during the context exchange. >=20 > An example of this need would be protecting context flags from the > client to the server. > Some server implementations require that certain context flags be set. > As an example ssh servers following RFC 4462 require the mutual flag = be > set. > This needs to be integrity protected. >=20 > There are a number of possible options: >=20 > 1) Integrity protect each token separately. Down side: more complex > especially if tokens need integrity protection that are exchanged = before > a key is available. >=20 > 2) Extend our mechanism to depend on a specific hash function. > Disadvantage: requires us dealing with crypto primitives directly . = Adds > complexity to specificiation of the mechanisms. >=20 > 3) Provide a gss_getmic or similar of the entire conversation. The > disadvantage here is that the client needs to maintain state = sufficient > to hold a copy of the conversation. If there is a stateless server, = this > ever-increasing state needs to be transported back and forth for each > message. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From lukeh@padl.com Thu Mar 31 03:05:05 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132C83A697A for ; Thu, 31 Mar 2011 03:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qq4WHiVtCxM6 for ; Thu, 31 Mar 2011 03:05:04 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 49C043A6919 for ; Thu, 31 Mar 2011 03:05:04 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VA6SpM028615; Thu, 31 Mar 2011 06:06:33 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 31 Mar 2011 21:06:27 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> References: To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.6 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 10:05:05 -0000 > I was wondering what are the exact implications of not protecting the = information until the EAP authentication ends up with a key. If certain = particular flags are unset during the conversation because it is not = protected, the negotiation should fail, right?. So some sort of = denial-of-service problem will raise. Is that what you had in mind?.=20 Right, it should fail. If there is no integrity protection of, in this = case, the client-requested-mutual-authentication flag, then it would = silently succeed. -- Luke= From ietf@augustcellars.com Thu Mar 31 04:20:47 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 204C03A68B7 for ; Thu, 31 Mar 2011 04:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJBqbGnmDL59 for ; Thu, 31 Mar 2011 04:20:46 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 1563A3A68B1 for ; Thu, 31 Mar 2011 04:20:46 -0700 (PDT) Received: from TITUS (dhcp-168b.meeting.ietf.org [130.129.22.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id EE9A26EF7C; Thu, 31 Mar 2011 04:22:24 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Thu, 31 Mar 2011 13:22:06 +0200 Message-ID: <016901cbef95$dfe39270$9faab750$@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: AQJAiuFiW86lPJ1g5ikpOXRYnWUeppNeFY+Q Content-Language: en-us Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:20:47 -0000 Sam, > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Thursday, March 31, 2011 10:03 AM > To: abfab@ietf.org > Subject: [abfab] Message Integrity for gss-eap > > > > Folks, during today's meeting we discussed the need for protecting > information exchanged during the context exchange. > > An example of this need would be protecting context flags from the client to > the server. > Some server implementations require that certain context flags be set. > As an example ssh servers following RFC 4462 require the mutual flag be set. > This needs to be integrity protected. > > There are a number of possible options: > > 1) Integrity protect each token separately. Down side: more complex > especially if tokens need integrity protection that are exchanged before a > key is available. I think there is another possible downside here that needs to be considered, without having a mic on all of the data that you are trying to protect, there is a possibility that either something that should be mic-ed isn't or something that is mic-ed is removed from the set. Jim > > 2) Extend our mechanism to depend on a specific hash function. > Disadvantage: requires us dealing with crypto primitives directly . Adds > complexity to specificiation of the mechanisms. > > 3) Provide a gss_getmic or similar of the entire conversation. The > disadvantage here is that the client needs to maintain state sufficient to hold > a copy of the conversation. If there is a stateless server, this ever-increasing > state needs to be transported back and forth for each message. > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Thu Mar 31 04:29:20 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7BBA28B797 for ; Thu, 31 Mar 2011 04:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn3yCpKElxWD for ; Thu, 31 Mar 2011 04:29:20 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id DAC2C3A6B0F for ; Thu, 31 Mar 2011 04:29:19 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VBToGS023696; Thu, 31 Mar 2011 07:30:56 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <016901cbef95$dfe39270$9faab750$@augustcellars.com> Date: Thu, 31 Mar 2011 22:30:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <016901cbef95$dfe39270$9faab750$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:29:20 -0000 > I think there is another possible downside here that needs to be = considered, > without having a mic on all of the data that you are trying to = protect, > there is a possibility that either something that should be mic-ed = isn't or > something that is mic-ed is removed from the set. Right, although a MIC that requires ordering (i.e. has sequence numbers) = can mitigate against this. I do think though that if we can find an = inexpensive way to protect the entire conversation, it simplifies things = considerably, and will make it easier to add extensions in the future. -- Luke= From ietf@augustcellars.com Thu Mar 31 04:40:24 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F1AE3A6B3D for ; Thu, 31 Mar 2011 04:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BB3LcHLmCy4 for ; Thu, 31 Mar 2011 04:40:23 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id B19DB28C121 for ; Thu, 31 Mar 2011 04:40:23 -0700 (PDT) Received: from TITUS (dhcp-168b.meeting.ietf.org [130.129.22.139]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 9A4E26A48E; Thu, 31 Mar 2011 04:42:02 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , Date: Thu, 31 Mar 2011 13:41:44 +0200 Message-ID: <016b01cbef98$9dc8ef90$d95aceb0$@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: AcvvmBDgBw8E0bDwRYOStQFEXwu1Lw== Content-Language: en-us Subject: [abfab] Channel Binding in the absence of Mututal Authentication. X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:40:24 -0000 Sam, You talked about this as part of the meeting today. In response to your request for comments. 1. Not having the channel binding even in the absence of mutual authentication is something that I have a gut reaction which says that I want it even I don't know why. 2. Can you present a usage case where I would not want mutual authentication to occur. The only places that I can see this as being true are situations where I want to have some non-traceability or anonymity in the system. But even in those cases I want to get the mutual authentication so that I can bind all of the channels together even in the absence of really knowing who all of the parties are. Jim From hartmans@painless-security.com Thu Mar 31 04:51:01 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 617033A6B44 for ; Thu, 31 Mar 2011 04:51:01 -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=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6fOixAEcqL6 for ; Thu, 31 Mar 2011 04:51:00 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 622733A6875 for ; Thu, 31 Mar 2011 04:51:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-159c.meeting.ietf.org [130.129.21.156]) (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 C51082034A for ; Thu, 31 Mar 2011 07:49:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC7EF4541; Thu, 31 Mar 2011 07:52:38 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Thu, 31 Mar 2011 07:52:38 -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] Mutual authentication and channel binding should be required X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:51:01 -0000 Over lunch, we discovered why it is that you want to require mutual authentication and channel binding all the time for gss-eap. The reason is that we're introducing a new application into the system. Consider the following. 1) EAP is used for network access. Since that's the only application and since mutual authentication is not important in a particular deployment for that, EAP mechanisms that do not provide mutual authentication are used. 2) A new application, such as e-mail with TLS authentication for e-mail is deployed. 3) An attacker pretends to be an access point towards a client captures authentication credentials and then uses them to access the user's mail. By increasing the number of possible services we've created a situation where security has been decreased. To avoid this, at most one service may permit authentication without establishing which service is involved. That service is already network access. For that reason, I think that draft-ietf-gss-eap should be revised to be consistent with the applicability statement rather than revising the applicability statement to be more permissive. From alper.yegin@yegin.org Thu Mar 31 04:59:18 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0921628C14B for ; Thu, 31 Mar 2011 04:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcbWYubKvNja for ; Thu, 31 Mar 2011 04:59:16 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 6B48C28C0F0 for ; Thu, 31 Mar 2011 04:59:16 -0700 (PDT) Received: from ibm ([217.167.116.154]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MAxmW-1QCvWJ2eRA-00AQnL; Thu, 31 Mar 2011 08:00:54 -0400 From: "Alper Yegin" To: "'Sam Hartman'" , References: In-Reply-To: Date: Thu, 31 Mar 2011 15:00:46 +0300 Message-ID: <00e701cbef9b$47d609d0$d7821d70$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvvmiVNBuXBLYIDT1GaLG04ePTPagAAIHIA Content-Language: en-us X-Provags-ID: V02:K0:asfQpRYJq/Qitj5Ny2kBOh5HMuM26ev7v+hsJOi8bAV dxEon1uhhoeufJ5wQBVDxMIUO1cRYjyCLiVCtuIbBBy/gBjMw+ LTdtAMME/HKy/lATG74/o0VYHyOu0Pqa7w3Sf5KVKrvFnEdP3Y N9aYjfL4vwKxdXacL+qnGAVtKThJ2/aDPqiMuq/Ts6yDzNJXBj 2Ij6r34JlZ3HoR73/hwNzp5a1uV5Z4lY9DN9ddW6gI= Subject: Re: [abfab] Mutual authentication and channel binding should be required X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:59:18 -0000 Hi Sam, Using EAP one-way authentication with network access is neither the norm, nor allowed by any decent network architecture. Whatever network allows that already has its own security issues without compounding with any higher-layer threats. I don't know if and how it impacts the Abfab discussion, I'm just commenting on the network access part. Alper > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Thursday, March 31, 2011 2:53 PM > To: abfab@ietf.org > Subject: [abfab] Mutual authentication and channel binding should be > required > > > Over lunch, we discovered why it is that you want to require mutual > authentication and channel binding all the time for gss-eap. > > The reason is that we're introducing a new application into the system. > Consider the following. > > 1) EAP is used for network access. Since that's the only application > and since mutual authentication is not important in a particular > deployment for that, EAP mechanisms that do not provide mutual > authentication are used. > > 2) A new application, such as e-mail with TLS authentication for e-mail > is deployed. > > 3) An attacker pretends to be an access point towards a client captures > authentication credentials and then uses them to access the user's > mail. > > By increasing the number of possible services we've created a situation > where security has been decreased. > To avoid this, at most one service may permit authentication without > establishing which service is involved. > That service is already network access. > > For that reason, I think that draft-ietf-gss-eap should be revised to > be > consistent with the applicability statement rather than revising the > applicability statement to be more permissive. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu Mar 31 04:59:57 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2749728C108 for ; Thu, 31 Mar 2011 04:59:57 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G+PqdA3CDYwd for ; Thu, 31 Mar 2011 04:59:56 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id F167E28C0F0 for ; Thu, 31 Mar 2011 04:59:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-159c.meeting.ietf.org [130.129.21.156]) (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 8953C203A2; Thu, 31 Mar 2011 07:58:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 78E674541; Thu, 31 Mar 2011 08:01:33 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: Date: Thu, 31 Mar 2011 08:01:33 -0400 In-Reply-To: (Rafa Marin Lopez's message of "Thu, 31 Mar 2011 11:48:23 +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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 11:59:57 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> I was wondering what are the exact implications of not Rafa> protecting the information until the EAP authentication ends Rafa> up with a key. If certain particular flags are unset during Rafa> the conversation because it is not protected, the negotiation Rafa> should fail, right?. So some sort of denial-of-service problem Rafa> will raise. Is that what you had in mind?. If we have protection. then an attacker can cause a denial of service by changing the negotiation. However, in the case of the mutual authentication flag, if we don't have protection, there is a more serious attack. In that situation, an attacker can set the mutual authentication flag when the mutual authentication did not happen. The server may think the client confirmed the server's identity when that did not happen. We can protect this after the key is established by sending some checksum or keyed hash that covers the flag in question. Rafa> I say this because, as you may know, there are some EAP Rafa> lower-layers which does not need to assume that there will be Rafa> a pre-established protected channel to exchange EAP. abfab is such a lower layer. Rafa> Best regards. Rafa> El 31/03/2011, a las 10:03, Sam Hartman escribió: >> >> >> Folks, during today's meeting we discussed the need for >> protecting information exchanged during the context exchange. >> >> An example of this need would be protecting context flags from >> the client to the server. Some server implementations require >> that certain context flags be set. As an example ssh servers >> following RFC 4462 require the mutual flag be set. This needs to >> be integrity protected. >> >> There are a number of possible options: >> >> 1) Integrity protect each token separately. Down side: more >> complex especially if tokens need integrity protection that are >> exchanged before a key is available. >> >> 2) Extend our mechanism to depend on a specific hash function. >> Disadvantage: requires us dealing with crypto primitives directly >> . Adds complexity to specificiation of the mechanisms. >> >> 3) Provide a gss_getmic or similar of the entire conversation. >> The disadvantage here is that the client needs to maintain state >> sufficient to hold a copy of the conversation. If there is a >> stateless server, this ever-increasing state needs to be >> transported back and forth for each message. >> >> --Sam _______________________________________________ abfab >> mailing list abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab Rafa> ------------------------------------------------------- Rafael Rafa> Marin Lopez, PhD Dept. Information and Communications Rafa> Engineering (DIIC) Faculty of Computer Science-University of Rafa> Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: Rafa> +34868884151 e-mail: Rafa> rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Thu Mar 31 05:15:43 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C49FE3A6767 for ; Thu, 31 Mar 2011 05:15:43 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYEXZHfFQSpw for ; Thu, 31 Mar 2011 05:15:43 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 101653A6B0E for ; Thu, 31 Mar 2011 05:15:43 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-159c.meeting.ietf.org [130.129.21.156]) (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 93F67203BA; Thu, 31 Mar 2011 08:14:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6ADDC4541; Thu, 31 Mar 2011 08:17:20 -0400 (EDT) From: Sam Hartman To: "Alper Yegin" References: <00e701cbef9b$47d609d0$d7821d70$@yegin@yegin.org> Date: Thu, 31 Mar 2011 08:17:20 -0400 In-Reply-To: <00e701cbef9b$47d609d0$d7821d70$@yegin@yegin.org> (Alper Yegin's message of "Thu, 31 Mar 2011 15:00:46 +0300") 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] Mutual authentication and channel binding should be required X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 12:15:43 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Hi Sam, Using EAP one-way authentication with network access Alper> is neither the norm, nor allowed by any decent network Alper> architecture. Whatever network allows that already has its Alper> own security issues without compounding with any higher-layer Alper> threats. I agree with you. We were basically discussing whether to permit that one-way use for abfab. I think we agree you SHOULD NOT deploy that way. The question is whether you MUST NOT deploy that way. I'm now arguing that we MUST NOT use eap without mutual. In some ways it is a pointless argument because we already agree it is a bad idea for network access. It's also at least a bad idea for network access. I'm arguing that if your network access deployment is bad then it can make your abfab deployment worse. To prevent that we can forbid the bad deployment from ABFAB. I think that's desirable, but it doesn't matter much. From hannes.tschofenig@gmx.net Thu Mar 31 05:40:40 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B3F83A6966 for ; Thu, 31 Mar 2011 05:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vC6Hg2VCDkVc for ; Thu, 31 Mar 2011 05:40:39 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id CE5E83A6914 for ; Thu, 31 Mar 2011 05:40:38 -0700 (PDT) Received: (qmail invoked by alias); 31 Mar 2011 12:42:17 -0000 Received: from dhcp-924f.meeting.ietf.org (EHLO dhcp-924f.meeting.ietf.org) [130.129.10.79] by mail.gmx.net (mp013) with SMTP; 31 Mar 2011 14:42:17 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+lUEhBXCml+GU8yhOgqMykkz728Zv03duoBGjsPa T66eJcT6mb7QJ4 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Thu, 31 Mar 2011 14:42:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4EA10721-3BBF-4D91-8782-4E7CEDAC03CD@gmx.net> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: abfab@ietf.org Subject: Re: [abfab] Mutual authentication and channel binding should be required X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 12:40:40 -0000 I guess you are talking about mutual authentication of the EAP peer and = the EAP server. See also text we put in http://tools.ietf.org/html/rfc5998 On Mar 31, 2011, at 1:52 PM, Sam Hartman wrote: >=20 > Over lunch, we discovered why it is that you want to require mutual > authentication and channel binding all the time for gss-eap. >=20 > The reason is that we're introducing a new application into the = system. > Consider the following. >=20 > 1) EAP is used for network access. Since that's the only application > and since mutual authentication is not important in a particular > deployment for that, EAP mechanisms that do not provide mutual > authentication are used. >=20 > 2) A new application, such as e-mail with TLS authentication for = e-mail > is deployed. >=20 > 3) An attacker pretends to be an access point towards a client = captures > authentication credentials and then uses them to access the user's = mail. >=20 > By increasing the number of possible services we've created a = situation > where security has been decreased. > To avoid this, at most one service may permit authentication without > establishing which service is involved. > That service is already network access. >=20 > For that reason, I think that draft-ietf-gss-eap should be revised to = be > consistent with the applicability statement rather than revising the > applicability statement to be more permissive. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nico@cryptonector.com Thu Mar 31 06:00:46 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE5AC28C16E for ; Thu, 31 Mar 2011 06:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.876 X-Spam-Level: X-Spam-Status: No, score=-1.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVFuLDQCvjSS for ; Thu, 31 Mar 2011 06:00:45 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (jankymail-mx1.g.dreamhost.com [208.97.132.126]) by core3.amsl.com (Postfix) with ESMTP id C1B0628C15F for ; Thu, 31 Mar 2011 06:00:45 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 727282F406D for ; Thu, 31 Mar 2011 06:02:25 -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; q=dns; s=cryptonector.com; b=J+AiAWQbspqxRiFKx9bDx NaWLrUV/PmB/iJpTzlf/2sb/ZMh/Y0fE6tw16H+CiyP1L6jwll7nTAi/V2/siCbx cSCYJMsT6qZJ6JITwUqiVGyreay6teBrqAPoePNp7DaqCWdtXDhgA9H2lwhqVY6D Jx5pbpXT26Zxj6XCg1+HeQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=kBaQvJ2isQGxuYTryliS /wHv7zA=; b=YmjOBOySxBBlXbUe1RTNO/Dbhu/IxDUVDM4/Nqy8bfEoDQ44XkPQ w4hSlHlZTrAka2eNBQKsEK2yApdpe2iyO/nF3nnRCVBjgbjGb8Fsy67Su0QOoqrO dWvD1VVBlooSvxglHQRAjwnkoyQlvPoE05nj8ritMABDiUvG0n6varo= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 4F96E2F4060 for ; Thu, 31 Mar 2011 06:02:25 -0700 (PDT) Received: by vxg33 with SMTP id 33so2132615vxg.31 for ; Thu, 31 Mar 2011 06:02:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.65 with SMTP id u1mr3486432vdt.310.1301576544604; Thu, 31 Mar 2011 06:02:24 -0700 (PDT) Received: by 10.52.162.70 with HTTP; Thu, 31 Mar 2011 06:02:24 -0700 (PDT) Received: by 10.52.162.70 with HTTP; Thu, 31 Mar 2011 06:02:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 08:02:24 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: multipart/alternative; boundary=20cf307cff8e96d19f049fc6e736 Cc: abfab@ietf.org Subject: Re: [abfab] Mutual authentication and channel binding should be required X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:00:46 -0000 --20cf307cff8e96d19f049fc6e736 Content-Type: text/plain; charset=UTF-8 Just require mutual auth. What's the cost? Nico -- --20cf307cff8e96d19f049fc6e736 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Just require mutual auth.=C2=A0 What's the cost?

Nico
--

--20cf307cff8e96d19f049fc6e736-- From rafa@um.es Thu Mar 31 06:34:09 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAC228C155 for ; Thu, 31 Mar 2011 06:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ii6F0KW25g7c for ; Thu, 31 Mar 2011 06:34:09 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by core3.amsl.com (Postfix) with ESMTP id D11C828C141 for ; Thu, 31 Mar 2011 06:34:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 6CCEA535CE; Thu, 31 Mar 2011 15:35:47 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ysMzpzVlg6Bp; Thu, 31 Mar 2011 15:35:47 +0200 (CEST) Received: from inf-205-102.inf.um.es (inf-205-102.inf.um.es [155.54.205.102]) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPA id D10A0535A6; Thu, 31 Mar 2011 15:35:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> Date: Thu, 31 Mar 2011 15:35:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> To: Luke Howard X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:34:09 -0000 Hi Luke, El 31/03/2011, a las 12:06, Luke Howard escribi=F3: >> I was wondering what are the exact implications of not protecting the = information until the EAP authentication ends up with a key. If certain = particular flags are unset during the conversation because it is not = protected, the negotiation should fail, right?. So some sort of = denial-of-service problem will raise. Is that what you had in mind?.=20 >=20 > Right, it should fail. If there is no integrity protection of, in this = case, the client-requested-mutual-authentication flag, then it would = silently succeed. However, in my mind you may confirm the value of that flag seen by both = parties with an integrity-protected "binding" exchange after the key = material has been exported by the EAP authentication. >=20 > -- Luke ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From lukeh@padl.com Thu Mar 31 06:51:41 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB2128C171 for ; Thu, 31 Mar 2011 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlBGTEc1ajJP for ; Thu, 31 Mar 2011 06:51:38 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 66EDD3A6B3D for ; Thu, 31 Mar 2011 06:51:38 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VDr6KW021588; Thu, 31 Mar 2011 09:53:09 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> Date: Fri, 1 Apr 2011 00:53:06 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:51:41 -0000 Hi Rafa, >>> I was wondering what are the exact implications of not protecting = the information until the EAP authentication ends up with a key. If = certain particular flags are unset during the conversation because it is = not protected, the negotiation should fail, right?. So some sort of = denial-of-service problem will raise. Is that what you had in mind?.=20 >>=20 >> Right, it should fail. If there is no integrity protection of, in = this case, the client-requested-mutual-authentication flag, then it = would silently succeed. >=20 > However, in my mind you may confirm the value of that flag seen by = both parties with an integrity-protected "binding" exchange after the = key material has been exported by the EAP authentication. Yes, this is (more or less) what we're proposing. If you want to see an = possible approach I tried, you can see the tlv-mic branch of Moonshot. -- Luke= From leifj@sunet.se Thu Mar 31 06:53:27 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 763C53A6B10 for ; Thu, 31 Mar 2011 06:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XzDiFNcjazk for ; Thu, 31 Mar 2011 06:53:26 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 2BCDF3A687F for ; Thu, 31 Mar 2011 06:53:25 -0700 (PDT) Received: from [130.129.8.61] ([130.129.8.61]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p2VDt1n5010725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Mar 2011 15:55:04 +0200 (CEST) Message-ID: <4D9487B5.7060403@sunet.se> Date: Thu, 31 Mar 2011 15:55:01 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:53:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Yes, this is (more or less) what we're proposing. If you want to see an possible approach I tried, you can see the tlv-mic branch of Moonshot. Luke can I get you to formulate that approach in English for those of us who do not track moonshot code. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2Uh7UACgkQ8Jx8FtbMZnfbAgCcCy2v34mzWHnY9UmHScavYrmR QPEAnRsXXh2Ou3QnN9vUx9YlEtgr2sXy =aGm9 -----END PGP SIGNATURE----- From hartmans@painless-security.com Thu Mar 31 06:53:42 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAC4D3A687F for ; Thu, 31 Mar 2011 06:53:42 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pveGkDIZmduB for ; Thu, 31 Mar 2011 06:53:42 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 0B2763A6B10 for ; Thu, 31 Mar 2011 06:53:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-45ef.meeting.ietf.org [130.129.69.239]) (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 2D848203BA; Thu, 31 Mar 2011 09:52:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CA2164541; Thu, 31 Mar 2011 09:55:18 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Thu, 31 Mar 2011 09:55:18 -0400 In-Reply-To: (Nico Williams's message of "Thu, 31 Mar 2011 08:00:00 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:53:42 -0000 >>>>> "Nico" == Nico Williams writes: Nico> If this were the only unauthenticated plaintext requiring Nico> protection... then you could require that all such flags be Nico> set that the mechanism supports. We can try to do this. The catch comes in because the mechanism may support features the environment does not. For example, we will require behavior out of EAP channel binding; see the draft. If the server does not verify the right attributes in channel binding then we will not indicate mutual auth to the initiator. It's desirable especially for RFC 4462 to also not indicate mutual to the acceptor in this case. Thus, an authenticated flag requirement. --Sam From rafa@UM.ES Thu Mar 31 07:03:32 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 661843A6918 for ; Thu, 31 Mar 2011 07:03:32 -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=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG2hv7f8wJMd for ; Thu, 31 Mar 2011 07:03:31 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by core3.amsl.com (Postfix) with ESMTP id 623EB3A687C for ; Thu, 31 Mar 2011 07:03:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 808C44BB04; Thu, 31 Mar 2011 16:05:09 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4AgxbBa0lopM; Thu, 31 Mar 2011 16:05:09 +0200 (CEST) Received: from inf-205-102.inf.um.es (inf-205-102.inf.um.es [155.54.205.102]) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPA id 961E24BCE1; Thu, 31 Mar 2011 16:05:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Thu, 31 Mar 2011 16:05:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <89A5EBD0-5219-4C3D-8684-7D2449A7B9A5@UM.ES> References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> To: Luke Howard X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Rafa Marin Lopez Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:03:32 -0000 Hi Luke, El 31/03/2011, a las 15:53, Luke Howard escribi=F3: > Hi Rafa, >=20 >>>> I was wondering what are the exact implications of not protecting = the information until the EAP authentication ends up with a key. If = certain particular flags are unset during the conversation because it is = not protected, the negotiation should fail, right?. So some sort of = denial-of-service problem will raise. Is that what you had in mind?.=20 >>>=20 >>> Right, it should fail. If there is no integrity protection of, in = this case, the client-requested-mutual-authentication flag, then it = would silently succeed. >>=20 >> However, in my mind you may confirm the value of that flag seen by = both parties with an integrity-protected "binding" exchange after the = key material has been exported by the EAP authentication. >=20 > Yes, this is (more or less) what we're proposing. If you want to see = an possible approach I tried, you can see the tlv-mic branch of = Moonshot. Yes, we had also thought about this "binding" and that it is why I was = commenting it. >=20 > -- Luke ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From lukeh@padl.com Thu Mar 31 07:04:17 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8501D3A6A92 for ; Thu, 31 Mar 2011 07:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oey736btDFod for ; Thu, 31 Mar 2011 07:04:16 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 4D7233A687C for ; Thu, 31 Mar 2011 07:04:16 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VE5ntu011857; Thu, 31 Mar 2011 10:05:52 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <4D9487B5.7060403@sunet.se> Date: Fri, 1 Apr 2011 01:05:49 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:04:17 -0000 Leif, On 01/04/2011, at 12:55 AM, Leif Johansson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >> Yes, this is (more or less) what we're proposing. If you want to see = an possible approach I tried, you can see the tlv-mic branch of = Moonshot. >=20 > Luke can I get you to formulate that approach in English for those of > us who do not track moonshot code. When the initiator has sent its last token, it calls GSS_GetMIC on the = entire conversation (including the last leg excepting the MIC). The MIC = is sent in a TLV-tagged token along with other extension tokens = (currently only one is defined for the initiator, containing GSS channel = binding information). The acceptor verifies the initiator MIC and then, in its last leg, calls = GSS_GetMIC on the entire conversation (including both last legs, = excepting the acceptor MIC) and sends it in an extension token to the = initiator. The initiator verifies the acceptor MIC before returning = GSS_S_COMPLETE. (It is true that this approach does require the client = and server to maintain the entire conversation state.) With respect to communicating the mutual authentication state, a new TLV = token type is defined containing a 32-bit integer in network byte order, = which consists of req_flags as passed to GSS_Init_sec_context. These = flags are masked by, currently, GSS_C_MUTUAL_FLAG before encoding. Other = flags may be allowed in the future; at this stage we do not wish to = reveal in plaintext anything more than the mutual authentication state. Once the acceptor returns GSS_S_COMPLETE, it will set the received = mutual authentication state in ret_flags. -- Luke= From rafa@um.es Thu Mar 31 07:09:09 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25EB13A6B4A for ; Thu, 31 Mar 2011 07:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAaceM1oYKhN for ; Thu, 31 Mar 2011 07:09:08 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by core3.amsl.com (Postfix) with ESMTP id C53FE3A6A92 for ; Thu, 31 Mar 2011 07:09:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 0925E4BC4D; Thu, 31 Mar 2011 16:10:47 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C6HTT5yiNR4c; Thu, 31 Mar 2011 16:10:46 +0200 (CEST) Received: from inf-205-102.inf.um.es (inf-205-102.inf.um.es [155.54.205.102]) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPA id 4728A4B8F3; Thu, 31 Mar 2011 16:10:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Thu, 31 Mar 2011 16:10:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1567B5C1-96DA-4C81-A1CA-E71E0FF42FDE@um.es> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:09:09 -0000 Hi Sam, El 31/03/2011, a las 14:01, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 > Rafa> I was wondering what are the exact implications of not > Rafa> protecting the information until the EAP authentication ends > Rafa> up with a key. If certain particular flags are unset during > Rafa> the conversation because it is not protected, the negotiation > Rafa> should fail, right?. So some sort of denial-of-service = problem > Rafa> will raise. Is that what you had in mind?. >=20 > If we have protection. then an attacker can cause a denial of service = by > changing the negotiation. > However, in the case of the mutual authentication flag, if we don't = have > protection, there is a more serious attack. > In that situation, an attacker can set the mutual authentication flag > when the mutual authentication did not happen. > The server may think the client confirmed the server's identity when > that did not happen. >=20 > We can protect this after the key is established by sending some > checksum or keyed hash that covers the flag in question. That is precisely what I had in mind. Moreover I agree with Alper about = the use of EAP methods that only requires one-way authentication are not = convenient at all. Even more I cannot remember now if there is any EAP = method with one-way authentication which export keys and can be = considered as a secure solution.=20 >=20 > Rafa> I say this because, as you may know, there are some EAP > Rafa> lower-layers which does not need to assume that there will be > Rafa> a pre-established protected channel to exchange EAP. >=20 > abfab is such a lower layer. I know abfab is the lower-layer, but I thought the discussion was = related with the possible need to protect the abfab lower-layer BEFORE = the EAP authentication. >=20 > Rafa> Best regards. >=20 >=20 >=20 >=20 > Rafa> El 31/03/2011, a las 10:03, Sam Hartman escribi=F3: >=20 >>>=20 >>>=20 >>> Folks, during today's meeting we discussed the need for >>> protecting information exchanged during the context exchange. >>>=20 >>> An example of this need would be protecting context flags from >>> the client to the server. Some server implementations require >>> that certain context flags be set. As an example ssh servers >>> following RFC 4462 require the mutual flag be set. This needs to >>> be integrity protected. >>>=20 >>> There are a number of possible options: >>>=20 >>> 1) Integrity protect each token separately. Down side: more >>> complex especially if tokens need integrity protection that are >>> exchanged before a key is available. >>>=20 >>> 2) Extend our mechanism to depend on a specific hash function. >>> Disadvantage: requires us dealing with crypto primitives directly >>> . Adds complexity to specificiation of the mechanisms. >>>=20 >>> 3) Provide a gss_getmic or similar of the entire conversation. >>> The disadvantage here is that the client needs to maintain state >>> sufficient to hold a copy of the conversation. If there is a >>> stateless server, this ever-increasing state needs to be >>> transported back and forth for each message. >>>=20 >>> --Sam _______________________________________________ abfab >>> mailing list abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >=20 > Rafa> ------------------------------------------------------- = Rafael > Rafa> Marin Lopez, PhD Dept. Information and Communications > Rafa> Engineering (DIIC) Faculty of Computer Science-University of > Rafa> Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: > Rafa> +34868884151 e-mail: > Rafa> rafa@um.es = ------------------------------------------------------- >=20 >=20 >=20 >=20 >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From lukeh@padl.com Thu Mar 31 07:12:52 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2BD3A6B49 for ; Thu, 31 Mar 2011 07:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeJTD1JvkQU8 for ; Thu, 31 Mar 2011 07:12:51 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 6B1883A6B13 for ; Thu, 31 Mar 2011 07:12:51 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VEEPBv028440; Thu, 31 Mar 2011 10:14:27 -0400 From: Luke Howard Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-63--996366031 Date: Fri, 1 Apr 2011 01:14:24 +1100 In-Reply-To: To: abfab@ietf.org References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> Message-Id: <980B7D2A-A0B5-4C23-BBA3-1A8C96D8DC98@padl.com> X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:12:52 -0000 --Apple-Mail-63--996366031 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > With respect to communicating the mutual authentication state, a new = TLV token type is defined containing a 32-bit integer in network byte = order, which consists of req_flags as passed to GSS_Init_sec_context. = These flags are masked by, currently, GSS_C_MUTUAL_FLAG before encoding. = Other flags may be allowed in the future; at this stage we do not wish = to reveal in plaintext anything more than the mutual authentication = state. This token is sent in the last leg by the initiator. It is not marked = critical; if the acceptor does not receive it, after verifying the = initiator MIC, it should assume the client did not do mutual = authentication. I also prototyped an extension negotiation mechanism: at the start the = initiator can send an extension token containing a set of types = indicating the acceptor extensions it accepts; and the acceptor can do = the converse. See below for a list of token types: #define ITOK_TYPE_NONE 0x00000000 #define ITOK_TYPE_CONTEXT_ERR 0x00000001 /* critical */ #define ITOK_TYPE_ACCEPTOR_NAME_REQ 0x00000002 /* TBD */ #define ITOK_TYPE_ACCEPTOR_NAME_RESP 0x00000003 /* TBD */ #define ITOK_TYPE_EAP_RESP 0x00000004 /* critical, = required, if not reauth */ #define ITOK_TYPE_EAP_REQ 0x00000005 /* critical, = required, if not reauth */ #define ITOK_TYPE_GSS_CHANNEL_BINDINGS 0x00000006 /* optional */ #define ITOK_TYPE_REAUTH_CREDS 0x00000007 /* optional */ #define ITOK_TYPE_REAUTH_REQ 0x00000008 /* optional */ #define ITOK_TYPE_REAUTH_RESP 0x00000009 /* optional */ #define ITOK_TYPE_GSS_FLAGS 0x0000000A /* optional */ #define ITOK_TYPE_INITIATOR_MIC 0x0000000B /* required */ #define ITOK_TYPE_ACCEPTOR_MIC 0x0000000C /* required */ #define ITOK_TYPE_SUPPORTED_ACCEPTOR_EXTS 0x0000000D /* optional */ #define ITOK_TYPE_SUPPORTED_INITIATOR_EXTS 0x0000000E /* optional */ Again, this is mostly my private experimentation, it's not in the main = Moonshot branch and I'm not advocating either way vis ABFAB. -- Luke= --Apple-Mail-63--996366031 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
With respect to communicating the = mutual authentication state, a new TLV token type is defined containing = a 32-bit integer in network byte order, which consists of req_flags as = passed to GSS_Init_sec_context. These flags are masked by, currently, = GSS_C_MUTUAL_FLAG before encoding. Other flags may be allowed in the = future; at this stage we do not wish to reveal in plaintext anything = more than the mutual authentication = state.

This token is sent in = the last leg by the initiator. It is not marked critical; if the = acceptor does not receive it, after verifying the initiator MIC, it = should assume the client did not do mutual = authentication.

I also prototyped an extension = negotiation mechanism: at the start the initiator can send an extension = token containing a set of types indicating the acceptor extensions it = accepts; and the acceptor can do the converse. See below for a list of = token types:

#define ITOK_TYPE_NONE       =               =  0x00000000
#define ITOK_TYPE_CONTEXT_ERR       =         0x00000001 /* critical */
#define = ITOK_TYPE_ACCEPTOR_NAME_REQ         0x00000002 /* = TBD */
#define ITOK_TYPE_ACCEPTOR_NAME_RESP       =  0x00000003 /* TBD */
#define ITOK_TYPE_EAP_RESP     =              0x00000004 /* critical, = required, if not reauth */
#define ITOK_TYPE_EAP_REQ     =               0x00000005 /* critical, = required, if not reauth */
#define ITOK_TYPE_GSS_CHANNEL_BINDINGS =      0x00000006 /* optional */
#define = ITOK_TYPE_REAUTH_CREDS             =  0x00000007 /* optional */
#define ITOK_TYPE_REAUTH_REQ   =              0x00000008 /* optional = */
#define ITOK_TYPE_REAUTH_RESP           =     0x00000009 /* optional */
#define ITOK_TYPE_GSS_FLAGS =                 0x0000000A /* = optional */
#define ITOK_TYPE_INITIATOR_MIC       =       0x0000000B /* required */
#define = ITOK_TYPE_ACCEPTOR_MIC             =  0x0000000C /* required */
#define = ITOK_TYPE_SUPPORTED_ACCEPTOR_EXTS   0x0000000D /* optional = */
#define ITOK_TYPE_SUPPORTED_INITIATOR_EXTS  0x0000000E /* = optional */

Again, this is mostly my = private experimentation, it's not in the main Moonshot branch and I'm = not advocating either way vis ABFAB.

-- = Luke= --Apple-Mail-63--996366031-- From lukeh@padl.com Thu Mar 31 07:14:52 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD0FB3A6AD7 for ; Thu, 31 Mar 2011 07:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf61p3Q9Jbij for ; Thu, 31 Mar 2011 07:14:51 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id BBABD3A6A92 for ; Thu, 31 Mar 2011 07:14:51 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VEGRVC032533; Thu, 31 Mar 2011 10:16:29 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <1567B5C1-96DA-4C81-A1CA-E71E0FF42FDE@um.es> Date: Fri, 1 Apr 2011 01:16:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1567B5C1-96DA-4C81-A1CA-E71E0FF42FDE@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:14:52 -0000 > I know abfab is the lower-layer, but I thought the discussion was = related with the possible need to protect the abfab lower-layer BEFORE = the EAP authentication. You can protect parts of the conversation that happen before the EAP = authentication, you just can't verify them until afterwards. There was a separate question in the meeting about protecting = application data that happens before EAP authentication (such as SASL = mechanism negotiation), I suggested that you could use GSS channel = bindings to protect this. Or you could restart the negotiation within an = integrity protected channel. -- Luke= From nico@cryptonector.com Thu Mar 31 07:28:32 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9589828C0EA for ; Thu, 31 Mar 2011 07:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZetkvrpFjwn for ; Thu, 31 Mar 2011 07:28:31 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 99B8128C0F4 for ; Thu, 31 Mar 2011 07:28:31 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 5BEF167C074 for ; Thu, 31 Mar 2011 07:30:11 -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; q=dns; s=cryptonector.com; b=S6F4N5blpQ2MdkiMqA7Pt vqNmCynP0Jx08ibjbluATn/G2iWNHio3ECyXrHH9AJxXXW4EWAgp4JyIXxJKQ6XJ PBIlgZA7gUa0UHzN9dJ85q3b9M9YbOU25+BTC3aYB2RHqPJEYKo4XeZPB3ghewsd yxO4s/64WiFJ8StKhRzWI0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=00493K/1Y21jiezbdtca 127y63g=; b=XlQ4ATmvW5SFQNUVYYwL0keyBU0+Qnbhw66T2XomALoIzKOciwaM ZDghkTl2NMPe8OUOOvxOIWz9lfhsDT+78JAZvmlewfcAQyrPMxtuftK89Aw1wC9L 1dikog2EacGzG9KIHAi5CJ4EVGx66/O2utiWsZTr1z6ybIAWvuNSaBU= Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 05F6F67C06D for ; Thu, 31 Mar 2011 07:30:10 -0700 (PDT) Received: by wyb29 with SMTP id 29so2333198wyb.31 for ; Thu, 31 Mar 2011 07:30:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.245.6 with SMTP id n6mr2163927wer.40.1301581809412; Thu, 31 Mar 2011 07:30:09 -0700 (PDT) Received: by 10.216.64.74 with HTTP; Thu, 31 Mar 2011 07:30:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 09:30:09 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:28:32 -0000 [resend] On Mar 31, 2011 3:03 AM, "Sam Hartman" wrote: > Folks, during today's meeting we discussed the need for protecting > information exchanged during the context exchange. > > An example of this need would be protecting context flags from the > client to the server. > Some server implementations require that certain context flags be set. > As an example ssh servers following RFC 4462 require the mutual flag be > set. > This needs to be integrity protected. If this were the only unauthenticated plaintext requiring protection... then you could require that all such flags be set that the mechanism supports. > There are a number of possible options: > > 1) Integrity protect each token separately. Down side: more complex > especially if tokens need integrity protection that are exchanged before > a key is available. You'd have to store or re-create those messages that come before kwy exchange. > 2) Extend our mechanism to depend on a specific hash function. > Disadvantage: requires us dealing with crypto primitives directly . Adds > complexity to specificiation of the mechanisms. Also, hash agility. TLS 1.2 didn't do this in a well performing way and you'd have the same problem (you can't know a priori which hash function you'll negotiate, so you either use them all as you go or keep the messages. > 3) Provide a gss_getmic or similar of the entire conversation. The > disadvantage here is that the client needs to maintain state sufficient > to hold a copy of the conversation. If there is a stateless server, this > ever-increasing state needs to be transported back and forth for each > message. 4) Re-construct those messages near the end of the exchange, storing only iyems such as nonces in the interim. Nico -- From alex@um.es Thu Mar 31 07:32:38 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8018A28C133 for ; Thu, 31 Mar 2011 07:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olXcEm-s3jVW for ; Thu, 31 Mar 2011 07:32:37 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by core3.amsl.com (Postfix) with ESMTP id 613B928C0F7 for ; Thu, 31 Mar 2011 07:32:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 9DE72535DA for ; Thu, 31 Mar 2011 16:34:15 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LAf4dNy1PXPt for ; Thu, 31 Mar 2011 16:34:15 +0200 (CEST) Received: from [155.54.205.224] (inf-205-224.inf.um.es [155.54.205.224]) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPA id EE9BD535CE for ; Thu, 31 Mar 2011 16:34:13 +0200 (CEST) Message-ID: <4D9490E8.9040702@um.es> Date: Thu, 31 Mar 2011 16:34:16 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: abfab@ietf.org References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:32:38 -0000 > The acceptor verifies the initiator MIC and then, in its last leg, calls GSS_GetMIC on the entire conversation (including both last legs, excepting the acceptor MIC) and sends it in an extension token to the initiator. The initiator verifies the acceptor MIC before returning GSS_S_COMPLETE. (It is true that this approach does require the client and server to maintain the entire conversation state.) Maybe this is just a stupid question, but do they really need to maintain state of the entire conversation? I mean, both parties could just maintain the result of a hash over the conversation so far, built in an iterative way. Something like this: state' = hash (state, new_message) At the end of the conversation, they could compute GSS_mic over the state. May be the overload of computing such hashes is worse than the memory needed to store the entire state. Regards, Alejandro > With respect to communicating the mutual authentication state, a new TLV token type is defined containing a 32-bit integer in network byte order, which consists of req_flags as passed to GSS_Init_sec_context. These flags are masked by, currently, GSS_C_MUTUAL_FLAG before encoding. Other flags may be allowed in the future; at this stage we do not wish to reveal in plaintext anything more than the mutual authentication state. > > Once the acceptor returns GSS_S_COMPLETE, it will set the received mutual authentication state in ret_flags. > > -- Luke > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From lukeh@padl.com Thu Mar 31 07:34:58 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2753A6B49 for ; Thu, 31 Mar 2011 07:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmutzPMx4msH for ; Thu, 31 Mar 2011 07:34:58 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id F02D53A6B4A for ; Thu, 31 Mar 2011 07:34:57 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VEaUTZ007250; Thu, 31 Mar 2011 10:36:33 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 1 Apr 2011 01:36:29 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4C9D4D9B-3674-4847-946B-B98994A95694@padl.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:34:59 -0000 > 4) Re-construct those messages near the end of the exchange, storing > only iyems such as nonces in the interim. That's a pretty clever idea, but -- if you're talking about = reconstructing the entire EAP exchange -- I don't think it would be very = practical from an implementation standpoint, particularly when a AAA = server is involved. A simple option, if we keep this last-round-trip extension exchange, is = to protect just that. It assumes that we'll never send an extension = token in an earlier leg that requires integrity protection. (And, given = we might want to do extension negotiation for something we haven't = thought of yet, and avoid downgrade attacks, my gut feeling is that = protecting the entire conversation is something we should bake into the = protocol now if it's not too expensive.) -- Luke= From lukeh@padl.com Thu Mar 31 07:37:47 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 748E53A6B49 for ; Thu, 31 Mar 2011 07:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r46h+zWw72X1 for ; Thu, 31 Mar 2011 07:37:46 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 98D403A6A92 for ; Thu, 31 Mar 2011 07:37:46 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VEdLtv011454; Thu, 31 Mar 2011 10:39:24 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <4D9490E8.9040702@um.es> Date: Fri, 1 Apr 2011 01:39:21 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <3ED94C4E-3D5A-4428-98AB-0AB672C6F1B5@padl.com> References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> <4D9490E8.9040702@um.es> To: Alejandro Perez Mendez X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:37:47 -0000 > Maybe this is just a stupid question, but do they really need to = maintain state of the entire conversation? I mean, both parties could = just maintain the result of a hash over the conversation so far, built = in an iterative way. Something like this: >=20 > state' =3D hash (state, new_message) >=20 > At the end of the conversation, they could compute GSS_mic over the = state. >=20 > May be the overload of computing such hashes is worse than the memory = needed to store the entire state. It's not this so much. The problem is hash agility: we want GSS EAP to = use the crypto primitives provided by RFC 3961, and this does not have a = primitive for incrementally updating a checksum. So, we could extend RFC = 3961 (which, wearing my implementors' hat, will involve some fairly = intrusive changes to the popular Kerberos implementations). Or we could = use a fixed checksum algorithm, but that's brittle and makes the entire = protocol vulnerable if a weakness is ever discovered. Or we could build = in some mechanism for negotiating checksum algorithms, but that risks = re-inventing the wheel. Sam or Nico can explain this better than I, I'm sure. -- Luke= From hartmans@painless-security.com Thu Mar 31 07:43:34 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8C633A6B55 for ; Thu, 31 Mar 2011 07:43:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4ED9cjAGGFf for ; Thu, 31 Mar 2011 07:43:34 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 2D16C3A6B10 for ; Thu, 31 Mar 2011 07:43:34 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-45ef.meeting.ietf.org [130.129.69.239]) (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 637FA20313; Thu, 31 Mar 2011 10:42:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 39EBA4541; Thu, 31 Mar 2011 10:45:11 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> <4D9490E8.9040702@um.es> Date: Thu, 31 Mar 2011 10:45:11 -0400 In-Reply-To: <4D9490E8.9040702@um.es> (Alejandro Perez Mendez's message of "Thu, 31 Mar 2011 16:34:16 +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] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:43:35 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: >> The acceptor verifies the initiator MIC and then, in its last >> leg, calls GSS_GetMIC on the entire conversation (including both >> last legs, excepting the acceptor MIC) and sends it in an >> extension token to the initiator. The initiator verifies the >> acceptor MIC before returning GSS_S_COMPLETE. (It is true that >> this approach does require the client and server to maintain the >> entire conversation state.) Alejandro> Maybe this is just a stupid question, but do they really Alejandro> need to maintain state of the entire conversation? I Alejandro> mean, both parties could just maintain the result of a Alejandro> hash over the conversation so far, built in an iterative Alejandro> way. Something like this: This is not a stupid question. elThis is what I was trying to explain with my option 2 above. The down side is you must decide on/negotiate a particular cryptographic hash. From nico@cryptonector.com Thu Mar 31 07:48:43 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8849528C0EA for ; Thu, 31 Mar 2011 07:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rdk2rdYUtqC for ; Thu, 31 Mar 2011 07:48:42 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by core3.amsl.com (Postfix) with ESMTP id 01E1F3A6B10 for ; Thu, 31 Mar 2011 07:48:42 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id C77D51B4081 for ; Thu, 31 Mar 2011 07:50:21 -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; q=dns; s=cryptonector.com; b=iiduOg05Ede0p+DaG4ORt YSRhiBHsHqYTukwmWvtsmhZ6WXP9ecafov9rafmXHcOMXqAJwFfvabmBjwvsDl2c LNfqBa92uNiFn17uc9O8Z0/dFB24H1XEcx4I7q6PgaXHv9DaCAF1hDmSdZJs7WJB QpTVBX4vqBRFQWoK3oFdGg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rwHasFs4z7uFn6YzG7uu 1m0+I50=; b=RJ8O9UyIMMLNmkWqLN9q+YK+1g9IibahR0hkooHHtiN+GSaaOFT7 xgxF5ogdR+RzGH8eyMREXtCNGYfS3vL6+mxSJxRd+GojeMYqwmWiZbuhomDRV7Dc 7Fk7AT780YOiVNnqtBlLhtOSRove1FUbWovsfC561lNp4/37RDMy8EU= Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 7248D1B406F for ; Thu, 31 Mar 2011 07:50:21 -0700 (PDT) Received: by wwa36 with SMTP id 36so2040501wwa.13 for ; Thu, 31 Mar 2011 07:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.59.81 with SMTP id r59mr2685578wec.40.1301583020208; Thu, 31 Mar 2011 07:50:20 -0700 (PDT) Received: by 10.216.64.74 with HTTP; Thu, 31 Mar 2011 07:50:20 -0700 (PDT) In-Reply-To: <4D9490E8.9040702@um.es> References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> <4D9490E8.9040702@um.es> Date: Thu, 31 Mar 2011 09:50:20 -0500 Message-ID: From: Nico Williams To: Alejandro Perez Mendez Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:48:43 -0000 On Thu, Mar 31, 2011 at 9:34 AM, Alejandro Perez Mendez wrote: > Maybe this is just a stupid question, but do they really need to maintain > state of the entire conversation? I mean, both parties could just maintain > the result of a hash over the conversation so far, built in an iterative > way. Something like this: > > state' = hash (state, new_message) > > At the end of the conversation, they could compute GSS_mic over the state. > > May be the overload of computing such hashes is worse than the memory needed > to store the entire state. That's what TLS does. It's clever, and it works, but you get into hash agility issues. If you need to negotiate a hash function (and you will), then you find yourself back at square #1 because at least for the first N messages, where N >=1 (but probably N == 1) you don't know what the hash algorithm will be. Either you use all your hash functions (whoops! slow!) or you hold the message(s) in memory (expensive). The good news is that most new phones and such devices have enough memory for this (and then some). Nico -- From rafa@UM.ES Thu Mar 31 12:25:13 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D73D728C0FC for ; Thu, 31 Mar 2011 12:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-taen1fECqr for ; Thu, 31 Mar 2011 12:25:13 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by core3.amsl.com (Postfix) with ESMTP id 9A06028C0FB for ; Thu, 31 Mar 2011 12:25:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id BCFC6538E9; Thu, 31 Mar 2011 21:26:51 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bkXhJiWTmtUc; Thu, 31 Mar 2011 21:26:51 +0200 (CEST) Received: from [192.168.1.65] (179.Red-83-57-163.dynamicIP.rima-tde.net [83.57.163.179]) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPA id E6836536F2; Thu, 31 Mar 2011 21:26:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Thu, 31 Mar 2011 21:26:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D64497B-CC68-4DBD-A182-5521C7466006@UM.ES> References: <1567B5C1-96DA-4C81-A1CA-E71E0FF42FDE@um.es> To: Luke Howard X-Mailer: Apple Mail (2.1082) Cc: abfab@ietf.org, Rafa Marin Lopez Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 19:25:13 -0000 Hi Luke, El 31/03/2011, a las 16:16, Luke Howard escribi=F3: >> I know abfab is the lower-layer, but I thought the discussion was = related with the possible need to protect the abfab lower-layer BEFORE = the EAP authentication. >=20 >=20 > You can protect parts of the conversation that happen before the EAP = authentication, you just can't verify them until afterwards. That is clear. >=20 > There was a separate question in the meeting about protecting = application data that happens before EAP authentication (such as SASL = mechanism negotiation), I suggested that you could use GSS channel = bindings to protect this. I see. > Or you could restart the negotiation within an integrity protected = channel. Exactly. That integrity protected channel can be derived from the EAP = key material and can be used to securely confirm the parameters = exchanged during the unsecured negotiation phase. >=20 > -- Luke ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From nico@cryptonector.com Thu Mar 31 12:44:26 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C93128C10C for ; Thu, 31 Mar 2011 12:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IBDsSQD9AH4 for ; Thu, 31 Mar 2011 12:44:25 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 559A328C108 for ; Thu, 31 Mar 2011 12:44:25 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 20FF41B4061 for ; Thu, 31 Mar 2011 12:46:05 -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=R3GIQ1EN43YGXIrpUbQREQsfNZqaH/xmJhLJPjqzb65k VYw0hKJNM+TCgTWTMtLi5Amb4WGLT7W8AE794y97i3mpVPHDYKzV2w7gJiMoeBUD nfMgM9y2WZLaND5iZ/i0clhZghmZV/DwKb/TBSUTVsIJQUpVc6hB0jbehg/krlA= 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=wMHjJN6SwboEpV2bLCzaQU69Klc=; b=W9oqnGFqtHy wFb06+fXVBVufnX58i9zQEuCzhU2p4A9bWJrZV8fG8cnr7MeH9HO6YPXkBUgQfGb ZcIC0k2/S6CpMOZ5azhFkz0boU0ACe4oGJeElYOYrxMy9ejt9fLvFFSU1YtBDAub H7D4L9yY87w+ynQyjM4SlHKXTVb0+j0s= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id E83471B405F for ; Thu, 31 Mar 2011 12:46:04 -0700 (PDT) Received: by vxg33 with SMTP id 33so2542435vxg.31 for ; Thu, 31 Mar 2011 12:46:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.169.39 with SMTP id ab7mr4111445vdc.230.1301600764279; Thu, 31 Mar 2011 12:46:04 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 12:46:04 -0700 (PDT) In-Reply-To: <4C9D4D9B-3674-4847-946B-B98994A95694@padl.com> References: <4C9D4D9B-3674-4847-946B-B98994A95694@padl.com> Date: Thu, 31 Mar 2011 14:46:04 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 19:44:26 -0000 On Thu, Mar 31, 2011 at 9:36 AM, Luke Howard wrote: >> 4) Re-construct those messages near the end of the exchange, storing >> only iyems such as nonces in the interim. > > That's a pretty clever idea, but -- if you're talking about reconstructin= g the entire EAP exchange -- I don't think it would be very practical from = an implementation standpoint, particularly when a AAA server is involved. Right, but you might be able to minimize what messages you must cache. Keep in mind that I'm not following all the details of your mechanism, thus I might write something like the above that might not make any sense in the context of your mech. > A simple option, if we keep this last-round-trip extension exchange, is t= o protect just that. It assumes that we'll never send an extension token in= an earlier leg that requires integrity protection. (And, given we might wa= nt to do extension negotiation for something we haven't thought of yet, and= avoid downgrade attacks, my gut feeling is that protecting the entire conv= ersation is something we should bake into the protocol now if it's not too = expensive.) We've seen the unauthenticate plaintext movie, and remakes. They usually don't feature a happy ending. From lukeh@padl.com Thu Mar 31 15:30:30 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36453A6BC0 for ; Thu, 31 Mar 2011 15:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=-0.689, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5nhXZJtQZkM for ; Thu, 31 Mar 2011 15:30:30 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id F2E7F3A67F4 for ; Thu, 31 Mar 2011 15:30:29 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VMW1Xr003656; Thu, 31 Mar 2011 18:32:06 -0400 References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> <4D9490E8.9040702@um.es> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8G4) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8G4) From: Luke Howard Date: Fri, 1 Apr 2011 09:31:56 +1100 To: Nico Williams X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.7 Cc: "abfab@ietf.org" Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 22:30:30 -0000 Note with GSS EAP we don't need to negotiate the hash function inside our me= chanism because it falls out of the enctype, and that in turn from the mech O= ID, so GSS negotiates for us. Assuming you only want to use the mandatory ch= ecksum type, of course. Von meinem iPhone gesendet Am 01/04/2011 um 1:50 schrieb Nico Williams : > On Thu, Mar 31, 2011 at 9:34 AM, Alejandro Perez Mendez wrote= : >> Maybe this is just a stupid question, but do they really need to maintain= >> state of the entire conversation? I mean, both parties could just maintai= n >> the result of a hash over the conversation so far, built in an iterative >> way. Something like this: >>=20 >> state' =3D hash (state, new_message) >>=20 >> At the end of the conversation, they could compute GSS_mic over the state= . >>=20 >> May be the overload of computing such hashes is worse than the memory nee= ded >> to store the entire state. >=20 > That's what TLS does. It's clever, and it works, but you get into > hash agility issues. If you need to negotiate a hash function (and > you will), then you find yourself back at square #1 because at least > for the first N messages, where N >=3D1 (but probably N =3D=3D 1) you don'= t > know what the hash algorithm will be. Either you use all your hash > functions (whoops! slow!) or you hold the message(s) in memory > (expensive). >=20 > The good news is that most new phones and such devices have enough > memory for this (and then some). >=20 > Nico > -- > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From nico@cryptonector.com Thu Mar 31 15:33:40 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FEB3A6AB6 for ; Thu, 31 Mar 2011 15:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqE91WBc6WDY for ; Thu, 31 Mar 2011 15:33:40 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by core3.amsl.com (Postfix) with ESMTP id E8D6B3A67F4 for ; Thu, 31 Mar 2011 15:33:39 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id D0AF32C806E for ; Thu, 31 Mar 2011 15:35:19 -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; q=dns; s=cryptonector.com; b=fXp/PokhT38EsQ7CgxolP TEjg7fWd9715e/HOmxN0C28lawgAgQgDL/7VTlSiT483ClwhsCYYQqQIwT9bB6QV I/cGVZNeTBdB7BIRDFgNmpEaq1LtAE5SOt3+ApR5MMqhzh0DnncgzKEC8UhkdpcZ RXWObbNTZWzOG21T0Wld8g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/XOaCbxF0eZewUGz3hg2 H2Y12aU=; b=EWUOfhsdmwx7gFuDCIztieM2DhYuxzC8Mb6j3lzbrVhvLT1FNyM9 gVspIR/pf0VBGoVjRBf3H5GyGPPliAf/GNies3LJ5ePB7OL8snE239744eVoncL6 v36TznlWnJ1Xal2aj4vJg88r6in1a2+Ghjyo0VSg6wo84jlLSnEXv2E= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id AC0722C806D for ; Thu, 31 Mar 2011 15:35:19 -0700 (PDT) Received: by vxg33 with SMTP id 33so2669392vxg.31 for ; Thu, 31 Mar 2011 15:35:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.74.106 with SMTP id s10mr4350362vdv.150.1301610919106; Thu, 31 Mar 2011 15:35:19 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 15:35:19 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 15:35:19 -0700 (PDT) In-Reply-To: References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> <4D9490E8.9040702@um.es> Date: Thu, 31 Mar 2011 17:35:19 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=20cf3071ccf2781a6b049fcee8ed Cc: "abfab@ietf.org" Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 22:33:40 -0000 --20cf3071ccf2781a6b049fcee8ed Content-Type: text/plain; charset=UTF-8 On Mar 31, 2011 5:32 PM, "Luke Howard" wrote: > > Note with GSS EAP we don't need to negotiate the hash function inside our mechanism because it falls out of the enctype, and that in turn from the mech OID, so GSS negotiates for us. Assuming you only want to use the mandatory checksum type, of course. In that case I'd just bite the bullet and use a hash function and a MIC of the hash. There's costs to this approah, but it seems likely that those will be more acceptable than the alternatives'. Nico -- --20cf3071ccf2781a6b049fcee8ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mar 31, 2011 5:32 PM, "Luke Howard" <lukeh@padl.com> wrote:
>
> Note with GSS EAP we don't need to negotiate the hash function ins= ide our mechanism because it falls out of the enctype, and that in turn fro= m the mech OID, so GSS negotiates for us. Assuming you only want to use the= mandatory checksum type, of course.

In that case I'd just bite the bullet and use a hash function and a = MIC of the hash.=C2=A0 There's costs to this approah, but it seems like= ly that those will be more acceptable than the alternatives'.

Nico
--

--20cf3071ccf2781a6b049fcee8ed-- From lukeh@padl.com Thu Mar 31 15:41:51 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 546A63A6BC6 for ; Thu, 31 Mar 2011 15:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1a4BxSb-QXX for ; Thu, 31 Mar 2011 15:41:50 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id E9AF53A6BC2 for ; Thu, 31 Mar 2011 15:41:49 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VMhIxp025657; Thu, 31 Mar 2011 18:43:24 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-93--965832912 From: Luke Howard In-Reply-To: Date: Fri, 1 Apr 2011 09:43:17 +1100 Message-Id: <3A5D0E4B-4011-48D8-B358-11DA8A486678@padl.com> References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> <4D9490E8.9040702@um.es> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,HTML_MESSAGE X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.8 Cc: "abfab@ietf.org" Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 22:41:51 -0000 --Apple-Mail-93--965832912 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The problem with this approach is that we end up reimplementing RFC = 3961. It's possible now to build an enctype-agnostic implementation, and = this would make that harder, at least with the APIs provided by shipping = Kerberos implementations. -- Luke On 01/04/2011, at 9:35 AM, Nico Williams wrote: > On Mar 31, 2011 5:32 PM, "Luke Howard" wrote: > > > > Note with GSS EAP we don't need to negotiate the hash function = inside our mechanism because it falls out of the enctype, and that in = turn from the mech OID, so GSS negotiates for us. Assuming you only want = to use the mandatory checksum type, of course. >=20 > In that case I'd just bite the bullet and use a hash function and a = MIC of the hash. There's costs to this approah, but it seems likely = that those will be more acceptable than the alternatives'. >=20 > Nico > -- >=20 --Apple-Mail-93--965832912 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The problem with this approach is that we end up reimplementing RFC 3961. It's possible now to build an enctype-agnostic implementation, and this would make that harder, at least with the APIs provided by shipping Kerberos implementations.

-- Luke

On 01/04/2011, at 9:35 AM, Nico Williams wrote:

On Mar 31, 2011 5:32 PM, "Luke Howard" <lukeh@padl.com> wrote:
>
> Note with GSS EAP we don't need to negotiate the hash function inside our mechanism because it falls out of the enctype, and that in turn from the mech OID, so GSS negotiates for us. Assuming you only want to use the mandatory checksum type, of course.

In that case I'd just bite the bullet and use a hash function and a MIC of the hash.  There's costs to this approah, but it seems likely that those will be more acceptable than the alternatives'.

Nico
--


--Apple-Mail-93--965832912-- From nico@cryptonector.com Thu Mar 31 16:31:50 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE2FF3A6ABD for ; Thu, 31 Mar 2011 16:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTZ15gzICIK6 for ; Thu, 31 Mar 2011 16:31:50 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id 07A9C3A69C8 for ; Thu, 31 Mar 2011 16:31:49 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id EF61443807F for ; Thu, 31 Mar 2011 16:33:29 -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; q=dns; s=cryptonector.com; b=lquPYj2JXC7zqg54EG+t9 qYpw/oBZRW/oJqZvZnrQQVINg9gUlHMKFPJp8jn78PiEsXYZ+N9HJzkIKtSfAwSC F8eRLHCT3gzTIVBYL0UwW4MvLwgvjvq9b4n0XiyZEPf7IhEd9rsW3Z3Z1VwRjGSu SdUgv5bdgp90UUMU1DP70g= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CZgEn2GhdaUgyyjSEz5h Sgse/SE=; b=BSpnmR2vkIGKXO5ZZVSbqN4asm6BDb6f2feM0hVkBzsVdDihwjGT cFXM3+xTLs6gjTFskJErUL8fGEXLAvnGYYNi20MgSAI0sahhvsOdkAuuxXib07a/ jUzR1ltCeXA/NwJZEHJ5Bll0pIHTD953awtRcnDNO+qKjSheN2YxkdI= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id C2DF643807C for ; Thu, 31 Mar 2011 16:33:29 -0700 (PDT) Received: by vxg33 with SMTP id 33so2700071vxg.31 for ; Thu, 31 Mar 2011 16:33:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.200 with SMTP id 8mr277961vdg.70.1301614409191; Thu, 31 Mar 2011 16:33:29 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 16:33:29 -0700 (PDT) In-Reply-To: <3A5D0E4B-4011-48D8-B358-11DA8A486678@padl.com> References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> <4D9490E8.9040702@um.es> <3A5D0E4B-4011-48D8-B358-11DA8A486678@padl.com> Date: Thu, 31 Mar 2011 18:33:29 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: "abfab@ietf.org" Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 23:31:51 -0000 On Thu, Mar 31, 2011 at 5:43 PM, Luke Howard wrote: > The problem with this approach is that we end up reimplementing RFC 3961. > It's possible now to build an enctype-agnostic implementation, and this > would make that harder, at least with the APIs provided by shipping Kerberos > implementations. I don't follow. A hash algorithm would be used entirely outside the RFC3961 framework, and the MIC would be the same that the mechanism surely must already support. Nico -- From lukeh@padl.com Thu Mar 31 16:32:40 2011 Return-Path: X-Original-To: abfab@core3.amsl.com Delivered-To: abfab@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D56C3A6ABD for ; Thu, 31 Mar 2011 16:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdb9DzRJHSoD for ; Thu, 31 Mar 2011 16:32:39 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 7B7E93A69C8 for ; Thu, 31 Mar 2011 16:32:39 -0700 (PDT) Received: by us.padl.com with ESMTP id p2VNY9eA030022; Thu, 31 Mar 2011 19:34:16 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Fri, 1 Apr 2011 10:34:08 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5326C314-B46D-49C7-9843-90E192E4404C@padl.com> <6541748B-7183-4F9A-A3F7-C358A1F874BA@um.es> <4D9487B5.7060403@sunet.se> <4D9490E8.9040702@um.es> <3A5D0E4B-4011-48D8-B358-11DA8A486678@padl.com> To: Nico Williams X-Mailer: Apple Mail (2.1084) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.9 Cc: "abfab@ietf.org" Subject: Re: [abfab] Message Integrity for gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 23:32:40 -0000 On 01/04/2011, at 10:33 AM, Nico Williams wrote: > On Thu, Mar 31, 2011 at 5:43 PM, Luke Howard wrote: >> The problem with this approach is that we end up reimplementing RFC = 3961. >> It's possible now to build an enctype-agnostic implementation, and = this >> would make that harder, at least with the APIs provided by shipping = Kerberos >> implementations. >=20 > I don't follow. A hash algorithm would be used entirely outside the > RFC3961 framework, and the MIC would be the same that the mechanism > surely must already support. OK, but how do we choose the hash algorithm? -- Luke=