Subject: Re: WG Review: IDentity Enabled Networks (ideas)

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Oct 2017 10:57:21 -0400

On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell <[email-masked]>
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.

​+1

I know how to restrict the work to 'meaningless' identifiers, require that
the identifiers be the output of a cryptographic algorithm.

​Now strictly speaking, this only limits scope to identifiers that are
indexical as opposed to rendering them meaningless but I think that was the
sense of it.

Nöth
<https://www.google.com/search?tbo=p&tbm=bks&q=inauthor:%22Winfried+N%C3%B6th%22>
proposed
a trichotemy of identifiers as follows

* Identity, the signifier is the signified (e.g. data: URI)

* Indexical, the signifier is related to the signified by a systematic
relationship, (e.g. ni URIs, SHA256Data), PGP fingerprints etc.)

* Names,  the signifier is the related to the signified by a purely
conventional relationship, (e.g. example.com to its owner)

There is a big difference between attempting to manage indexical signifiers
and names. Especially when the people trying to do so refuse to read any of
the literature on semiotics.

Names are problematic because the only way that a conventional relationship
can be implemented is through some sort of registration infrastructure and
we already have one of those and the industry that manages it has a
marketcap in the tens of billions.

Identifiers do lead to tractable solutions. But, this proposal looks a bit
unfocused for IRTF consideration, an IETF WG? Really?

I wrote this for the ename workshop and I think it shows that some of the
goals stated can be solved:
http://www.prismproof.org/Documents/draft-hallambaker-sin.html

But this is what my names look like:

[email-masked]
https://mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com/

They are both legal addresses fully compliant with the DNS etc specs. The
first won't resolve on the regular DNS, the second does but the embedded
security properties will only be enforced if the resolver understands the
mm-- prefix.

I can use these names to achieve content based routing of both static and
dynamic data. In the first case, the identifier is the fingerprint of the
content itself, in the second, the identifier is the fingerprint of a key
signing the content.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 4 Oct 2017 09:17:38 -0700

On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker
<[email-masked]> wrote:
> +1
> Now strictly speaking, this only limits scope to identifiers that are
> Nöth proposed a trichotemy of identifiers as follows
>
Identifiers are equivalent to addresses in that they indicate a node
in the network for the purposes of end to end communications. The only
difference between identifiers and addresses is that identifiers are
not topological. Virtual addresses in network virtualization are also
identifiers. So the security properties are the same when considering
privacy. For instance, if applications use temporary addresses for
privacy, it would have equivalent properties using temporary
identifiers. In fact from the application POV this would be
transparent. It could get a pool of apparently random addresses to
choose from as source of communication, it shouldn't know or even care
if the addresses are identifiers.

Identity is a completely separate concept from identifiers. Is not
required in any of the identifier/locator protocols and AFAIK none of
them even mention the term. There is no association of an identity of
user behind and identifier any more than there is an association of
identity behind IP address. The fact that the words "identifier" and
"identity" share a common prefix is an unfortunate happenstance :-).

Tom

---

From: [email-masked]
Date: Wed, 4 Oct 2017 16:34:41 +0000

> "identity" share a common prefix is an unfortunate happenstance :-).

Yes. But doesn't that mean either the name of this effort is wildly misleading or else the effort is hugely problematic from a privacy POV? Either way, istm this ought not proceed.

S.

---

From: John C Klensin <[email-masked]>
Date: Wed, 04 Oct 2017 12:57:55 -0400

IESG,

A comment somewhat orthogonal to whether this WG should be
chartered (I see the need, or at least the desire, but suspect
the current charter is badly structured to accomplish it).   It
may be that, with LISP (another IMO unfortunate name) and HIP
already out there, we are already obligated to do something like
this.

However, I strongly urge that, if the charter is accepted in
principle,  you move away from from acronyms that are likely to
create far more confusion than the desire for demonstrating
cleverness or cuteness can possibly be worth.  "ideas" itself is
an example.  It may be an an acronym that was cleverly matched
to the WG name (or vice versa) but it is also a word that
implies an entirely different meaning, one that is fairly
misleading relative to the intended WG's topic and more suited,
if it is suitable at all for a WG name, for something exploring
or brainstorming a much broader range of topics.  An
"[email-masked]" mailing list is particularly obnoxious in that
regard.

<sarcasm>If people really are trying to show off how clever they
can be with acronyms, how about taking the LISP precedent and
figuring out words that would match some other programming
language names?  For example, those who oppose this might like
COBOL or, more neutrally, SLIP (although that, of course,
describes another piece of networking protocol (see RFC 1055)). 
Or someone who dislikes this might advocate calling it The
Ultimate Routing Key Evolutionary Ysmmer group.
</sarcasm>
You get the idea -- if we want the IETF to be seen as a mature
and responsible body, we really don't need to go there.

"GRIDS" is as bad or worse, because "Grid" refers to a
well-known networking technology about which the IETF Stream has
published RFCs (See, e.g., RFC 6272).

Our job is supposed to be trying to make the Internet better.
It seems to me that creating confusion by side-effect of the
terminology we use does not advance that goal.

best,
    john

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 ([email-masked]) by 2017-10-09.
> 
> IDentity Enabled Networks (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).
>...

---

From: Tom Herbert <[email-masked]>
Date: Wed, 4 Oct 2017 10:07:11 -0700

> Yes. But doesn't that mean either the name of this effort is wildly misleading or else the effort is hugely problematic from a privacy POV? Either way, istm this ought not proceed.
Stephen,

There are two distinct efforts represented in IDEAS. One is a
developing a common identifier/locator mapping system and the other is
identity management. IMO the first is much more tangible and it's
clear this is needed given the emergence of id/loc use in data center,
mobile networks, as well as network virtualization. The identity
effort is less clear in terms of feasibility, privacy, and benefits--
there might be something there, but honestly it looks much more like a
research project to me at this point.

Tom

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 4 Oct 2017 18:48:03 +0000

There were a couple of things raised in the overall thread that I just wanted to quickly respond to:

Clearly privacy is an important issue and concern.  The current charter proposal includes a requirement for a detailed analysis of this aspect.  If this aspect needs to be expanded, sure, let's do this.  

Everyone seems to be jumping up and down regarding the use of the term of "identity" as if a foregone conclusion that this is a synonym for "privacy invasion".   However:
- "Identity" does not imply "personal identity".  Really, this is an identifier scheme for endpoints.   Perhaps even "identity" is a misnomer.  If you will, identity as conceived in the context of IDEAS is a second level of identifier that does not have to be exposed over the data plane
- Because of this, it may result in greater privacy than existing schemes, not less.  It enables you, for example, to obfuscate endpoints to outside observers as you wouldn't need to use personal unique long-lived identifiers, quite the contrary.  
 - There is also a security dimension here. If I am victim of a phishing attack because my network information (like today) is exposed to botnets, phishers etc who can hide from me (but not I from them) and remain anonymous or impersonate legitimate users, I do consider this a very serious threat also to my privacy.  How can IETF counteract such threats?  I think that IDEAS, if done right, can provide a contribution here.  

One aspect that has been missing from the discussion is the question whether there is a distinction between the network provider who provides GRIDS services and an outside attacker / observer.  I think this distinction is important.  The way I see it, if done right (sure, big "if", and requiring detailed analysis), IDEAS as I would envision it can contribute greatly to provide greater security and privacy from outside attackers.  At the same time, as it is currently envisioned, there clearly is a trust relationship between an entity and the provider of "its" GRIDS services.  The mapping database will have information about locator-identifier and identifier-identifier mappings, so GRIDS will know which identifiers its endpoints are using.  Clearly, if this trust is abused because the provider cannot be trusted, if you are concerned that it sells your endpoint’s information to the mob or a suppressive government, there is an issue.  However, when concerned about this scenario, it seems to me one would have equal reason to e.g. not trust your mobile service provider either, who can track you, knows your location, and has your customer data.  

--- Alex

> -----Original Message-----
> From: Ideas [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, October 04, 2017 9:35 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
> 
> 
> 
> > >> 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.
> > >
> > >
> > > +1
> > >
> > > I know how to restrict the work to 'meaningless' identifiers,
> > > require that the identifiers be the output of a cryptographic algorithm.
> > >
> > > Now strictly speaking, this only limits scope to identifiers that
> > > are indexical as opposed to rendering them meaningless but I think
> > > that was the sense of it.
> > >
> > >
> > > * Indexical, the signifier is related to the signified by a
> > > systematic relationship, (e.g. ni URIs, SHA256Data), PGP
> > > fingerprints etc.)
> > >
> > > There is a big difference between attempting to manage indexical
> > > signifiers and names. Especially when the people trying to do so
> > > refuse to read any of the literature on semiotics.
> > >
> > > Names are problematic because the only way that a conventional
> > > relationship can be implemented is through some sort of registration
> > > infrastructure and we already have one of those and the industry
> > > that manages it has a marketcap in the tens of billions.
> > >
> > > Identifiers do lead to tractable solutions. But, this proposal looks
> > > a bit unfocused for IRTF consideration, an IETF WG? Really?
> > >
> Yes. But doesn't that mean either the name of this effort is wildly misleading
> or else the effort is hugely problematic from a privacy POV? Either way, istm
> this ought not proceed.
> 
> S.
> 
> >
> > Tom
> >
> _______________________________________________
> Ideas mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ideas

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 4 Oct 2017 19:13:18 +0000

On 2017-9-29, at 11:31, Stephen Farrell <[email-masked]> wrote:
> group

+1, for the reasons below

Lars

> on the basis that it enables and seemingly encourages

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Oct 2017 20:45:09 +0100

Hiya,

TL;DR - I am now even more convinced that this ought not
go ahead. (Sorry;-)

On 04/10/17 19:48, Alexander Clemm wrote:
> Clearly privacy is an important issue and concern.  The current
> charter proposal includes a requirement for a detailed analysis of
> this aspect.  If this aspect needs to be expanded, sure, let's do
> this.

TBH, I don't think that'd help, for me at least. I don't
see any way in which such permanent strings representing
identity can be defined to be usable as claimed and not
be perniciously privacy invasive. So some promises to
ponder the problem in charter text wouldn't do it for
me. (And tbh, I've seen that can kicked down that road
before, so I'm skeptical of such promises in general.)

> Everyone seems to be jumping up and down regarding the use of the
> term of "identity" as if a foregone conclusion that this is a synonym
> for "privacy invasion".   However: - "Identity" does not imply
> "personal identity".  Really, this is an identifier scheme for
> endpoints.   

Sorry, what I assume is the relevant draft [1] says the "identity"
(denoted "IDy") is a "Unique and Permanent Identity" and that
"Networks may treat traffic differently depending on the IDy of
source or destination" and also seems to envisage a large logical
database of everyone's IDy's: "Identity also allows to have metadata
associated it to be applied, regardless of which IDf is used to
refer it." (Where IDf is the identifier that'll later be mapped
to a locator via, I assume, HIP or LISP or similar.)

I think it's entirely correct to jump up and down about the
privacy consequences of the above. (Not to mention the potential
censorship and discriminatory aspects.)

     [1] https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01

> Perhaps even "identity" is a misnomer.  

Well, it was presumably your choice (where your == some set of
the proponents). If that's a mistake, then it seems a fairly
fatal one - to get the name wrong for an effort all about mapping
names to identifiers;-)

> If you will,
> identity as conceived in the context of IDEAS is a second level of
> identifier that does not have to be exposed over the data plane -
> Because of this, it may result in greater privacy than existing
> schemes, not less. 

I see that argument in [1] but I'm not buying it tbh. To get
that level of protection from such an indirection, one would
have to have something like Tor hidden services and perhaps
one would have to *not* standardise the mapping from human
meaningful identifiers to those used as IDf, and esp. not the
reverse mapping. Defining that reverse mapping cannot but be
privacy invasive afaics. (There could maybe be ways to define
how an already hashed human meaningful identifier could then
be further hashed to become an IDy but I don't really see the
point of that at all, other than to just standardise something
for the fun of the process.)

> It enables you, for example, to obfuscate
> endpoints to outside observers as you wouldn't need to use personal
> unique long-lived identifiers, quite the contrary. - There is also a
> security dimension here. If I am victim of a phishing attack because
> my network information (like today) is exposed to botnets, 

(Nit: that says nothing about being a victim of, only of being
a target of, an attempted attack. Speaking of victims also
tends not to lead to more objective analysis, so I think it's
better to not go there unless it's relevant, which I don't
think is the case here, because...)

I don't understand what network information you mean. If you
mean email addresses, and are proposing that the email ecosystem
change to use some IDf or LOC values, that doesn't seem at all
realistic to me. If you don't mean email addresses then I don't
see how any lower layer change will affect attempted phishes.
The routing area is probably also the entirely wrong venue for
any real anti-phishing effort.

That really wasn't a good example;-)

> phishers
> etc who can hide from me (but not I from them) and remain anonymous
> or impersonate legitimate users, I do consider this a very serious
> threat also to my privacy.  How can IETF counteract such threats?  I
> think that IDEAS, if done right, can provide a contribution here.

I don't see that at all. Unless I'm mistaken that seems like
wishful thinking to me.

> 
> One aspect that has been missing from the discussion is the question
> whether there is a distinction between the network provider who
> provides GRIDS services and an outside attacker / observer.  I think
> this distinction is important.  The way I see it, if done right
> (sure, big "if", and requiring detailed analysis), IDEAS as I would
> envision it can contribute greatly to provide greater security and
> privacy from outside attackers.  At the same time, as it is currently
> envisioned, there clearly is a trust relationship between an entity
> and the provider of "its" GRIDS services.  The mapping database will
> have information about locator-identifier and identifier-identifier
> mappings, so GRIDS will know which identifiers its endpoints are
> using.  Clearly, if this trust is abused because the provider cannot
> be trusted, if you are concerned that it sells your endpointâ€™s
> information to the mob or a suppressive government, there is an
> issue.  However, when concerned about this scenario, it seems to me
> one would have equal reason to e.g. not trust your mobile service
> provider either, who can track you, knows your location, and has your
> customer data.

ISTM that introducing that GRIDS thing makes matters worse and not
better, because, as you yourself say, it is clear that whoever has
access to the GRIDS information would be better able to track people
compared to now.

I would prefer to see fewer long lived identifiers in networking
and not more, and this proposal introduces more long lived identifiers
(erroneously calling those identities).

Regardless of what one thinks of them, given that things like
HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit
adding this extra layer of indirection with a privacy invasive
"Unique and Permanent" identifier which seems to be the only
non-overlapping part of this work - in fact I only see downsides.

Cheers,
S.

> 
> --- Alex
> 
> 
>> -----Original Message----- From: Ideas
>> [mailto:[email-masked]] On Behalf Of 
>> [email-masked] Sent: Wednesday, October 04, 2017 9:35
>> AM To: [email-masked] Cc: [email-masked];
>> [email-masked]; [email-masked] Subject: Re: [Ideas] WG
>> Review: IDentity Enabled Networks (ideas)
>> 
>> 
>> 
>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell 
>>>> <[email-masked]> wrote:
>>>>> 
>>>>> 
>>>>> 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.
>>>>> 
>>>>> 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.
>>>> 
>>>> 
>>>> +1
>>>> 
>>>> Now strictly speaking, this only limits scope to identifiers
>>>> that are indexical as opposed to rendering them meaningless but
>>>> I think that was the sense of it.
>>>> 
>>>> 
>>>> NÃ¶th proposed a trichotemy of identifiers as follows
>>>> 
>>>> * Names,  the signifier is the related to the signified by a
>>>> purely conventional relationship, (e.g. example.com to its
>>>> owner)
>>>> 
>>>> 
>>>> There is a big difference between attempting to manage
>>>> indexical signifiers and names. Especially when the people
>>>> trying to do so refuse to read any of the literature on
>>>> semiotics.
>>>> 
>>>> relationship can be implemented is through some sort of
>>>> registration infrastructure and we already have one of those
>>>> and the industry that manages it has a marketcap in the tens of
>>>> billions.
>>>> 
>>>> Identifiers do lead to tractable solutions. But, this proposal
>>>> looks a bit unfocused for IRTF consideration, an IETF WG?
>>>> Really?
>>>> 
>>> Identifiers are equivalent to addresses in that they indicate a
>>> node in the network for the purposes of end to end
>>> communications. The only difference between identifiers and
>>> addresses is that identifiers are not topological. Virtual
>>> addresses in network virtualization are also identifiers. So the
>>> security properties are the same when considering privacy. For
>>> instance, if applications use temporary addresses for privacy, it
>>> would have equivalent properties using temporary identifiers. In
>>> fact from the application POV this would be transparent. It could
>>> get a pool of apparently random addresses to choose from as
>>> source of communication, it shouldn't know or even care if the
>>> addresses are identifiers.
>>> 
>>> Identity is a completely separate concept from identifiers. Is
>>> not required in any of the identifier/locator protocols and AFAIK
>>> none of them even mention the term. There is no association of an
>>> identity of user behind and identifier any more than there is an
>>> association of identity behind IP address. The fact that the
>>> words "identifier" and "identity" share a common prefix is an
>>> unfortunate happenstance :-).
>> 
>> 
>> Yes. But doesn't that mean either the name of this effort is wildly
>> misleading or else the effort is hugely problematic from a privacy
>> POV? Either way, istm this ought not proceed.
>> 
>> S.
>> 
>>> 
>>> Tom
>>> 
>> _______________________________________________ Ideas mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/ideas

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Oct 2017 13:35:32 -0700

Adding [email-masked] to cc list.

How about creating a working group that solely focuses on deployment of a mapping system and does not specify how and where identifiers are allocated?

I have made suggestions before that such a working group should be in the ops area. Some examples include and are not limited to v6ops, dnsop, and mboned.

Cheers,
Dino

> On Oct 4, 2017, at 12:45 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Oct 2017 21:46:41 +0100

Hi Dino,

On 04/10/17 21:35, Dino Farinacci wrote:
> How about creating a working group that solely focuses on deployment
> of a mapping system and does not specify how and where identifiers
> are allocated?
> 
> I have made suggestions before that such a working group should be in
> the ops area. Some examples include and are not limited to v6ops,
> dnsop, and mboned.

If there's deployment of things like LISP and HIP and folks
are interested in discussing/documenting what they've been
doing in the ops area then that seems quite reasonable sure.

S.

> Cheers, Dino
>> TL;DR - I am now even more convinced that this ought not go ahead.
>> (Sorry;-)
>> 
>>> charter proposal includes a requirement for a detailed analysis
>>> of this aspect.  If this aspect needs to be expanded, sure, let's
>>> do this.
>> 
>> TBH, I don't think that'd help, for me at least. I don't see any
>> way in which such permanent strings representing identity can be
>> defined to be usable as claimed and not be perniciously privacy
>> invasive. So some promises to ponder the problem in charter text
>> wouldn't do it for me. (And tbh, I've seen that can kicked down
>> that road before, so I'm skeptical of such promises in general.)
>> 
>>> Everyone seems to be jumping up and down regarding the use of
>>> the term of "identity" as if a foregone conclusion that this is a
>>> synonym for "privacy invasion".   However: - "Identity" does not
>>> imply "personal identity".  Really, this is an identifier scheme
>>> for endpoints.
>> 
>> database of everyone's IDy's: "Identity also allows to have
>> metadata associated it to be applied, regardless of which IDf is
>> used to refer it." (Where IDf is the identifier that'll later be
>> mapped to a locator via, I assume, HIP or LISP or similar.)
>> 
>> I think it's entirely correct to jump up and down about the privacy
>> consequences of the above. (Not to mention the potential censorship
>> and discriminatory aspects.)
>> 
>> [1]
>> https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01
>> 
>> Well, it was presumably your choice (where your == some set of the
>> proponents). If that's a mistake, then it seems a fairly fatal one
>> - to get the name wrong for an effort all about mapping names to
>> identifiers;-)
>> 
>>> If you will, identity as conceived in the context of IDEAS is a
>>> second level of identifier that does not have to be exposed over
>>> the data plane - Because of this, it may result in greater
>>> privacy than existing schemes, not less.
>> 
>> I see that argument in [1] but I'm not buying it tbh. To get that
>> level of protection from such an indirection, one would have to
>> have something like Tor hidden services and perhaps one would have
>> to *not* standardise the mapping from human meaningful identifiers
>> to those used as IDf, and esp. not the reverse mapping. Defining
>> that reverse mapping cannot but be privacy invasive afaics. (There
>> could maybe be ways to define how an already hashed human
>> meaningful identifier could then be further hashed to become an IDy
>> but I don't really see the point of that at all, other than to just
>> standardise something for the fun of the process.)
>> 
>>> It enables you, for example, to obfuscate endpoints to outside
>>> observers as you wouldn't need to use personal unique long-lived
>>> identifiers, quite the contrary. - There is also a security
>>> dimension here. If I am victim of a phishing attack because my
>>> network information (like today) is exposed to botnets,
>> 
>> (Nit: that says nothing about being a victim of, only of being a
>> target of, an attempted attack. Speaking of victims also tends not
>> to lead to more objective analysis, so I think it's better to not
>> go there unless it's relevant, which I don't think is the case
>> here, because...)
>> 
>> I don't understand what network information you mean. If you mean
>> email addresses, and are proposing that the email ecosystem change
>> to use some IDf or LOC values, that doesn't seem at all realistic
>> to me. If you don't mean email addresses then I don't see how any
>> lower layer change will affect attempted phishes. The routing area
>> is probably also the entirely wrong venue for any real
>> anti-phishing effort.
>> 
>>> phishers etc who can hide from me (but not I from them) and
>>> remain anonymous or impersonate legitimate users, I do consider
>>> this a very serious threat also to my privacy.  How can IETF
>>> counteract such threats?  I think that IDEAS, if done right, can
>>> provide a contribution here.
>> 
>>> One aspect that has been missing from the discussion is the
>>> question whether there is a distinction between the network
>>> provider who provides GRIDS services and an outside attacker /
>>> observer.  I think this distinction is important.  The way I see
>>> it, if done right (sure, big "if", and requiring detailed
>>> analysis), IDEAS as I would envision it can contribute greatly to
>>> provide greater security and privacy from outside attackers.  At
>>> the same time, as it is currently envisioned, there clearly is a
>>> trust relationship between an entity and the provider of "its"
>>> GRIDS services.  The mapping database will have information about
>>> locator-identifier and identifier-identifier mappings, so GRIDS
>>> will know which identifiers its endpoints are using.  Clearly, if
>>> this trust is abused because the provider cannot be trusted, if
>>> you are concerned that it sells your endpointâ€™s information to
>>> the mob or a suppressive government, there is an issue.  However,
>>> when concerned about this scenario, it seems to me one would have
>>> equal reason to e.g. not trust your mobile service provider
>>> either, who can track you, knows your location, and has your 
>>> customer data.
>> 
>> access to the GRIDS information would be better able to track
>> people compared to now.
>> 
>> and not more, and this proposal introduces more long lived
>> identifiers (erroneously calling those identities).
>> 
>> Regardless of what one thinks of them, given that things like HIP
>> and LISP exist, and try tackle the ID/LOC split, I see no benefit 
>> Cheers, S.
>>>> [email-masked] Sent: Wednesday, October 04, 2017
>>>> 9:35 AM To: [email-masked] Cc: [email-masked]; 
>>>>>>> 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.
>>>>>>> 
>>>>>> I know how to restrict the work to 'meaningless'
>>>>>> identifiers, require that the identifiers be the output of
>>>>>> a cryptographic algorithm.
>>>>>> 
>>>>>> Now strictly speaking, this only limits scope to
>>>>>> identifiers that are indexical as opposed to rendering them
>>>>>> meaningless but I think that was the sense of it.
>>>>>> 
>>>>>> 
>>>>>> * Names,  the signifier is the related to the signified by
>>>>>> a purely conventional relationship, (e.g. example.com to
>>>>>> its owner)
>>>>>> 
>>>>>> 
>>>>>> Names are problematic because the only way that a
>>>>>> conventional relationship can be implemented is through
>>>>>> some sort of registration infrastructure and we already
>>>>>> have one of those and the industry that manages it has a
>>>>>> Identifiers do lead to tractable solutions. But, this
>>>>>> proposal looks a bit unfocused for IRTF consideration, an
>>>>>> IETF WG? Really?
>>>>>> 
>>>>> Identifiers are equivalent to addresses in that they indicate
>>>>> a node in the network for the purposes of end to end 
>>>>> addresses in network virtualization are also identifiers. So
>>>>> the security properties are the same when considering
>>>>> privacy. For instance, if applications use temporary
>>>>> addresses for privacy, it would have equivalent properties
>>>>> using temporary identifiers. In fact from the application POV
>>>>> this would be transparent. It could get a pool of apparently
>>>>> random addresses to choose from as source of communication,
>>>>> it shouldn't know or even care if the addresses are
>>>>> identifiers.
>>>>> 
>>>>> Identity is a completely separate concept from identifiers.
>>>>> Is not required in any of the identifier/locator protocols
>>>>> and AFAIK none of them even mention the term. There is no
>>>>> association of an identity of user behind and identifier any
>>>>> more than there is an association of identity behind IP
>>>>> address. The fact that the words "identifier" and "identity"
>>>>> share a common prefix is an unfortunate happenstance :-).
>>>> 
>>>> 
>>>> Yes. But doesn't that mean either the name of this effort is
>>>> wildly misleading or else the effort is hugely problematic from
>>>> a privacy POV? Either way, istm this ought not proceed.
>>>> 
>>>> S.
>>>> 
>>>>> 
>>>>> Tom
>>>>> 
>>>> _______________________________________________ Ideas mailing
>>>> list [email-masked]

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 4 Oct 2017 21:26:05 +0000

