Subject: [arch-d] Network security services: fundamentally broken

From: Watson Ladd <[email-masked]>
Date: Wed, 26 Jan 2022 08:47:47 -0500

Dear all,

Networks cannot provide security services. That's the result of some
fundamental architectural properties of networks and devices and services.
All of this is in the BeyondCorp paper or if you remembered what a mess NFS
permissions are.

Security is about enforcing policies that let principals apply actions to
objects. And these principals are opaque to the network without significant
intermediation. Networks see hosts not the users on the hosts and thus
cannot enforce the requisite policies. The host is a confused deputy.

Concretely this is what made NFS a security issue. By trusting the client
to tell the truth about principals any attacker who could connect to the
network could just lie.

Intermediation raises many challenges: it's quite hard to do right as every
round of request smuggling attacks shows. It also has challenges with
ossification and not understanding new extensions to a protocol.

Such an attack is not possible with e.g. ssh. The server determines the
authentication of the connecting user directly. An attacker with network
access is unable to authenticate. And if we need endpoint policies those
can be enforced on the host via the standard mechanisms built into all OS's.

We also need to consider trust in the network. There is no difference
between a coffeeshop wifi or home wifi or an office wifi from a connecting
device. Any sort of mechanism that tries to authorize the network to
control the device faces some very thorny issues with this reality.

Lastly endpoint identification at network level provides a persistent
tracking vector, and suffers from the same principal identification issues.

Sincerely,
Watson Ladd

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jan 2022 15:42:28 +0100

On 26.01.22 14:47, Watson Ladd wrote:
> between a coffeeshop wifi or home wifi or an office wifi from a 
> connecting device. Any sort of mechanism that tries to authorize the 
> network to control the device faces some very thorny issues with this 
> reality.

Your last statement is true, but your 2nd statement is not.  This has to 
be broken out because "trust" is not a binary in many cases (in some 
cases it may be).  In an IoT world, a device needs to know which network 
to join, a device may need configure local credentials for local 
services, and all of that has to be bootstrapped.

Eliot

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 26 Jan 2022 16:25:24 +0100 (CET)

> Il 26/01/2022 14:47 Watson Ladd <[email-masked]> ha scritto:
> 
> Security is about enforcing policies that let principals apply actions to objects. And these principals are opaque to the network without significant intermediation. Networks see hosts not the users on the hosts and thus cannot enforce the requisite policies. The host is a confused deputy.
> 
> Concretely this is what made NFS a security issue. By trusting the client to tell the truth about principals any attacker who could connect to the network could just lie.
> 
> Intermediation raises many challenges: it's quite hard to do right as every round of request smuggling attacks shows. It also has challenges with ossification and not understanding new extensions to a protocol.
> 
> Such an attack is not possible with e.g. ssh. The server determines the authentication of the connecting user directly. An attacker with network access is unable to authenticate. And if we need endpoint policies those can be enforced on the host via the standard mechanisms built into all OS's.
> 
> We also need to consider trust in the network. There is no difference between a coffeeshop wifi or home wifi or an office wifi from a connecting device. Any sort of mechanism that tries to authorize the network to control the device faces some very thorny issues with this reality.
> 
IMHO this is one of many manifestations of one of the biggest gaps in the Internet's architecture: the lack of a standardized and generalized identity layer/functionality, i.e. something that is able to authenticate and/or transmit in a reliable way the identity of whoever currently owns a resource or a communication endpoint in a network-wide standard format, within an open and federated identity management model. We only have non-generalized, partial, often centralized solutions that only apply to specific protocols or ecosystems, ranging from PKI to Google's Web-wide single-sign-on to corporate OIDC systems to bl******in identity schemes and more.

Of course, the connection between an authenticated network-wide digital identity and a real-world physical and juridical entity would then be a different (hard) problem, and not a technical one. But if any application at any layer had a standard way of asking to the other endpoint (e.g. the wi-fi access point you are connecting to) "can you please tell me who you are?", and the other endpoint a way to decide whether they want to disclose any information and which information to disclose - even just a stable pseudonymous identifier with no actual personal information that you can change for each use case - then you would be able, for example, to put your own token into your ISP's router when you bring it home, put the same token into your devices, and then have all your devices tell automatically whether they are on a network you own or not, and behave accordingly. If you wanted, you could even have cafe owners choose to disclose a subset of their own State-validated digital identity 
 (we have that up and running in Europe) to anyone who connects to their wifi, so that people have a chance to check that this is actually the cafe's wifi as validated by appropriate public authorities.

We may have solutions for that, but we don't have solutions that work everywhere in the same way and do not require you to enter and validate the same information dozens of times in dozens of systems, which is a prerequisite for true success. That might be because too many people wanted to conquer the world with their own solution, I don't know. But some ambitious standardization and unification effort on this could address so many problems.

> Lastly endpoint identification at network level provides a persistent tracking vector, and suffers from the same principal identification issues.
> 
You cannot have full anonymity and reasonable security on the same network at once. Pick one.

-- vb.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 26 Jan 2022 11:55:23 -0500

On Wed, Jan 26, 2022, 10:25 AM Vittorio Bertola <
[email-masked]> wrote:

> Intermediation raises many challenges: it's quite hard to do right as
> every round of request smuggling attacks shows. It also has challenges with
> IMHO this is one of many manifestations of one of the biggest gaps in the
> Internet's architecture: the lack of a standardized and generalized
> identity layer/functionality, i.e. something that is able to authenticate
> and/or transmit in a reliable way the identity of whoever currently owns a
> resource or a communication endpoint in a network-wide standard format,
> within an open and federated identity management model. We only have
> non-generalized, partial, often centralized solutions that only apply to
> specific protocols or ecosystems, ranging from PKI to Google's Web-wide
> single-sign-on to corporate OIDC systems to bl******in identity schemes and
> more.
>

927 issues. Also see G+ real names dispute, Cher, Madonna, Muhammed Ali,
etc, etc. Also hosts and users are distinct and work in multiple confusing
ways and you have to deal with that. Maybe I don't want to tell Wicked
Grounds my real name when I check my email stopping in there for a coffee.

>
> Of course, the connection between an authenticated network-wide digital
> identity and a real-world physical and juridical entity would then be a
> different (hard) problem, and not a technical one. But if any application
> at any layer had a standard way of asking to the other endpoint (e.g. the
> wi-fi access point you are connecting to) "can you please tell me who you
> are?", and the other endpoint a way to decide whether they want to disclose
> any information and which information to disclose - even just a stable
> pseudonymous identifier with no actual personal information that you can
> change for each use case - then you would be able, for example, to put your
> own token into your ISP's router when you bring it home, put the same token
> into your devices, and then have all your devices tell automatically
> whether they are on a network you own or not, and behave accordingly. If
> you wanted, you could even have cafe owners choose to disclose a subset of
> their own State-validated digital identity (we have that up and running in
> Europe)
>

