idnits 2.17.1 draft-carpenter-anima-quads-grasp-02.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 (October 30, 2019) is 1640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-carpenter-anima-l2acp-scenarios-01 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-20 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-29 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational October 30, 2019 5 Expires: May 2, 2020 7 Quick and Dirty Security for GRASP 8 draft-carpenter-anima-quads-grasp-02 10 Abstract 12 A secure substrate is required by the Generic Autonomic Signaling 13 Protocol (GRASP) used by Autonomic Service Agents. This document 14 describes QUADS, a QUick And Dirty Security method using symmetric 15 cryptography and preconfigured keys or passwords. It also describes 16 a simplistic QUADS Key Infrastructure based on asymmetric 17 cryptography used over insecure instances of GRASP. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 2, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. QUick And Dirty Security Method . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . . 7 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . 9 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 emulating an ACP 83 immediately above the transport layer, known as QUADS (QUick And 84 Dirty Security) 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 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 141 The recommended frequency of flooding is once per minute with a valid 142 life time of two minutes. By this means, every autonomic node can 143 learn the public key of the server. 145 "411:quadski" is a negotiation objective that is used by an autonomic 146 node that wishes to enrol securely in the AN, i.e. a pledge. In 147 fragmentary CDDL, it is defined as follows: 149 quadski-objective = ["411:quadski", objective-flags, loop-count, value] 150 objective-flags = ; as in the GRASP specification 151 loop-count = ; as in the GRASP specification 152 value = pledge-value / server-value 153 pledge-value = [encrypted-password, pledge-PEM] 154 server-value = encrypted-keys 155 encrypted-password = bytes 156 pledge-PEM = bytes 157 encrypted-keys = bytes 159 The encrypted-password is a previously agreed pledge password for the 160 AN domain, RSA-encrypted using the public key of the server. This 161 password should not be the same as the keying password used in 162 Section 2. 164 The pledge-PEM is the PEM encoding of the public RSA key of the 165 pledge node. 167 The encrypted-keys value is the result of the following process: 169 1. Assume the symmetric cryptography in use is AES/CBC, key length 170 32, initialisation vector length 16, padding PKCS7(128). 172 2. Let the key bytes be 'key' and the initialisation vector bytes be 173 'iv'. 175 3. Construct the array object [key, iv]. 177 4. Encode this object in CBOR. 179 5. Encrypt the resulting CBOR bytes with RSA using the public key of 180 the pledge ("pledge-PEM"). 182 6. The result is the value of "encrypted-keys". 184 The QUADSKI server must have possession of the AN domain keys 185 (Section 2) and the domain's pledge password when it starts up, by a 186 method not specified here. It then proceeds as follows: 188 1. Create an RSA key pair, store the private key, and prepare the 189 PEM encoding of the public key ("server-PEM"). 191 2. Start flooding out the "411:quadskip" objective with the "server- 192 PEM" value, using the GRASP M_FLOOD message. 194 3. Start listening for negotiation requests (GRASP M_NEG_REQ) for 195 the "411:quadski" objective. 197 4. Whenever it receives such a request, RSA-decrypt the "encrypted- 198 password" using its private key. 200 5. If the password matches, recover the pledge's public key from the 201 "pledge-PEM". 203 6. Generate the "encrypted-keys" value as described above, and reply 204 (GRASP M_NEGOTIATE) with that value. 206 7. Normally, the pledge will reply with GRASP M_END and an O_ACCEPT 207 option. 209 Error conditions such as a password mismatch will be handled like any 210 GRASP error condition, with GRASP M_END and an O_DECLINE option. 212 The pledge proceeds as follows: 214 1. Create an RSA key pair, store the private key, and prepare the 215 PEM encoding of the public key ("pledge-PEM"). 217 2. Wait until it detects the flooded "411:quadskip" option, at which 218 point it can recover the QUADSKI server's public key from the 219 "server-PEM" value. 221 3. Request the pledge password from the user. 223 4. RSA-encrypt the password using the server's public key. 225 5. Use GRASP discovery (M_DISCOVER "411:quadski") to locate the 226 QUADSKI server. 228 6. Construct a "411:quadski" objective whose value is [encrypted- 229 password, pledge-PEM] as described above. 231 7. Start the negotiation process (M_NEG_REQ). 233 8. When it receives a successful reply (M_NEGOTIATE), RSA-decrypt 234 the value using its own private key, decode the result from CBOR, 235 and thus recover the QUADS keys [key, iv]. 237 9. Close the GRASP session with M_END + O_ACCEPT. 239 In the pledge and the QUADSKI server, RSA encryption and decryption 240 should follow best current practice, e.g. [RFC8017]. At present the 241 following choices are recommended: public exponent 65537, key size 242 2048, padding OAEP with MGF1, hash SHA256. 244 As noted, this process uses unencrypted GRASP, since there are no 245 QUADS keys available until it ends. Unlike BRSKI 246 [I-D.ietf-anima-bootstrapping-keyinfra], it does not rely on any 247 limitation to link-local traffic, since it is protected by asymmetric 248 cryptography. However, for this to work on an evolving network where 249 nodes may enrol at any time, GRASP must run encrypted for nodes that 250 have acquired QUADS keys and simultaneously unencrypted for the 251 QUADSKI process. The simplest way to achieve this is to run two 252 GRASP instances as necessary. In particular, a node that acts as a 253 GRASP relay needs to be able to relay encrypted traffic (for enrolled 254 nodes) and unencrypted traffic (for nodes needing to run the QUADSKI 255 process). Note that such instances will receive GRASP broadcasts 256 that they cannot interpret (encrypted packets reaching an unencrypted 257 GRASP instance, and vice versa). These packets can be harmlessly 258 discarded. 260 Finally, the reader familiar with BRSKI may note that the QUADSKI 261 server replaces the role of the BRSKI Registrar, and the unencrypted 262 GRASP daemon replaces the role of the BRSKI Join Proxy. 264 4. Implementation Status [RFC Editor: please remove] 266 QUADS for GRASP has been implemented as a small extension to the 267 Python GRASP prototype, using the Python 'cryptography' module. The 268 algorithm choices were: 270 o Encryption: AES/CBC, key lengths 32/16, padding PKCS7(128). 272 o Password hash: PBKDF2HMAC SHA256, length 32, 100000 iterations. 274 o Salt used for keying password hash: 275 0xf474526a2e74accee189f1fbc1c34ceb. 277 QUADSKI for GRASP has been implemented as two Python ASAs, known as 278 'quadski.py' for the server and 'qpledge.py' for the pledge node. 279 These also use the Python 'cryptography' module. 281 RSA parameters: 283 Public Exponent 65537 284 Key Size 2048 286 Padding OAEP with MGF1 288 Hash SHA256 290 The code has been posted to https://github.com/becarpenter/graspy. 292 5. Security Considerations 294 QUADS provides effective secrecy for all GRASP messages, against any 295 party not in possession of the relevant shared keys. However, before 296 a GRASP message is encrypted or after it is decrypted, it is not 297 protected within the host. Therefore, secrecy is only effective 298 against nodes that do not contain a GRASP instance in possession of 299 the keys. Those nodes cannot send valid GRASP messages, and they 300 cannot interpret intercepted GRASP messages, including multicasts. 301 However, they might attempt traffic analysis. 303 QUADS provides authentication of GRASP instances to the extent that 304 they must be in possession of the relevant shared keys. 306 QUADS depends on pre-configuration of keys, or on password entry and 307 a public salt value, for each autonomic node, unless QUADSKI is in 308 use. 310 QUADS offers no defence against denial of service attacks. 312 QUADSKI securely avoids the need for pre-configuration of keys except 313 in a central server. Nevertheless it requires each joining node to 314 be in possession of the AN domain's pledge password, and there is 315 presently no rekeying procedure without rebooting the whole autonomic 316 network. 318 6. IANA Considerations 320 This document makes no request of the IANA. 322 7. Acknowledgements 324 Excellent suggestions were made by TBD 326 8. References 327 8.1. Normative References 329 [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, 330 "PKCS #1: RSA Cryptography Specifications Version 2.2", 331 RFC 8017, DOI 10.17487/RFC8017, November 2016, 332 . 334 [RFC8221] Wouters, P., Migault, D., Mattsson, J., Nir, Y., and T. 335 Kivinen, "Cryptographic Algorithm Implementation 336 Requirements and Usage Guidance for Encapsulating Security 337 Payload (ESP) and Authentication Header (AH)", RFC 8221, 338 DOI 10.17487/RFC8221, October 2017, 339 . 341 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 342 Definition Language (CDDL): A Notational Convention to 343 Express Concise Binary Object Representation (CBOR) and 344 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 345 June 2019, . 347 8.2. Informative References 349 [I-D.carpenter-anima-l2acp-scenarios] 350 Carpenter, B. and B. Liu, "Scenarios and Requirements for 351 Layer 2 Autonomic Control Planes", draft-carpenter-anima- 352 l2acp-scenarios-01 (work in progress), October 2019. 354 [I-D.ietf-anima-autonomic-control-plane] 355 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 356 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 357 plane-20 (work in progress), July 2019. 359 [I-D.ietf-anima-bootstrapping-keyinfra] 360 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 361 and K. Watsen, "Bootstrapping Remote Secure Key 362 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 363 keyinfra-29 (work in progress), October 2019. 365 [I-D.ietf-anima-grasp] 366 Bormann, C., Carpenter, B., and B. Liu, "A Generic 367 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 368 grasp-15 (work in progress), July 2017. 370 [I-D.ietf-anima-reference-model] 371 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 372 and J. Nobre, "A Reference Model for Autonomic 373 Networking", draft-ietf-anima-reference-model-10 (work in 374 progress), November 2018. 376 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 377 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 378 October 2013, . 380 Appendix A. Change log [RFC Editor: Please remove] 382 draft-carpenter-anima-quads-grasp-00, 2019-10-16: 384 Initial version 386 draft-carpenter-anima-quads-grasp-01, 2019-10-24: 388 Added QUADSKI 390 draft-carpenter-anima-quads-grasp-02, 2019-10-30: 392 Added crypto details on QUADSKI 394 Minor corrections and clarifications 396 Author's Address 398 Brian Carpenter 399 The University of Auckland 400 School of Computer Science 401 University of Auckland 402 PB 92019 403 Auckland 1142 404 New Zealand 406 Email: brian.e.carpenter@gmail.com