Subject: [Anima] Reference draft: New Security Considerations Section

From: "Michael H. Behringer" <[email-masked]>
Date: Thu, 12 Oct 2017 11:23:07 +0200

As mentioned before, the Security Considerations section needed work. I 
have now restructured and to a large extent re-written that section.

The main focus is on the fact that while AN is auto-protecting, in the 
case of a vulnerability, protocol design error, operational error, the 
attack surface is huge.

All, especially co-authors: Please read the new section and comment!

Right now only on github:
https://github.com/mbehring/ANIMA-Reference-Model/blob/master/draft-ietf-anima-reference-model.txt

Other than that:
- on sections 7.6 and 7.7 I'm waiting for feedback from John.
- otherwise, to my knowledge, all other input received has been taken 
into account.

Once 7.6, 7.7 and the security considerations are stable, I'll push a 
new version. Co-authors: Comment now! :-)

Michael

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Oct 2017 13:41:28 +1300

Hi Michael,

One additional issue for outside attackers is to mention that
a specific attack surface is anywhere that an autonomic entity
interacts with a non-autonomic entity, which is by definition
outside the ANI security barrier. Unlike the second bullet
in 9.2 "Risk of Insider Attacks", this is fairly specific
to autonomic components.

Regards
   Brian

On 12/10/2017 22:23, Michael H. Behringer wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Mon, 16 Oct 2017 01:15:53 +0000

Hi Michael.
I think the security section looks good, but I have some comments, to
clarify some passages
My comments:

In Section 9:
"... transit, inject and replay packets "on the wire".  In an insider
   attack, the attacker has access to an autonomic node, or can insert
   packets directly into the ACP."
- I understand the difference between "on the wire" and "directly into the
ACP", but I think this should be better explained.

In Section 9.1:
"...as well as mechanisms specific to
   an autonomic network (such as a secured MASA server)."
- I believe "secured MASA server" can be replaced by "MASA service".

 "AN specific protocols and methods must also follow traditional
   security methods, in that all packets that can be sniffed or injected
   by an outside attacker are:

   o  protected against modification.

   o  authenticated.

   o  protected against replay attacks.

   o  encrypted."
- I'd rather be consistent using "protection on Confidentiality, Integrity,
Availability, and Non-repudiation".

  "Most AN messages run inside the cryptographically protected ACP.  The
   not protected AN messages outside the ACP are limited to a simple
   discovery method, defined in Section 2.5.2 of [I-D.ietf-anima-grasp]:
   The "Discovery Unsolicited Link-Local (DULL)" message, with detailed
   rules on its usage."
- Since it is a important exception, I think the usage rules should be
replicated here instead of just using a reference to the GRASP I-D.

Cheers.
Jéferson

---

From: "Michael H. Behringer" <[email-masked]>
Date: Wed, 18 Oct 2017 12:23:51 +0200

On 16/10/17 03:15, Jéferson Campos Nobre wrote:
> - I understand the difference between "on the wire" and "directly into 
> the ACP", but I think this should be better explained.

Somehow I was afraid someone would say this. :-(  It's not easy to 
explain, in simple terms...

How does this sound:

"In an outsider attack all network elements and protocols are securely 
managed and operating, and an outside attacker can sniff packets in 
transit, inject and replay packets. In an insider attack, the attacker 
has access to an autonomic node, or can insert packets directly into the 
protected ACP."

> - I believe "secured MASA server" can be replaced by "MASA service".

Done.

> - I'd rather be consistent using "protection on Confidentiality, 
> Integrity, Availability, and Non-repudiation".

That's not the same :-)  You don't cover re-play attacks.

> replicated here instead of just using a reference to the GRASP I-D.

I respectfully disagree, this would add a lot of detail, and would make 
the section less readable. I think the reference is better here.

Will push the changes onto the git repo in a minute.

Michael

> Cheers.
> Jéferson
>
> Em qui, 12 de out de 2017 às 06:23, Michael H. Behringer 
> <[email-masked] <mailto:[email-masked]>> 
> escreveu:
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Michael H. Behringer" <[email-masked]>
Date: Wed, 18 Oct 2017 12:39:09 +0200

I think I've incorporated all the comments I got so far, and the latest 
version on github addresses all open issues.

Tomorrow I'm planning on pushing version -05. If you still have 
comments, I'd appreciate them in the next 24h (or a quick note that I 
should still expect comments).

Again, goal is WGLC.

Michael

---

From: Artur Hecker <[email-masked]>
Date: Wed, 18 Oct 2017 13:01:51 +0000

Hi

Please find below some short additional comments, hopefully on time :-) Michael, these things are indeed a pain to formulate correctly, so please feel free to disregard, if it becomes too bulky.

