Can anyone else (Vicky?) respond to jiazi's comments regarding the trust model?
Am 02.03.2016 um 16:41 schrieb Lotte Steenbrink <lotte.steenbrink@xxxxxxxxxxxx>:
Hi Ulrich and MANET members,
[for some reason my e-mail Client ate Ulrich's e-mail so I've copy & pasted
it, I hope that doesn't mess up the thread/formatting too much]
Thanks for your quick and thorough response!
The reason I'm getting back to you just now is that we're currently
incorporating your comments into the document and I wanted to answer with at
least some work in progress. Attached you'll find what we've changed so far
(and a diff from the last version). There are still a lot of TODOs in there,
but this is the direction we're currently going in and the changes we've
made. (The quotes you'll find after some TODOs are from BCP72)
One additional thing that's not in the document yet but maybe should be
addresses is an additional scenario for 13.1.3 False Confirmation of Link
Bidirectionality:
A malicious node could also immediately answer a RREQ with a RREP that has
stellar metric values, causing the genuine RREP of the route that is actually
established to be discarded.
Direct responses inline:
Ulrich Herberg <ulrich@xxxxxxxxxxxx> Sat, 20 February 2016 16:41 UTC
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've read that it can be a non-exhaustive classification and I had the
suspicion that there are many more axes to cover.
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).
Indeed. I hope we've resolved this with this update.
- 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.
Just for the record, we didn't resolve this with the current version.
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 way I'm understanding the E-Mail you're citing, your issue with the word
"regeneration" there is that overall regeneration is a more drastic measure
than mere modification, and that this extra effort is unnecessary. That makes
sense to me, but simple forwarding (and thus end-to-end protection?) of
entirely unmodified messages won't be possible with AODVv2, since TLVs like
Metric and ValidityTime and AckReq need to be updated hop by hop. Are you
suggesting to add the option to exclude these TLVs during ICV calculation? I
guess that would open the door to different attacks, but we could name "both
sides" and let the implementers decide which is better for them? Or what am I
misunderstanding here?
I guess the entire topic deserves its own thread...
- 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.
Good point. We've restructured that section and tried to bullet-point-ify the
overall document a bit more. What do you think?
- 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".
We've converted shoulds to SHOULDs now and the section doesn't contain MAYs
or mays...
- 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?
Afaik not; has ben added as a TODO.
- 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).
Written down in the current version, but could be more detailed and
step-by-step based.
Best regards
Ulrich
Kind regards,
Lotte
<13. Security Considerations_v3-from- Security Considerations.diff.html>
<13. Security Considerations_v3.txt>
