Re: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-threats-03: (with DISCUSS)

["Dearlove, Christopher (UK)" <[e-mail]>]

Not an author, but I hope this is useful. It follows up Stephen's second point.

RFC 7182 describes a mechanism for adding ICVs to anything based on RFC 5444 format (which includes OLSRv2). It includes code points for some ICVs that may be signatures and some that aren't - I think more of the latter.

RFC 7183 is, roughly speaking, an RFC 7182 option for OLSRv2 (and NHDP) implementation. It's called out from RFC 7181 (OLSRv2) as a "must implement, don't need to use" mechanism. It specifies the HMAC/SHA-256 option indicated. It is shared secret key, and thus isn't a signature (as Stephen notes).

Reading Section 6.2 with that in mind, apart from the use of signature, I think mostly it's OK, the RFC 7183 option will work as described if nothing is compromised, but I'm not sure about the final parenthesised piece at the end of the first long paragraph. If you want to be able to revoke you want to be using a different RFC 7182 (or extension) option, as noted an asymmetric one, not the RFC 7183 option, and I don't think that's clear. Possibly "in addition" is meant to mean something more like "alternatively" (though it is not a simple text change like that) but should reference RFC 7182.

(I think the ICVs that might be signatures in RFC 7182 are probably underspecified, which goes back to RFC 6622 of which it is an update. There is an ICV that is a signature in RFC 7859, an extension to RFC 7182, but that is experimental, although specified in some detail.)

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

-----Original Message-----
From: manet [mailto:[e-mail]] On Behalf Of Stephen Farrell
Sent: 05 January 2017 13:28
To: The IESG
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-threats-03: (with DISCUSS)

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


Stephen Farrell has entered the following ballot position for
draft-ietf-manet-olsrv2-sec-threats-03: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


I have two things I'd like to discuss to see if changes are needed or not:

(1) Neither this nor RFC7186 seem to consider battery depletion attacks. Why is that ok?

(2) 6.2: HMAC is *not* a digital signature mechanism.
While loose terminology may be ok elsewhere, in this case, you shouldn't do that as it can lead to wrong conclusions. Digital signatures do provide origin authentication of sorts, but MACs do not, especially if keys are shared. It is not clear to me that some of the claims in 6.2.x of attacks being mitigated are in fact correct, given shared secrets. (Note: It could be that the claims are correct, I didn't have time to check back on all the vulnerability definitions, sorry. But I'd like to check, given the defective
terminology.)




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