Hi Stephen,

                > .. information would be better able to track people compared to now.

This is not about people..

	>Regardless of what one thinks of them, given that things like HIP and LISP exist, and try tackle the ID/LOC split, I see no benefit adding this extra layer of indirection with a privacy invasive "Unique and Permanent" identifier
                >which seems to be the only non-overlapping part of this work - in fact I only see downsides.

FWIW,
This is also to enable security and access restrictions to the new breed of devices on the network (IoT or other mobility  nodes). Just because of the fact that they are on the network with an address they should not be allowed to be accessible. 
Authentication with a trusted IdP would enable establishing the type of the type of device, which then allows group based policies to be enforceable (a V2X node can talk to only same kind of node or a particular IoT can be accessed by only particular device). 
As discussed earlier in the list perhaps https://tools.ietf.org/wg/abfab/ can be looked into build this federated system in the architecture document.
I also see you are arguing(unfortunately)  against your https://tools.ietf.org/html/rfc7258 document, where this can be one more potential mitigation tool w.r.t device anonymity (apart from encrypt everything/TCPINC - which serves a different and important purpose for content privacy w.r.t monitoring).

I don't see a fully functional mapping system without any authentication into the system by the device/node for the mapping. This has been always the case in the cellular world and it seems we are all okay with it and today it's 80+% of the total traffic.
 It would be great if you can suggest which can meet this objective in more balanced way...

--
Uma C.

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Wed, 4 Oct 2017 21:39:03 +0000

Thank you for voicing your concerns 
"on the basis that it enables and seemingly encourages embedding  identifiers for humans as addresses"

This is not the objective or in the charter of this wg as you point out this would be against the policy.
Perhaps this can be made clearer in the charter - this is about machines and processes.

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

Well it really depends in which context this work is being used.
Looking at some of the postings, it seems that adding more context on the problem space would help to bring more clarity on the charter.

Padma 

> > From: Ideas [mailto:[email-masked]] On Behalf Of Eggert, 
> > Lars
> > Sent: Wednesday, October 04, 2017 12:13 PM
> > To: Stephen Farrell <[email-masked]>
> > Cc: [email-masked]; [email-masked]
> > > As currently described, I oppose creation of this working group
> >
> > > on the basis that it enables and seemingly encourages embedding 
> > > should one wish to help protect people's privacy, as I think is current IETF policy.
> > >

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Wednesday, October 04, 2017 10:07 AM
To: Stephen Farrell <[email-masked]>
Cc: [email-masked]; Phillip Hallam-Baker <[email-masked]>; IETF-Discussion <[email-masked]>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

On Wed, Oct 4, 2017 at 9:34 AM,  <[email-masked]> wrote:
>> > registration infrastructure and we already have one of those and 
>> > the industry that manages it has a marketcap in the tens of billions.
>> >
>> > looks a bit unfocused for IRTF consideration, an IETF WG? Really?
>> >
>> in the network for the purposes of end to end communications. The 
>> only difference between identifiers and addresses is that identifiers 
>> are not topological. Virtual addresses in network virtualization are 
>> also identifiers. So the security properties are the same when 
>> considering privacy. For instance, if applications use temporary 
>> addresses for privacy, it would have equivalent properties using 
>> temporary identifiers. In fact from the application POV this would be 
>> choose from as source of communication, it shouldn't know or even 
>> care if the addresses are identifiers.
>>
Stephen,

There are two distinct efforts represented in IDEAS. One is a developing a common identifier/locator mapping system and the other is identity management. IMO the first is much more tangible and it's clear this is needed given the emergence of id/loc use in data center, mobile networks, as well as network virtualization. The identity effort is less clear in terms of feasibility, privacy, and benefits-- there might be something there, but honestly it looks much more like a research project to me at this point.

Tom

---

From: Jari Arkko <[email-masked]>
Date: Thu, 5 Oct 2017 00:41:47 +0300

I was a bit surprised to see this come out of the IESG for 
review, given that we had fairly serious discussions about the
problems of the proposed approaches at the BOF, but I see little 
attention on those issues in the charter.

But, to state my opinion about working group being created with this
charter, I have comments from two directions.

First, from the point of view of “do we need this” or “do I need this”,
I’m a “meh”. If the HIP and LISP folk and everyone else were
screaming for this, and we had enough deployment that we saw the 
issues that the charter proposes, then sure. Not sure that’s case.

Secondly, I’m have similar concerns to Christian, Lars, Stephen and others.
More specifically, at the BOF the goal seemed to be creation of infrastructures
to manage and track identities, and to bind them to entities that assigned
them. I am not at all sure that’s a desirable direction. And the charter
says little about the assumptions behind the work.

To expand a bit on these concerns, the proposed work doesn’t consider
at all the types of identifier operations that work on ephemeral identities
(e.g., HIP, MP-TCP). It would be sad if we created systems that
forced us to manage identifiers from some infrastructure when all
we needed to do in a particular case was “prove that you are the
same entity as in the other connection”, which can be done e2e and
requires no infrastructure, or permanent identifiers.

The charter text also mentions “identifier changes” in what feels
like a special case for what I would think is rather the default.

I find concept of firewalls checking identity troublesome.

Now, I’m not opposed to creating a working group in the IETF in this
area, and to support various infrastructure needs of say mobility or
multihoming or anycast protoocols, but if we do it, we need to do
it right. Dino’s suggestion of mapping systems without the manage/
create aspect might be one potential useful direction. Another
way to think about this space is to consider nodes to have autonomy
in how they manage and create their identities, when they reveal
or do not reveal identities. Then we could ask what
helpful tasks might an infrastructure provide on top of that, e.g., 
mapping services or forwarding agent type designs.

Jari

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Oct 2017 17:43:12 -0400

I see different people providing different descriptions of why this is 
being proposed.
I do not see a clear problem statement.
As such, it is not even clear to me that this is "a" working group.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Oct 2017 10:56:48 +1300

> How about creating a working group that solely focuses on deployment of a mapping system and does not specify how and where identifiers are allocated?

That seems reasonable, well defined and relatively uncontentious.

The current proposed charter leaves me a bit puzzled. Firstly I agree
that the name 'IDEAS' is misleading, and 'GRIDS' tramples on previous work,
and 'identity' is a red flag. But if we get past terminology distractions,
where's the meat? All the interesting stuff is relegated to drafts or a
wiki, and the output is a 'framework'. The IETF has a very mixed record
with 'framework' documents.

    Brian

> .

---

From: Tom Herbert <[email-masked]>
Date: Wed, 4 Oct 2017 15:32:11 -0700

On Oct 4, 2017 1:35 PM, "Dino Farinacci" <[email-masked]> wrote:

How about creating a working group that solely focuses on deployment of a
mapping system and does not specify how and where identifiers are allocated?

+1

I suggest that could be called idloc (for Identifier-Locator)

Tom

I have made suggestions before that such a working group should be in the
ops area. Some examples include and are not limited to v6ops, dnsop, and
mboned.

Cheers,
Dino

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 4 Oct 2017 22:34:03 +0000

Hi Stephen,
Just a couple of responses inline, <ALEX>  (at the risk of making your opposition even stronger;-)
--- Alex

> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Wednesday, October 04, 2017 12:45 PM
> To: Alexander Clemm <[email-masked]>;
> [email-masked]
> TL;DR - I am now even more convinced that this ought not go ahead. (Sorry;-)
> 
> TBH, I don't think that'd help, for me at least. I don't see any way in which
> such permanent strings representing identity can be defined to be usable as
> claimed and not be perniciously privacy invasive. So some promises to
> ponder the problem in charter text wouldn't do it for me. (And tbh, I've seen
> that can kicked down that road before, so I'm skeptical of such promises in
> general.)
> 
> > Everyone seems to be jumping up and down regarding the use of the term
> > of "identity" as if a foregone conclusion that this is a synonym
> (denoted "IDy") is a "Unique and Permanent Identity" and that "Networks
> may treat traffic differently depending on the IDy of source or destination"
> and also seems to envisage a large logical database of everyone's IDy's:
> "Identity also allows to have metadata associated it to be applied, regardless
> of which IDf is used to refer it." (Where IDf is the identifier that'll later be

<ALEX> The intent is to distinguish between how you would be identified through a private/secured/authenticated control plane (which is the longer-lived "anchor" identifier) vs out in the open (shorter-lived identifiers for use on the data plane that provider greater anonymization, making it more difficult to track users by outside observers).  The assumption is that a distinction can be made between outside 3rd party observer vs provider of the GRIDS services. 

I guess a big part of the controversy and your reaction comes from the statement "Networks may treat traffic differently depending on IDy of source or destination".  I can see that this is something that needs to be reframed. The item of concern here concerns scenarios like that as a user, I might want to be able to define access rules who can contact me much like frequently done using firewall rules.  For example, no Webcams/IoT devices (part of the metadata) should contact me.  Rather than putting the onus on my end device to try and block illegitimate traffic and exposing me to DoS attacks or worse, I might want to be able to articulate a policy to that effect and ask GRIDS to not provide my locator information to e.g. a Mirai-controlled Webcam.  One question is whether we would want policies to be articulated that refer to specific identifiers.  If we were to allow such a thing, the question about how to maintain such rules immediately comes up - given identfiers are anonymized and fast changing, what sense would it make to even try to articulate such a rule?  Here it would make sense to articulate a rule along the lines of "apply this rule to the entity that the identifier refers to".   

You can disagree with this, but this is just to provide some explanation regarding background.  I don’t think these are illegitimate concerns.  So, how can we frame things accordingly?  
</ALEX>

> consequences of the above. (Not to mention the potential censorship and
> discriminatory aspects.)
> 
> proponents). If that's a mistake, then it seems a fairly fatal one - to get the
> name wrong for an effort all about mapping names to identifiers;-)

<ALEX> Again, not identity is exposed on the data plane.  What term would you suggest?   </ALEX> 