> Somehow I was afraid someone would say this. :-(  It's not easy to explain, in simple terms...
> 
> How does this sound:
> 
> "In an outsider attack all network elements and protocols are securely managed and 
> operating, and an outside attacker can sniff packets in transit, inject and replay packets. 
> In an insider attack, the attacker has access to an autonomic node, or can insert packets
> directly into the protected ACP."

[[AH] ] Minor point: as an attack is a practical instantiation of potential threats exploiting some vulnerabilities, I believe that what we describe here is better called a "threat model". We can still call those presumed actors "inside attacker" and "outside attacker" respectively, both being "threat agents", but I wouldn't talk about "inside attack". (Rationale: a specific attack could be an arbitrary combination of all these.)

Besides, I would suggest addition of "destroy/suppress packets", to fully cover MitM capabilities of an "on the wire" attacker.

For the second phrase, I would add something like: "<...> access to an autonomic node or any other means (e.g. remote code execution in the node by exploiting ACP-independent vulnerabilities in the node platform) that would allow the attacker to produce arbitrary payloads of the protected ACP channels".

Finally, probably it would be good to categorize these "arbitrary payloads": if the inside attackers only produce some twisted packets and wrong syntax, we can discover them by sanity checks of ACP related protocols. But for more complex scenarios, we would seem to need behavioural node analysis or majority votes, etc., which imo still have too many false positives / negatives. I guess we cannot require TC/TPM with remote attestation? Especially, because all this is somehow orthogonal to ANIMA...

> That's not the same :-)  You don't cover re-play attacks.

[[AH] ] I would agree with Michael here. C.I.A. refers to data protection, we talk about a protocol. I would even add MitM specifically in the list above, as it very probably will be the first choice... (See KRACK).

Greetings
artur

---

From: Jéferson Campos Nobre <[email-masked]>
Date: Wed, 18 Oct 2017 15:20:34 +0000

Hi.
I respectfully disagree on C.I.A. and re-play, but I can live with the
Michael's original text :) My changes are aimed at the style of the
described list.
Best.
Jéferson

Em qua, 18 de out de 2017 às 11:01, Artur Hecker <[email-masked]>
escreveu:

> Hi
>
>
> Please find below some short additional comments, hopefully on time :-)
> Michael, these things are indeed a pain to formulate correctly, so please
> feel free to disregard, if it becomes too bulky.
>
>
> managed and
> [[AH] ] Minor point: as an attack is a practical instantiation of
> potential threats exploiting some vulnerabilities, I believe that what we
> describe here is better called a "threat model". We can still call those
> presumed actors "inside attacker" and "outside attacker" respectively, both
> being "threat agents", but I wouldn't talk about "inside attack".
> (Rationale: a specific attack could be an arbitrary combination of all
> these.)
>
> Besides, I would suggest addition of "destroy/suppress packets", to fully
> cover MitM capabilities of an "on the wire" attacker.
>
> For the second phrase, I would add something like: "<...> access to an
> autonomic node or any other means (e.g. remote code execution in the node
> by exploiting ACP-independent vulnerabilities in the node platform) that
> would allow the attacker to produce arbitrary payloads of the protected ACP
> channels".
>
> Finally, probably it would be good to categorize these "arbitrary
> payloads": if the inside attackers only produce some twisted packets and
> wrong syntax, we can discover them by sanity checks of ACP related
> protocols. But for more complex scenarios, we would seem to need
> behavioural node analysis or majority votes, etc., which imo still have too
> many false positives / negatives. I guess we cannot require TC/TPM with
> remote attestation? Especially, because all this is somehow orthogonal to
> ANIMA...
>
>
> [[AH] ] I would agree with Michael here. C.I.A. refers to data protection,
> we talk about a protocol. I would even add MitM specifically in the list
> above, as it very probably will be the first choice... (See KRACK).
>
>
> Greetings
> artur
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Oct 2017 08:16:51 +1300

> On 16/10/17 03:15, Jéferson Campos Nobre wrote:

...
> the section less readable. I think the reference is better here.

I agree with Michael. We had to do a lot of work on this (and other
security aspects) to get IESG approval of the GRASP draft, and
I think it's a mistake to paraphrase or duplicate any of that text
in another document. It could create new problems with the IESG.

I'm generally happy with the way this section is developing.

    Brian

---

From: "Michael H. Behringer" <[email-masked]>
Date: Thu, 19 Oct 2017 15:12:59 +0200

> Please find below some short additional comments, hopefully on time :-) Michael, these things are indeed a pain to formulate correctly, so please feel free to disregard, if it becomes too bulky.

Artur, thanks for the comments, I'm very happy to get feedback! :-)

> [[AH] ] Minor point: as an attack is a practical instantiation of potential threats exploiting some vulnerabilities, I believe that what we describe here is better called a "threat model". We can s…

Well, a threat model is more comprehensive than what we have right now, 
and would result in a bigger analysis than I think we want here. Maybe 
we should spin off another document on this some time. But I'm a bit 
hesitant in using this term in the current version.

> Besides, I would suggest addition of "destroy/suppress packets", to fully cover MitM capabilities of an "on the wire" attacker.

Good point. I'll use the term "drop packets", I think that's the 
generally used term. Added: "and that the AN protocols are robust 
against packet drops."

> For the second phrase, I would add something like: "<...> access to an autonomic node or any other means (e.g. remote code execution in the node by exploiting ACP-independent vulnerabilities in the…

Changed (with a few small edits).

> Finally, probably it would be good to categorize these "arbitrary payloads": if the inside attackers only produce some twisted packets and wrong syntax, we can discover them by sanity checks of ACP…

For now, I suggest we leave it as it is, essentially: "an insider can do 
anything". Again, a deeper analysis should go into a separate document, 
in my view.

> [[AH] ] I would agree with Michael here. C.I.A. refers to data protection, we talk about a protocol. I would even add MitM specifically in the list above, as it very probably will be the first choi…

So now I added a bullet combining both of the comments received: "and 
that the AN protocols are robust against packet drops and 
man-in-the-middle attacks."

These were all the comments received so far, and I tried to address them 
appropriately.

I'll now update the github repo, and publish the new version. The chairs 
should decide whether we're good for a WGLC, I think that would be a 
good next step. Surely there will be more comments during that process.

Thanks Artur for your comments!

Michael