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

Padma Pillay-Esnault <padma.ietf@gmail.com> Thu, 05 October 2017 06:58 UTC

Return-Path: <padma.ietf@gmail.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 25B5913454D; Wed, 4 Oct 2017 23:58:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Vh07oSpyXT8a; Wed, 4 Oct 2017 23:58:49 -0700 (PDT)
Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (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 54876134220; Wed, 4 Oct 2017 23:57:50 -0700 (PDT)
Received: by mail-wr0-x230.google.com with SMTP id p46so7678640wrb.0; Wed, 04 Oct 2017 23:57:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H53I9YjUoFVCaIUoyVLnpcRClC9YU/gGed3DVsFqiOU=; b=cPBTYYSfBmtbXuuwsO+J5T3zv7Wq2OYYZbwyX4YK2UlrYJm+ihT2eYZJlxLO1SgnbY XGiXrE3iIWwGGsPRtBupX2vuwE8kB4KXA5g5e5qp26zatiIAQVMW02eXiO6i1JbkSKs8 7eBRF2WHKTclMbZiSaPXhfvXWj5n/DROwEXyAlq1ssid6fW+lo94UorOVaaLMHupTYCj jW8EyiQ+VfxGBK1EXeUrZUU+SjgpH3J2nXgCbETmhIS6osULgz3KxrCotXSpLNpPvOZx 8sBSd8AtPuJom+wNV2Lpn9qVKsGzB5j3BiTyugp12ZZw5T7ZioSAuTdIF9t809ySsh9i KIag==
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=H53I9YjUoFVCaIUoyVLnpcRClC9YU/gGed3DVsFqiOU=; b=r9jtV0qwcogeOXPyypcp0I1QTkjc6fXgCQRPmPXnY/5j9cO2lPsFpM+e9JG2QjppVj PZsgI9HzyR3Uagp9swoYzDsRsU3mxaZmnSXGmPBnDBgmQkxEq1nb0WLcQbSjcc7T8dxm yVfgkUoGCHI809uSvjx38fsb0kXS/4x9jrSFtxO1rzVjmz80IlZUTT7fp0W/oRCpehrV xJvXk69Q2sCeLfRDuTPjlw6sZtCEuLpd+7isfq2AVa/O4XznKsketnWJAxgXFRPZM4aO j/TBWP3ZBjTLvTgN/b+Kxtp5GefxiN2WL+LoqWQA57YXSUWlZOJMmGyvqIQMX21YfmKc PuvA==
X-Gm-Message-State: AHPjjUgHw9B2HAOTa+AfG+UVlQV5/kiB7gmmJN/ghe1g4z6vWBe4wf+k 0h25gjHvbK63P1HUVuC0mYe9tU49ldhCSK8EvRY=
X-Google-Smtp-Source: AOwi7QAh3yoI3Qiu04JwRJlXBRW01tFAirbj6wfxUlIaUU+eFRBoyvd0fb9BkyZx3pD8yzT6bua0FvzK/DWjFaueAyU=
X-Received: by 10.223.199.15 with SMTP id k15mr22580368wrg.111.1507186668795; Wed, 04 Oct 2017 23:57:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.173.86 with HTTP; Wed, 4 Oct 2017 23:57:47 -0700 (PDT)
In-Reply-To: <d92f5bd7-8081-37bf-cefe-d19ba4a203e2@joelhalpern.com>
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>
From: Padma Pillay-Esnault <padma.ietf@gmail.com>
Date: Wed, 04 Oct 2017 23:57:47 -0700
Message-ID: <CAG-CQxp8EwehgsQksZcALGiChp=eEif6P68zAZ-2wydock9Ryg@mail.gmail.com>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: Uma Chunduri <uma.chunduri@huawei.com>, Benjamin Kaduk <kaduk@mit.edu>, Jari Arkko <jari.arkko@piuha.net>, "ideas@ietf.org" <ideas@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="089e0824490c00fb21055ac73ea5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/JnLX95b_cAfKsML5hFfxawKrEI4>
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: Thu, 05 Oct 2017 06:58:52 -0000

On Wed, Oct 4, 2017 at 9:40 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:

> 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.  The communication service provider has no role in creating or
> authenticating identifiers.  Their job is to provide locators.
>

<Padma> There is no disagreement in that the access provider role is to
provide locators.


> Now, those service providers may have an authentication relationship,
> based on some identifiers, in order to provide communications services.


<Padma> Again no disagreement that the access provider have an
authentication mechanism. An example would be  "A device connects to a
wifi, uses some authentication to get a locator."


> But the identifiers for that are completely uncoupled from and unrealted
> to the identifiers need for an ID / Locator system.
>

<Padma> Still in agreement with you here and this is like a
<wifiname,passwd> and has nothing to do with ID/LOC. I might also add that
this is orthogonal to the discussion. The access provider can be provider
of identifiers or not it would not have any bearing.


At this point, the device has a locator and next step is to update its
locator in the mapping system.



> Yes, if there is a provider of identifiers (not all systems even require
> that), 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.
>
> <Padma>

(1) The "appropriate relationship with the provider of identifier"  or what
you call the "user of the identifier" (for clarity - user is NOT a person)
is what in this context is called "identity". May be some people would
prefer some other term (pseudonym?) but let's stick to this one for the
moment.



Now regarding who can update the locators?

(2) There is agreement that there is a need for the "user of the
identifier" (again user is NOT a person)  to be authenticated to update the
locator of an Identifier.



(1) + (2)  actually shows de facto a relationship between "user of
identifier"(aka identity here)  and the "identifier".


This is all that what is formalized in this charter as the
identity-identifier relationship.


> But neither of those require anything other than the identifier and
> suitable keying.  I gave several examples of this in earlier emails to the
> list.
>
>
<Padma> Here is where we have some difference of opinion ...


Well depending on the functionalities, it might be that keying is not
sufficient or they may be alternatives to keying. As mentioned in the
thread earlier ... there are 2 operations with require some authentication
or access-control

- update

- lookup



Access control or "policies" on look up for one may be challenging using
keying. Some notions of closed user groups are interesting use cases and it
is worthwhile to evaluate other alternatives.


Now if we want an open system with no authentication for updates or lookups
and no close user group kind of features ... Then, as you said earlier not
all system require that and we do not need "user of identifier".

Precisely, this is why the identity concept is optional.

However it can be useful in some cases such as in enterprise space where
IoT devices may need finer access control.

Regards
Padma


> Yours,
> Joel
>
>
> On 10/4/17 11:24 PM, Uma Chunduri wrote:
>
>> Hi Joel,
>>
>>
>>         >Yes, authentication is necessary to modify the entries.
>> (Whether one should be authenticated before reading varies from case to
>> case.)
>>         >But authentication does not require a separate identity.
>> Exactly what it requires depends upon how the system is constructed.
>>
>> IMHO, provider based AUTH is needed in lot of cases if we really want to
>> build a solid system which enables mobility.
>> I responded to Jari, who is a pioneer and who helped spec out one of the
>> best AUTH methods  & systems successfully deployed ever with his
>> https://tools.ietf.org/html/rfc4187
>> (but he did it for another most successful SDO, with all constructs like
>> Pseudonyms and fast-re-auth-ids) didn't see the need for the same here.
>> May be as you indicated there is something missing in the charter that
>> didn't reflect the need.
>>
>> --
>> Uma C.
>>
>>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas
>