idnits 2.17.1 draft-warden-appsawg-vnc-scheme-06.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 13, 2015) is 3058 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 13, 2015 7 The "vnc" URI Scheme 8 draft-warden-appsawg-vnc-scheme-06.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 16, 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.......................................14 71 3.1. Application Trust........................................15 72 3.2. URI Transmission.........................................15 73 3.3. Host Identification......................................16 74 3.4. Connection Database Integrity............................16 75 4. IANA Considerations...........................................17 76 4.1. "vnc" Scheme.............................................17 77 4.2. Remote Framebuffer Security Types........................17 78 4.3. VNC Connection Channel Types.............................18 79 4.4. VNC ID Hash Algorithms...................................18 80 4.5. VNC URI Parameters.......................................18 81 5. References....................................................20 82 5.1. Normative References.....................................20 83 5.2. Informative References...................................21 84 6. Acknowledgments...............................................21 85 Appendix A. "vnc" URI Template...................................22 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 If an error prevents a session from being established, the VNC 481 client presents an error message to the user. When the message is 482 acknowledged, the console application can show a session initiation 483 data-entry screen populated with available session parameters or it 484 can terminate. If an error occurs after a session is successfully 485 established that terminates the connection, the VNC client presents 486 a termination notification to the user. When the termination 487 notification is acknowledged, the client can present a reconnection 488 prompt or terminate. 490 2.2.2. Connection Profile Matching 492 VNC clients MAY store remote desktop session settings in connection 493 profiles. If the client is able to uniquely identify and associate 494 a connection request with a connection profile based on the 495 "ConnectionName" parameter value, remote host IP address, or 496 hostname/fully-qualified domain name, the VNC client SHOULD apply 497 profile values for those settings which do not have values supplied 498 in the "vnc" URI. When profile data is unavailable, the VNC client 499 MAY apply global application defaults for settings not supplied in 500 the URI and for which the scheme does not specify a default value. 501 The VNC client MUST NOT override supplied parameters with profile 502 values or global defaults. 504 When the "SaveConnection" parameter value is true, within the VNC 505 client a connection profile SHOULD be created or updated with the 506 values supplied in the "vnc" URI. Profile updates and storage 507 should be consistent with the recommendations in Section 3.4. 509 2.3. Connection Channel Types 511 2.3.1. The "Integrated SSH" Channel Type 513 The "Integrated SSH" channel type establishes an SSH connection to a 514 host, authenticates with SSH password authentication, establishes a 515 secure tunnel to the VNC host/port, and then connects to the VNC 516 server using a supported "SecurityType". The secure tunnel will 517 provide encryption and data integrity, while verifying the public 518 key authenticates the server. The SSH architecture is specified in 519 [RFC4251]. The steps are detailed below: 521 1. The VNC client initiates a transport-level connection to the 522 "SshHost" on the "SshPort" specified in the parameter values with 523 a key exchange as described in [RFC4253]. 525 2. When the VNC client receives the server key (or certificate), the 526 hash of the key (or certificate) is computed using the algorithm 527 corresponding to the "IdHashAlgorithm" parameter value and 528 compared with the expected "IdHash" value (if available). If the 529 certificate hash cannot be verified, the client alerts the user. 530 The alert provides the remote system's identifying information 531 including the hash value and allow the user to terminate the 532 connection. The alert could allow the user to accept the key and 533 continue establishing the connection. 535 3. The SSH client authenticates the user using the "SshUsername" and 536 "SshPassword" parameter values according to the "password" 537 authentication mechanism described in [RFC4252]. 539 4. The SSH client opens a TCP/IP channel as specified in [RFC4254] 540 from the local system to the system indicated by the and 541 information values. 543 5. The VNC client establishes a RFB connection to the VNC server 544 over the channel and authenticates using the "SecurityType" as 545 described in [RFC6143] or other reference. 547 The VNC client MAY establish the connection described in this 548 section using an external SSH client, by launching the client and 549 then connecting to a secure tunnel created between a local port and 550 the VNC server. 552 If the VNC client is supplied with additional parameters outside the 553 scope of this document, it MAY perform a variation of these steps 554 consistent with the underlying protocols, for example by using 555 "publickey" SSH client authentication [RFC4252] or providing another 556 form of authentication to the VNC server. The specific negotiation 557 of SSH parameters such as cipher suite configuration is outside the 558 scope of this document. 560 Many SSH clients present key hashes using MD5 and it can be expected 561 that launching applications will specify the hash be displayed in 562 the manner its users are familiar with. 564 For compatibility, when the "SecurityType" parameter value is 565 "Integrated SSH" (24), a VNC client MUST treat the value as a 566 request to use "Integrated SSH" as the "ChannelType". However, this 567 value SHOULD NOT be supplied for the "SecurityType" parameter unless 568 required for backward compatibility as the channel is established 569 prior to connecting to the server and is not consistent with the 570 negotiation of other security types. 572 2.3.2. The "Secure Tunnel" Channel Type 574 The "Secure Tunnel" channel type establishes a TLS connection with a 575 remote server using certificate authentication, over which a 576 connection to the VNC server is established using a supported 577 "SecurityType". The secure tunnel will provide encryption and data 578 integrity, while verifying the certificate authenticates the server. 579 The TLS protocol is specified in [RFC5246]. The steps are detailed 580 below: 582 1. The VNC client initiates the TLS Handshake Protocol with a system 583 indicated by the and information values. 585 2. When the server certificate is received, the hash of the key 586 certificate is computed using the algorithm corresponding to the 587 "IdHashAlgorithm" parameter value and compared with the expected 588 "IdHash" value (if available). If the certificate hash cannot be 589 verified, the client alerts the user. The alert provides the 590 remote system's identifying information and allows the user to 591 terminate the connection. The alert could allow the user to 592 accept the key and continue establishing the connection. 594 When providing identifying information of a host identified by an 595 X509 certificate [RFC5280], the certificate subject, issuer, 596 validity period, and certificate hash is typically included. The 597 VNC client MAY verify the validity of the certificate. If the 598 validity of a certificate is not confirmed, the console 599 application includes a statement indicating such information has 600 not been verified. 602 3. The client finishes establishing the TLS tunnel. 604 4. The VNC client establishes a RFB connection to the VNC server 605 over the channel and authenticates using the "SecurityType" as 606 described in [RFC6143] or other reference. 608 If the VNC client is supplied with additional parameters, it MAY 609 perform a variation of these steps consistent with the underlying 610 protocols, for example by providing another form of authentication 611 to the VNC server. The negotiation of specific TLS parameters such 612 as cipher suite configuration is outside the scope of this document. 614 The TLS protocol provides backwards compatibility with SSLv3, 615 however due to known security flaws it SHOULD NOT be used. 617 For compatibility, when the "SecurityType" parameter value is 618 "Secure Tunnel" (23) a VNC client MUST treat the value as a request 619 to use "Secure Tunnel" as the "ChannelType". However, this value 620 SHOULD NOT be supplied for the "SecurityType" parameter unless 621 required for backward compatibility as the channel must be 622 established prior to connecting to the server and is not consistent 623 with the negotiation of other security types. 625 3. Security Considerations 627 General security concerns involving URI schemes are discussed in 628 [RFC3986]. In implementing support for the "vnc" URI scheme, areas 629 for particular consideration include application trust, URI 630 transmission, host identification, and connection database security. 632 Remote desktop connectivity requires the transmission of security 633 credentials, which could be included in a URI. If those credentials 634 are not kept secure, an attacker can gain access to any systems 635 using those credentials. Host addresses and connection parameters 636 might also be considered sensitive, as such information can be used 637 in planning an attack. 639 URIs can also contain host identification information. It is 640 important to securely identify the remote host system to which a 641 connection is established. If a user connects to an attacker's 642 system, user data, including credentials, can be exposed. 644 Note that the RFB protocol itself does not encrypt data. To protect 645 data in transit, RFB should be tunneled over TLS [RFC5246], SSH 646 [RFC4251], or another secure protocol. 648 Some VNC systems can be used without authentication. To protect the 649 remote host, strong passwords or other authentication mechanisms 650 need to be used. 652 3.1. Application Trust 654 A malicious application receiving VNC credentials via URI or other 655 means can obviously misuse those credentials. To protect against 656 this, users should only install applications from trusted sources. 657 The integrity of application packages can be verified through 658 digital signatures. 660 Applications launching VNC clients can elect to launch only 661 particular trusted clients, and can specify those clients through 662 platform-specific mechanisms. Package integrity can be verified 663 programmatically by querying the package manager for digital 664 signatures or other platform-specific means. 666 The risk to a VNC client from a launching application is generally 667 much lower, since the launching application will not receive 668 credentials or data from the client. A VNC client can verify its 669 caller thorough platform-specific means. 671 VNC clients ought not to accept potentially destructive parameters 672 from untrusted launching applications without explicit user 673 confirmation. For example, a client-specific parameter that runs an 674 arbitrary command upon establishing a SSH connection used for VNC 675 tunneling is potentially destructive and high risk. 677 3.2. URI Transmission 679 Within a mobile or desktop environment, application launch will 680 typically involve in-memory URI data transmission facilitated and 681 secured by the operating system. 683 If sensitive URI information is exchanged across a network, for 684 example by providing a list of connection URIs in a web page, the 685 data needs to be encrypted in transit and only be accessible to 686 authorized users. 688 When an application detects potentially sensitive information in a 689 VNC URI, it needs to be handled securely or discarded. In 690 particular, the URI data that is persisted needs to be encrypted as 691 described in Section 3.4. 693 Applications that process URIs in a generic way, such as web 694 browsers, might not detect that sensitive information is contained 695 in a URI and could cache or store that information insecurely. It 696 is advisable to avoid including credentials and other sensitive 697 information in URIs that are likely to be processed in a generic way 698 unless such caching and storage is disabled or otherwise secured. 700 3.3. Host Identification 702 In the absence of verifiable host identification, a VNC client 703 application is vulnerable to spoofing and man-in-the-middle attacks 704 that capture VNC or host OS credentials and user data. To prevent 705 such attacks, administrators SHOULD secure their VNC communications 706 with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection 707 mechanisms identifying remote hosts via certificate or public key. 708 VNC clients MUST verify the respective certificates or public keys 709 to confirm the remote host's identity. 711 An application launching a VNC client via URI MAY provide a 712 certificate hash or public key hash identifying the remote host. 713 VNC clients maintaining a connection database can also store 714 certificate or public key data suitable for validating a host's 715 identity. 717 If connecting to a system identified by certificate or public key 718 and a remote system ID hash cannot be matched to available 719 identifying data, the VNC client needs to alert the user. The alert 720 will provide the remote system's identifying information and allow 721 the user to terminate the connection. The alert can allow the user 722 to accept the information and continue establishing the connection. 724 When providing identifying information of a host identified by an 725 X509 certificate [RFC5280], the certificate subject, issuer, 726 validity period, and certificate hash needs to be included. The VNC 727 client can verify the certificate validity. If the validity of a 728 certificate is not determined, the console application needs to 729 include a statement indicating such information has not been 730 verified. 732 Identifying information of a host identified by public key, such as 733 the endpoint of an SSH connection using a raw key, needs to include 734 a hash of the key. 736 3.4. Connection Database Integrity 738 A VNC client application and/or launching application can maintain a 739 connection database containing remote host information, credentials, 740 and/or connection parameters. Applications storing credentials need 741 to ensure they are stored in an encrypted format with a decryption 742 process requiring user-supplied or device-specific data. If 743 supported, it is advisable for applications to have a setting 744 disabling storage of credentials. 746 If available, the VNC client connection database can store 747 certificate or public key data used to verify host identification. 748 To prevent a malicious URI from overriding the database, if 749 identification information in the URI conflicts with information in 750 the database, the user needs to be prompted to accept the new 751 information prior to updating the database. 753 4. IANA Considerations 755 The "vnc" scheme should be registered in the URI schemes registry. 757 IANA "Remote Framebuffer Security Types", "VNC Connection Channel 758 Types", "VNC ID Hash Algorithms", and "VNC URI Parameters" 759 registries will support elements of the scheme. 761 4.1. "vnc" Scheme 763 IANA is asked to add the "vnc" scheme to the "Uniform Resource 764 Identifier (URI) Schemes" registry with description "Remote 765 Framebuffer Protocol" and reference to this document. A 766 registration template is provided in Appendix A. 768 The IANA schemes registry is currently located at: 770 http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 772 4.2. Remote Framebuffer Security Types 774 This document references the existing IANA "Remote Framebuffer 775 Security Types" registry in specifying security type options. IANA 776 is asked to update the "Secure Tunnel" and "Integrated SSH" security 777 types to refer to this document. 779 Future RFB security types will be supported in "vnc" URIs. Any new 780 security mechanism integrated with a VNC client which alters the 781 process by which a connection is established should also be 782 reflected in the registry to avoid overlapping numeric assignments. 784 This applies even if the mechanism does not involve a change to the 785 VNC server implementation or RFB protocol itself. For example, the 786 "Secure Tunnel" security type does not require RFB modification, but 787 indicates to the client that it must establish a TLS tunnel prior to 788 initiating RFB communications. Without inclusion in the registry, a 789 URI-launched client will be unable to distinguish future client- 790 initiated and protocol-based security mechanisms. 792 4.3. VNC Connection Channel Types 794 IANA is asked to create a "VNC Connection Channel Types" registry 795 within the "Remote Framebuffer (RFB)" group. The registry should 796 include Value, Description, and Reference columns. The initial 797 contents of the registry are described in this document. The values 798 of the "Secure Tunnel" and "Integrated SSH" types are copied from 799 the RFB Security Types registry. They should be: 801 Value Description Reference 802 -------- --------------- --------------- 803 1 Standard TCP (this document) 804 23 Secure Tunnel (this document) 805 24 Integrated SSH (this document) 807 Future assignments to this registry should be made through the 808 "Expert Review" process described in [RFC5226]. Experts reviewing 809 VNC Connection Channel Types should verify the proposed channel type 810 description is clear, and the channel type does not conflict with 811 existing channel types that are registered or in widespread use. 813 4.4. VNC ID Hash Algorithms 815 IANA is asked to create a "VNC ID Hash Algorithms" registry within 816 the "Remote Framebuffer (RFB)" group. The registry should include 817 Value, Description, and Reference columns. 819 The initial hash algorithms specified are a subset of the algorithms 820 contained in the "TLS HashAlgorithm Registry". The initial contents 821 of the registry should be: 823 Value Description Reference 824 -------- ------------ --------------- 825 1 MD5 (this document) 826 2 SHA1 (this document) 827 4 SHA256 (this document) 829 Future assignments to this registry should be made through the 830 "Expert Review" process described in [RFC5226]. Experts reviewing 831 VNC ID Hash Algorithms should verify the proposed parameter 832 description is clear, and the parameter does not conflict with 833 existing parameters that are registered or in widespread use. 835 4.5. VNC URI Parameters 837 IANA is asked to create a "VNC URI Parameters" registry within the 838 "Remote Framebuffer (RFB)" group. 840 The initial contents are described in this document. They should be: 842 +-----------------+-----------------------------+-----------------+ 843 | Name | Description | Reference | 844 +-----------------+-----------------------------+-----------------+ 845 | ConnectionName | Name of connection profile | (this document) | 846 +-----------------+-----------------------------+-----------------+ 847 | VncUsername | VNC server username | (this document) | 848 +-----------------+-----------------------------+-----------------+ 849 | VncPassword | VNC server password | (this document) | 850 +-----------------+-----------------------------+-----------------+ 851 | SecurityType | VNC security type used | (this document) | 852 +-----------------+-----------------------------+-----------------+ 853 | ChannelType | Connection channel type | (this document) | 854 +-----------------+-----------------------------+-----------------+ 856 +-----------------+-----------------------------+-----------------+ 857 | SshHost | SSH server hostname or IP | (this document) | 858 +-----------------+-----------------------------+-----------------+ 859 | SshPort | SSH server port | (this document) | 860 +-----------------+-----------------------------+-----------------+ 861 | SshUsername | SSH username | (this document) | 862 +-----------------+-----------------------------+-----------------+ 863 | SshPassword | SSH password | (this document) | 864 +-----------------+-----------------------------+-----------------+ 865 | IdHashAlgorithm | Hash algorithm used with | (this document) | 866 | | "IdHash" parameter | | 867 +-----------------+-----------------------------+-----------------+ 868 | IdHash | Expected hash of remote | (this document) | 869 | | public key or certificate | | 870 +-----------------+-----------------------------+-----------------+ 871 | ColorLevel | Client color depth/mode | (this document) | 872 +-----------------+-----------------------------+-----------------+ 873 | ViewOnly | Client is view only | (this document) | 874 +-----------------+-----------------------------+-----------------+ 875 | SaveConnection | Store connection info | (this document) | 876 +-----------------+-----------------------------+-----------------+ 878 Future assignments to these registries should be made through the 879 "Expert Review" process described in [RFC5226]. Experts reviewing 880 VNC URI parameters should verify the proposed parameter name and 881 description are clear, and the parameter does not conflict with 882 existing parameters that are registered or in widespread use. 884 5. References 886 5.1. Normative References 888 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 889 April 1992. 891 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 892 Requirement Levels", BCP 14, RFC 2119, March 1997. 894 [RFC3629] Yergeau, F., "UTF-8, a transformation format of 895 ISO 10646", STD 63, RFC 3629, November 2003. 897 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 898 Resource Identifier (URI): Generic Syntax", STD 66, RFC 899 3986, January 2005. 901 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 902 Protocol Architecture", RFC 4251, January 2006. 904 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 905 Authentication Protocol", RFC 4252, January 2006. 907 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 908 Transport Layer Protocol", RFC 4253, January 2006. 910 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 911 Connection Protocol", RFC 4254, January 2006. 913 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 914 Syntax Specifications: ABNF", STD 68, RFC 5234, January 915 2008. 917 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 918 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 920 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 921 Housley, R., and W. Polk, "Internet x.509 Public Key 922 Infrastructure Certificate and Certificate Revocation List 923 (CRL) Profile", RFC 5280, May 2008. 925 [RFC6143] Richardson, T., and J. Levine, "The Remote Framebuffer 926 Protocol", RFC 6143, March 2011. 928 [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National 929 Institute of Standards and Technology, U.S. Department of 930 Commerce, August 2002. 932 5.2. Informative References 934 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 935 and Registration Procedures for URI Schemes", BCP 35, RFC 936 7595, June 2015. 938 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 939 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 940 May 2008. 942 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 943 Information technology - Open Systems Interconnection - 944 The Directory: Public-key and attribute certificate 945 frameworks. 947 6. Acknowledgments 949 Dominic Parkes and the staff of RealVNC Ltd. graciously reviewed 950 this document and provided constructive comments. 952 RFB and VNC are registered trademarks of RealVNC Ltd. in the U.S. 953 and in other countries. 955 This document was prepared using 2-Word-v2.0.template.dot. 957 Appendix A. "vnc" URI Template 959 This template is provided for registration of the VNC URI in the 960 IANA URI schemes registry as specified in [RFC7595]. 962 URI Scheme name: vnc 964 Status: Permanent 966 URI scheme syntax: See Section 2 of this document. 968 Scheme semantics: See Section 2 of this document. 970 Encoding considerations: See Section 2 of this document. 972 Applications/protocols that use this URI scheme name: Virtual 973 Network Computing (VNC) remote desktop applications use vnc URIs. 974 VNC applications use the Remote Framebuffer (RFB) protocol. 976 Interoperability considerations: Legacy software applications 977 respond to vnc URIs in different ways and may fail to behave as 978 expected. It is advisable to test vnc URIs with specific 979 applications or consult application-specific documentation. 981 Security considerations: See Section 3 of this document. 983 Contact: IESG . 985 Author/Change Controller: See the Authors of this document. Change 986 control is through the IESG on behalf of the IETF . 988 References: This document. 990 Authors' Addresses 992 David Warden 993 Dell Products LP 994 200 Dell Way 995 Round Rock, Texas 78682 996 U.S.A. 998 Phone: 512-728-0380 999 Email: David_Warden@dell.com 1000 URI: http://www.dell.com 1002 Iordan Iordanov 1003 Undatech 1004 260 Scarlet Road, Apt. 503 1005 Toronto, ON M6N 4X6 1006 CANADA 1008 Email: iiordanov@gmail.com