idnits 2.17.1 draft-warden-appsawg-vnc-scheme-08.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 (January 10, 2016) is 3021 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: July 2016 Undatech 5 January 10, 2016 7 The "vnc" URI Scheme 8 draft-warden-appsawg-vnc-scheme-08.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) 2016 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 URI Group............................................18 79 4.4. VNC URI Connection Channel Types.........................18 80 4.5. VNC URI ID Hash Algorithms...............................19 81 4.6. VNC URI Parameters.......................................20 82 5. References....................................................21 83 5.1. Normative References.....................................21 84 5.2. Informative References...................................22 85 6. Acknowledgments...............................................22 86 Appendix A. "vnc" URI Template...................................23 88 1. Introduction 90 Virtual Network Computing (VNC) clients are used to support remote 91 desktop connectivity based on the Remote Framebuffer (RFB) Protocol 92 [RFC6143]. It is often desirable to integrate such functionality 93 with other software. However, the lack of a standard method for 94 specifying VNC client parameters has limited such integration. 96 The "vnc" Uniform Resource Identifier (URI) scheme specified in this 97 document facilitates the launch of VNC clients from applications in 98 browser-based, desktop, and mobile environments. Using this scheme, 99 users and application vendors will be able to integrate remote 100 desktop capabilities without being tied to a particular client. 102 Remote desktop clients often store connection profiles in a local 103 connection database. By associating connections specified in a URI 104 with those stored in a database, client-specific options can be 105 automatically applied to a connection launched from another 106 application, even when that application is unaware of those options. 108 Connections to VNC servers are often secured using mechanisms 109 including Transport Layer Security/Secure Sockets Layer (TLS/SSL) 110 tunneling [RFC5246] and Secure Shell (SSH) [RFC4251] tunneling which 111 are outside the scope of the RFB protocol. Defining the behavior of 112 these client-integrated security options enables their use with 113 "vnc" URIs. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC-2119 [RFC2119]. 121 In this document, these words will appear with that interpretation 122 only when in ALL CAPS. Lower case uses of these words are not to be 123 interpreted as carrying RFC-2119 significance. 125 2. The "vnc" URI Scheme 127 2.1. URI Scheme Syntax 129 The normative syntax of the "vnc" URI is defined in the 130 rule in the following syntax specification. This specification uses 131 the Augmented Backus-Naur Form (BNF) as described in [RFC5234]. The 132 "vnc" URI conforms to the generic URI syntax specified in [RFC3986]. 133 The , , , , and 134 rules are defined in [RFC3986]. 136 vnc-uri = "vnc://" [ userinfo "@" ] [ host [ ":" port ] ] 138 [ "?" [ vnc-params ] ] 140 vnc-params = param "=" value *("&" param "=" value) ["&"] 142 param = 1*( param-char ) 144 value = *( param-char ) 146 param-char = unreserved / pct-encoded / unreserved-symbols 148 unreserved-symbols = ":" / "/" / "@" / "!" / "$" / "'" 150 / "(" / ")" / "*" / "," / ";" 152 The "?", "=", and "&" characters are used to delimit VNC parameters 153 and must be percent-encoded when representing a data octet as 154 specified in [RFC3986]. Within the portion of a "vnc" 155 URI the do not have special meaning and need 156 not be percent-encoded when representing a data octet. 158 A "vnc" URI has the general form: 160 vnc://host:port?param1=value1¶m2=value2... 162 The host information and each parameter value specify information 163 used in establishing or operating the remote desktop session as 164 specified in Section 2.1.1. 166 For example: 168 vnc://10.0.0.1:5901?VncPassword=secret&SecurityType=2 170 Indicates a vnc connection to the host at IP "10.0.0.1" on port 171 "5901" with VNC password "secret" using the VNC Authentication 172 security type. 174 2.1.1. URI Parameters 176 A description of host information and URI parameters is provided in 177 this section. Information on the constraints of various data types 178 is provided in Section 2.1.2. All parameters are considered 179 optional, however a client will not be able to connect without 180 sufficient information. 182 A parameter without a specified default value indicates that no 183 default value is implied by this URI scheme, however VNC clients can 184 apply implementation dependent default behaviors otherwise 185 consistent with this document. 187 The value is deprecated and processed only in an 188 implementation-specific manner. The component MUST NOT 189 be generated in an environment where a client supporting an updated 190 URI format is expected to be available. When processing a URI value 191 from an untrusted source, VNC clients SHOULD alert the user in order 192 to mitigate the risk that the URI is constructed to obscure the 193 identity of the remote host unless the URI can be validated or 194 backwards compatibility considerations make an alert impractical. 196 The and values in the "vnc" URI specify the address of 197 the VNC server on the remote host: 199 +------------+------------+-----------------------------+----------+ 200 | Name | Type | Description | Default | 201 +------------+------------+-----------------------------+----------+ 202 | host | string | VNC server hostname or IP | none | 203 +------------+------------+-----------------------------+----------+ 204 | port | ushort | VNC server port | 5900 | 205 +------------+------------+-----------------------------+----------+ 207 The "vnc" URI parameter values specify remote desktop connection or 208 session properties, including aspects of client operation, 209 usability, and security as specified in the table below: 211 +---------------+---------+-----------------------------+----------+ 212 | Name | Type | Description | Default | 213 +---------------+---------+-----------------------------+----------+ 214 |ConnectionName | string | Name of connection profile | none | 215 +---------------+---------+-----------------------------+----------+ 216 |VncUsername | string | VNC server username | none | 217 +---------------+---------+-----------------------------+----------+ 218 |VncPassword | string | VNC server password | none | 219 +---------------+---------+-----------------------------+----------+ 220 |SecurityType | enum | RFB security type used | none | 221 | | | | | 222 +---------------+---------+-----------------------------+----------+ 223 |ChannelType | enum | Connection channel type | none | 224 | | | | | 225 +---------------+---------+-----------------------------+----------+ 226 |SshHost | string | SSH server hostname or IP | | 227 +---------------+---------+-----------------------------+----------+ 228 |SshPort | ushort | SSH server port | 22 | 229 +---------------+---------+-----------------------------+----------+ 230 |SshUsername | string | SSH username | none | 231 +---------------+---------+-----------------------------+----------+ 232 |SshPassword | string | SSH password | none | 233 +---------------+---------+-----------------------------+----------+ 234 +---------------+---------+-----------------------------+----------+ 235 |IdHashAlgorithm| enum | Hash algorithm used with | none | 236 | | | "IdHash" parameter | | 237 +---------------+---------+-----------------------------+----------+ 238 |IdHash | string | Expected hash of remote | none | 239 | | | public key or certificate | | 240 +---------------+---------+-----------------------------+----------+ 241 |ColorLevel | enum | Client color depth/mode | none | 242 | | | | | 243 +---------------+---------+-----------------------------+----------+ 244 |ViewOnly | boolean | Client is view only | false | 245 +---------------+---------+-----------------------------+----------+ 246 |SaveConnection | boolean | Store connection info | none | 247 +---------------+---------+-----------------------------+----------+ 249 o ConnectionName, SaveConnection 251 The "ConnectionName" is used to identify a connection profile in 252 both the launching application and VNC client. Profiles are 253 applied as described in Section 2.2.2. If omitted, the client 254 MAY generate a name based on the host, port, and/or other 255 parameters. The VNC client MAY normalize the name as required. 257 If true, "SaveConnection" indicates a connection profile should 258 be created or updated and stored in the client connection 259 database. If false, no profile should be updated or persisted. 261 o VncUsername, VncPassword, SecurityType 263 The SecurityType parameter indicates which RFB security type 264 applies to the connection. RFB security types are recorded in 265 the IANA "Remote Framebuffer Security Types" registry created by 266 [RFC6143]. The VNC client will use this information to determine 267 which parameters are required and establish the connection. 269 VNC clients can sometimes automatically negotiate a security type 270 with a server. However, in addition to controlling the security 271 negotiation, specifying the security type also allows for a 272 client to prompt in advance for necessary security parameters. 273 Parameters may take time to enter on mobile clients, and could 274 otherwise result in timeouts and/or security lockouts. If the 275 specified type is not supported by the server, an error SHOULD be 276 indicated as described in Section 2.2.1. 278 The "VncUsername" and "VncPassword" are used when applicable to 279 authenticate to the VNC server using the specified 280 "SecurityType". Since passwords often contain arbitrary 281 characters, they will often require percent encoding. 283 o ChannelType 285 The channel type specifies the transport stream used to carry 286 connection data. This allows a client to initiate a connection 287 using a secure transport protocol such as SSH prior to connecting 288 to the VNC server socket. Use of this value in the context of the 289 "Integrated SSH" and "Secure Tunnel" channel types is provided in 290 Section 2.3. 292 o SshHost, SshPort, SshUsername, SshPassword 294 The SSH parameters are intended for use with the "Integrated SSH" 295 channel type described in Section 2.3.1. These parameters can 296 also be used with any future SSH-based channel types. Since 297 passwords often contain arbitrary characters, they will often 298 require percent encoding. 300 o IdHashAlgorithm, IdHash 302 The "IdHashAlgorithm" and "IdHash" values are used to verify the 303 expected identity of the remote system based on its public key or 304 certificate. Use of these values in the context of the 305 "Integrated SSH" and "Secure Tunnel" channel types is provided in 306 Section 2.3. 308 o ColorLevel 310 The "ColorLevel" parameter specifies the color model to use for 311 data transfer and display as specified in Section 2.1.2. If the 312 requested color model is unsupported, the behavior is 313 implementation dependent. 315 o ViewOnly 317 If true, the VNC client SHOULD operate in a display-only mode and 318 refrain from sending input data including KeyEvent, PointerEvent, 319 and ClientCutText messages specified in Section 7.5 of [RFC6143] 320 unless this mode is unsupported by the client. 322 Parameter names SHOULD be provided in the case specified in this 323 document, however for compatibility clients SHOULD accept parameters 324 in a case-insensitive manner. Values SHALL be interpreted in a case- 325 sensitive manner, unless otherwise noted. 327 Additional parameters likely to be useful with multiple VNC clients 328 can be added to the "VNC URI Parameters" registry as specified in 329 Section 4.6 of this document. Individual clients MAY support 330 parameters specific to that client. VNC Clients supporting 331 application-specific parameters SHOULD include a distinguishing 332 prefix within the parameter name, such as the name of the 333 application package specified in source code except when precluded 334 by compatibility constraints. For example: 336 vnc://?com.dell.vncclient.ScreenMode=2& 338 It can also be expected that clients will maintain backward 339 compatibility with legacy URI formats and parameters. 341 2.1.2. Data Types 343 "vnc" URIs can be percent-encoded as specified in [RFC3986] and MUST 344 be decoded. After decoding, the following type constraints and 345 semantics apply: 347 o string 349 Values of "string" type are UTF-encoded strings as specified in 350 [RFC3629]. 352 The "string" subtype used in the "IdHash" consists of colon- 353 delimited ":" octets displayed in hexadecimal. For example: 355 5D:D2:39:57 357 Comparison of "string" values SHALL be case-insensitive, 358 however the uppercase notation is preferred for readability. 360 o enum 362 The "enum" types consist of specific enumerated subtypes and are 363 represented by their decimal value. 365 The "enum" values represent an RFB security type included 366 in the IANA "Remote Framebuffer Security Types" registry created 367 by [RFC6143]. 369 "enum" values represent connection channel types listed in 370 the "VNC URI Connection Channel Types" registry created by 371 Section 4.4 of this document. Initial values are: 373 Value Description 374 -------- -------------- 375 1 Standard TCP 376 23 Secure Tunnel 377 24 Integrated SSH 379 The Standard TCP channel type represents a generic TCP 380 connection. The Secure Tunnel and Integrated Secure Shell (SSH) 381 [RFC4252] channel types are described in Section 2.3. 383 Values of the "enum" parameter represent secure hash 384 algorithms in the "VNC URI Hash Algorithms" registry created by 385 Section 4.5 of this document. The initial values include: 387 Value Description 388 -------- ------------ 389 1 MD5 390 2 SHA1 391 4 SHA256 393 The MD5 algorithm is described in [RFC1321]. The SHA1 and SHA256 394 algorithms are described in [SHS]. 396 Values of the "enum" subtype represent a color level. In 397 the table below, the columns have the meaning specified in 398 Section 7.4 of [RFC6143]: 400 BPP = bits-per-pixel 401 TC = true-color-flag 402 RM = red-max 403 GM = green-max 404 BM = blue-max 405 RS = red-shift 406 GS = green-shift 407 BS = blue-shift 409 The values are: 411 Value Description BPP Depth TC RM GM BM RS GS BS 412 ----- --------------- --- ----- -- ---- ---- ---- -- -- -- 413 1 Black and White 8 3 t 1 1 1 2 1 0 414 2 Greyscale 8 6 t 3 3 3 4 2 0 415 3 8 Colors 8 3 t 1 1 1 2 1 0 416 Value Description BPP Depth TC RM GM BM RS GS BS 417 ----- --------------- --- ----- -- ---- ---- ---- -- -- -- 418 4 64 Colors 8 6 t 3 3 3 4 2 0 419 5 256 Colors 8 8 t 7 7 3 0 3 6 420 6 16-bit Color 16 16 t 31 63 31 11 5 0 421 7 24-bit Color 32 24 t 255 255 255 16 8 0 422 8 30-bit Color 32 30 t 1023 1023 1023 0 10 20 424 A value of "t" indicates the true-color-flag should be set. The 425 big-endian-flag should be set as required for the system. 427 o ushort 429 The "ushort" values represent unsigned 16-bit integers expressed 430 in decimal digits with value between 0-65535 inclusive. 432 o boolean 434 "boolean" values represent conditions that are true or false and 435 are represented as either "true" or "false" respectively. For 436 maximum compatibility, clients SHOULD accept the value 1 as 437 representing true values and 0 as representing false values. 438 Clients SHOULD perform parsing of "boolean" values in a case- 439 insensitive manner. 441 An example "vnc" URI including several of these data types is: 443 vnc://localhost:5900?ConnectionName=Server&SecurityType=2& 444 IdHash=0D:3A:72:08:57:EA:4D:30&SaveConnection=false& 446 Note the above example should be considered to be a contiguous 447 string without line breaks or whitespace and is broken into multiple 448 lines in this document for readability. 450 2.2. Processing URIs 452 Conceptually, a VNC URI supports only a "VIEW" operation, indicating 453 the user wishes to view the remote desktop accessible via the URI 454 reference. 456 In general, when a VNC client receives a "vnc" URI it will initiate 457 an RFB protocol remote desktop connection using the specified host 458 information and parameter values. Initiating the connection using a 459 connection channel mechanism such as those specified in Section 2.3 460 might require processing prior to establishing the RFB connection. 461 A client MAY attempt to automatically discover or negotiate 462 appropriate connection channel, security, or other parameter values. 464 The process for negotiating security types is specified in 465 [RFC6143]. Supported connection channels could be discovered by 466 testing channel types to detect when a channel is successfully 467 established. To best integrate with other applications the VNC 468 client SHOULD initiate the connection with minimal or no user 469 intervention, whenever sufficient information is available and 470 adequate security is preserved. 472 Host information and parameter values may be provided through 473 connection profiles. When a parameter value is not available from 474 either a URI or a connection profile described in Section 2.2.2, the 475 default value specified in Section 2.1.1 SHOULD be applied. If 476 available parameters are not sufficient to establish a connection, 477 the VNC client SHOULD present a session initiation data-entry 478 screen. 480 2.2.1. Error Handling 482 In a typical interactive environment, if an error prevents a session 483 from being established, the VNC client presents an error message to 484 the user. When the message is acknowledged, the console application 485 can show a session initiation data-entry screen populated with 486 available session parameters or it can terminate. If an error 487 occurs after a session is successfully established that terminates 488 the connection, the VNC client presents a termination notification 489 to the user. When the termination notification is acknowledged, the 490 client can present a reconnection prompt or terminate. 492 When an error occurs in a dedicated environment (such as a kiosk 493 system), the system can transmit an alert to the remote operator, 494 record a log entry, and execute appropriate fallback behavior such 495 as automatically attempting to reestablish a session or displaying a 496 generic message requesting servicing. 498 2.2.2. Connection Profile Matching 500 VNC clients MAY store remote desktop session settings in connection 501 profiles. If the client is able to uniquely identify and associate 502 a connection request with a connection profile based on the 503 "ConnectionName" parameter value, remote host IP address, or 504 hostname/fully-qualified domain name, the VNC client SHOULD apply 505 profile values for those settings which do not have values supplied 506 in the "vnc" URI. When profile data is unavailable, the VNC client 507 MAY apply global application defaults for settings not supplied in 508 the URI and for which the scheme does not specify a default value. 509 The VNC client MUST NOT override supplied parameters with profile 510 values or global defaults. 512 When the "SaveConnection" parameter value is true, within the VNC 513 client a connection profile SHOULD be created or updated with the 514 values supplied in the "vnc" URI. Profile updates and storage 515 should be consistent with the recommendations in Section 3.4. 517 2.3. Connection Channel Types 519 2.3.1. The "Integrated SSH" Channel Type 521 The "Integrated SSH" channel type establishes an SSH connection to a 522 host, authenticates with SSH password authentication, establishes a 523 secure tunnel to the VNC host/port, and then connects to the VNC 524 server using a supported "SecurityType". The secure tunnel will 525 provide encryption and data integrity, while verifying the public 526 key authenticates the server. The SSH architecture is specified in 527 [RFC4251]. The steps are detailed below: 529 1. The VNC client initiates a transport-level connection to the 530 "SshHost" on the "SshPort" specified in the parameter values with 531 a key exchange as described in [RFC4253]. 533 2. When the VNC client receives the server key (or certificate), the 534 hash of the key (or certificate) is computed using the algorithm 535 corresponding to the "IdHashAlgorithm" parameter value and 536 compared with the expected "IdHash" value (if available). If the 537 certificate hash cannot be verified, the client alerts the user 538 or operator. In a typical interactive environment, the alert 539 provides the remote system's identifying information including 540 the hash value and allows the user to terminate the connection. 541 The alert could allow the user to accept the key and continue 542 establishing the connection. In a dedicated environment (such as 543 a kiosk system), the system can transmit an alert to the remote 544 operator, record a log entry, and execute appropriate fallback 545 behavior such as displaying a generic message requesting 546 servicing. 548 3. The SSH client authenticates the user using the "SshUsername" and 549 "SshPassword" parameter values according to the "password" 550 authentication mechanism described in [RFC4252]. 552 4. The SSH client opens a TCP/IP channel as specified in [RFC4254] 553 from the local system to the system indicated by the and 554 information values. 556 5. The VNC client establishes a RFB connection to the VNC server 557 over the channel and authenticates using the "SecurityType" as 558 described in [RFC6143] or other reference. 560 The VNC client MAY establish the connection described in this 561 section using an external SSH client, by launching the client and 562 then connecting to a secure tunnel created between a local port and 563 the VNC server. 565 If the VNC client is supplied with additional parameters outside the 566 scope of this document, it MAY perform a variation of these steps 567 consistent with the underlying protocols, for example by using 568 "publickey" SSH client authentication [RFC4252] or providing another 569 form of authentication to the VNC server. The specific negotiation 570 of SSH parameters such as cipher suite configuration is outside the 571 scope of this document. 573 Many SSH clients present key hashes using MD5 and it can be expected 574 that launching applications will specify the hash be displayed in 575 the manner its users are familiar with. 577 For compatibility, when the "SecurityType" parameter value is 578 "Integrated SSH" (24), a VNC client MUST treat the value as a 579 request to use "Integrated SSH" as the "ChannelType". However, this 580 value SHOULD NOT be supplied for the "SecurityType" parameter unless 581 required for backward compatibility as the channel is established 582 prior to connecting to the server and is not consistent with the 583 negotiation of other security types. 585 2.3.2. The "Secure Tunnel" Channel Type 587 The "Secure Tunnel" channel type establishes a TLS connection with a 588 remote server using certificate authentication, over which a 589 connection to the VNC server is established using a supported 590 "SecurityType". The secure tunnel will provide encryption and data 591 integrity, while verifying the certificate authenticates the server. 592 The TLS protocol is specified in [RFC5246]. The steps are detailed 593 below: 595 1. The VNC client initiates the TLS Handshake Protocol with a system 596 indicated by the and information values. 598 2. When the server certificate is received, the hash of the key 599 certificate is computed using the algorithm corresponding to the 600 "IdHashAlgorithm" parameter value and compared with the expected 601 "IdHash" value (if available). If the certificate hash cannot be 602 verified, the client alerts the user or operator. In a typical 603 interactive environment, the alert provides the remote system's 604 identifying information and allows the user to terminate the 605 connection. The alert could allow the user to accept the key and 606 continue establishing the connection. In a dedicated environment 607 (such as a kiosk system), the system can transmit an alert to the 608 remote operator, record a log entry, and execute appropriate 609 fallback behavior such as displaying a generic message requesting 610 servicing. 612 When providing identifying information of a host identified by an 613 X509 certificate [RFC5280], the certificate subject, issuer, 614 validity period, and certificate hash is typically included. The 615 VNC client MAY verify the validity of the certificate. If the 616 validity of a certificate is not confirmed, the alert includes a 617 statement indicating such information has not been verified. 619 3. The client finishes establishing the TLS tunnel. 621 4. The VNC client establishes a RFB connection to the VNC server 622 over the channel and authenticates using the "SecurityType" as 623 described in [RFC6143] or other reference. 625 If the VNC client is supplied with additional parameters, it MAY 626 perform a variation of these steps consistent with the underlying 627 protocols, for example by providing another form of authentication 628 to the VNC server. The negotiation of specific TLS parameters such 629 as cipher suite configuration is outside the scope of this document. 631 The TLS protocol provides backwards compatibility with SSLv3, 632 however due to known security flaws it SHOULD NOT be used. 634 For compatibility, when the "SecurityType" parameter value is 635 "Secure Tunnel" (23) a VNC client MUST treat the value as a request 636 to use "Secure Tunnel" as the "ChannelType". However, this value 637 SHOULD NOT be supplied for the "SecurityType" parameter unless 638 required for backward compatibility as the channel must be 639 established prior to connecting to the server and is not consistent 640 with the negotiation of other security types. 642 3. Security Considerations 644 General security concerns involving URI schemes are discussed in 645 [RFC3986]. In implementing support for the "vnc" URI scheme, areas 646 for particular consideration include application trust, URI 647 transmission, host identification, and connection database security. 649 Remote desktop connectivity requires the transmission of security 650 credentials, which could be included in a URI. If those credentials 651 are not kept secure, an attacker can gain access to any systems 652 using those credentials. Host addresses and connection parameters 653 might also be considered sensitive, as such information can be used 654 in planning an attack. 656 URIs can also contain host identification information. It is 657 important to securely identify the remote host system to which a 658 connection is established. If a user connects to an attacker's 659 system, user data, including credentials, can be exposed. 661 Note that the RFB protocol itself may not encrypt data. To protect 662 data in transit, RFB should be tunneled over TLS [RFC5246], SSH 663 [RFC4251], or another secure protocol. 665 Some VNC systems can be used without authentication. To protect the 666 remote host, strong passwords or other authentication mechanisms 667 need to be used. 669 3.1. Application Trust 671 A malicious application receiving VNC credentials via URI or other 672 means can obviously misuse those credentials. To protect against 673 this, users should only install applications from trusted sources. 674 The integrity of application packages can be verified through 675 digital signatures. 677 Applications launching VNC clients can elect to launch only 678 particular trusted clients, and can specify those clients through 679 platform-specific mechanisms. Package integrity can be verified 680 programmatically by querying the package manager for digital 681 signatures or other platform-specific means. 683 The risk to a VNC client from a launching application is generally 684 much lower, since the launching application will not receive 685 credentials or data from the client. A VNC client can verify its 686 caller thorough platform-specific means. 688 VNC clients ought not to accept potentially destructive parameters 689 from untrusted launching applications without explicit user 690 confirmation. For example, a client-specific parameter that runs an 691 arbitrary command upon establishing a SSH connection used for VNC 692 tunneling is potentially destructive and high risk. 694 3.2. URI Transmission 696 Within a mobile or desktop environment, application launch will 697 typically involve in-memory URI data transmission facilitated and 698 secured by the operating system. 700 If sensitive URI information is exchanged across a network, for 701 example by providing a list of connection URIs in a web page, the 702 data needs to be encrypted in transit and only be accessible to 703 authorized users. 705 When an application detects potentially sensitive information in a 706 VNC URI, it needs to be handled securely or discarded. In 707 particular, the URI data that is persisted needs to be encrypted as 708 described in Section 3.4. 710 Applications that process URIs in a generic way, such as web 711 browsers, might not detect that sensitive information is contained 712 in a URI and could cache or store that information insecurely. It 713 is advisable to avoid including credentials and other sensitive 714 information in URIs that are likely to be processed in a generic way 715 unless such caching and storage is disabled or otherwise secured. 717 3.3. Host Identification 719 In the absence of verifiable host identification, a VNC client 720 application is vulnerable to spoofing and man-in-the-middle attacks 721 that capture VNC or host OS credentials and user data. To prevent 722 such attacks, administrators SHOULD secure their VNC communications 723 with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection 724 mechanisms identifying remote hosts via certificate or public key. 725 VNC clients MUST verify the respective certificates or public keys 726 to confirm the remote host's identity. 728 An application launching a VNC client via URI MAY provide a 729 certificate hash or public key hash identifying the remote host. 730 VNC clients maintaining a connection database can also store 731 certificate or public key data suitable for validating a host's 732 identity. 734 If connecting to a system identified by certificate or public key 735 and a remote system ID hash cannot be matched to available 736 identifying data, the VNC client needs to alert the user or 737 operator. In a typical interactive environment, the alert will 738 provide the remote system's identifying information and allow the 739 user to terminate the connection. The alert can allow the user to 740 accept the information and continue establishing the connection. In 741 a dedicated environment (such as a kiosk system), the system can 742 transmit an alert to the remote operator, record a log entry, and 743 execute appropriate fallback behavior such as displaying a generic 744 message requesting servicing. 746 When providing identifying information of a host identified by an 747 X509 certificate [RFC5280], the certificate subject, issuer, 748 validity period, and certificate hash needs to be included. The VNC 749 client can verify the certificate validity. If the validity of a 750 certificate is not determined, the alert needs to include a 751 statement indicating such information has not been verified. 753 Identifying information of a host identified by public key, such as 754 the endpoint of an SSH connection using a raw key, needs to include 755 a hash of the key. 757 3.4. Connection Database Integrity 759 A VNC client application and/or launching application can maintain a 760 connection database containing remote host information, credentials, 761 and/or connection parameters. Applications storing credentials need 762 to ensure they are stored in an encrypted format with a decryption 763 process requiring user-supplied or device-specific data. If 764 supported, it is advisable for applications to have a setting 765 disabling storage of credentials. 767 If available, the VNC client connection database can store 768 certificate or public key data used to verify host identification. 769 To prevent a malicious URI from overriding the database, if 770 identification information in the URI conflicts with information in 771 the database, the user or operator needs to be alerted. In a 772 typical interactive environment, the user can be prompted to accept 773 the new information prior to updating the database. 775 4. IANA Considerations 777 The "vnc" scheme should be registered in the URI schemes registry. 779 IANA "Remote Framebuffer Security Types", "VNC URI Connection 780 Channel Types", "VNC URI ID Hash Algorithms", and "VNC URI 781 Parameters" registries will support elements of the scheme. 783 4.1. "vnc" Scheme 785 IANA is asked to add the "vnc" scheme to the "Uniform Resource 786 Identifier (URI) Schemes" registry with description "Remote 787 Framebuffer Protocol" and reference to this document. A 788 registration template is provided in Appendix A. 790 The IANA schemes registry is currently located at: 792 http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 794 4.2. Remote Framebuffer Security Types 796 This document references the existing IANA "Remote Framebuffer 797 Security Types" registry in specifying security type options. RFB 798 security types are supported in "vnc" URIs. 800 Security mechanisms integrated with VNC clients might need to alter 801 the process by which a connection is established prior to the 802 security handshake described in Section 7.1.2 of RFC6143. Such 803 mechanisms should be reflected in the "VNC URI Connection Chanel 804 Types" registry described in Section 4.4 of this document rather 805 than the "Remote Framebuffer Security Types" registry as their use 806 cannot be negotiated by the mechanism specified in RFC6143. 808 Exceptions can be made for backwards compatibility. IANA is asked 809 to update the "Secure Tunnel" and "Integrated SSH" security types 810 listed for compatibility to refer to this document. 812 4.3. VNC URI Group 814 IANA is asked to create a "VNC URI" Group. This group will contain 815 application-level URI related registries distinct from those used by 816 the RFB protocol itself. 818 4.4. VNC URI Connection Channel Types 820 IANA is asked to create a "VNC URI Connection Channel Types" 821 registry within the "VNC URI" group. The registry should include 822 Value, Description, and Reference columns. The initial contents of 823 the registry are described in this document. The values of the 824 "Secure Tunnel" and "Integrated SSH" types are copied from the RFB 825 Security Types registry. They should be: 827 Value Description Reference 828 -------- --------------- --------------- 829 0 Reserved (this document) 830 1 Standard TCP (this document) 831 23 Secure Tunnel (this document) 832 24 Integrated SSH (this document) 834 The maximum acceptable value is 2,147,483,647. 836 Future assignments to this registry should be made through the 837 "Expert Review" process described in [RFC5226]. Experts reviewing 838 VNC URI Connection Channel Types should verify the proposed channel 839 type description is clear, and the channel type does not conflict 840 with existing channel types that are registered or in widespread 841 use. 843 4.5. VNC URI ID Hash Algorithms 845 IANA is asked to create a "VNC URI ID Hash Algorithms" registry 846 within the "VNC URI" group. The registry should include Value, 847 Description, and Reference columns. 849 The initial hash algorithms specified are a subset of the algorithms 850 contained in the "TLS HashAlgorithm Registry". The initial contents 851 of the registry should be: 853 Value Description Reference 854 -------- ------------ --------------- 855 0 Reserved (this document) 856 1 MD5 (this document) 857 2 SHA1 (this document) 858 4 SHA256 (this document) 860 The maximum acceptable value is 2,147,483,647. 862 Future assignments to this registry should be made through the 863 "Expert Review" process described in [RFC5226]. Experts reviewing 864 VNC URI ID Hash Algorithms should verify the proposed parameter 865 description is clear, and the parameter does not conflict with 866 existing parameters that are registered or in widespread use. 868 4.6. VNC URI Parameters 870 IANA is asked to create a "VNC URI Parameters" registry within the 871 "VNC URI" group. 873 The initial contents are described in this document. They should be: 875 +-----------------+-----------------------------+-----------------+ 876 | Name | Description | Reference | 877 +-----------------+-----------------------------+-----------------+ 878 | ConnectionName | Name of connection profile | (this document) | 879 +-----------------+-----------------------------+-----------------+ 880 | VncUsername | VNC server username | (this document) | 881 +-----------------+-----------------------------+-----------------+ 882 | VncPassword | VNC server password | (this document) | 883 +-----------------+-----------------------------+-----------------+ 884 | SecurityType | RFB security type used | (this document) | 885 +-----------------+-----------------------------+-----------------+ 886 | ChannelType | Connection channel type | (this document) | 887 +-----------------+-----------------------------+-----------------+ 888 | SshHost | SSH server hostname or IP | (this document) | 889 +-----------------+-----------------------------+-----------------+ 890 | SshPort | SSH server port | (this document) | 891 +-----------------+-----------------------------+-----------------+ 892 | SshUsername | SSH username | (this document) | 893 +-----------------+-----------------------------+-----------------+ 894 | SshPassword | SSH password | (this document) | 895 +-----------------+-----------------------------+-----------------+ 896 | IdHashAlgorithm | Hash algorithm used with | (this document) | 897 | | "IdHash" parameter | | 898 +-----------------+-----------------------------+-----------------+ 899 | IdHash | Expected hash of remote | (this document) | 900 | | public key or certificate | | 901 +-----------------+-----------------------------+-----------------+ 902 | ColorLevel | Client color depth/mode | (this document) | 903 +-----------------+-----------------------------+-----------------+ 904 | ViewOnly | Client is view only | (this document) | 905 +-----------------+-----------------------------+-----------------+ 906 | SaveConnection | Store connection info | (this document) | 907 +-----------------+-----------------------------+-----------------+ 909 Future assignments to these registries should be made through the 910 "Expert Review" process described in [RFC5226]. Experts reviewing 911 VNC URI parameters should verify the proposed parameter name and 912 description are clear, and the parameter does not conflict with 913 existing parameters that are registered or in widespread use. 915 5. References 917 5.1. Normative References 919 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 920 April 1992. 922 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 923 Requirement Levels", BCP 14, RFC 2119, March 1997. 925 [RFC3629] Yergeau, F., "UTF-8, a transformation format of 926 ISO 10646", STD 63, RFC 3629, November 2003. 928 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 929 Resource Identifier (URI): Generic Syntax", STD 66, RFC 930 3986, January 2005. 932 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 933 Protocol Architecture", RFC 4251, January 2006. 935 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 936 Authentication Protocol", RFC 4252, January 2006. 938 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 939 Transport Layer Protocol", RFC 4253, January 2006. 941 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 942 Connection Protocol", RFC 4254, January 2006. 944 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 945 Syntax Specifications: ABNF", STD 68, RFC 5234, January 946 2008. 948 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 949 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 951 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 952 Housley, R., and W. Polk, "Internet x.509 Public Key 953 Infrastructure Certificate and Certificate Revocation List 954 (CRL) Profile", RFC 5280, May 2008. 956 [RFC6143] Richardson, T., and J. Levine, "The Remote Framebuffer 957 Protocol", RFC 6143, March 2011. 959 [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National 960 Institute of Standards and Technology, U.S. Department of 961 Commerce, August 2002. 963 5.2. Informative References 965 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 966 and Registration Procedures for URI Schemes", BCP 35, RFC 967 7595, June 2015. 969 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 970 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 971 May 2008. 973 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 974 Information technology - Open Systems Interconnection - 975 The Directory: Public-key and attribute certificate 976 frameworks. 978 6. Acknowledgments 980 Dominic Parkes and the staff of RealVNC Ltd. graciously reviewed 981 this document and provided constructive comments. 983 RFB and VNC are registered trademarks of RealVNC Ltd. in the U.S. 984 and in other countries. 986 This document was prepared using 2-Word-v2.0.template.dot. 988 Appendix A. "vnc" URI Template 990 This template is provided for registration of the VNC URI in the 991 IANA URI schemes registry as specified in [RFC7595]. 993 URI Scheme name: vnc 995 Status: Permanent 997 URI scheme syntax: See Section 2 of this document. 999 Scheme semantics: See Section 2 of this document. 1001 Encoding considerations: See Section 2 of this document. 1003 Applications/protocols that use this URI scheme name: Virtual 1004 Network Computing (VNC) remote desktop applications use vnc URIs. 1005 VNC applications use the Remote Framebuffer (RFB) protocol. 1007 Interoperability considerations: Legacy software applications 1008 respond to vnc URIs in different ways and may fail to behave as 1009 expected. It is advisable to test vnc URIs with specific 1010 applications or consult application-specific documentation. 1012 Security considerations: See Section 3 of this document. 1014 Contact: IESG . 1016 Author/Change Controller: See the Authors of this document. Change 1017 control is through the IESG on behalf of the IETF . 1019 References: This document. 1021 Authors' Addresses 1023 David Warden 1024 Dell Products LP 1025 200 Dell Way 1026 Round Rock, Texas 78682 1027 U.S.A. 1029 Phone: 512-728-0380 1030 Email: David_Warden@dell.com 1031 URI: http://www.dell.com 1033 Iordan Iordanov 1034 Undatech 1035 260 Scarlet Road, Apt. 503 1036 Toronto, ON M6N 4X6 1037 CANADA 1039 Email: iiordanov@gmail.com