Subject: [Anima] Brian/anima: trust notion of ASA communications

From: Toerless Eckert <[email-masked]>
Date: Thu, 6 Feb 2020 21:59:49 +0100

Hi Brian, 

sorry to pick you out, but i think you've got the best overview of
the ongoing set of ASA related docs.

I just got reminded through ongoing ACP spec review about something that
would be good to write into the appropriate ASA spec, but not sure which
one:

One of the fundamental problems we have to solve longer term is how we
can establish better than "Any ANI peer is equally trusted" notion.

Short term, i'll propose when i have time to have according roles in
the ANI certificates, but thats really a non-autonomic solution because
some outside intelligence (operator) has to assign such a role.

In reality today, its family,friends,colleagues&media that establish
the trust notion for us: trust foo.com to provide service bar, but
certainly not acme.com. The fact that you can then cryptographically
(web-Cert) assert that you're really talking to foo.com is really just
a secondary dependency.

I think DINRG is working in this direction, but have failed to track.
Maybe there is a way to collaborate on this, aka: see if/when they might
have output we could think to adopt/leverae.

But its fundamental if we want to move into more autonomic solutions
beyond just supporting the current SDN model.

Right now we expect objective announcements from any node to be equally
trustworthy and decide on selecting one only on announced parameters
(also subject to equal trust) and network parameter comparison.
And of course, this goes beyond trust into performance vetting by
others and so on.

Trying to figure out the most easy use-case would also be quite
helpfull. aka: what the most short term useful ASA that we'd like to
have spread around the network, where we could apply different degrees
of these mechanisms...

Cheers
    Toerless

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Feb 2020 22:55:31 +0100

> can establish better than "Any ANI peer is equally trusted" notion.

I agree.
But, at this point, all the ANI peers are equal.

None do anything special yet... Once we have protocol(s) that can do
something different, then we need to figure out what the requirements for
that protocol.

Putting the trusted-to-do-foo bit into the certificate is probably unwise.

It seems that in an autonomic network that there ought to be a service that
can be used to ask, "should I trust node FOO to do X?".
That could be the (cmc)RA or another node so designated.
It seems that GRASP can pretty much do all of this.

COSE can be used to sign answers.
That is probably a thing we need to add.

    > have output we could think to adopt/leverae.

I don't know what they are doing either.

    > And of course, this goes beyond trust into performance vetting by

At some level, if you are looking for resource X, and some node can provide
X, and it works and does what you need... then maybe it is reasonable to
trust it.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Feb 2020 16:42:13 +1300

Yes, this is certainly a gap, and it's why I put register_asa and register_objective in the API, thinking that when we add some kind of trust/authorize magic dust, this would be created when registering the ASA to (a) run and (b) manage certain GRASP objectives. I feel quite far from having a complete model in my head though. I guess we should start with understanding what threats we are protecting against.

Regards
   Brian Carpenter

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 7 Feb 2020 15:58:02 +0100

> But, at this point, all the ANI peers are equal.

Except for cmc(RA).

> something different, then we need to figure out what the requirements for

Or rather service. yes. Thats what i am asking for.

> Putting the trusted-to-do-foo bit into the certificate is probably unwise.

Well...
a) see above (registrar)
b) I think its wise, but i do understand how the crypto folks don't lke it
   and every time you ask crypto folks think outside the box it takes
   eternities. Aka: to me its not different from the implied trust
   expressed by a weeb certificate through the name. If i have cert bits
   indicating more generic "roles" thats IMHO quite similar.
c) But the main ask here was to see if there is some actionable output
   of research that moves us beyond this model.

> can be used to ask, "should I trust node FOO to do X?".

Sure, and i am going to run a hacked ACP node thats announcing in GRASP
to be the "best-ever" node to provide that service ;-) How to you
prohibit me to happen ? -> Anser: i dont have a fitting certificate, or
there is some ACP crowd intelligence that says i am untrustworthy.

> That could be the (cmc)RA or another node so designated.

Right. Thats the "role" indications in certificate approach. And of
course we want to limit that to really "lifetime role assignments"
(lifetime larger than cert lifetime..).

> That is probably a thing we need to add.

Right.

> X, and it works and does what you need... then maybe it is reasonable to

Yes, discovering violation of trust is the biggest issue for crowd intelligence.

The easier starting point case would be crowd intelligence based on
client measured service performance experience. Think DNS proxies on
each edge-router circling around the set of DNS services announced, DNS
proxies measure RTT and failure rate, exchange amongst themselves those
parameters and adjust their use of these servers accordingly. Easy to
see how this might easily wipe out unreliable servers. Much more difficult
to do the solution to optimize overall load when the best server becomes
overloaded because everybody wants to start using it.

Cheers
    Toerless

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

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Feb 2020 12:04:33 +1300

On 08-Feb-20 03:58, Toerless Eckert wrote:
<snip>
> there is some ACP crowd intelligence that says i am untrustworthy.

I don't see how you can get away from asymmetric crypto to do that. An ASA
comes up and says 'I support "DANGER"', which is a GRASP objective for doing
something very dangerous. Take a concrete example: 'I support "PrefixManager"',
which is defined in draft-ietf-anima-prefix-management and will be in an
RFC one day soon. So this ASA needs to be trusted to allocate or assign
IP address space.

How can we check this is OK? As far as I can see, only if we have previously
decided to trust any PrefixManager ASA that can prove possession of a given
private key, or more precisely one of a given set of private keys.

In practical reality, I'm sure operators will want to install identical
binaries of a given ASA on multiple autonomic nodes. So the private key
will be scattered around the autonomic domain. My guess is that a lot of
operators would not see this as any better than just trusting the nodes,
not the individual ASAs.

    Brian

---

From: "Michael H. Behringer" <[email-masked]>
Date: Sat, 8 Feb 2020 11:36:09 +0100

Brian, I'm not sure I understand your phrase "the private key will be 
scattered around the autonomic domain." Are you suggesting to create a 
key pair for a role, and if several nodes have the same role, they will 
have the same private key?!? That strikes me as very unusual...

I think we're back to really old concepts of security:

A node has an identity and a role. The identity is proven by a 
certificate. The role (ex: Prefix Manager) is assigned to an identity. 
And a role may require a specific ASA to fulfil its function.

As Toerless points out, we CAN (and do) assign roles statically in a 
certificate. In the "real" world a diplomatic passport is exactly that: 
It's an identity of a person, plus a role (diplomat). But that only 
makes sense for fairly static roles, and I would not suggest that for 
things like Prefix Manager.

There are two alternatives:
1 - We come up with a consensus model (see Toerless' mail). In a 
distributed model such as ANI very interesting, but I think needs a lot 
more work. Much more common though:

2 - We maintain a directory (read: a secured database), where we assign 
roles to identities. This is "normal" in standard security. Role based 
access control for example, Active Directory, etc.

I would vote for a directory type of solution at first. This way an 
administrator can assign and change roles quite easily. Later we can 
look into consensus models.

I'd need a lot more convincing that certificates for roles (or ASAs) are 
a good idea. And shared private keys (actually: Contradiction in terms, 
I probably misunderstood Brian there) definitely not.

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 9 Feb 2020 08:05:25 +1300

> have the same private key?!? That strikes me as very unusual...

Yes. But if you're a network operator, you're very pragmatic and if you have
an updated binary of an ASA that you need to install on 500 nodes, you won't want
to add a complex key management task to the installation.

Indeed it's bad security to share a key. I just think that it will happen, if
we propose an alternative that is perhaps as complex as BRSKI itself but is
applied at the ASA level instead of the node level.

> And a role may require a specific ASA to fulfil its function.

Make that plural. A node may have mutltiple roles and a role may 
multiple ASAs.
 
> look into consensus models.

I agree entirely, but it wasn't obvious that Toerless was heading in that
direction.
 
> I probably misunderstood Brian there) definitely not.

Again, I agree. I was simply speculating about what I expect operators would
do if presented with too much complexity.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Feb 2020 13:13:28 +0100

> there is some ACP crowd intelligence that says i am untrustworthy.

a) How are you going to connect to the ACP?
b) If you say that it is because you are going to attack some existing node,
   then no number of certificate bits are going to help.

    > (lifetime larger than cert lifetime..).

But, that's the only role we need.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Michael H. Behringer" <[email-masked]>
Date: Mon, 10 Feb 2020 10:26:38 +0100

> applied at the ASA level instead of the node level.
OK, I think we agree: let's make sure that doesn't happen! :-)   In any 
case, if the goal is to prevent a potential hacker to spin up any ASA on 
a hacked node, then a key delivered with the ASA won't do the job, 
right? Because that could potentially be found on another hacked node, 
and copied as well.

We need to first define the problem statement precisely. (Maybe it's 
just me who doesn't have it clear?)

The problem is that a node runs an ASA which it shouldn't. Right?

There is however more than one way to get to this situation:
1) A node may be hacked, have all sorts of ASAs installed manually by 
the hacker, and use those in ways not intended by the operator. 
("malicious case")
2) Autonomic nodes may well decide by themselves to run certain 
functions if needed. ("Erroneous case")

I agree with Toerless: The concept with a special bit in the certificate 
isn't all that bad. If it's a pretty static function, it's perfectly 
appropriate. (Like a diplomatic passport). Let's not throw this out.

As Toerless said: "crowd intelligence based on client measured service 
performance experience" would be a solution to the 2nd case. But that's 
to me for further study, not a short-term goal. And that may well be 
different for different types of ASA.

The middle way would be a centrally controlled directory, that nodes can 
query. Needs more thinking. Do we want to check permissions for all 
types of ASAs? How long can you cache permissions? Do we want to define 
different "security levels" of ASAs, to distinguish between "to be 
checked at each usage" and "trust crowd intelligence" and "trust 
implicitly"? Should we just re-use an existing scheme for that? (AAA?) 
This isn't going to happen in a rush...

Michael

> Make that plural. A node may have mutltiple roles and a role may
Yes. The word "a" was not meant as an enumeration.