Citation needed. Also this isn't useful for lots of boring reasons related
to the fall of EV.

to anyone who connects to their wifi, so that people have a chance to check
> that this is actually the cafe's wifi as validated by appropriate public
> authorities.
>

If I want to control my devices that's what ssh is for. Why do we need
network support for this? Or to put another way why isn't this an
application layer issue?

I also don't see why I should give the cafe any more ability to intercept
my communications than an completely untrusted network.

>
>
> We may have solutions for that, but we don't have solutions that work
> everywhere in the same way and do not require you to enter and validate the
> same information dozens of times in dozens of systems, which is a
> prerequisite for true success. That might be because too many people wanted
> to conquer the world with their own solution, I don't know. But some
> ambitious standardization and unification effort on this could address so
> many problems.
>

I don't see how this follows at all. Real identity doesn't stop ransomware.
It doesn't stop RVE vulns in logging libraries. It doesn't solve
uncooperative jurisdictions.

 Note that anonymity also protects you from getting extrajuducially
executed when you post a video of police brutality or chopped up and sold
for parts when you post a meme of Winnie the Pooh. These are real problems
for real people.

We laughed at the USSR controlling copy machines and now you want to do the
same?

Sincerely,
Watson Ladd

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jan 2022 08:43:49 +1300

On 27-Jan-22 03:42, Eliot Lear wrote:
> Your last statement is true, 

Is it? I thought that we had actually solved that issue in BRSKI
(RFC 8995). The device intrinsically trusts an agent on the Internet
to tell it that the registrar it has discovered is entitled to control
the device itself. That could be used, for example, to ensure that
the device surrenders control when connected to a specific office
network, but not when connected to a coffeeshop network.

> but your 2nd statement is not.  This has to

Exactly.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jan 2022 21:00:04 +0100

> network, but not when connected to a coffeeshop network. 

BRSKI and similar are still in their youth.  A lot more work is needed.

Eliot

---

From: Watson Ladd <[email-masked]>
Date: Wed, 26 Jan 2022 15:05:22 -0500

> network, but not when connected to a coffeeshop network.

Why does the network matter? Why is it a local registrar and not e.g. an
ssh key that is granted control?

> Exactly.

The only part of this that has to do with "the network" is the wifi
credentials. Netbooted thin clients that pull down configuration over a
network share post authentication of the hardware have existed using the
application layer for years.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 27 Jan 2022 09:41:53 +1300

On 27-Jan-22 09:05, Watson Ladd wrote:
> 
> 
> On Wed, Jan 26, 2022, 2:43 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Why does the network matter? Why is it a local registrar and not e.g. an ssh key that is granted control?

A fair question. In the target scenario for RFC8995, it's local
by construction, and it's that local registrar that goes off to
the Internet to get a voucher that proves it has the right
to assert control. I suppose you could imagine a remote controller
too, but how could a controller back in the corporate network
know how to configure a device to work in a random coffee shop
network? Today we solve that problem using a corporate VPN
that's agile enough to work in any coffee shop.

> The only part of this that has to do with "the network" is the wifi credentials. Netbooted thin clients that pull down configuration over a network share post authentication of the hardware have existed using the application layer for years.

That's a narrow definition of "network".

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 26 Jan 2022 21:53:59 +0100

Any unqualified use of the term "trust" should be answered with
a question "trust to do what" ?

"Trust" is such an ambiguous, catchall word. Whenever possible
i recommend to use more precise words like Authorization, but
of course its hard.

> BRSKI and similar are still in their youth.  A lot more work is needed.

While that is probably true, the problem of Trust including
Authorization and other decision making is likely more
applicable to systems built on top of BRSKI, like ACP (RFC8994).

I only realized later in the game that in a quest towards fully
peer-to-peer autonomous networks, we would have to come up with
a replacement of very complex authorization/selection issue.

My classical example (sorry for repetition):

You are looking for a service in the network, for example search and
learn there are three different providers, e.g.: bing, google and phisher.

Which one do you select ? Lets say they even all self-announce
all the wonderful criteria you might be interested in: Best search results,
Fastest answers, highest confinement of user(search) data, lowest price,
best coffee, etc. pp. But of course there is no god-like authority that actually
third-party qualifies any of this to you. And you who is looking is a poor
autonomous system without 20 years of human knowledge that obviously phisher
must be the man-in-the middle attacker that is just proxying search/replies and selling 
your information because they where so stupid to even give their purpose away by name.

Aka: even on the web for humans, its not primarily about the
crypto to authenticate identities. That is just simple lower layer stuff.
Its about a complex mesh of information about those identities to come
up with selection/authorization and other important decisions about
those identities. And we have no good simple computerized versions of that.

Only when you actually are a bing, google or phisher can you afford to
build really big and complex automated solutions for some of these proplems.

But then you are oh, lets say a financial rating agency doing pretty
much exactly that type of ranking as well, and the year is 2008.
Aka: even with supposedly rather simple systems (just run the numbers),
past performance is no good predictor of future results.

So: Whom do you trust to do what, and why ?

Of course: Any sufficiently interesting security
problem can be solved with enough trusted third parties,
and there is a terrible absence of them where it counts.

Cheers
    Toerless

> 
> Eliot
> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

---

From: <[email-masked]>
Date: Thu, 27 Jan 2022 11:00:53 -0000

This is a vision that has been achieved, at least partially, within the global research & education. Eduroam and EduGAIN provide decentralised “open and federated identity management” for tens of millions of users, affiliated with thousands of organisations located in scores of countries, for network access and browser-based applications respectively. Both systems are built on technologies (RADIUS/EAP and SAML) that are 20+ years old and, despite their quirks, are still going strong.

I don’t think there are any insurmountable technical barriers to scaling and applying these models for a generalised identity layer. I believe the challenge is organisational. R&E has local, national, and global structures that are intrinsically amenable to federation; and that can absorb the (very modest) costs of operating these systems. There are few analogues that could provide a similar function for a general internet identity layer. Perhaps the ISP concept needs to be rebooted, so that the “I” also captures “identity” provision? If you’re paying for an internet service, your ISP certainly knows who you are…

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 27 Jan 2022 12:15:04 +0100 (CET)

