idnits 2.17.1 draft-warden-appsawg-vnc-scheme-05.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 (September 27, 2015) is 3132 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: March 2016 Undatech 5 September 27, 2015 7 The "vnc" URI Scheme 8 draft-warden-appsawg-vnc-scheme-05.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 March 30, 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.................................11 68 2.3.1. The "Integrated SSH" Channel Type...................11 69 2.3.2. The "Secure Tunnel" Channel Type....................13 70 3. Security Considerations.......................................14 71 3.1. Application Trust........................................14 72 3.2. URI Transmission.........................................15 73 3.3. Host Identification......................................15 74 3.4. Connection Database Integrity............................16 75 4. IANA Considerations...........................................16 76 4.1. "vnc" Scheme.............................................17 77 4.2. Remote Framebuffer Security Types........................17 78 4.3. VNC Connection Channel Types.............................17 79 4.4. VNC ID Hash Algorithms...................................18 80 4.5. VNC URI Parameters.......................................18 81 5. References....................................................19 82 5.1. Normative References.....................................19 83 5.2. Informative References...................................20 84 6. Acknowledgments...............................................20 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?parm1=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 The value is deprecated and processed only in an 181 implementation-specific manner. The component MUST NOT 182 be generated in an environment where a client supporting an updated 183 URI format is expected to be available. When processing a URI value 184 from an untrusted source, VNC clients SHOULD alert the user in order 185 to mitigate the risk that the URI is constructed to obscure the 186 identity of the remote host. 188 The and values in the "vnc" URI specify the address of 189 the VNC server on the remote host: 191 +------------+------------+-----------------------------+----------+ 192 | Name | Type | Description | Default | 193 +------------+------------+-----------------------------+----------+ 194 | host | string | VNC server hostname or IP | | 195 +------------+------------+-----------------------------+----------+ 196 | port | ushort | VNC server port | 5900 | 197 +------------+------------+-----------------------------+----------+ 199 The "vnc" URI parameter values specify remote desktop connection or 200 session properties, including aspects of client operation, 201 usability, and security as specified in the table below: 203 +---------------+---------+-----------------------------+----------+ 204 | Name | Type | Description | Default | 205 +---------------+---------+-----------------------------+----------+ 206 |ConnectionName | string | Name of connection profile | | 207 +---------------+---------+-----------------------------+----------+ 208 |VncUsername | string | VNC server username | | 209 +---------------+---------+-----------------------------+----------+ 210 |VncPassword | string | VNC server password | | 211 +---------------+---------+-----------------------------+----------+ 212 |SecurityType | enum | VNC security type used | | 213 | | | | | 214 +---------------+---------+-----------------------------+----------+ 215 |ChannelType | enum | Connection channel type | | 216 | | | | | 217 +---------------+---------+-----------------------------+----------+ 218 |SshHost | string | SSH server hostname or IP | | 219 +---------------+---------+-----------------------------+----------+ 220 |SshPort | ushort | SSH server port | 22 | 221 +---------------+---------+-----------------------------+----------+ 222 |SshUsername | string | SSH username | | 223 +---------------+---------+-----------------------------+----------+ 224 |SshPassword | string | SSH password | | 225 +---------------+---------+-----------------------------+----------+ 226 |IdHashAlgorithm| enum | Hash algorithm used with | | 227 | | | "IdHash" parameter | | 228 +---------------+---------+-----------------------------+----------+ 229 |IdHash | string | Expected hash of remote | | 230 | | | public key or certificate | | 231 +---------------+---------+-----------------------------+----------+ 232 +---------------+---------+-----------------------------+----------+ 233 |ColorLevel | enum | Client color depth/mode | | 234 | | | | | 235 +---------------+---------+-----------------------------+----------+ 236 |ViewOnly | boolean | Client is view only | false | 237 +---------------+---------+-----------------------------+----------+ 238 |SaveConnection | boolean | Store connection info | | 239 +---------------+---------+-----------------------------+----------+ 241 o ConnectionName, SaveConnection 243 The "ConnectionName" is used to identify a connection profile in 244 both the launching application and VNC client. Profiles are 245 applied as described in Section 2.2.2. If omitted, the client 246 MAY generate a name based on the host, port, and/or other 247 parameters. The VNC client MAY normalize the name as required. 249 If true, "SaveConnection" indicates a connection profile should 250 be created or updated and stored in the client connection 251 database. If false, no profile should be updated or persisted. 253 o VncUsername, VncPassword, SecurityType 255 The SecurityType parameter indicates which RFB security type 256 applies to the connection. VNC security types are recorded in 257 the IANA "Remote Framebuffer Security Types" registry created by 258 [RFC6143]. The VNC client will use this information to determine 259 which parameters are required and establish the connection. 261 VNC clients can sometimes automatically negotiate a security type 262 with a server. However, in addition to controlling the security 263 negotiation, specifying the security type also allows for a 264 client to prompt in advance for necessary security parameters. 265 Parameters may take time to enter on mobile clients, and could 266 otherwise result in timeouts and/or security lockouts. If the 267 specified type is not supported by the server, an error should be 268 indicated as described in Section 2.2.1. 270 The "VncUsername" and "VncPassword" are used when applicable to 271 authenticate to the VNC server using the specified 272 "SecurityType". Since passwords often contain arbitrary 273 characters, they will often require percent encoding. 275 o ChannelType 277 The channel type specifies the transport stream used to carry 278 connection data. This allows a client to initiate a connection 279 using a secure transport protocol such as SSH prior to connecting 280 to the VNC server socket. Use of this value in the context of the 281 "Integrated SSH" and "Secure Tunnel" channel types is provided in 282 Section 2.3. 284 o SshHost, SshPort, SshUsername, SshPassword 286 The SSH parameters are intended for use with the "Integrated SSH" 287 channel type described in Section 2.3.1. These parameters can 288 also be used with any future SSH-based channel types. Since 289 passwords often contain arbitrary characters, they will often 290 require percent encoding. 292 o IdHashAlgorithm, IdHash 294 The "IdHashAlgorithm" and "IdHash" values are used to verify the 295 expected identity of the remote system based on its public key or 296 certificate. Use of these values in the context of the 297 "Integrated SSH" and "Secure Tunnel" channel types is provided in 298 Section 2.3. 300 o ColorLevel 302 The "ColorLevel" parameter specifies the color model to use for 303 data transfer and display as specified in Section 2.1.2. If the 304 requested color model is unsupported, the behavior is 305 implementation dependent. 307 o ViewOnly 309 If true, the VNC client should operate in a display-only mode and 310 refrain from sending input data including KeyEvent, PointerEvent, 311 and ClientCutText messages specified in Section 7.5 of [RFC6143]. 313 Parameter names SHOULD be provided in the case specified in this 314 document, however for compatibility clients SHOULD accept parameters 315 in a case-insensitive manner. Values SHALL be interpreted in a case 316 sensitive manner, unless otherwise noted. 318 Additional parameters likely to be useful with multiple VNC clients 319 can be added to the "VNC URI Parameters" registry as specified in 320 Section 4.5 of this document. Individual clients MAY support 321 parameters specific to that client. VNC Clients supporting 322 application-specific parameters SHOULD include a distinguishing 323 prefix within the parameter name, such as the name of the 324 application package specified in source code. For example: 326 vnc://?com.dell.vncclient.ScreenMode=2& 328 It can also be expected that clients will maintain backward 329 compatibility with legacy URI formats and parameters. 331 2.1.2. Data Types 333 As "vnc" URIs may be percent-encoded as specified in [RFC3986] and 334 must be decoded. After decoding, the following type constraints and 335 semantics apply: 337 o string 339 Values of "string" type are UTF-encoded strings as specified in 340 [RFC3629]. 342 The "string" subtype used in the "IdHash" consists of colon- 343 delimited ":" octets displayed in hexadecimal. For example: 345 5D:D2:39:57 347 Comparison of "string" values shall be case-insensitive, 348 however the uppercase notation is preferred for readability. 350 o enum 352 The "enum" types consist of specific enumerated subtypes and are 353 represented by their decimal index value. 355 The "enum" values represent a VNC security type included 356 in the IANA "Remote Framebuffer Security Types" registry created 357 by [RFC6143]. 359 "enum" values represent connection channel types listed in 360 the "VNC Connection Channel Types" registry created by Section 361 4.3 of this document. Initial values are: 363 Value Description 364 -------- -------------- 365 1 Standard TCP 366 23 Secure Tunnel 367 24 Integrated SSH 369 The Standard TCP channel type represents a generic TCP 370 connection. The Secure Tunnel and Integrated SSH channel types 371 are described in Section 2.3. 373 Values of the "enum" parameter represent secure hash 374 algorithms in the "VNC Hash Algorithms" registry created by 375 Section 4.4 of this document. The initial values include: 377 Value Description 378 -------- ------------ 379 1 MD5 380 2 SHA1 381 4 SHA256 383 The MD5 algorithm is described in [RFC1321]. The SHA1 and SHA256 384 algorithms are described in [SHS]. 386 Values of the "enum" subtype represent a color level. In 387 the table below, the columns have the meaning specified in 388 Section 7.4 of [RFC6143]: 390 BPP = bits-per-pixel 391 TC = true-color-flag 392 RM = red-max 393 GM = green-max 394 BM = blue-max 395 RS = red-shift 396 GS = green-shift 397 BS = blue-shift 399 The values are: 401 Value Description BPP Depth TC RM GM BM RS GS BS 402 ----- --------------- --- ----- -- ---- ---- ---- -- -- -- 403 1 Black and White 8 3 t 1 1 1 2 1 0 404 2 Greyscale 8 6 t 3 3 3 4 2 0 405 3 8 Colors 8 3 t 1 1 1 2 1 0 406 4 64 Colors 8 6 t 3 3 3 4 2 0 407 5 256 Colors 8 8 t 7 7 3 0 3 6 408 6 16-bit Color 16 16 t 31 63 31 11 5 0 409 7 24-bit Color 32 24 t 255 255 255 16 8 0 410 8 30-bit Color 32 30 t 1023 1023 1023 0 10 20 412 A value of "t" indicates the true-color-flag should be set, the 413 big-endian-flag should be set as required for the system. 415 o ushort 417 The "ushort" values represent unsigned 16-bit integers expressed 418 in decimal digits with value between 0-65535 inclusive. 420 o boolean 422 "boolean" values represent conditions that are true or false and 423 are represented as either "true" or "false" respectively. For 424 maximum compatibility, clients SHOULD accept the value "1" as 425 representing true values and "0" as representing false values. 426 Clients SHOULD perform parsing of "boolean" values in a case 427 insensitive manner. 429 An example "vnc" URI including several of these data types is: 431 vnc://localhost:5900?ConnectionName=Server&SecurityType=2& 432 IdHash=0D:3A:72:08:57:EA:4D:30&SaveConnection=false& 434 2.2. Processing URIs 436 Conceptually, a VNC URI supports only a "VIEW" operation, indicating 437 the user wishes to view the remote desktop accessible via the URI 438 reference. 440 In general, when a VNC client receives a "vnc" URI it will initiate 441 an RFB protocol remote desktop connection using the specified host 442 information and parameter values. Initiating the connection using a 443 connection channel mechanism such as those specified in Section 2.3 444 may require processing prior to establishing the RFB connection. A 445 client MAY attempt to automatically discover or negotiate 446 appropriate connection channel, security, or other parameter values. 447 To best integrate with other applications the VNC client SHOULD 448 initiate the connection with minimal or no user intervention, 449 whenever sufficient information is available and adequate security 450 is preserved. 452 Host information and parameter values may be provided through 453 connection profiles. When a parameter value is not available from 454 either a URI or a connection profile described in Section 2.2.2, the 455 default value specified in Section 2.1.1 should be applied. If 456 available parameters are not sufficient to establish a connection, 457 the VNC client SHOULD present a session initiation data-entry 458 screen. Canceling the dialog or ending the session SHOULD terminate 459 the application. 461 2.2.1. Error Handling 463 If an error prevents a session from being established, the VNC 464 client MUST present an error message to the user. When the message 465 is acknowledged, the console application MAY show a session 466 initiation data-entry screen populated with available session 467 parameters or it MAY terminate. If an error occurs after a session 468 is successfully established which terminates the connection, the VNC 469 client MUST present a termination notification to the user. When 470 the termination notification is acknowledged, the client MAY present 471 a reconnection prompt or MAY terminate. 473 2.2.2. Connection Profile Matching 475 VNC clients MAY store remote desktop session settings in connection 476 profiles. If the client is able to uniquely identify and associate 477 a connection request with a connection profile based on the 478 "ConnectionName" parameter value, remote host IP address, or 479 hostname/fully-qualified domain name, the VNC client SHOULD apply 480 profile values for those settings which do not have values supplied 481 in the "vnc" URI. When profile data is unavailable, the VNC client 482 MAY apply global application defaults for settings not supplied in 483 the URI and for which the scheme does not specify a default value. 484 The VNC client MUST NOT override supplied parameters with profile 485 values or global defaults. 487 When the "SaveConnection" parameter value is true, a connection 488 profile SHOULD be created or updated with the values supplied in the 489 "vnc" URI. Profile updates and storage should be consistent with 490 the recommendations in Section 3.4. 492 2.3. Connection Channel Types 494 2.3.1. The "Integrated SSH" Channel Type 496 The "Integrated SSH" channel type establishes an SSH connection to a 497 host, authenticates with SSH password authentication, establishes a 498 secure tunnel to the VNC host/port, and then connects to the VNC 499 server using a supported "SecurityType". The secure tunnel will 500 provide encryption and data integrity, while verifying the public 501 key authenticates the server. The SSH architecture is specified in 502 [RFC4251]. The steps are detailed below: 504 1. The VNC client initiates a transport-level connection to the 505 "SshHost" on the "SshPort" specified in the parameter values with 506 a key exchange as described in [RFC4253]. 508 2. When the VNC client receives the server key (or certificate), the 509 hash of the key (or certificate) is computed using the algorithm 510 corresponding to the "IdHashAlgorithm" parameter value and 511 compared with the expected "IdHash" value (if available). If the 512 certificate hash cannot be verified, the client MUST alert the 513 user. The alert MUST provide the remote system's identifying 514 information including the hash value and allow the user to 515 terminate the connection. The alert MAY allow the user to accept 516 the key and continue establishing the connection. 518 3. The SSH client authenticates the user using the "SshUsername" and 519 "SshPassword" parameter values according to the "password" 520 authentication mechanism described in [RFC4252]. 522 4. The SSH client opens a TCP/IP channel as specified in [RFC4254] 523 from the local system to the system indicated by the and 524 information values. 526 5. The VNC client establishes a RFB connection to the VNC server 527 over the channel and authenticates using the "SecurityType" as 528 described in [RFC6143] or other reference. 530 The VNC client MAY establish the connection described in this 531 section using an external SSH client, by launching the client and 532 then connecting to a secure tunnel created between a local port and 533 the VNC server. 535 If the VNC client is supplied with additional parameters outside the 536 scope of this document, it MAY perform a variation of these steps 537 consistent with the underlying protocols, for example by using 538 "publickey" SSH client authentication [RFC4252] or providing another 539 form of authentication to the VNC server. The specific negotiation 540 of SSH parameters such as cipher suite configuration is outside the 541 scope of this document. 543 Many SSH clients present key hashes using MD5 and it can be expected 544 that launching applications MAY specify the hash be displayed in the 545 manner its users are familiar with. 547 For compatibility, when the "SecurityType" parameter value is 548 "Integrated SSH" (24) a VNC client SHOULD treat the value as a 549 request to use "Integrated SSH" as the "ChannelType". However this 550 value SHOULD NOT be supplied for the "SecurityType" parameter as the 551 channel must be established prior to connecting to the server and is 552 not consistent with the negotiation of other security types. 554 2.3.2. The "Secure Tunnel" Channel Type 556 The "Secure Tunnel" channel type establishes a TLS connection with a 557 remote server using certificate authentication, over which a 558 connection to the VNC server is established using a supported 559 "SecurityType". The secure tunnel will provide encryption and data 560 integrity, while verifying the certificate authenticates the server. 561 The TLS protocol is specified in [RFC5246]. The steps are detailed 562 below: 564 1. The VNC client initiates the TLS Handshake Protocol with a system 565 indicated by the and information values. 567 2. When the server certificate is received, the hash of the key 568 certificate is computed using the algorithm corresponding to the 569 "IdHashAlgorithm" parameter value and compared with the expected 570 "IdHash" value (if available). If the certificate hash cannot be 571 verified, the client MUST alert the user. The alert MUST provide 572 the remote system's identifying information and allow the user to 573 terminate the connection. The alert MAY allow the user to accept 574 the key and continue establishing the connection. 576 When providing identifying information of a host identified by an 577 X509 certificate [RFC5280], the certificate subject, issuer, 578 validity period, and certificate hash MUST be included. The VNC 579 client MAY verify the validity of the certificate. If the 580 validity of a certificate is not determined, the console 581 application MUST include a statement indicating such information 582 has not been verified. 584 3. The client finishes establishing the TLS tunnel. 586 4. The VNC client establishes a RFB connection to the VNC server 587 over the channel and authenticates using the "SecurityType" as 588 described in [RFC6143] or other reference. 590 If the VNC client is supplied with additional parameters, it may 591 perform a variation of these steps consistent with the underlying 592 protocols, for example by providing another form of authentication 593 to the VNC server. The negotiation of specific TLS parameters such 594 as cipher suite configuration are outside the scope of this 595 document. 597 The TLS protocol provides backwards compatibility with SSLv3, 598 however due to known security flaws it SHOULD NOT be used. 600 For compatibility, when the "SecurityType" parameter value is 601 "Secure Tunnel" (23) a VNC client SHOULD treat the value as a 602 request to use "Secure Tunnel" as the "ChannelType". However this 603 value SHOULD NOT be supplied for the "SecurityType" parameter as the 604 channel must be established prior to connecting to the server and is 605 not consistent with the negotiation of other security types. 607 3. Security Considerations 609 General security concerns involving URI schemes are discussed in 610 [RFC3986]. In implementing support for the "vnc" URI scheme, areas 611 for particular consideration include application trust, URI 612 transmission, host identification, and connection database security. 614 Remote desktop connectivity requires the transmission of security 615 credentials, which may be included in a URI. If those credentials 616 are not kept secure, an attacker may gain access to any systems 617 using those credentials. Host addresses and connection parameters 618 may also be considered sensitive, as such information can be used in 619 planning an attack. 621 URIs can also contain host identification information. It is 622 important to securely identify the remote host system connected to. 623 If a user connects to an attacker's system, user data, including 624 credentials, may be exposed. 626 Note that the RFB protocol itself does not encrypt data. To protect 627 data in transit, RFB should be tunneled over TLS [RFC5246], SSH 628 [RFC4251], or another secure protocol. 630 Some VNC systems can be used without authentication. To protect the 631 remote host, strong passwords or other authentication mechanisms 632 should be used. 634 3.1. Application Trust 636 A malicious application receiving VNC credentials via URI or other 637 means can obviously misuse those credentials. To protect against 638 this, users should only install applications from trusted sources. 639 The integrity of application packages can be verified through 640 digital signatures. 642 Applications launching VNC clients MAY wish to launch only 643 particular trusted clients, and can specify those clients through 644 platform-specific mechanisms. Package integrity can be verified 645 programmatically by querying the package manager for digital 646 signatures or other platform-specific means. 648 The risk to a VNC client from a launching application is generally 649 much lower, since the launching application will not receive 650 credentials or data from the client. A VNC client MAY verify its 651 caller thorough platform-specific means. 653 VNC clients SHOULD NOT accept potentially destructive parameters 654 from untrusted launching applications without explicit user 655 confirmation. For example, a client-specific parameter that runs an 656 arbitrary command upon establishing a SSH connection used for VNC 657 tunneling is potentially destructive and high risk. 659 3.2. URI Transmission 661 Within a mobile or desktop environment, application launch will 662 typically involve in-memory URI data transmission facilitated and 663 secured by the OS. 665 If sensitive URI information is exchanged across a network, for 666 example by providing a list of connection URIs in a web page, the 667 data should be encrypted in transit and only be accessible to 668 authorized users. 670 When an application detects potentially sensitive information in a 671 VNC URI, it MUST be handled securely or discarded. In particular, 672 the URI data MUST only be persisted when encrypted as described in 673 Section 3.4. 675 Applications which process URIs in a generic way, such as web 676 browsers, might not detect that sensitive information is contained 677 in a URI and could cache or store that information insecurely. It 678 is advisable to avoid including credentials and other sensitive 679 information in URIs that are likely to be processed in a generic way 680 unless such caching and storage is disabled or otherwise secured. 682 3.3. Host Identification 684 In the absence of verifiable host identification, a VNC client 685 application is vulnerable to spoofing and man-in-the-middle attacks 686 which capture VNC or host OS credentials and user data. To prevent 687 such attacks, administrators SHOULD secure their VNC communications 688 with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection 689 mechanisms identifying remote hosts via certificate or public key. 690 VNC clients MUST verify the respective certificates or public keys 691 to confirm the remote host's identity. 693 An application launching a VNC client via URI MAY provide a 694 certificate hash or public key hash identifying the remote host. 696 VNC clients maintaining a connection database MAY also store 697 certificate or public key data suitable for validating a host's 698 identity. 700 If connecting to a system identified by certificate or public key 701 and a remote system ID hash cannot be matched to available 702 identifying data, the VNC client MUST alert the user. The alert 703 MUST provide the remote system's identifying information and allow 704 the user to terminate the connection. The alert MAY allow the user 705 to accept the information and continue establishing the connection. 707 When providing identifying information of a host identified by an 708 X509 certificate [RFC5280], the certificate subject, issuer, 709 validity period, and certificate hash MUST be included. The VNC 710 client MAY verify the certificate validity. If the validity of a 711 certificate is not determined, the console application MUST include 712 a statement indicating such information has not been verified. 714 Identifying information of a host identified by public key, such as 715 the endpoint of an SSH connection using a raw key, MUST include a 716 hash of the key. 718 3.4. Connection Database Integrity 720 A VNC client application and/or launching application MAY maintain a 721 connection database containing remote host information, credentials, 722 and/or connection parameters. Applications MUST NOT store 723 credentials unless the credentials are stored in an encrypted format 724 with a decryption process requiring user-supplied or device-specific 725 data. If supported, an application SHOULD have a setting disabling 726 storage of credentials. 728 If available, the VNC client connection database SHOULD store 729 certificate or public key data used to verify host identification. 730 To prevent a malicious URI from overriding the database, if 731 identification information in the URI conflicts with information in 732 the database, the user MUST be prompted to accept the new 733 information prior to updating the database. 735 4. IANA Considerations 737 The "vnc" scheme should be registered in the URI schemes registry. 739 IANA "Remote Framebuffer Security Types", "VNC Connection Channel 740 Types", "VNC ID Hash Algorithms", and "VNC URI Parameters" 741 registries will support elements of the scheme. 743 4.1. "vnc" Scheme 745 IANA is asked to add the "vnc" scheme to the URI schemes registry 746 with description "Remote Framebuffer Protocol" and reference to this 747 document. A registration template is provided in Appendix A. 749 The IANA schemes registry is currently located at: 751 http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 753 4.2. Remote Framebuffer Security Types 755 This document references the existing IANA "Remote Framebuffer 756 Security Types" registry in specifying security type options. IANA 757 is asked to update the "Secure Tunnel" and "Integrated SSH" security 758 types to refer to this document. 760 Future RFB security types will be supported in "vnc" URIs. Any new 761 security mechanism integrated with a VNC client which alters the 762 process by which a connection is established should also be 763 reflected in the registry to avoid overlapping numeric assignments. 765 This applies even if the mechanism does not involve a change to the 766 VNC server implementation or RFB protocol itself. For example, the 767 "Secure Tunnel" security type does not require RFB modification, but 768 indicates to the client that it must establish a TLS tunnel prior to 769 initiating RFB communications. Without inclusion in the registry, a 770 URI-launched client will be unable to distinguish future client- 771 initiated and protocol-based security mechanisms. 773 4.3. VNC Connection Channel Types 775 IANA is asked to create a "VNC Connection Channel Types" registry 776 within the "Remote Framebuffer (RFB)" group. The registry should 777 include Value, Description, and Reference columns. The initial 778 contents of the registry are described in this document. The values 779 of the "Secure Tunnel" and "Integrated SSH" types are copied from 780 the RFB Security Types registry. They should be: 782 Value Description Reference 783 -------- --------------- --------------- 784 1 Standard TCP (this document) 785 23 Secure Tunnel (this document) 786 24 Integrated SSH (this document) 788 Future assignments to this registry should be made through the 789 "Expert Review" process described in [RFC5226]. Experts reviewing 790 VNC Connection Channel Types should verify the proposed channel type 791 description is clear, and the channel type does not conflict with 792 existing channel types that are registered or in widespread use. 794 4.4. VNC ID Hash Algorithms 796 IANA is asked to create a "VNC ID Hash Algorithms" registry within 797 the "Remote Framebuffer (RFB)" group. The registry should include 798 Value, Description, and Reference columns. 800 The initial hash algorithms specified are a subset of the algorithms 801 contained in the "TLS HashAlgorithm Registry". The initial contents 802 of the registry should be: 804 Value Description Reference 805 -------- ------------ --------------- 806 1 MD5 (this document) 807 2 SHA1 (this document) 808 4 SHA256 (this document) 810 Future assignments to this registry should be made through the 811 "Expert Review" process described in [RFC5226]. Experts reviewing 812 VNC ID Hash Algorithms should verify the proposed parameter 813 description is clear, and the parameter does not conflict with 814 existing parameters that are registered or in widespread use. 816 4.5. VNC URI Parameters 818 IANA is asked to create a "VNC URI Parameters" registry within the 819 "Remote Framebuffer (RFB)" group. 821 The initial contents are described in this document. They should be: 823 +-----------------+-----------------------------+-----------------+ 824 | Name | Description | Reference | 825 +-----------------+-----------------------------+-----------------+ 826 | ConnectionName | Name of connection profile | (this document) | 827 +-----------------+-----------------------------+-----------------+ 828 | VncUsername | VNC server username | (this document) | 829 +-----------------+-----------------------------+-----------------+ 830 | VncPassword | VNC server password | (this document) | 831 +-----------------+-----------------------------+-----------------+ 832 | SecurityType | VNC security type used | (this document) | 833 +-----------------+-----------------------------+-----------------+ 834 | ChannelType | Connection channel type | (this document) | 835 +-----------------+-----------------------------+-----------------+ 836 +-----------------+-----------------------------+-----------------+ 837 | SshHost | SSH server hostname or IP | (this document) | 838 +-----------------+-----------------------------+-----------------+ 839 | SshPort | SSH server port | (this document) | 840 +-----------------+-----------------------------+-----------------+ 841 | SshUsername | SSH username | (this document) | 842 +-----------------+-----------------------------+-----------------+ 843 | SshPassword | SSH password | (this document) | 844 +-----------------+-----------------------------+-----------------+ 845 | IdHashAlgorithm | Hash algorithm used with | (this document) | 846 | | "IdHash" parameter | | 847 +-----------------+-----------------------------+-----------------+ 848 | IdHash | Expected hash of remote | (this document) | 849 | | public key or certificate | | 850 +-----------------+-----------------------------+-----------------+ 851 | ColorLevel | Client color depth/mode | (this document) | 852 +-----------------+-----------------------------+-----------------+ 853 | ViewOnly | Client is view only | (this document) | 854 +-----------------+-----------------------------+-----------------+ 855 | SaveConnection | Store connection info | (this document) | 856 +-----------------+-----------------------------+-----------------+ 858 Future assignments to these registries should be made through the 859 "Expert Review" process described in [RFC5226]. Experts reviewing 860 VNC URI parameters should verify the proposed parameter name and 861 description are clear, and the parameter does not conflict with 862 existing parameters that are registered or in widespread use. 864 5. References 866 5.1. Normative References 868 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 869 April 1992. 871 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 872 Requirement Levels", BCP 14, RFC 2119, March 1997. 874 [RFC3629] Yergeau, F., "UTF-8, a transformation format of 875 ISO 10646", STD 63, RFC 3629, November 2003. 877 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 878 Resource Identifier (URI): Generic Syntax", STD 66, RFC 879 3986, January 2005. 881 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 882 Protocol Architecture", RFC 4251, January 2006. 884 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 885 Authentication Protocol", RFC 4252, January 2006. 887 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 888 Transport Layer Protocol", RFC 4253, January 2006. 890 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 891 Connection Protocol", RFC 4254, January 2006. 893 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 894 Syntax Specifications: ABNF", STD 68, RFC 5234, January 895 2008. 897 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 898 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 900 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 901 Housley, R., and W. Polk, "Internet x.509 Public Key 902 Infrastructure Certificate and Certificate Revocation List 903 (CRL) Profile", RFC 5280, May 2008. 905 [RFC6143] Richardson, T., and J. Levine, "The Remote Framebuffer 906 Protocol", RFC 6143, March 2011. 908 [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National 909 Institute of Standards and Technology, U.S. Department of 910 Commerce, August 2002. 912 5.2. Informative References 914 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 915 and Registration Procedures for URI Schemes", BCP 35, RFC 916 7595, June 2015. 918 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 919 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 920 May 2008. 922 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 923 Information technology - Open Systems Interconnection - 924 The Directory: Public-key and attribute certificate 925 frameworks. 927 6. Acknowledgments 929 Dominic Parkes and the staff of RealVNC Ltd. graciously reviewed 930 this document and provided constructive comments. 932 RFB and VNC are registered trademarks of RealVNC Ltd. in the U.S. 933 and in other countries. 935 This document was prepared using 2-Word-v2.0.template.dot. 937 Appendix A. "vnc" URI Template 939 This template is provided for registration of the VNC URI in the 940 IANA URI schemes registry as specified in [RFC7595]. 942 URI Scheme name: vnc 944 Status: Permanent 946 URI scheme syntax: See Section 2 of this document. 948 Scheme semantics: See Section 2 of this document. 950 Encoding considerations: See Section 2 of this document. 952 Applications/protocols that use this URI scheme name: Virtual 953 Network Computing (VNC) remote desktop applications use vnc URIs. 954 VNC applications use the Remote Framebuffer (RFB) protocol. 956 Interoperability considerations: Legacy software applications 957 respond to vnc URIs in different ways and may fail to behave as 958 expected. It is advisable to test vnc URIs with specific 959 applications or consult application-specific documentation. 961 Security considerations: See Section 3 of this document. 963 Contact: IETF Applications Area Directors 965 Author/Change Controller: See the Authors of this document. Change 966 control is through the IESG on behalf of the IETF iesg@ietf.org. 968 References: This document. 970 Authors' Addresses 972 David Warden 973 Dell Products LP 974 200 Dell Way 975 Round Rock, Texas 78682 976 U.S.A. 978 Phone: 512-728-0380 979 Email: David_Warden@dell.com 980 URI: http://www.dell.com 982 Iordan Iordanov 983 Undatech 984 260 Scarlet Road, Apt. 503 985 Toronto, ON M6N 4X6 986 CANADA 988 Email: iiordanov@gmail.com