From ietf@augustcellars.com Wed Aug 1 18:16:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0080C11E811A for ; Wed, 1 Aug 2012 18:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4x8FWQIIKhE for ; Wed, 1 Aug 2012 18:16:03 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1CE11E80FD for ; Wed, 1 Aug 2012 18:16:03 -0700 (PDT) Received: from Tobias (dhcp-10a6.meeting.ietf.org [130.129.16.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 05FD938F28; Wed, 1 Aug 2012 18:16:02 -0700 (PDT) From: "Jim Schaad" To: "Sam Hartman" , References: <00da01cd6ebc$a1768ae0$e463a0a0$@augustcellars.com> In-Reply-To: <00da01cd6ebc$a1768ae0$e463a0a0$@augustcellars.com> Date: Wed, 1 Aug 2012 18:14:37 -0700 Message-ID: <004901cd704c$301bb500$90531f00$@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: AQMp9g8w2Rw/Zais+WJttGNnsnIT8JSMq5sQ Content-Language: en-us Cc: draft-ietf-abfab-eapapplicability-authors@tools.ietf.org, abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:16:04 -0000 Sam or Josh, After writing the below and trying to get a good night sleep. > 6. I think that you might talk about the cases where channel binding COULD > be required even for network authentication. The fact that it is not required > does not mean that it cannot be used. One issue is going to be how an IdP > identifies a network authentication service from a different service for the > purposes of deciding if channel binding is going to be required. I seem to remember at one point that there were some discussions about possibly using abfab for granting of network access of some types of devices. Do I remember incorrectly or is this still a possible usage that might need to be considered in the applicability statement. Jim From ietf@augustcellars.com Wed Aug 1 18:20:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4807A11E8109 for ; Wed, 1 Aug 2012 18:20:05 -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=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaASyWEc6QBn for ; Wed, 1 Aug 2012 18:20:02 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97B4C21F88E0 for ; Wed, 1 Aug 2012 18:20:02 -0700 (PDT) Received: from Tobias (dhcp-10a6.meeting.ietf.org [130.129.16.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4BB322CA36; Wed, 1 Aug 2012 18:20:02 -0700 (PDT) From: "Jim Schaad" To: "'Alper Yegin'" , "'Leif Johansson'" References: <500961A2.4060104@cs.tcd.ie> In-Reply-To: Date: Wed, 1 Aug 2012 18:18:34 -0700 Message-ID: <004a01cd704c$bea01500$3be03f00$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01CD7012.1243FC20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNkzdWx9LqchV+n6DwJc3ijfGZe5AKQccl2Ak5jB4MBMKJnDJPmgVzg Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] EAP applicability statement comment X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:20:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004B_01CD7012.1243FC20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit While it is possible that one should require that network access services should require that channel binding be required. For the general purpose of this update we are restricted to updating for ABFAB usage cases and thus do not have the authority to put additional restrictions on the generic network access service case. That being said, the original presentations in the EMU group did refer to the case of the lying NAS (either in terms of service ability or costs) as one of the things that needed to be addressed. This issue really needs to be addressed in EMU (or maybe EAP) in order to become any type of requirement. Jim From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Wednesday, July 25, 2012 8:57 AM To: Leif Johansson Cc: abfab@ietf.org Subject: Re: [abfab] EAP applicability statement comment Another comment: In most network access use cases all access servers that are served by a particular EAP server are providing the same or very similar types of service. The peer does not need to differentiate between different access network services supported by the same EAP server. This is not accurate. In between the EAP peer and the EAP authentication server, there are zero or more independent service providers (access network provider, roaming exchange, roaming network provider). It's not like all of the access networks being served by the EAP auth server belong to the same service provider (that owns the EAP auth server too). The type of service the mobile device gets differ too (e.g., roaming vs non-roaming). Shouldn't the channel binding requirements equally apply to network access and non-network access cases? Alper On Jul 20, 2012, at 6:41 PM, Leif Johansson wrote: 20 jul 2012 kl. 16:24 skrev "Sam Hartman" : So, I'm really hoping that from a process standpoint we can not look to hard at this. I absolutely agree with Bernard that we need to implement things that meet the 4962 requirements. The implementation I have the most experience with (Moonshot) does implement RFC 4962. We use radsec as the key confidentiality method between AAA server and client. We basically require EAP-TTLS because that's all we're currently implementing channel binding for. The problem is that if we get too picky about IETF process, none of this works. In terms of standardized EAP methods with security, we have EAP-GPSK and EAP-TLS. EAP-TLS doesn't support channel binding and adding it would be difficult. EAP-GPSK probably is something we could use. However, it's the wrong fit for a lot of deployments. RADSEC is a good fit for what we want. Except it's not standards track. Long term, TEAP will be a standards-track method we can move to. Long term, either diameter will catch on, or we'll decide that RADSEC or some other form of security is appropriate for a normative reference from a standards-track spec. I don't think publishing ABFAB is experimental is the right approach. I don't think blocking ABFAB until EAP and RADEXT get done coming up with standards-track mechanisms is the right fix. So, I'm left concluding that being a bit liberal in our process and doing something reasonable with the implementations is the right approach here. So, I think that the right fix for the applicability statement is simply to refer to section 1.2 of RFC 4962 and note that is mandatory-to-implement. _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab This approach sounds reasonable to me too. _______________________________________________ abfab mailing list abfab@ietf.org https://www.ietf.org/mailman/listinfo/abfab ------=_NextPart_000_004B_01CD7012.1243FC20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While it is possible that one should require that network access = services should require that channel binding be required.  For the = general purpose of this update we are restricted to updating for ABFAB = usage cases and thus do not have the authority to put additional = restrictions on the generic network access service = case.

 

That being said, the original presentations in the EMU group did = refer to the case of the lying NAS (either in terms of service ability = or costs) as one of the things that needed to be addressed.  This = issue really needs to be addressed in EMU (or maybe EAP) in order to = become any type of requirement.

 

Jim

 

 

From:= = abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of = Alper Yegin
Sent: Wednesday, July 25, 2012 8:57 = AM
To: Leif Johansson
Cc: = abfab@ietf.org
Subject: Re: [abfab] EAP applicability = statement comment

 

Another = comment:

 

   In most network access use cases =
all access servers
   that are served by a particular =
EAP server are providing the same or
   very similar types of =
service.  The peer does not need to
   differentiate between different =
access network services supported by
   the same EAP =
server.

 

 

This is not accurate. In between the EAP peer and the = EAP authentication server, there are zero or more independent service = providers (access network provider, roaming exchange, roaming network = provider). 

It's not = like all of the access networks being served by the EAP auth server = belong to the same service provider (that owns the EAP auth server = too).

The type of service = the mobile device gets differ too (e.g., roaming vs = non-roaming).

Shouldn't = the channel binding requirements equally apply to network access and = non-network access cases?

 

Alper

 

 

 

 

On Jul 20, 2012, at 6:41 PM, Leif Johansson = wrote:






20 jul 2012 kl. 16:24 skrev "Sam = Hartman" <hartmans@painless-security= .com>:


So, I'm = really hoping that from a process standpoint we can not look = to

hard = at this.  I absolutely agree with Bernard that we need to = implement

things that meet the 4962 = requirements.

 

The = implementation I have the most experience with (Moonshot) = does

implement RFC 4962.  We use radsec as the key = confidentiality method

between AAA server and = client.

 

We = basically require EAP-TTLS because that's all we're = currently

implementing channel binding = for.

 

The = problem is that if we get too picky about IETF process, none of = this

works.  In terms of standardized EAP methods with = security, we have

EAP-GPSK and = EAP-TLS.

EAP-TLS doesn't support channel binding and adding it = would be

difficult.

EAP-GPSK probably is something we could use. However, = it's the wrong fit

for = a lot of deployments.

 

RADSEC is a good fit for what we want. Except it's not = standards track.

 

Long = term, TEAP will be a standards-track method we can move = to.

Long = term,  either diameter will catch on, or we'll decide that = RADSEC

or = some other form of security is appropriate for a normative = reference

from = a standards-track spec.

 

I = don't think publishing ABFAB is experimental is the right = approach.

I = don't think blocking ABFAB until EAP and RADEXT get done coming = up

with = standards-track mechanisms is the right = fix.

 

So, = I'm left concluding that  being a bit liberal in our process = and

doing something reasonable with the implementations is = the right

approach here.

 

So, = I think that the right fix for the applicability statement is = simply

to = refer to section 1.2 of RFC 4962 and note that = is

mandatory-to-implement.

_______________________________________________

abfab mailing = list

abfab@ietf.org

https://www.ietf.org= /mailman/listinfo/abfab



This approach sounds reasonable to me = too.

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

 

------=_NextPart_000_004B_01CD7012.1243FC20-- From leifj@sunet.se Wed Aug 1 18:46:44 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C420921F892D for ; Wed, 1 Aug 2012 18:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVwp27e+-3Ck for ; Wed, 1 Aug 2012 18:46:44 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id BF98A21F892C for ; Wed, 1 Aug 2012 18:46:43 -0700 (PDT) Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q721kbpl011181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Aug 2012 03:46:42 +0200 (CEST) Message-ID: <5019DBFD.8000208@sunet.se> Date: Thu, 02 Aug 2012 03:46:37 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: abfab@ietf.org References: <00da01cd6ebc$a1768ae0$e463a0a0$@augustcellars.com> <004901cd704c$301bb500$90531f00$@augustcellars.com> In-Reply-To: <004901cd704c$301bb500$90531f00$@augustcellars.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:46:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/02/2012 03:14 AM, Jim Schaad wrote: > Sam or Josh, > > After writing the below and trying to get a good night sleep. > >> 6. I think that you might talk about the cases where channel >> binding COULD be required even for network authentication. The >> fact that it is not > required >> does not mean that it cannot be used. One issue is going to be >> how an IdP identifies a network authentication service from a >> different service for > the >> purposes of deciding if channel binding is going to be required. > > I seem to remember at one point that there were some discussions > about possibly using abfab for granting of network access of some > types of devices. Do I remember incorrectly or is this still a > possible usage that might need to be considered in the > applicability statement. Isn't that too deep a recursion for us? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAZ2/wACgkQ8Jx8FtbMZneg0ACgvQNodkmCSnbzbmb01mTD+SK6 FTkAoLX8UN9RIkdLCO5c26gtCLu7P2f1 =bbOY -----END PGP SIGNATURE----- From diego@tid.es Wed Aug 1 22:11:10 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED4711E8109 for ; Wed, 1 Aug 2012 22:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.024 X-Spam-Level: X-Spam-Status: No, score=-5.024 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QU+Nedi0Enez for ; Wed, 1 Aug 2012 22:11:08 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7639511E80EC for ; Wed, 1 Aug 2012 22:11:05 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M8400KBL3QGG0@tid.hi.inet> for abfab@ietf.org; Thu, 02 Aug 2012 07:11:04 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 33.F7.02752.8EB0A105; Thu, 02 Aug 2012 07:11:04 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0M8400KBC3QFG0@tid.hi.inet> for abfab@ietf.org; Thu, 02 Aug 2012 07:11:03 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([fe80::a90d:2f68:6fb8:5c75]) by ex10-htcas3-mad.hi.inet ([::1]) with mapi id 14.02.0298.004; Thu, 02 Aug 2012 07:11:03 +0200 Date: Thu, 02 Aug 2012 05:10:55 +0000 From: "Diego R. Lopez" In-reply-to: <004901cd704c$301bb500$90531f00$@augustcellars.com> X-Originating-IP: [10.95.64.115] To: Jim Schaad Message-id: MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_73vDg2b1HIET6OSdul8aFw)" Content-language: en-US Accept-Language: en-US Thread-topic: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt Thread-index: AQMp9g8w2Rw/Zais+WJttGNnsnIT8JSMq5sQgAAhJ4A= X-AuditID: 0a5f4e69-b7f6d6d000000ac0-a2-501a0be8c1e5 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkk+LIzCtJLcpLzFFi42Lhivcz1H3BLRVg0LWZ1+Lj9TeMDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKON5vWbCnvGLW/2ssDYx387oYOTkkBEwkelbMYoewxSQu3FvP 1sXIxSEksJ1R4se+a8wQzk9GiWlPr7BCOEsZJf6emccC0sIioCrRtWQyK4jNBmQ/av4NNkpY wFPizf2rQDYHB6eAg0TLmQiIDQoSf849BmsVEVCX2Lr6JhPITGaBP4wSi+5uYQNJ8ApYShx7 towdwhaU+DH5HlgDs0CoxKXrR6FscYnm1ptgNiPQ2d9PrWGCGOol8WzCLUaQvSICVhK/blpB 7BWReHjxNBuELSrx8vE/sJOFBEol2k/NZp/AKDYLybZZSLbNQrINwo6VmDF1HzuErSOxYPcn NghbW2LZwtfMMPaZA4+ZIGwziW1rbjJjqrGQ+LT/EyOErStxac0soHpQUGxllPi//AUbTPOt m+uhGhQlpnQ/ZF/AyLeKUaw4qSgzPaMkNzEzJ93ASC8jUy8zL7VkEyMkPWTuYFy+U+UQowAH oxIP74YayQAh1sSy4srcQ4ySHExKorwHOKUChPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwyoPk eFMSK6tSi/JhUjIcHEoSvF+4gFKCRanpqRVpmTnAJAiTZuLgBGnnAWr/BlLDW1yQmFucmQ6R P8UoKSXO+wAkIQCSyCjNg+t9xSgOdKQw70OQLA8wXcN1vQIayAQ0MMRBDGRgSSJCSqqBcf5L +RSJTcqdnzclvVuZv7q1wqT74rvLcivqs39OXHM/WPlmk4q01W5JLe1KlqDKdSI96z3/vb7x u+1D95nOkulzf33T6/nQp/7PQujgv9zap6fmVu/VX76wcpeJ/n/39cu36SvJvy9lN9Yo4whN CkptE8idZ7fYZ8Lu4JmnA50zL/D0PdiVpMRSnJFoqMVcVJwIAOYsnjGUAwAA References: <00da01cd6ebc$a1768ae0$e463a0a0$@augustcellars.com> <004901cd704c$301bb500$90531f00$@augustcellars.com> Cc: "" , "" , Sam Hartman Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 05:11:10 -0000 --Boundary_(ID_73vDg2b1HIET6OSdul8aFw) Content-type: multipart/alternative; boundary="Boundary_(ID_tWQZ3pmc7+MCulXDFwGIMg)" --Boundary_(ID_tWQZ3pmc7+MCulXDFwGIMg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT On 1 Aug 2012, at 18:14 , Jim Schaad wrote: > Sam or Josh, > > After writing the below and trying to get a good night sleep. > >> 6. I think that you might talk about the cases where channel binding COULD >> be required even for network authentication. The fact that it is not > required >> does not mean that it cannot be used. One issue is going to be how an IdP >> identifies a network authentication service from a different service for > the >> purposes of deciding if channel binding is going to be required. > > I seem to remember at one point that there were some discussions about > possibly using abfab for granting of network access of some types of > devices. Do I remember incorrectly or is this still a possible usage that > might need to be considered in the applicability statement. There was a position statement presented by Sam and Margaret at the Smart Object Security workshop before the IETF in Paris. You probably refer to this. I'm attaching the text, that does not explicitly mention network access, but I guess suggests the possibility... Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_tWQZ3pmc7+MCulXDFwGIMg) Content-id: <39870820F7B8DC4AB25C79A604381B6D@hi.inet> Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

On 1 Aug 2012, at 18:14 , Jim Schaad wrote:

> Sam or Josh,
>
> After writing the below and trying to get a good night sleep.
>
>> 6. I think that you might talk about the cases where channel binding COULD
>> be required even for network authentication.  The fact that it is not
> required
>> does not mean that it cannot be used.  One issue is going to be how an IdP
>> identifies a network authentication service from a different service for
> the
>> purposes of deciding if channel binding is going to be required.
>
> I seem to remember at one point that there were some discussions about
> possibly using abfab for granting of network access of some types of
> devices.  Do I remember incorrectly or is this still a possible usage that
> might need to be considered in the applicability statement.


There was a position statement presented by Sam and Margaret at the Smart
Object Security workshop before the IETF in Paris. You probably refer to
this. I'm attaching the text, that does not explicitly mention network
access, but I guess suggests the possibility...

Be goode,



--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego@tid.es
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_tWQZ3pmc7+MCulXDFwGIMg)-- --Boundary_(ID_73vDg2b1HIET6OSdul8aFw) Content-id: Content-type: text/html; name="abfab smart devices.html" Content-transfer-encoding: 7BIT Content-disposition: attachment; filename="abfab smart devices.html"; size=7258; creation-date="Thu, 02 Aug 2012 05:10:55 GMT"; modification-date="Thu, 02 Aug 2012 05:10:55 GMT" Content-description: abfab smart devices.html

Federation, ABFAB and Smart Devices

February 15, 2012

Many smart devices deployments involve multiple organizations that do not directly share security infrastructure. For example, in smart power deployments, devices including appliances and infrastructure such as electric car chargers will wish to connect to an energy management system. The energy management system is provided by a utility company in some deployments. The utility company may wish to grant access only to authorized devices; for example, a consortium of utility companies and device manufacturers may certify devices to connect to power networks.

In another example, consumer devices may be used to access cloud services. For example, a camera could be bound to a photo processing site. Authentication and authorization for uploading pictures or ordering prints is required. Sensors could be used to provide data to services run by organizations other than the sensor manufacturer. Authorization and authentication can become very tricky when sensors have no user interface. Cellular devices may want to access services provided by a third party regardless of whether the cellular network or wi-fi is used. This becomes difficult when authorization and billing is coordinated by the cellular provider.

Introducing ABFAB

The ABFAB working group of the IETF is working to extend authentication and authorization technology that is already very successful at handling network access deployments for application layer access management [draft-ietf-abfab-arch]. The ABFAB technology focuses on federated access management. A set of one or more organizations provide services that are accessed by entities from one or more identity providers.

At a technical level, The Extensible Authentication Protocol (EAP) [RFC 3748] is used to provide authentication between one entity, such as a smart device, and its identity provider. Only two parties are involved in this exchange; this means that the smart device need not participate in any complicated public-key infrastructure even if it is authenticating against many cloud services. Instead, the device can delegate the process of authenticating the service and even deciding whether the device should be permitted to access the service to the identity provider. This has several advantages. A wide variety of revenue sharing models are enabled. Because device authentication is only with a single identity provider, phishing of device credentials can be avoided. Authorization and decisions about what personal information to release are made by the identity provider. The device owner can use a rich interface such as a website to configure authorization and privacy policy even if the device has no user interface. This model works well with pre-provisioning of device credentials.

RADIUS [RFC 2865] provides authentication and authorization between the identity provider and the service. The identity provider can disclose information about the device or device owner as consistent with privacy requirements. The service can disclose information about itself and the intended service. The credentials used between the identity provider and service are independent of the credentials used between the identity provider and device. As new relationships with services are established or as security associations are updated, no changes are required on devices. Services do not learn device-specific security information. If a device is lost and replaced or compromised, services need not be updated. If a service is compromised, devices need not be re-credentialed, although privacy sensitive information held by the service may still be exposed.

ABFAB is designed to make it easy to set up federations or consortia of identity providers and services. Traditionally with RADIUS, a mesh of connected RADIUS proxies are used. This has been very effective in the cellular provider and wireless hotspot deployment space. Proxies can assist in billing management and authorization decisions. Alternatively, RADIUS over TLS [draft-ietf-radext-radsec] can be used. In this model, a public-key infrastructure can be used between the identity and service. The identity provider and service may be in a position to handle revocation and to decide based on the contents of certificates what information should be released to comply with privacy policy.

Ongoing work not currently within ABFAB's scope [draft-mrw-abfab-multihop-fed] proposes to extend the RADSEC model to provide for secure dynamic discovery of identity providers appropriate to a given service along with policy information. In this model, a distributed database of identity providers for a given Community of Interest is built. Intermediate nodes can enforce policy surrounding naming, privacy and other issues. However key exchange is end-to-end using a model similar to how SIP and DTLS are integrated: an integrity protected channel is used to run a key agreement protocol. The integrity protected channel permits intermediates. However, assuming the intermediates are trusted not to mount a man-in-the-middle attack, the key is only known by the identity provider and service.

Today, the ABFAB mechanism [draft-ietf-abfab-gss-eap] can work with most IETF protocols including HTTP and XMPP. In the future, this model could be extended to any additional IETF protocols needed by smart devices that do not support the existing mechanism.

ABFAB provides a rich set of facilities for integrating attributes about authenticated identities into an application. Facilities are also provided to allow infrastructure supporting a service or identity provider to provide and enforce policy.

Authors' Contact Information

Sam Hartman (hartmans@painless-security.com)

Margaret Wasserman (mrw@painless-security.com)

Painless Security, LLC





--Boundary_(ID_73vDg2b1HIET6OSdul8aFw)-- From jimsch@augustcellars.com Thu Aug 2 10:44:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3136E11E81AA for ; Thu, 2 Aug 2012 10:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ5gkcinjaAU for ; Thu, 2 Aug 2012 10:44:02 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id AB7A811E81A6 for ; Thu, 2 Aug 2012 10:44:02 -0700 (PDT) Received: from Tobias (dhcp-10a6.meeting.ietf.org [130.129.16.166]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 50A5438F0D; Thu, 2 Aug 2012 10:44:02 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 2 Aug 2012 10:42:36 -0700 Message-ID: <008f01cd70d6$35b21d30$a1165790$@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: Ac1wTmT5aOg4o6bCS1ij/wEnSCqLPw== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Comments on draft-smith-abfab-usability-ui-considerations-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:44:03 -0000 This is a set of first impressions and should not be construed as an actual review of the document. 1. Section 4 s/for a user to user a different/for a user to use a different/ Issues: 1. application specific choice of identities 2. separation of ABFAB identities from other GSS-API credentials 3. Ordering of identity choice for least privilege principles 4. Identification of non password based credentials - where does the secret come from? Credential may or may not be usable based on the state of a plug in token as an example. From hartmans@painless-security.com Mon Aug 6 15:06:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F0611E80F5 for ; Mon, 6 Aug 2012 15:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.042 X-Spam-Level: * X-Spam-Status: No, score=1.042 tagged_above=-999 required=5 tests=[AWL=-3.247, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3e7EB8NGfljW for ; Mon, 6 Aug 2012 15:06:40 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-76-251.compute-1.amazonaws.com [23.21.76.251]) by ietfa.amsl.com (Postfix) with ESMTP id 80F3411E80F4 for ; Mon, 6 Aug 2012 15:06:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E45112002D; Mon, 6 Aug 2012 18:05:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 66DBB420E; Mon, 6 Aug 2012 18:06:36 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <00da01cd6ebc$a1768ae0$e463a0a0$@augustcellars.com> <004901cd704c$301bb500$90531f00$@augustcellars.com> <5019DBFD.8000208@sunet.se> Date: Mon, 06 Aug 2012 18:06:36 -0400 In-Reply-To: <5019DBFD.8000208@sunet.se> (Leif Johansson's message of "Thu, 02 Aug 2012 03:46:37 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 22:06:41 -0000 My personal preference is to keep network access discussions out of scope here. I think the IDP can detect gss-eap based on the RADIUS AVPs such as acceptor-hostname and acceptor-realm that are sent by GSS-EAP. If another ABFAB application integration layer is used, then it may get more complex. My personal belief is that level of detail is not needed for the applicability statement. From leifj@sunet.se Mon Aug 6 15:17:44 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D1521F84F8 for ; Mon, 6 Aug 2012 15:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1NVGRd51E8Q for ; Mon, 6 Aug 2012 15:17:43 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 837A221F84F5 for ; Mon, 6 Aug 2012 15:17:43 -0700 (PDT) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q76MHW5P017441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Aug 2012 00:17:39 +0200 (CEST) Message-ID: <5020427A.7090804@sunet.se> Date: Tue, 07 Aug 2012 00:17:30 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Sam Hartman References: <00da01cd6ebc$a1768ae0$e463a0a0$@augustcellars.com> <004901cd704c$301bb500$90531f00$@augustcellars.com> <5019DBFD.8000208@sunet.se> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 22:17:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/07/2012 12:06 AM, Sam Hartman wrote: > My personal preference is to keep network access discussions out > of scope here. > > I think the IDP can detect gss-eap based on the RADIUS AVPs such > as acceptor-hostname and acceptor-realm that are sent by GSS-EAP. > > If another ABFAB application integration layer is used, then it may > get more complex. > Nothing stops us from updating the applicability stmt at that time. > My personal belief is that level of detail is not needed for the > applicability statement. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAgQnMACgkQ8Jx8FtbMZnfn9ACbBQCByYRwvfEAeqgEZIpQBDtd 9KAAmwRZc1YfXqAYemvJ3qMwhQhMR1Vm =yXjt -----END PGP SIGNATURE----- From Josh.Howlett@ja.net Tue Aug 7 01:21:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9121221F8510 for ; Tue, 7 Aug 2012 01:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.227 X-Spam-Level: X-Spam-Status: No, score=-102.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGZ9Y7Fvg8er for ; Tue, 7 Aug 2012 01:21:53 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 96C3721F850D for ; Tue, 7 Aug 2012 01:21:53 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 6FD2820C72EF_20D01FB; Tue, 7 Aug 2012 08:21:51 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 4892B20C711F_20D01FF; Tue, 7 Aug 2012 08:21:51 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 7 Aug 2012 09:21:51 +0100 From: Josh Howlett To: Sam Hartman , Leif Johansson Thread-Topic: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt Thread-Index: AQHNdB/Mx9oGG2V96E6pbV/t392dzZdN9DuA Date: Tue, 7 Aug 2012 08:21:50 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 08:21:56 -0000 +1 On 06/08/2012 23:06, "Sam Hartman" wrote: >My personal preference is to keep network access discussions out of >scope here. > >I think the IDP can detect gss-eap based on the RADIUS AVPs such as >acceptor-hostname and acceptor-realm that are sent by GSS-EAP. > >If another ABFAB application integration layer is used, then it may get >more complex. > >My personal belief is that level of detail is not needed for the >applicability statement. >_______________________________________________ >abfab mailing list >abfab@ietf.org >https://www.ietf.org/mailman/listinfo/abfab Janet 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 stephen.farrell@cs.tcd.ie Wed Aug 8 09:23:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7303221F871A for ; Wed, 8 Aug 2012 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDrsQfGtFBJk for ; Wed, 8 Aug 2012 09:23:38 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 5E76121F8717 for ; Wed, 8 Aug 2012 09:23:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C26F71714F2 for ; Wed, 8 Aug 2012 17:23:37 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1344443017; bh=EYDnbtY5xpNrUF Q0Qn2bwoNmBbIIO5eybmxlLtUoJmY=; b=sBmp69hqNDL4+ljqltvtDuNnZF+ddJ xchBBNT1WCrKgX4sq0LYKl0XK6DrIfUikmrtoDqKJM8/+twKe/sZ9cg9PrT3bpPw 1uS1OCn4kLhaRDZD+aZg/JnT9gRYVVOU+s4LvFB0kTWOn6XN1Km8Cp4/vn6IVIAf 6Q/qdhttCfKAi1sFxecaHggmqshM/CtdCdldT+WADr9UNfDKrADAbo7ZmpumpEPJ pktC6B6dx8TGwF0klPQYacQrgkP0oz7+LWrlqRMGiIwRa7VpapRNhzvAIX1ei6NR MP74fy7oUa53W1qgzg0occil9Ev6eXD0vyC7z3PcHjUo0Rh1ODrxI+UQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id zdovBk-kVu3u for ; Wed, 8 Aug 2012 17:23:37 +0100 (IST) Received: from [IPv6:2001:770:10:203:49b3:3973:5610:abc4] (unknown [IPv6:2001:770:10:203:49b3:3973:5610:abc4]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 35D34158177 for ; Wed, 8 Aug 2012 17:23:37 +0100 (IST) Message-ID: <50229289.6020103@cs.tcd.ie> Date: Wed, 08 Aug 2012 17:23:37 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "" References: In-Reply-To: X-Enigmail-Version: 1.4.3 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Fwd: Secdir review of draft-ietf-abfab-usecases-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:23:39 -0000 Just posting to abfab list for visibility there. S. -------- Original Message -------- Subject: Secdir review of draft-ietf-abfab-usecases-03 Date: Mon, 6 Aug 2012 18:23:27 -0700 From: Brian Weis To: secdir@ietf.org, The IESG CC: draft-ietf-abfab-usecases.all@tools.ietf.org I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes several scenarios in which federated access could be useful to non-web protocols. The use cases include federation between supplier/consumers of resources (e.g., cloud services, high performance computing, and grid), the sharing of content or resources between an organization and selected outsiders (e.g., databases and directories, and printing), and cooperation between multiple organizations (e.g., smart objects). Each use case discusses the movement from non-federated identity to the use of an ABFAB architecture. The security considerations section states that necessary security considerations will be documented as part of subsequent protocol specifications. But typically there are higher level security considerations to use cases unrelated to the details of protocols. In this case there are likely effects of federation on the various actors within the case entities. I note above that there are several classes of use cases, each of which has a different trust model and set of actors either providing or validating credentials. If converting to the ABFAB architecture in any of the use cases results in a change of security considerations (positive or negative) from the pre-existing non-federated case then it would be helpful to note this to readers considering adopting one of the ABFAB use cases. For example, when in federation between supplier/consumers of resources are there changes in the trust model when a supplier re-designs/re-factors their environment to use federation? Are there security considerations for a consumer moving to federated identities from directly supplying IDs/authentication material to previously non-federated services? This sort of characterization would be valuable in understanding the effects of transitioning to federation. I'm not suggesting a full blown threat analysis (although that would be useful!) but rather a summary of how federation affects the security of both a provider and consumer of a resource in the various use cases. Brian From stephen.farrell@cs.tcd.ie Wed Aug 8 09:32:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DE721F875A for ; Wed, 8 Aug 2012 09:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mH-N1DkxPSv for ; Wed, 8 Aug 2012 09:32:21 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D847821F8690 for ; Wed, 8 Aug 2012 09:32:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E07C0171508 for ; Wed, 8 Aug 2012 17:32:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1344443537; bh=97jHCbZ+Xb3N89AF/SJAPhYC OQZXisPlAfATQPJobaE=; b=GPCW4d251B/sRrV/k9HGUZMmBLBaHAeiY4Yd+XIP 7GZAB/7LarqhOymFlamCWg57dGG8tF0n/5U5SKEwzkSQtoiNZOIOzccZe99VxQdC RZtlf29/lHM1BAFapk7rvymRT9HEe48Cvz4nrVvA09cszWTyE1ynnKoShZBw04Kd GrbGgDZ2qneB5YR9vzrz2YKzhgTNKY5wcV4L16jA2uO/2ASVOlRVXU1SY5CSvlt9 8tAzzHZMkqq68uhAknjv6duqjV737bvVP4lA7kic3B0oPzGuSv5OKfGsJRfcUtOb jJh2qo/upuuQqgUR5X0PCHcfUD1CTkuTxDZMABM6F/wkFQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 9nSu+XQa1Eyu for ; Wed, 8 Aug 2012 17:32:17 +0100 (IST) Received: from [IPv6:2001:770:10:203:49b3:3973:5610:abc4] (unknown [IPv6:2001:770:10:203:49b3:3973:5610:abc4]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 888A41714F2 for ; Wed, 8 Aug 2012 17:32:17 +0100 (IST) Message-ID: <50229491.3010109@cs.tcd.ie> Date: Wed, 08 Aug 2012 17:32:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "" X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] usecases is done IETF LC X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:32:22 -0000 So I only saw my comments and the secdir review. Is that right? I think there are at minimum some I-D nits to fix and maybe a few nitty comments of mine worth taking into account. As I said before you can take or leave my comments about wishful thinking, though it might be better to bolster the weaker parts if possible. Can someone also respond to the secdir review? I'm not sure if changes will result or not but he does make a reasonable point that deserves an answer. If that seems ok I'll mark this as revised ID needed and then once we have that done I can put it on a telechat agenda. (Next likely date for that is Aug 30 so if the revision is done by Aug 23 there'll be no added delay.) If that's not ok, please argue with me now:-) Ta, S. From hartmans@painless-security.com Wed Aug 8 10:57:30 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B689711E80F3 for ; Wed, 8 Aug 2012 10:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.969 X-Spam-Level: * X-Spam-Status: No, score=1.969 tagged_above=-999 required=5 tests=[AWL=-2.319, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oBTsweD8tbC for ; Wed, 8 Aug 2012 10:57:30 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 31F2121F86D3 for ; Wed, 8 Aug 2012 10:57:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 05F9F2014C; Wed, 8 Aug 2012 13:48:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A4EB2420E; Wed, 8 Aug 2012 13:48:40 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <50229289.6020103@cs.tcd.ie> Date: Wed, 08 Aug 2012 13:48:40 -0400 In-Reply-To: <50229289.6020103@cs.tcd.ie> (Stephen Farrell's message of "Wed, 08 Aug 2012 17:23:37 +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: "" Subject: Re: [abfab] Fwd: Secdir review of draft-ietf-abfab-usecases-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 17:57:30 -0000 I wonder whether addressing the higher-level security issues in abfab-arch makes more sense. It seems like the consideractions are architecture not use-case specific. From ietf@augustcellars.com Wed Aug 8 18:49:45 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15DD11E8150 for ; Wed, 8 Aug 2012 18:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.492 X-Spam-Level: X-Spam-Status: No, score=-3.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx8MrpE-guAT for ; Wed, 8 Aug 2012 18:49:45 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 62BB211E80A5 for ; Wed, 8 Aug 2012 18:49:45 -0700 (PDT) Received: from Tobias (50-39-234-129.bvtn.or.frontiernet.net [50.39.234.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 53F8D2CA48; Wed, 8 Aug 2012 18:49:42 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Stephen Farrell'" References: <50229289.6020103@cs.tcd.ie> In-Reply-To: Date: Wed, 8 Aug 2012 18:48:10 -0700 Message-ID: <006801cd75d1$0dfc8500$29f58f00$@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: AQJoNA3Y8LuoH2bty1iQa4yQPJOTGwEya3s3AdxoL2iWAsMwkA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Fwd: Secdir review of draft-ietf-abfab-usecases-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 01:49:45 -0000 That would make sense to me. And I am already trying to get as many of the overall items as possible into that document. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, August 08, 2012 10:49 AM > To: Stephen Farrell > Cc: > Subject: Re: [abfab] Fwd: Secdir review of draft-ietf-abfab-usecases-03 > > I wonder whether addressing the higher-level security issues in abfab-arch > makes more sense. > It seems like the consideractions are architecture not use-case specific. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From smith@Cardiff.ac.uk Fri Aug 10 07:04:32 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E3421F861F for ; Fri, 10 Aug 2012 07:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzdh5U1DsmnK for ; Fri, 10 Aug 2012 07:04:32 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id E1DED21F861C for ; Fri, 10 Aug 2012 07:04:31 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1SzppG-00041i-G7 for abfab@ietf.org; Fri, 10 Aug 2012 15:04:30 +0100 Received: from [131.251.148.37] (helo=dangermouse.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SzppG-0001x2-FO for abfab@ietf.org; Fri, 10 Aug 2012 15:04:30 +0100 From: Rhys Smith Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Aug 2012 15:04:30 +0100 Message-Id: To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] Tools being weird X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:04:32 -0000 Is it just me or does = http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-09 contain some = entirely unrelated I-D=85? R. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's education and research network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C From aland@deployingradius.com Fri Aug 10 07:27:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF9021F8671 for ; Fri, 10 Aug 2012 07:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBnHm30cEqQ8 for ; Fri, 10 Aug 2012 07:27:14 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 984AF21F866D for ; Fri, 10 Aug 2012 07:27:14 -0700 (PDT) Message-ID: <50251A26.9030804@deployingradius.com> Date: Fri, 10 Aug 2012 16:26:46 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Rhys Smith References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Tools being weird X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:27:15 -0000 Rhys Smith wrote: > Is it just me or does http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-09 contain some entirely unrelated I-D…? Yes. It's been that way for a while. From mrw@lilacglade.org Fri Aug 10 07:33:07 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBFC21F85C4 for ; Fri, 10 Aug 2012 07:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.68 X-Spam-Level: X-Spam-Status: No, score=-95.68 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gpuc7tV8zObi for ; Fri, 10 Aug 2012 07:33:07 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 12E8221F85F0 for ; Fri, 10 Aug 2012 07:33:06 -0700 (PDT) Received: from lilac-too.home (permutation-city.suchdamage.org [69.25.196.28]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mail.suchdamage.org (Postfix) with ESMTPSA id E0CDA201B6; Fri, 10 Aug 2012 10:33:04 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Margaret Wasserman In-Reply-To: <50251A26.9030804@deployingradius.com> Date: Fri, 10 Aug 2012 10:33:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50251A26.9030804@deployingradius.com> To: Alan DeKok X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org Subject: Re: [abfab] Tools being weird X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:33:07 -0000 Write to "tools@ietf.org" and tell them about the problem. They usually = fix things quickly once they are aware of them. Margaret On Aug 10, 2012, at 10:26 AM, Alan DeKok wrote: > Rhys Smith wrote: >> Is it just me or does = http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-09 contain some = entirely unrelated I-D=85? >=20 > Yes. It's been that way for a while. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From smith@Cardiff.ac.uk Fri Aug 10 07:42:59 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B986921F8691 for ; Fri, 10 Aug 2012 07:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGbS7Y5vp-BU for ; Fri, 10 Aug 2012 07:42:58 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 2D64A21F85FF for ; Fri, 10 Aug 2012 07:42:58 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1SzqQR-0005Nz-7S; Fri, 10 Aug 2012 15:42:55 +0100 Received: from [131.251.148.37] (helo=dangermouse.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SzqQR-0002V0-6Z; Fri, 10 Aug 2012 15:42:55 +0100 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Rhys Smith In-Reply-To: Date: Fri, 10 Aug 2012 15:42:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50251A26.9030804@deployingradius.com> To: Margaret Wasserman X-Mailer: Apple Mail (2.1278) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: Re: [abfab] Tools being weird X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:42:59 -0000 Will do, thanks Margaret. I was scanning through the document (didn't = read the title first) and wondering when we started having to introduce = status codes for the DSL line quality... -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's education and research network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C On 10 Aug 2012, at 15:33, Margaret Wasserman wrote: >=20 > Write to "tools@ietf.org" and tell them about the problem. They = usually fix things quickly once they are aware of them. >=20 > Margaret >=20 > On Aug 10, 2012, at 10:26 AM, Alan DeKok wrote: >=20 >> Rhys Smith wrote: >>> Is it just me or does = http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-09 contain some = entirely unrelated I-D=85? >>=20 >> Yes. It's been that way for a while. >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 From hartmans@painless-security.com Fri Aug 10 09:37:42 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B8021F874A for ; Fri, 10 Aug 2012 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.229 X-Spam-Level: *** X-Spam-Status: No, score=3.229 tagged_above=-999 required=5 tests=[AWL=-2.548, BAYES_05=-1.11, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYf5umYAonIo for ; Fri, 10 Aug 2012 09:37:39 -0700 (PDT) Received: from ec2-23-21-76-251.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 603F221F86FA for ; Fri, 10 Aug 2012 09:37:39 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DFDD8201B6 for ; Fri, 10 Aug 2012 12:37:37 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0BA50420F; Fri, 10 Aug 2012 12:37:33 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Fri, 10 Aug 2012 12:37:33 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] escaping and draft-ietf-abfab-gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:37:42 -0000 Presumably the backslash escaping is only for importing, exporting and displaying names. In particular, you'd expect the escaps to be removed in things like RADIUS AVPs. That is, if the acceptor-username AVP was foo\/ bar that would mean someone imported foo\\\/bar not foo\/bar importing foo\/bar would look like foo/bar over RADIUS? That's our intent right? From internet-drafts@ietf.org Mon Aug 13 09:07:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD03921F86E4; Mon, 13 Aug 2012 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-dq221duiCT; Mon, 13 Aug 2012 09:07:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EC621F8722; Mon, 13 Aug 2012 09:07:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120813160728.14252.98952.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2012 09:07:28 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 16:07:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : A GSS-API Mechanism for the Extensible Authentication Pr= otocol Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-09.txt Pages : 41 Date : 2012-08-13 Abstract: This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the Extensible Authentication Protocol mechanism. Through the GS2 family of mechanisms defined in RFC 5801, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-gss-eap-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hartmans@painless-security.com Mon Aug 13 09:15:45 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E699C21F8527 for ; Mon, 13 Aug 2012 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.788 X-Spam-Level: * X-Spam-Status: No, score=1.788 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeOACjCkgpBn for ; Mon, 13 Aug 2012 09:15:45 -0700 (PDT) Received: from mail.suchdamage.org (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5A021F850B for ; Mon, 13 Aug 2012 09:15:45 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 50BB7205FD for ; Mon, 13 Aug 2012 12:15:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5306F4350; Mon, 13 Aug 2012 12:15:42 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org References: <20120813160728.14252.98952.idtracker@ietfa.amsl.com> Date: Mon, 13 Aug 2012 12:15:42 -0400 In-Reply-To: <20120813160728.14252.98952.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon, 13 Aug 2012 09:07:28 -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 Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 16:15:46 -0000 Hi. I think we have consensus on all the changes in this version, but I'd really appreciate it if one or two people would read the diff between 08 and 09 and confirm that I didn't introduce any problems. I think it's all good but there were a lot of post-approval comments to resolve. --Sam From ietf@augustcellars.com Mon Aug 13 17:43:26 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83EB21F865B for ; Mon, 13 Aug 2012 17:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytLmgF++SQyO for ; Mon, 13 Aug 2012 17:43:26 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 86EBC21F8653 for ; Mon, 13 Aug 2012 17:43:26 -0700 (PDT) Received: from Tobias (mc70f36d0.tmodns.net [208.54.15.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 369AD38F06; Mon, 13 Aug 2012 17:43:26 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , References: <20120813160728.14252.98952.idtracker@ietfa.amsl.com> In-Reply-To: Date: Mon, 13 Aug 2012 17:42:01 -0700 Message-ID: <008d01cd79b5$9edc6da0$dc9548e0$@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: AQGVS33EAPS4kwzdfOmPloqnxSHjbwGAyuKHl7zNzxA= Content-Language: en-us Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 00:43:27 -0000 I will be doing a full read over the next couple of days, but I did not see anything that jumped out to me as a problem with the diff. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Monday, August 13, 2012 9:16 AM > To: abfab@ietf.org > Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt > > > > Hi. I think we have consensus on all the changes in this version, but I'd really > appreciate it if one or two people would read the diff between 08 and 09 and > confirm that I didn't introduce any problems. I think it's all good but there > were a lot of post-approval comments to resolve. > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From klaas@cisco.com Tue Aug 14 01:38:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077A821F859A for ; Tue, 14 Aug 2012 01:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIFS9QX597QH for ; Tue, 14 Aug 2012 01:38:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1704E21F8512 for ; Tue, 14 Aug 2012 01:38:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1360; q=dns/txt; s=iport; t=1344933532; x=1346143132; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fku+dslaCzl0l8iQeTQsonytsCS/34t5i0UMAXoi2yA=; b=JRXnYnU2p8hveAKlyo9fxvBKDUItXYMafAu3s38DONA+odddIuH8GRbW D4u/CgFHk7R9CBAY/o01e4gTx8jwfqpTOkk22KFZV16RdsV3XO/lzNPM/ jBYrqoGi7bN280fEo7W8Raf8I4OSg1BUjingZdMcvrQcZaB1LDF40ypEI Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAM0NKlCtJXG+/2dsb2JhbABEug6BB4IgAQEBAwEBAQEPASc0CwUHBAsOAwQBASgHJx8JCAYTIodlBguYGqEFBIsFhVFgA5VLjiqBZoJh X-IronPort-AV: E=Sophos;i="4.77,765,1336348800"; d="scan'208";a="111326896" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 14 Aug 2012 08:38:51 +0000 Received: from rtp-kwiereng-8712.cisco.com (rtp-kwiereng-8712.cisco.com [10.116.7.35]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7E8cnK2000635; Tue, 14 Aug 2012 08:38:50 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Klaas Wierenga In-Reply-To: <008d01cd79b5$9edc6da0$dc9548e0$@augustcellars.com> Date: Tue, 14 Aug 2012 10:38:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A9D6E25-7437-499B-8309-04CFDCD56483@cisco.com> References: <20120813160728.14252.98952.idtracker@ietfa.amsl.com> <008d01cd79b5$9edc6da0$dc9548e0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1485) Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 08:38:53 -0000 On Aug 14, 2012, at 2:42 AM, Jim Schaad wrote: Jim, > I will be doing a full read over the next couple of days, but I did = not see > anything that jumped out to me as a problem with the diff. That is great. I'll do the writeup and wait for your "no objection" = before submitting it. I'll go on holiday on Saturday, so it'll have to = be on Friday at the latest. Thanks, Klaas >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On = Behalf >> Of Sam Hartman >> Sent: Monday, August 13, 2012 9:16 AM >> To: abfab@ietf.org >> Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt >>=20 >>=20 >>=20 >> Hi. I think we have consensus on all the changes in this version, but = I'd > really >> appreciate it if one or two people would read the diff between 08 and = 09 > and >> confirm that I didn't introduce any problems. I think it's all good = but > there >> were a lot of post-approval comments to resolve. >>=20 >> --Sam >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From klaas@cisco.com Tue Aug 14 04:35:51 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF9A21F84F7 for ; Tue, 14 Aug 2012 04:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tApfGufNRY+e for ; Tue, 14 Aug 2012 04:35:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9119421F84D8 for ; Tue, 14 Aug 2012 04:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1725; q=dns/txt; s=iport; t=1344944139; x=1346153739; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1+1NxdnBFry0w6prV4mPUPff3tlqIXYuezYq4cVBWlg=; b=gFiBNpV0Xdaa4yPVKqU55j07Y08tZR77MeVwqQ2nTKqTMZb9klPxR/dA aMcanDIfExYBq2O8Pl2YLhd+d+kAi1kwFFREXlolAp4E9JNFry8NmM2Jn T2nP2/MyTyKebgLQDYif+ZplNnn+x6C/+dkWQKALN3g1xOat7VfqsCWoH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANk2KlCtJV2a/2dsb2JhbABEuhCBB4IgAQEBAwEBAQEPASc0CwwECw4DBAEBAScHJx8JCAYTIodlBguYHaEKBIsFhVFgA5VLjiqBZoJh X-IronPort-AV: E=Sophos;i="4.77,766,1336348800"; d="scan'208";a="111411190" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 14 Aug 2012 11:35:39 +0000 Received: from rtp-vpn6-527.cisco.com (rtp-vpn6-527.cisco.com [10.82.250.17]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7EBZagn012996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Aug 2012 11:35:38 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Klaas Wierenga In-Reply-To: <2A9D6E25-7437-499B-8309-04CFDCD56483@cisco.com> Date: Tue, 14 Aug 2012 13:31:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <69E7E2DF-871C-41A9-AACB-98C42D8A7D61@cisco.com> References: <20120813160728.14252.98952.idtracker@ietfa.amsl.com> <008d01cd79b5$9edc6da0$dc9548e0$@augustcellars.com> <2A9D6E25-7437-499B-8309-04CFDCD56483@cisco.com> To: Jim Schaad X-Mailer: Apple Mail (2.1485) Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 11:35:51 -0000 On Aug 14, 2012, at 10:38 AM, Klaas Wierenga wrote: >=20 > On Aug 14, 2012, at 2:42 AM, Jim Schaad = wrote: >=20 > Jim, >=20 >> I will be doing a full read over the next couple of days, but I did = not see >> anything that jumped out to me as a problem with the diff. >=20 > That is great. I'll do the writeup and wait for your "no objection" = before submitting it. I'll go on holiday on Saturday, so it'll have to = be on Friday at the latest. ooops, please ignore, I was mixing eap and eap-naming Klaas >=20 > Thanks, >=20 > Klaas >=20 >=20 >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On = Behalf >>> Of Sam Hartman >>> Sent: Monday, August 13, 2012 9:16 AM >>> To: abfab@ietf.org >>> Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt >>>=20 >>>=20 >>>=20 >>> Hi. I think we have consensus on all the changes in this version, = but I'd >> really >>> appreciate it if one or two people would read the diff between 08 = and 09 >> and >>> confirm that I didn't introduce any problems. I think it's all good = but >> there >>> were a lot of post-approval comments to resolve. >>>=20 >>> --Sam >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From klaas@cisco.com Tue Aug 14 04:35:51 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757A521F84D8 for ; Tue, 14 Aug 2012 04:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjgqWNv6lKKD for ; Tue, 14 Aug 2012 04:35:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3A75221F8512 for ; Tue, 14 Aug 2012 04:35:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1725; q=dns/txt; s=iport; t=1344944151; x=1346153751; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=1+1NxdnBFry0w6prV4mPUPff3tlqIXYuezYq4cVBWlg=; b=Ahbtkg2r1MtQidQzAHiRNT1ysu/W+rGgIoMJ3ogyYrz1GTXBHBwO/vh9 mhoouZHdqqkvPiuMJnLDj6nQI945TvhKsr471SH5QYwlSodJaQFdS14w6 tYa7bV11VptymGKB9FGh47trNBNxDNNQI7O5vKUzPji5X8SjAZ/3KdVPB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANk2KlCtJV2a/2dsb2JhbABEuhCBB4IgAQEBAwEBAQEPASc0CwwECw4DBAEBAScHJx8JCAYTIodlBguYHaEKBIsFhVFgA5VLjiqBZoJh X-IronPort-AV: E=Sophos;i="4.77,765,1336348800"; d="scan'208";a="108392541" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 14 Aug 2012 11:35:47 +0000 Received: from rtp-vpn6-527.cisco.com (rtp-vpn6-527.cisco.com [10.82.250.17]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7EBZagp012996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Aug 2012 11:35:46 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1485\)) From: Klaas Wierenga In-Reply-To: <2A9D6E25-7437-499B-8309-04CFDCD56483@cisco.com> Date: Tue, 14 Aug 2012 13:35:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <32E726F4-5740-45BF-8E6C-D464B293B229@cisco.com> References: <20120813160728.14252.98952.idtracker@ietfa.amsl.com> <008d01cd79b5$9edc6da0$dc9548e0$@augustcellars.com> <2A9D6E25-7437-499B-8309-04CFDCD56483@cisco.com> To: Jim Schaad X-Mailer: Apple Mail (2.1485) Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 11:35:51 -0000 On Aug 14, 2012, at 10:38 AM, Klaas Wierenga wrote: >=20 > On Aug 14, 2012, at 2:42 AM, Jim Schaad = wrote: >=20 > Jim, >=20 >> I will be doing a full read over the next couple of days, but I did = not see >> anything that jumped out to me as a problem with the diff. >=20 > That is great. I'll do the writeup and wait for your "no objection" = before submitting it. I'll go on holiday on Saturday, so it'll have to = be on Friday at the latest. ooops, please ignore, I was mixing eap and eap-naming Klaas >=20 > Thanks, >=20 > Klaas >=20 >=20 >>=20 >> Jim >>=20 >>=20 >>> -----Original Message----- >>> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On = Behalf >>> Of Sam Hartman >>> Sent: Monday, August 13, 2012 9:16 AM >>> To: abfab@ietf.org >>> Subject: Re: [abfab] I-D Action: draft-ietf-abfab-gss-eap-09.txt >>>=20 >>>=20 >>>=20 >>> Hi. I think we have consensus on all the changes in this version, = but I'd >> really >>> appreciate it if one or two people would read the diff between 08 = and 09 >> and >>> confirm that I didn't introduce any problems. I think it's all good = but >> there >>> were a lot of post-approval comments to resolve. >>>=20 >>> --Sam >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Tue Aug 14 09:05:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B637E21F84C9 for ; Tue, 14 Aug 2012 09:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.038 X-Spam-Level: *** X-Spam-Status: No, score=3.038 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avUv626im6jV for ; Tue, 14 Aug 2012 09:05:53 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3544421F8497 for ; Tue, 14 Aug 2012 09:05:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7C1C92067F; Tue, 14 Aug 2012 11:47:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1693A4350; Tue, 14 Aug 2012 11:47:14 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <011101cd616e$0400a3a0$0c01eae0$@augustcellars.com> Date: Tue, 14 Aug 2012 11:47:14 -0400 In-Reply-To: <011101cd616e$0400a3a0$0c01eae0$@augustcellars.com> (Jim Schaad's message of "Fri, 13 Jul 2012 20:08:59 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming believed ready for last call X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:05:53 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> 1. Just because I keep having to go and read the SAML document Jim> every time, it might be useful to provide an example in Jim> paragraph 1 of section 3 about what makes a first part and a Jim> second part. I would pass the document without this, it is Jim> just a suggestion. I'd love to include an example here. I'll try to update code prior to IETF LC ending. Jim> 3. In section 5, I thought we had agreed that there should be Jim> a statement that "The values, prior to receiving the Jim> access-accept message, are undefined." I thought the first paragraph was adequate, but expanded it somewhat. Let me know how we're doing now. Jim> 4. Section 6.1 - I think this is correct. s/is always Jim> authentic when present/is always authenticated when present/ If Jim> I am wrong (which is possible) then I am not sure what the word Jim> authentic is supposed to be. I don't think it currently makes Jim> sense. The argument against the above is the following on Jim> sentence which states that a new GSS-API mechanism may allow it Jim> to be unauthenticated. Added hopeful clarity to this paragraph. Jim> 5. Section 6.1 - unclear if this is useful information or not. Jim> Might want to say that for GSS-API-EAP, it is the same as Jim> "urn:ietf:gss:radius-attribute TBD". I don't want to trod on draft-ietf-abfab-aaa-saml's toes. Jim> 6. Section 5 - the above note just nudged a new one. Does Jim> there need to be a DIME attribute as the number space can be Jim> larger. Perhaps just a comment to the effect that some DIME Jim> space may not be reachable? If we want diameter support there does need to be an attribute. We can define that in the diameter document if that ever happens. Jim> 7. Section 6.2 -- Possible comment to be added. "If the Jim> implementation does discard it, then processing the entire SAML Jim> statement will result in a different answer than processing the Jim> individual attributes." This might just be a security Jim> considerations comment. OK. From internet-drafts@ietf.org Tue Aug 14 09:07:49 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246B721F86B7; Tue, 14 Aug 2012 09:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4dGp-t-NRIJ; Tue, 14 Aug 2012 09:07:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A942B21F84CE; Tue, 14 Aug 2012 09:07:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120814160748.19570.38056.idtracker@ietfa.amsl.com> Date: Tue, 14 Aug 2012 09:07:48 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-04.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Aug 2012 16:07:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Name Attributes for the GSS-API EAP mechanism Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-naming-04.txt Pages : 15 Date : 2012-08-14 Abstract: The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-gss-eap-naming-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Wed Aug 15 05:38:26 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A8521F87FD for ; Wed, 15 Aug 2012 05:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.608 X-Spam-Level: X-Spam-Status: No, score=-102.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHa9J+kI0kk2 for ; Wed, 15 Aug 2012 05:38:26 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id CBDF621F87FC for ; Wed, 15 Aug 2012 05:38:24 -0700 (PDT) Received: (qmail invoked by alias); 15 Aug 2012 12:38:23 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp024) with SMTP; 15 Aug 2012 14:38:23 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19oxNQqahBoMCXGy6fzSL1qw+ZqjdkpG3xyRUTFCP sEE3hWjd5Oncai From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Aug 2012 15:38:23 +0300 Message-Id: To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [abfab] Use Cases Document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 12:38:26 -0000 Hi all,=20 during the IETF ABFAB WG session I went to the microphone to comment on = Stephen's AD review of the use case document. In his review he argued = that some use cases are rather wishful thinking than something that the = participants in the group are targeting in their deployment.=20 I had promised to look at the draft to figure out whether it makes sense = to "mark" them in a special way.=20 I went through the document and I have to say that it is hard to judge = the use cases regarding their future deployment likelihood.=20 ABFAB would certainly work technically; there is no doubt about that. = There are, however, so many other factors that may impact the future of = these applications (not only the design of the authentication and = authorization infrastructure). The discussion about 'everything over = HTTP' and the trend towards Web-based application design relates to this = aspect as well.=20 In a nutshell, I would leave the draft as is.=20 Ciao Hannes= From smith@Cardiff.ac.uk Wed Aug 15 06:59:48 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C82F21F8885 for ; Wed, 15 Aug 2012 06:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy97PKL6MqdX for ; Wed, 15 Aug 2012 06:59:47 -0700 (PDT) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8064521F8839 for ; Wed, 15 Aug 2012 06:59:46 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1T1e8L-0000Gi-GR; Wed, 15 Aug 2012 14:59:41 +0100 Received: from [131.251.148.37] (helo=dangermouse.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1T1e8L-0004kc-FO; Wed, 15 Aug 2012 14:59:41 +0100 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Rhys Smith In-Reply-To: <006801cd75d1$0dfc8500$29f58f00$@augustcellars.com> Date: Wed, 15 Aug 2012 14:59:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50229289.6020103@cs.tcd.ie> <006801cd75d1$0dfc8500$29f58f00$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: Re: [abfab] Secdir review of draft-ietf-abfab-usecases-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 13:59:48 -0000 Thanks for the comments and suggestion. I think I agree with Sam and Jim = that this should absolutely be addressed, but is probably better = addressed in the arch document, as these are security considerations = about using abfab architecture generally. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's education and research network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C On 9 Aug 2012, at 02:48, Jim Schaad wrote: > That would make sense to me. And I am already trying to get as many = of the > overall items as possible into that document. >=20 > Jim >=20 >=20 >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On = Behalf >> Of Sam Hartman >> Sent: Wednesday, August 08, 2012 10:49 AM >> To: Stephen Farrell >> Cc: >> Subject: Re: [abfab] Fwd: Secdir review of = draft-ietf-abfab-usecases-03 >>=20 >> I wonder whether addressing the higher-level security issues in = abfab-arch >> makes more sense. >> It seems like the consideractions are architecture not use-case = specific. >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From smith@Cardiff.ac.uk Wed Aug 15 07:54:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65B421F8831 for ; Wed, 15 Aug 2012 07:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4yfbi5a4GGt for ; Wed, 15 Aug 2012 07:54:41 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C021F85AF for ; Wed, 15 Aug 2012 07:54:40 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1T1ezX-000085-7p; Wed, 15 Aug 2012 15:54:39 +0100 Received: from [131.251.148.37] (helo=dangermouse.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1T1ezX-0005hg-6z; Wed, 15 Aug 2012 15:54:39 +0100 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Rhys Smith In-Reply-To: <500993C0.7040806@cs.tcd.ie> Date: Wed, 15 Aug 2012 15:54:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <500993C0.7040806@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1278) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: abfab@ietf.org Subject: Re: [abfab] AD review of draft-ietf-abfab-use-cases X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 14:54:41 -0000 Comments inline: >=20 > 1. In general there are a number of times where this document > seems to be wishful thinking. I think it'd be better if you > reduced it to the more concrete use-cases where implementation is > actually planned and where you can be more authoritative about > how abfab will be beneficial. Sections 3.5 and 3.9 in particular > seem weak to me and the document might be better if they were > deleted - would you really miss them? Think this has been dealt with in subsequent discussions and opinions on = the list. I personally am happy with there being a mix of concrete use = cases and a few more aspirational ones. Doesn't hurt to be aspirational, = as long as that's not all you are... > 2. ID nits says: >=20 > -- Obsolete informational reference (is this intentional?): RFC > 2060 (Obsoleted by RFC 3501) >=20 > -- Obsolete informational reference (is this intentional?): RFC > 2821 (Obsoleted by RFC 5321) >=20 > -- No information found for draft-freeman-plasma-requirements - > is the name correct? >=20 > Looks like these should be updated as noted in the writeup. Fixed. > 3. Please expand CRM on 1st use Done. > 4. Maybe move the reference to SSH to the end of 3.1, from the > start of 3.2, or ideally provide a reference to an "abfab-enabled > SSH" if you have one. (And say "secure shell (SSH)" on 1st use.) Done. > 5. 2nd last para of 3.3 could do with some references really. Don't know of anywhere this is written down well enough to reference; = this is from well-known operational experience. Happy to add a reference = if anyone has one=85 ? > 6. The argument in 3.3 that grid admin complexity is really due > to X.509 seems weak to me. I'd expect you to get comments about > that. And replacing the entire VO thing would be a large task. > It'd be better if you had a very specific use-case here I think > rather than being so general. The issue isn't really that X.509 makes grid admin complex, but rather = that it makes the user experience complex. I think we'd have a hard time = finding anyone who would be willing to argue that point=85 > 7. Its not clear to me how abfab helps in 3.5 - I think you'd > maybe need to say some more about how that'd work. >=20 > 8. 3.9: is it "smart object" or "smart device" just using one > marketing term would be better (zero even moreso;-) >=20 > 9. 3.9 seems quite far-fetched to me. Do you really expect > sensors to use gss-eap? Think these have been addressed in other comments.= From internet-drafts@ietf.org Wed Aug 15 08:13:08 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC53C21F8622; Wed, 15 Aug 2012 08:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.427 X-Spam-Level: X-Spam-Status: No, score=-102.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAicvZghJXyQ; Wed, 15 Aug 2012 08:13:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B79721F87F1; Wed, 15 Aug 2012 08:13:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120815151308.24352.25743.idtracker@ietfa.amsl.com> Date: Wed, 15 Aug 2012 08:13:08 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-usecases-04.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Aug 2012 15:13:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Access= Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond web (AB= FAB) Use Cases Author(s) : Rhys Smith Filename : draft-ietf-abfab-usecases-04.txt Pages : 14 Date : 2012-08-15 Abstract: Federated identity is typically associated with Web-based services at present, but there is growing interest in its application in non Web- based contexts. The goal of this document is to document a selection of the wide variety of these contexts whose user experience could be improved through the use of technologies based on the ABFAB architecture and specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-usecases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-usecases-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-usecases-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Thu Aug 16 00:08:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B980621F8618 for ; Thu, 16 Aug 2012 00:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QcaZL61ke+R for ; Thu, 16 Aug 2012 00:08:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3FC4421F85AE for ; Thu, 16 Aug 2012 00:08:44 -0700 (PDT) Received: (qmail invoked by alias); 16 Aug 2012 07:08:43 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 16 Aug 2012 09:08:43 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+IgeBM1h6IAV2hNhsbiIR7kdufKDrIPT0qI4Yaw6 Pp6kDL7VA4SlEY From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Aug 2012 10:08:41 +0300 Message-Id: <57E38F60-AF22-472B-92C3-1FC22EFEE5E1@gmx.net> To: Jim Schaad Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: abfab@ietf.org Subject: [abfab] draft-ietf-abfab-arch-03.txt - GSS X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 07:08:46 -0000 Hi Jim, Hi all,=20 I now managed to read through the GSS-API part of the draft as well. A = few minor remarks. Section 3.1: The authentication section is indeed interesting and I understand that = there is a challenge to describe it properly. However, may the way how = the story was phrased for earlier EAP-related publications may help. I = believe that the situation is similar to the Secure Association = Protocol, as http://tools.ietf.org/html/rfc4962 calls it. Here is the = short description:=20 A protocol for managing security associations derived from EAP and/or AAA exchanges. The protocol establishes a security association, which includes symmetric keys and a context for the use of the keys. An example of a Secure Association Protocol is the 4-way handshake defined within [802.11i]. The properties of the exchange between the GSS initiator and the GSS = acceptor can similar to the IEEE 802.11i 4-way handshake protocol, i.e., = where the Supplient and the Access Point do not authenticate each other = directly but they both independently derive keying material obtained via = the EAP MSK to confirm through this protocol exchange that they indeed = know the same keying material.=20 A possible variation (which is also supported with the ABFAB work) is = that there is indeed direct authentication of the acceptor to the = initiator (when TLS with server-side authentication is used in GSS). = Here the appropriate comparison would be the IKEv2-EAP integration.=20 The details matter here and since I am not the GSS-API expert I am = wondering how the exchange looks in detail. Maybe a diagram would help = to illustrate how the keying material is derived.=20 Section 3.2:=20 However there are a variety of situations where this authentication is not checked for policy or usability reasons. =20 We cannot make the assumption that the software does not do = authentication or check the result of the authentication process since = then the entire security solution does not work anymore. If this check = is not done how can we assume that other checks are done instead.=20 Even when it is checked, if the trust infrastructure behind the TLS authentication is different from the trust infrastructure behind the GSS-API mutual authentication then confirming the end-points using both trust infrastructures is likely to enhance security. If the endpoints of the GSS-API authentication are different than the endpoints of the lower layer, this is a strong indication of a problem such as a man-in-the-middle attack. Channel binding provides a facility to determine whether these endpoints are the same. =20 I believe the cases that you will detect using this technique are TLS = load balancers that terminate the TLS at the edge of the network. Are = those the main concern or are you also trying to prevent "TLS = inspection" in the style of = http://www.juniper.net/techpubs/en_US/idp5.0/topics/concept/intrusion-dete= ction-prevention-ssl-decryption-overview.html The GSS-EAP mechanism needs to support channel binding. When an application provides channel binding data, the mechanism needs to confirm this is the same on both sides consistent with the GSS-API specification. XXXThere is an open question here as to the details; today RFC 5554 governs. We could use that and the current draft assumes we will. However in Beijing we became aware of some changes to these details that would make life much better for GSS authentication of HTTP. We should resolve this with kitten and replace this note with a reference to the spec we're actually following. Regarding the inline note have we come to a conclusion about this issue = already? RFC 5056 channel binding (also called GSS-API channel binding when GSS-API is involved) is not the same thing as EAP channel binding. EAP channel binding is also used in the ABFAB context in order to implement acceptor naming and mutual authentication. Details are discussed in the mechanisms specification [I-D.ietf-abfab-gss-eap]. =20 I would put this sentence at the beginning of Section 3.2 with a "Note: = ...".=20 Section 3.3:=20 s/A number of GSS-API mechanisms suchs as Kerberos [RFC1964] split the = problem into two parts./A number of GSS-API mechanisms, such as Kerberos = [RFC1964], split the name into two parts. =20 =20 Actually, I do not follow the line of argument in Section 3.3.=20 What is the problem you are solving? I understand that the user either enters a URI of the resource (or gets = it from somewhere else).=20 The URI indicates the resolution mechanism. In our cases it will = typically involve a DNS-based resolution mechanism for resolving the = hostname part to an address (potentially through a series of resolution = steps).=20 Section 3.4: As with mutual authentication, per-message services will limit the set of EAP methods that are available. Any method that produces a Master Session Key (MSK) should be able to support per-message security services. =20 I wouldn't say that it restricts the choice of EAP methods in any = realistic way since EAP methods have to generate keying material also = for other reasons and all EAP methods published since about 15 years = expert the MSK. EAP-MD5 is one method that would work but we have = already standardized a Standards Track replacement for it.=20 I would also suggest to rephrase the last sentence to: " Any EAP=20 method that produces a Master Session Key (MSK) is able to support per-message security services using the procedure described=20= in [X]. " In [X] we put the reference to the document that explains how the MSK = that is make available to the relying party is further derived to create = these session keys for per-message security protection, which is = http://www.ietf.org/id/draft-ietf-abfab-gss-eap-09.txt I believe.=20 =20 GSS-API provides a pseudo-random function. While the pseudo-random function does not involve sending data over the wire, it provides an algorithm that both the initiator and acceptor can run in order to arrive at the same key value. This is useful for designs where a successful authentication is used to key some other function. This is similar in concept to the TLS extractor. No current IETF protocols require this. However GSS-EAP supports this service because it is valuable for the future and easy to do given per- message services. Non-IETF protocols are expected to take advantage of this in the near future. I would delete this paragraph since it is confusing, is not relevant for = the work we are doing, and does not relate to the previous paragraph = either.=20 Ciao Hannes From Hannes.Tschofenig@gmx.net Thu Aug 16 00:09:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F3E21F863C for ; Thu, 16 Aug 2012 00:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqBTvCNeR5Sh for ; Thu, 16 Aug 2012 00:09:02 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 57EC921F8608 for ; Thu, 16 Aug 2012 00:09:02 -0700 (PDT) Received: (qmail invoked by alias); 16 Aug 2012 07:09:00 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp017) with SMTP; 16 Aug 2012 09:09:00 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/hsZMv26bhiX3ewDEw2OIjmXOD1euO7VaR6zuQV2 MTO2dNYtRnFVhe From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Aug 2012 10:09:00 +0300 Message-Id: To: Jim Schaad Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: abfab@ietf.org Subject: [abfab] draft-ietf-abfab-arch-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 07:09:04 -0000 Hi Jim,=20 you have shipped an update of the ABFAB architecture draft for the = Vancouver IETF meeting and I have only now had a chance to review the = changes. Overall, I have to say "Great work."=20 I only have a few minor text suggestions:=20 Federated access management has evolved over the last decade through such standards as SAML [OASIS.saml-core-2.0-os], OpenID [1], OAuth [RFC5849], [I-D.ietf-oauth-v2] and WS-Trust [WS-TRUST].=20 =20 s/such standards as/specifications like=20 =20 =20 =20 Privacy: Often a Relying Party does not need to know the identity of a Subject to reach an access management decision. It is frequently only necessary for the Relying Party know specific attributes about the subject, for example, that the Subject is affiliated with a particular organisation or has a certain role or entitlement. Sometimes the RP does not need to know the identity of the Subject, but does require a unique identifier for the Subject (for example, so that it can recognise the Subject subsequently); in this case, it is a common practise for the IdP to only release a pseudonym that is specific to that particular Relying Party. Federated access management therefore provides various strategies for protecting the Subject's privacy. Other privacy aspects typically of concern are the policy for releasing personal data about the Subject from the IdP to the RP, the purpose of the usage, the retention period of the data, and many more. =20 This paragraph needs to be re-written to something like: Data Minimization and User Participation:=20 =20 Often a Relying Party does not need to know the identity of a Subject to reach an access management decision. It is frequently only necessary for the Relying Party know specific attributes about the subject, for example, that the Subject is affiliated with a particular organisation or has a certain role or entitlement. Sometimes the RP only needs to know a pseudonym=20 of the Subject.=20 =20 Prior to the transfer of attributes from the IdP to the RP the=20 consent of the Subject is often explicitly obtained. Along with = the=20 transfer of attributes usage constraints and retention policies=20 are enforced by the IdP.=20 =20 =20 1.1. Terminology This document uses identity management and privacy terminology from [I-D.iab-privacy-terminology]. In particular, this document uses the terms identity provider, relying party, (data) subject, identifier, pseudonymity, unlinkability, and anonymity. =20 =20 =20 Please replace the reference to [I-D.iab-privacy-terminology] with a = reference to http://tools.ietf.org/html/draft-iab-privacy-considerations = since we merged the terminology with the main privacy consideration = document.=20 We also do not use the term (data) subject anymore but rather = individual. I am not sure whether it is worthwhile to change it from = subject to individual.=20 Section 1.1 lists a table but the table has no title. Why is the 'SASL' = row completely empty? Does SASL, EAP and the GSS-API actually fit in a meaningful way in that = table since those are=20 all two-party protocols? =20 I believe the RADIUS row is wrong. It currently says: " +----------+------------+-------------------+-----------------------+ | Protocol | Subject | Relying Party | Identity Provider | +----------+------------+-------------------+-----------------------+ | RADIUS | client | NAS | RADIUS server | " but it should say: " +----------+------------+-------------------+-----------------------+ | Protocol | Subject | Relying Party | Identity Provider | +----------+------------+-------------------+-----------------------+ | RADIUS | user | NAS or | (RADIUS) server | | | | (RADIUS) client | | " For EAP I would delete the term 'EAP client' since it isn't really = defined in the EAP spec (although it is used twice). EAP client isn't used in this draft.=20 Section 1.2: Some deployments demand the deployment of sophisticated technical infrastructure, including message routing intermediaries, to offer the required technical functionality. In other deployments fewer technical components are needed. =20 =20 The first sentence sounds a bit strange. Maybe it is better to use Some deployments demand the usage of sophisticated technical infrastructure, including message routing intermediaries, to offer the required technical functionality. In other deployments fewer technical components are needed. =20 =20 A note about this sentence:=20 Figure 1 also shows the relationship between the IdP and the Subject. Often a real world entity is associated with the Subject; for example, a person or some software. =20 At least in the way we have current defined the individual (instead of = subject) says: $ Individual: A natural person. =20 The previous definition for subject wasn't different. As such, we don't = need to explain that it may be a person and it cannot be software.=20 This relationship would typically involve the IdP positively identifying and credentialing the Subject (for example, at time of enrollment in the context of employment within an organisation). =20 NIST SP 800-63 calls this initial phase identity proofing. Should we = re-use that terminology? This is sometimes described as the Level of Assurance. =20 Should we reference here NIST SP 800-63 as well since they came up with = this concept.=20 Federation does not imposes requirement of an a priori relationship or a long-term relationship between the RP and the Subject. =20 =20 s/imposes requirement/impose requirements Finally, it is important to reiterate that in some scenarios there might indeed be a human behind the device denoted as Client and in other cases there is no human involved in the actual protocol execution. Hmmm. Wasn't the term for the human subject (or now individual)? 1.3. Challenges to Contemporary Federation Shouldn't we write: "Challenges for ..." Not sure.=20 Section 1.4: 1. Principal provides an NAI to Application: The client application is configured with an NAI. The provided name contains, at a minimum, the realm of an NAI. The realm represents the IdP to be discovered. =20 Here I believe we are talking about EAP, right? The NAI is an EAP/AAA = concept.=20 So, for example when you give your credentials to the network access = application you are in fact provisioning a specific EAP method.=20 Section 1.5: o Each party of a transaction will be authenticated, and the client will be authorized for access to a specific resource. =20 I believe we have mutual authentication between the EAP peer and the EAP = server; we may have mutual authentication between the AAA server and the = AAA client. We don't really have the authentication of the Subject to = the RP (since the Subject may be anonymous towards the RP). We also do = not have a classical authentication of the RP to the Subject/App since = the only guarantee we get is the channel binding mechanism (which may = not be present, right?) o Hence, the architecture requires no sharing of long term private keys. I believe we should be more specific here: No sharing of the Subject's = <-> IdP long term key with the RP.=20 Section 2:=20 Other alternatives exist as well and may be considered later, such as "TLS using EAP Authentication" [I-D.nir-tls-eap].[anchor9] =20 Maybe we remove the [anchor9] thing.=20 Section 2.1: Communications between the Relying Part and the Identity Provider is done by the federation substrate.=20 s/Relying Part/Relying Party o Determining the Rules governing the relationship. =20 s/Rules/rules=20 o Conveying packets between the RP and IdP. =20 s/packets/signaling messages o Providing the means of establishing a trust relationship between the RP and the client. =09 =20 In the text below it adds: The ABFAB protocol itself details the method of establishing the trust relationship between the RP and the client. =20 I am not sure what this is talking about. Is this trying to hint to the = channel binding? Section 2.1.1: The existence of these protocols allows us to re-use a pair of existing protocols that have been widely deployed and are reasonable well understood. =20 s/reasonable/resonably A key difference is that today RADIUS is largely transported upon UDP, and its use is largely, though not exclusively, intra-domain. Diameter itself was designed to scale to broader uses.=20 =20 I would rephrase this as: " RADIUS and Diameter are deployed in different environments. RADIUS = can often be found in=20 enterprise and university networks, and is also in use by fixed = network operators. Diameter, on the other=20 hand, is deployed by mobile operators.=20 " The protocol defines all the necessary new AAA attributes as RADIUS attributes, this allows for the same structures and attributes to be used in both RADIUS and Diameter. =20 Actually, it is not so easy and for that reason there is a separate = RADIUS document and=20 one for Diameter. So, I would delete this sentence and maybe put = references to the drafts.=20 Section 2.1.2: ABFAB has not formally defined any part of discovery at this point. The process of specifying and evaluating the business rules and technical policies is too complex to provide a simple framework. There is not currently a way to know if a AAA proxy is able to communicate with a specific IdP, although this may change with some of the routing protocols that are being considered. At the present time, the discovery process is going to be a manual configuration process. =20 =20 Would it make sense to write this paragrah as follows since the work = will progress but this document, once published as an RFC will remain = unchanged: At the time of writing the discovery process is going to be a manual = configuration process. Proposals for supporting such a dynamic discovery procedure = exist, see [I-D.mrw-abfab-trust-router],=20 and allow an RP to know if a AAA proxy is able to communicate with a = specific IdP. =20 =20 2.1.4. SAML Assertions The new profile can be found in RFCXXXX [I-D.ietf-abfab-aaa-saml]. =20 --> and in the corresponding Diameter document.=20 Throughout this section use s/Assertions/assertions Section 2.2:=20 =20 ABFAB has defined and specified a new channel binding mechanism that operates as an EAP method for the purpose of agreeing on the identity of the RP. =20 I would write:=20 A new channel binding mechanism that operates as an EAP method for the purpose of agreeing on the identity of the RP has been=20= specified in [TBD: whatever that document is]. =20 =20 Section 2.2.2:=20 A general overview of the problem can be found in [I-D.hartman-emu-mutual-crypto-bind]. The recommended way to deal with channel binding can be found in RFC XXXX [I-D.ietf-emu-chbind]. =20 I would write:=20 A general overview of the channel binding problem can be found in RFC 6677.=20 =20 =20 [I have to continue with the GSS related content later.]=20 Ciao Hannes From hartmans@painless-security.com Thu Aug 16 05:30:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EABEF21F85F4 for ; Thu, 16 Aug 2012 05:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.12 X-Spam-Level: **** X-Spam-Status: No, score=4.12 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCyrsHtKQAOP for ; Thu, 16 Aug 2012 05:30:54 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id C960E21F85EF for ; Thu, 16 Aug 2012 05:30:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4C7332085D; Thu, 16 Aug 2012 08:22:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E91CA4350; Thu, 16 Aug 2012 08:22:42 -0400 (EDT) From: Sam Hartman To: Hannes Tschofenig References: Date: Thu, 16 Aug 2012 08:22:42 -0400 In-Reply-To: (Hannes Tschofenig's message of "Thu, 16 Aug 2012 10:09:00 +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: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 12:30:55 -0000 >>>>> "Hannes" == Hannes Tschofenig writes: Hannes> Privacy: Hannes> Often a Relying Party does not need to know the Hannes> identity of a Subject to reach an access management Hannes> decision. It is frequently only necessary for the Relying Hannes> Party know specific attributes about the subject, for Hannes> example, that the Subject is affiliated with a particular Hannes> organisation or has a certain role or entitlement. Hannes> Sometimes the RP does not need to know the identity of the Hannes> Subject, but does require a unique identifier for the Hannes> Subject (for example, so that it can recognise the Subject Hannes> subsequently); in this case, it is a common practise for the Hannes> IdP to only release a pseudonym that is specific to that Hannes> particular Relying Party. Federated access management Hannes> therefore provides various strategies for protecting the Hannes> Subject's privacy. Other privacy aspects typically of Hannes> concern are the policy for releasing personal data about the Hannes> Subject from the IdP to the RP, the purpose of the usage, Hannes> the retention period of the data, and many more. Hannes> This paragraph needs to be re-written to something like: Hannes, I'd appreciate it if you would describe your concerns with the original paragraph. From my standpoint the original paragraph does a much better job of describing these issues from the ABFAb standpoint. One particular concern is that I think bringing consent in without a lot more discussion may provide an accurate description of our hopes, but not so much of the realities. Hannes> Data Minimization and User Participation: Hannes> Often a Relying Party does not need to know the Hannes> identity of a Subject to reach an access management Hannes> decision. It is frequently only necessary for the Relying Hannes> Party know specific attributes about the subject, for Hannes> example, that the Subject is affiliated with a particular Hannes> organisation or has a certain role or entitlement. Sometimes Hannes> the RP only needs to know a pseudonym of the Subject. Hannes> Prior to the transfer of attributes from the IdP to Hannes> the RP the consent of the Subject is often explicitly Hannes> obtained. Along with the transfer of attributes usage Hannes> constraints and retention policies are enforced by the IdP. Hannes> 1.1. Terminology Hannes> This document uses identity management and privacy Hannes> terminology from [I-D.iab-privacy-terminology]. In Hannes> particular, this document uses the terms identity provider, Hannes> relying party, (data) subject, identifier, pseudonymity, Hannes> unlinkability, and anonymity. Hannes> Please replace the reference to Hannes> [I-D.iab-privacy-terminology] with a reference to Hannes> http://tools.ietf.org/html/draft-iab-privacy-considerations Hannes> since we merged the terminology with the main privacy Hannes> consideration document. Hannes> We also do not use the term (data) subject anymore but Hannes> rather individual. I am not sure whether it is worthwhile to Hannes> change it from subject to individual. Hannes> Section 1.1 lists a table but the table has no title. Why is Hannes> the 'SASL' row completely empty? Does SASL, EAP and the Hannes> GSS-API actually fit in a meaningful way in that table since Hannes> those are all two-party protocols? Hannes> I believe the RADIUS row is wrong. It currently says: Hannes> " Hannes> +----------+------------+-------------------+-----------------------+ Hannes> | Protocol | Subject | Relying Party | Identity Provider | Hannes> +----------+------------+-------------------+-----------------------+ Hannes> | RADIUS | client | NAS | RADIUS server | " Hannes> but it should say: Hannes> " Hannes> +----------+------------+-------------------+-----------------------+ Hannes> | Protocol | Subject | Relying Party | Identity Provider | Hannes> +----------+------------+-------------------+-----------------------+ Hannes> | RADIUS | user | NAS or | (RADIUS) server | | | | (RADIUS) Hannes> client | | " Hannes> For EAP I would delete the term 'EAP client' since it isn't Hannes> really defined in the EAP spec (although it is used twice). Hannes> EAP client isn't used in this draft. Hannes> Section 1.2: Hannes> Some deployments demand the deployment of sophisticated Hannes> technical infrastructure, including message routing Hannes> intermediaries, to offer the required technical Hannes> functionality. In other deployments fewer technical Hannes> components are needed. Hannes> The first sentence sounds a bit strange. Maybe it is better Hannes> to use Hannes> Some deployments demand the usage of sophisticated Hannes> technical infrastructure, including message routing Hannes> intermediaries, to offer the required technical Hannes> functionality. In other deployments fewer technical Hannes> components are needed. Hannes> A note about this sentence: Hannes> Figure 1 also shows the relationship between the IdP and Hannes> the Subject. Often a real world entity is associated with Hannes> the Subject; for example, a person or some software. Hannes> At least in the way we have current defined the individual Hannes> (instead of subject) says: Hannes> $ Individual: A natural person. Hannes> The previous definition for subject wasn't different. As Hannes> such, we don't need to explain that it may be a person and Hannes> it cannot be software. Hannes> This relationship would typically involve the IdP Hannes> positively identifying and credentialing the Subject (for Hannes> example, at time of enrollment in the context of employment Hannes> within an organisation). Hannes> NIST SP 800-63 calls this initial phase identity Hannes> proofing. Should we re-use that terminology? Hannes> This is sometimes described as the Level of Assurance. Hannes> Should we reference here NIST SP 800-63 as well since they Hannes> came up with this concept. Hannes> Federation does not imposes requirement of an a priori Hannes> relationship or a long-term relationship between the RP and Hannes> the Subject. Hannes> s/imposes requirement/impose requirements Hannes> Finally, it is important to reiterate that in some Hannes> scenarios there might indeed be a human behind the device Hannes> denoted as Client and in other cases there is no human Hannes> involved in the actual protocol execution. Hannes> Hmmm. Wasn't the term for the human subject (or now Hannes> individual)? Hannes> 1.3. Challenges to Contemporary Federation Hannes> Shouldn't we write: "Challenges for ..." Not sure. Hannes> Section 1.4: Hannes> 1. Principal provides an NAI to Application: The client Hannes> application is configured with an NAI. The provided name Hannes> contains, at a minimum, the realm of an NAI. The realm Hannes> represents the IdP to be discovered. Hannes> Here I believe we are talking about EAP, right? The NAI is Hannes> an EAP/AAA concept. So, for example when you give your Hannes> credentials to the network access application you are in Hannes> fact provisioning a specific EAP method. Hannes> Section 1.5: Hannes> o Each party of a transaction will be authenticated, and Hannes> the client will be authorized for access to a specific Hannes> resource. Hannes> I believe we have mutual authentication between the EAP peer Hannes> and the EAP server; we may have mutual authentication Hannes> between the AAA server and the AAA client. We don't really Hannes> have the authentication of the Subject to the RP (since the Hannes> Subject may be anonymous towards the RP). We also do not Hannes> have a classical authentication of the RP to the Subject/App Hannes> since the only guarantee we get is the channel binding Hannes> mechanism (which may not be present, right?) Hannes> o Hence, the architecture requires no sharing of long Hannes> term private keys. Hannes> I believe we should be more specific here: No sharing of the Hannes> Subject's <-> IdP long term key with the RP. Hannes> Section 2: Hannes> Other alternatives exist as well and may be considered Hannes> later, such as "TLS using EAP Authentication" Hannes> [I-D.nir-tls-eap].[anchor9] Hannes> Maybe we remove the [anchor9] thing. Hannes> Section 2.1: Hannes> Communications between the Relying Part and the Identity Hannes> Provider is done by the federation substrate. Hannes> s/Relying Part/Relying Party Hannes> o Determining the Rules governing the relationship. Hannes> s/Rules/rules Hannes> o Conveying packets between the RP and IdP. Hannes> s/packets/signaling messages Hannes> o Providing the means of establishing a trust Hannes> relationship between the RP and the client. Hannes> In the text below it adds: Hannes> The ABFAB protocol itself details the method of Hannes> establishing the trust relationship between the RP and the Hannes> client. Hannes> I am not sure what this is talking about. Is this trying to Hannes> hint to the channel binding? Hannes> Section 2.1.1: Hannes> The existence of these protocols allows us to re-use a Hannes> pair of existing protocols that have been widely deployed Hannes> and are reasonable well understood. Hannes> s/reasonable/resonably Hannes> A key difference is that today RADIUS is largely Hannes> transported upon UDP, and its use is largely, though not Hannes> exclusively, intra-domain. Diameter itself was designed to Hannes> scale to broader uses. Hannes> I would rephrase this as: Hannes> " RADIUS and Diameter are deployed in different Hannes> environments. RADIUS can often be found in enterprise and Hannes> university networks, and is also in use by fixed network Hannes> operators. Diameter, on the other hand, is deployed by Hannes> mobile operators. " Hannes> The protocol defines all the necessary new AAA attributes Hannes> as RADIUS attributes, this allows for the same structures Hannes> and attributes to be used in both RADIUS and Diameter. Hannes> Actually, it is not so easy and for that reason there is a Hannes> separate RADIUS document and one for Diameter. So, I would Hannes> delete this sentence and maybe put references to the drafts. Hannes> Section 2.1.2: Hannes> ABFAB has not formally defined any part of discovery at Hannes> this point. The process of specifying and evaluating the Hannes> business rules and technical policies is too complex to Hannes> provide a simple framework. There is not currently a way to Hannes> know if a AAA proxy is able to communicate with a specific Hannes> IdP, although this may change with some of the routing Hannes> protocols that are being considered. At the present time, Hannes> the discovery process is going to be a manual configuration Hannes> process. Hannes> Would it make sense to write this paragrah as follows since Hannes> the work will progress but this document, once published as Hannes> an RFC will remain unchanged: Hannes> At the time of writing the discovery process is going to Hannes> be a manual configuration process. Proposals for supporting Hannes> such a dynamic discovery procedure exist, see Hannes> [I-D.mrw-abfab-trust-router], and allow an RP to know if a Hannes> AAA proxy is able to communicate with a specific IdP. Hannes> 2.1.4. SAML Assertions Hannes> The new profile can be found in RFCXXXX Hannes> [I-D.ietf-abfab-aaa-saml]. --> and in the corresponding Diameter document. Hannes> Throughout this section use s/Assertions/assertions Hannes> Section 2.2: Hannes> ABFAB has defined and specified a new channel binding Hannes> mechanism that operates as an EAP method for the purpose of Hannes> agreeing on the identity of the RP. Hannes> I would write: Hannes> A new channel binding mechanism that operates as an EAP Hannes> method for the purpose of agreeing on the identity of the RP Hannes> has been specified in [TBD: whatever that document is]. Hannes> Section 2.2.2: Hannes> A general overview of the problem can be found in Hannes> [I-D.hartman-emu-mutual-crypto-bind]. The recommended way Hannes> to deal with channel binding can be found in RFC XXXX Hannes> [I-D.ietf-emu-chbind]. Hannes> I would write: Hannes> A general overview of the channel binding problem can be Hannes> found in RFC 6677. Hannes> [I have to continue with the GSS related content later.] Hannes> Ciao Hannes Hannes> _______________________________________________ abfab Hannes> mailing list abfab@ietf.org Hannes> https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu Aug 16 06:00:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A166121F84D5 for ; Thu, 16 Aug 2012 06:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.187 X-Spam-Level: **** X-Spam-Status: No, score=4.187 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izjLD3fpDIQ4 for ; Thu, 16 Aug 2012 06:00:55 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id 34AFB21F851A for ; Thu, 16 Aug 2012 06:00:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3B72420862; Thu, 16 Aug 2012 08:35:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B8D2B4350; Thu, 16 Aug 2012 08:35:07 -0400 (EDT) From: Sam Hartman To: Hannes Tschofenig References: <57E38F60-AF22-472B-92C3-1FC22EFEE5E1@gmx.net> Date: Thu, 16 Aug 2012 08:35:07 -0400 In-Reply-To: <57E38F60-AF22-472B-92C3-1FC22EFEE5E1@gmx.net> (Hannes Tschofenig's message of "Thu, 16 Aug 2012 10:08:41 +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: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt - GSS X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 13:00:55 -0000 >>>>> "Hannes" == Hannes Tschofenig writes: Hannes> Section 3.2: Hannes> However there are a variety of situations where this Hannes> authentication is not checked for policy or usability Hannes> reasons. Hannes> We cannot make the assumption that the software does not do Hannes> authentication or check the result of the authentication Hannes> process since then the entire security solution does not Hannes> work anymore. Section 3.2 is all about providing alternatives when this check is not done. This check is not done in practice a *lot*. There are lots of application libraries that do not check server certificates. Actually the TLS channel bindings have been designed with a couple of strategies for dealing with load balancers and in general for allowing a server to securly indicate that it cannot provide channel bindings and so server certs are all you get. Hannes> consistent with the GSS-API specification. XXXThere is an Hannes> open question here as to the details; today RFC 5554 Hannes> governs. We could use that and the current draft assumes we Hannes> will. However in Beijing we became aware of some changes to Hannes> these details that would make life much better for GSS Hannes> authentication of HTTP. We should resolve this with kitten Hannes> and replace this note with a reference to the spec we're Hannes> actually following. Hannes> Regarding the inline note have we come to a conclusion about Hannes> this issue already? Yeah, we're just using the existing stuff. Nothing new has materialized in the IETF. Hannes> Section 3.3: Hannes> GSS-API provides a pseudo-random function. While the Hannes> pseudo-random function does not involve sending data over Hannes> the wire, it provides an algorithm that both the initiator Hannes> and acceptor can run in order to arrive at the same key Hannes> value. This is useful for designs where a successful Hannes> authentication is used to key some other function. This is Hannes> similar in concept to the TLS extractor. No current IETF Hannes> protocols require this. However GSS-EAP supports this Hannes> service because it is valuable for the future and easy to do Hannes> given per- message services. Non-IETF protocols are Hannes> expected to take advantage of this in the near future. Hannes> I would delete this paragraph since it is confusing, is not Hannes> relevant for the work we are doing, and does not relate to Hannes> the previous paragraph either. How is this not relevant? GSS-EAP implementations are required to provide gss_pseudo_random. Hannes> Ciao Hannes Hannes> _______________________________________________ abfab Hannes> mailing list abfab@ietf.org Hannes> https://www.ietf.org/mailman/listinfo/abfab From Hannes.Tschofenig@gmx.net Fri Aug 17 04:52:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F1C21F856D for ; Fri, 17 Aug 2012 04:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzifzIbo2diE for ; Fri, 17 Aug 2012 04:52:13 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EE54621F8568 for ; Fri, 17 Aug 2012 04:52:12 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 11:52:11 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp037) with SMTP; 17 Aug 2012 13:52:11 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX195k9ZChvd5Z5Ym5A22IAraPLkDUJRChrhueEx8cv fvVy5Ag8hxR4OE Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 17 Aug 2012 14:52:04 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <61B75D7E-4478-498B-BE75-774FB18FC6DE@gmx.net> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:52:14 -0000 Hi Sam,=20 thanks for the quick response.=20 On Aug 16, 2012, at 3:22 PM, Sam Hartman wrote: >>>>>> "Hannes" =3D=3D Hannes Tschofenig = writes: >=20 > Hannes> Privacy: >=20 > Hannes> Often a Relying Party does not need to know the > Hannes> identity of a Subject to reach an access management > Hannes> decision. It is frequently only necessary for the Relying > Hannes> Party know specific attributes about the subject, for > Hannes> example, that the Subject is affiliated with a particular > Hannes> organisation or has a certain role or entitlement. > Hannes> Sometimes the RP does not need to know the identity of the > Hannes> Subject, but does require a unique identifier for the > Hannes> Subject (for example, so that it can recognise the Subject > Hannes> subsequently); in this case, it is a common practise for = the > Hannes> IdP to only release a pseudonym that is specific to that > Hannes> particular Relying Party. Federated access management > Hannes> therefore provides various strategies for protecting the > Hannes> Subject's privacy. Other privacy aspects typically of > Hannes> concern are the policy for releasing personal data about = the > Hannes> Subject from the IdP to the RP, the purpose of the usage, > Hannes> the retention period of the data, and many more. >=20 > Hannes> This paragraph needs to be re-written to something like: >=20 > Hannes, I'd appreciate it if you would describe your concerns with the > original paragraph. =46rom my standpoint the original paragraph does = a > much better job of describing these issues from the ABFAb standpoint. > One particular concern is that I think bringing consent in without a = lot more discussion > may provide an accurate description of our hopes, but not so much of = the > realities. The issue with the original paragraph is the following.=20 Privacy: [hannes] The title privacy suggests that we cover privacy as a whole but = instead the paragraph only discussed a small area of privacy. For this = reason I suggested to change the title of that paragraph=20 Often a Relying Party does not need to know the identity of a Subject to reach an access management decision. It is frequently only necessary for the Relying Party know specific attributes about the subject, for example, that the Subject is affiliated with a particular organisation or has a certain role or entitlement. [hannes] Here we have a terminology issue. Let me copy the definition of = "identity" here:=20 http://tools.ietf.org/html/draft-iab-privacy-considerations-02 " $ Identity Any subset of a data subject's attributes that identifies the subject within a given context. Data subjects usually have multiple identities for use in different contexts. " So, I think what the above sentence tries to say is that the relying = party only needs to know a (small) subset of the subject's attributes = and particularly not an identifier that is persistent across multiple = sessions. =20 =20 Sometimes the RP does not need to know the identity of the Subject, but does require a unique identifier for the Subject (for example, so that it can recognise the Subject subsequently);=20 [hannes] This also confused the terminology. A unique identifier of a = subject is one of the identities of the subject. in this case, it is a common practise for the IdP to only release a pseudonym that is specific to that particular Relying Party. [hannes] Here is the definition of the pseudonym: " $ Pseudonym An identifier of a data subject other than the subject's real name. " So, I guess the previous sentence should have talked about identifiers = rather than identities.=20 Federated access management therefore provides various strategies for protecting the Subject's privacy. Other privacy aspects typically of concern are the policy for releasing personal data about the Subject from the IdP to the RP, the purpose of the usage, the retention period of the data, and many more. From hannes.tschofenig@gmx.net Fri Aug 17 04:55:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804A021F8513 for ; Fri, 17 Aug 2012 04:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1x9t-dlRTNq for ; Fri, 17 Aug 2012 04:55:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7544A21F84B9 for ; Fri, 17 Aug 2012 04:55:52 -0700 (PDT) Received: (qmail invoked by alias); 17 Aug 2012 11:55:51 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp034) with SMTP; 17 Aug 2012 13:55:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Ih4UpEiOI03kgsPtMlnylNUBKLmBFw+MS6zRf1y oFwVDLEuJx95HS Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Fri, 17 Aug 2012 14:55:49 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0AF3B21D-4112-4733-B370-506474E3CA42@gmx.net> References: <57E38F60-AF22-472B-92C3-1FC22EFEE5E1@gmx.net> To: Sam Hartman X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt - GSS X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 11:55:53 -0000 Hi Sam,=20 thanks also for the quick response to this mail.=20 On Aug 16, 2012, at 3:35 PM, Sam Hartman wrote: >>>>>> "Hannes" =3D=3D Hannes Tschofenig = writes: >=20 > Hannes> Section 3.2: >=20 > Hannes> However there are a variety of situations where this > Hannes> authentication is not checked for policy or usability > Hannes> reasons. >=20 > Hannes> We cannot make the assumption that the software does not do > Hannes> authentication or check the result of the authentication > Hannes> process since then the entire security solution does not > Hannes> work anymore.=20 >=20 > Section 3.2 is all about providing alternatives when this check is not > done. > This check is not done in practice a *lot*. There are lots of > application libraries that do not check server certificates. >=20 I guess we just have a different understanding here.=20 My strategy is to fix the lack of certificate checking.=20 Your strategy is to define a new specification that provides an = additional mechanism for doing a similar check assuming that it would = get implemented.=20 I am failing to see why people would implement your alternative = mechanisms when they did not bother to implement the certificate = checking.=20 >=20 > Actually the TLS channel bindings have been designed with a couple of > strategies for dealing with load balancers and in general for allowing = a > server to securly indicate that it cannot provide channel bindings > and so server certs are all you get. Interesting. I didn't know that.=20 Where do I read more about this?=20 > Hannes> consistent with the GSS-API specification. XXXThere is an > Hannes> open question here as to the details; today RFC 5554 > Hannes> governs. We could use that and the current draft assumes = we > Hannes> will. However in Beijing we became aware of some changes = to > Hannes> these details that would make life much better for GSS > Hannes> authentication of HTTP. We should resolve this with kitten > Hannes> and replace this note with a reference to the spec we're > Hannes> actually following. >=20 > Hannes> Regarding the inline note have we come to a conclusion = about > Hannes> this issue already? >=20 > Yeah, we're just using the existing stuff. > Nothing new has materialized in the IETF. >=20 Great to hear.=20 Maybe it would be good to fix this note in the text so that we can = finish it asap. =20 > Hannes> Section 3.3: >=20 > Hannes> GSS-API provides a pseudo-random function. While the > Hannes> pseudo-random function does not involve sending data over > Hannes> the wire, it provides an algorithm that both the initiator > Hannes> and acceptor can run in order to arrive at the same key > Hannes> value. This is useful for designs where a successful > Hannes> authentication is used to key some other function. This is > Hannes> similar in concept to the TLS extractor. No current IETF > Hannes> protocols require this. However GSS-EAP supports this > Hannes> service because it is valuable for the future and easy to = do > Hannes> given per- message services. Non-IETF protocols are > Hannes> expected to take advantage of this in the near future. >=20 >=20 > Hannes> I would delete this paragraph since it is confusing, is not > Hannes> relevant for the work we are doing, and does not relate to > Hannes> the previous paragraph either. >=20 > How is this not relevant? > GSS-EAP implementations are required to provide gss_pseudo_random. >=20 Hmmm. Maybe I should re-read GSS-EAP. Will do that and then I will come = back to this issue.=20 Ciao Hannes >=20 > Hannes> Ciao Hannes >=20 > Hannes> _______________________________________________ abfab > Hannes> mailing list abfab@ietf.org > Hannes> https://www.ietf.org/mailman/listinfo/abfab >=20 From Josh.Howlett@ja.net Fri Aug 17 06:17:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4192521F854F for ; Fri, 17 Aug 2012 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVDwzUrGRCtK for ; Fri, 17 Aug 2012 06:17:00 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7350C21F8517 for ; Fri, 17 Aug 2012 06:17:00 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id ED11A20C713A_2E444AB; Fri, 17 Aug 2012 13:16:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id B2D1220C7109_2E444AF; Fri, 17 Aug 2012 13:16:58 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Fri, 17 Aug 2012 14:16:58 +0100 From: Josh Howlett To: Hannes Tschofenig , Sam Hartman Thread-Topic: [abfab] draft-ietf-abfab-arch-03.txt Thread-Index: AQHNe34SqahBBr+oQ0qlYXJCp/BCrZdcXy3jgAF2gwCAABUWAA== Date: Fri, 17 Aug 2012 13:16:57 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30A470190@EXC001> References: <61B75D7E-4478-498B-BE75-774FB18FC6DE@gmx.net> In-Reply-To: <61B75D7E-4478-498B-BE75-774FB18FC6DE@gmx.net> 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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 13:17:01 -0000 > > Hannes, I'd appreciate it if you would describe your concerns with > the > > original paragraph. From my standpoint the original paragraph does a > > much better job of describing these issues from the ABFAb standpoint. > > One particular concern is that I think bringing consent in without a > lot more discussion > > may provide an accurate description of our hopes, but not so much of > the > > realities. I prefer Hannes' formulation; with the exception of the part discussing con= sent. I don't think it is necessary to discuss specific policy mechanisms (= particularly in the case of consent, where there is plenty of ambiguity abo= ut where it is appropriate and where it is not). Josh. Janet 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@mnt.se Fri Aug 17 07:33:11 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7523921E8053 for ; Fri, 17 Aug 2012 07:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.295 X-Spam-Level: X-Spam-Status: No, score=-0.295 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il109wvDoiAL for ; Fri, 17 Aug 2012 07:33:11 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABC1C21E8063 for ; Fri, 17 Aug 2012 07:33:10 -0700 (PDT) Received: by lahm15 with SMTP id m15so2212805lah.31 for ; Fri, 17 Aug 2012 07:33:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=ewwSznp8Y1MLVwwwt211k4rwuXcdkgOwtvPzqC5BQsQ=; b=QAhEr0UMNGGBf4hsu6+civ1LC8/B8Pky4CGvDEwbGdyWo8eGa9RTOFOYn4H9+opMPp V4XAVJ/5pCQ8xsVI/C3d32idMk+0hLMV5cDkLx9VO4GpF249NR6JZ+x87Hg3sORc6vyt R0PW5m67FTFMB+Qu25gvdzlZrm9uga0alsXEB8x668Aq3ueJPFqf2LG51YfuN43hOJxd 7Q1mpXPUm/OkWZ4FM4zjhAryJWvUH6rV0FxgvjkJOUSW8gmO/tgbXz6wl9JBXpbhgXAO 5B87Xinv8FF06uKXsU6Nzab2MBRHSSwr7TiknWBB61N7r1OEpKzBR4PUUk0gsg/lEpit vnSQ== Received: by 10.152.124.180 with SMTP id mj20mr5089494lab.43.1345213989618; Fri, 17 Aug 2012 07:33:09 -0700 (PDT) Received: from [172.20.10.3] (2.67.174.249.mobile.tre.se. [2.67.174.249]) by mx.google.com with ESMTPS id lr17sm7333621lab.12.2012.08.17.07.33.05 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 17 Aug 2012 07:33:08 -0700 (PDT) References: <61B75D7E-4478-498B-BE75-774FB18FC6DE@gmx.net> <55DC663C2F4F9F439F23543E0078E8B30A470190@EXC001> In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30A470190@EXC001> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <99B692B5-D7B8-4EB2-8262-53CF54DDAAE4@mnt.se> X-Mailer: iPad Mail (9B206) From: Leif Johansson Date: Fri, 17 Aug 2012 16:33:03 +0200 To: Josh Howlett X-Gm-Message-State: ALoCoQlEE+Z5GmV1dCPd2Oq3zh/S5Dm52ul50u7j8qf/Qat7lvAKJAiWVG7857iL8wnty0DPDzDI Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 14:33:11 -0000 17 aug 2012 kl. 15:16 skrev Josh Howlett : >>> Hannes, I'd appreciate it if you would describe your concerns with >> the >>> original paragraph. =46rom my standpoint the original paragraph does a >>> much better job of describing these issues from the ABFAb standpoint. >>> One particular concern is that I think bringing consent in without a >> lot more discussion >>> may provide an accurate description of our hopes, but not so much of >> the >>> realities. >=20 > I prefer Hannes' formulation; with the exception of the part discussing co= nsent. I don't think it is necessary to discuss specific policy mechanisms (= particularly in the case of consent, where there is plenty of ambiguity abou= t where it is appropriate and where it is not). >=20 > Josh. +1 consent is just a huge can of worms >=20 >=20 >=20 > Janet 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 Fri Aug 17 09:16:50 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BD021F8463 for ; Fri, 17 Aug 2012 09:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.232 X-Spam-Level: **** X-Spam-Status: No, score=4.232 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpzYI2zrkymP for ; Fri, 17 Aug 2012 09:16:50 -0700 (PDT) Received: from ec2-23-21-227-93.compute-1.amazonaws.com (ec2-23-21-227-93.compute-1.amazonaws.com [23.21.227.93]) by ietfa.amsl.com (Postfix) with ESMTP id ABFFF21F845B for ; Fri, 17 Aug 2012 09:16:49 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A4AC320A27; Fri, 17 Aug 2012 12:16:46 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6B2CD4350; Fri, 17 Aug 2012 12:16:37 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: <61B75D7E-4478-498B-BE75-774FB18FC6DE@gmx.net> <55DC663C2F4F9F439F23543E0078E8B30A470190@EXC001> Date: Fri, 17 Aug 2012 12:16:37 -0400 In-Reply-To: <55DC663C2F4F9F439F23543E0078E8B30A470190@EXC001> (Josh Howlett's message of "Fri, 17 Aug 2012 13:16:57 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 16:16:50 -0000 I'm fine with Hannes's formulation if we drop consent From ietf@augustcellars.com Sat Aug 18 04:08:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9D321F859B for ; Sat, 18 Aug 2012 04:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5crKLRd3Fmw5 for ; Sat, 18 Aug 2012 04:08:27 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4C21F8592 for ; Sat, 18 Aug 2012 04:08:27 -0700 (PDT) Received: from Tobias (unknown [210.11.218.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2DE4138EF2; Sat, 18 Aug 2012 04:08:22 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Josh Howlett'" References: <61B75D7E-4478-498B-BE75-774FB18FC6DE@gmx.net> <55DC663C2F4F9F439F23543E0078E8B30A470190@EXC001> In-Reply-To: Date: Sat, 18 Aug 2012 20:36:53 +0930 Message-ID: <023f01cd7d31$99178f60$cb46ae20$@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: AQGFkdo1N59fOqGhMcRLtEDsDyXtLwHLaP1uAXXdAjYB0L0JSQDuBAd3l78/LaA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 11:08:28 -0000 I'll try and get this in the next revision > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Saturday, August 18, 2012 1:47 AM > To: Josh Howlett > Cc: Hannes Tschofenig; Jim Schaad; abfab@ietf.org > Subject: Re: [abfab] draft-ietf-abfab-arch-03.txt > > I'm fine with Hannes's formulation if we drop consent From jsalowey@cisco.com Tue Aug 21 21:18:09 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE211E8091 for ; Tue, 21 Aug 2012 21:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H88-jTL0AYMW for ; Tue, 21 Aug 2012 21:18:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5396E11E809A for ; Tue, 21 Aug 2012 21:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=4930; q=dns/txt; s=iport; t=1345609085; x=1346818685; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=6JlIjF8SYIm+2qO7e0qBSvfr+eJovcc0zMlfSc8GsDc=; b=S6QGfdRqEyIb4nj4iLJ/P2e/uTtAEuenwa9QySHhPfzf3B+InIzeOyWk HMNe4QwiXK1WwsvILi0WoC37mMqzM3if/ul5XSgFnbe0EjS+Mn5j+ooWG 66+dTtPw2TXrMn5dgpwHgR7VdQvl8kpRgE3HaQs53EDO5fe7rHAyBZqsS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMNcNFCtJV2Y/2dsb2JhbABFumCBB4IgAQEBAwESASc/BQ0BCDZCJwQOJ4dlBpkooDiLHIYoYAOVUo4tgWaCYYFYAiM X-IronPort-AV: E=Sophos;i="4.77,807,1336348800"; d="scan'208";a="113811564" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 22 Aug 2012 04:18:04 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7M4I42o016185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Aug 2012 04:18:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Tue, 21 Aug 2012 23:18:04 -0500 From: "Joseph Salowey (jsalowey)" To: "abfab@ietf.org" Thread-Topic: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt Thread-Index: AQHNgB0fiXIVenQlO02TsHqgcjGbtg== Date: Wed, 22 Aug 2012 04:18:03 +0000 Message-ID: <3E8B557B-AC35-482E-9A32-79ACDABAC662@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.64] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19130.001 x-tm-as-result: No--35.992000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Jim Schaad Subject: Re: [abfab] Comments on draft-ietf-abfab-eapapplicability-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 04:18:10 -0000 Hi Jim, Thanks for the review,=20 Somehow I lost the original message so I've reproduced it from the archives= below: > Abstract. > 1. Expand the EAP and ABFAB > 2. Do you really want to talk about the use cases in the sentence? >=20 How about: "This document updates the Extensible Authentication Protocol (EAP) applica= bility statement from RFC3748 to reflect recent usage of the EAP protocol in the Application Bridging fo= r Federated Access Beyond web (ABFAB) working group." > Uses of EAP for Application-Layer Access > 1. It is not clear to me that using channel bindings informs the peer wh= at > services are provided by an authenticator. What I think is given is that > the peer can validate that A specific service is provided. >=20 [Joe] There is something wrong with the text, this should be better: "Without channel bindings, a peer cannot verify if an authenticator is auth= orized to provide an advertised service. " > 2. para #2 says that which service is needed, but the previous paragraph = is > talking about different services not different qualities of a specific > service. I don't think this follows well. >=20 > 3. Swapping sentences 2 and 3 in para #2 might be reasonable - this > describing that the quality of service can be important and then giving a= n > example of why that is true. >=20 [Joe]=20 > 4. Do we have the ability to discuss the security implications in channe= l > binding? In order for this to be true you need to have the ability to ha= ve > a distinct name of the service between the low and high value versions of > the same service. This would mean multiple names for the "print" service= . > It is not clear that this is how people are going to do this. >=20 [Joe] You have to have some way of differentiating the types of services.= This could be by name or it could be by some other parameter. for examp= le you can have a print service with a confidential attribute which may be = true or false. There are many other approaches as well. I'm not sure that= this is the document that should detail this. =20 > 5. After reading this for a while, I think that part of my problem is th= at > I am picking up a different meaning for the word service. I think of > service as a print service, not of as "The high security print service > running on machine foo.example.com". If this is the case then that might= be > the clarification that removes the above comments. >=20 [Joe] OK, so would the following help: "However as additional services use EAP for authentication, the distinction of which service is being contacted becomes more important. Application services might have different properties.=20 Consider an environment with multiple printers some of which provide a c= onfidential service to output documents to a controlled location. If a peer sent a document to the wrong service then potentially sensitive information might be printed in an uncontrolled location and be disclose= d. In addition, it might be more likely that a low-value service is compromised than some high value service. If the high-value service could be impersonated by a low-value service then the security of the overall system would be limited by the security of the lower value service." > 6. I think that you might talk about the cases where channel binding COUL= D > be required even for network authentication. The fact that it is not > required does not mean that it cannot be used. One issue is going to be = how > an IdP identifies a network authentication service from a different servi= ce > for the purposes of deciding if channel binding is going to be required. >=20 [Joe] I agree with the discussion on the list that says this is out of scop= e for this document.=20 > 7. Is it just important to prove that the EAP MSK is mutually held, or i= s > it REQUIRED? What are the implications of not doing so? >=20 [Joe] REQUIRED, "It is REQUIRED for the application layer to prove possession of the EAP MSK between the EAP Peer and EAP Authenticator. Failing to validate = the possession of the EAP MSK can allow an attacker to insert himself into = the conversation and impersonate the peer or authenticator. =20 > Security Considerations > 1. When doing channel binding, it is highly desirable (required?) that th= e > authenticator is not able to modify (and potentially to see?) the channel > binding data passed from the peer to the authenticator (or reverse) as pa= rt > of the authentication process. [Joe] I don't think confidentiality is required. How about: "When doing channel binding it is REQUIRED that the authenticator is not ab= le to modify the channel binding data passed between the peer to the authen= ticator as part of the authentication process. " From ietf@augustcellars.com Wed Aug 22 04:25:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5731D21F8634 for ; Wed, 22 Aug 2012 04:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PixzClIezV-u for ; Wed, 22 Aug 2012 04:25:21 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3C3621F8629 for ; Wed, 22 Aug 2012 04:25:21 -0700 (PDT) Received: from Tobias (dsl-210-15-238-225-static.VIC.netspace.net.au [210.15.238.225]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id C59502CA18; Wed, 22 Aug 2012 04:25:19 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <011101cd616e$0400a3a0$0c01eae0$@augustcellars.com> In-Reply-To: Date: Wed, 22 Aug 2012 20:53:51 +0930 Message-ID: <026d01cd8058$a01ee8b0$e05cba10$@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: AQItLSFlIDnqLO+ojZBMKe64RR50xgGtlMWbAVdIlU2WjIqSsA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming believed ready for last call X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Aug 2012 11:25:22 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Wednesday, August 15, 2012 1:17 AM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] draft-ietf-abfab-gss-eap-naming believed ready for last > call > > >>>>> "Jim" == Jim Schaad writes: > > Jim> 1. Just because I keep having to go and read the SAML document > Jim> every time, it might be useful to provide an example in > Jim> paragraph 1 of section 3 about what makes a first part and a > Jim> second part. I would pass the document without this, it is > Jim> just a suggestion. > > I'd love to include an example here. > I'll try to update code prior to IETF LC ending. Hope to see it. > > > Jim> 3. In section 5, I thought we had agreed that there should be > Jim> a statement that "The values, prior to receiving the > Jim> access-accept message, are undefined." > > I thought the first paragraph was adequate, but expanded it somewhat. > Let me know how we're doing now. Yes this looks better. > > Jim> 4. Section 6.1 - I think this is correct. s/is always > Jim> authentic when present/is always authenticated when present/ If > Jim> I am wrong (which is possible) then I am not sure what the word > Jim> authentic is supposed to be. I don't think it currently makes > Jim> sense. The argument against the above is the following on > Jim> sentence which states that a new GSS-API mechanism may allow it > Jim> to be unauthenticated. > > Added hopeful clarity to this paragraph. Better > > Jim> 5. Section 6.1 - unclear if this is useful information or not. > Jim> Might want to say that for GSS-API-EAP, it is the same as > Jim> "urn:ietf:gss:radius-attribute TBD". > > I don't want to trod on draft-ietf-abfab-aaa-saml's toes. I understand that you don't want to trod on the SAML document. I might suggest that the following text be added instead. For the GSS-API mechanism this attribute is an alias for a RADIUS attribute, however it is recommended that this attribute name be used as other mechanism could transport the SAML statement by a different method that RADIUS. > > Jim> 6. Section 5 - the above note just nudged a new one. Does > Jim> there need to be a DIME attribute as the number space can be > Jim> larger. Perhaps just a comment to the effect that some DIME > Jim> space may not be reachable? > > If we want diameter support there does need to be an attribute. > We can define that in the diameter document if that ever happens. Sounds fine > > > Jim> 7. Section 6.2 -- Possible comment to be added. "If the > Jim> implementation does discard it, then processing the entire SAML > Jim> statement will result in a different answer than processing the > Jim> individual attributes." This might just be a security > Jim> considerations comment. > > OK. Nits: Abstract s\Authentication/Authorization/Accounting\Authentication/Authorization/Accou nting (AAA)\ s/Generic Security Services Application Programming interface/Generic Security Services Application Programming interface (GSS-API)/ Section 1. s\Authentication/Authorization/Accounting\Authentication/Authorization/Accou nting (AAA)\ Expand the EC in SAML EC Section 3. s/Attributes using the federated context/Attributes access by the federated context/ s/based on who is the subject of the name/based on authenticator part/ I this that it is backwards - you need to know who the authenticator is in order to know the semantics of the subject is. Section 5 s/specifations/specifications/ Section 6.1 s/some other mechanisms/other mechanism/ or /some other mechanism/ Section 7 s/mechanisms are/Mechanisms are/ Section 9 s/Sam hartman's/Sam Hartman's/ From stephen.farrell@cs.tcd.ie Mon Aug 27 02:27:52 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4409921F8495 for ; Mon, 27 Aug 2012 02:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3UEJ2Bh96DH for ; Mon, 27 Aug 2012 02:27:51 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 94B3E21F845C for ; Mon, 27 Aug 2012 02:27:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 793EC171474 for ; Mon, 27 Aug 2012 10:27:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1346059668; bh=/iPCBUKyv9gnbH HVoAz36is3T8ss2B3Ay0qMHf3YHPY=; b=wZdpD6Yu5dZYtauo1si2vBsWu0wa8A dDgwWDa82eHH0L+0T4RXKND37REBun6VWoeywo1Nag1DO3PM5q6q4xuEtETeE9Ir k4xbxxIUNlyYMWJykQ7JMrXKNgSZrqjP1VUyjN/ZSaFDIbl3nzZYbFDq+V8nvmYU cUSaT/fxrjlpwU0pimL2D+eebuIVpPyUSuJqm6vjXUNz68on4ynJwhgVDZ6VxIeV p1G8Yr5akUopvJ7DAG9ZhQ2YIA+Htxa0+/zgkq+Q7KrtjWIQtwlJ1om8AQraD3kA b2ujeWkcHr/KhFC7bZ+W9l3t9N0g4PfmMlG/kMTgEFfe/EhvemHdjQqA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id SJnC9a9iDBH4 for ; Mon, 27 Aug 2012 10:27:48 +0100 (IST) Received: from [IPv6:2001:770:10:203:71b6:750a:a60b:7188] (unknown [IPv6:2001:770:10:203:71b6:750a:a60b:7188]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 28317171473 for ; Mon, 27 Aug 2012 10:27:47 +0100 (IST) Message-ID: <503B3D94.8080606@cs.tcd.ie> Date: Mon, 27 Aug 2012 10:27:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "" References: <50229491.3010109@cs.tcd.ie> In-Reply-To: <50229491.3010109@cs.tcd.ie> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] usecases is done IETF LC X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Aug 2012 09:27:52 -0000 Hi, On 08/08/2012 05:32 PM, Stephen Farrell wrote: > > If that seems ok I'll mark this as revised ID > needed and then once we have that done I can > put it on a telechat agenda. (Next likely date > for that is Aug 30 so if the revision is done > by Aug 23 there'll be no added delay.) I see you did post the update but I didn't manage to put it on this week's telechat whilst I was on vacation (sorry about that). Its a little late to do that now so I've put it on the Sep 13th IESG telechat. Cheers, S. From leifj@sunet.se Tue Aug 28 04:02:43 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EAA11E8101 for ; Tue, 28 Aug 2012 04:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKiF+ScGG-en for ; Tue, 28 Aug 2012 04:02:43 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B595411E80F1 for ; Tue, 28 Aug 2012 04:02:42 -0700 (PDT) Received: from [109.105.104.220] (dhcp85.se-tug.nordu.net [109.105.104.220] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id q7SB2ben000548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Aug 2012 13:02:41 +0200 (CEST) Message-ID: <503CA54D.9030609@sunet.se> Date: Tue, 28 Aug 2012 13:02:37 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: "abfab@ietf.org" References: <503C9DF9.2010405@cs.tcd.ie> In-Reply-To: <503C9DF9.2010405@cs.tcd.ie> X-Enigmail-Version: 1.4.4 X-Forwarded-Message-Id: <503C9DF9.2010405@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Fwd: Approved: draft-ietf-abfab-gss-eap-09 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 11:02:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A milestone - our first core documents has been approved by the IESG and is on its way to the RFC editor. Thank you for all your hard work! - -------- Original Message -------- Subject: Approved: draft-ietf-abfab-gss-eap-09 Resent-Date: Tue, 28 Aug 2012 12:31:36 +0200 Resent-From: stephen.farrell@cs.tcd.ie Resent-To: hartmans-ietf@mit.edu, josh.howlett@ja.net, leifj@sunet.se, kwiereng@cisco.com Date: Tue, 28 Aug 2012 11:31:21 +0100 From: Stephen Farrell To: IESG , "abfab-chairs@tools.ietf.org" , draft-ietf-abfab-gss-eap@tools.ietf.org CC: The IESG Dear Secretariatish Folk: draft-ietf-abfab-gss-eap-09 is approved, there are no RFC editor notes. Please shuffle this one along, Thanks, Stephen. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlA8pUYACgkQ8Jx8FtbMZncqmACfZnRC0rpzCyS7ilNmqZmuiz66 rZQAni+26r00Z9WXqRD7Ml2AjgkrGd8Z =Qrg4 -----END PGP SIGNATURE----- From iesg-secretary@ietf.org Tue Aug 28 12:18:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542D321F84E4; Tue, 28 Aug 2012 12:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSDZ36ULSJmf; Tue, 28 Aug 2012 12:18:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C92421F8615; Tue, 28 Aug 2012 12:18:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120828191803.18125.58655.idtracker@ietfa.amsl.com> Date: Tue, 28 Aug 2012 12:18:03 -0700 Cc: abfab mailing list , abfab chair , RFC Editor Subject: [abfab] Protocol Action: 'A GSS-API Mechanism for the Extensible Authentication Protocol' to Proposed Standard (draft-ietf-abfab-gss-eap-09.txt) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 19:18:04 -0000 The IESG has approved the following document: - 'A GSS-API Mechanism for the Extensible Authentication Protocol' (draft-ietf-abfab-gss-eap-09.txt) as Proposed Standard This document is the product of the Application Bridging for Federated Access Beyond web Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap/ Technical Summary This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. Working Group Summary As "usual" with I-Ds with lots of technical content in the security area (especially true for GSS-related stuff) there are fewer reviews than one might want. This document is no better or worse than most in this respect. Sam Hartman (an author) had this concern during IETF LC that I'd like to check with the IESG to make sure we're ok with this document progressing now: "EAP (RFC 3748) has a applicability statement scoped very strictly to network access. This document provides a mechanism that falls well outside that applicability statement and permits the use of EAP for general application authentication. When ABFAB was chartered, there was a charter item to update the EAP applicability statement. I think A number of people in the room at the BOF, including myself, would have objected to the work being chartered had that charter item not been present. I think that work is important because I believe there are a number of important concerns that apply to the use of EAP for authentication beyond network access that need to be documented. Unfortunately, the technical specification has gotten ahead of the applicability statement update. I'm OK with that provided that we're still firmly committed to an applicability statement update. As part of approving this document now, I want to confirm that we have consensus at least within the ABFAB working group and the IESG to do that update. If there is any doubt I'd far prefer that this document be held until the applicability statement catches up." Document Quality There is one implementation (moonshot project) that spans multiple platforms. To our knowledge no other implementations exists or are planned. The one implementation has seen quite a bit of testing though expecially for the GSS-layer since lots of opensource applications have been modified to support ABFAB/GSS-EAP using moonshot. Personnel Leif Johansson is sheparding (co-chair) Stephen Farrell (AD)