idnits 2.17.1 draft-zubov-snif-04.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 19 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 (16 February 2022) is 793 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Zubov 3 Internet-Draft VESvault Corp 4 Intended status: Experimental 16 February 2022 5 Expires: 20 August 2022 7 Deploying Publicly Trusted TLS Servers on IoT Devices Using SNI-based 8 End-to-End TLS Forwarding (SNIF) 9 draft-zubov-snif-04 11 Abstract 13 This document proposes a solution, referred as SNIF, that provides 14 the means for any Internet connected device to: 16 * allocate a globally unique anonymous hostname; 18 * obtain and maintain a publicly trusted X.509 certificate issued 19 for the allocated hostname; 21 * accept incoming TLS connections on specific TCP ports of the 22 allocated hostname from any TLS clients that are capable of 23 sending Server Name Indication. 25 The private key associated with the X.509 certificate is securely 26 stored on the TLS terminating device, and is never exposed to any 27 other party at any step of the process. 29 About This Document 31 This note is to be removed before publishing as an RFC. 33 Status information for this document may be found at 34 https://datatracker.ietf.org/doc/draft-zubov-snif. 36 Information can be found at https://snif.host. 38 Source for this draft and an issue tracker can be found at 39 https://github.com/vesvault/snif-i-d. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 20 August 2022. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 76 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. SNIF CA Proxy Protocol . . . . . . . . . . . . . . . . . . . 4 78 3.1. Protocol Variables . . . . . . . . . . . . . . . . . . . 5 79 3.2. Protocol Flow . . . . . . . . . . . . . . . . . . . . . . 5 80 3.3. CN Allocation Request . . . . . . . . . . . . . . . . . . 7 81 3.4. CSR Submission Request . . . . . . . . . . . . . . . . . 7 82 3.5. Certificate Download Request . . . . . . . . . . . . . . 8 83 4. SNIF Relay Protocol Suite . . . . . . . . . . . . . . . . . . 9 84 4.1. SNIF Messages . . . . . . . . . . . . . . . . . . . . . . 9 85 4.2. SNIF Control Connection Protocol . . . . . . . . . . . . 9 86 4.3. SNIF Service Connection Protocol . . . . . . . . . . . . 12 87 4.4. SNIF Client Connection Protocol . . . . . . . . . . . . . 13 88 4.5. SNIF IPC FIFO Protocol . . . . . . . . . . . . . . . . . 14 89 4.6. Abuse Management . . . . . . . . . . . . . . . . . . . . 16 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 94 7.2. Informative References . . . . . . . . . . . . . . . . . 20 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 A typical Internet-of-Things (IoT) device connects to the Internet 100 using a dynamic IP address, and is usually unable to accept incoming 101 connections to TCP ports. A dedicated trusted relay is needed to 102 facilitate the communications between the IoT device and its intended 103 users. While all communications are recommended to be TLS encrypted, 104 the trusted relay will terminate each TLS connection and therefore 105 have access to unencrypted traffic between IoT devices and user 106 clients, which may pose undesirable security risk. 108 Designing a dedicated relay that works in end-to-end encrypted mode, 109 where the TLS tunnel is established between the IoT device and the 110 client, and is passed by the relay in an encrypted form, raises 111 additional challenges. Clients expect to be able to verify the 112 authenticity of the TLS certificate presented by the IoT device they 113 are connecting to. Public certificate authorities requite to 114 validate the ownership of the hostname the certificate is being 115 requested for, using certain challenge mechanisms. Therefore, the 116 IoT device needs to allocate a unique hostname, and to be able to 117 complete the CA challenge in order to acquire a trusted certificate. 119 Alternatively, the client may decide to use a different certificate 120 trust scheme, not based on publicly trusted root CAs. In this case, 121 the client is limited to specifically built software with custom 122 trust rules, or the system trust root on the client device needs to 123 be customized. 125 This document proposes a solution, referred as SNIF, that allows any 126 common TLS client with standard root CAs, such as a web browser, to 127 establish a trusted end-to-end TLS connection with an IoT device 128 using the unique hostname permanently allocated to the device, via a 129 dedicated relay. 131 While this document focuses on IoT devices, SNIF is applicable to any 132 physical or virtual device or software that can benefit from 133 accepting trusted TLS connections to an anonymous hostname. 135 1.1. Notational Conventions 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2. Overview 145 _SNIF CA Proxy_ is a combination of web-based services and background 146 processes that run on a publicly accessible server, normally on the 147 same physical server as SNIF Relay. SNIF CA Proxy allocates 148 hostnames for SNIF Connectors and facilitates issuing and renewing 149 X.509 certificates [RFC5280] without having access to the Connectors' 150 private keys. The functions of SNIF CA Proxy are described in 151 Section 3. 153 _SNIF Relay_ is a process that runs on a publicly accessible server, 154 normally on the same physical server as SNIF CA Proxy. SNIF Relay 155 facilitates end-to-end TLS connections, [RFC8446] or older versions, 156 between SNIF Clients and SNIF Connectors. The functions of SNIF 157 Relay are described in Section 4. 159 _SNIF Connector_ is a software process that runs on an IoT device, or 160 on other type of device that intends to provide TLS-based services 161 that can be accessed by general purpose TLS clients using SNIF Relay. 162 SNIF Connector can be implemented as a standalone process that 163 communicates with the TLS server processes over local filesystem and 164 sockets, or as an integral part of a TLS server process. 166 _SNIF Client_ is any common TLS-compatible client with SNI capability 167 [RFC6066], such as a web browser or an email client, that connects to 168 a SNIF hostname provided by a specific SNIF Connector. SNIF Client 169 does not need any awareness of SNIF, or of any protocols described in 170 this document. 172 _Certificate Authority (CA)_ is a service that issues public trusted 173 TLS Certificates to specific hostnames when requested by the hostname 174 owner, upon validating the ownership of the hostname. CA does not 175 need any awareness of SNIF, except for a working relationship with 176 the SNIF CA Proxy that requests certificates using protocols 177 supported by the CA. 179 _SNIF Peripheral Process_ is any kind of additional service that 180 extends or supplements functions of SNIF, in a way not defined within 181 the scope of this document. 183 3. SNIF CA Proxy Protocol 185 SNIF CA Proxy Protocol is designed for securely acquiring and 186 maintaining a publicly trusted TLS/SSL X.509 certificate issued by a 187 Certificate Authority to a uniquely allocated hostname, by an agent 188 that has no direct control over that hostname, or over a server the 189 hostname is pointing to. 191 SNIF CA Proxy accepts requests from SNIF Connectors via HTTP / HTTPS. 193 SNIF CA Proxy interacts with the CA using protocols supported by the 194 CA, such as ACME [RFC8555], not covered by this document. 196 3.1. Protocol Variables 198 Each SNIF Connector MUST be configured with an initiation URL 199 ({initUrl}), which is specific to the SNIF CA Proxy server the 200 Connector intends to work with. Depending on the CA Proxy rules, 201 {initUrl} might be unique for each Connector, or common for multiple 202 Connectors. 204 The canonical name {cn} is received by a SNIF Connector in response 205 to the CN Allocation Request (Section 3.3), and might be either a 206 single hostname or a wildcard starting with "*.", depending on the CA 207 Proxy rules. 209 {cn_host} is a hostname derived from the {cn} - it is identical to 210 {cn} in case of a single-host CN, or is the {cn} with truncated 211 initial "*." in case of a wildcard CN. Note that {cn_host} is 212 different than the SNIF hostname in case of a wildcard CN. 214 Each SNIF Connector MAY be configured with an API URL base - 215 {apiUrl}. If configured, the {apiUrl} SHOULD be HTTPS. 217 In case if {apiUrl} is not configured - the SNIF Connector MUST 218 derive {apiUrl} from the {cn_host}, upon allocating the CN, as 219 following: 221 {apiUrl} := http://{cn_host}/snif-cert/ 223 3.2. Protocol Flow 225 Upon the initial start or after a hard reset, the Connector SHALL 226 generate a Private Key, which needs to be securely permanently stored 227 by the Connector. Any key algorithm acceptable by the CA can be 228 used, the choice of the algorithm should be made according to the CA 229 guidelines and industry practices. 231 The Connector SHALL send a CN Allocation Request using the {initUrl}. 233 Having the canonical name {cn}, the Connector SHALL generate a CSR 234 [RFC2986] using the Private Key, the subject containing the {cn}. The 235 CSR subject may or may not have other fields besides {cn}, according 236 to the specific requirements of the CA. 238 The Connector SHALL issue a CSR Submission Request to send the CSR to 239 the CA Proxy. 241 Once the CSR is submitted, the Connector MUST permanently store the 242 {cn} by some means - to minimize the storage compartments it might be 243 practical to generate and store a dummy self-signed certificate with 244 the {cn} in the subject until it gets replaced with a trusted 245 certificate issued by the CA. 247 A this point, the Connector will normally know the SNIF hostname it 248 will be using with the SNIF Relay - it matches the {cn} in case of a 249 single host CN, or is a one sub-level down from a wildcard {cn}, the 250 name being derived by the Connector in a way that is not 251 deterministically derivable from the {cn} and the public key, e.g. a 252 hash of the Private Key. 254 The Connector can now send a Certificate Download Request, and MUST 255 verify the returned Certificate. If the Certificate is valid - the 256 Connector MUST permanently store it. 258 If the Certificate Download Request fails - the Connector SHOULD 259 repeat the request after certain delay. In case if the response was 260 401 and the {authUrl} is returned in a header, and the Connector has 261 the means of communicating with the device user - the Connector also 262 SHOULD alert the user and bring {authUrl} to their attention by some 263 means, so the user can complete the required authorization steps. If 264 the Connector has no means of alerting the user, which is often the 265 case with IoT devices - the user MUST be provided with some external 266 means of authorizing with the CA Proxy, not covered by this 267 domcument. 269 Once the Certificate is validated and stored, the Connector is 270 capable of terminating SNIF connections, and may proceed launching a 271 SNIF Control Connection (Section 4.2). The Connector SHOULD 272 communicate its SNIF hostname by some means to the SNIF Clients that 273 will be accessing the Connector. The means of such communication are 274 not covered by this document. 276 The Connector SHOULD watch for the expiration of the stored 277 Certificate. If the Certificate is about to expire in 7 days or 278 less, or has already expired - the Connector SHOULD send a 279 Certificate Download Requests, and repeat with appropriate delays 280 until the renewed Certificate is successfully downloaded and 281 verified. 283 At any stage of the flow, if the Connector receives unexpected volume 284 of rejections or inconsistent responses from the CA Proxy, the 285 Connector MAY decide to hard reset the storage and start the flow 286 over from the beginning. In such case, the Connector will have to 287 re-send its new SNIF hostname to any concerned SNIF Clients, the 288 means of such communication is not covered by this document. 290 3.3. CN Allocation Request 292 Connection from: SNIF Connector 294 Connection to: SNIF CA Proxy 296 Protocol: https or http 298 GET {initUrl} 300 Response 200: Canonical Name (CN) is successfully allocated. The 301 response headers MUST include X-SNIF-CN: with the value of the 302 allocated {cn}, either a wildcard starting with "*.", or a single 303 hostname, depending on the CA Proxy rules. The Relay MUST NOT ever 304 return a CN that's been previously returned by another CN Allocation 305 Request. The Connector SHOULD ignore the response body. 307 Any other response: Error, try again later. 309 3.4. CSR Submission Request 311 Connection from: SNIF Connector 313 Connection to: SNIF CA Proxy 315 Protocol: https or http 317 PUT {apiUrl}{cn_host}.csr 318 Content-Type: application/pkcs10 320 The request body MUST contain a PEM encoded PKCS#10 CSR [RFC5967], 321 the newlines are either or , the length of the body 322 SHOULD NOT exceed 16384 bytes. 324 Note that a CSR for the specific allocated CN can be submitted to the 325 CA Proxy once in a lifetime. In case of an incorrect submission the 326 Connector SHOULD hard reset the storage and restart the flow from the 327 beginning, including allocating a new CN. 329 Response 201: the CSR is successfully submitted. The response 330 headers MAY include X-SNIF-AuthUrl: with the value of an {authUrl}, 331 that SHOULD, if possible, be communicated to the user to authorize 332 the certificate issuance. 334 Response 403: the CSR for this CN has already been submitted, or is 335 denied by the CA Proxy rules. If the Connector receives 403, is 336 SHOULD hard reset the storage and restart the CA Proxy flow from the 337 beginning. 339 Response 404: the CN was not allocated. 341 Any other response: Error, try again later. 343 3.5. Certificate Download Request 345 Connection from: SNIF Connector 347 Connection to: SNIF CA Proxy 349 Protocol: https or http 351 GET {apiUrl}{cn_host}.crt 353 The CA Proxy SHOULD check for a cached previously generated 354 Certificate chain for the {cn}. If the cached Certificate chain is 355 found and if it expires in more that 10 days in the future - the 356 cached Certificate chain SHOULD be returned with status 200. 357 Otherwise, if the {cn} has a valid CSR and a proper authorization to 358 issue a certificate - the CA Proxy SHOULD return status 503 and 359 SHOULD launch a background process that communicates with the CA to 360 issue or renew the certificate, and caches the issued Certificate 361 chain for subsequent Certificate Download Requests. 363 Response 200: the Certificate chain is returned. The Content-Type of 364 such response SHOULD be "application/x-x509-ca-cert". The response 365 body MUST be a PEM encoded X.509 certificate chain, the issued 366 certificate being the first member, the newlines are either 367 or , the length of the body SHOULD NOT exceed 65535 bytes. 369 Response 503: the Certificate is being issued, try later. 371 Response 401: Certificate issuance authorization is required. The 372 response headers MAY include X-SNIF-AuthUrl: with the value of an 373 {authUrl}, that SHOULD, if possible, be communicated to the user to 374 authorize the certificate issuance. If the CA Proxy expects to work 375 with Connectors that cannot communicate with the user, it MUST 376 include external means of the authorization, not covered by this 377 document. 379 Response 404: the CN was not allocated, or the CSR was not submitted. 381 Any other response: Error, try again later. 383 4. SNIF Relay Protocol Suite 385 Except for SNIF Client Connection, all protocols mentioned below 386 involve sending and receiving asynchronous SNIF Messages over a 387 specific type of stream connection. 389 _SNIF Control Connection Protocol_ defines communications between 390 SNIF Relay and SNIF Connector that runs on an IoT device, or other 391 type of device that provides TLS-based services through SNIF. 393 _SNIF Service Connection Protocol_ defines secondary communications 394 between SNIF Relay and SNIF Connector that include end-to-end TLS 395 traffic forwarded by the Relay. 397 _SNIF Client Connection Protocol_ defines TLS communications between 398 SNIF Relay and a Client, where the Relay acts as a transparent end- 399 to-end forwarder. 401 _SNIF IPC FIFO Protocol_ defines communications between nodes of a 402 SNIF Relay cluster, and/or between SNIF Relay and SNIF Peripheral 403 Processes. 405 4.1. SNIF Messages 407 A SNIF Message consists of a 1 or more ASCII characters excluding 408 special characters, terminated by . 410 The total length of a SNIF Message, including the terminal , 411 SHOULD NOT exceed 4096 bytes. 413 8-bit characters are discouraged. If 8-bit characters are used, they 414 SHOULD comply to UTF-8 [RFC3629]. 416 The receiving party SHOULD silently ignore any invalid or malformed 417 SNIF message. 419 4.2. SNIF Control Connection Protocol 421 Protocol name: snif 423 Connection from: SNIF Connector 425 Connection to: SNIF Relay 427 To be able to open a SNIF Control Connection, the SNIF Connector MUST 428 have a valid trusted TLS/SSL certificate, the CN hostname DNS 429 pointing to the SNIF Relay or a wildcard CN having a sub-host DNS 430 pointing to the SNIF Relay, and a Private Key that matches the 431 Certificate. Normally, the SNIF Connector will generate the Private 432 Key and use SNIF CA Proxy Protocol (Section 3) to obtain and maintain 433 the Certificate, although other means can be used. 435 To initiate the Control Connection, the SNIF Connector opens a TCP 436 connection to the hostname matching the Certificate's CN, that points 437 to the Relay. 439 Upon accepting the incoming TCP connection, the SNIF Relay MUST 440 initiate a reversed TLS session as a client peer. If the Relay 441 expects connections from Connectors that have been configured with 442 {apiUrl} (Section 3.1) - it MAY supply a trusted client TLS 443 certificate issued to a host matching such {apiUrl}. 445 The SNIF Connector MUST initiate the TLS as a server peer, using the 446 Certificate and the Private Key. 448 Upon successful TLS negotiation, the SNIF Relay MUST validate the 449 SNIF Connector's certificate. If the certificate is not trusted, the 450 SNIF Relay MUST shut down the TLS session and the TCP socket 451 immediately. 453 If the certificate is accepted, both SNIF Relay and SNIF Connector 454 are ready to accept SNIF Messages from each other over the TLS 455 connection, as following. 457 SNIF LISTEN {hostname} 459 Sent by: SNIF Connector 461 The SNIF LISTEN message informs the Relay that the Connector is ready 462 to accept incoming TLS connections to {hostname} through the Relay. 464 {hostname} MUST specify a single host (no wildcards), and MUST match 465 the CN of the Connector's TLS certificate - either match a wildcard 466 CN, or exactly match a single host CN. 468 The SNIF LISTEN message SHOULD be sent only once per the Control 469 Connection. The Relay SHOULD ignore any invalid or subsequent SNIF 470 LISTEN messages. 472 SNIF CONNECT {conn_id} {dst_host}:{dst_port} {fwd_host}:{fwd_port} {cln_addr}:{cln_port} 474 Sent by: SNIF Relay 476 The SNIF CONNECT message informs the Connector of an incoming TLS 477 connection from a Client to the Connector's {dst_host}, TCP port 478 {dst_port}. 480 {conn_id} is a unique alphanumeric connection identifier assigned by 481 the Relay, {cln_addr}:{cln_port} are the Client's remote IPv4/IPv6 482 address and TCP port, {cln_addr} is supplied in "[" brackets "]". 484 The Relay sends the SNIF CONNECT message to Connectors with 485 {dst_host} matching the {hostname} the Connector is listening to. 486 The Connector doesn't need to verify {dst_host}. 488 If the Connector decides to accept the connection - it MUST launch a 489 SNIF Service Connection to {fwd_host}:{fwd_port}. It also SHOULD send 490 any SNIF message back to the Relay over the Control Connection to 491 update the keep-alive timer, a copy of the SNIF ACCEPT message that 492 is sent over the Service Connection can be used. 494 In case of a rejection - the Connector SHOULD send SNIF CLOSE with 495 matching {conn_id}. 497 SNIF CLOSE {conn_id} 499 Sent by: SNIF Connector 501 The SNIF CLOSE message instructs the Relay to terminate the Client 502 connection with matching {conn_id}. 504 For SNIF CLOSE received from a Connector, the Relay MUST validate 505 that the connection was targeted at the Connector's {hostname}, 506 otherwise ignore the message. 508 SNIF ABUSE {conn_id} {abuse_score} 510 Sent by: SNIF Connector 512 The SNIF ABUSE message instructs the Relay to increase the DoS 513 protection abuse counter for the Client that initiated the connection 514 {conn_id} by {abuse score}. 516 {abuse score} SHOULD be an integer from 1 to 255, 1 is the score for 517 a normal non-abusive connection. 519 For SNIF ABUSE received from a Connector, the Relay MUST validate 520 that the connection was targeted at the Connector's {hostname}, 521 otherwise ignore the message. 523 SNIF MSG {hostname} {content} 525 Sent by: SNIF Connector or SNIF Relay 526 The SNIF MSG message is relayed between the Connector and the SNIF 527 Peripheral Processes attached to the Relay. 529 {content} SHOULD NOT contain whitespaces or special characters. Its 530 semantics is specific to the targeted Peripheral Process, and is not 531 covered by this document. 533 For SNIF MSG received by the Relay from a Connector, the Relay MUST 534 verify that the {hostname} matches the one associated with the 535 Connector, forward the message to all IPC FIFOs if matched, ignore 536 otherwise. 538 For SNIF MSG received by the Relay from an IPC FIFO, the Relay SHOULD 539 forward the message to the Connector(s) with the matching {hostname}, 540 ignore the message if none are found. 542 Note that in certain uncommon circumstances a SNIF MSG send by a 543 Connector might come back to the Connector through a different 544 Control Connection. The Connector SHOULD be aware of this fact to 545 avoid a potential message storm. 547 NOOP 549 Sent by: SNIF Connector or SNIF Relay 551 The NOOP message is not associated with any explicit action, except 552 that the Relay receiving NOOP from the connector SHOULD promply send 553 NOOP or any other message back to the Connector. Therefore, the 554 Connector may use NOOP as a keep-alive ping. 556 4.3. SNIF Service Connection Protocol 558 Protocol name: snif-srv 560 Connection from: SNIF Connector 562 Connection to: SNIF Relay 564 The SNIF Connector opens a TCP connection to the 565 {fwd_host}:{fwd_port} in response to a SNIF CONNECT message received 566 from the Relay over the Control Connection. 568 The Connector MUST immediately send a SNIF ACCEPT message over the 569 Service Connection as a plain TCP: 571 SNIF ACCEPT {conn_id} 573 The {conn_id} is the one that was received in the SNIF CONNECT 574 message over the Control Connection. 576 Upon sending the SNIF ACCEPT message, the Connector MUST immediately 577 assign further control and bi-directional traffic of the SNIF Service 578 Connection to the matching TLS server process. 580 If the Relay decides to reject the connection, either because of 581 invalid message or {conn_id}, or because of reaching the abuse 582 threshold - the Relay SHOULD terminate the TCP connection 583 immediately. 585 Otherwise, the Relay SHOULD link the Service Connection to the 586 matched Client Connection, forward to the Service Connection all 587 buffered TLS data previously received from the Client, and start bi- 588 directional forwarding between the Client Connection and the Service 589 Connection. 591 When either Client or Service Connection is shut down, or an 592 inactivity timeout is reached, the Relay SHOULD shut down both the 593 Client Connection and the Service Connection. 595 Once the Relay has linked the Client Connection matching the 596 {conn_id} to the Service Connection, any further SNIF ACCEPT messages 597 with the same {conn_id} on other Service Connections MUST be 598 rejected. 600 4.4. SNIF Client Connection Protocol 602 Protocol name: snif-cln 604 Connection from: Any TLS enabled software, such as a web browser or 605 an email client 607 Connection to: SNIF Relay 609 From the Client's perspective, a SNIF Client Connection functions as 610 a direct TLS connection to the IoT Device. 612 The ports the Relay is listening to, can be any well-known ports for 613 services with persistent TLS, such as https or imaps, or can be any 614 custom ports agreed among the Relay, the Connectors and the Clients. 616 The Relay accepts an incoming TCP connection, receives and buffers 617 the incoming initial data from the client, and attempts to interpret 618 the received data as a TLS handshake. 620 If the received data is not recognized as a TLS handshake, does not 621 contain an SNI record in a supported format, or the SNI hostname does 622 not meet rules defined for the Relay - the Relay SHOULD immediately 623 reject the TLS session with an appropriate error status, and shut 624 down the Client Connection. 626 If the SNI hostname is found acceptable - the Relay allocates a 627 unique {conn_id}, checks if there are current Control Connections 628 that match the SNI hostname, and sends a SNIF CONNECT message over 629 those connections. 631 If there are no active applicable Control Connections, or if the 632 Relay doesn't receive a response from a SNIF Connector within a 633 specified timeframe - the Relay SHOULD forward the same SNIF CONNECT 634 message over IPC FIFOs (if any are open) to alert cluster peer Relays 635 and Peripheral processes of the incoming Client Connection. 637 A Service Connection with a matching SNIF ACCEPT establishes an end- 638 to-end TLS circuit with the Client Connection. Once established, the 639 Relay bi-directionally forwards all traffic between the Client and 640 the Service Connection until either of the connections is closed or 641 is timed out due to inactivity. 643 Upon receiving a matching SNIF CLOSE - the Relay MUST terminate the 644 Client Connection. If a Service Connection has already been linked 645 it MUST be terminated too, otherwise the Relay SHOULD attempt to 646 gracefully reject TLS on the Client Connection with an appropriate 647 status prior to shutting down TCP. 649 4.5. SNIF IPC FIFO Protocol 651 Protocol name: snif-fifo 653 Connection from: SNIF Relay or SNIF Peripheral Service 655 Connection to: SNIF Relay or SNIF Peripheral Service 657 SNIF IPC FIFO is a permanent trusted connection between the SNIF 658 Relay and a SNIF Peripheral Process, or between a pair of nodes in a 659 SNIF Relay cluster. An IPC FIFO is usually unidirectional, but a 660 bidirectional connection can serve as a pair of FIFOs. An IPC FIFO 661 can be implemented as a Unix FIFO pipe, a TCP socket, an SSH tunnel 662 or by other means. The mechanism of establishing and maintaining IPC 663 FIFOs is implementation specific and is not covered by this document. 665 The following SNIF Messages are defined over an IPC FIFO from the 666 perspective of a SNIF Relay: 668 SNIF CONNECT {conn_id} {dst_host}:{dst_port} {fwd_host}:{fwd_port} {cln_addr}:{cln_port} 670 Direction: Send or Receive 672 (see SNIF Control Connection, Section 4.2). 674 The SNIF CONNECT message is sent by a Relay over an IPC FIFO in case 675 if the Relay failed to reach the respective Connector through Control 676 Connections. SNIF CONNECT sent by a Relay MUST be followed up by one 677 of SNIF CLEAR or SNIF CLOSE to inform the Peripheral Processes of the 678 further outcome. 680 When a SNIF CONNECT message is received by a Relay, the Relay SHOULD 681 forward it to any matching open Control Connections, or ignore it 682 otherwise. 684 SNIF CLEAR {conn_id} 686 Direction: Send 688 The SNIF CLEAR message SHOULD be sent by a Relay only as a followup 689 to SNIF CONNECT with a matching {conn_id}, in case if the Client 690 Connection that triggered SNIF CONNECT was accepted by a Service 691 Connection. 693 The purpose of SNIF CLEAR is to advice Peripheral Processes to cease 694 further attempts of reaching the Connector by external means, not 695 specified within this document. 697 SNIF CLOSE {conn_id} 699 Direction: Send or Receive 701 (see SNIF Control Connection, Section 4.2). 703 The SNIF CLOSE message SHOULD be sent by a Relay only as a followup 704 to SNIF CONNECT with a matching {conn_id}, in case if the Client 705 Connection that triggered SNIF CONNECT was closed without being 706 accepted. 708 When the SNIF CLOSE is received by a Relay, the Relay SHOULD 709 immediately close the matching Client and/or Service Connection if 710 any found, ignore the message otherwise. 712 SNIF ABUSE {conn_id} {abuse_score} 714 Direction: Receive 715 (see SNIF Control Connection, Section 4.2). 717 SNIF MSG {hostname} {content} 719 Direction: Send or Receive 721 (see SNIF Control Connection, Section 4.2). 723 SNIF CTL {ctl_fd} {hostname} {remote_addr}:{remote_port} 724 SNIF CTL {ctl_fd} 726 Direction: Send 728 The SNIF CTL message is sent by a Relay to inform Peripheral 729 Processes about Control Connections. The first version is sent for 730 each opening Control Connection, and is followed up by the second 731 version with the matching {ctl_fd} when the Control Connection is 732 closed. {ctl_fd} is a numeric descriptor which is unique for open 733 connections, but can be reused after a connection is closed. 735 4.6. Abuse Management 737 SNIF Relay SHOULD implement basic protection from denial of service. 738 A separate abuse count SHOULD be assigned to each remote address, 739 incremented by 1 on every incoming connection from the address, 740 incremented by a specified score on every received SNIF ABUSE 741 message, and periodically decremented or reset at regular time 742 intervals. 744 If the abuse counter for a certain remote address reaches a specific 745 threshold, the Relay SHOULD drop any further TCP connections from 746 that address until the abuse counter goes below the threshold. The 747 Relay MAY allow some grace above the threshold to incoming SNIF 748 Service Connections, to minimize stalled Client Connections. 750 SNIF Connector MAY implement basic protection from denial of service 751 by limiting the number of accepted connections per period of time 752 and/or the total number of open connections, and reject connections 753 over the limit. 755 5. Security Considerations 757 Requests to CA Proxy (Section 3) sent over plain unencrypted HTTP, 758 including a PKCS#10 CSR in the CSR Submission Request payload, do not 759 contain senstive information. 761 The response to the CN Allocation Request, if sent over plain HTTP, 762 is a randomly generated hostname or wildcard, that will also be 763 publicly exposed through Certificate Transparency once the 764 Certificate is issued. Any attempt by an intruder to submit an 765 alternate CSR for the issued CN prior to the legitimate Connector, 766 will result in a certificate that doesn't match the Connector's 767 private key, therefore the Connector will need to hard reset and redo 768 the initialization. If the intruder alters the X-SNIF-CN: response 769 sent to the Connector, the CSR submission for a bad CN will be 770 rejected by the CA Proxy, which will also require to hard reset the 771 Connector. 773 The content of the Certificate Download Request response is an X.509 774 certificate which is safe to be exposed to any parties. If the 775 intruder alters the HTTP response to the CSR Submission Request or to 776 the Certificate Download request, the Connector won't receive a valid 777 certificate and will need a hard reset. 779 SNIF Connector SHOULD NOT send its hostname to any parties until it 780 downloads and successfully validates the Certificate from the CA 781 Proxy. 783 To mitigate request flooding potentially resulting in denial of 784 service, it is RECOMMENDED for SNIF CA Proxy to require a Certificate 785 issuance authorization. For SNIF Connectors that have a means of 786 interacting with the user such as a built-in web browser, the CA 787 Proxy SHOULD implement an interactive authorization mechanism not 788 described in this document, and return {authUrl} to the Connector 789 (Section 3.5), and the Connector SHOULD open {authUrl} in the browser 790 for the user to complete the process. 792 For a SNIF CA Proxy that intends to work with devices that have 793 limited capabilities of interacting with their user, some non- 794 interactive Certificate issuance authorization mechanism SHOULD be 795 implemented. As an example of such mechanism, each SNIF Connector 796 can have a unique {initUrl} that MUST be HTTPS to avoid possible 797 interception, and each device is supplied with a unique setup URL 798 presented to the user, the CA Proxy properly mapping each setup URL 799 to the mathing {initUrl}, and using the setup URL to authorize the 800 certificate issuance and to communicate the SNIF Connector's hostname 801 to the user's browser. Such mechanism MUST have a means of alerting 802 the user about misrouted setup, when some other agent other than the 803 legitimate user has used the same setup URL during the device setup 804 process, in such case the user MUST be instructed to immediately hard 805 reset the device and repeat the setup. Such mechanism is RECOMMENDED 806 to use an HTTPS {apiUrl} (Section 3.1); otherwise it MUST provide a 807 means to prevent or detect intercepted setup when an intruder alters 808 a submitted CSR, such as status lights on the device to indicate the 809 completion of SNIF setup. The details of such mechanism are not 810 covered by this document. 812 Since each certificate issued by a CA remains on the certificate 813 transparency public records, it is RECOMMENDED for SNIF CA Proxy to 814 only issue Certificates with a wildcard CN. This way, the actual 815 Connector's hostname (Section 3.2) will not be listed on the public 816 records. 818 SNIF Control Connection Protocol communicates all sensitive 819 information over a TLS connection with a trusted certificate supplied 820 by the SNIF Connector. In high security settings, the SNIF Relay 821 SHOULD provide a trusted client certificate when initiating the 822 Control Connection, and the Connector SHOULD be configured with an 823 HTTPS {apiUrl} (Section 3.1). If the client certificate is not valid 824 for the {apiUrl} - the Connector SHOULD immediately terminate the 825 Control Connection. In case if the Connector doesn't validate a 826 client certificate from the Relay - the Connector MUST NOT send any 827 sensitine information in SNIF MSG messages, and MUST NOT consider any 828 messages received from the Relay to be trusted. 830 SNIF Service Connection Protocol communicates a randomly generated 831 {conn_id} over an unsecure TCP connection. Except if used over a 832 trusted SNIF IPC FIFO, the {conn_id} can be used only once to accept 833 the Client's TLS connection, which in turn can only be successfully 834 negotiated by the targeted SNIF Connector. All further 835 communications are comprised of end-to-end encrypted TLS traffic. 836 The security of the TLS encrypted content between the Client and the 837 Connector is specific to the protocols involved. The underlying 838 protocol SHOULD require proper authentication specific to the 839 protocol before communicating any sensitive information. Negotiation 840 of the credentials for such authentication is not covered by this 841 document. 843 SNIF Client Connection is a TLS session with a trusted certificate. 844 The security of the TLS encrypted content between the Client and the 845 Connector is specific to the protocols involved. 847 SNIF IPC FIFO connections SHOULD only be established between mutually 848 trusted parties, and need to be secured by external means specific to 849 the implementation, such as filesystem permissions, TLS or SSH 850 tunnels etc. The security of such external means cannot be assessed 851 within the scope of this document. 853 A compromised SNIF CA Proxy can potentially issue certificates to any 854 hostnames allocated by the Relay, including a catch-all wildcard, 855 using an alternative private key, and thus allow a man-in-the-middle 856 attack on any SNIF Connectors associated with the Relay. This 857 vulnerability can be mitigated by constant monitoring of public TLS 858 Transparency logs, such as [RFC6962]. At least one independent party 859 SHOULD continuously monitor TLS Transparency logs for each deployed 860 SNIF CA Proxy and Relay. Once any duplicate or overlapping 861 certificates are detected - the corresponding SNIF Relay MUST be 862 permanently deemed compromised. 864 6. IANA Considerations 866 Service Names "snif", "snif-srv", "snif-cln" and "snif-fifo" are 867 registered with IANA. 869 TCP port 7123 is registered with IANA for service "snif". 871 7. References 873 7.1. Normative References 875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 876 Requirement Levels", BCP 14, RFC 2119, 877 DOI 10.17487/RFC2119, March 1997, 878 . 880 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification 881 Request Syntax Specification Version 1.7", RFC 2986, 882 DOI 10.17487/RFC2986, November 2000, 883 . 885 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 886 Housley, R., and W. Polk, "Internet X.509 Public Key 887 Infrastructure Certificate and Certificate Revocation List 888 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 889 . 891 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 892 Extensions: Extension Definitions", RFC 6066, 893 DOI 10.17487/RFC6066, January 2011, 894 . 896 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 897 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 898 May 2017, . 900 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 901 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 902 . 904 7.2. Informative References 906 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 907 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 908 2003, . 910 [RFC5967] Turner, S., "The application/pkcs10 Media Type", RFC 5967, 911 DOI 10.17487/RFC5967, August 2010, 912 . 914 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 915 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 916 . 918 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 919 Kasten, "Automatic Certificate Management Environment 920 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 921 . 923 Author's Address 925 Jim Zubov 926 VESvault Corp 927 Email: jz@vesvault.com 928 URI: https://snif.host