idnits 2.17.1 draft-porambage-core-ace-x509-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3723 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'I-D.ietf-core-coap' on line 218 -- Looks like a reference, but probably isn't: 'RFC6347' on line 210 -- Looks like a reference, but probably isn't: 'RFC5280' on line 213 -- Looks like a reference, but probably isn't: 'I-D.ietf-lwig-terms' on line 224 -- Looks like a reference, but probably isn't: 'RFC2119' on line 207 -- Looks like a reference, but probably isn't: 'I-D.draft-schmitt-two-way-authentication-for-iot' on line 230 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Porambage 3 Internet-Draft University of Oulou 4 Intended status: Standards Track C. Schmitt 5 Expires: August 18, 2014 University of Zurich 6 A. Gurtov 7 Aalto University 8 S. Gerdes 9 Universitaet Bremen TZI 10 February 14, 2014 12 X.509 Public Key Infrastructure Certificates for the Constrained 13 Application Protocol (CoAP) 14 16 Abstract 18 The Constrained Application Protocol (CoAP) is a web transfer 19 protocol designed for resource limited nodes in constrained networks. 20 For securing the protocol, CoAP defines a binding to Datagram 21 Transport Layer Security (DTLS) with four security modes. One of 22 them is the Certificate mode where the device has an asymmetric key 23 pair with an X.509 certificate. However, the intrinsic properties of 24 x.509 certificates impede the application on the resource constrained 25 nodes. This draft describes the necessary adjustments and derives a 26 modified profile for X.509 certificates to cope with the resource 27 limitations of low-power low-performing devices 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 18, 2014. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Design Requirements . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Overview of the approach . . . . . . . . . . . . . . . . . . . 4 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 74 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 76 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 8.1. Norminative References . . . . . . . . . . . . . . . . . . 5 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 84 1. Introduction 86 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is 87 proposed as a lightweight alternative for HTTP protocol, in order to 88 support web services while realizing the REST architecture on top of 89 the most constrained nodes and networks. CoAP is designed for the 90 special requirements of this constrained environments, especially 91 considering energy, building automation and other machine-to-machine 92 (M2M) applications. 94 CoAP defines a binding to Datagram Transport Layer Security (DTLS) 95 [RFC6347] and specifies four security modes: NoSec, PreSharedKey, 96 RawPublicKey and Certificate. In the Certificate Mode, the device 97 has an X.509 certificate [RFC5280], which binds the public key of the 98 device to its Authority name and is signed by a common trust root. 100 Complex asymmetric algorithms like RSA use a lot of resources such as 101 processing power and memory. Devices may have to dedicate the major 102 portion of these resources on security algorithms instead of spending 103 them on the application they are intended for. Therefore, it is 104 necessary to adapt a low cost solution for the DTLS Certificate mode 105 in CoAP. 107 Mismatches of X.509 certificates in their original formats; According 108 to [RFC5280] the content of X.509 certificates is mainly composed of 109 three parts: TBSCertificate, Signature Algorithm and Signature Value. 110 We would like to focus on the internal configurations and attributes 111 of TBSCertificate component. The standard X.509 certificates use RSA 112 public key algorithm and keys as the public key infrastructure. 113 According to the definitions of Classes of devices as given in 114 [I-D.ietf-lwig-terms] class 0 and 1 are the most constrained devices. 115 These low performing devices are not capable of handling RSA PKI 116 algorithms due to their limited memory capacities and processing 117 capabilities. 119 1.1. Document Structure 121 Section 2 mentions conventions used in this draft. Afterwards the 122 assumed design requirements are briefly mentioned in Section 3. 123 Section 4 describes the proposed approach using X.509 public key 124 infrastructure (PKI) certificates for CoAP,followed by security 125 considerations. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Design Requirements 135 The key design goal is to profile the content and operations of X.509 136 certificates in such a way to balance the resource constraints of the 137 devices along with the security requirements. Therefore, we 138 emphasize the following design requirements: Low memory consumption; 139 Less complexity of mathematical operations for authentication and 140 authorization processes; Support interoperability among different 141 vendor devices. Alternatively, we focus on profiling X.509 142 certificates according to the specifications of CoAP enabled devices. 144 4. Overview of the approach 146 It is obvious that the utilization of X.509 certificates with RSA 147 public key algorithm would not be a lightweight solution. We can 148 adjust the size and the complexity of the certificate by changing the 149 attributes in TBSCertificate part in the original certificates. 150 Elliptic Curve Cryptography (ECC) algorithms would be suitable 151 candidate for PKI replacement in X.509 certificates. Alternatively 152 this could be reusable for digital signature in the certificates too. 153 For instance the algorithm in Elliptic Curve Qu-Vanstone Implicit 154 Certificate Scheme (ECQV) would be a feasible solution for this[1]. 156 5. Security Considerations 158 The following security goals are addressed by the key idea presented 159 in this draft similar to proposed considerations in 160 [I-D.draft-schmitt-two-way-authentication-for-iot]: 162 Authenticity 164 Recipients of a message can identify their communication partners 165 and can detect if the sender information has been forged. 167 Integrity 169 Communication partners can detect changes to a message during 170 transmission. 172 Confidentiality 174 Attackers cannot gain knowledge about the content of a secured 175 message. 177 6. Acknowledgement 179 This work has been supported by Tekes under Massive Scale Machine-to- 180 Machine Service (MAMMotH) project and Academy of Finland project 181 SEMOHealth. 183 The ongoing work is supported partially by the SmartenIT [2] and the 184 FLAMINGO [3] projects, funded by the EU FP7 Program under Contract 185 No. FP7-2012-ICT-317846 and No. FP7-2012-ICT-318488, respectively. 187 7. Formal Syntax 189 CoAP - Constrained Application Protocol 191 DTLS - Datagram Transport Layer Security 193 ECC - Elliptic Curve Cryptography 195 ECQV - Elliptic Curve Qu-Vanstone Implicit Certificate Scheme 197 IETF - Internet Engineering Task Force 199 M2M - Machine-to-Machine 201 PKI - Public Key Infrastructure 203 8. References 205 8.1. Norminative References 207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 208 Requirement Levels", BCP 14, RFC 2119, March 1997. 210 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 211 Security Version 1.2", RFC 6347, January 2012. 213 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 214 Housley, R., and W. Polk, "Internet X.509 Public Key 215 Infrastructure Certificate and Certificate Revocation List 216 (CRL) Profile", RFC 5280, May 2008. 218 [I-D.ietf-core-coap] 219 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 220 Application Protocol (CoAP), http://www.ietf.org/ 221 internet-drafts/draft-ietf-core-coap-18.txt", 222 draft-ietf-core-coap-18 (work in progress), March 2013. 224 [I-D.ietf-lwig-terms] 225 Bormann, C. and M. Ersue, "Terminology for Constrained 226 Node Networks, http://www.ietf.org/internet-drafts/ 227 draft-ietf-lwig-terms-00.txt", draft-bormann-lwig-terms-00 228 (work in progress), November 2012. 230 [I-D.draft-schmitt-two-way-authentication-for-iot] 231 Schmitt, C. and B. Stiller, "DTLS-based Security with two- 232 way Authentication for IoT, http://www.ietf.org/id/ 233 draft-schmitt-two-way-authentication-for-iot-02.txt", 234 draft-schmitt-two-way-authentication-for-iot-02 (work in 235 progress), February 2014. 237 8.2. Informative References 239 [1] "Elliptic Curve Qu-Vanstone Implicit Certificate Scheme 240 (ECQV), v0.97, 241 http://www.secg.org/download/aid-785/sec4-0.97.pdf", 242 SEC 4, March 2011. 244 [2] SmartenIT Consortium, "Socially-aware Management of New 245 Overlay Application Traffic combined with Energy 246 Efficiency in the Internet (SmartenIT), 247 http://www.smartenit.eu/", 20103. 249 [3] Flamingo Consortium, "FLAMINGO - Management of the Future 250 Internet, http://www.fp7-flamingo.eu/", 2013. 252 Authors' Addresses 254 Pawani Porambage 255 University of Oulou 256 P.O. Box 4500 257 Oulu 90014 258 Finland 260 Email: pporamba@ee.oulu.fi 261 Corinna Schmitt 262 Univerity of Zurich 263 Department for Informatics 264 Communication Systems Group 265 Binzmuehlestrasse 14 266 Zurich 8050 267 Switzerland 269 Email: schmitt@ifi.uzh.ch 271 Andrei Gurtov 272 Aalto University 273 Otakaari 1 274 Espoo 02150 275 Finland 277 Email: gurtov@hiit.fi 279 Stefanie Gerdes 280 Universitaet Bremen TZI 281 Postfach 330440 282 Bremen 28359 283 Germany 285 Email: gerdes@tzi.org