> I see that argument in [1] but I'm not buying it tbh. To get that level of
> protection from such an indirection, one would have to have something like
> Tor hidden services and perhaps one would have to *not* standardise the
> mapping from human meaningful identifiers to those used as IDf, and esp.
> not the reverse mapping. Defining that reverse mapping cannot but be
> privacy invasive afaics. (There could maybe be ways to define how an already
> hashed human meaningful identifier could then be further hashed to
> become an IDy but I don't really see the point of that at all, other than to just

<ALEX> Are you arguing against the problem statement of the particular solution?   
</ALEX>

> > identifiers, quite the contrary. - There is also a security dimension
> > here. If I am victim of a phishing attack because my network
> > information (like today) is exposed to botnets,
> 
> (Nit: that says nothing about being a victim of, only of being a target of, an
> attempted attack. Speaking of victims also tends not to lead to more
> objective analysis, so I think it's better to not go there unless it's relevant,
> which I don't think is the case here, because...)

<ALEX> I was using the term "I" as a figure of speech.  I am not speaking as a victim here.  As a target, sure.    
</ALEX>

> 
> I don't understand what network information you mean. If you mean email
> addresses, and are proposing that the email ecosystem change to use some
> IDf or LOC values, that doesn't seem at all realistic to me. If you don't mean
> email addresses then I don't see how any lower layer change will affect
> attempted phishes.
> The routing area is probably also the entirely wrong venue for any real anti-
> phishing effort.
> 

<ALEX> I am referring to locator information.  To phish me, someone needs to obtain my locator. 
I am concerned about privacy.  Do I have a right to privacy for my locator information?  
</ALEX>

> 
> > phishers
> > etc who can hide from me (but not I from them) and remain anonymous or
> > impersonate legitimate users, I do consider this a very serious threat
> > also to my privacy.  How can IETF counteract such threats?  I think
> > that IDEAS, if done right, can provide a contribution here.
> 
> I don't see that at all. Unless I'm mistaken that seems like wishful thinking to
> me.

<ALEX> Maybe it is wishful, but I do think that these treats are real and that it is not dishonorable to try to counteract them.  Just like threats on privacy (a big concern on this thread) are real and need to be counteracted; I completely agree with this by the way but do believe we have to strike a balance with security.  </ALEX>

> > this distinction is important.  The way I see it, if done right (sure,
> > big "if", and requiring detailed analysis), IDEAS as I would envision
> > it can contribute greatly to provide greater security and privacy from
> > outside attackers.  At the same time, as it is currently envisioned,
> > there clearly is a trust relationship between an entity and the
> > provider of "its" GRIDS services.  The mapping database will have
> > information about locator-identifier and identifier-identifier
> > information to the mob or a suppressive government, there is an issue.
> > However, when concerned about this scenario, it seems to me one would
> > have equal reason to e.g. not trust your mobile service provider
> > either, who can track you, knows your location, and has your customer
> > data.
> 
> ISTM that introducing that GRIDS thing makes matters worse and not better,
> because, as you yourself say, it is clear that whoever has access to the GRIDS
> information would be better able to track people compared to now.
> 
> I would prefer to see fewer long lived identifiers in networking and not
> more, and this proposal introduces more long lived identifiers (erroneously
> calling those identities).

<ALEX> See above.  I really believe this will result in fewer long-lived identifiers used in the data plane.  That this would somehow mandate long-lived person-identifying identifiers on the data plane is a misconception. 
(end of my comments)
</ALEX>

> 
> Regardless of what one thinks of them, given that things like HIP and LISP
> exist, and try tackle the ID/LOC split, I see no benefit adding this extra layer
> of indirection with a privacy invasive "Unique and Permanent" identifier
> >> [email-masked] Sent: Wednesday, October 04, 2017 9:35 AM
> >> To: [email-masked] Cc: [email-masked]; [email-masked];
> >> [email-masked] Subject: Re: [Ideas] WG
> >>> only difference between identifiers and addresses is that
> >>> identifiers are not topological. Virtual addresses in network
> >>> virtualization are also identifiers. So the security properties are
> >>> the same when considering privacy. For instance, if applications use
> >>> temporary addresses for privacy, it would have equivalent properties
> >>> using temporary identifiers. In fact from the application POV this
> >>> would be transparent. It could get a pool of apparently random
> >>> addresses to choose from as source of communication, it shouldn't
> >>> know or even care if the addresses are identifiers.
> >>>
> >>> required in any of the identifier/locator protocols and AFAIK none
> >>> of them even mention the term. There is no association of an
> >>> association of identity behind IP address. The fact that the words
> >>> "identifier" and "identity" share a common prefix is an unfortunate
> >>> happenstance :-).
> >>
> >>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Oct 2017 15:37:37 -0700

> I suggest that could be called idloc (for Identifier-Locator)

I would suggest ms-ops as in “mapping system operation”.

Dino

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 5 Oct 2017 00:46:21 +0000

Jari,

	> More specifically, at the BOF the goal seemed to be creation of infrastructures to manage and track identities, and to bind them to entities that assigned them. 
                > I am not at all sure that’s a desirable direction. And the charter says little about the assumptions behind the work.
	>To expand a bit on these concerns, the proposed work doesn’t consider at all the types of identifier operations that work on ephemeral identities (e.g., HIP, MP-TCP). 
                >It would be sad if we created systems that forced us to manage identifiers from some infrastructure when all we needed to do in a particular case was “prove that you are 
                >the same entity as in the other connection”, which can be done e2e and requires no infrastructure, or permanent identifiers.

I hope you agree, when we talk about a mapping system - it's important 

     - Who can update the mappings 
     - Who can access the mappings 

Both needs AUTH and hence an Identity (EAP or whatever mechanism with anonymous or pseudonymous access) & provider ==> essentially an access ID.
If you don't restrict who can access the mapping (2nd question) one would get a primitive system, but the ability to provide some control is useful for lot of scenarios (including lot of IoT/Vehicular nodes having mobility and multi-access). 
In any case, you should still restrict who can update whose mappings.

You need this "standardized" system with well-defined interfaces  for
   a.  lot of local IoT/enterprise deployments and 
   b.  can be  extended through a federated system where only mapping of Identifiers and locations can be shared among providers for further reachability (central to any mobility system, regardless of which ID/LOC protocol).

With regard to privacy concerns raised, I still believe there are IETF approved solutions like https://tools.ietf.org/wg/abfab/ can be leveraged here too.

What data plane identifier is another aspect and that is governed by ID/LOC protocols.

--
Uma C.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 4 Oct 2017 21:35:38 -0400

Uma,
     It simply does not follow that you need an identity in order to be 
able to update the mapping system.  You do need authentication.
      If you use DNS, then mechanissm such as the authentication used 
with dynamic DNS suffice.
      If you use LISP, then the keying associated with the delegation of 
the identifier works.
      If you use MobileIP, then you need the authentication with your 
home register.

     There is no need for any special Identity.

Yours,
Joel

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Oct 2017 20:37:30 -0500

>      There is no need for any special Identity.

My reading of the claim was that authentication is needed in order to
change the actual map itself, which does seem like a true statement,
in general.  Authentication is not necessarily needed just to consume
the map.

-Ben

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 4 Oct 2017 21:40:54 -0400

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.

Uma was arguing that they need an identity.  I am arguing that such a 
thing is counter-productive.

Yours,
Joel

---

From: Mike StJohns <[email-masked]>
Date: Wed, 4 Oct 2017 21:50:29 -0400

FYI.  IDEAS as an IETF acronym has been taken since about 1989 or so.  It stood for Internet Design Engineering and Analysis Series which was a fairly short lived document series that preceded the Internet Drafts process.  This led to at least one internet routing company noting in its collateral that it implemented IDEA 9.   

Mike

FWIW. I agree with John about the obnoxiousness of "[email-masked]" as a mailing list name.  

Sent from my iPad

> On Oct 4, 2017, at 12:57, John C Klensin <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 4 Oct 2017 22:25:33 -0400

On Wed, Oct 4, 2017 at 9:50 PM, Mike StJohns <[email-masked]> wrote:
>
> FYI.  IDEAS as an IETF acronym has been taken since about 1989 or so.  It
stood for Internet Design Engineering and Analysis Series which was a
fairly short lived document series that preceded the Internet Drafts
process.  This led to at least one internet routing company noting in its
collateral that it implemented IDEA 9.
> FWIW. I agree with John about the obnoxiousness of "[email-masked]" as a
mailing list name.

IDEA
​ is also the name of the cipher originally used in PGP which might not be
an issue only I seem to recall it was broken with a meet in the middle
attack so it is probably tainted.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 5 Oct 2017 03:07:25 +0000

Hi Joel,

	    > It simply does not follow that you need an identity in order to be able to update the mapping system.  You do need authentication.

Indeed, thx.
  		
  	 >....

If we choose,  auth. method is as primitive as using passwords else the above statement is not True.

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 5 Oct 2017 03:09:10 +0000

Hi Ben,

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Wednesday, October 04, 2017 6:38 PM
To: Joel M. Halpern <[email-masked]>
Cc: [email-masked]; [email-masked]; Uma Chunduri <[email-masked]>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

>      There is no need for any special Identity.

My reading of the claim was that authentication is needed in order to change the actual map itself, which does seem like a true statement, in general. 

[Uma]: Yes.  AUTH is also needed to update on who all can access that information. One possibility is  It's based on type of the device. 

Authentication is not necessarily needed just to consume the map.

[Uma]:  But what is envisioned here is to restrict this consumption based on access policy set forth based on type of the device. IoT device type X can only access the mapping of say Y. This needs AUTH for who is asking the mapping too.. 

-Ben

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 5 Oct 2017 03:24:18 +0000

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 5 Oct 2017 00:40:38 -0400

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

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Oct 2017 08:31:38 +0200

> That really wasn't a good example;-)

yeah thats not how phishing works

---

From: Leif Johansson <[email-masked]>
Date: Thu, 5 Oct 2017 08:46:40 +0200

> This is not about people..

Relying on a distinction between human and (often personal) device
identity seems iffy... at least if you hope to deploy in the EU

For instance, this:

http://curia.europa.eu/juris/document/document.jsf?text=&docid=184668&pageIndex=0&doclang=en&mode=lst&dir=&occ=first&part=1&cid=1116945

Note the courts emphasis on linkability using additional information.

Availability of such linkable information is not the exception, which
means you can't just analyze the privacy aspects of an effort like IDEAS
by looking at one layer of the stack.

	Cheers Leif

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 4 Oct 2017 23:57:47 -0700

On Wed, Oct 4, 2017 at 9:40 PM, Joel M. Halpern <[email-masked]> wrote:

> communications service provider, then I would fundamentally disagree with
> you.  The communication service provider has no role in creating or

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

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

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

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

> 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

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

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 5 Oct 2017 00:51:22 -0700

> says little about the assumptions behind the work.
The goal was not to manage and track identities but have a means to protect
an identifier from misuse and abuse. The "user of an identifier"
(disclaimer - user is not a human and in this context aka identity)
typically need to authenticate to be able to update the locator in a
mapping system. This aspect was just formalized in the charter.

Looking at much of the discussions, it is important to make this
clarification in the charter.

> <Padma> Actually after the discussions in the bof, it was clear that the
entities should be allowed to have multiple identifiers and identities. The
charter points to life cycle of these and there is no assumption that they
cannot be ephemeral. The management of identities here is just formalizing
what mapping systems need - an authentication of the "device using the
identifier" for the update and look up of the locators. Today we already
have identifiers/loc in infrastructure for lookups this is no different.

The goal was rather to check if that entity X that is trying to locate
entity Y is ok by entity . If not, not to honor the look up  - kind of a
"do not call" list.

> <Padma> no it is default as identifiers are best to be ephemeral for
privacy.

> I find concept of firewalls checking identity troublesome.

<Padma> there is no concept of enforcing firewall in the charter. The
policy per identifier or identity is based on whether a lookup should be
honored or not. Whether local firewalls (as in enterprise domains) are used
to prevent and block communication is no different than today's use.

> mapping services or forwarding agent type designs.
<Padma>
Agree that we want to do it the right. The notion autonomous nodes having
their say on when to reveal their location is a goal for this infra. The
"identities" in this context here are never revealed on the wire but only
the pseudonyms or identifiers associated.

There has been a lot of discussions on the alias and drafts which
unfortunately cannot be reflected in a charter.

One of the goals is to have better privacy and prevent easy tracking (as
with long lived identities) against eavesdroppers or outsiders.

Padma

Jari

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 5 Oct 2017 17:05:06 +0000

Hi Joel,

In-line [Uma]:

Best Regards,
--
Uma C.

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, October 04, 2017 9:41 PM
To: Uma Chunduri <[email-masked]>; Benjamin Kaduk <[email-masked]>; Jari Arkko <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

If by "Provider" in "Provider based AUTH" you mean the last hop communications service provider, then I would fundamentally disagree with you. 
[Uma]: I meant IdP and it's an orthogonal discussion if both roles played by same entity..
 
 The communication service provider has no role in creating or authenticating identifiers.  Their job is to provide locators.
[Uma]: Absolutely.

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

[Uma]:  Yes, may be not all systems require that, especially if this is a local deployment.

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.
[Uma]: Yes.

But neither of those require anything other than the identifier and suitable keying.  
[Uma]: If it's a local system simple keying is enough (in the expense of key management etc) as all devices may be managed by the same org.

---

From: Georgios Karagiannis <[email-masked]>
Date: Fri, 6 Oct 2017 07:49:13 +0000

Hi all,

Please note that I have looked into the output of the (concluded) IETF ABFAB WG. In order to answer many questions/concerns that have been raised during the previous IDEAS discussions, it might be useful to consider the results of the IETF ABFAB WG.
https://datatracker.ietf.org/wg/abfab/documents/

We could incorporate their concepts about identity and how identity can be established and leveraged in a distributed way able to satisfy trust and privacy concerns.

Best regards,
Georgios

-----Original Message-----
From: Ideas [mailto:[email-masked]] On Behalf Of Uma Chunduri
Sent: Thursday, October 05, 2017 7:05 PM
To: Joel M. Halpern; Benjamin Kaduk; Jari Arkko
Cc: [email-masked]; [email-masked]
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

Hi Joel,

In-line [Uma]:

Best Regards,
--
Uma C.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 6 Oct 2017 10:32:16 +0100

Hiya,

On 06/10/17 08:49, Georgios Karagiannis wrote:
> Hi all,
> 
> Please note that I have looked into the output of the (concluded)
> IETF ABFAB WG. In order to answer many questions/concerns that have
> been raised during the previous IDEAS discussions, it might be useful
> to consider the results of the IETF ABFAB WG. 
> We could incorporate their concepts about identity and how identity
> can be established and leveraged in a distributed way able to satisfy
> trust and privacy concerns.

I have no clue how GSS-API is even relevant here. abfab
was a fine thing for JISC and friends to do to as a way
to try broaden the benefit they got from their existing
federated authentication setup, in their case involving
UK universities. It is not at all clear that that would
be even relevant if one wanted to build the kind of all
encompassing IdPs envisaged in the ideas charter/draft.
The relationships that university account holders have
with their own and other academic institutions and with
applications running in such environments (that being
the point of abfab) don't seem to me to generalise to
lower layers in any useful manner.

In any case, if this proposal is only now at the point
where you're starting to ponder the basic architecture
then I'd conclude it's nowhere near ready to charter.
(As well as being a bad idea from the privacy POV;-)

WGs for such decisions can be a good plan when there's
a few known architectural choices on the table, and if
different sets of folks need a venue to reach consensus
on which road to take - suggesting abfab at this point
sounds like floundering around looking for reasons to
exist tbh. (Sorry to be blunt and it may not be that,
but it appears to be that to me.)

S.

> Best regards, Georgios
> [mailto:[email-masked]] On Behalf Of Uma Chunduri Sent:
> Thursday, October 05, 2017 7:05 PM To: Joel M. Halpern; Benjamin
> Kaduk; Jari Arkko Cc: [email-masked]; [email-masked] Subject: Re:
> [Ideas] WG Review: IDentity Enabled Networks (ideas)
> 
> Hi Joel,
> 
> In-line [Uma]:
> 
> 
> Best Regards, -- Uma C.
> 
> -----Original Message----- From: Joel M. Halpern
> [mailto:[email-masked]] Sent: Wednesday, October 04, 2017 9:41
> PM To: Uma Chunduri <[email-masked]>; Benjamin Kaduk
> <[email-masked]>; Jari Arkko <[email-masked]> Cc:
> [email-masked]; [email-masked] Subject: Re: [Ideas] WG Review:
> with you. [Uma]: I meant IdP and it's an orthogonal discussion if
> both roles played by same entity..
> 
> The communication service provider has no role in creating or
> authenticating identifiers.  Their job is to provide locators. [Uma]:
> Absolutely.
> 
> 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.
> 
> 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. [Uma]: Yes.
> 
> 
> suitable keying. [Uma]: If it's a local system simple keying is
> enough (in the expense of key management etc) as all devices may be
> managed by the same org.
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Fri, 6 Oct 2017 20:38:10 -0700

On Fri, Oct 6, 2017 at 2:32 AM, Stephen Farrell <[email-masked]>
wrote:

>
> <snip>
> It is not at all clear that that would
> <snip>

What kind of all encompassing IdPs is being referred to above? The charter
does not propose to build such an all encompassing system.

The charter refers to a mapping system for Id/Loc protocols. The data is
routing information. It may have some limited information if useful for
routing purposes - such as the list of locators, groupings and so on.

Today, routing information of this nature in mapping systems is not hidden.
All nodes in ID/Loc protocols typically access this information for
encapsulation, translation or forwarding decisions without any restrictions
(within their instance/scope).

One of the goals is to be able to authenticate and have access-control on
the lookups if so desired.  This functionality should enhance privacy on
revealing locators of nodes.

For example, you may want to advertise the location of some of  your mobile
IoT nodes in a factory on a need to know basis. The solution proposed here
is one of them.

To address your concerns: no all encompassing system, or humans involved
here.

Padma

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 7 Oct 2017 14:22:21 +0100

> To address your concerns: no all encompassing system, or humans involved

I'm sorry but my concerns are just not addressed.

There are humans involved here - they're the ones carrying
the phones and whose presence triggers traffic from other
devices. And while "all encompassing" is maybe a little bit
overstated, anything considering that there's a widespread
need for permanent identifiers (your IDy's) does seem to be
aiming in that direction. If this effort is only aiming at
some niche within the universe of devices that could have
(but hopefully won't have) permanent identifiers known to
networking kit, then you've not identified the niche, and
so do sorta seem to be aiming for an all-encompasing IdP.

S.

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 7 Oct 2017 19:58:11 +0000

>If this effort is only aiming at some niche within the universe of devices that could have (but hopefully won't have) permanent identifiers known to networking kit

Quick response regarding the term permanent identifier:

- This is not there in the charter
- This is no more permanent than any  identity used for any AUTH method today (IETF defined)
- If this is used in any of the documents - this is to differentiate from the temporary nature of the anonymous identifiers (e.g: LISP anonymous EID). These can't be used for AUTH.
- Though it's up to the community decide which AUTH method - there was a precedent for this term - one *example* RFC 4187/5448
- would be happy to replace with any other term which indicates the intent

--
Uma C.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sat, 7 Oct 2017 15:54:33 -0700

On Sat, Oct 7, 2017 at 6:22 AM, Stephen Farrell <[email-masked]>
wrote:

> devices.And while "all encompassing" is maybe a little bit

> aiming in that direction.

<Padma>
The charter does not mention permanent IDy.  However, it is in one of the
drafts which AFAIK the authors intend to refresh in a few days to clear up
this specific point.

I responded earlier to Jari on this specific topic wrt his feedback at the
bof. It was discussed on the alias whether IDy are permanent or have a
lifecycle.  The consensus was that IDys are mutable and have a lifecycle.

The charter specifically has this text to reflect this:
- Registration and lifecycle management of identities and their
associated identifiers.

If this effort is only aiming at
> so do sorta seem to be aiming for an all-encompasing IdP.

Noted that the scope should be clarified in the charter.

To address your concerns:
The IDy is not permanent and the scope of the work is not aiming to be all
encompassing.
The consensus position should be reflected in the next revision to avoid
any discrepancies.

Propose that we add some text in the charter to reflect the niche/scope of
the work.

Padma

---

From: Randy Bush <[email-masked]>
Date: Sun, 08 Oct 2017 08:32:32 +0900

is there a parallel here as to why we had to re-hack v6 for 'privacy'
addresses?

randy

---

From: S Moonesamy <[email-masked]>
Date: Sat, 07 Oct 2017 16:43:28 -0700

Hello,
At 09:13 AM 29-09-2017, 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 ([email-masked]) by 2017-10-09.

I took a quick look at the drafts for the proposed working group and 
I came across the following: "An Identity uniquely identifies a 
Communication Entity" and "To put it simply, while the IDy of a 
communicating entity is obfuscated to outside observers, it is 
revealed to communicating parties with a legitimate need to 
know.  Legitimate parties include either end of entities itself or 
regulatory authorities or authorized edge nodes (routers/IDf based 
firewalls) in the network."

I assume that the proposed working group will be creating an embedded 
identifier so that legitimate parties can track Internet users.  I 
don't think that it is a good idea.

Regards,
S. Moonesamy

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sat, 7 Oct 2017 18:38:22 -0700

On Sat, Oct 7, 2017 at 4:43 PM, S Moonesamy <[email-masked]> wrote:

> I took a quick look at the drafts for the proposed working group and I
> came across the following: "An Identity uniquely identifies a Communication
> Entity" and "To put it simply, while the IDy of a communicating entity is
> obfuscated to outside observers, it is revealed to communicating parties
> with a legitimate need to know.  Legitimate parties include either end of
> entities itself or regulatory authorities or authorized edge nodes
> (routers/IDf based firewalls) in the network."
>

> identifier so that legitimate parties can track Internet users.  I don't
> think that it is a good idea.
>

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.

The draft in question is being updated and the authors are doing for
clarification.

Padma

---

From: S Moonesamy <[email-masked]>
Date: Sun, 08 Oct 2017 10:55:57 -0700

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

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?

>The draft in question is being updated and the authors are doing for 

Ok.

Regards,
S. Moonesamy

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sun, 8 Oct 2017 11:20:22 -0700

On Sun, Oct 8, 2017 at 10:55 AM, S Moonesamy <[email-masked]> wrote:

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

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

---

From: S Moonesamy <[email-masked]>
Date: Sun, 08 Oct 2017 11:33:14 -0700

Hi Padma,
At 11:20 AM 08-10-2017, Padma Pillay-Esnault wrote:
>identifier changes, including their implications on anonymity and 
>privacy. Explicitly, the framework must define privacy requirements 
>and how potential extensions/solutions should meet them.

Why is privacy requirements being redefined?  The IAB already has a 
RFC about that.  I have not done a search; there are probably IETF 
RFCs about that subject.

>?? Not sure what /how this is in context .... Are we still taking 
>about routing information here?

No.

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

There is currently an IETF thread about that [1].

Regards,
S. Moonesamy

1. https://www.ietf.org/mail-archive/web/ietf/current/msg104717.html

---

From: Tom Herbert <[email-masked]>
Date: Sun, 8 Oct 2017 11:47:57 -0700

> identifiers, can obsfuscate them or encrypt them as Dino pointed out
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

> Explicitly, the framework must define privacy requirements and how potential
> extensions/solutions should meet them.
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sun, 8 Oct 2017 11:48:09 -0700

On Sun, Oct 8, 2017 at 11:33 AM, S Moonesamy <[email-masked]> wrote:

> Why is privacy requirements being redefined?  The IAB already has a RFC
> about that.  I have not done a search; there are probably IETF RFCs about
> that subject.

It looks like you are referring to general privacy requirements but this is
not the scope/context of this work.

The charter only refers to the context of the framework requirements.

>> routing information here?

this work is in the context of routing information only.

No.

Padma

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Sun, 8 Oct 2017 12:10:16 -0700

Tom

> will be authorized to access the system.

Let's clarify again

1. IDy is NOT human identities but the "user(temporal) of an (temporal)
identifier" who is authorized to update or look up identities.

2. It is not mandatory to authenticate but desirable.

3. In some cases, like in a private or closed when you need to track your
devices/planes, do accounting or whatever, you should be able to do this on
a need to know basis.

Using the cell phone example to tie an end device to a human. Today,
doesn't SIM cards tie at some level you as a subscriber to your device and
do the accounting? The SIM database is not publicly accessible are they?

Thanks
Padma

---

From: Melinda Shore <[email-masked]>
Date: Sun, 8 Oct 2017 11:57:04 -0800

On 10/8/17 11:10 AM, Padma Pillay-Esnault wrote:
> doesn't SIM cards tie at some level you as a subscriber to your device
> and do the accounting? The SIM database is not publicly accessible are they?

I think the concern is less about the ability to query a database
than it is about these identifiers providing a mechanism that
doesn't address linkability (consider, for example, Bitcoin addresses).

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Oct 2017 11:56:12 +1300

On 09/10/2017 08:10, Padma Pillay-Esnault wrote:
...
> do the accounting? The SIM database is not publicly accessible are they?

It's available to repressive governments. Also, I don't know if there have
been wholesale thefts or leaks of parts of the SIM database, but there have
certainly been breaches of the secrecy by corrupt law enforcement agents
or telco employees.

So the IETF has to be careful not to create another similar exposure.

   Brian

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 9 Oct 2017 17:14:18 +0000

Hi,

Some reponses in-line [Uma]:

------------

		>>privacy. Explicitly, the framework must define privacy requirements and 
		>>how potential extensions/solutions should meet them.

	>Why is privacy requirements being redefined?  The IAB already has a RFC about that.  I have not done a search; there are probably IETF RFCs about that subject.

[Uma]: I am not sure what do you mean by "Privacy requirements redefined".  Today in mapping systems LOC information is not private, meaning anybody can access this information. 
               This won't work (or fatal w.r.t security) for lot of applications who are seeking to use ID/LOC protocols.
               AUTH into the system (with mutual authentication, if we can) can help restrict who can access the LOC information.
               This also entails LOC updates with encryption.
                These are essential for ID/LOC protocol deployments (for the applications described  in IDEAS).
                Privacy requirements in the charter are mostly around these items...            

	>1. https://www.ietf.org/mail-archive/web/ietf/current/msg104717.html 

[Uma]: What's  the relevance of the same here.  IDEAS is not seeking to change any type of LOC information used in ID/LOC protocols... this is governed by ID/LOC protocol in use. It could be IPv4 or (mostly) IPv6.
               IDEAS doesn't alter or won't come into picture  outside of ID/LOC protocol context.

--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 9 Oct 2017 10:38:03 -0700

> Some reponses in-line [Uma]:

I don't believe that is true. There are many examples of deployments
that have a private mapping system which is not accessible by just
anyone, For instance, in multi tenant virtualization it is imperative
that tenants are not able to access the mapping system-- if they were
then the whole concept of virtual network isolation starts to breaks
done. Mapping systems are already by protected using ACLs,
authentication, network isolation, etc.

Tom

---

From: S Moonesamy <[email-masked]>
Date: Mon, 09 Oct 2017 13:08:02 -0700

Hi Uma,
At 10:14 AM 09-10-2017, Uma Chunduri wrote:
>[Uma]: I am not sure what do you mean by "Privacy requirements 
>redefined".  Today in

I was commenting on the text from the proposed charter.  There are 
one or more RFCs which discusses about privacy.

>[Uma]: What's  the relevance of the same here.  IDEAS is not seeking 
>to change any type of LOC information used in ID/LOC protocols... 
>this is governed by ID/LOC protocol in use. It could be IPv4 or (mostly) IPv6.
>                IDEAS doesn't alter or won't come into 
> picture  outside of ID/LOC protocol context.

If the IETF were to decide that it will stop doing IPv4 work except 
for maintenance, should the working group be allowed to add in 
support for IPv4?

Regards,
S. Moonesamy

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 9 Oct 2017 21:14:48 +0000

> 
> I don't believe that is true. There are many examples of deployments that
> have a private mapping system which is not accessible by just anyone, For
> instance, in multi tenant virtualization it is imperative that tenants are not
> able to access the mapping system-- if they were then the whole concept of
> virtual network isolation starts to breaks done. Mapping systems are already
> by protected using ACLs, authentication, network isolation, etc.
> 
> Tom
> 

I thought one concern raised here wasn't that the information couldn't be secured, but that the owner or operator of the mapping system could collude with dark forces to turn its information against you, in which case all bets are off. 

Assuming for a moment that we have an operator who does not collude with dark forces and does want to secure access to the mapping system and information, one question concerns how the access is controlled - just to the mapping system as a whole, or at the level of individual records.  Is this level of differentiation provided (which can be important if I want to protect e.g. my locator information from some, but not all users)? 

--- Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Oct 2017 11:55:19 +1300

> I thought one concern raised here wasn't that the information couldn't be secured, but that the owner or operator of the mapping system could collude with dark forces to turn its information agains…

Indeed. There is one possible mitigation, which is that all the central system
knows about is the *existence* of a unique ID, not who or what it refers to.
In other words the central system creates and hands out IDs, never hands out the
same one twice, and keeps no record beyond the value of the ID. Then only the
entity that obtained the ID can create mappings to it. That allows knowledge
of the mappings to be compartmentalised and decentralised, and the mappings
will not be traceable back to the entity that requested the ID itself.

Much like trying to ping fd63:46cb:fe17:0:be05:43af:fec1:bad9

    Brian

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 10 Oct 2017 11:42:50 -0400

[Apologies for not chiming in before. [*]]

I’ve been reading this thread and discussing with others in the IAB/IESG.  Thank you for all the comments and opinions!

The concerns about privacy/anonymity and the potential results (tracking, censorship, etc.) are clear.  It is a serious topic and I wouldn’t have expected less.  I can also see that clarifications about the intention or assurances about what the (proposed) WG should produce/focus on haven’t been enough to reduce the criticism of both the charter and the existing (individual) work.

At this point in the process, and without trying to run the WG or rewrite the documents on this thread, all I can offer is charter text.  My expectation is for the support documents (i.e. the individual drafts that have been written so far) to be discussed and consensus reached on them – vs assuming that they are a foregone conclusion.  I think that the number of use cases require that formal discussion anyway.  Whatever the result of the chartering effort is, I hope that interested people will join the mailing list and contribute with the same enthusiasm.  To me, the widening of the audience has been as important as the discussion itself.

Right after I send this e-mail I will be opening the ballot [1] for this week’s IESG Telechat discussion of this (proposed) WG.  I will be balloting “Yes” because I think that the discussion could be taken further in the context of a WG (hopefully with additional security/privacy expertise).  I know that the charter text is not perfect, and realize that I may be in the rough anyway.

Thanks!

Alvaro.

[1] https://datatracker.ietf.org/doc/charter-ietf-ideas/ballot/   

[*] I’m in the process of changing jobs, took a couple of (I would strongly argue, well-deserved) days off in between, e-mail went missing, changed e-mail systems 3 times… <sigh>   Definitely not the best timing. :-(

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 10 Oct 2017 15:35:31 -0400

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

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).  As the 
charter says, strong access control will be designed in (but of course 
no assurance of implementing).  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.

Bob

On 09/29/2017 02:31 PM, Stephen Farrell wrote:
>> -----------------------------------------------------------------------
>> Current status: Proposed WG
>>
>> Chairs:
>>    Padma Pillay-Esnault <[email-masked]>
>>
>> Assigned Area Director:
>>    Alvaro Retana <[email-masked]>
>>
>> Routing Area Directors:
>>    Alia Atlas <[email-masked]>
>>    Alvaro Retana <[email-masked]>
>>    Deborah Brungard <[email-masked]>
>>
>> Mailing list:
>>    Address: [email-masked]
>>    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.)
>>
>> - 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
>>
>>
>>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Oct 2017 21:23:51 +0100

Hi Bob,

On 10/10/17 20:35, Robert Moskowitz wrote:
> 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
> 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

Sure.

> 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
> no assurance of implementing).  

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

> Note that HIP has a course access

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.

>>> separation are
>>> associated

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Oct 2017 10:07:52 +0900

> I can also see that clarifications about the intention or assurances
> about what the (proposed) WG should produce/focus on haven’t been
> enough to reduce the criticism of both the charter and the existing
> (individual) work.

that is because papering over dangerous things with assertions of good
intent is a path to hell.  one has to actually fix the things.

randy

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 11 Oct 2017 07:01:23 +0000

Hi,

> Right after I send this e-mail I will be opening the ballot [1] for this week’s IESG Telechat discussion of this (proposed) WG.  I will be balloting “Yes” because I think that the discussion could…

not only is the charter text "not perfect", it *raises* serious security and privacy concerns.

Going forward with the current charter text is hence exactly the wrong thing to do. At the very least, the charter text requires a serious refactoring, to attempt to either address the raised concerns or to explicitly (and drastically) limit the scope of the work so that there is consensus that these issues can be worked out in a WG.

The statement to take this "further in the context of a WG (hopefully with additional security/privacy expertise)" basically asks the rest of us who have no interest in this work to spend cycles on it anyway, in order to do damage control in a WG. The reason we do consensus calls on charters is so that we *don't* need to do that for ideas that are clearly problematic and shouldn't be chartered.

Lars

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Oct 2017 08:14:15 +0100

I agree with Lars' statement below and don't understand the
logic of the "yes" ballot here. That said, I see there are
now also two "block" ballots [1] so it looks like the IESG
collectively are doing the right thing.

S.

On 11/10/17 08:01, Eggert, Lars wrote:
>> Right after I send this e-mail I will be opening the ballot [1] for this weekâ€™s IESG Telechat discussion of this (proposed) WG.  I will be balloting â€œYesâ€ because I think that the discussion could be taken further in the context of a WG (hopefully with additional security/privacy expertise).  I know that the charter text is not perfect, and realize that I may be in the rough anyway.
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Oct 2017 16:29:47 +0900

> The statement to take this "further in the context of a WG (hopefully
> with additional security/privacy expertise)" basically asks the rest
> of us who have no interest in this work to spend cycles on it anyway,
> in order to do damage control in a WG. The reason we do consensus
> calls on charters is so that we *don't* need to do that for ideas that
> are clearly problematic and shouldn't be chartered.

this is a terrible scaling problem.  lack of guts in the iesg devolves
into a massive time burden on a lot of people.

randy

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 11 Oct 2017 02:56:24 -0700

Hi,

I share all the concerns expressed, these have to be taken very seriously and properly addressed, I expect authors and proponents to do so rather soon!
I also support Alvaro’s view on future evolution and further fine-tuning of the charter and deliverables within a new WG.   

Cheers,
Jeff

-----Original Message-----
From: ietf <[email-masked]> on behalf of Alvaro Retana <[email-masked]>
Date: Tuesday, October 10, 2017 at 08:56
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

    

    
    Thanks!
    
    Alvaro.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 11 Oct 2017 10:56:05 +0000

Hi Stephen -

I would let Bob to respond the questions you asked - but If I may for the below question 

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

[Uma]: 

1. IDEAS only intended deal with aspects for control/mapping plane of ID/LOC protocols. 
      How  and what kind of Identifier's used in the data packets are governed by the  respective ID/LOC protocol in use.  Just give some examples -
      It could be HIT in case of HIP with security properties, EID/Anonymous EID's in case of LISP with encapsulation.
  
     This has been explicitly updated in the use-case draft and can be further updated in the charter. But, I would note  this is the intention for the  following in the current charter text -
      "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."

2.  And regarding the usage of the term "identity" - not sure what's the confusion and why this has been associated with humans to start with. This has been further clarified in the discussions past few days and also been updated in the document. 
      Now the term,  we felt appropriate as the intent is in the context  of AUTH (examples of identifies thought through IPV4_ADDR, FQDN, RFC822_ADDR, IPV6_ADDR, DER_ASN1_DN, DER_ASN1_GN, KEY_IDs etc) , 
       which is consistent with any of the authentication mechanism we use today* as defined by IETF. 

--
Uma C.

* https://tools.ietf.org/html/draft-ietf-tls-tls13-21
   https://tools.ietf.org/html/rfc5996 
   Or one of the 20/30+ EAP AUTH methods with mutual authentication properties (depending the low power/high power mobile/industrial/vehicular IoT device in question)

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 Oct 2017 20:56:21 +0900

> 1. IDEAS only intended deal with aspects for control/mapping plane of

please stop using the word 'intended' and it's friends.  joseph ii had
wonderful intent, but did not succeed.

how about 'will be chartered to only do X.'  'will not by charter' etc.

and let's see the revised charter.

note that ipv6 MAC-derived EUI addresses were intended only to map
identity to location.  they are a privacy disaster.

randy

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 11 Oct 2017 10:56:48 -0400

Just sqeezing in a couple more replies before the last days of the 
Holiday...

On 10/04/2017 05:56 PM, Brian E Carpenter wrote:
> that the name 'IDEAS' is misleading,

And other wg's are not?  The IETF's desire for 'nice' names often 
results in names a little misleading.  Thus need to read the charter.  
Not that everyone who worked on the charter got what they wanted.  It is 
called compromise.

> and 'GRIDS' tramples on previous work,

Yeah, I did/dont like it.  But it is not my draft.

> and 'identity' is a red flag.

Whow there!  You were part of the Namespace Research Group?  I think?  I 
was and we we worked a lot on this and came to the conclusion that there 
could be no conclusion.  Not even a rough concensus, it seemed.

I have been using 'identity' to apply to things for 20 years. Pretty 
much ever since I started working with things.  Anyone that holds the 
position that 'identity' means we are talking only about people are 
allowing their thinking to be clouded.

So we use qualify our use of such terms.  That is why I called it a 
'Host Identity', then I was challenged as to what I was naming? Were you 
at the NL meeting the week before Oslo?  'Oh you are naming the stack'.  
ARGH!

enough history.

> But if we get past terminology distractions,

The meat is what is missing in current ID/Loc technologies to realize 
the full potential.  Discovery. Some level of reversiblity. Strong 
access controls.

I plan on doing some real protocol work.  And some real implementation 
guidelines for protecting privacy.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 11 Oct 2017 11:06:02 -0400

> doesn't address linkability (consider, for example, Bitcoin addresses).

Melinda, I am struggling to get your meaning.

Identities are messy and do not work well in protocols or as table 
indicies.  Identifiers TEND to be one-way concise mappings of Identities 
that CAN be used thusly.  So there is a one-way linkage. Thing is 
sometimes you need the other way.  Given an Identifier, what is the 
Identity, as there might be policy rules needing enforcement.

Then there is discovering the Identity for peer communications.  Why 
should party A be allowed to learn that party B exists and then be led 
to where it is?  So more linkage.

And all of this needs to be fast and work on very small things as well 
as rather big things.  Blockchains tend not to be easy to work on things 
with much less than a M of capacity.  Some of the work will be done in 
big ugly sentral services.  Other work closer to the problem.

But I am wandering here.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 11 Oct 2017 11:12:04 -0400

> So the IETF has to be careful not to create another similar exposure.

And LDAP is not?

We create knives and forks.  You can do good things and bad things with 
them.  We do not cook meals or such.

Other than DNS, do we really come close to owning anything other than 
how things can work?

And interesting that it seems there have been no major breachs of things 
like SIM databases but ones with extensive PII have.

Bob

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 11 Oct 2017 11:17:27 -0400

On 10/09/2017 04:08 PM, S Moonesamy wrote:
> I was commenting on the text from the proposed charter.  There are one 
> or more RFCs which discusses about privacy.
>
> for maintenance, should the working group be allowed to add in support 
> for IPv4?

Unfortunately, a technology that intentionally breaks IPv4 will not get 
deployed.  It needs to give a 'nod' to backwards compatiblity. A part of 
me would really like to come up with the 'killer protocol' that everyone 
needs but just can't EVER be made to work with IPv4, so sorry world, you 
just have to get over it (IPv4).  If you want something to fit into 
factories, you have to work around IPv4.  It will be interesting to see 
how 6TISCH works out there (with 4in6?)...

Bob

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Oct 2017 16:20:39 +0100

> like SIM databases but ones with extensive PII have.

https://www.theguardian.com/us-news/2015/feb/19/nsa-gchq-sim-card-billions-cellphones-hacking

Admittedly quite a sophisticated attacker.

S

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 11 Oct 2017 12:11:19 -0400

> Admittedly quite a sophisticated attacker.

Well, that is a horse of a different color.

:)

