Subject: [secdir] Security review of draft-ietf-core-coap-14

From: Alexey Melnikov <[email-masked]>
Date: Tue, 02 Apr 2013 14:14:10 +0100

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors.  Document editors and WG chairs should treat these 
comments just like any other last call comments.

This document defines the Constrained Application Protocol (CoAP), which 
is a specialized web transfer protocol (basically a binary protocol that 
provides a subset of HTTP functionality) for use with constrained nodes 
and constrained (e.g., low-power, lossy) networks.  The nodes often have 
8-bit microcontrollers with small amounts of ROM and RAM, while 
constrained networks such as 6LoWPAN often have high packet error rates 
and a typical throughput of 10s of kbit/s.  The protocol is designed for 
machine-to-machine applications such as smart energy and building 
automation.

The Security Consideration points to Section 15 of RFC 2616 (among other 
things). I think this is quite appropriate, as RFC 2616 covers lots of 
relevant issues, including disclosure of sensitive information.

The Security Consideration section correctly points out
that Protocol Parsing complexity can lead to vulnerabilities,
in particular parsing/processing of URIs.

Section 11.3 talks about risk of amplification attacks (causing bigger 
packets to be sent to a victim based on smaller packets sent by an 
attacker) and possible mitigations. Section 11.4 talks about IP Address 
Spoofing Attacks (message spoofing, making endpoints "deaf", cache 
poisoning, etc.). Section 11.2 talks about Proxying and Caching attacks 
(Denial-of-service, threat to confidentiality and integrity of 
request/response data). Many mitigation techniques depend on use of DTLS 
(modes other than NoSec), but this is fine, as one of DTLS modes is 
mandatory to implement for all compliant CoAP nodes.

I appreciated text describing possible cross protocol attacks, in 
particular when DNS packets are sent to a CoAP endpoint.

Section 9 (Securing CoAP) talks about several modes of securing CoAP 
with DTLS. It talks about how certificate verification should be done 
and provisioning of raw public keys. These sections seem to be well 
written and sufficiently detailed to implement.

Overall I think that the document has very good and detailed security 
considerations.

Minor issues/nits:

9.1.3.2.  Raw Public Key Certificates

    In this mode the device has an asymmetric key pair but without an
    X.509 certificate (called a raw public key).  A device MAY be
    configured with multiple raw public keys.  The type and length of the
    raw public key depends on the cipher suite used.  Implementations in
    RawPublicKey mode MUST support the mandatory to implement cipher
    suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as specified in
    [I-D.mcgrew-tls-aes-ccm-ecc],

It looks like this reference is Normative, while you have it as Informative.

    [RFC5246], [RFC4492].  The mechanism
    for using raw public keys with TLS is specified in
    [I-D.ietf-tls-oob-pubkey].

9.1.3.2.1.  Provisioning

    The RawPublicKey mode was designed to be easily provisioned in M2M
    deployments.  It is assumed that each device has an appropriate
    asymmetric public key pair installed.  An identifier is calculated
    from the public key as described in Section 2 of
    [I-D.farrell-decade-ni].  All implementations that support checking
    RawPublicKey identities MUST support at least the sha-256-120 mode
    (SHA-256 truncated to 120 bits).  Implementations SHOULD support also

I think you need a Normative reference to SHA-256 here.

    longer length identifiers and MAY support shorter lengths.  Note that
    the shorter lengths provide less security against attacks and their
    use is NOT RECOMMENDED.

Best Regards,
Alexey

P.S. I have some Apps specific issues with the document, but I send 
these separately in my AppsDir review.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Apr 2013 18:32:20 +0200

Alexey,

thank you for this thoughtful review.

> It looks like this reference is Normative, while you have it as Informative.

We will add this as a normative reference in draft-ietf-core-coap-15.

> I think you need a Normative reference to SHA-256 here.

Actually, we specifically require the sha-256-120 mode from draft-farrell-decade-ni (the parenthetical remark is just explanatory), which is a normative reference and in turn has SHA-256 (FIPS PUB 180-3) as a normative reference.

(We also reference RFC 6347, which does not reference SHA-256, but references RFC 5246, which finally references FIPS PUB 180-2.   Of course, we could reference FIPS PUB 180-4, if that helps, but we would like to avoid the "transitive closure" effect.  Or maybe draft-farrell-decade-ni should be updated to FIPS PUB 180-4 before publication.  Or maybe not, which is another reason not to try doing the transitive closure.)

> P.S. I have some Apps specific issues with the document, but I send these separately in my AppsDir review.

Looking forward to it!

Grüße, Carsten