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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 10 October 2017 20:24 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 E3F8A1342F6; Tue, 10 Oct 2017 13:24:04 -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 DMxVUYlALi-s; Tue, 10 Oct 2017 13:24:00 -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 F201B1342F2; Tue, 10 Oct 2017 13:23:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 88654BE5B; Tue, 10 Oct 2017 21:23:57 +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 Kgqo_GmMYR0C; Tue, 10 Oct 2017 21:23:52 +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 80CF4BE56; Tue, 10 Oct 2017 21:23:52 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507667032; bh=98zgoMjn5PicbyKYPdFD7+HF3dPCbiWyFI6KQTggAxU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=zUPBA61WZPLOjRV6AyEWC4owq4cKyUn1VUoxsbYVgpXWm40bAp+NIy9sYx5jdbaXx B97of6wJdvzFjl7HYwiswuvJq6jSc0YVF1M0v1/5dnshFiLGx0JjUwL5hNJ8mwuBWv N1MihwoNQlQKKAIt+73jwGVw5UlUFmaQ+Z5gDang=
To: Robert Moskowitz <rgm-ietf@htt-consult.com>, ietf@ietf.org
Cc: ideas@ietf.org
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <c4157942-0cc9-06a0-3ef0-260feb7e14e3@htt-consult.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <acdda660-58bf-e8e1-320c-e13c5a7d6e46@cs.tcd.ie>
Date: Tue, 10 Oct 2017 21:23:51 +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: <c4157942-0cc9-06a0-3ef0-260feb7e14e3@htt-consult.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Dx2Sb595Hahsvoe28IBbVLr9fG75tJvUn"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/wM7uL9BGct2JWOWvNJCZSAnfY2g>
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: Tue, 10 Oct 2017 20:24:05 -0000

Hi Bob,

On 10/10/17 20:35, Robert Moskowitz wrote:
> Stephen, and others...
> 
> I am on Jewish Holidays since Sept 20th and I will finally be past them
> on Oct 16th.  I do have some time between the actual Holidays to see how
> far I have fallen behind.  That said, I will attempt to address a couple
> concerns here on the IETF list for the broader audience.
> 
> I am also concerned that some ID/Loc technologies seem to allow for PII
> to be enshrined in ID.  

"Enshrined in" isn't that clear to me (but I did say
"embedding" below which is just as bad:-). As we know,
long-lived identifiers that correlate with people can
be enough to cause problems, e.g. IMEIs and MS-ISDNs,
if exposed to other parts of the network.

> I have always been against that.  I have always
> seen a strictly one-way mapping that could take a human PII and find a
> ID for that.  Phone number lookup technologies based on LDAP have always
> supplied this.  Nothing new here, if done right. Human PII based ID
> should not be encouraged in this work, but is more the feature of an
> underlying ID/Loc technology (note, HIP does NOT do this).
> 
> Thus this is out of scope of IDEAS.  

I don't follow how the last statement follows from the
preceeding paragraph. I also saw nothing in the charter
or the use-cases draft or in the list archive to back
up that conclusion.

> And, as I am funded to work on
> IDEAS, I will vigorously work against anything that expands what we
> already have (and maybe get this out of in ID/Loc tech that has it).

Sure.

> 
> This is about machines, and processes, have ID/Loc through some
> underlying technology (e.g. HIP, ILA, LISP) to have a common ID
> discovery and Loc back to ID (for things like HTTP redirects).  

If that's the case, then there appears to be serious confusion
in the use-cases draft at least. And "identity" seems a fairly
mad term to pick if one means processes or devices, as it pretty
much guarantees raised hackles and confusion.

> As the
> charter says, strong access control will be designed in (but of course
> no assurance of implementing).  

I don't see such a statement in the -06 charter sorry.

> Note that HIP has a course access
> control in its RVS service in that an RVS COULD ignore a redirect from
> an Initiator nore registered to the RVS.  But we need finer grain access
> control and, well it is in the charter.
> 
> Why do this?  ID/Loc has a number of use cases, but is limited by the
> lack of discovery services (well, HIP can use DNS) and reverse discovery
> (but this is from Loc to get ID and only if authorized). We feel that
> adding in what we have learned limits ID/Loc will broaden its use.

TBH, I don't get the motivation here at all and I haven't
been enlightened by the discussion so far, nor from reading
the use-cases draft, but likely that's my fault.

Cheers,
S.