> Il 26/01/2022 17:55 Watson Ladd <[email-masked]> ha scritto:
> 
> >  If you wanted, you could even have cafe owners choose to disclose a subset of their own State-validated digital identity (we have that up and running in Europe)
> > 
> 
> Citation needed. Also this isn't useful for lots of boring reasons related to the fall of EV.
> 
In Italy we now have 28 million SPID identities, just about half of the population has one. SPID is the Italian incarnation of eIDAS (so they could work EU-wide), you can get it from any of the registered operators, and you can use it to sign into any public website in the country / in Europe, without prior registration. More and more countries are working on this kind of solution, and other communities too (e.g. universities), but the Internet industry is rather going its own way, so that on global platform services your id is not provided by your country under a legal framework, but by a dominant private company under whatever policy suits their business - one id per each walled garden. This is not an acceptable solution in the long term and we need some technical leadership to make this thing standard, open, federated and interoperable.

Please note that this is completely unrelated to how much of your identity you want to share (except that if you can pick your identity operator, you can at least avoid those whose business model is about tracking and data monetization).

> 
> 
> > to anyone who connects to their wifi, so that people have a chance to check that this is actually the cafe's wifi as validated by appropriate public authorities.
> > 
> 
> If I want to control my devices that's what ssh is for. Why do we need network support for this? Or to put another way why isn't this an application layer issue?
> 
It is an application layer issue much like DNS is. It would be a sort of collateral network service that you can bring in at any layer when you need to do something with identities, including for example the simple proof that the current identity at the other end of the communication is the same as yesterday, without any further details.

> 
> I also don't see why I should give the cafe any more ability to intercept my communications than an completely untrusted network. 
> 
You may want not to connect at all to a completely untrusted network, i.e. a network whose owner does not disclose who they are, or that it is not what you think it is (e.g. it is someone nearby with an access point and an SSID similar to the one used by the cafe). At least, you get some reliable information to make your choice.