Bob

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Oct 2017 09:19:16 -0700

> Well, that is a horse of a different color. 

Don't forget that what the spooks can do today, the gangsters will do
tomorrow, and the high school kids not so long after that...

-- 
Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Oct 2017 09:15:56 -0700

On 10/11/2017 7:56 AM, Robert Moskowitz wrote:

> Whow there!  You were part of the Namespace Research Group?  I think? 
> I was and we we worked a lot on this and came to the conclusion that
> there could be no conclusion.  Not even a rough concensus, it seemed.
>

I am concerned that the current proponents of the IDEAS work are mainly
resisting the feedback, treating it as some roadblock put in the path of
their work by misguided privacy purists, and attempting to remove the
roadblocks by adding some weasel words to the charter. I would feel much
more confident if these proponents acknowledged the tension between
privacy and stable identifiers of any sort, if that tension was clearly
noted in the charter, and if privacy goals were clearly stated.

Specifically, I think there is a contradiction between some of
documents. For example, draft-padma-ideas-problem-statement-01 states that:

   o  A single entity may have multiple IDs, and IDs of the same entity
      may have different life spans that are different from the lifespan
      of the entity.  Furthermore, it is understood that IDs may have
      different lifecycles, which may be permanent or ephemeral by
      choice or design.

   o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
      for a permanent ID to protect the privacy of the related entity.

