[secdir] Security review of draft-ietf-core-coap-14
Alexey Melnikov <alexey.melnikov@isode.com> Tue, 02 April 2013 13:13 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEB221F84BC; Tue, 2 Apr 2013 06:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPcLBYI9bODQ; Tue, 2 Apr 2013 06:13:28 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2CAE221F8700; Tue, 2 Apr 2013 06:13:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1364908405; d=isode.com; s=selector; i=@isode.com; bh=RiKMAjcFEXvq8ERlhTg4IhLUD2vgtq994PPyh5f6eBw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IbBGjYTP2k3UrRc/XUv6QzWOYo0ewPKru8Ki8HMk3KTz8DKJbXnIfGY+Sq7JK3lyXfiJCs 8v2JZM2hHaQq5EHLHJS+B64JHrt65ldsdZBKhp5Wuh0pDJ4/GHg7X2S99X9K2k/dct/1Xz 7UTOhWPuXeNksz7mIYQNrNtElP4GCjU=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id <UVrZdQAF4pMh@waldorf.isode.com>; Tue, 2 Apr 2013 14:13:25 +0100
Message-ID: <515AD9A2.4030003@isode.com>
Date: Tue, 02 Apr 2013 14:14:10 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: The IESG <iesg@ietf.org>, secdir@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-core-coap.all@tools.ietf.org
Subject: [secdir] Security review of draft-ietf-core-coap-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2013 13:13:29 -0000
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.
- [secdir] Security review of draft-ietf-core-coap-… Alexey Melnikov
- Re: [secdir] Security review of draft-ietf-core-c… Carsten Bormann