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

From: John Dowdell <[email-masked]>
Date: Wed, 27 Apr 2016 21:10:17 +0100

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

---

From: John Dowdell <[email-masked]>
Date: Wed, 27 Apr 2016 22:38:47 +0100

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

> On 27 Apr 2016, at 21:27, Christopher Dearlove <[email-masked]> 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 21:10, John Dowdell <[email-masked]> wrote:
>> 
>> Hi all
>> 
>> _______________________________________________
>> manet mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 27 Apr 2016 23:11:21 +0100

Neither would I. Single shared key was what we were able to get 7181 passed referring to (7183) as a lowest common denominator "must implement, don't have to use". And I'm not certain it would pass again today. And not what I'd want to use.

(I should note that I slightly oversimplified when I said single shared secret key. The actual mechanism is more than one key, with IDs. But with no mechanism to choose among them.)

Beyond that, key management in an ad hoc network is hard because of the chicken and egg problem of finding routes securely and using routes to exchange material. Plus additional complications of multicast. And reactive is probably worse than proactive.

Do I think it's an impossible problem? No. But I don't think there's anything convincing that can be simply said "do this, it works". I'd like to be wrong, something simple that solves all your problems would be great. But at this point I don't think I am.

What I do think is that this is a suitable problem for future work. (Subject to all the comments I've made about people, interest etc.) But I don't know how you handle it now. The shared secret key I've noted was how we broke our logjam - and it took a lot longer than the time you've got. A real solution, longer still.

You could try just saying something about automatic key management without having an actual approach, let alone a defined interoperable one. If it passed the IESG I'd be flabbergasted. I'd not even be happy for it to pass WGLC.

Solution? Sorry, don't have one beyond what I've said above.

-- 
Christopher Dearlove

> On 27 Apr 2016, at 22:38, John Dowdell <[email-masked]> wrote:
>

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 27 Apr 2016 23:16:04 +0100

I should have said that this might be an area to discuss in a rechartered piece of work on security/encryption. But unless there's something I definitely missed, I don't think there's a worked out solution here.

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

--  
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

---

From: Christopher Dearlove <[email-masked]>
Date: Wed, 27 Apr 2016 23:16:17 +0100

-- 
Christopher Dearlove

---

From: John Dowdell <[email-masked]>
Date: Thu, 28 Apr 2016 20:37:00 +0100

By the way I have re-ordered the emails in this post to make it easier to read for flow.
> 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 rout…

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

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 28 Apr 2016 21:11:39 +0100

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.

Each router needing some preconfiguration, sure. See the IBS draft for example.

> On 28 Apr 2016, at 20:37, John Dowdell <[email-masked]> wrote:
> 
>>>> 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 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.
>>

---

From: John Dowdell <[email-masked]>
Date: Thu, 28 Apr 2016 21:22:56 +0100

> On 28 Apr 2016, at 21:11, Christopher Dearlove <[email-masked]> wrote:
> 

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

> [email-masked] <mailto:[email-masked]> (iPhone)
> [email-masked] <mailto:[email-masked]> (home)
> 
>> On 28 Apr 2016, at 20:37, John Dowdell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>>> On 27 Apr 2016, at 21:10, John Dowdell <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Hi all
>>>>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 28 Apr 2016 22:27:26 +0200

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

> On 28 Apr 2016, at 22:22, John Dowdell <[email-masked]> wrote:
> 
>

---

From: Christopher Dearlove <[email-masked]>
Date: Thu, 28 Apr 2016 21:48:30 +0100

Not interested in that case either. Some might be, sure. But it would make a very poor model as your baseline. A single shared key in your network, which I agreed earlier wasn't a great model, is still better than that.

Why? Because manufacturer isn't aligned to any trust model I'd have. Generally everyone - people I trust, people I don't trust - all buy from the same manufacturers.

> On 28 Apr 2016, at 21:22, John Dowdell <[email-masked]> wrote:
> 
>

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 28 Apr 2016 18:59:56 -0400

There is some IPR that I'm aware of that may help out here - it's based on
my prior work at Cisco. I've already let Alvaro know; he's going to check
into getting Cisco to make a disclosure...

Regards,
Stan

On Thu, Apr 28, 2016 at 4:11 PM, Christopher Dearlove <
[email-masked]> 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.
>
> >>>> 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.
> >>
> >>>> 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.
> >>>>
> >>>> - 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.
> >>>>
> >>>> - 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.
> >>>>
> >>>> 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
> >>>>
> >>>>
> >>>>
> >>
> >>> 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
> >>>
> >> 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
> >
> >>>>

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 29 Apr 2016 00:21:38 +0100

Building something into the base AODVv2 specification that relies on Cisco's (or anyone else's) IPR isn't going to be acceptable either.

> On 28 Apr 2016, at 23:59, Stan Ratliff <[email-masked]> wrote:
> 
> There is some IPR that I'm aware of that may help out here - it's based on my prior work at Cisco. I've already let Alvaro know; he's going to check into getting Cisco to make a disclosure... 
> 
> Regards,
> Stan
> 
> 
>> On Thu, Apr 28, 2016 at 4:11 PM, Christopher Dearlove <[email-masked]> wrote:

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 29 Apr 2016 00:24:19 +0100

I meant to add might however be interesting, even useful in another case.

-- 
Christopher Dearlove

> On 29 Apr 2016, at 00:21, Christopher Dearlove <[email-masked]> wrote:
>