idnits 2.17.1 draft-carpenter-anima-quads-grasp-03.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 June 2020) is 1395 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-25 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-41 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. E. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational 29 June 2020 5 Expires: 31 December 2020 7 Quick and Dirty Secure Autonomic Control Plane for GRASP 8 draft-carpenter-anima-quads-grasp-03 10 Abstract 12 A secure substrate known as the Autonomic Control Plane (ACP) is 13 required by the Generic Autonomic Signaling Protocol (GRASP) used by 14 Autonomic Service Agents. This document describes QUADS, a QUick And 15 Dirty Secure ACP using symmetric cryptography and preconfigured keys 16 or passwords. It also describes a simplistic QUADS Key 17 Infrastructure based on asymmetric cryptography used over insecure 18 instances of GRASP to create a QUADS ACP. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 31 December 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. QUick And Dirty Security ACP Method . . . . . . . . . . . . . 3 55 3. QUick And Dirty Security Key Infrastructure . . . . . . . . . 3 56 4. Implementation Status [RFC Editor: please remove] . . . . . . 6 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 8.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 9 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 66 1. Introduction 68 As defined in [I-D.ietf-anima-reference-model], the Autonomic Service 69 Agent (ASA) is the atomic entity of an autonomic function, and it is 70 instantiated on autonomic nodes. When ASAs communicate with each 71 other, they should use the Generic Autonomic Signaling Protocol 72 (GRASP) [I-D.ietf-anima-grasp]. It is essential that such 73 communication is strongly secured to avoid malicious interference 74 with the Autonomic Network Infrastructure (ANI). 76 For this reason, GRASP must run over a secure substrate that is 77 isolated from regular data plane traffic. This substrate is known as 78 the Autonomic Control Plane (ACP). A method for constructing an ACP 79 at the network layer is described in 80 [I-D.ietf-anima-autonomic-control-plane]. Scenarios for link layer 81 ACPs are discussed in [I-D.carpenter-anima-l2acp-scenarios]. The 82 present document describes a simple method of forming an ACP 83 immediately above the transport layer, known as QUADS (QUick And 84 Dirty Security) ACP for GRASP. 86 It also describes a simplistic key infrastructure known as QUADSKI, 87 using asymmetric cryptography embedded in GRASP objectives used over 88 insecure instances of GRASP. 90 2. QUick And Dirty Security ACP Method 92 Every GRASP message, whether unicast or multicast, is encrypted 93 immediately before transmission, and decrypted immediately after 94 reception, using the same symmetric encryption algorithm and domain- 95 wide shared keys. This applies to all unicast and multicast messages 96 sent over either UDP or TCP. Typically encryption will take place 97 immediately after a message is encoded as CBOR [RFC7049], and 98 decryption will take place immediately before a message is decoded 99 from CBOR. 101 There is no attempt to specify an automatic algorithm choice. Every 102 instance of GRASP in a given Autonomic Network (AN) must be pre- 103 configured with the choice of encryption algorithm and any necessary 104 parameters, and with the same key(s). 106 An alternative to configuring the keys is that every instance of 107 GRASP is pre-configured with a fixed salt value and the keys are 108 created from a locally chosen keying password, using a pre-defined 109 hash algorithm and that salt value. Note that the salt value cannot 110 be secret as it must be the same in all QUADS for all GRASP 111 implementations. In this model the secrecy depends on the keying 112 password. 114 The choice of algorithms should follow best current practice, e.g. 115 [RFC8221]. At present the following choices are recommended: AES/ 116 CBC, key length 32, initialisation vector length 16, padding 117 PKCS7(128). 119 3. QUick And Dirty Security Key Infrastructure 121 This uses a Diffie-Hellman key exchange to secure delivery of QUADS 122 keys from a key server in one autonomic node to another node wishing 123 to join the AN domain, known as a "pledge" to align with BRSKI 124 [I-D.ietf-anima-bootstrapping-keyinfra] terminology. 126 A QUADSKI key server exists in one instance in a given AN. It 127 supports two GRASP objectives, provisonally named "411:quadskip" and 128 "411:quadski". It runs via an instance of GRASP that is not running 129 QUADS, i.e. its traffic is not encrypted except as defined below. 131 "411:quadskip" is a synchronization objective that is flooded out to 132 all nodes in the AN. Its value is the PEM encoding of the public RSA 133 key of the QUADSKI server. In fragmentary CDDL [RFC8610], it is 134 defined as follows: 136 quadskip-objective = ["411:quadskip", objective-flags, loop-count, value] 137 objective-flags = ; as in the GRASP specification 138 loop-count = ; as in the GRASP specification 139 value = server-PEM 140 server-PEM = bytes 142 The recommended frequency of flooding is once per minute with a valid 143 life time of two minutes. By this means, every autonomic node can 144 learn the public key of the server. 146 "411:quadski" is a negotiation objective that is used by an autonomic 147 node that wishes to enrol securely in the AN, i.e. a pledge. In 148 fragmentary CDDL, it is defined as follows: 150 quadski-objective = ["411:quadski", objective-flags, loop-count, value] 151 objective-flags = ; as in the GRASP specification 152 loop-count = ; as in the GRASP specification 153 value = pledge-value / server-value 154 pledge-value = [encrypted-password, pledge-PEM] 155 server-value = encrypted-keys 156 encrypted-password = bytes 157 pledge-PEM = bytes 158 encrypted-keys = bytes 160 The encrypted-password is a previously agreed pledge password for the 161 AN domain, RSA-encrypted using the public key of the server. This 162 password should not be the same as the keying password used in 163 Section 2. 165 The pledge-PEM is the PEM encoding of the public RSA key of the 166 pledge node. 168 The encrypted-keys value is the result of the following process: 170 1. Assume the symmetric cryptography in use is AES/CBC, key length 171 32, initialisation vector length 16, padding PKCS7(128). 173 2. Let the key bytes be 'key' and the initialisation vector bytes be 174 'iv'. 176 3. Construct the array object [key, iv]. 178 4. Encode this object in CBOR. 180 5. Encrypt the resulting CBOR bytes with RSA using the public key of 181 the pledge ("pledge-PEM"). 183 6. The result is the value of "encrypted-keys". 185 The QUADSKI server must have possession of the AN domain keys 186 (Section 2) and the domain's pledge password when it starts up, by a 187 method not specified here. It then proceeds as follows: 189 1. Create an RSA key pair, store the private key, and prepare the 190 PEM encoding of the public key ("server-PEM"). 192 2. Start flooding out the "411:quadskip" objective with the "server- 193 PEM" value, using the GRASP M_FLOOD message. 195 3. Start listening for negotiation requests (GRASP M_NEG_REQ) for 196 the "411:quadski" objective. 198 4. Whenever it receives such a request, RSA-decrypt the "encrypted- 199 password" using its private key. 201 5. If the password matches, recover the pledge's public key from the 202 "pledge-PEM". 204 6. Generate the "encrypted-keys" value as described above, and reply 205 (GRASP M_NEGOTIATE) with that value. 207 7. Normally, the pledge will reply with GRASP M_END and an O_ACCEPT 208 option. 210 Error conditions such as a password mismatch will be handled like any 211 GRASP error condition, with GRASP M_END and an O_DECLINE option. 213 The pledge proceeds as follows: 215 1. Create an RSA key pair, store the private key, and prepare the 216 PEM encoding of the public key ("pledge-PEM"). 218 2. Wait until it detects the flooded "411:quadskip" option, at which 219 point it can recover the QUADSKI server's public key from the 220 "server-PEM" value. 222 3. Request the pledge password from the user. 224 4. RSA-encrypt the password using the server's public key. 226 5. Use GRASP discovery (M_DISCOVER "411:quadski") to locate the 227 QUADSKI server. 229 6. Construct a "411:quadski" objective whose value is [encrypted- 230 password, pledge-PEM] as described above. 232 7. Start the negotiation process (M_NEG_REQ). 234 8. When it receives a successful reply (M_NEGOTIATE), RSA-decrypt 235 the value using its own private key, decode the result from CBOR, 236 and thus recover the QUADS keys [key, iv]. 238 9. Close the GRASP session with M_END + O_ACCEPT. 240 In the pledge and the QUADSKI server, RSA encryption and decryption 241 should follow best current practice, e.g. [RFC8017]. At present the 242 following choices are recommended: public exponent 65537, key size 243 2048, padding OAEP with MGF1, hash SHA256. 245 As noted, this process uses unencrypted GRASP, since there are no 246 QUADS keys available until it ends. Unlike BRSKI 247 [I-D.ietf-anima-bootstrapping-keyinfra], it does not rely on any 248 limitation to link-local traffic, since it is protected by asymmetric 249 cryptography. However, for this to work on an evolving network where 250 nodes may enrol at any time, GRASP must run encrypted for nodes that 251 have acquired QUADS keys and simultaneously unencrypted for the 252 QUADSKI process. The simplest way to achieve this is to run two 253 GRASP instances as necessary. In particular, a node that acts as a 254 GRASP relay needs to be able to relay encrypted traffic (for enrolled 255 nodes) and unencrypted traffic (for nodes needing to run the QUADSKI 256 process). Note that such instances will receive GRASP broadcasts 257 that they cannot interpret (encrypted packets reaching an unencrypted 258 GRASP instance, and vice versa). These packets can be harmlessly 259 discarded. 261 Finally, the reader familiar with BRSKI may note that the QUADSKI 262 server replaces the role of the BRSKI Registrar, and the unencrypted 263 GRASP daemon replaces the role of the BRSKI Join Proxy. 265 4. Implementation Status [RFC Editor: please remove] 267 QUADS for GRASP has been implemented as a small extension to the 268 Python GRASP prototype, using the Python 'cryptography' module. The 269 algorithm choices were: 271 * Encryption: AES/CBC, key lengths 32/16, padding PKCS7(128). 273 * Password hash: PBKDF2HMAC SHA256, length 32, 100000 iterations. 275 * Salt used for keying password hash: 276 0xf474526a2e74accee189f1fbc1c34ceb. 278 QUADSKI for GRASP has been implemented as two Python ASAs, known as 279 'quadski.py' for the server and 'qpledge.py' for the pledge node. 280 These also use the Python 'cryptography' module. 282 RSA parameters: 284 Public Exponent 65537 286 Key Size 2048 288 Padding OAEP with MGF1 290 Hash SHA256 292 The code has been posted to https://github.com/becarpenter/graspy. 294 5. Security Considerations 296 QUADS provides effective secrecy for all GRASP messages, against any 297 party not in possession of the relevant shared keys. However, before 298 a GRASP message is encrypted or after it is decrypted, it is not 299 protected within the host. Therefore, secrecy is only effective 300 against nodes that do not contain a GRASP instance in possession of 301 the keys. Those nodes cannot send valid GRASP messages, and they 302 cannot interpret intercepted GRASP messages, including multicasts. 303 However, they might attempt traffic analysis. 305 QUADS provides authentication of GRASP instances to the extent that 306 they must be in possession of the relevant shared keys. 308 QUADS depends on pre-configuration of keys, or on password entry and 309 a public salt value, for each autonomic node, unless QUADSKI is in 310 use. 312 QUADS offers no defence against denial of service attacks. 314 QUADSKI securely avoids the need for pre-configuration of keys except 315 in a central server. Nevertheless it requires each joining node to 316 be in possession of the AN domain's pledge password, and there is 317 presently no rekeying procedure without rebooting the whole autonomic 318 network. 320 The result is that QUADS provides an autonomic control plane with the 321 above security characteristics. 323 6. IANA Considerations 325 This document makes no request of the IANA. 327 7. Acknowledgements 329 Excellent suggestions were made by TBD 331 8. References 333 8.1. Normative References 335 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 336 "PKCS #1: RSA Cryptography Specifications Version 2.2", 337 RFC 8017, DOI 10.17487/RFC8017, November 2016, 338 . 340 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 341 Kivinen, "Cryptographic Algorithm Implementation 342 Requirements and Usage Guidance for Encapsulating Security 343 Payload (ESP) and Authentication Header (AH)", RFC 8221, 344 DOI 10.17487/RFC8221, October 2017, 345 . 347 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 348 Definition Language (CDDL): A Notational Convention to 349 Express Concise Binary Object Representation (CBOR) and 350 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 351 June 2019, . 353 8.2. Informative References 355 [I-D.carpenter-anima-l2acp-scenarios] 356 Carpenter, B. and B. Liu, "Scenarios and Requirements for 357 Layer 2 Autonomic Control Planes", Work in Progress, 358 Internet-Draft, draft-carpenter-anima-l2acp-scenarios-02, 359 8 April 2020, . 362 [I-D.ietf-anima-autonomic-control-plane] 363 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 364 Control Plane (ACP)", Work in Progress, Internet-Draft, 365 draft-ietf-anima-autonomic-control-plane-25, 23 June 2020, 366 . 369 [I-D.ietf-anima-bootstrapping-keyinfra] 370 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 371 and K. Watsen, "Bootstrapping Remote Secure Key 372 Infrastructures (BRSKI)", Work in Progress, Internet- 373 Draft, draft-ietf-anima-bootstrapping-keyinfra-41, 8 April 374 2020, . 377 [I-D.ietf-anima-grasp] 378 Bormann, C., Carpenter, B., and B. Liu, "A Generic 379 Autonomic Signaling Protocol (GRASP)", Work in Progress, 380 Internet-Draft, draft-ietf-anima-grasp-15, 13 July 2017, 381 . 383 [I-D.ietf-anima-reference-model] 384 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 385 and J. Nobre, "A Reference Model for Autonomic 386 Networking", Work in Progress, Internet-Draft, draft-ietf- 387 anima-reference-model-10, 22 November 2018, 388 . 391 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 392 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 393 October 2013, . 395 Appendix A. Change log [RFC Editor: Please remove] 397 * draft-carpenter-anima-quads-grasp-00, 2019-10-16: 399 - Initial version 401 * draft-carpenter-anima-quads-grasp-01, 2019-10-24: 403 - Added QUADSKI 405 * draft-carpenter-anima-quads-grasp-02, 2019-10-30: 407 - Added crypto details on QUADSKI 409 - Minor corrections and clarifications 411 * draft-carpenter-anima-quads-grasp-03, 2020-06-29: 413 - Added ACP terminology 415 - Updated to xml2rfcv3 417 Author's Address 419 Brian Carpenter 420 The University of Auckland 421 School of Computer Science 422 University of Auckland 423 PB 92019 424 Auckland 1142 425 New Zealand 427 Email: brian.e.carpenter@gmail.com