idnits 2.17.1 draft-bormann-core-ipsec-for-coap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 06, 2012) is 4157 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-12 ** Obsolete normative reference: RFC 4835 (Obsoleted by RFC 7321) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational December 06, 2012 5 Expires: June 9, 2013 7 Using CoAP with IPsec 8 draft-bormann-core-ipsec-for-coap-00 10 Abstract 12 CoAP is a RESTful transfer protocol for constrained nodes and 13 networks. Security for the protocol can be supplied in a number of 14 ways. The mandatory-to-implement security mode for CoAP makes use of 15 DTLS. Other applications may want to use IPsec. 17 This document will discuss considerations for the use of IPsec with 18 CoAP. It will be advanced on a timescale separate from the main CoAP 19 specification, as most experience in securing CoAP so far has been 20 made with DTLS. 22 The current version of this specification is a placeholder, built out 23 of text extracted from draft-ietf-core-coap-12. It is meant to pick 24 up http://trac.tools.ietf.org/wg/core/trac/ticket/262 and provide a 25 home for its considerations. It might be merged with other documents 26 later. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on June 9, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Using CoAP with IPsec . . . . . . . . . . . . . . . . . . . . . 4 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 (see abstract for now) 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119, BCP 14 79 [RFC2119] and indicate requirement levels for compliant CoAP 80 implementations. 82 In this document, the term "byte" is used in its now customary sense 83 as a synonym for "octet". 85 Where bit arithmetic is explained, this document uses the notation 86 familiar from the programming language C, except that the operator 87 "**" stands for exponentiation. 89 2. Using CoAP with IPsec 91 One mechanism to secure CoAP [I-D.ietf-core-coap] in constrained 92 environments is the IPsec Encapsulating Security Payload (ESP) 93 [RFC4303] when CoAP is used without DTLS in NoSec Mode. Using IPsec 94 ESP with the appropriate configuration, it is possible for many 95 constrained devices to support encryption with built-in link-layer 96 encryption hardware. For example, some IEEE 802.15.4 radio chips are 97 compatible with AES-CBC (with 128-bit keys) [RFC3602] as defined for 98 use with IPsec in [RFC4835]. Alternatively, particularly on more 99 common IEEE 802.15.4 hardware that supports AES encryption but not 100 decryption, and to avoid the need for padding, nodes could directly 101 use the more widely supported AES-CCM as defined for use with IPsec 102 in [RFC4309], if the security considerations in Section 9 of that 103 specification can be fulfilled. 105 Necessarily for AES-CCM, but much preferably also for AES-CBC, static 106 keying should be avoided and the initial keying material be derived 107 into transient session keys, e.g. using a low-overhead mode of IKEv2 108 [RFC5996] as described in [I-D.kivinen-ipsecme-ikev2-minimal]; such a 109 protocol for managing keys and sequence numbers is also the only way 110 to achieve anti-replay capabilities. However, no recommendation can 111 be made at this point on how to manage group keys (i.e., for 112 multicast) in a constrained environment. Once any initial setup is 113 completed, IPsec ESP adds a limited overhead of approximately 10 114 bytes per packet, not including initialization vectors, integrity 115 check values and padding required by the cipher suite. 117 When using IPsec to secure CoAP, both authentication and 118 confidentiality SHOULD be applied as recommended in [RFC4303]. The 119 use of IPsec between CoAP endpoints is transparent to the application 120 layer and does not require special consideration for a CoAP 121 implementation. 123 IPsec may not be appropriate for all environments. For example, 124 IPsec support is not available for many embedded IP stacks and even 125 in full PC operating systems or on back-end web servers, application 126 developers may not have sufficient access to configure or enable 127 IPsec or to add a security gateway to the infrastructure. Problems 128 with firewalls and NATs may furthermore limit the use of IPsec. 130 3. IANA Considerations 132 (none foreseen.) 134 4. Security Considerations 136 TBD. 138 5. Acknowledgements 140 This text was extracted from draft-ietf-core-coap-12.txt and probably 141 mostly was written by Zach Shelby. 143 6. References 145 6.1. Normative References 147 [I-D.ietf-core-coap] 148 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 149 "Constrained Application Protocol (CoAP)", 150 draft-ietf-core-coap-12 (work in progress), October 2012. 152 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 153 Requirement Levels", BCP 14, RFC 2119, March 1997. 155 [RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher 156 Algorithm and Its Use with IPsec", RFC 3602, 157 September 2003. 159 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 160 RFC 4303, December 2005. 162 [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM 163 Mode with IPsec Encapsulating Security Payload (ESP)", 164 RFC 4309, December 2005. 166 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 167 Requirements for Encapsulating Security Payload (ESP) and 168 Authentication Header (AH)", RFC 4835, April 2007. 170 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 171 "Internet Key Exchange Protocol Version 2 (IKEv2)", 172 RFC 5996, September 2010. 174 6.2. Informative References 176 [I-D.kivinen-ipsecme-ikev2-minimal] 177 Kivinen, T., "Minimal IKEv2", 178 draft-kivinen-ipsecme-ikev2-minimal-01 (work in progress), 179 October 2012. 181 Author's Address 183 Carsten Bormann 184 Universitaet Bremen TZI 185 Postfach 330440 186 Bremen D-28359 187 Germany 189 Phone: +49-421-218-63921 190 Email: cabo@tzi.org