> I don't see how this follows at all. Real identity doesn't stop ransomware. It doesn't stop RVE vulns in logging libraries. It doesn't solve uncooperative jurisdictions.
> 
>  Note that anonymity also protects you from getting extrajuducially executed when you post a video of police brutality or chopped up and sold for parts when you post a meme of Winnie the Pooh. These are real problems for real people.
> 
> We laughed at the USSR controlling copy machines and now you want to do the same?
> 
No. I would just like to replicate the physical world, in which you get an identity document from a recognized public authority and then you decide when to show it, to whom, and to which extent; in some cases you want to prove who you are, in some others you just need to prove something (e.g. your age), in others you want to be pseudonymous (i.e. the other party can check it's you but does not know who you are, or gets fake information), and sometimes you want to be fully anonymous, but for certain functionalities anonymity is not accepted (e.g. you cannot board a flight or rent a car if you do not disclose an official proof of who you are). We'd just need to make that work digitally as a standard functionality of the whole network, rather than having piecemeal solutions spring up here and there.

And, I absolutely sympathize for dissidents in certain countries of the world, but it's 2022, and we cannot continue to optimize a global network that runs the entire economy and society of the planet for that use case only, as if all the other (way more common) use cases in democratic countries where reliable identification is a big pro or a true requirement did not exist. Let's just find a way to make them coexist as well as possible.

-- vb.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Jan 2022 12:39:07 +0100

On 2022-01-27, at 12:15, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> reliable identification

Was this about identity or (law-enforcement style) identification?
Your missive seems confused.

https://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf
Please go to page 8, law 4.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 27 Jan 2022 12:41:08 +0100

On 2022-01-27, at 12:15, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> 
> And, I absolutely sympathize for dissidents in certain countries of the world, but it's 2022, and we cannot continue to optimize a global network that runs the entire economy and society of the planet for that use case only,

The problem is that when we set up a system, we don’t know whether we are in that use case or not.  Not only because we may not know where we are; we also don’t know whether the country will be stolen next.

Grüße, Carsten

---

From: Watson Ladd <[email-masked]>
Date: Thu, 27 Jan 2022 06:43:58 -0500

On Thu, Jan 27, 2022, 6:15 AM Vittorio Bertola <
[email-masked]> wrote:

>  If you wanted, you could even have cafe owners choose to disclose a
> subset of their own State-validated digital identity (we have that up and
> running in Europe)
>
>
> In Italy we now have 28 million SPID identities, just about half of the
> population has one. SPID is the Italian incarnation of eIDAS (so they could
> work EU-wide), you can get it from any of the registered operators, and you
> can use it to sign into any public website in the country / in Europe,
> without prior registration.
>

I have significant questions about getting people to use certificates.

More and more countries are working on this kind of solution, and other
> communities too (e.g. universities), but the Internet industry is rather
> going its own way, so that on global platform services your id is not
> provided by your country under a legal framework, but by a dominant private
> company under whatever policy suits their business - one id per each walled
> garden.
>

Lots of sites use email as the identifier.

This is not an acceptable solution in the long term and we need some
> technical leadership to make this thing standard, open, federated and
> interoperable.
>

Why? I means sure it's a nice puzzle for anonymous credentials and getting
adoption but what are the actual things that this makes easier? We had
persona, we had U-prove, X500, etc, etc. And none of it took off.

>
>
> Please note that this is completely unrelated to how much of your identity
> you want to share (except that if you can pick your identity operator, you
> can at least avoid those whose business model is about tracking and data
> monetization).
>

This takes some serious cryptography to achieve.

>
> to anyone who connects to their wifi, so that people have a chance to
> check that this is actually the cafe's wifi as validated by appropriate
> public authorities.
>
>
> It is an application layer issue much like DNS is. It would be a sort of
> collateral network service that you can bring in at any layer when you need
> to do something with identities, including for example the simple proof
> that the current identity at the other end of the communication is the same
> as yesterday, without any further details.
>
>
> You may want not to connect at all to a completely untrusted network, i.e.
> a network whose owner does not disclose who they are, or that it is not
> what you think it is (e.g. it is someone nearby with an access point and an
> SSID similar to the one used by the cafe). At least, you get some reliable
> information to make your choice.
>

The internet threat model means untrusted networks don't matter.

> I don't see how this follows at all. Real identity doesn't stop
> ransomware. It doesn't stop RVE vulns in logging libraries. It doesn't
> solve uncooperative jurisdictions.
>
> No. I would just like to replicate the physical world, in which you get an
> identity document from a recognized public authority and then you decide
> when to show it, to whom, and to which extent; in some cases you want to
> prove who you are, in some others you just need to prove something (e.g.
> your age), in others you want to be pseudonymous (i.e. the other party can
> check it's you but does not know who you are, or gets fake information),
> and sometimes you want to be fully anonymous, but for certain
> functionalities anonymity is not accepted (e.g. you cannot board a flight
> or rent a car if you do not disclose an official proof of who you are).
> We'd just need to make that work digitally as a standard functionality of
> the whole network, rather than having piecemeal solutions spring up here
> and there.
>

Why "the network"? And not the applications that need such things? Part of
the whole philosophy is enabling permissionless innovation by not having
the network need enhancements. We don't teach routers oauth.

I'm not saying this wouldn't be useful. I am saying that it isn't something
that we should think of as a network function for core architectural
reasons.

>
>
> And, I absolutely sympathize for dissidents in certain countries of the
> world, but it's 2022, and we cannot continue to optimize a global network
> that runs the entire economy and society of the planet for that use case
> only, as if all the other (way more common) use cases in democratic
> countries where reliable identification is a big pro or a true requirement
> did not exist. Let's just find a way to make them coexist as well as
> possible.
>

Are there actual services that have a problem? Could you list some
examples? And anonymity isn't just about the government in authoritarian
countries.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jan 2022 12:39:03 -0500

The one-word notion of identity seems far too narrow and prescriptive. The
provider of a resource should be able to decide:

* I only trust entities that I have validated before (e.g., my customers)
* I only trust entities that have a public, traceable identity with
recourse (i.e., individuals where I have some hope of using local law
enforcement to deal with misbehavior)
* I only trust entities that have some other property (e.g., originate with
a local ISP or another university)

We obviously have a network identity today - the IP address. Lots of
systems effectively rely on this "identity" to make access control
decisions. Clearly, it's an awful, terrible, no-good idea to rely on that
identity by itself, but there's a significant advantage of that particular
model as a complement to other identities. If I only green-list
IP addresses known to be my employees (or those known to be from local
ISPs), I greatly reduce the attack surface, e.g., if an ssh key leaks or
the ssh software shows up on the CVE list. Such a leak or bug is still bad,
but a permit list raises the bar since the attacker now also has to
compromise one of the permit-list hosts and that may just buy you a bit of
time to recognize and fix the problem (and make it much harder for
adversaries to scan IP addresses for vulnerabilities or rely on shodan).

For the same reason, I suspect that corporate VPNs will stick around even
with zero-trust - it's just an additional hurdle to the attacker, i.e.,
necessary, but not sufficient, to gain access.

And we all know that, despite serious limitations, various spam blocklists,
based on sender reputation, will likely be with us for the duration.

We use these reverse-routability communication identifiers at all layers -
the typical password recovery mechanism by email simply ensures
communication reachability.

Thus, I think it's more productive to think of identity as layered. We do
this routinely in real life - your work badge or easily-stolen car
transponder gets you into the front door (and the guard may only do a rough
visual inspection easily circumvented by an amateur forger, but may use
rough facial recognition, too) or the company parking garage, but you need
additional permissions and credentials (such as a door code or iris scan)
to get into the machine room. Few people would advocate getting rid of
the reception desk just because a spy can print a badge that passes the
1-second inspection by the guard.

After all, for many cases, the goal is similar to a home alarm system sign
on the front lawn: not to protect against a determined state-level
attacker, but make the drive-by thief choose another home to burglarize.
(And, in the long run, make being a burglar an economically unattractive
occupation.)

The question then is whether an additional lower-layer or common identity
mechanism other than one coupled directly to reverse routability (IP
address, email) offers additional value. This is independent of who creates
the identity and how reusable this is.

Henning

On Thu, Jan 27, 2022 at 6:15 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> without prior registration. More and more countries are working on this
> kind of solution, and other communities too (e.g. universities), but the
> Internet industry is rather going its own way, so that on global platform
> services your id is not provided by your country under a legal framework,
> but by a dominant private company under whatever policy suits their
> business - one id per each walled garden. This is not an acceptable
> solution in the long term and we need some technical leadership to make
> this thing standard, open, federated and interoperable.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jan 2022 14:32:22 -0500

This Eduroam example is a good one for a particular class of applications
and conditions:

* privileges are relatively non-sensitive (access to Wi-Fi and scientific
journals, say) - Eduroam won't allow you to register for classes or access
the student grades database;
* there are clear mutual trust and enforcement mechanisms - if a student
from institution A misbehaves using resources at institution B, the dean of
students or IT department at B calls up A and will likely find a
sympathetic ear (and the misbehaving student will suffer dean's discipline
or be kicked off the local network);
* the precise identity of the "visiting" student or faculty is not
relevant, just that they are a student of a generally-trusted peer
institution;
* if an institution were to misbehave (e.g., allow anybody to get student
IDs or violate the reasonable expectations of privacy of 'visiting'
students by publishing the email address and list of controversial papers
they are reading), there are mechanisms in place to kick out the
institution, and the value of being part of the club is high;
* the number of such institutions is relatively small (thousands, not
millions) and static (universities get founded and go belly-up, but churn
is probably less than 0.1% a year, particularly among the larger
institutions that participate in Eduroam - I don't think Trump University
gave you Eduroam privileges).

But these conditions are harder to replicate outside the relatively
"friendly" and static world of higher education. I suspect you could set up
similar systems within medicine and (air) transportation, and versions of
these exist, from what I understand, although I lack any knowledge of their
nature and organization.

Henning

On Thu, Jan 27, 2022 at 6:01 AM <[email-masked]> wrote:

> This is a vision that has been achieved, at least partially, within the
> global research & education. Eduroam and EduGAIN provide decentralised “open
> and federated identity management” for tens of millions of users,
> affiliated with thousands of organisations located in scores of countries,
> for network access and browser-based applications respectively. Both
> systems are built on technologies (RADIUS/EAP and SAML) that are 20+ years
> old and, despite their quirks, are still going strong.
>
>
>
> I don’t think there are any insurmountable technical barriers to scaling
> and applying these models for a generalised identity layer. I believe the
> challenge is organisational. R&E has local, national, and global structures
> that are intrinsically amenable to federation; and that can absorb the
> (very modest) costs of operating these systems. There are few analogues
> that could provide a similar function for a general internet identity
> layer. Perhaps the ISP concept needs to be rebooted, so that the “I” also
> captures “identity” provision? If you’re paying for an internet service,
> your ISP certainly knows who you are…
>
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 Jan 2022 00:55:48 +0100

Would be fun to learn more how much this supposedly "friendly"
system has been put to a test and performed in face of easy to construct
challenges.

1. Western student goes to islamic rule country, posts (via eduroam account)
   mohammed carricatures to the local universitys social network site.
2. Traditional islamic country student goes to USA university, posts
   (via eduroam account) dismissive statements about womens and other diversity
   groups equal rights.

If the dean of the students own universities would instantiate local
university repercussions to their pupil in the situations (on behalf of
the visiting universities dean), that would enforce the opposite of
that universities own values that they typically teach pupils to live on.
If they don't, they risk cohesion of the federation.

I would bet that given how authoritarian universities can still be
over their students (no right to education at that level in most countries),
deans would rather punish against their own value than to risk the federation,
and i am not sure if that is a good thing given how we already have enough
proliferation of arbitrary authoritarism. Besides, they would likely get 
a good amount of problem locally whatever they choose to do.

Aka: any multi-domain enforcement/punishment policies are IMHO always difficult
unless they are meticulously worked out upfront. And even then...

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jan 2022 19:23:43 -0500

eduroam has been around for twenty years. Do you have any evidence of your
scenario happening in practice rather than "could happen"? No human-made
system can avoid potential pitfalls, but is your opinion that we should
just abandon eduroam given the dangers you posit?

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 Jan 2022 02:31:11 +0100

On Thu, Jan 27, 2022 at 07:23:43PM -0500, Henning Schulzrinne wrote:
> scenario happening in practice rather than "could happen"?

Not sure why you want to be so defensive and deflect the question.
Would you have done the same if i had asked about scenarios of Harrisburg, Chernobyl or
Fukoshima before each of them happened ?

Of course i do not have evidence, why else would i ask ? I just wanted
to discuss fragility of model.  But let me give you a recent example that
IMHO is somewhat in kind:

Germany had a law, 103.1 StGB that makes insults to foreign dignitaries of state
a punishable offense if the German government asks for prosecution (that German
goverment stands in for your eduroam scenario local dean).

That law was not used at least since WW2 (AFAIK),
until in 2016 a german comedian triggered Tayyip Erdogan (president of turkey)
to call for it, causing a fun international incident, ultimately making Merkel
feel obliged to Erdogan to ask for a federal investigation nobody in germany wanted,
Merkel apologizing later and Germany finally eliminating the law 2 years later,
thereby getting rid of a quaint bit of "federation over local laws", that probably
had survived from the 19th century because nobody bothered to proactively check laws for risks
of such laws and fix them proactively (https://en.wikipedia.org/wiki/B%C3%B6hmermann_affair).

And i of course still think that Germany paid for this incident somehow
financially through the nose in secret given all those dependencies on Turkey for
refugee control and NATO.

I think its not too far fetched to imagine possible parallels between this case
and e.g. a US vs eastern university incident, financial dependencies of the
US university from (loss of) overseas funding, and my scenarios.  Arguably,
i wouldn't recommend anyone to repeat what Boehmerman did while being logged
into eduroam in person in the other country though, so thats where the comparison
may fail, but there have been enough more radical political activists than Boehmerman.

Aka: Decades of absence of evidence is no proof of absence of possibility
or opportunity, at best just absence of a party triggering the event,
and that can quickly change.

> No human-made

You started the discussion alredy pointing out how limited and supposedly
well-controllable the eduroam scenario is. My question was if we still couldn't learn
anything from its experience for broader, potentially more challenging
federation scenarios that this whole thread started out with. And i was
offering the type of scenarios that could challenge eduroam to see if 
anything in that ballpart was observed and how it was or likely would be handled.

And again, i have to observe a very defensive, deflective reply from you. Why ?

It may well be that we can not learn much from eduroam for other cases,
which i think is also what you lead your description in with, just because
it never was severely challenged so far. Then again, even when i was at university
in network administration, 25 years ago (in my memory a more friendy, nicer time
in computer networking), we already did have instances where we had to work
with the police for computer/networking incidents by students, so i would be
surprised if there is not anything to be learned from eduroam experiences either.

Cheers
   Toerless

-- 
---
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Jan 2022 17:51:14 -0800

> Not sure why you want to be so defensive and deflect the question.
,,

And again, i have to observe a very defensive, deflective reply from you.
> Why ?

Toerless, can you please keep this professional and not personal.

-Ekr

> > > > from institution A misbehaves using resources at institution B, the
> dean
> > > of
> > > > "friendly" and static world of higher education. I suspect you could
> set
> > > up
> > > > > global research & education. Eduroam and EduGAIN provide
> decentralised
> > > “open
> > > > > systems are built on technologies (RADIUS/EAP and SAML) that are
> 20+
> > > years
> > > > > and applying these models for a generalised identity layer. I
> believe
> > > the
> > > > > layer. Perhaps the ISP concept needs to be rebooted, so that the
> “I”
> > > also
> > > > > IMHO this is one of many manifestations of one of the biggest gaps
> in
> > > the
> > > > > non-generalized, partial, often centralized solutions that only
> apply
> > > to

---

From: Christian Huitema <[email-masked]>
Date: Thu, 27 Jan 2022 17:51:47 -1000

>     (via eduroam account) dismissive statements about womens and other diversity

Toerless,

Both of your scenarios are of the form "student goes to some place and 
acts stupid". As Henning mentioned, the Eduroam system has been working 
for 20 years. During these 20 years, I would be very surprised if no 
student ever did something illegal or offensive. Students in general are 
not known for their deep respect of rules, young students have been 
doing stupid things consistently since there ever were universities. You 
have to expect that offenses similar to what you hypothesize happened, 
and the world did not stop. But Henning actually mentioned a key 
property of Eduroam that deal with these issues: "privileges are 
relatively non-sensitive (access to Wi-Fi and scientific journals, say) 
- Eduroam won't allow you to register for classes or access the student 
grades database."

That is, Eduroam is not an all encompassing identity system. The Eduroam 
identity is not in the some class as, say, a passport. It is more like a 
library card, good for what it does, but not for unexpected and 
unrelated purposes. And I think that there is a valuable lesson there. 
Some network architects may dream of a generic identity system that 
would be the basis for all kind of services, but limited systems that 
provided identification for a limited set of purposes and services are 
much more practical.

-- Christian Huitema

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 27 Jan 2022 23:37:57 -0500

Just to slightly disagree: even a passport doesn't give you unlimited
access - you may get to cross a border (but not if you're on some kind of
do-not-fly list) and you may be able to buy alcohol or vote (in places that
require government ID to vote). But it doesn't entitle you to get into a
government or corporate building, get a loan, access email or drive a
vehicle. Thus, it provides some level of authentication and attests to some
properties (citizenship and age, mostly), but it's fairly limited in the
authorizations it offers without additional data or policy. This is why
most of us don't carry a passport unless we're traveling internationally -
it's pretty useless in most day-to-day authorization interactions.

What makes a passport (and similar primary identity documents) different is
that they are used for cross-domain identity - I probably have to show a
passport or similar document when starting a university job so that the
university can do a background check on me, even if I will use a different
name there. Similarly, I have to show some kind of stronger ID to get a
NYPL library card:

When applying for a New York Public Library card in person, or providing
proof of their identity to validate a card received in the mail, an
applicant must show proof that he/she lives, works, attends school, or pays
property taxes in New York State. To apply for a card:

Adults may provide only one piece of identification if it is *1* of the
following valid New York State or City IDs:

   - Current driver's license
      - Current photo learner's permit
      - Current non-driver's identification (includes IDNYC)

(There are various alternative IDs you can provide, but you need to provide
two of the weaker ones.)

But, as Christian said, the library card only conveys very limited
privileges, so the library has no need to check my credit record or my
criminal record and possession of the library card likely won't get me any
privileges beyond the library building.

https://pages.nist.gov/800-63-3/sp800-63-3.html and
https://www.nist.gov/system/files/documents/2020/07/02/SP-800-63-3-Implementation-Resources_07012020.pdf
discuss related issues.

But for most network cases, whether an identity (key, email address, user
name) is traceable to some real-world physical ID is both invisible and
very specific to the application.

We're seeing a similar struggle with phone numbers right now. STIR/SHAKEN
(IETF work, for those not following this domain closely) is essentially an
identity-proving mechanism. The phone number is signed by the originator,
but you have three levels of attestation (A, B and C). A means "I, phone
company X [signer], attest that I know this customer and have assurance
that the customer is authorized to use this number". B and C are weaker.
Increasingly, phone companies will need to follow KYC (know your customer)
rules, but this is primarily relevant for business customers. Note that it
says nothing about the name of the customer (that's the caller ID database,
completely separate) or whether they are a highly-rated business.

The question is whether something similar is valuable at the network layer.
A voluntary, customer-requested assertion "I, Comcast, have been asked to
attest that this IP address is the same customer X as the different IP
address used last week" could be useful, but I'm not sure how useful.

Henning

---

From: Christian Huitema <[email-masked]>
Date: Thu, 27 Jan 2022 19:14:06 -1000

> very specific to the application.

There is another related issue, the potential for abuse. For example, 
many web sites offer the option of authenticating through a few big 
systems (e.g., Google, Facebook) or by entering an e-mail address and 
going through email-based verification of identity. The "email address" 
option looks more private, and certainly avoids the immediate leakage of 
privacy sensitive information to the overlords of surveillance 
capitalism. But the email address is in practice a unique identifier. We 
have thus a "latent privacy leak" -- services could retrieve all the 
sites for which a particular e-mail address has been registered, 
disclosing a lot of information about the owner of the address. That's 
not very good either.

-- Christian Huitema

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 Jan 2022 08:10:39 +0100

Thanks, Christian,

I was trying to point out that the core problem of federations across
diverse entities even when thought to be limited in scope/rights.
It is that the policy enforcement, as through example by the mutual deans,
is a built in weak point when you actually do not have a precise mutually
agreed AND enforcible policy sytem in place that has been well examined 
against possible "attacks" / "weak points" (similar to what we attempt
to do in our RFC security sections, just for policy enforcement). 

The other point of course being that a permissions/authorizationn that looks limited
(because it may not allow to lend books/book classes) may easily
incur undesired bigger consequences because of mutual policy misunderstanding
(a kinder word for "stupid") which is then unveiling the missing thorough
vetting of possible conflicts of implied policies.

I am sure that in the case of eduroam all these cases may have been resolved
by the absolute power that deams may have over their pupils, which is of
course exactly one property that doesn't easily work in other systems.

Not even down to lower grade schools where you do often have a right of eductation,
and deans decisions about school kids are regularily turned over in a
real court, severely limiting abilities to come up with arbitrary policies.

I always felt eduroam was/is a cool system, but of course its hard to
understand what has been learned about those potential problematic aspects
(because its unlikely any of the challenging cases are getting very
 public) to figure out if/how to apply (or not) these methodologies to potentially
be reaplied elsewhere.

Cheers
    toerless

On Thu, Jan 27, 2022 at 05:51:47PM -1000, Christian Huitema wrote:
> Both of your scenarios are of the form "student goes to some place and acts
> stupid". As Henning mentioned, the Eduroam system has been working for 20
> years. During these 20 years, I would be very surprised if no student ever
> did something illegal or offensive. Students in general are not known for
> their deep respect of rules, young students have been doing stupid things
> consistently since there ever were universities. You have to expect that
> offenses similar to what you hypothesize happened, and the world did not
> stop. But Henning actually mentioned a key property of Eduroam that deal
> with these issues: "privileges are relatively non-sensitive (access to Wi-Fi
> and scientific journals, say) - Eduroam won't allow you to register for
> classes or access the student grades database."
> 
> library card, good for what it does, but not for unexpected and unrelated
> purposes. And I think that there is a valuable lesson there. Some network
> architects may dream of a generic identity system that would be the basis
> for all kind of services, but limited systems that provided identification
> for a limited set of purposes and services are much more practical.
> 
> -- Christian Huitema

-- 
---
[email-masked]

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 28 Jan 2022 09:20:12 +0100 (CET)

> Il 27/01/2022 12:39 Carsten Bormann <[email-masked]> ha scritto:
> 
>  

It was indeed about identity, i.e. something that the user fully controls. Showing your official identity to some other entity whenever you want (voluntary self-identification) is just a sub-case of that. You may have more than one identity from more than one provider and pick the one you want to use. This is nothing new, the new part would be unifying and generalizing the multiple limited scope systems we have today (which might be impossible by now because of ossification and user/market dynamics - my original point was about this not having been foreseen within the architecture since the beginning).

Law enforcement wants to identify people who do not want to share their identity, and this would be outside the scope of such a mechanism, though uniformity might help them to develop a working "identity interception" system - but it's like saying that email is easier to intercept because everyone exchanges email with the same protocol rather than using ten different systems. You don't do security by protocol obscurity or fragmentation.

(thanks for the interesting pointer)

-- vb.

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 28 Jan 2022 09:30:05 +0100 (CET)

> Il 28/01/2022 04:51 Christian Huitema <[email-masked]> ha scritto:
> 

Practical for whom? It is more practical for people who want to set up such a system, as limiting the scope gets them rid of many organizational complexities. However, if they could just use an existing standard system for users to present identities, that would be even more practical - they'd just need to implement a "login form" (the relying party, in OIDC terms), and all the software would possibly already be there as open source, like for all other basic Internet protocols. (If they wanted, they could still also emit their own identities and require users to present one of those identities only, when using their services.)

For users, having to cope with dozens of different limited scope systems is not practical - it is a nightmare. Just try to move to a new address and then go update all your registrations one by one on each website that you use and that needs to have your correct home address to send you stuff or generate valid invoices. Changing email address is even worse, as that's your actual identifier on most systems.

True, you may use the multiplication of systems as a way to increase your privacy by decoupling information, but that could also be achieved with proper design. It's the same in the instant messaging world; people often partition their contacts by use case and use e.g. Telegram for friends, Whatsapp for social circles and Slack for work, but that does not make walled gardens more desirable in architectural terms; you should just have one IM client with a proper UI.

-- vb.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 Jan 2022 10:39:09 +0100

Hi Henning

On 28.01.22 05:37, Henning Schulzrinne wrote:
>
> The question is whether something similar is valuable at the network 
> layer. A voluntary, customer-requested assertion "I, Comcast, have 
> been asked to attest that this IP address is the same customer X as 
> the different IP address used last week" could be useful, but I'm not 
> sure how useful.

There are a set of related questions:

  * Which device(s) committed a cyberattack from IP addresses X, Y, and
    Z at given points in time?
  * Where did was that device at a particular time?
  * Which addresses did a given suspect use at a given time and who did
    they talk to?
  * Add your own LE questions here...

Just as you see with SHAKEN and STIR, absent accountability a numbering 
resource will be abused.  This is the flipside of 
authentication/authorization.  Which also reminds me: this conversation 
is a bit tangled between the two.  A library card is a form of 
authentication bound to a certain authorization set.  If an IP address 
is authenticated, there's pretty much no implied authorization; although 
one can be layered on top.

Should it be?  To me, there's a certain value in the IOT world, where 
devices access a small subset of the Internet to perform their 
functions; but the binding they use is via the DNS.  Thus name-based 
authorization must follow down the resolution path to either an 
enforcement or audit point.

There's less value to this for general purpose computing like smart 
phones.  But what does that mean about the trust model we employ for 
each of these classes of devices?

Eliot

---

From: <[email-masked]>
Date: Fri, 28 Jan 2022 12:39:58 -0000

This isn’t the venue to correct the strawmen that have been raised on this thread. I’ll just note that academic federations do not, in general, possess the kinds of properties raised by some commentators because the use-cases do not require them. It is an outcome of need, not a deficiency of the technology or approach. For example, it would be trivial to communicate the identity of an eduroam user. It isn’t implemented because it isn’t needed for the use case.

I agree with other commentators that eduroam’s success is, in part, due to the social and organisational trust relations within that community. Higher Education is rich in these. They offer fertile soil for “open and federated” systems to take root, just as it did for the early Internet.

By the same token, I dispute the notion that the academic origins of eduroam and other federations diminishes their relevance. We all remember the time when the future of networking belonged to acronyms that are now long-forgotten. At that time, IP was often considered an aberration of academic and research networks. And yet, despite this legacy, it became the future.

The Internet community found ways to translate IP from academia to a global audience. To my earlier point, this was facilitated by the morphing and creation of organisational structures that could support the proliferation of the technical infrastructure. Today, academic federations present a similar opportunity for the Internet community. They offer hard-won lessons that could help to arrest the centralisation and balkanisation of Internet identity. It seems a shame to pass on the opportunity, when there is such alignment in vision.

From: Henning Schulzrinne <[email-masked]> 
Sent: 27 January 2022 19:32
To: [email-masked]
Cc: Vittorio Bertola <vittorio.bertola=[email-masked]>; Watson Ladd <[email-masked]>; [email-masked]
Subject: Re: [arch-d] Network security services: fundamentally broken

This Eduroam example is a good one for a particular class of applications and conditions:

* privileges are relatively non-sensitive (access to Wi-Fi and scientific journals, say) - Eduroam won't allow you to register for classes or access the student grades database;

* there are clear mutual trust and enforcement mechanisms - if a student from institution A misbehaves using resources at institution B, the dean of students or IT department at B calls up A and will likely find a sympathetic ear (and the misbehaving student will suffer dean's discipline or be kicked off the local network);

* the precise identity of the "visiting" student or faculty is not relevant, just that they are a student of a generally-trusted peer institution;

* if an institution were to misbehave (e.g., allow anybody to get student IDs or violate the reasonable expectations of privacy of 'visiting' students by publishing the email address and list of controversial papers they are reading), there are mechanisms in place to kick out the institution, and the value of being part of the club is high;

* the number of such institutions is relatively small (thousands, not millions) and static (universities get founded and go belly-up, but churn is probably less than 0.1% a year, particularly among the larger institutions that participate in Eduroam - I don't think Trump University gave you Eduroam privileges).

But these conditions are harder to replicate outside the relatively "friendly" and static world of higher education. I suspect you could set up similar systems within medicine and (air) transportation, and versions of these exist, from what I understand, although I lack any knowledge of their nature and organization.

Henning

On Thu, Jan 27, 2022 at 6:01 AM <[email-masked] <mailto:[email-masked]> > wrote:

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 Jan 2022 11:19:32 -0500

We have a mechanism to deal with this, namely running your own domain for
such purposes and then creating per-site identifiers (not perfect since the
domain is specific to you, but probably good enough). But that's obviously
beyond the reasonable reach of 99% of the internet user population.

The nice thing about the email-as-identifier (or
phone-number-as-identifier) is that it provides a
reasonable password recovery mechanism that scales well and seems to be
understandable by non-technical users.

It seems difficult to create a system that
* provides a communication-enabled identifier (i.e., where the site can
send a reset link)
* has an identifier that is human-readable (so that one can keep records of
important, but rarely used ones)
* is not email or SMS (or similar)
* allows per-site user names without confusing the user (and password
managers are too fallible to make that work)
* allows easy changes of the communications provider (e.g., email service
or SMS service)
* does not cost money similar in amount to a domain registration
($10-$20/year)

In the phone number case, you at least have number portability in many
countries and it's relatively easy to set up a "burner" number (e.g.,
Google Voice), although probably not 100s of them.

Many low-sensitivity sites have made the password optional - you provide
your email or phone number, click on the "reset" link sent and then get a
very long-lived cookie (months, if not longer), so that login is
essentially through a secret stored in your browser, as long as you are
using that device.

Henning

---

From: Christian Huitema <[email-masked]>
Date: Fri, 28 Jan 2022 06:40:27 -1000

On 1/27/2022 11:39 PM, Eliot Lear wrote:
> Just as you see with SHAKEN and STIR, absent accountability a 
> numbering resource will be abused.  This is the flipside of 
> authentication/authorization.  Which also reminds me: this 
> conversation is a bit tangled between the two.  A library card is a 
> form of authentication bound to a certain authorization set.  If an IP 
> address is authenticated, there's pretty much no implied 
> authorization; although one can be layered on top. 

At a minimum, an IP address is a contract between a host and a network 
provider, allowing the host to send and receive IP packets through a 
specified interface (or set of) using the specified address.

-- Christian Huitema

---

From: tom petch <[email-masked]>
Date: Fri, 28 Jan 2022 17:07:34 +0000

From: Architecture-discuss <[email-masked]> on behalf of Henning Schulzrinne <[email-masked]>
Sent: 28 January 2022 16:19

We have a mechanism to deal with this, namely running your own domain for such purposes and then creating per-site identifiers (not perfect since the domain is specific to you, but probably good enough). But that's obviously beyond the reasonable reach of 99% of the internet user population.

The nice thing about the email-as-identifier (or phone-number-as-identifier) is that it provides a reasonable password recovery mechanism that scales well and seems to be understandable by non-technical users.

It seems difficult to create a system that
* provides a communication-enabled identifier (i.e., where the site can send a reset link)
* has an identifier that is human-readable (so that one can keep records of important, but rarely used ones)
* is not email or SMS (or similar)
* allows per-site user names without confusing the user (and password managers are too fallible to make that work)
* allows easy changes of the communications provider (e.g., email service or SMS service)
* does not cost money similar in amount to a domain registration ($10-$20/year)

<tp>
The eduroam system that I am familiar with is slightly different.  A member of the university -  staff, student, whatever -  has an e-mail address which is not used by Eduroam,  Rather, the person has a short alphanumeric identifier which is unique and goes back to b.c. (before computers).  The identifier for Eduroam is this <identifier>@<domain name of university> the e-mail address is typically jane.doe@<domain name of university>.

And Eduroam is used for operational systems of the University which, to me, should have a slightly higher leverl of security than the systems mentianed above.

Tom Petch

In the phone number case, you at least have number portability in many countries and it's relatively easy to set up a "burner" number (e.g., Google Voice), although probably not 100s of them.

Many low-sensitivity sites have made the password optional - you provide your email or phone number, click on the "reset" link sent and then get a very long-lived cookie (months, if not longer), so that login is essentially through a secret stored in your browser, as long as you are using that device.

Henning

On Fri, Jan 28, 2022 at 12:14 AM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

-- Christian Huitema

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 Jan 2022 12:38:41 -0500

The accountability part is an important facet and indeed drives STIR/SHAKEN
- the main advantage is that violators of do-not-call laws can be found
quickly and with reasonable effort.

A very common scenario is "some compromised device on your network is
attacking my system". Universities deal with this all the time, given that
they allow pretty much any device to connect to their network and often
don't have NATs. There is no issue of protecting the privacy of the user -
the user likely doesn't know that their device has found a gig as a DDOS
vector. With dynamic allocation of IP addresses, it's tedious to do this
mapping. Thus, this issue reaches well beyond the IoT realm.

Finding the misbehaving compromised device behind a NAT, residential or
corporate, is even more challenging, given the lack of an IT department.
You'd have to be able to map the source port at a specific time to a
specific device.

Henning

On Fri, Jan 28, 2022 at 4:39 AM Eliot Lear <[email-masked]> wrote:

> layer. A voluntary, customer-requested assertion "I, Comcast, have been
> asked to attest that this IP address is the same customer X as the
> different IP address used last week" could be useful, but I'm not sure how
> useful.
>
>    - Which device(s) committed a cyberattack from IP addresses X, Y, and
>    - Where did was that device at a particular time?
>    - Which addresses did a given suspect use at a given time and who did
>    they talk to?
>    - Add your own LE questions here...
>
> authentication/authorization.  Which also reminds me: this conversation is
> a bit tangled between the two.  A library card is a form of authentication
> bound to a certain authorization set.  If an IP address is authenticated,
> there's pretty much no implied authorization; although one can be layered
> on top.
>
> devices access a small subset of the Internet to perform their functions;
> but the binding they use is via the DNS.  Thus name-based authorization
> must follow down the resolution path to either an enforcement or audit
> point.
>
> phones.  But what does that mean about the trust model we employ for each
> of these classes of devices?
>
> Eliot
>

---

From: Christian Huitema <[email-masked]>
Date: Fri, 28 Jan 2022 08:13:08 -1000

> We have a mechanism to deal with this, namely running your own domain for such purposes and then creating per-site identifiers (not perfect since the domain is specific to you, but probably good en…

Depends what your goal is. If the goal is to disable the kind of 
correlations used by the ad industry (aka, surveillance), then "running 
your own domain" is not very efficient -- the domain name identifies 
you, regardless of the user part. Henning was mentioning "burner phones" 
as the tool to escape surveillance based on phone numbers. To escape 
surveillance based on email names, you will need to create "burner 
email" inside a big email service such as gmail or yahoo. But then, you 
also have to do that "without confusing the user", which is not so easy 
with basic email. The burner phone approach works because the phone 
rings inside your pocket, so you know when to look at it. With burner 
email, you will have to program your mail agent to go check all the 
burner mailboxes. We don't have software that does that. Or, you will 
have to ask the burner email server to forward the mail, but then you 
need the server to cooperate and also protect the identity of the 
forwarding address.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 29 Jan 2022 09:10:20 +1300

Tom,

> The identifier for Eduroam is this <identifier>@<domain name of university> the e-mail address is typically jane.doe@<domain name of university>.

In all the cases that I know, jane.doe@<domain name of university> is just an alias for <identifier>@<domain name of university>. The <identifier> isn't particularly secret, either.

Regards
    Brian

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 Jan 2022 17:35:36 -0500

This is only peripherally related, but there seems to be a group of (east
coast?) universities that all use xyNN@university as their default email.
Mine is [email-masked].

On Fri, Jan 28, 2022 at 3:10 PM Brian E Carpenter <
[email-masked]> wrote:

> Tom,
>
> > The identifier for Eduroam is this <identifier>@<domain name of
> university> the e-mail address is typically jane.doe@<domain name of
> university>.
>
> In all the cases that I know, jane.doe@<domain name of university> is
> just an alias for <identifier>@<domain name of university>. The
> <identifier> isn't particularly secret, either.
>
> Regards
>     Brian
>
>

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Mon, 31 Jan 2022 22:13:17 +0700

Dear Watson &
architecture-discuss,

As I am reading this thread (from Yours till Henning's) yet also these
books "Internet Books" (2019) ch. 30 "Network Security (Encryption and
Firewalls) "*1 --where there was "coffe shop" as one among other examples--
and "Computer Networks" (2009) ch 30 "Network Security"*2 --where there was
a list of security technologies including among others Secure Shell
(SSH))-- both are by Douglas Comer, I am still thinking of "network
security" is about ensured (human) rights to communicate*3: thus, "network
security" is about measurements/methods/strategies/tactics to problems of
threats/attacks related with communication proccess at least when it is
about messages between senders and receiver which are transferred well.
Internet as the machine of the communication should properly
architecturized and enginereed. Here are supposedly matters of concepts and
of conventions of protocols ...?

NOTES:

1*
https://www.pdfdrive.com/the-internet-book-everything-you-ne
ed-to-know-about-computer-networking-and-how-the-internet-
works-e183848463.html

2*
https://www.pdfdrive.com/computer-networks-and-internets-e28079779.html

3* It  supposedly resemblances what a farmer/gardener who struggles for
his/her rights --no pain no gain. He/she deals with problems of floods,
droughts and pests --how he/she endeavours to secure his/her farm/garden
work, thus his/her rights, his/her gains.

Regard,
Guntur Wiseno Putra