> 
> Bob
> 
> On 09/29/2017 02:31 PM, Stephen Farrell wrote:
>> As currently described, I oppose creation of this working
>> group on the basis that it enables and seemingly encourages
>> embedding identifiers for humans as addresses. Doing so
>> would have significant privacy downsides, would enable
>> new methods for censorship and discrimination, and could
>> be very hard to mitigate should one wish to help protect
>> people's privacy, as I think is current IETF policy.
>>
>> If the work precluded the use of any identifiers that
>> strongly map to humans then I'd be ok with it being done
>> as it'd then only be a waste of resources. But I don't
>> know how that could be enforced so I think it'd be better
>> to just not do this work at all.
>>
>> S.
>>
>> On 29/09/17 17:13, The IESG wrote:
>>> A new IETF WG has been proposed in the Routing Area. The IESG has not
>>> made
>>> any determination yet. The following draft charter was submitted, and is
>>> provided for informational purposes only. Please send your comments
>>> to the
>>> IESG mailing list (iesg@ietf.org) by 2017-10-09.
>>>
>>> IDentity Enabled Networks (ideas)
>>> -----------------------------------------------------------------------
>>> Current status: Proposed WG
>>>
>>> Chairs:
>>>    Padma Pillay-Esnault <padma.ietf@gmail.com>
>>>
>>> Assigned Area Director:
>>>    Alvaro Retana <aretana@cisco.com>
>>>
>>> Routing Area Directors:
>>>    Alia Atlas <akatlas@gmail.com>
>>>    Alvaro Retana <aretana@cisco.com>
>>>    Deborah Brungard <db3546@att.com>
>>>
>>> Mailing list:
>>>    Address: ideas@ietf.org
>>>    To subscribe: https://www.ietf.org/mailman/listinfo/ideas
>>>    Archive: https://mailarchive.ietf.org/arch/browse/ideas/
>>>
>>> Group page: https://datatracker.ietf.org/group/ideas/
>>>
>>> Charter: https://datatracker.ietf.org/doc/charter-ietf-ideas/
>>>
>>> Network solutions based on the concept of Identifier-Locator
>>> separation are
>>> increasingly considered to support mobility, overlay networking for
>>> virtualization and multi-homing across heterogeneous access networks.
>>> Identifier-locator separation protocols require infrastructure that
>>> allows
>>> nodes to discover the network topological location(s) of its peer(s) for
>>> packet delivery. A common infrastructure and protocol could be used by
>>> identifier/locator protocols as well as network virtualization. However,
>>> additional infrastructure and new protocol extensions are needed to
>>> address
>>> new requirements that go well beyond the traditional discovery
>>> service and
>>> mapping of identifier-to-location for packet delivery.
>>> Identifier-locator
>>> protocols are also useful for additional services involving dynamic
>>> association of a name to a set of network addresses - these include
>>> dynamic
>>> multicast, cloud service anycast and context-aware IoT queries.
>>>
>>> The IDEAS WG is chartered to produce a framework document that
>>> defines the
>>> expected behavior of a mapping system across the multiple existing
>>> use cases.
>>>   The framework will aim at a homogeneous behavior across use cases,
>>> and it
>>> will call out specific trade-offs that may be considered in the
>>> development
>>> of solutions.  We refer to the framework providing the set of
>>> services as
>>> Generic Identity Services (GRIDS).
>>>
>>> Some of the areas that must be considered when developing the framework
>>> include:
>>>
>>> - Description of interfaces for different protocols to interact with the
>>> framework (e.g. id-loc split protocols, management protocols, etc)
>>>
>>> - Description of identifier/locator mapping resolution and mapping
>>> update
>>> (e.g. discovery, pub/sub, multi-homing, ...)
>>>
>>> - Registration and lifecycle management of identities and their
>>> associated
>>> identifiers.
>>>
>>> - Identity authentication and authorization (e.g. access to
>>> framework, update
>>> of information for identifiers..)
>>>
>>> - Description of required basic network policies and policy
>>> enforcement needs
>>> (e.g. ability to look up an identifier-locator pair, permit forwarding
>>> traffic for particular endpoints on a per-identity basis, etc.)
>>>
>>> - Analysis of the concepts of identity-identifier split and dynamic
>>> identifier changes, including their implications on anonymity and
>>> privacy.
>>> Explicitly, the framework must define privacy requirements and how
>>> potential
>>> extensions/solutions should meet them.
>>>
>>> - Security analysis of the complete system, including authentication,
>>> authorization requirements and protection of any metadata.
>>>
>>> - Operational and deployment considerations
>>>
>>> The IDEAS WG will closely coordinate with the LISP and HIP WGs (and with
>>> others as needed) in order to keep them well-informed of the
>>> progress.  Any
>>> extension to existing protocols that is identified while developing the
>>> framework document will be carried out in the responsible WG for that
>>> protocol; any extension work to be done in this WG will require
>>> re-chartering.
>>>
>>> WG deliverables include:
>>>
>>> (1) Generic Identity Services Framework
>>>
>>> (2) Other WG sustaining/informational documents may include:
>>>
>>> - Problem statement
>>> - Use cases
>>> - Requirements for identifier/locator mapping and resolution
>>> - Requirements for identity authentication and authorization service
>>> (for
>>> GRIDS) - Applications of the architecture for use cases - Threat model
>>> document
>>>
>>> These documents will not be published as RFCs, but will be maintained
>>> in a
>>> draft form or on a collaborative Working Group wiki to support the
>>> efforts of
>>> the Working Group and help new comers.
>>>
>>> Milestones
>>>
>>> January 2018 Adopt WG draft for the Generic Identity Services framework
>>> July 2018 WGLC for the Generic Identity Services framework
>>> September 2018 Send Generic Identity Services framework draft to the
>>> IESG
>>> November 2018 Recharter or Close
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Ideas mailing list
>> Ideas@ietf.org
>> https://www.ietf.org/mailman/listinfo/ideas
> 
>