Re: [manet] AODVv2 security: Key Management to BCP107

[Thomas Heide Clausen <[e-mail]>]

I must say, I fully share Chris' strong reservations. This is not the solution. 

> On 28 Apr 2016, at 22:22, John Dowdell <[e-mail]> wrote:
> 
> 
>> On 28 Apr 2016, at 21:11, Christopher Dearlove <[e-mail]> wrote:
>> 
>> I really wouldn't be interested in a system in which each router had to have knowledge of all other routers. Far too restrictive, and scales poorly. It just might fly as a solution. As the solution, definitely not.
> 
> Not all individual routers, just the implementors. Implementor A knows of and (at least partly) trusts routers made by Implementor B. You could break that down by model and year of manufacture if you wanted.
> 
> John
> 
>> 
>> Each router needing some preconfiguration, sure. See the IBS draft for example.
>> 
>> --  
>> Christopher Dearlove
>> [e-mail] (iPhone)
>> [e-mail] (home)
>> 
>>> On 28 Apr 2016, at 20:37, John Dowdell <[e-mail]> wrote:
>>> 
>>> By the way I have re-ordered the emails in this post to make it easier to read for flow.
>>>> 
>>>>>> On 27 Apr 2016, at 21:10, John Dowdell <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi all
>>>>>> 
>>>>>> As an AODVv2 co-author I’d like to propose this position regarding key management against BCP107, one of the artefacts we are being asked to state a position over. I’d also like to state that I’m open to contributions from others knowledgeable on this topic or who have been this way previously.
>>>>>> 
>>>>>> If you’re not familiar (and I wasn’t), RFC4107 aka BCP107 is the set of guidelines for choosing either automated or manual key management for cryptographic purposes. It’s not a long read and guides the reader through a set of tests as to whether automated or manual key management would be suitable for the application in hand.
>>>>>> 
>>>>>> The very first question is does AODVv2 need key management at all? I would contend that it does, since we require to secure the signalling traffic for the routing algorithm. The aim here is therefore to purely assist in the security of the signalling traffic; security of user data that is forwarded once an AODVv2 route has been established is out of scope.
>>>>>> 
>>>>>> Section 1 of BCP107 states that automated key management SHOULD be used.. Thus my answer will be in favour of that unless I can contend otherwise.
>>>>>> 
>>>>>> The guidelines in section 2 outline that automated key management derives short-term session keys between two parties. In the case of AODVv2, this would correspond to two routers that form or wish to form an adjacency.
>>>>>> 
>>>>>> The guidelines state that the short-term keys may be derived from long-term keys, and that the dissemination of long term keys is out of scope of BCP107. I would envisage that an AODVv2 router, given that it would form ephemeral ad hoc networks with other routers as it went about its business, would be supplied with one or more long term keys for a period of time, to be determined by the system integrator, and that the long term keys would then be used to derive short term keys which are used in the forming of adjacBy the way I have re-ordered the emails in this post to make it easier to read for flow.
>>>> 
>>>>>> On 27 Apr 2016, at 21:10, John Dowdell <[e-mail]> wrote:
>>>>>> 
>>>>>> Hi all
>>>>>> 
>>>>>> As an AODVv2 co-author I’d like to propose this position regarding key management against BCP107, one of the artefacts we are being asked to state a position over. I’d also like to state that I’m open to contributions from others knowledgeable on this topic or who have been this way previously.
>>>>>> 
>>>>>> If you’re not familiar (and I wasn’t), RFC4107 aka BCP107 is the set of guidelines for choosing either automated or manual key management for cryptographic purposes. It’s not a long read and guides the reader through a set of tests as to whether automated or manual key management would be suitable for the application in hand.
>>>>>> 
>>>>>> The very first question is does AODVv2 need key management at all? I would contend that it does, since we require to secure the signalling traffic for the routing algorithm. The aim here is therefore to purely assist in the security of the signalling traffic; security of user data that is forwarded once an AODVv2 route has been established is out of scope.
>>>>>> 
>>>>>> Section 1 of BCP107 states that automated key management SHOULD be used. Thus my answer will be in favour of that unless I can contend otherwise.
>>>>>> 
>>>>>> The guidelines in section 2 outline that automated key management derives short-term session keys between two parties. In the case of AODVv2, this would correspond to two routers that form or wish to form an adjacency.
>>>>>> 
>>>>>> The guidelines state that the short-term keys may be derived from long-term keys, and that the dissemination of long term keys is out of scope of BCP107. I would envisage that an AODVv2 router, given that it would form ephemeral ad hoc networks with other routers as it went about its business, would be supplied with one or more long term keys for a period of time, to be determined by the system integrator, and that the long term keys would then be used to derive short term keys which are used in the forming of adjacencies plural.
>>>>>> 
>>>>>> Section 2.1 of BCP107 describes the conditions under which automated key management MUST be used.
>>>>>> 
>>>>>> - If a large number of static keys would have to be managed. It is not known how many routers could be deployed, but if this is aimed at ad hoc applications then the number of routers could quickly become large. I consider this condition is met.
>>>>>> 
>>>>>> - Any stream cipher is used. This is a choice for the system integrator, but an AES based cipher is a real possibility. There is more likelihood this condition is met than not met.
>>>>>> 
>>>>>> - An initialisation vector (IV) might be re-used. I am open to advice on this point.
>>>>>> 
>>>>>> - Large amounts of data need to be encrypted in a short time. Even if there is no specific guidance on ‘large’, I do not consider this condition to be met, since signalling messages are likely to be short relative to the user data that could be exchanged.
>>>>>> 
>>>>>> - Long-term session keys are used by more than two parties, including multicast applications. AODVv2 uses multicast extensively, and therefore I consider this condition to be met.
>>>>>> 
>>>>>> - Device turnover is frequent. This is a certainty in ad hoc networks, so I consider this condition to be met.
>>>>>> 
>>>>>> I believe the outcomes from section 2.1 guidance is more in favour of automated key management.
>>>>>> 
>>>>>> However, to consider the guidance on manual key management in section 2.2 of BCP107, where such management may be reasonable:
>>>>>> 
>>>>>> - the environment has very limited bandwidth or high round trip times. Some applications for AODVv2 may use very low bandwidths, perhaps for low-power sensor networks. The point is made that "public key systems require long exchanges and lots of computation”. The AODVv2 author team believe that very low power hardware might be used by some implementors, which may give problems when being required to use public key exchanges. Such implementors need to carefully consider the tradeoff between the need for security and the need for very low power consumption. Such implementors should also consider whether some functions should be realised in hardware or software, and the resulting impact on system performance and power consumption.
>>>>>> 
>>>>>> - the information being protected is of low value. I do not consider this condition to be met; on the contrary, the signalling traffic in AODVv2 is of high value to a potential attacker.
>>>>>> 
>>>>>> - the scale of each deployment is limited. I consider that this is an unknown, but I also consider that we should engineer for larger networks with ephemeral connections rather than smaller ones.
>>>>>> 
>>>>>> Discussion welcome.
>>>>>> 
>>>>>> Regards
>>>>>> John
>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>>> On 27 Apr 2016, at 21:27, Christopher Dearlove <[e-mail]> wrote:
>>>>> 
>>>>> I really don't know what you are proposing. I think you have a great big can of worms here that hasn't been thought through.
>>>>> 
>>>>> So AODVv2 is sending, as it's very first message, an RREQ. We want to authenticate this. How? You can't negotiate a key, you haven't got a route. You don't know who your neighbours are. You plan to multicast to them in fact, what's your key plan for that?
>>>>> 
>>>>> If you say use long term key, what are you actually going to use the short term key for? And if you plan to exchange message with your neighbours, that rather preempts a significant part of your protocol (why establish bidirectionality when your key negotiation must have done that?)
>>>>> 
>>>>> And then we've spent some time discussing end to end authentication. That doesn't work with short term keys for adjacencies only.
>>>>> 
>>>>> We (OLSRv2) went through, more than once, a hard argument why automated key management wasn't appropriate here, and why the exceptions did apply.
>>>>> 
>>>>> But in a nutshell (though this wasn't the argument we used, just why we needed it) how can you agree a key without communicating? How do you communicate more than one hop without a route? How do you authenticate the messages to create that route without a key?
>>>>> 
>>>>> Something has to give. And in giving you might end up redesigning your whole protocol. Or using something quite clever that there's no hint of here. Or using the simplest fallback of a single shared key (our 7183 default) which isn't automatically managed.
>>>>> 
>>>>> -- 
>>>>> Christopher Dearlove
>>>>> 
>>>> On 27 Apr 2016, at 22:38, John Dowdell <[e-mail]> wrote:
>>>> 
>>>> OK so there’s a really big problem here. We were asked to run the guidance. Running the guidance gives the result below. In this case, the guidance is not giving a result that makes sense. The routers themselves are almost certainly on the move, there is no other reason why you would want to only determine the path at send time. You now have routers potentially from multiple organisations occasionally conversing with other routers. I do not see that a single shared key is going to pass muster; I certainly wouldn’t recommend such a use case.
>>>> 
>>>> Regards
>>>> John
>>> 
>>> One possible way forwards is to require all routers to have knowledge of some credentials of the other routers before AODVv2 can begin signalling. This isn’t so crazy as it might seem. Suppose such routers are installed in cars, and each manufacturer pre-loads the car with credentials of all the other manufacturers that it trusts for signalling purposes. Thus Ford (say) might pre-load credentials for Volkswagens. When a Ford and a Volkswagen meet, they already have some degree of trust, and therefore the burden of proof of identity in AODVv2 signalling is reduced, but not eliminated, because then we would be open to spoofing.
>>> 
>>> We are also here acting as part of a (hopefully) layered authentication system. The wireless devices will presumably be authenticated to each other, through some system that is suitable for the task in hand, and above routing there should be some checks on incoming user data to see if that is sensible.
>>> 
>>> Regards
>>> John
>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> manet mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet