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

"Joel M. Halpern" <jmh@joelhalpern.com> Thu, 05 October 2017 04:40 UTC

Return-Path: <jmh@joelhalpern.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 447291321DE; Wed, 4 Oct 2017 21:40:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=joelhalpern.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 eK78wVRIlVG8; Wed, 4 Oct 2017 21:40:41 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5D11321A0; Wed, 4 Oct 2017 21:40:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 7D97446DC89; Wed, 4 Oct 2017 21:40:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1507178441; bh=mEKNVSyD99hdO8hzz/+1RSMZSaTDG7k8csLGW5FPwEg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TnvT1e/3foGjKvQmIDgrjAnYUKs7YXv4/orWkyAsgk+ENyXkXj/NFKl6UJ+py2tbG k0swm7AmRZgZ2JHKcXEKhw26ogyN9o2IbohZa45AJ+FxjZFp2jiReLPqFOpO4+7Vbh Qw/2EYUE1UYNCfAXfJhsuRliQHXvBaOq9X0DYuso=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.225.209.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B7648467F1B; Wed, 4 Oct 2017 21:40:39 -0700 (PDT)
To: Uma Chunduri <uma.chunduri@huawei.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>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <d92f5bd7-8081-37bf-cefe-d19ba4a203e2@joelhalpern.com>
Date: Thu, 5 Oct 2017 00:40:38 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <25B4902B1192E84696414485F572685401A873A3@SJCEML701-CHM.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/2wAuk5-cxqT_YdHHHuNHeW9hBco>
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 04:40:43 -0000

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.
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), 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.

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.

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.
>