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

[Brian E Carpenter <[e-mail]>]

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.

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