But then, draft-ccm-ideas-identity-use-cases-01 states that:

   a.  Unique and Permanent Identity representing the entity enables
       authentication (AUTH) with the mapping and Identity services
       infrastructure.  While it is possible to do AUTH on Identifiers
       those are not permanently associated to the entity.  Moreover,
       AUTH operation is a relatively an expensive and inefficient
       procedure (compared to LOC resolution for example) and can cause
       excessive startup delays for lot of applications.

The tension is obvious. On one hand, the ephemeral identifiers envisaged
in the problem statement would pretty much align the privacy properties
of the ID to those of IPv6 privacy addresses, and that's good. On the
other hand, the requirement to perform authentication on identities
completely negates that property.

I would be fine if the support for "Unique and Permanent Identity" was
explicitly excluded from the charter. There is obviously a need to
support some form of access control to a mapping database, but you do
not need a reference to a permanent identity for that -- systems similar
to CGA would work just fine.

-- 
Christian Huitema

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 11 Oct 2017 10:32:44 -0700

On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema <[email-masked]>
wrote:

> I have been using 'identity' to apply to things for 20 years. Pretty much
> ever since I started working with things.  Anyone that holds the position
> that 'identity' means we are talking only about people are allowing their
> thinking to be clouded.
>
>
> more confident if these proponents acknowledged the tension between privacy
> and stable identifiers of any sort, if that tension was clearly noted in
> the charter, and if privacy goals were clearly stated.
>
>
As one of the proponents, I feel I need to speak up because blanket
statements are just not helping.

