Re: [manet] AODVv2: Security considerations update

[Ulrich Herberg <[e-mail]>]

Hi Lotte,

I agree with what Chris said.

Can you clarify what you mean in your email by:
"[...] (afaik) the Availability/Confidentiality/Integrity model may be
considered a bit dated [...]"?

I have a few concerns with the proposed security considerations section:

- BCP72 specifies:
===================
"Authors MUST describe

      1.   which attacks are out of scope (and why!)
      2.   which attacks are in-scope
      2.1  and the protocol is susceptible to
      2.2  and the protocol protects against

   At least the following forms of attack MUST be considered:
   eavesdropping, replay, message insertion, deletion, modification, and
   man-in-the-middle.  Potential denial of service attacks MUST be
   identified as well.  If the protocol incorporates cryptographic
   protection mechanisms, it should be clearly indicated which portions
   of the data are protected and what the protections are (i.e.,
   integrity only, confidentiality, and/or endpoint authentication,
   etc.).  Some indication should also be given to what sorts of attacks
   the cryptographic protection is susceptible.  Data which should be
   held secret (keying material, random seeds, etc.) should be clearly
   labeled.
"
===================

I don't think all of the above MUSTs are addressed in the proposed
text (see also below).


- I think the chain-of-trust model that doesn't allow end-to-end
integrity protection is problematic in an entirely distributed and
untrusted network environment. It's a bit like saying that you trust
that an email sent to someone else is integrity protected because the
step-wise SMTP between various mail servers along the path uses TLS.
This brings me to the deeper issue of why messages are regenerated
instead of forwarded. I have not understood why this is necessary in
the first place (and I argued this in an email to the list at
https://www.ietf.org/mail-archive/web/manet/current/msg18081.html)

- The text in section 13.3.1  is hard to interpret as implementer,
since it mixes a security evaluation with the actual specifications of
how to protect the messages. I think it would be better to have
separate sections for these two parts. Also, as a stylistic
recommendation, I always had a hard time reading the continuous text
as opposed to bullet points as we applied in OLSRv2.

- I have some doubts that the Security ADs will agree with the terms
"recommendations" in the title of the section together with a lot of
SHOULDs and MAYs in the text, which seems to imply that usage of the
integrity protection is not mandatory. When specifying OLSRv2, we were
clearly told that we require a "MUST-implement/SHOULD use until you
have something more better".

- The Sec ADs required us for OLSRv2 to argue (in the spec) why we
don't need to specify automatic key management as per BCP107. I don't
see a similar section in AODVv2. Have you confirmed with the Sec ADs
that their requirements have been relaxed?

- The biggest issue I have with the proposed security consideration
text is that there is no detailed specification of how to sign and
validate messages, similar to what we were required to do by the Sec
ADs in RFC7183. I doubt that two AODVv2 implementations by different
programmers would be interoperable just using the current text. You
mention the functions specified in RFC7182; but really these are just
the containers for the actual information. RFC7182 does not mandate
how to use them (such as we do in RFC7183).

Best regards
Ulrich


On Fri, Feb 19, 2016 at 7:52 AM, Dearlove, Christopher (UK)
<[e-mail]> wrote:
> I would say that in the interests of transparency, a lot more should appear
> on list. Of course there’s no need - until later stages - to discuss every
> editorial nit on list, but basic decisions should have been discussed here
> before now, and responses to comments received (I’ve never had responses to
> all my comments).
>
>
>
> On this posting, it’s not exactly true that
>
>
>
>    Encryption will not only make it more difficult for unauthorized devices
> to obtain
>    information about network topology but will also ensure that only trusted
>    routers participate in routing operations:
>
>
>
> What ensure the latter is not encryption, but authentication. It is true
> that one should generally not use encryption without authentication, and
> there are some algorithms that do both together. Nevertheless I think it’s
> both useful and important to assign the right properties to each.
>
>
>
> There’s then the practical issue that with a shared secret key, encryption
> and authentication are both (relatively) easy. But if you want a solution
> that isn’t that (because that has various drawbacks) then authentication is
> more manageable than encryption. For example draft-ietf-manet-ibs has a
> scheme (not of course the only possible one) for authentication. The
> equivalent for encryption that actually conceals network topology is hard
> (just revealing all addresses gives away quite a lot).
>
>
>
> (Following the path of a signalling message is probably easier in a reactive
> network, because of the direct reaction.)
>
>
>
> --
>
> Christopher Dearlove
> Senior Principal Engineer
> BAE Systems Applied Intelligence Laboratories
> __________________________________________________________________________
>
> T:  [phone]  |  E: [e-mail]
>
> BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow,
> Chelmsford, Essex CM2 8HN.
> www.baesystems.com/ai
>
> BAE Systems Applied Intelligence Limited
> Registered in England & Wales No: 01337451
>
> Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP
>
>
>
> From: manet [mailto:[e-mail]] On Behalf Of Lotte Steenbrink
> Sent: 19 February 2016 15:06
> To: [e-mail]
> Subject: [manet] AODVv2: Security considerations update
>
>
>
> ----------------------! WARNING ! ----------------------
> This message originates from outside our organisation,
> either from an external partner or from the internet.
> Consider carefully whether you should click on any
> links, open any attachments or reply.
> Follow the 'Report Suspicious Emails' link on IT matters
> for instructions on reporting suspicious email messages.
> --------------------------------------------------------
>
> *** WARNING ***
> EXTERNAL EMAIL -- This message originates from outside our organization.
>
>
>
>
> Hi all,
> in the interest of transparency, we (the AODVv2 author team) want to send
> out more updates on what we've been doing, and this is the first of these
> e-mails. We've restructured (and sometimes rewritten) our security
> considerations a bit and added a subsection about the Trust Model, and we'd
> love to hear your opinions on those changes. You can find the result and a
> diff to the current considerations in the attachments. (the formatting was
> done manually, so it might be a bit wonky)
>
> Some notes:
> * This is all work in progress, so please poke holes into it where you can!
> * While (afaik) the Availability/Confidentiality/Integrity model may be
> considered a bit dated, I thought it might be a good starting point.
> * I was wondering if “Encryption will not only protect against unauthorized
> devices obtaining
>    information about network topology” isn't a tad too short and bold– maybe
> we could add a clarification along the lines of:
>
>    Encryption will not only make it more difficult for unauthorized devices
> to obtain
>    information about network topology but will also ensure that only trusted
>    routers participate in routing operations: When messages are encrypted,
>    a malicious observer would have to monitor the entire network to
> understand
>    its topology and traffic flow. And even then, due to the hop by hop
>    nature of the protocol and the fact that messages are regenerated rather
>    than forwarded (resulting in a different payload every time),
>    following the path of a message would be hard if its transmission is not
>    the only encrypted traffic produced by the network.
>
> Regards,
> Lotte
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
>
>
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>