Security re-focus on public keys

[zach@…]

Previously the CoAP security section has focused its attention to shared keys, and has been depending on the WG to create a suitable symmetric key provisioning and management scheme for CoRE. This task has turned out to be more difficult than planned, and progress hasn't really been made.

In Quebec the WG found consensus to re-focus on the provisioning and mangement of public keys. The following changes to the draft were proposed:

1. The SharedKey? and MultiKey? modes are combined into a PreSharedKey? mode. This mode can be used if PSKs are already available, but it does not attempt to describe how to acquire them. This mode is useful for vendors, systems or other SDOs that already have their own shared key management.

2. New sections on the provisioning of public keys and access control using them will be added (before Section 10.1).

3. A new RawPublicKey? mode will be added, that defines the use of raw public keys with hashed identity (for access control). It will be defined how this key mode can be used with DTLS (TBD, dummy certificate wrapping?) and IPsec.

[zach@…]

The following section was added to the draft.

10.3.4. IP Address Spoofing Attacks

Due to the non-reliability of UDP (and to some extent to the
duplicate message processing strategy), a rogue endpoint which is
free to read and write messages carried by the constrained network
(i.e. NoSec? or PreSharedKey? deployments with nodes/key ratio > 1:1),
may easily attack a single endpoint, a group of endpoints, as well as
the whole network e.g. by:

1. spoofing RST in response to a CON message, thus making an

endpoint "deaf"; or

2. spoofing the entire response with forged payload/options (this

has different levels of impact: from single response disruption,
to much bolder attacks on the supporting infrastructure, e.g.
poisoning proxy caches, or tricking validation / lookup
interfaces in resource directories and, more generally, any
component that stores global network state and uses CoAP as the
messaging facility to handle state set/update's is a potential
target.); or

3. spoofing a multicast request for a target node which may result

in both network congestion/collapse and victim DoS'ing / forced
wakeup from sleeping; or

4. spoofing observe messages, etc.

In principle, spoofing can be detected by CoAP only in case CON
semantics is used, because of unexpected ACK/RSTs coming from the
deceived endpoint. But this imposes keeping track of the used MIDs
which is not always possible, and moreover detection becomes
available usually after the damage is already done. This kind of
attack can be prevented using PreSharedKey? (with a 1:1 node/key
ratio) or Certificate security modes.

[zach@…]

Wrong ticket, re-opened.

[zach@…]

The RPK re-focus is now in good shape, so now closing this ticket.