Speaking on behalf of my fellow proponents, we have always welcomed
constructive feedback from people who want/can contribute and make the
technology better. We have been willing to clarify the charter
(clarification does not mean weaseling).

If it is helpful to  move forward, I am willing to volunteer for this work
and discuss with anyone to ensure constructive feedback and comments are
addressed.

Specifically, I think there is a contradiction between some of documents.
> For example, draft-padma-ideas-problem-statement-01 states that:
>
As said earlier this draft was not updated by the authors and a new version
was posted yesterday.

https://www.ietf.org/mail-archive/web/ideas/current/msg00520.html

> in the problem statement would pretty much align the privacy properties of
> the ID to those of IPv6 privacy addresses, and that's good. On the other
> hand, the requirement to perform authentication on identities completely
> negates that property.
>
> explicitly excluded from the charter.
>

AFAIK, none of the proponents resisted that.

> There is obviously a need to support some form of access control to a
> mapping database,
>

Agreed.

> but you do not need a reference to a permanent identity for that --
> systems similar to CGA would work just fine.
>

The identity of the device is just adding a lever of identifier which
effectively allows authentication to modify the identifiers used by that
device but also what the users of these identifiers can look up. If we had
used "user of identifier" it would have been misconstrued for humans. So
damn if you do and damn if you don't ...

We are open for discussions anytime.

Padma

> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>
>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 11 Oct 2017 18:47:52 +0000

Two additional thoughts inline, <ALEX>

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Wednesday, October 11, 2017 10:33 AM
To: Christian Huitema <[email-masked]>
Cc: [email-masked]; [email-masked] list <[email-masked]>; Dino Farinacci <[email-masked]>; Robert Moskowitz <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)

On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

Whow there!  You were part of the Namespace Research Group?  I think?  I was and we we worked a lot on this and came to the conclusion that there could be no conclusion.  Not even a rough concensus, it seemed.

I have been using 'identity' to apply to things for 20 years. Pretty much ever since I started working with things.  Anyone that holds the position that 'identity' means we are talking only about people are allowing their thinking to be clouded.

I am concerned that the current proponents of the IDEAS work are mainly resisting the feedback, treating it as some roadblock put in the path of their work by misguided privacy purists, and attempting to remove the roadblocks by adding some weasel words to the charter. I would feel much more confident if these proponents acknowledged the tension between privacy and stable identifiers of any sort, if that tension was clearly noted in the charter, and if privacy goals were clearly stated.

As one of the proponents, I feel I need to speak up because blanket statements are just not helping.

Speaking on behalf of my fellow proponents, we have always welcomed constructive feedback from people who want/can contribute and make the technology better. We have been willing to clarify the charter (clarification does not mean weaseling).

If it is helpful to  move forward, I am willing to volunteer for this work and discuss with anyone to ensure constructive feedback and comments are addressed.

<ALEX> +1 on welcoming constructive feedback.  To incorporate it we need to update documents.  An update to the ccm use case document was posted yesterday (rev -02) which incorporates a lot of the feedback given.  Clearly, this will not be the last update and other documents need to follow.
</ALEX>

Specifically, I think there is a contradiction between some of documents. For example, draft-padma-ideas-problem-statement-01 states that:

      choice or design.

As said earlier this draft was not updated by the authors and a new version was posted yesterday.

<ALEX> I think you meant to say it *was* updated ;-)
draft-padma-ideas-problem-statement will presumably be one of the documents that are next in line for updating.  </ALEX>

The tension is obvious. On one hand, the ephemeral identifiers envisaged in the problem statement would pretty much align the privacy properties of the ID to those of IPv6 privacy addresses, and that's good. On the other hand, the requirement to perform authentication on identities completely negates that property.

I would be fine if the support for "Unique and Permanent Identity" was explicitly excluded from the charter.

There is obviously a need to support some form of access control to a mapping database,

Agreed.

but you do not need a reference to a permanent identity for that -- systems similar to CGA would work just fine.

The identity of the device is just adding a lever of identifier which effectively allows authentication to modify the identifiers used by that device but also what the users of these identifiers can look up. If we had used "user of identifier" it would have been misconstrued for humans. So damn if you do and damn if you don't ...

Padma

--

Christian Huitema

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 12:39:16 -0700

Let me ask for your opinion Christian (or anyone else for that matter). If a device is assigned a private/public key-pair and the identifier for the device is a hash of the public-key, is the identifier private?

Is the identifier trackable even when its network location is not generally known, not advertised publicly, and possibly changing frequently?

Dino

> On Oct 11, 2017, at 12:34 PM, Christian Huitema <[email-masked]> wrote:
> 
> On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:
> Some thing you should be hearing is that "long term identity of device" has almost the same privacy properties as "long term identity of the device's owner". You may think that identifying a random piece of hardware is no big deal, but it turns out that the network activity and network locations of that piece of hardware can be associated to those of its human owner. So you need the same kind of protection for these device identifiers as for human identifiers.
> -- 
> Christian Huitema
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Oct 2017 12:43:46 -0700

On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci <[email-masked]>
wrote:

> Let me ask for your opinion Christian (or anyone else for that matter). If
> a device is assigned a private/public key-pair and the identifier for the
> device is a hash of the public-key, is the identifier private?
>
>
I can't answer this in isolation. Does the identifier show up on the wire?
If so, then totally.

-Ekr

Is the identifier trackable even when its network location is not generally
> known, not advertised publicly, and possibly changing frequently?
>
> Dino
>
> > Some thing you should be hearing is that "long term identity of device"
> has almost the same privacy properties as "long term identity of the
> device's owner". You may think that identifying a random piece of hardware
> is no big deal, but it turns out that the network activity and network
> locations of that piece of hardware can be associated to those of its human
> owner. So you need the same kind of protection for these device identifiers
> as for human identifiers.
> > --
> > Christian Huitema
> >
>
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 11 Oct 2017 12:49:49 -0700

> tomorrow, and the high school kids not so long after that...

If we (community of IETF) decide no work should be done unless we have an
absolute fool-proof system against insider attacks (which I do not believe
we have an answer to that) or correlation by transitivity to humans then I
would like to have some clarifications.

The need for privacy is a given and no one is disputing that but where I
struggle is in what context?

(1) Discovery vs tracking
What is considered discovery and what is considered tracking?
If you can discover then you can track? So the only way is to access
control the discovery and this is what this proposal is about!

(2) Type of data, transitivity to human
What type of data are we talking about here? Do we believe that having
careful applications where encrypted sensitive data are not colocated with
location information so that attacks will require multi-level attacks on
multiple systems and cross-referencing a deterrent and good enough? If on
top of that we have sensitive information (human) encrypted database with
one way communications and changing identifiers etc etc as discussed.... is
that a good start or not even close?

(3) Tracking as a business model
How about companies specialized with services of tracking and discovering
things?
Pet tracking ? How about the truck driver with assisted driving?  Asset
tracking as in bikes where people swipe a wireless card? How would this
business model even work if they cannot recover their assets because we can
track a person through transitivity?

(4) Tracking who and by whom
More concerning to me is that privacy is tricky, depending on the
perspective...
We want to protect the "good" guys but isn't that also enabling the privacy
of the "bad" guys?
Should the individual behind mirai bonnet attacks or gansters be entitled
to privacy and non tracking?

(5) Tracking is all evil?
BUT then there is this annoying question that comes back to my mind .. do
we EVER consider that human tracking is needed or beneficial?
What about disaster recovery scenarios or emergency services or people who
willingly want to participate in such a service?

For example with an aging population, assisted living with monitoring
health devices is a trend in the industry. These devices can be mobile. Not
everyone can afford a caregiver full time ... So is it just going to be "no
sorry ma'am someone may use this technology to do bad things with it?" It
might be a matter of life and death to be able to track a person.

The truth is that these services exist today outside of IETF technology and
people are willingly subscribing to it because their priorities are
different.

While I completely agree we should be careful in what we do.

Disclaimer trying to clarify how/where ideas is situated in all that?
1. It was not aimed for a wide scale deployed on the internet but it may be
large enterprises.
2. It had no human info but it has been inferred this may be possible
through transitivity
3. It has changing identifiers

So we need protection  - again no one disputes that ... if we have better
technology let's integrate it.

Let's not through the baby with the bathwater ...

Padma

--

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 12:51:38 -0700

> On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci <[email-masked]> wrote:
> I can't answer this in isolation. Does the identifier show up on the wire? If so, then totally.

When the payload is encrypted, it does not. So let me ask you these follow-up questions:

(1) If a host sources a packet with its identifier in one VM and an encapsulator in another VM (in the same physical system) encapsulates the packet but encrypts the payload before encapsulation, has the identifier remain private?

(2) If in (1), the packet is decapsulated by an intermmediate point, and then reencapsulated but the packet is encrypted with a new session key (from a new ECDH exchange) to the destination, has the identifier remained private?

Dino

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Oct 2017 12:57:55 -0700

On Wed, Oct 11, 2017 at 12:51 PM, Dino Farinacci <[email-masked]>
wrote:

> > Let me ask for your opinion Christian (or anyone else for that matter).
> If a device is assigned a private/public key-pair and the identifier for
> the device is a hash of the public-key, is the identifier private?
> >
> >
> When the payload is encrypted, it does not.

Are the handshakes that establish the cryptographic keys used to encrypt
the payload themselves encrypted? If it's IKE, the answer is probably yes,
but if not, I don't know.

So let me ask you these follow-up questions:
>
> (1) If a host sources a packet with its identifier in one VM and an
> encapsulator in another VM (in the same physical system) encapsulates the
> packet but encrypts the payload before encapsulation, has the identifier
> remain private?
>
> (2) If in (1), the packet is decapsulated by an intermmediate point, and
> then reencapsulated but the packet is encrypted with a new session key
> (from a new ECDH exchange) to the destination, has the identifier remained
> private?
>

Generally, I don't tend to think of things as being "private" or
"non-private". Rather we talk about who has a given capability or piece of
information. I think it's clear that in these cases the identifier was
available to the machine doing the deencapsulation/reencapsulation.
Obviously, that's worse for privacy than having it not have that
information. How much worse depends on a lot of factors.

In this particular, work, however, it seems like the privacy concerns are
about:

1. Whether the ID mapping systems reveal who is talking to who.
2. Whether this creates persistent identifiers that would otherwise be
destroyed when people changed their location

Maybe Christian and Stephen would like to say more about their concerns
-Ekr

>
> Dino
>
> >
> > -Ekr
> >
> >
> > Is the identifier trackable even when its network location is not
> generally known, not advertised publicly, and possibly changing frequently?
> >
> > Dino
> >
> > > Some thing you should be hearing is that "long term identity of
> device" has almost the same privacy properties as "long term identity of
> the device's owner". You may think that identifying a random piece of
> hardware is no big deal, but it turns out that the network activity and
> network locations of that piece of hardware can be associated to those of
> its human owner. So you need the same kind of protection for these device
> identifiers as for human identifiers.
> > > --
> > > Christian Huitema
> > >
> >
> >
>
>

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 11 Oct 2017 13:13:03 -0700

typo

On Wed, Oct 11, 2017 at 12:49 PM, Padma Pillay-Esnault <[email-masked]

>
>
> Let's not *throw the baby with the bathwater ...
>
>
>
> Padma
>
>>
>>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 13:13:07 -0700

> Are the handshakes that establish the cryptographic keys used to encrypt the payload themselves encrypted? If it's IKE, the answer is probably yes, but if not, I don't know.

For SD-WAN implementations they use IKE. For RFC8061 (lisp-crypto) the Map-Request/Map-Reply exchange carry the EIDs in the clear. However, DTLS could be used but it would take more RTTs to get mappings in the encapsulator (causing more packet loss).

> Generally, I don't tend to think of things as being "private" or "non-private". Rather we talk about who has a given capability or piece of information. I think it's clear that in these cases the identifier was available to the machine doing the deencapsulation/reencapsulation. Obviously, that's worse for privacy than having it not have that information. How much worse depends on a lot of factors.

It needs the information for table lookups. So how private/trackable are IP addresses in packets today?

> In this particular, work, however, it seems like the privacy concerns are about:
> 

The charter talks about no designs or solutions. In LISP, the mappings are not revealed to the world, you need to sign Map-Registers (to make your network location available to others) and you need to sign Map-Requests (for retrieving network location).

And if you cannot get network location, you can't send packets (i.e. DoS) the destination or any nodes close to the destination (much better than what we have on the Internet today where anyone can send packets anywhere).

> 2. Whether this creates persistent identifiers that would otherwise be destroyed when people changed their location

We can solve this quite easily. I’ll use Bitcoin wallet addresses as an example. You can keep changing them for every transaction so there is no association analysis. We have a working group draft in the LISP WG that does just that.

> Maybe Christian and Stephen would like to say more about their concerns

Would welcome.

Dino

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Oct 2017 13:16:14 -0700

On Wed, Oct 11, 2017 at 1:13 PM, Dino Farinacci <[email-masked]> wrote:

> For SD-WAN implementations they use IKE. For RFC8061 (lisp-crypto) the
> Map-Request/Map-Reply exchange carry the EIDs in the clear. However, DTLS
> could be used but it would take more RTTs to get mappings in the
> encapsulator (causing more packet loss).
>

Uh really terrible? That's why things like Tor exist.

I'm not sure it's useful to continue with the technical side of the present
discussion. We're not trying to design a system here. The requirements for
the system the WG is to design is is properly the kind of question that
needs to be hashed out for the charter for the WG.

-Ekr

> The charter talks about no designs or solutions. In LISP, the mappings are
> not revealed to the world, you need to sign Map-Registers (to make your
> network location available to others) and you need to sign Map-Requests
> (for retrieving network location).
>
> And if you cannot get network location, you can't send packets (i.e. DoS)
> the destination or any nodes close to the destination (much better than
> what we have on the Internet today where anyone can send packets anywhere).
>
> We can solve this quite easily. I’ll use Bitcoin wallet addresses as an
> example. You can keep changing them for every transaction so there is no
> association analysis. We have a working group draft in the LISP WG that
> does just that.
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Oct 2017 12:34:19 -0700

On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:

>     but you do not need a reference to a permanent identity for that
>     -- systems similar to CGA would work just fine.
>
>  
>
> effectively allows authentication to modify the identifiers used by
> that device but also what the users of these identifiers can look up.
> If we had used "user of identifier" it would have been misconstrued
> for humans. So damn if you do and damn if you don't ... 
>

Some thing you should be hearing is that "long term identity of device"
has almost the same privacy properties as "long term identity of the
device's owner". You may think that identifying a random piece of
hardware is no big deal, but it turns out that the network activity and
network locations of that piece of hardware can be associated to those
of its human owner. So you need the same kind of protection for these
device identifiers as for human identifiers.

-- 
Christian Huitema

---

From: Sam Sun <[email-masked]>
Date: Wed, 11 Oct 2017 16:50:21 -0400

I second Padma on this!

I suggest we all work more constructively in refining our charter here, 
and be more focused on the tasks listed in the charter. It's probably 
too early to fight on the exact meaning of any particular word (e.g. 
'identity'). Features like privacy protection and discoverability can 
also be left for discussion when we work on the details of the 
framework, instead of being used to kill the whole proposal.

By the way, statements like "someone else failed before" should never be 
a reason to stop working on something of such importance.

Sam

On 10/11/17 1:32 PM, Padma Pillay-Esnault wrote:
>
>
> On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     Whow there!  You were part of the Namespace Research Group?  I
>>     think?  I was and we we worked a lot on this and came to the
>>     conclusion that there could be no conclusion.  Not even a rough
>>     concensus, it seemed.
>>
>>     I have been using 'identity' to apply to things for 20 years.
>>     Pretty much ever since I started working with things.  Anyone
>>     that holds the position that 'identity' means we are talking only
>>     about people are allowing their thinking to be clouded. 
>
>     I am concerned that the current proponents of the IDEAS work are
>     mainly resisting the feedback, treating it as some roadblock put
>     in the path of their work by misguided privacy purists, and
>     attempting to remove the roadblocks by adding some weasel words to
>     the charter. I would feel much more confident if these proponents
>     acknowledged the tension between privacy and stable identifiers of
>     any sort, if that tension was clearly noted in the charter, and if
>     privacy goals were clearly stated.
>
>
> If it is helpful to  move forward, I am willing to volunteer for this 
> work and discuss with anyone to ensure constructive feedback and 
> comments are addressed.
>
>
>     The tension is obvious. On one hand, the ephemeral identifiers
>     envisaged in the problem statement would pretty much align the
>     privacy properties of the ID to those of IPv6 privacy addresses,
>     and that's good. On the other hand, the requirement to perform
>     authentication on identities completely negates that property.
>
>     I would be fine if the support for "Unique and Permanent Identity"
>     was explicitly excluded from the charter.
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/lisp>
>
>
>
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Oct 2017 13:58:59 -0700

> Let me ask for your opinion Christian (or anyone else for that matter). If a device is assigned a private/public key-pair and the identifier for the device is a hash of the public-key, is the ident…
The proper question is, what are the privacy properties of the
identifier. And there, there are two big scenarios: casual observation,
and proof of ownership.

Casual observation is what happens when the identifier can be shown in
network traffic, logs, etc. There, the properties vary depending on how
the hash is constructed. If H = hash(public-key), then the identifier is
static, and the privacy properties are just the same as publishing the
public key -- which means, mostly terrible, as EKR said. On the other
hand, if H =
hash(public-key|something-that-changes-for-every-session-and-is-hard-to-predict),
then the properties are similar to privacy preserving IPv6 addresses.

Many of the scenarios seem to require proof-of-ownership, as in "proving
that the device can legitimately use the ID by demonstrating ownership
of the public key behind the ID". In that case, you are effectively
publishing the public key. If the public key is static and permanent,
that is a pretty strong identifier with terrible privacy properties. On
the other hand, if you can pick a new public key for every session, then
the privacy properties are reasonable.

-- Christian Huitema

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 14:25:27 -0700

> Uh really terrible? That's why things like Tor exist.

TOR exists because the network layer doesn’t have sufficient security. I’m preaching to the choir.

> I'm not sure it's useful to continue with the technical side of the present discussion. We're not trying 

It is useful because there is usually no technical discussion among people from different areas of expertise. The discussion tend to happen when a decision like this is made.

So I’ll take the discussion whenever I can get it!

> to design a system here. The requirements for the system the WG is to design is is properly the kind of question that needs to be hashed out for the charter for the WG.

I am trying to design a system. And we need more deployment experience. And I think an IETF working group can help facilitate this. Otherwise, people will do it else where and new protocols will surface OUTSIDE of the IETF. And that is when scale, security and interoperability is not priority. 

In the IETF, we are for the common good. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 14:29:47 -0700

> then the properties are similar to privacy preserving IPv6 addresses.

Just note how much better the above is than what we have today with both provider-assigned and provider-independent address allocations.

> publishing the public key. If the public key is static and permanent,

A single instance of a public-key is static but you don’t always have to use one identifier, and thereby don’t need to use one key-pair. And with a locator/ID separated architecture, you have flexibility to not require permanent addresses.

> the privacy properties are reasonable.

See Bitcoin example.

Dino

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Oct 2017 12:15:17 +0900

> I am trying to design a system. And we need more deployment
> experience.  And I think an IETF working group can help facilitate
> this. Otherwise, people will do it else where and new protocols will
> surface OUTSIDE of the IETF.  And that is when scale, security and
> interoperability is not priority.

old threat which sounds too much of my way or the highway, or i'll take
my ball and go home.

either it is simple to deal with the privacy concerns in the charter
wording or the proposed wg is really not all that concerned with the
privacy issue.  if the latter is the case, then indeed, the ietf may not
be the best place to work on it.

randy

---

From: Georgios Karagiannis <[email-masked]>
Date: Thu, 12 Oct 2017 13:22:24 +0000

Hi Stephen,

Thanks for your comments and insights on this topic, since you were an IETF Security AD for several years;

In the previous email I wanted to mention a possible IETF based solution (or an enhancement of this) that can be used to support the dynamic management/refreshing of Identities, i.e., using the Federation concept proposed in RFC7831, https://www.rfc-editor.org/rfc/rfc7831.txt

An enhanced ABFAB solution might be used to support the lifecycle management of Identities. The Identity provider stores the Identities and the Relying Party can be a controller that controls when the Identities need to be refreshed;

These entities and their relationships are illustrated graphically below (taken from RFC7831)

             ,----------\                        ,---------\
             | Identity |       Federation       | Relying |
             | Provider + <--------------------> + Party   |
             `----------'                        '---------'
                    <
                     \
                      \ Authentication
                       \
                        \
                         \
                          \
                           \  +---------+
                            \ |         |  
                             v| Client  |
                              |         |  
                              +---------+ 

                Entities and Their Relationships

Note that the above is for further study and has not been discussed with the IDEAS proponents;

Best regards,
Georgios

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Friday, October 06, 2017 11:32 AM
To: Georgios Karagiannis; Uma Chunduri; Joel M. Halpern; Benjamin Kaduk; Jari Arkko
Cc: [email-masked]; [email-masked]
Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)

Hiya,

On 06/10/17 08:49, Georgios Karagiannis wrote:
> Hi all,
> 
> Please note that I have looked into the output of the (concluded) IETF 
> ABFAB WG. In order to answer many questions/concerns that have been 
> raised during the previous IDEAS discussions, it might be useful to 
> consider the results of the IETF ABFAB WG.

I have no clue how GSS-API is even relevant here. abfab was a fine thing for JISC and friends to do to as a way to try broaden the benefit they got from their existing federated authentication setup, in their case involving UK universities. It is not at all clear that that would be even relevant if one wanted to build the kind of all encompassing IdPs envisaged in the ideas charter/draft.
The relationships that university account holders have with their own and other academic institutions and with applications running in such environments (that being the point of abfab) don't seem to me to generalise to lower layers in any useful manner.

In any case, if this proposal is only now at the point where you're starting to ponder the basic architecture then I'd conclude it's nowhere near ready to charter.
(As well as being a bad idea from the privacy POV;-)

WGs for such decisions can be a good plan when there's a few known architectural choices on the table, and if different sets of folks need a venue to reach consensus on which road to take - suggesting abfab at this point sounds like floundering around looking for reasons to exist tbh. (Sorry to be blunt and it may not be that, but it appears to be that to me.)

S.

> 
> Best regards, Georgios
> 
> 
> -----Original Message----- From: Ideas [mailto:[email-masked]] 
> On Behalf Of Uma Chunduri Sent:
> [mailto:[email-masked]] Sent: Wednesday, October 04, 2017 9:41 PM 
> To: Uma Chunduri <[email-masked]>; Benjamin Kaduk 
> with you. [Uma]: I meant IdP and it's an orthogonal discussion if both 
> roles played by same entity..
> 
> suitable keying. [Uma]: If it's a local system simple keying is enough 
> (in the expense of key management etc) as all devices may be managed 
> by the same org.
>