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

Tom Herbert <tom@herbertland.com> Sun, 08 October 2017 18:48 UTC

Return-Path: <tom@herbertland.com>
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 4421B1321AC for <ideas@ietfa.amsl.com>; Sun, 8 Oct 2017 11:48:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 PhrCvhPvw4Lf for <ideas@ietfa.amsl.com>; Sun, 8 Oct 2017 11:48:03 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CE51348F3 for <ideas@ietf.org>; Sun, 8 Oct 2017 11:47:59 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id z50so34600084qtj.4 for <ideas@ietf.org>; Sun, 08 Oct 2017 11:47:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iF6Auw7hK6bJDxDy4BzW+tYnh9w5T12uaPnJrwBVXIQ=; b=yBZTuy4bChgu7Ml13pRGsJWXCNdzWaUq8TrvUy2R9ZKU+ObV2uqyo8gRngEjxnJmmy 3L0uHrz6+N0TvRQ8tTatgjtCfp0wquYOf9HZRRQfTtdrRf/a+Wq3Lt+qvR91cD3oRMuK bDlXIRSTnbcyUm7PF5AUrCpQ9nr//7z6VXDR2GUWa4+lAff8+qsOVT9DxYkIn+jMF+ky 4PARxqKARRaXJtxIgHYkZpoqtSuas0efsa0pCzlrf+y3FfFdU0LAdElfGLJ1iYDjLqQm V53eVJ1Z1MyrkzYcdAXhMOt8JooA4CE01lrPyNQFLIdhLlwvrsSUHMrttVXryowD6F7t iSuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iF6Auw7hK6bJDxDy4BzW+tYnh9w5T12uaPnJrwBVXIQ=; b=DJOy2iHZXCFek2lq3s43OG/glB2UwCyKgARjhPKUM/L+DTYTUjNNP7mwG0dkxNsj5l j5BBE8hfcT5ye7jjQHQHtfiP7PA8D41MNF5jIZYT8B9Ea+jkWpQwbwerJlxSt6OR2M/D jUtAQzW0zlngpBc4x48DSk2wNNc55tQsUfkrAQPG4A2bh4h4PilvJi8gUnOSm+CbzMFf SedfuL4eqqL0Au01kQsFYYVIjpun2f8kZ+qj0sedWEg9McukLCp0VqcvZvcSSsLOwZyX jSU3ZnCu1Wfkzzr/1m5TVT5STQ8H9rN8BkXUwpWbgZDWDmDfCishsawVnwP1aOuAKCGz WQow==
X-Gm-Message-State: AMCzsaXacNxdWPouDMHmTlQY3TIGehyh+dh1tFIcyS4kRe6WXQsAd7N+ +2AK80Zoou5azCVUEs/VENM4XYtplU7xrk+0UxfkpA==
X-Google-Smtp-Source: AOwi7QACLS3ZJGkNSV9d/Og+ZjwbhqkM4nbIKmL0k+cCyBxfwCXaUp2LxfOldar40RF4WBh6r8DQQ2Ons2Maapd1a90=
X-Received: by 10.200.43.140 with SMTP id m12mr11715049qtm.58.1507488478754; Sun, 08 Oct 2017 11:47:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.144 with HTTP; Sun, 8 Oct 2017 11:47:57 -0700 (PDT)
In-Reply-To: <CAG-CQxpEb8Lcjy0M5445K4Ob+nQW15WeEooggcxpb=hToB4HZw@mail.gmail.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <6.2.5.6.2.20171007163002.11c897a0@elandnews.com> <CAG-CQxpnHKtov+pj6YFL0wxnO3YX7mbLUA9uHUkVQbHqE3A1rQ@mail.gmail.com> <6.2.5.6.2.20171008102541.11499408@elandnews.com> <CAG-CQxpEb8Lcjy0M5445K4Ob+nQW15WeEooggcxpb=hToB4HZw@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sun, 8 Oct 2017 11:47:57 -0700
Message-ID: <CALx6S372+69EkycAJ_y6b_rJnMw3ncFEZzhVFyWsA+3GbxHaZA@mail.gmail.com>
To: Padma Pillay-Esnault <padma.ietf@gmail.com>
Cc: S Moonesamy <sm+ietf@elandsys.com>, ideas@ietf.org, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/NghKDl5lxFOr7ZaFeq_DBFOFRcY>
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: Sun, 08 Oct 2017 18:48:05 -0000

On Sun, Oct 8, 2017 at 11:20 AM, Padma Pillay-Esnault
<padma.ietf@gmail.com> wrote:
>
>
> On Sun, Oct 8, 2017 at 10:55 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:
>>
>> Hi Padma,
>> At 06:38 PM 07-10-2017, Padma Pillay-Esnault wrote:
>>>
>>> Not sure if you have been following the discussions the last few days and
>>> emails today.  The charter which is under review is not trying to create an
>>> embedded identifier to track users.
>>
>>
>> I caught up with the thread about this proposed working group.  The
>> (proposed) charter might say that it is not trying to create an embedded
>> identifier to track users.  What if that was a side effect of this work?
>
>
> I believe this has already been discussed on the thread. But here it is
> again, the id.loc protocols are in perspective here and they use ephemeral
> identifiers, can obsfuscate them or encrypt them as Dino pointed out
> earlier.
>
Padma,

I don't think ephemeral identifiers answer the underlying concern
here. Hosts can already get multiple addresses to use for obscuring
their identity without needing any additional work.

I think the concern is more around having a system that provides a
potentially public interface that maps identifiers, even ephemeral
ones, to an identity. When this is the identity of a end user device,
such as a phone, this becomes a system that does maps identifier to
user identities. This naturally leads to concerns about how to secure
such a system and how to prevent abuse of the information that goes
beyond the needs of connectivity. Both the proposed charter and the
related drafts are sketchy as to how the system can be secured and who
will be authorized to access the system.

Tom

> There is even text in the charter regarding this.
>
> - 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.
>
>
>>
>> I took a look at the ideas problem statement draft.  I can understand that
>> there may be a need for identification.  However, it is up to the companies
>> or 501(c)(3) status organizations to make their case for that.
>
>
> ?? Not sure what /how this is in context .... Are we still taking about
> routing information here?
>
>>
>>
>>
>> Will this proposed working group do any maintenance work on IPv4 technical
>> specifications?  Will the output of this proposed working group be used for
>> future work on IPv4 technical specifications?
>>
> Can you clarify what you mean here by maintenance work on IPv4 technical
> specification? Again the context here is a mapping system infrastructure to
> be used by Id/Loc protocols.
>
> Padma
>
>>>
>>> The draft in question is being updated and the authors are doing for
>>> clarification.
>>
>>
>> Ok.
>>
>> Regards,
>> S. Moonesamy
>
>
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>