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

["Michael H. Behringer" <[e-mail]>]

On 08/02/2020 20:05, Brian E Carpenter wrote:
> On 08-Feb-20 23:36, Michael H. Behringer wrote:
>> 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...
> 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.
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


>
>> 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.
> Make that plural. A node may have mutltiple roles and a role may
> multiple ASAs.
Yes. The word "a" was not meant as an enumeration.
>> 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 agree entirely, but it wasn't obvious that Toerless was heading in that
> direction.
>   
>> 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.
> Again, I agree. I was simply speculating about what I expect operators would
> do if presented with too much complexity.
>
>      Brian
>
>> Michael
>>
>>
>> On 08/02/2020 00:04, Brian E Carpenter wrote:
>>> On 08-Feb-20 03:58, Toerless Eckert wrote:
>>> <snip>
>>>> 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.
>>> 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
>>>
>>>
>>> _______________________________________________
>>> Anima mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/anima
>> _______________________________________________
>> Anima mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/anima
>>