idnits 2.17.1 draft-warden-appsawg-vnc-scheme-07.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 (November 15, 2015) is 3079 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Applications Area Working Group D. Warden 2 Internet Draft Dell Products LP 3 Intended status: Informational I. Iordanov 4 Expires: May 2016 Undatech 5 November 15, 2015 7 The "vnc" URI Scheme 8 draft-warden-appsawg-vnc-scheme-07.txt 10 Abstract 12 Virtual Network Computing (VNC) software provides remote desktop 13 functionality. This document describes a Uniform Resource 14 Identifier (URI) scheme enabling the launch of VNC clients from 15 other applications. The scheme specifies parameters useful in 16 securely connecting clients with remote hosts. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as 31 reference material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on May 18, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction...................................................2 59 1.1. Requirements Language.....................................3 60 2. The "vnc" URI Scheme...........................................3 61 2.1. URI Scheme Syntax.........................................3 62 2.1.1. URI Parameters.......................................4 63 2.1.2. Data Types...........................................8 64 2.2. Processing URIs..........................................10 65 2.2.1. Error Handling......................................11 66 2.2.2. Connection Profile Matching.........................11 67 2.3. Connection Channel Types.................................12 68 2.3.1. The "Integrated SSH" Channel Type...................12 69 2.3.2. The "Secure Tunnel" Channel Type....................13 70 3. Security Considerations.......................................15 71 3.1. Application Trust........................................15 72 3.2. URI Transmission.........................................16 73 3.3. Host Identification......................................16 74 3.4. Connection Database Integrity............................17 75 4. IANA Considerations...........................................18 76 4.1. "vnc" Scheme.............................................18 77 4.2. Remote Framebuffer Security Types........................18 78 4.3. VNC Connection Channel Types.............................18 79 4.4. VNC ID Hash Algorithms...................................19 80 4.5. VNC URI Parameters.......................................19 81 5. References....................................................20 82 5.1. Normative References.....................................20 83 5.2. Informative References...................................21 84 6. Acknowledgments...............................................22 85 Appendix A. "vnc" URI Template...................................23 87 1. Introduction 89 Virtual Network Computing (VNC) clients are used to support remote 90 desktop connectivity based on the Remote Framebuffer (RFB) Protocol 91 [RFC6143]. It is often desirable to integrate such functionality 92 with other software. However, the lack of a standard method for 93 specifying VNC client parameters has limited such integration. 95 The "vnc" Uniform Resource Identifier (URI) scheme specified in this 96 document facilitates the launch of VNC clients from applications in 97 browser-based, desktop, and mobile environments. Using this scheme, 98 users and application vendors will be able to integrate remote 99 desktop capabilities without being tied to a particular client. 101 Remote desktop clients often store connection profiles in a local 102 connection database. By associating connections specified in a URI 103 with those stored in a database, client-specific options can be 104 automatically applied to a connection launched from another 105 application, even when that application is unaware of those options. 107 Connections to VNC servers are often secured using mechanisms 108 including Transport Layer Security/Secure Sockets Layer (TLS/SSL) 109 tunneling [RFC5246] and Secure Shell (SSH) [RFC4251] tunneling which 110 are outside the scope of the RFB protocol. Defining the behavior of 111 these client-integrated security options enables their use with 112 "vnc" URIs. 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC-2119 [RFC2119]. 120 In this document, these words will appear with that interpretation 121 only when in ALL CAPS. Lower case uses of these words are not to be 122 interpreted as carrying RFC-2119 significance. 124 2. The "vnc" URI Scheme 126 2.1. URI Scheme Syntax 128 The normative syntax of the "vnc" URI is defined in the 129 rule in the following syntax specification. This specification uses 130 the Augmented Backus-Naur Form (BNF) as described in [RFC5234]. The 131 "vnc" URI conforms to the generic URI syntax specified in [RFC3986]. 132 The , , , , and 133 rules are defined in [RFC3986]. 135 vnc-uri = "vnc://" [ userinfo "@" ] [ host [ ":" port ] ] 137 [ "?" [ vnc-params ] ] 139 vnc-params = param "=" value *("&" param "=" value) ["&"] 141 param = 1*( param-char ) 143 value = *( param-char ) 145 param-char = unreserved / pct-encoded / unreserved-symbols 147 unreserved-symbols = ":" / "/" / "@" / "!" / "$" / "'" 149 / "(" / ")" / "*" / "," / ";" 151 The "?", "=", and "&" characters are used to delimit VNC parameters 152 and must be percent-encoded when representing a data octet as 153 specified in [RFC3986]. Within the portion of a "vnc" 154 URI the do not have special meaning and need 155 not be percent-encoded when representing a data octet. 157 A "vnc" URI has the general form: 159 vnc://host:port?param1=value1¶m2=value2... 161 The host information and each parameter value specify information 162 used in establishing or operating the remote desktop session as 163 specified in Section 2.1.1. 165 For example: 167 vnc://10.0.0.1:5901?VncPassword=secret&SecurityType=2 169 Indicates a vnc connection to the host at IP "10.0.0.1" on port 170 "5901" with VNC password "secret" using VNC security. 172 2.1.1. URI Parameters 174 A description of host information and URI parameters is provided in 175 this section. Information on the constraints of various data types 176 is provided in Section 2.1.2. All parameters are considered 177 optional, however a client will not be able to connect without 178 sufficient information. 180 A parameter without a specified default value indicates that no 181 default value is implied by this URI scheme, however VNC clients can 182 apply implementation dependent default behaviors otherwise 183 consistent with this document. 185 The value is deprecated and processed only in an 186 implementation-specific manner. The component MUST NOT 187 be generated in an environment where a client supporting an updated 188 URI format is expected to be available. When processing a URI value 189 from an untrusted source, VNC clients SHOULD alert the user in order 190 to mitigate the risk that the URI is constructed to obscure the 191 identity of the remote host unless the URI can be validated or 192 backwards compatibility considerations make an alert impractical. 194 The and values in the "vnc" URI specify the address of 195 the VNC server on the remote host: 197 +------------+------------+-----------------------------+----------+ 198 | Name | Type | Description | Default | 199 +------------+------------+-----------------------------+----------+ 200 | host | string | VNC server hostname or IP | none | 201 +------------+------------+-----------------------------+----------+ 202 | port | ushort | VNC server port | 5900 | 203 +------------+------------+-----------------------------+----------+ 205 The "vnc" URI parameter values specify remote desktop connection or 206 session properties, including aspects of client operation, 207 usability, and security as specified in the table below: 209 +---------------+---------+-----------------------------+----------+ 210 | Name | Type | Description | Default | 211 +---------------+---------+-----------------------------+----------+ 212 |ConnectionName | string | Name of connection profile | none | 213 +---------------+---------+-----------------------------+----------+ 214 |VncUsername | string | VNC server username | none | 215 +---------------+---------+-----------------------------+----------+ 216 |VncPassword | string | VNC server password | none | 217 +---------------+---------+-----------------------------+----------+ 218 |SecurityType | enum | VNC security type used | none | 219 | | | | | 220 +---------------+---------+-----------------------------+----------+ 221 |ChannelType | enum | Connection channel type | none | 222 | | | | | 223 +---------------+---------+-----------------------------+----------+ 224 |SshHost | string | SSH server hostname or IP | | 225 +---------------+---------+-----------------------------+----------+ 226 |SshPort | ushort | SSH server port | 22 | 227 +---------------+---------+-----------------------------+----------+ 228 |SshUsername | string | SSH username | none | 229 +---------------+---------+-----------------------------+----------+ 230 |SshPassword | string | SSH password | none | 231 +---------------+---------+-----------------------------+----------+ 232 +---------------+---------+-----------------------------+----------+ 233 |IdHashAlgorithm| enum | Hash algorithm used with | none | 234 | | | "IdHash" parameter | | 235 +---------------+---------+-----------------------------+----------+ 236 |IdHash | string | Expected hash of remote | none | 237 | | | public key or certificate | | 238 +---------------+---------+-----------------------------+----------+ 239 |ColorLevel | enum | Client color depth/mode | none | 240 | | | | | 241 +---------------+---------+-----------------------------+----------+ 242 |ViewOnly | boolean | Client is view only | false | 243 +---------------+---------+-----------------------------+----------+ 244 |SaveConnection | boolean | Store connection info | none | 245 +---------------+---------+-----------------------------+----------+ 247 o ConnectionName, SaveConnection 249 The "ConnectionName" is used to identify a connection profile in 250 both the launching application and VNC client. Profiles are 251 applied as described in Section 2.2.2. If omitted, the client 252 MAY generate a name based on the host, port, and/or other 253 parameters. The VNC client MAY normalize the name as required. 255 If true, "SaveConnection" indicates a connection profile should 256 be created or updated and stored in the client connection 257 database. If false, no profile should be updated or persisted. 259 o VncUsername, VncPassword, SecurityType 261 The SecurityType parameter indicates which RFB security type 262 applies to the connection. VNC security types are recorded in 263 the IANA "Remote Framebuffer Security Types" registry created by 264 [RFC6143]. The VNC client will use this information to determine 265 which parameters are required and establish the connection. 267 VNC clients can sometimes automatically negotiate a security type 268 with a server. However, in addition to controlling the security 269 negotiation, specifying the security type also allows for a 270 client to prompt in advance for necessary security parameters. 271 Parameters may take time to enter on mobile clients, and could 272 otherwise result in timeouts and/or security lockouts. If the 273 specified type is not supported by the server, an error SHOULD be 274 indicated as described in Section 2.2.1. 276 The "VncUsername" and "VncPassword" are used when applicable to 277 authenticate to the VNC server using the specified 278 "SecurityType". Since passwords often contain arbitrary 279 characters, they will often require percent encoding. 281 o ChannelType 283 The channel type specifies the transport stream used to carry 284 connection data. This allows a client to initiate a connection 285 using a secure transport protocol such as SSH prior to connecting 286 to the VNC server socket. Use of this value in the context of the 287 "Integrated SSH" and "Secure Tunnel" channel types is provided in 288 Section 2.3. 290 o SshHost, SshPort, SshUsername, SshPassword 292 The SSH parameters are intended for use with the "Integrated SSH" 293 channel type described in Section 2.3.1. These parameters can 294 also be used with any future SSH-based channel types. Since 295 passwords often contain arbitrary characters, they will often 296 require percent encoding. 298 o IdHashAlgorithm, IdHash 300 The "IdHashAlgorithm" and "IdHash" values are used to verify the 301 expected identity of the remote system based on its public key or 302 certificate. Use of these values in the context of the 303 "Integrated SSH" and "Secure Tunnel" channel types is provided in 304 Section 2.3. 306 o ColorLevel 308 The "ColorLevel" parameter specifies the color model to use for 309 data transfer and display as specified in Section 2.1.2. If the 310 requested color model is unsupported, the behavior is 311 implementation dependent. 313 o ViewOnly 315 If true, the VNC client SHOULD operate in a display-only mode and 316 refrain from sending input data including KeyEvent, PointerEvent, 317 and ClientCutText messages specified in Section 7.5 of [RFC6143] 318 unless this mode is unsupported by the client. 320 Parameter names SHOULD be provided in the case specified in this 321 document, however for compatibility clients SHOULD accept parameters 322 in a case-insensitive manner. Values SHALL be interpreted in a case- 323 sensitive manner, unless otherwise noted. 325 Additional parameters likely to be useful with multiple VNC clients 326 can be added to the "VNC URI Parameters" registry as specified in 327 Section 4.5 of this document. Individual clients MAY support 328 parameters specific to that client. VNC Clients supporting 329 application-specific parameters SHOULD include a distinguishing 330 prefix within the parameter name, such as the name of the 331 application package specified in source code except when precluded 332 by compatibility constraints. For example: 334 vnc://?com.dell.vncclient.ScreenMode=2& 336 It can also be expected that clients will maintain backward 337 compatibility with legacy URI formats and parameters. 339 2.1.2. Data Types 341 "vnc" URIs can be percent-encoded as specified in [RFC3986] and MUST 342 be decoded. After decoding, the following type constraints and 343 semantics apply: 345 o string 347 Values of "string" type are UTF-encoded strings as specified in 348 [RFC3629]. 350 The "string" subtype used in the "IdHash" consists of colon- 351 delimited ":" octets displayed in hexadecimal. For example: 353 5D:D2:39:57 355 Comparison of "string" values SHALL be case-insensitive, 356 however the uppercase notation is preferred for readability. 358 o enum 360 The "enum" types consist of specific enumerated subtypes and are 361 represented by their decimal value. 363 The "enum" values represent a VNC security type included 364 in the IANA "Remote Framebuffer Security Types" registry created 365 by [RFC6143]. 367 "enum" values represent connection channel types listed in 368 the "VNC Connection Channel Types" registry created by Section 369 4.3 of this document. Initial values are: 371 Value Description 372 -------- -------------- 373 1 Standard TCP 374 23 Secure Tunnel 375 24 Integrated SSH 377 The Standard TCP channel type represents a generic TCP 378 connection. The Secure Tunnel and Integrated Secure Shell (SSH) 379 [RFC4252] channel types are described in Section 2.3. 381 Values of the "enum" parameter represent secure hash 382 algorithms in the "VNC Hash Algorithms" registry created by 383 Section 4.4 of this document. The initial values include: 385 Value Description 386 -------- ------------ 387 1 MD5 388 2 SHA1 389 4 SHA256 391 The MD5 algorithm is described in [RFC1321]. The SHA1 and SHA256 392 algorithms are described in [SHS]. 394 Values of the "enum" subtype represent a color level. In 395 the table below, the columns have the meaning specified in 396 Section 7.4 of [RFC6143]: 398 BPP = bits-per-pixel 399 TC = true-color-flag 400 RM = red-max 401 GM = green-max 402 BM = blue-max 403 RS = red-shift 404 GS = green-shift 405 BS = blue-shift 407 The values are: 409 Value Description BPP Depth TC RM GM BM RS GS BS 410 ----- --------------- --- ----- -- ---- ---- ---- -- -- -- 411 1 Black and White 8 3 t 1 1 1 2 1 0 412 2 Greyscale 8 6 t 3 3 3 4 2 0 413 3 8 Colors 8 3 t 1 1 1 2 1 0 414 Value Description BPP Depth TC RM GM BM RS GS BS 415 ----- --------------- --- ----- -- ---- ---- ---- -- -- -- 416 4 64 Colors 8 6 t 3 3 3 4 2 0 417 5 256 Colors 8 8 t 7 7 3 0 3 6 418 6 16-bit Color 16 16 t 31 63 31 11 5 0 419 7 24-bit Color 32 24 t 255 255 255 16 8 0 420 8 30-bit Color 32 30 t 1023 1023 1023 0 10 20 422 A value of "t" indicates the true-color-flag should be set. The 423 big-endian-flag should be set as required for the system. 425 o ushort 427 The "ushort" values represent unsigned 16-bit integers expressed 428 in decimal digits with value between 0-65535 inclusive. 430 o boolean 432 "boolean" values represent conditions that are true or false and 433 are represented as either "true" or "false" respectively. For 434 maximum compatibility, clients SHOULD accept the value 1 as 435 representing true values and 0 as representing false values. 436 Clients SHOULD perform parsing of "boolean" values in a case- 437 insensitive manner. 439 An example "vnc" URI including several of these data types is: 441 vnc://localhost:5900?ConnectionName=Server&SecurityType=2& 442 IdHash=0D:3A:72:08:57:EA:4D:30&SaveConnection=false& 444 Note the above example should be considered to be a contiguous 445 string without line breaks or whitespace and is broken into multiple 446 lines in this document for readability. 448 2.2. Processing URIs 450 Conceptually, a VNC URI supports only a "VIEW" operation, indicating 451 the user wishes to view the remote desktop accessible via the URI 452 reference. 454 In general, when a VNC client receives a "vnc" URI it will initiate 455 an RFB protocol remote desktop connection using the specified host 456 information and parameter values. Initiating the connection using a 457 connection channel mechanism such as those specified in Section 2.3 458 might require processing prior to establishing the RFB connection. 459 A client MAY attempt to automatically discover or negotiate 460 appropriate connection channel, security, or other parameter values. 462 The process for negotiating security types is specified in 463 [RFC6143]. Supported connection channels could be discovered by 464 testing channel types to detect when a channel is successfully 465 established. To best integrate with other applications the VNC 466 client SHOULD initiate the connection with minimal or no user 467 intervention, whenever sufficient information is available and 468 adequate security is preserved. 470 Host information and parameter values may be provided through 471 connection profiles. When a parameter value is not available from 472 either a URI or a connection profile described in Section 2.2.2, the 473 default value specified in Section 2.1.1 SHOULD be applied. If 474 available parameters are not sufficient to establish a connection, 475 the VNC client SHOULD present a session initiation data-entry 476 screen. 478 2.2.1. Error Handling 480 In a typical interactive environment, if an error prevents a session 481 from being established, the VNC client presents an error message to 482 the user. When the message is acknowledged, the console application 483 can show a session initiation data-entry screen populated with 484 available session parameters or it can terminate. If an error 485 occurs after a session is successfully established that terminates 486 the connection, the VNC client presents a termination notification 487 to the user. When the termination notification is acknowledged, the 488 client can present a reconnection prompt or terminate. 490 When an error occurs in a dedicated environment (such as a kiosk 491 system), the system can transmit an alert to the remote operator, 492 record a log entry, and execute appropriate fallback behavior such 493 as automatically attempting to reestablish a session or displaying a 494 generic message requesting servicing. 496 2.2.2. Connection Profile Matching 498 VNC clients MAY store remote desktop session settings in connection 499 profiles. If the client is able to uniquely identify and associate 500 a connection request with a connection profile based on the 501 "ConnectionName" parameter value, remote host IP address, or 502 hostname/fully-qualified domain name, the VNC client SHOULD apply 503 profile values for those settings which do not have values supplied 504 in the "vnc" URI. When profile data is unavailable, the VNC client 505 MAY apply global application defaults for settings not supplied in 506 the URI and for which the scheme does not specify a default value. 507 The VNC client MUST NOT override supplied parameters with profile 508 values or global defaults. 510 When the "SaveConnection" parameter value is true, within the VNC 511 client a connection profile SHOULD be created or updated with the 512 values supplied in the "vnc" URI. Profile updates and storage 513 should be consistent with the recommendations in Section 3.4. 515 2.3. Connection Channel Types 517 2.3.1. The "Integrated SSH" Channel Type 519 The "Integrated SSH" channel type establishes an SSH connection to a 520 host, authenticates with SSH password authentication, establishes a 521 secure tunnel to the VNC host/port, and then connects to the VNC 522 server using a supported "SecurityType". The secure tunnel will 523 provide encryption and data integrity, while verifying the public 524 key authenticates the server. The SSH architecture is specified in 525 [RFC4251]. The steps are detailed below: 527 1. The VNC client initiates a transport-level connection to the 528 "SshHost" on the "SshPort" specified in the parameter values with 529 a key exchange as described in [RFC4253]. 531 2. When the VNC client receives the server key (or certificate), the 532 hash of the key (or certificate) is computed using the algorithm 533 corresponding to the "IdHashAlgorithm" parameter value and 534 compared with the expected "IdHash" value (if available). If the 535 certificate hash cannot be verified, the client alerts the user 536 or operator. In a typical interactive environment, the alert 537 provides the remote system's identifying information including 538 the hash value and allows the user to terminate the connection. 539 The alert could allow the user to accept the key and continue 540 establishing the connection. In a dedicated environment (such as 541 a kiosk system), the system can transmit an alert to the remote 542 operator, record a log entry, and execute appropriate fallback 543 behavior such as displaying a generic message requesting 544 servicing. 546 3. The SSH client authenticates the user using the "SshUsername" and 547 "SshPassword" parameter values according to the "password" 548 authentication mechanism described in [RFC4252]. 550 4. The SSH client opens a TCP/IP channel as specified in [RFC4254] 551 from the local system to the system indicated by the and 552 information values. 554 5. The VNC client establishes a RFB connection to the VNC server 555 over the channel and authenticates using the "SecurityType" as 556 described in [RFC6143] or other reference. 558 The VNC client MAY establish the connection described in this 559 section using an external SSH client, by launching the client and 560 then connecting to a secure tunnel created between a local port and 561 the VNC server. 563 If the VNC client is supplied with additional parameters outside the 564 scope of this document, it MAY perform a variation of these steps 565 consistent with the underlying protocols, for example by using 566 "publickey" SSH client authentication [RFC4252] or providing another 567 form of authentication to the VNC server. The specific negotiation 568 of SSH parameters such as cipher suite configuration is outside the 569 scope of this document. 571 Many SSH clients present key hashes using MD5 and it can be expected 572 that launching applications will specify the hash be displayed in 573 the manner its users are familiar with. 575 For compatibility, when the "SecurityType" parameter value is 576 "Integrated SSH" (24), a VNC client MUST treat the value as a 577 request to use "Integrated SSH" as the "ChannelType". However, this 578 value SHOULD NOT be supplied for the "SecurityType" parameter unless 579 required for backward compatibility as the channel is established 580 prior to connecting to the server and is not consistent with the 581 negotiation of other security types. 583 2.3.2. The "Secure Tunnel" Channel Type 585 The "Secure Tunnel" channel type establishes a TLS connection with a 586 remote server using certificate authentication, over which a 587 connection to the VNC server is established using a supported 588 "SecurityType". The secure tunnel will provide encryption and data 589 integrity, while verifying the certificate authenticates the server. 590 The TLS protocol is specified in [RFC5246]. The steps are detailed 591 below: 593 1. The VNC client initiates the TLS Handshake Protocol with a system 594 indicated by the and information values. 596 2. When the server certificate is received, the hash of the key 597 certificate is computed using the algorithm corresponding to the 598 "IdHashAlgorithm" parameter value and compared with the expected 599 "IdHash" value (if available). If the certificate hash cannot be 600 verified, the client alerts the user or operator. In a typical 601 interactive environment, the alert provides the remote system's 602 identifying information and allows the user to terminate the 603 connection. The alert could allow the user to accept the key and 604 continue establishing the connection. In a dedicated environment 605 (such as a kiosk system), the system can transmit an alert to the 606 remote operator, record a log entry, and execute appropriate 607 fallback behavior such as displaying a generic message requesting 608 servicing. 610 When providing identifying information of a host identified by an 611 X509 certificate [RFC5280], the certificate subject, issuer, 612 validity period, and certificate hash is typically included. The 613 VNC client MAY verify the validity of the certificate. If the 614 validity of a certificate is not confirmed, the alert includes a 615 statement indicating such information has not been verified. 617 3. The client finishes establishing the TLS tunnel. 619 4. The VNC client establishes a RFB connection to the VNC server 620 over the channel and authenticates using the "SecurityType" as 621 described in [RFC6143] or other reference. 623 If the VNC client is supplied with additional parameters, it MAY 624 perform a variation of these steps consistent with the underlying 625 protocols, for example by providing another form of authentication 626 to the VNC server. The negotiation of specific TLS parameters such 627 as cipher suite configuration is outside the scope of this document. 629 The TLS protocol provides backwards compatibility with SSLv3, 630 however due to known security flaws it SHOULD NOT be used. 632 For compatibility, when the "SecurityType" parameter value is 633 "Secure Tunnel" (23) a VNC client MUST treat the value as a request 634 to use "Secure Tunnel" as the "ChannelType". However, this value 635 SHOULD NOT be supplied for the "SecurityType" parameter unless 636 required for backward compatibility as the channel must be 637 established prior to connecting to the server and is not consistent 638 with the negotiation of other security types. 640 3. Security Considerations 642 General security concerns involving URI schemes are discussed in 643 [RFC3986]. In implementing support for the "vnc" URI scheme, areas 644 for particular consideration include application trust, URI 645 transmission, host identification, and connection database security. 647 Remote desktop connectivity requires the transmission of security 648 credentials, which could be included in a URI. If those credentials 649 are not kept secure, an attacker can gain access to any systems 650 using those credentials. Host addresses and connection parameters 651 might also be considered sensitive, as such information can be used 652 in planning an attack. 654 URIs can also contain host identification information. It is 655 important to securely identify the remote host system to which a 656 connection is established. If a user connects to an attacker's 657 system, user data, including credentials, can be exposed. 659 Note that the RFB protocol itself does not encrypt data. To protect 660 data in transit, RFB should be tunneled over TLS [RFC5246], SSH 661 [RFC4251], or another secure protocol. 663 Some VNC systems can be used without authentication. To protect the 664 remote host, strong passwords or other authentication mechanisms 665 need to be used. 667 3.1. Application Trust 669 A malicious application receiving VNC credentials via URI or other 670 means can obviously misuse those credentials. To protect against 671 this, users should only install applications from trusted sources. 672 The integrity of application packages can be verified through 673 digital signatures. 675 Applications launching VNC clients can elect to launch only 676 particular trusted clients, and can specify those clients through 677 platform-specific mechanisms. Package integrity can be verified 678 programmatically by querying the package manager for digital 679 signatures or other platform-specific means. 681 The risk to a VNC client from a launching application is generally 682 much lower, since the launching application will not receive 683 credentials or data from the client. A VNC client can verify its 684 caller thorough platform-specific means. 686 VNC clients ought not to accept potentially destructive parameters 687 from untrusted launching applications without explicit user 688 confirmation. For example, a client-specific parameter that runs an 689 arbitrary command upon establishing a SSH connection used for VNC 690 tunneling is potentially destructive and high risk. 692 3.2. URI Transmission 694 Within a mobile or desktop environment, application launch will 695 typically involve in-memory URI data transmission facilitated and 696 secured by the operating system. 698 If sensitive URI information is exchanged across a network, for 699 example by providing a list of connection URIs in a web page, the 700 data needs to be encrypted in transit and only be accessible to 701 authorized users. 703 When an application detects potentially sensitive information in a 704 VNC URI, it needs to be handled securely or discarded. In 705 particular, the URI data that is persisted needs to be encrypted as 706 described in Section 3.4. 708 Applications that process URIs in a generic way, such as web 709 browsers, might not detect that sensitive information is contained 710 in a URI and could cache or store that information insecurely. It 711 is advisable to avoid including credentials and other sensitive 712 information in URIs that are likely to be processed in a generic way 713 unless such caching and storage is disabled or otherwise secured. 715 3.3. Host Identification 717 In the absence of verifiable host identification, a VNC client 718 application is vulnerable to spoofing and man-in-the-middle attacks 719 that capture VNC or host OS credentials and user data. To prevent 720 such attacks, administrators SHOULD secure their VNC communications 721 with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection 722 mechanisms identifying remote hosts via certificate or public key. 723 VNC clients MUST verify the respective certificates or public keys 724 to confirm the remote host's identity. 726 An application launching a VNC client via URI MAY provide a 727 certificate hash or public key hash identifying the remote host. 728 VNC clients maintaining a connection database can also store 729 certificate or public key data suitable for validating a host's 730 identity. 732 If connecting to a system identified by certificate or public key 733 and a remote system ID hash cannot be matched to available 734 identifying data, the VNC client needs to alert the user or 735 operator. In a typical interactive environment, the alert will 736 provide the remote system's identifying information and allow the 737 user to terminate the connection. The alert can allow the user to 738 accept the information and continue establishing the connection. In 739 a dedicated environment (such as a kiosk system), the system can 740 transmit an alert to the remote operator, record a log entry, and 741 execute appropriate fallback behavior such as displaying a generic 742 message requesting servicing. 744 When providing identifying information of a host identified by an 745 X509 certificate [RFC5280], the certificate subject, issuer, 746 validity period, and certificate hash needs to be included. The VNC 747 client can verify the certificate validity. If the validity of a 748 certificate is not determined, the alert needs to include a 749 statement indicating such information has not been verified. 751 Identifying information of a host identified by public key, such as 752 the endpoint of an SSH connection using a raw key, needs to include 753 a hash of the key. 755 3.4. Connection Database Integrity 757 A VNC client application and/or launching application can maintain a 758 connection database containing remote host information, credentials, 759 and/or connection parameters. Applications storing credentials need 760 to ensure they are stored in an encrypted format with a decryption 761 process requiring user-supplied or device-specific data. If 762 supported, it is advisable for applications to have a setting 763 disabling storage of credentials. 765 If available, the VNC client connection database can store 766 certificate or public key data used to verify host identification. 767 To prevent a malicious URI from overriding the database, if 768 identification information in the URI conflicts with information in 769 the database, the user or operator needs to be alerted. In a 770 typical interactive environment, the user can be prompted to accept 771 the new information prior to updating the database. 773 4. IANA Considerations 775 The "vnc" scheme should be registered in the URI schemes registry. 777 IANA "Remote Framebuffer Security Types", "VNC Connection Channel 778 Types", "VNC ID Hash Algorithms", and "VNC URI Parameters" 779 registries will support elements of the scheme. 781 4.1. "vnc" Scheme 783 IANA is asked to add the "vnc" scheme to the "Uniform Resource 784 Identifier (URI) Schemes" registry with description "Remote 785 Framebuffer Protocol" and reference to this document. A 786 registration template is provided in Appendix A. 788 The IANA schemes registry is currently located at: 790 http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 792 4.2. Remote Framebuffer Security Types 794 This document references the existing IANA "Remote Framebuffer 795 Security Types" registry in specifying security type options. IANA 796 is asked to update the "Secure Tunnel" and "Integrated SSH" security 797 types to refer to this document. 799 Future RFB security types will be supported in "vnc" URIs. Any new 800 security mechanism integrated with a VNC client which alters the 801 process by which a connection is established should also be 802 reflected in the registry to avoid overlapping numeric assignments. 804 This applies even if the mechanism does not involve a change to the 805 VNC server implementation or RFB protocol itself. For example, the 806 "Secure Tunnel" security type does not require RFB modification, but 807 indicates to the client that it must establish a TLS tunnel prior to 808 initiating RFB communications. Without inclusion in the registry, a 809 URI-launched client will be unable to distinguish future client- 810 initiated and protocol-based security mechanisms. 812 4.3. VNC Connection Channel Types 814 IANA is asked to create a "VNC Connection Channel Types" registry 815 within the "Remote Framebuffer (RFB)" group. The registry should 816 include Value, Description, and Reference columns. The initial 817 contents of the registry are described in this document. The values 818 of the "Secure Tunnel" and "Integrated SSH" types are copied from 819 the RFB Security Types registry. They should be: 821 Value Description Reference 822 -------- --------------- --------------- 823 1 Standard TCP (this document) 824 23 Secure Tunnel (this document) 825 24 Integrated SSH (this document) 827 Future assignments to this registry should be made through the 828 "Expert Review" process described in [RFC5226]. Experts reviewing 829 VNC Connection Channel Types should verify the proposed channel type 830 description is clear, and the channel type does not conflict with 831 existing channel types that are registered or in widespread use. 833 4.4. VNC ID Hash Algorithms 835 IANA is asked to create a "VNC ID Hash Algorithms" registry within 836 the "Remote Framebuffer (RFB)" group. The registry should include 837 Value, Description, and Reference columns. 839 The initial hash algorithms specified are a subset of the algorithms 840 contained in the "TLS HashAlgorithm Registry". The initial contents 841 of the registry should be: 843 Value Description Reference 844 -------- ------------ --------------- 845 1 MD5 (this document) 846 2 SHA1 (this document) 847 4 SHA256 (this document) 849 Future assignments to this registry should be made through the 850 "Expert Review" process described in [RFC5226]. Experts reviewing 851 VNC ID Hash Algorithms should verify the proposed parameter 852 description is clear, and the parameter does not conflict with 853 existing parameters that are registered or in widespread use. 855 4.5. VNC URI Parameters 857 IANA is asked to create a "VNC URI Parameters" registry within the 858 "Remote Framebuffer (RFB)" group. 860 The initial contents are described in this document. They should be: 862 +-----------------+-----------------------------+-----------------+ 863 | Name | Description | Reference | 864 +-----------------+-----------------------------+-----------------+ 865 | ConnectionName | Name of connection profile | (this document) | 866 +-----------------+-----------------------------+-----------------+ 867 +-----------------+-----------------------------+-----------------+ 868 | VncUsername | VNC server username | (this document) | 869 +-----------------+-----------------------------+-----------------+ 870 | VncPassword | VNC server password | (this document) | 871 +-----------------+-----------------------------+-----------------+ 872 | SecurityType | VNC security type used | (this document) | 873 +-----------------+-----------------------------+-----------------+ 874 | ChannelType | Connection channel type | (this document) | 875 +-----------------+-----------------------------+-----------------+ 876 | SshHost | SSH server hostname or IP | (this document) | 877 +-----------------+-----------------------------+-----------------+ 878 | SshPort | SSH server port | (this document) | 879 +-----------------+-----------------------------+-----------------+ 880 | SshUsername | SSH username | (this document) | 881 +-----------------+-----------------------------+-----------------+ 882 | SshPassword | SSH password | (this document) | 883 +-----------------+-----------------------------+-----------------+ 884 | IdHashAlgorithm | Hash algorithm used with | (this document) | 885 | | "IdHash" parameter | | 886 +-----------------+-----------------------------+-----------------+ 887 | IdHash | Expected hash of remote | (this document) | 888 | | public key or certificate | | 889 +-----------------+-----------------------------+-----------------+ 890 | ColorLevel | Client color depth/mode | (this document) | 891 +-----------------+-----------------------------+-----------------+ 892 | ViewOnly | Client is view only | (this document) | 893 +-----------------+-----------------------------+-----------------+ 894 | SaveConnection | Store connection info | (this document) | 895 +-----------------+-----------------------------+-----------------+ 897 Future assignments to these registries should be made through the 898 "Expert Review" process described in [RFC5226]. Experts reviewing 899 VNC URI parameters should verify the proposed parameter name and 900 description are clear, and the parameter does not conflict with 901 existing parameters that are registered or in widespread use. 903 5. References 905 5.1. Normative References 907 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 908 April 1992. 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, March 1997. 913 [RFC3629] Yergeau, F., "UTF-8, a transformation format of 914 ISO 10646", STD 63, RFC 3629, November 2003. 916 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 917 Resource Identifier (URI): Generic Syntax", STD 66, RFC 918 3986, January 2005. 920 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 921 Protocol Architecture", RFC 4251, January 2006. 923 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 924 Authentication Protocol", RFC 4252, January 2006. 926 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 927 Transport Layer Protocol", RFC 4253, January 2006. 929 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 930 Connection Protocol", RFC 4254, January 2006. 932 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 933 Syntax Specifications: ABNF", STD 68, RFC 5234, January 934 2008. 936 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 937 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 939 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 940 Housley, R., and W. Polk, "Internet x.509 Public Key 941 Infrastructure Certificate and Certificate Revocation List 942 (CRL) Profile", RFC 5280, May 2008. 944 [RFC6143] Richardson, T., and J. Levine, "The Remote Framebuffer 945 Protocol", RFC 6143, March 2011. 947 [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National 948 Institute of Standards and Technology, U.S. Department of 949 Commerce, August 2002. 951 5.2. Informative References 953 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 954 and Registration Procedures for URI Schemes", BCP 35, RFC 955 7595, June 2015. 957 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 958 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 959 May 2008. 961 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 962 Information technology - Open Systems Interconnection - 963 The Directory: Public-key and attribute certificate 964 frameworks. 966 6. Acknowledgments 968 Dominic Parkes and the staff of RealVNC Ltd. graciously reviewed 969 this document and provided constructive comments. 971 RFB and VNC are registered trademarks of RealVNC Ltd. in the U.S. 972 and in other countries. 974 This document was prepared using 2-Word-v2.0.template.dot. 976 Appendix A. "vnc" URI Template 978 This template is provided for registration of the VNC URI in the 979 IANA URI schemes registry as specified in [RFC7595]. 981 URI Scheme name: vnc 983 Status: Permanent 985 URI scheme syntax: See Section 2 of this document. 987 Scheme semantics: See Section 2 of this document. 989 Encoding considerations: See Section 2 of this document. 991 Applications/protocols that use this URI scheme name: Virtual 992 Network Computing (VNC) remote desktop applications use vnc URIs. 993 VNC applications use the Remote Framebuffer (RFB) protocol. 995 Interoperability considerations: Legacy software applications 996 respond to vnc URIs in different ways and may fail to behave as 997 expected. It is advisable to test vnc URIs with specific 998 applications or consult application-specific documentation. 1000 Security considerations: See Section 3 of this document. 1002 Contact: IESG . 1004 Author/Change Controller: See the Authors of this document. Change 1005 control is through the IESG on behalf of the IETF . 1007 References: This document. 1009 Authors' Addresses 1011 David Warden 1012 Dell Products LP 1013 200 Dell Way 1014 Round Rock, Texas 78682 1015 U.S.A. 1017 Phone: 512-728-0380 1018 Email: David_Warden@dell.com 1019 URI: http://www.dell.com 1021 Iordan Iordanov 1022 Undatech 1023 260 Scarlet Road, Apt. 503 1024 Toronto, ON M6N 4X6 1025 CANADA 1027 Email: iiordanov@gmail.com