Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 06 October 2017 09:32 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B36A13487E; Fri, 6 Oct 2017 02:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUbpwdR7dDQq; Fri, 6 Oct 2017 02:32:22 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91BF13487D; Fri, 6 Oct 2017 02:32:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 21922BE24; Fri, 6 Oct 2017 10:32:20 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxCL7iKHtaAy; Fri, 6 Oct 2017 10:32:18 +0100 (IST)
Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49E30BE38; Fri, 6 Oct 2017 10:32:17 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507282337; bh=8neyMjmPuN9uOo+qlboyaUax4QCoJhr2aLzFQt0AIlY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UtdODxj52eSAN6WdofbX9W4jx0fPfMqKCI4ncBbWHkWwWVAe/dyNhWKQFe6mlAwh7 oiyzGfQcUnZo6m/pfSWnNjzPf9ExLnHKxOOj6cvJe6+B8buh+uQH0vdPK6ecP2QjQq XCUmnoKik8B4aTRFbR/DeXoWSmX5dn5dMisE+hno=
To: Georgios Karagiannis <georgios.karagiannis@huawei.com>, Uma Chunduri <uma.chunduri@huawei.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Benjamin Kaduk <kaduk@mit.edu>, Jari Arkko <jari.arkko@piuha.net>
Cc: "ideas@ietf.org" <ideas@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <D7D4AEE9-3BD0-4C8F-BCC6-7185AF7D37BA@netapp.com> <9C663B18-21CC-4A16-8B26-7994B12B1DC5@piuha.net> <25B4902B1192E84696414485F572685401A872DE@SJCEML701-CHM.china.huawei.com> <33f100a0-5114-269c-adb4-5db6edb1fd4d@joelhalpern.com> <20171005013730.GC96685@kduck.kaduk.org> <55bf5ae5-848a-ba81-f76b-14aaefdad2bf@joelhalpern.com> <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com> <d92f5bd7-8081-37bf-cefe-d19ba4a203e2@joelhalpern.com> <25B4902B1192E84696414485F572685401A8750D@SJCEML701-CHM.china.huawei.com> <C5034E44CD620A44971BAAEB372655DC2DD336ED@lhreml502-mbs>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <b801b130-b054-6874-1d04-8cd7b8200419@cs.tcd.ie>
Date: Fri, 6 Oct 2017 10:32:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <C5034E44CD620A44971BAAEB372655DC2DD336ED@lhreml502-mbs>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NoMbXAHSBFaRiUjdEtlIVKM7G4LXg8oIi"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/IobBZ_-TIQtpBUk5d3K0qp95g-U>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Oct 2017 09:32:29 -0000

Hiya,

On 06/10/17 08:49, Georgios Karagiannis wrote:
> Hi all,
> 
> Please note that I have looked into the output of the (concluded)
> IETF ABFAB WG. In order to answer many questions/concerns that have
> been raised during the previous IDEAS discussions, it might be useful
> to consider the results of the IETF ABFAB WG. 
> https://datatracker.ietf.org/wg/abfab/documents/
> 
> We could incorporate their concepts about identity and how identity
> can be established and leveraged in a distributed way able to satisfy
> trust and privacy concerns.

I have no clue how GSS-API is even relevant here. abfab
was a fine thing for JISC and friends to do to as a way
to try broaden the benefit they got from their existing
federated authentication setup, in their case involving
UK universities. It is not at all clear that that would
be even relevant if one wanted to build the kind of all
encompassing IdPs envisaged in the ideas charter/draft.
The relationships that university account holders have
with their own and other academic institutions and with
applications running in such environments (that being
the point of abfab) don't seem to me to generalise to
lower layers in any useful manner.

In any case, if this proposal is only now at the point
where you're starting to ponder the basic architecture
then I'd conclude it's nowhere near ready to charter.
(As well as being a bad idea from the privacy POV;-)

WGs for such decisions can be a good plan when there's
a few known architectural choices on the table, and if
different sets of folks need a venue to reach consensus
on which road to take - suggesting abfab at this point
sounds like floundering around looking for reasons to
exist tbh. (Sorry to be blunt and it may not be that,
but it appears to be that to me.)

S.


> 
> Best regards, Georgios
> 
> 
> -----Original Message----- From: Ideas
> [mailto:ideas-bounces@ietf.org] On Behalf Of Uma Chunduri Sent:
> Thursday, October 05, 2017 7:05 PM To: Joel M. Halpern; Benjamin
> Kaduk; Jari Arkko Cc: ideas@ietf.org; ietf@ietf.org Subject: Re:
> [Ideas] WG Review: IDentity Enabled Networks (ideas)
> 
> Hi Joel,
> 
> In-line [Uma]:
> 
> 
> Best Regards, -- Uma C.
> 
> -----Original Message----- From: Joel M. Halpern
> [mailto:jmh@joelhalpern.com] Sent: Wednesday, October 04, 2017 9:41
> PM To: Uma Chunduri <uma.chunduri@huawei.com>;; Benjamin Kaduk
> <kaduk@mit.edu>;; Jari Arkko <jari.arkko@piuha.net>; Cc:
> ideas@ietf.org; ietf@ietf.org Subject: Re: [Ideas] WG Review:
> IDentity Enabled Networks (ideas)
> 
> You seem to be making some unstated assumptions.
> 
> If by "Provider" in "Provider based AUTH" you mean the last hop
> communications service provider, then I would fundamentally disagree
> with you. [Uma]: I meant IdP and it's an orthogonal discussion if
> both roles played by same entity..
> 
> The communication service provider has no role in creating or
> authenticating identifiers.  Their job is to provide locators. [Uma]:
> Absolutely.
> 
> Now, those service providers may have an authentication relationship,
> based on some identifiers, in order to provide communications
> services. But the identifiers for that are completely uncoupled from
> and unrealted to the identifiers need for an ID / Locator system.
> 
> Yes, if there is a provider of identifiers (not all systems even
> require that),
> 
> [Uma]:  Yes, may be not all systems require that, especially if this
> is a local deployment.
> 
> then the user of the identifier needs to have an appropriate
> relationship with the provider of the identifier. And that needs to
> be related to the authentication needed to update the mapping
> system. [Uma]: Yes.
> 
> 
> But neither of those require anything other than the identifier and
> suitable keying. [Uma]: If it's a local system simple keying is
> enough (in the expense of key management etc) as all devices may be
> managed by the same org.
> 
> _______________________________________________ Ideas mailing list 
> Ideas@ietf.org https://www.ietf.org/mailman/listinfo/ideas
> 
>