A Security Framework for Routing over Low Power and Lossy Networks
Summary: Needs a YES.
(Stephen Farrell) Discuss
Discuss (2011-05-05 for -)
Since I've taken over Tim's discuss, I've just had a read to ensure I understand this. I read this document and section 10 of roll-rpl. I believe that the core of Tim's discuss is that there is no specification for how the authenticated mode of roll-rpl is to be done, and specifically using public key based mechanisms for key distribution. That seems to still be the case, so if I'm right there, then the discuss should remain. If not, (Tim?) then I may be misunderstanding, and should clear. I don't see anything in this document, the charter milestones or the set of WG docs that looks like it will address this. I'd be happy to clear were there to be a good specification of how to do e.g. a signature based authenticated mode, or a public key based way to distribute keys for an authenticated mode, or even a kerberos-like way to distribute secret keys for an authenticated mode. While this will all be optional to implement, its absence is really not consistent with bcp107. Having read the thing, I also have a bunch of comments (below) and one additional question about RPL to which I'd love to know the answer. (It may be that the answer is in roll-rpl already but I didn't read all 163 pages;-). My question: with pre-shared keys, what prevents reflection or re-direction attacks where a MACed message is captured and either reflected back to the sender or else sent to another node using the same pre-shared secret? In order to avoid having to exhaustively analyse the protocol, its normal to try to prevent such attacks inside the crypto mechanism. [Tim's original discuss text is below] I think this is a really good document, and support its publication. However, I think some of the issues I was persuaded to remove from my discuss on roll-rpl because they would be more appropriate in this document were omitted. I am specifically concerned about punting the details on public key distribution, then finding they are not covered here either. Did I get the wrong document? Where are those issues going to be addressed? I will hold this discuss while we sort out the best place to address these issues...
Comment (2011-05-05 for -)
#1 The document uses terminology very slightly differently when compared to others in e.g. the security area. It might be worth going throuh rfc4949 and trying to change terminology here to match that. (Or maybe you did, and 4949 is wrong - 4949 is so long its hard to know;-) #2 Non-repudiation is a nonsense (as a network service) and is better omitted from documents like this entirely. In this case you might be able to s/non-repudiation/evidence gathering/ with a few edits to fix this. #3 I don't understand "routing in LLNs needs to bootstrap the authentication process" - I guess I'm not sure who's authentication to whom is being discussed. #4 "Only when a validated and authenticated node association is completed will routing exchange be allowed to proceed using established session confidentiality keys and an agreed confidentiality algorithm. " You can have confidentiality to counter sniffing without authentication, but at the expense of remaining vulnerable to MITM attacks. Might be too big a change, but sniffing and MITM are different attacks really. #5 "This session key shall be applied in conjunction" should that be a 2119 SHALL? #6 A reference for JTAG might be useful for some readers #7 s/it associated external memory/its associated external memory/ #8 I can't parse this: "Since remote access is not invoked as part of a routing protocol security of routing information stored on the node against remote access will not be addressable as part of the routing protocol." Maybe it just needs rephrasing. #9 5.2 says that it won't include physical attacks, but the title of 5.2.1 includes the word "tampering" which is usually used in the context of physical attacks. In 5.2.1 tampering can be replaced with the more common "message modification" or "message insertion" etc. as appropriate. #10 5.2.2 says "...while there is not necessarily tampering" which needs rephrasing. #11 5.2.5 could also note that replay-caches are usually needed to counter clock-skew (esp in LLN devices where you may need 24 hour wide windows) and that those can be problematic on the kind of device considered here. #12 There's either a missing reference or better explanation of byzantine attacks. A reference would be better. #13 5.2.5 talks about "routing principals" being authenticated - is that a well defined term for roll/RPL? (It could be a machine, a process, a thing in the context of a dodag...) The very next paragraph says "routing entities" - are those the same? #14 5.2.5 - without a reference or explanation its not sufficiently obvious that ospf or isis can directly detect these attacks by comparing different messages - adding a reference would be best. #15 5.3.2 - you don't really drain an engrgy budget, but rather an energy store #16 5.3.2 - not sure that saying verify certs before signatures is always right - that might involve CRL retrievals that could amplify an attack if an attacker just presents a highly complex cert path with a bogus signature - where's the evidence this way is better? If you have it, it should be included/referenced. #17 5.3.2 - I don't get the relevance of s/mime at the end of 5.3.2 - what part of (the 45 pages of) rfc5751 is relevant? #18 5.3.4 - a reference would be good #19 5.3.5 - a reference would be good #20 6.1 - privacy isn't right here, it appears to be a confidentiality service that's being required #21 6.1 - it'd be better to be clear about what's mandatory to implement vs. mandatory to use, 6.1's "MUST provide privacy..." seems to be calling for mandatory-to-use. (A question on that, are there really no LLN's where all geographic information is obvious? e.g. a very small scale network, or a network where node position is inherently public, say a node on each bus-stop - maybe a SHOULD is more correct here?) #22 6.1 - asking that key lengths (strengths really) be "in accordance" with requirements is a bit optimistic - how is one supposed to know that 67bit strength is ok or not? We usually do this in a gross manner, currently 80/128 bits of strength. Its also typical to say that commensurate strength is at least a SHOULD requirement. Its also quite unlikely that e.g. FIPS accredited interfaces for 67bit strength ciphers will be developed, so I'm very unsure that this is worthwhile. I also think its less likely that you'd be able to justify 40bit strength (maybe worth a try, not sure) in which case choices other than 80bit and 128 equivalent strength seem wrong. #23 6.1 has MAY requirements for tunnelling and load-balancing without any explanation or reference - I don't get what that's for anyway. #24 6.2's 1st MUST parenthetically implies that integrity has to be applied after confidentiality. Sign-then-encrypt is more common, though in LLNs there can be reasons to do encrypt-then-sign (or both). However, I'm surprised that you're mandating something like that here - is that deliberate? #24 6.2's 2nd MUST requires verifying "authenticity and liveliness" - what are those?o #25 6.2 - another weird bit of terminology; "MAY use security auditing mechanisms that are external to routing to verify the validity..." Auditing is not a run-time decision making mechanism in all cases of which I'm aware. #26 6.3 - I don't understand the impact of this section which contains only MAY requirements. This also needs rephrasing since there's no antecedent for the MAY statements, and the last one is hard to understand - what's an "insight"? #27 title of 6.4 is odd - it reads like an add-on #28 6.4 - does "MUST secure these mechanisms" mean "MUST use"? If so, what's special about multi-/any-cast? (vs. unicast that is) #29 6.4 - it makes no sense to me that a node MUST have physical security countermeasures just because it doesn't only use unicast. Is that what it really says here? (Sentence starting "Furthermore, the nodes MUST provide...") #30 6.4 "will assume" isn't 2119 language esp. when quoting bcp107 here it seems odd, suggest adding some 2119 statement. #31 6.4 "public certificates" is wrong, you mean "public key certificates" #32 6.4 - rfc3029 is a *very* odd citation - why that experimental non-repudiation related protocol? I am unaware of any LLN related experimental deployment of 3029 which is just not designed for challenged environments, never mind anything better. (Such as real deployment.) #33 6.4 "must support means for secure config..." s/must/MUST/ probably? #34 6.4 - One sentence has a *lot* of MUSTs in it - "secure configuration, device authentication, and adherence to secure key wrapping" and that's for cases where PKI it too heavyweight? I don't think we'll benefit from more security fig-leaves for the Internet and this sounds like one. I think this aspect needs more real thought - for an LLN that cannot support the complexity of PKI what do we think is reasonably required? (I'm ok to help try figure that out, but I do not believe we know the answer right now.) #35 6.4 - I like the idea of using IKE/IPsec where useful/possible. However, (presumably transport mode) IPsec will only supply security services for moving roll/RPL messages between nodes, so what about the other services needed? E.g. I can't see how the 2nd bullet from 6.2 could be satisfied by IPsec. #36 6.4 - It seems a tall order for roll to "adapt" things like mikey in order to make progress. Is that really what you think is needed? If so, what kind of adaptation and where might that be done? #37 6.5.1 - is this what you meant to say: "On the other hand, providing four individual domain designs that attempt to a priori match each individual domain is also very likely to provide a suitable answer given the degree of network variability even within a given domain; furthermore, the type of link layers in use within each domain also influences the overall security." It reads like it ought to say "is also very unlikely" but it says "likely," which is also not that easy to believe. #38 6.5.1: "Instead, the framework implementation approach recommended for optional, routing protocol-specific measures that can be applied separate from or together with flexible transport network mechanisms." Should that be "recommended is for"? (Couple more typos in that paragraph as well.) #39 6.5.2: typo: "and allow for flexible expiration scheme of authentication credentials" s/for flexible/for a flexible/ #40 6.5.2: typo: "There and other.." (and more typos in that paragraph)
(Tim Polk) (was No Objection) Discuss
Discuss (2011-01-20 for -)
I think this is a really good document, and support its publication. However, I think some of the issues I was persuaded to remove from my discuss on roll-rpl because they would be more appropriate in this document were omitted. I am specifically concerned about punting the details on public key distribution, then finding they are not covered here either. Did I get the wrong document? Where are those issues going to be addressed? I will hold this discuss while we sort out the best place to address these issues...
(Adrian Farrel) Yes
Comment (2011-05-02 for -)
Additional nit per David Black Section 6.1 I would have used the word "confidentiality" instead of "privacy" in stating the second requirement
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
(Russ Housley) (was Discuss) No Objection
Alexey Melnikov No Objection
(Dan Romascanu) No Objection
Comment (2011-01-20 for -)
I support the position expressed by Russ in his DISCUSS.
(Peter Saint-Andre) No Objection
Comment (2011-01-19 for -)
Overall this is a fine document. Several infelicities in the text might cause confusion: 1. In Section 3.2, "the service of non-repudiation implies after-the-fact" sounds like it should be "the service of non-repudiation applies after-the-fact" but instead the authors seem to mean that "the service of non-repudiation implies that the attack occurs after the fact" or somesuch. 2. In Section 3.3, "can all contribute to key management issues" could be construed as contributing to important or critical ("key") issues related to network management, not as "complicating the operations of key management" as in the previous paragraph; I suggest repeating the previously-used phrasing. There are also several unfortunate typographical errors (e.g., "fundament" instead of "fundamental" in Section 3.4, "undue utilization of exhaustion" instead of "undue utilization or exhaustion" in Section 4.3.4, "any device local or remote" instead of "any local or remote device" in Section 5.1.5, "compliment" instead of "complement" in Section 6.1, "aimed the manipulation" instead of "aimed at the manipulation" in Section 6.5). With regard to Denial of Service (DoS) in Section 4.3.3, please add a reference to RFC 4732. Please provide informative references for OSPF and ISIS in Section 5.2.5. In Section 6.1, is uppercase "MAY" meant in the text "new ciphering key may therefore be concurrently generated or updated"? In Section 6.4, is uppercase "MUST" meant in the text "a LLN must include a process for key and credential distribution"? In Section 6.4, is uppercase "SHOULD" meant in the text Correspondingly, the routing protocol(s) specified by the ROLL Working Group should assume that the system affords key management mechanisms consistent with the guidelines given in [RFC4107]"? In Section 6.5, is uppercase "SHOULD" meant in the text " As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy"? (And so on; in general, I suggest that the authors check all lowercase keywords throughout Section 6.)