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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 8, 2017 at 11:20 AM, Padma Pillay-Esnault
<padma.ietf@xxxxxxxxx> wrote:
>
>
> On Sun, Oct 8, 2017 at 10:55 AM, S Moonesamy <sm+ietf@xxxxxxxxxxxx> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ideas
>




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]