idnits 2.17.1 draft-warden-appsawg-vnc-scheme-01.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 (May 4, 2015) is 3279 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 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 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: November 2015 Undatech 5 May 4, 2015 7 The "vnc" URI Scheme 8 draft-warden-appsawg-vnc-scheme-01.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 November 5, 2015. 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...........................................7 64 2.2. Processing URIs...........................................9 65 2.2.1. Error Handling......................................10 66 2.2.2. Connection Profile Matching.........................10 67 2.3. Integrated Security Types................................11 68 2.3.1. The "Integrated SSH" Security Type..................11 69 2.3.2. The "Secure Tunnel" Security Type...................12 70 3. Security Considerations.......................................13 71 3.1. Application Trust........................................13 72 3.2. URI Transmission.........................................14 73 3.3. Host Identification......................................14 74 3.4. Connection Database Integrity............................15 75 4. IANA Considerations...........................................15 76 4.1. "vnc" Scheme.............................................15 77 4.2. Remote Framebuffer Security Types........................16 78 4.3. VNC ID Hash Algorithms...................................16 79 4.4. VNC URI Parameters.......................................16 80 5. References....................................................17 81 5.1. Normative References.....................................17 82 5.2. Informative References...................................18 83 6. Acknowledgments...............................................19 84 Appendix A. "vnc" URI Template...................................20 86 1. Introduction 88 Virtual Network Computing (VNC) clients are used to support remote 89 desktop connectivity based on the Remote Framebuffer (RFB) Protocol 90 [RFC6143]. It is often desirable to integrate such functionality 91 with other software. However, the lack of a standard method for 92 specifying VNC client parameters has limited such integration. 94 The "vnc" Uniform Resource Identifier (URI) scheme specified in this 95 document facilitates the launch of VNC clients from applications in 96 browser-based, desktop, and mobile environments. Using this scheme 97 users and application vendors will be able to integrate remote 98 desktop capabilities without being tied to a particular client. 100 Remote desktop clients often store connection profiles in a local 101 connection database. By associating connections specified in a URI 102 with those stored in a database, client-specific options can be 103 automatically applied to a connection launched from another 104 application, even when that application is unaware of those options. 106 Connections to VNC servers are often secured using mechanisms 107 including Transport Layer Security/Secure Sockets Layer (TLS/SSL) 108 tunneling [RFC5246] and Secure Shell (SSH) [RFC4251] tunneling which 109 are outside the scope of the RFB protocol. Defining the behavior of 110 these client-integrated security options enables their use with 111 "vnc" URIs. 113 1.1. Requirements Language 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC-2119 [RFC2119]. 119 In this document, these words will appear with that interpretation 120 only when in ALL CAPS. Lower case uses of these words are not to be 121 interpreted as carrying RFC-2119 significance. 123 2. The "vnc" URI Scheme 125 2.1. URI Scheme Syntax 127 The normative syntax of the "vnc" URI is defined in the 128 rule in the following syntax specification. This specification uses 129 the augmented Backus-Naur Form (BNF) as described in [RFC5234]. The 130 "vnc" URI conforms to the generic URI syntax specified in [RFC3986]. 131 The , , , , and 132 rules are defined in [RFC3986]. 134 vnc-uri = "vnc://" [ userinfo "@" ] [ host [ ":" port ] ] 136 [ "?" [ vnc-params ] ] 138 vnc-params = param "=" value *("&" param "=" value) ["&"] 140 param = 1*( param-char ) 141 value = *( param-char ) 143 param-char = unreserved / pct-encoded / unreserved-symbols 145 unreserved-symbols = ":" / "/" / "#" / "[" / "]" / "@" / "!" / 147 "$" / "'" / "(" / ")" / "*" / "," / ";" 149 The "?", "=", and "&" characters are used to delimit VNC parameters 150 and must be percent-encoded when representing a data octet as 151 specified in [RFC3986]. Within the portion of a "vnc" 152 URI the do not have special meaning and need 153 not be percent-encoded when representing a data octet. 155 A "vnc" URI has the general form: 157 vnc://host:port?parm1=value1¶m2=value2... 159 The host information and each parameter value specify information 160 used in establishing or operating the remote desktop session as 161 specified in Section 2.1.1. 163 For example: 165 vnc://10.0.0.1:5901?VncPassword=secret&SecurityType=2 167 Indicates a vnc connection to the host at IP "10.0.0.1" on port 168 "5901" with VNC password "secret" using VNC security. 170 2.1.1. URI Parameters 172 A description of host information and URI parameters is provided in 173 this section. Information on the constraints of various data types 174 is provided in Section 2.1.2. All parameters are considered 175 optional, however a client will not be able to connect without 176 sufficient information. 178 The value is deprecated and processed only in an 179 implementation-specific manner. The component MUST NOT 180 be generated in an environment where a client supporting an updated 181 URI format is expected to be available. When processing a URI value 182 from an untrusted source, VNC clients SHOULD alert the user in order 183 to mitigate the risk that the URI is constructed to obscure the 184 identity of the remote host. 186 The and values in the "vnc" URI specify the address of 187 the VNC server on the remote host: 189 +------------+------------+-----------------------------+----------+ 190 | Name | Type | Description | Default | 191 +------------+------------+-----------------------------+----------+ 192 | host | string | VNC server hostname or IP | | 193 +------------+------------+-----------------------------+----------+ 194 | port | ushort | VNC server port | 5900 | 195 +------------+------------+-----------------------------+----------+ 197 The "vnc" URI parameter values specify remote desktop connection or 198 session properties, including aspects of client operation, 199 usability, and security as specified in the table below: 201 +---------------+---------+-----------------------------+----------+ 202 | Name | Type | Description | Default | 203 +---------------+---------+-----------------------------+----------+ 204 |ConnectionName | string | Name of connection profile | | 205 +---------------+---------+-----------------------------+----------+ 206 |VncUsername | string | VNC server username | | 207 +---------------+---------+-----------------------------+----------+ 208 |VncPassword | string | VNC server password | | 209 +---------------+---------+-----------------------------+----------+ 210 |SecurityType | enum | VNC security type used | | 211 | | | | | 212 +---------------+---------+-----------------------------+----------+ 213 |SshHost | string | SSH server hostname or IP | | 214 +---------------+---------+-----------------------------+----------+ 215 |SshPort | ushort | SSH server port | 22 | 216 +---------------+---------+-----------------------------+----------+ 217 |SshUsername | string | SSH username | | 218 +---------------+---------+-----------------------------+----------+ 219 |SshPassword | string | SSH password | | 220 +---------------+---------+-----------------------------+----------+ 221 |IdHashAlgorithm| enum | Hash algorithm used with | | 222 | | | "IdHash" parameter | | 223 +---------------+---------+-----------------------------+----------+ 224 |IdHash | string | Expected hash of remote | | 225 | | | public key or certificate | | 226 +---------------+---------+-----------------------------+----------+ 227 |ColorLevel | enum | Client color depth/mode | | 228 | | | | | 229 +---------------+---------+-----------------------------+----------+ 230 |ViewOnly | boolean | Client is view only | false | 231 +---------------+---------+-----------------------------+----------+ 232 |SaveConnection | boolean | Store connection info | | 233 +---------------+---------+-----------------------------+----------+ 234 o ConnectionName, SaveConnection 236 The "ConnectionName" is used to identify a connection profile in 237 both the launching application and VNC client. Profiles are 238 applied as described in Section 2.2.2. If omitted, the client 239 MAY generate a name based on the host, port, and/or other 240 parameters. The VNC client MAY normalize the name as required. 242 If true, "SaveConnection" indicates a connection profile should 243 be created or updated and stored in the client connection 244 database. If false, no profile should be updated or persisted. 246 o VncUsername, VncPassword, SecurityType 248 The SecurityType parameter indicates which RFB security type 249 applies to the connection. VNC security types are recorded in 250 the IANA "Remote Framebuffer Security Types" registry created by 251 [RFC6143]. The VNC client will use this information to determine 252 which parameters are required and establish the connection. 254 VNC clients can sometimes automatically negotiate a security type 255 with a server. However, in addition to controlling the security 256 negotiation, specifying the security type allows a client to 257 activate a secure transport mechanism such as VNC over SSH prior 258 to connecting to the VNC server socket. Specifying the security 259 type also allows for a client to prompt in advance for necessary 260 security parameters, which may take time to enter on mobile 261 clients, and could otherwise result in timeouts and/or security 262 lockouts. If the specified type is not supported by the server, 263 an error should be indicated as described in Section 2.2.1. 265 The "VncUsername" and "VncPassword" are used when applicable to 266 authenticate to the VNC server using the specified 267 "SecurityType". Since passwords often contain arbitrary 268 characters, they will often require percent encoding. 270 o SshHost, SshPort, SshUsername, SshPassword 272 The SSH parameters are intended for use with the "Integrated SSH" 273 security type described in Section 2.3.1. These parameters can 274 also be used with any future SSH-based security types. Since 275 passwords often contain arbitrary characters, they will often 276 require percent encoding. 278 o IdHashAlgorithm, IdHash 280 The "IdHashAlgorithm" and "IdHash" values are used to verify the 281 expected identity of the remote system based on its public key or 282 certificate. Use of these values in the context of the 283 "Integrated SSH" and "Secure Tunnel" security types is provided 284 in Section 2.3. 286 o ColorLevel 288 The "ColorLevel" parameter specifies the color model to use for 289 data transfer and display as specified in Section 2.1.2. If the 290 requested color model is unsupported, the behavior is 291 implementation dependent. 293 o ViewOnly 295 If true, the VNC client should operate in a display-only mode and 296 refrain from sending input data including KeyEvent, PointerEvent, 297 and ClientCutText messages specified in Section 7.5 of [RFC6143]. 299 Parameter names SHOULD be provided in the case specified in this 300 document, however for compatibility clients SHOULD accept parameters 301 in a case-insensitive manner. Values SHALL be interpreted in a case 302 sensitive manner, unless otherwise noted. 304 Additional parameters likely to be useful with multiple VNC clients 305 can be added to the "VNC URI Parameters" registry as specified in 306 Section 4.4 of this document. Individual clients MAY support 307 parameters specific to that client. VNC Clients supporting 308 application-specific parameters SHOULD include a distinguishing 309 prefix within the parameter name, such as the name of the 310 application package specified in source code. For example: 312 vnc://?com.dell.vncclient.ScreenMode=2& 314 It can also be expected that clients will maintain backward 315 compatibility with legacy URI formats and parameters. 317 2.1.2. Data Types 319 As "vnc" URIs may be percent-encoded as specified in [RFC3986] and 320 must be decoded. After decoding, the following type constraints and 321 semantics apply: 323 o string 325 Values of "string" type are UTF-encoded strings as specified in 326 [RFC3629]. 328 The "string" subtype used in the "IdHash" consists of colon- 329 delimited ":" octets displayed in hexadecimal. For example: 331 5D:D2:39:57 333 Comparison of "string" values shall be case-insensitive, 334 however the uppercase notation is preferred for readability. 336 o enum 338 The "enum" types consist of specific enumerated subtypes and are 339 represented by their decimal index value. 341 The "enum" values represent a VNC security type included 342 in the IANA "Remote Framebuffer Security Types" registry created 343 by [RFC6143]. 345 Values of the "enum" parameter represent secure hash 346 algorithms in the "VNC Hash Algorithms" registry created by 347 Section 4.3 of this document. The initial values include: 349 Value Description 350 -------- ------------ 351 1 MD5 352 2 SHA1 353 4 SHA256 355 The MD5 algorithm is described in [RFC1321]. The SHA1 and SHA256 356 algorithms are described in [SHS]. 358 Values of the "enum" subtype represent a color level. In 359 the table below, the columns have the meaning specified in 360 Section 7.4 of [RFC6143]: 362 BPP = bits-per-pixel 363 TC = true-color-flag 364 RM = red-max 365 GM = green-max 366 BM = blue-max 367 RS = red-shift 368 GS = green-shift 369 BS = blue-shift 371 The values are: 373 Value Description BPP Depth TC RM GM BM RS GS BS 374 ----- --------------- --- ----- -- ---- ---- ---- -- -- -- 375 1 Black and White 8 3 t 1 1 1 2 1 0 376 2 Greyscale 8 6 t 3 3 3 4 2 0 377 3 8 Colors 8 3 t 1 1 1 2 1 0 378 4 64 Colors 8 6 t 3 3 3 4 2 0 379 5 256 Colors 8 8 t 7 7 3 0 3 6 380 6 16-bit Color 16 16 t 31 63 31 11 5 0 381 7 24-bit Color 32 24 t 255 255 255 16 8 0 382 8 30-bit Color 32 30 t 1023 1023 1023 0 10 20 384 A value of "t" indicates the true-color-flag should be set, the 385 big-endian-flag should be set as required for the system. 387 o ushort 389 The "ushort" values represent unsigned 16-bit integers expressed 390 in decimal digits with value between 0-65535 inclusive. 392 o boolean 394 "boolean" values represent conditions that are true or false and 395 are represented as either "true" or "false" respectively. For 396 maximum compatibility, clients SHOULD accept the value "1" as 397 representing true values and "0" as representing false values. 398 Clients SHOULD perform parsing of "boolean" values in a case 399 insensitive manner. 401 An example "vnc" URI including several of these data types is: 403 vnc://localhost:5900?ConnectionName=Server&SecurityType=2& 404 IdHash=0D:3A:72:08:57:EA:4D:30&SaveConnection=false& 406 2.2. Processing URIs 408 Conceptually, a VNC URI supports only a "VIEW" operation, indicating 409 the user wishes to view the remote desktop accessible via the URI 410 reference. 412 In general, when a VNC client receives a "vnc" URI it will initiate 413 an RFB protocol remote desktop connection using the specified host 414 information and parameter values. Initiating the connection using 415 an integrated security mechanism such as those specified in Section 416 2.3 may require processing prior to establishing the RFB connection. 418 To best integrate with other applications the VNC client SHOULD 419 initiate the connection with minimal or no user intervention, 420 whenever sufficient information is available and adequate security 421 is preserved. 423 Host information and parameter values may be provided through 424 connection profiles. When a parameter value is not available from 425 either a URI or a connection profile described in Section 2.2.2, the 426 default value specified in Section 2.1.1 should be applied. If 427 available parameters are not sufficient to establish a connection, 428 the VNC client SHOULD present a session initiation data-entry 429 screen. Canceling the dialog or ending the session SHOULD terminate 430 the application. 432 2.2.1. Error Handling 434 If an error prevents a session from being established, the VNC 435 client MUST present an error message to the user. When the message 436 is acknowledged, the console application MAY show a session 437 initiation data-entry screen populated with available session 438 parameters or it MAY terminate. If an error occurs after a session 439 is successfully established which terminates the connection, the VNC 440 client MUST present a termination notification to the user. When 441 the termination notification is acknowledged, the client MAY present 442 a reconnection prompt or MAY terminate. 444 2.2.2. Connection Profile Matching 446 VNC clients MAY store remote desktop session settings in connection 447 profiles. If the client is able to uniquely identify and associate 448 a connection request with a connection profile based on the 449 "ConnectionName" parameter value, remote host IP address, or 450 hostname/fully-qualified domain name, the VNC client SHOULD apply 451 profile values for those settings which do not have values supplied 452 in the "vnc" URI. When profile data is unavailable, the VNC client 453 MAY apply global application defaults for settings not supplied in 454 the URI and for which the scheme does not specify a default value. 455 The VNC client MUST NOT override supplied parameters with profile 456 values or global defaults. 458 When the "SaveConnection" parameter value is true, a connection 459 profile SHOULD be created or updated with the values supplied in the 460 "vnc" URI. Profile updates and storage should be consistent with 461 the recommendations in Section 3.4. 463 2.3. Integrated Security Types 465 2.3.1. The "Integrated SSH" Security Type 467 The "Integrated SSH" security type is establishes an SSH connection 468 to a host, authenticates with SSH password authentication, 469 establishes a secure tunnel to the VNC host/port, and then connects 470 to the VNC server using "VNC Authentication". The secure tunnel 471 will provide encryption and data integrity, while verifying the 472 public key authenticates the server. The SSH architecture is 473 specified in [RFC4251]. The steps are detailed below: 475 1. The VNC client initiates a transport-level connection to the 476 "SshHost" on the "SshPort" specified in the parameter values with 477 a key exchange as described in [RFC4253]. 479 2. When the VNC client receives the server key (or certificate), the 480 hash of the key (or certificate) is computed using the algorithm 481 corresponding to the "IdHashAlgorithm" parameter value and 482 compared with the expected "IdHash" value (if available). If the 483 certificate hash cannot be verified, the client MUST alert the 484 user. The alert MUST provide the remote system's identifying 485 information including the hash value and allow the user to 486 terminate the connection. The alert MAY allow the user to accept 487 the key and continue establishing the connection. 489 3. The SSH client authenticates the user using the "SshUsername" and 490 "SshPassword" parameter values according to the "password" 491 authentication mechanism described in [RFC4252]. 493 4. The SSH client opens a TCP/IP channel as specified in [RFC4254] 494 from the local system to the system indicated by the and 495 information values. 497 5. The VNC client establishes a RFB connection to the VNC server 498 over the channel and authenticates using VNC Security as 499 described in [RFC6143] and the "VncPassword" parameter. 501 The VNC client MAY establish the connection described in this 502 section using an external SSH client, by launching the client and 503 then connecting to a secure tunnel created between a local port and 504 the VNC server. 506 If the VNC client is supplied with additional parameters outside the 507 scope of this document, it MAY perform a variation of these steps 508 consistent with the underlying protocols, for example by using 509 "publickey" SSH client authentication [RFC4252] or providing another 510 form of authentication to the VNC server. The specific negotiation 511 of SSH parameters such as cipher suite configuration is outside the 512 scope of this document. 514 Many SSH clients present key hashes using MD5 and it can be expected 515 that launching applications MAY specify the hash be displayed in the 516 manner its users are familiar with. 518 2.3.2. The "Secure Tunnel" Security Type 520 The "Secure Tunnel" security type establishes a TLS connection with 521 a remote server using certificate authentication, over which a 522 connection to the VNC server is established using "VNC 523 Authentication". The secure tunnel will provide encryption and data 524 integrity, while verifying the certificate authenticates the server. 525 The TLS protocol is specified in [RFC5246]. The steps are detailed 526 below: 528 1. The VNC client initiates the TLS Handshake Protocol with a system 529 indicated by the and information values. 531 2. When the server certificate is received, the hash of the key 532 certificate is computed using the algorithm corresponding to the 533 "IdHashAlgorithm" parameter value and compared with the expected 534 "IdHash" value (if available). If the certificate hash cannot be 535 verified, the client MUST alert the user. The alert MUST provide 536 the remote system's identifying information and allow the user to 537 terminate the connection. The alert MAY allow the user to accept 538 the key and continue establishing the connection. 540 When providing identifying information of a host identified by an 541 X509 certificate [RFC5280], the certificate subject, issuer, 542 validity period, and certificate hash MUST be included. The VNC 543 client MAY verify the validity of the certificate. If the 544 validity of a certificate is not determined, the console 545 application MUST include a statement indicating such information 546 has not been verified. 548 3. The client finishes establishing the TLS tunnel. 550 4. The VNC client establishes a RFB connection to the VNC server 551 over the channel and authenticates using VNC Security as 552 described in [RFC6143] and the "VncPassword" parameter. 554 If the VNC client is supplied with additional parameters, it may 555 perform a variation of these steps consistent with the underlying 556 protocols, for example by providing another form of authentication 557 to the VNC server. The negotiation of specific TLS parameters such 558 as cipher suite configuration are outside the scope of this 559 document. 561 The TLS protocol provides backwards compatibility with SSLv3, 562 however due to known security flaws it SHOULD NOT be used. 564 3. Security Considerations 566 General security concerns involving URI schemes are discussed in 567 [RFC3986]. In implementing support for the "vnc" URI scheme, areas 568 for particular consideration include application trust, URI 569 transmission, host identification, and connection database security. 571 Remote desktop connectivity requires the transmission of security 572 credentials, which may be included in a URI. If those credentials 573 are not kept secure, an attacker may gain access to any systems 574 using those credentials. Host addresses and connection parameters 575 may also be considered sensitive, as such information can be used in 576 planning an attack. 578 URIs can also contain host identification information. It is 579 important to securely identify the remote host system connected to. 580 If a user connects to an attacker's system, user data, including 581 credentials, may be exposed. 583 Note that the RFB protocol itself does not encrypt data. To protect 584 data in transit, RFB should be tunneled over TLS [RFC5246], SSH 585 [RFC4251], or another secure protocol. 587 Some VNC systems can be used without authentication. To protect the 588 remote host, strong passwords or other authentication mechanisms 589 should be used. 591 3.1. Application Trust 593 A malicious application receiving VNC credentials via URI or other 594 means can obviously misuse those credentials. To protect against 595 this, users should only install applications from trusted sources. 596 The integrity of application packages can be verified through 597 digital signatures. 599 Applications launching VNC clients MAY wish to launch only 600 particular trusted clients, and can specify those clients through 601 platform-specific mechanisms. Package integrity can be verified 602 programmatically by querying the package manager for digital 603 signatures or other platform-specific means. 605 The risk to a VNC client from a launching application is generally 606 much lower, since the launching application will not receive 607 credentials or data from the client. A VNC client MAY verify its 608 caller thorough platform-specific means. 610 VNC clients SHOULD NOT accept potentially destructive parameters 611 from untrusted launching applications without explicit user 612 confirmation. For example, a client-specific parameter that runs an 613 arbitrary command upon establishing a SSH connection used for VNC 614 tunneling is potentially destructive and high risk. 616 3.2. URI Transmission 618 Within a mobile or desktop environment, application launch will 619 typically involve in-memory URI data transmission facilitated and 620 secured by the OS. 622 If sensitive URI information is exchanged across a network, for 623 example by providing a list of connection URIs in a web page, the 624 data should be encrypted in transit and only be accessible to 625 authorized users. 627 3.3. Host Identification 629 In the absence of verifiable host identification, a VNC client 630 application is vulnerable to spoofing and man-in-the-middle attacks 631 which capture VNC or host OS credentials and user data. To prevent 632 such attacks, administrators SHOULD secure their VNC communications 633 with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection 634 mechanisms identifying remote hosts via certificate or public key. 635 VNC clients MUST verify the respective certificates or public keys 636 to confirm the remote host's identity. 638 An application launching a VNC client via URI MAY provide a 639 certificate hash or public key hash identifying the remote host. 640 VNC clients maintaining a connection database MAY also store 641 certificate or public key data suitable for validating a host's 642 identity. 644 If connecting to a system identified by certificate or public key 645 and a remote system ID hash cannot be matched to available 646 identifying data, the VNC client MUST alert the user. The alert 647 MUST provide the remote system's identifying information and allow 648 the user to terminate the connection. The alert MAY allow the user 649 to accept the information and continue establishing the connection. 651 When providing identifying information of a host identified by an 652 X509 certificate [RFC5280], the certificate subject, issuer, 653 validity period, and certificate hash MUST be included. The VNC 654 client MAY verify the certificate validity. If the validity of a 655 certificate is not determined, the console application MUST include 656 a statement indicating such information has not been verified. 658 Identifying information of a host identified by public key, such as 659 the endpoint of an SSH connection using a raw key, MUST include a 660 hash of the key. 662 3.4. Connection Database Integrity 664 A VNC client application and/or launching application MAY maintain a 665 connection database containing remote host information, credentials, 666 and/or connection parameters. Applications MUST NOT store 667 credentials unless the credentials are stored in an encrypted format 668 with a decryption process requiring user-supplied or device-specific 669 data. If supported, an application SHOULD have a setting disabling 670 storage of credentials. 672 If available, the VNC client connection database SHOULD store 673 certificate or public key data used to verify host identification. 674 To prevent a malicious URI from overriding the database, if 675 identification information in the URI conflicts with information in 676 the database, the user MUST be prompted to accept the new 677 information prior to updating the database. 679 4. IANA Considerations 681 The "vnc" scheme should be registered in the URI schemes registry. 683 The IANA "Remote Framebuffer Security Types", "VNC ID Hash 684 Algorithms", and "VNC URI Parameters" registries support elements of 685 the scheme. Future assignments to these registries should be made 686 through the "Expert Review" or "IESG Approval" process described in 687 [RFC5226]. 689 4.1. "vnc" Scheme 691 The "vnc" scheme should be listed in the URI schemes registry with 692 description "Remote Framebuffer Protocol" and reference to this 693 document. A registration template is provided in Appendix A. 695 The IANA schemes registry is currently located at: 697 http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml 699 4.2. Remote Framebuffer Security Types 701 This document references the existing IANA "Remote Framebuffer 702 Security Types" registry in specifying security type options. The 703 registry includes entries for the "Secure Tunnel" and "Integrated 704 SSH" security types described in this document and should refer to 705 this document. 707 Future RFB security types will be supported in "vnc" URIs. Any new 708 security mechanism integrated with a VNC client which alters the 709 process by which a connection is established should also be 710 reflected in the registry to avoid overlapping numeric assignments. 712 This applies even if the mechanism does not involve a change to the 713 VNC server implementation or RFB protocol itself. For example, the 714 "Secure Tunnel" security type does not require RFB modification, but 715 indicates to the client that it must establish a TLS tunnel prior to 716 initiating RFB communications. Without inclusion in the registry, a 717 URI-launched client will be unable to distinguish future client- 718 initiated and protocol-based security mechanisms. 720 4.3. VNC ID Hash Algorithms 722 The ID hash algorithms should be maintained in a "VNC ID Hash 723 Algorithms" sub-registry within the "Remote Framebuffer (RFB)" 724 protocol registry. The registry should include the enumeration 725 value, description, and reference document/contact person. 727 The initial hash algorithms specified are a subset of the algorithms 728 contained in the "TLS HashAlgorithm Registry". The initial contents 729 of the registry are: 731 Value Description Reference 732 -------- ------------ --------------- 733 1 MD5 (this document) 734 2 SHA1 (this document) 735 4 SHA256 (this document) 737 4.4. VNC URI Parameters 739 The URI parmeters should be maintained in a "VNC URI Parameters" 740 sub-registry within the "Remote Framebuffer (RFB)" protocol 741 registry. 743 The initial contents are described in this document. They are: 745 +-----------------+-----------------------------+-----------------+ 746 | Name | Description | Reference | 747 +-----------------+-----------------------------+-----------------+ 748 | ConnectionName | Name of connection profile | (this document) | 749 +-----------------+-----------------------------+-----------------+ 750 | VncUsername | VNC server username | (this document) | 751 +-----------------+-----------------------------+-----------------+ 752 | VncPassword | VNC server password | (this document) | 753 +-----------------+-----------------------------+-----------------+ 754 | SecurityType | VNC security type used | (this document) | 755 +-----------------+-----------------------------+-----------------+ 756 | SshHost | SSH server hostname or IP | (this document) | 757 +-----------------+-----------------------------+-----------------+ 758 | SshPort | SSH server port | (this document) | 759 +-----------------+-----------------------------+-----------------+ 760 | SshUsername | SSH username | (this document) | 761 +-----------------+-----------------------------+-----------------+ 762 | SshPassword | SSH password | (this document) | 763 +-----------------+-----------------------------+-----------------+ 764 +-----------------+-----------------------------+-----------------+ 765 | IdHashAlgorithm | Hash algorithm used with | (this document) | 766 | | "IdHash" parameter | | 767 +-----------------+-----------------------------+-----------------+ 768 | IdHash | Expected hash of remote | (this document) | 769 | | public key or certificate | | 770 +-----------------+-----------------------------+-----------------+ 771 | ColorLevel | Client color depth/mode | (this document) | 772 +-----------------+-----------------------------+-----------------+ 773 | ViewOnly | Client is view only | (this document) | 774 +-----------------+-----------------------------+-----------------+ 775 | SaveConnection | Store connection info | (this document) | 776 +-----------------+-----------------------------+-----------------+ 778 5. References 780 5.1. Normative References 782 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 783 April 1992. 785 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 786 Requirement Levels", BCP 14, RFC 2119, March 1997. 788 [RFC3629] Yergeau, F., "UTF-8, a transformation format of 789 ISO 10646", STD 63, RFC 3629, November 2003. 791 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 792 Resource Identifier (URI): Generic Syntax", STD 66, RFC 793 3986, January 2005. 795 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 796 Protocol Architecture", RFC 4251, January 2006. 798 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 799 Authentication Protocol", RFC 4252, January 2006. 801 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 802 Transport Layer Protocol", RFC 4253, January 2006. 804 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 805 Connection Protocol", RFC 4254, January 2006. 807 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 808 Syntax Specifications: ABNF", STD 68, RFC 5234, January 809 2008. 811 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 812 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 814 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 815 Housley, R., and W. Polk, "Internet x.509 Public Key 816 Infrastructure Certificate and Certificate Revocation List 817 (CRL) Profile", RFC 5280, May 2008. 819 [RFC6143] Richardson, T., and J. Levine, "The Remote Framebuffer 820 Protocol", RFC 6143, March 2011. 822 [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National 823 Institute of Standards and Technology, U.S. Department of 824 Commerce, August 2002. 826 5.2. Informative References 828 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 829 Registration Procedures for New URI Schemes", BCP 35, RFC 830 4395, February 2006. 832 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 833 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 834 May 2008. 836 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 837 Information technology - Open Systems Interconnection - 838 The Directory: Public-key and attribute certificate 839 frameworks. 841 6. Acknowledgments 843 RFB and VNC are registered trademarks of RealVNC Ltd. in the U.S. 844 and in other countries. 846 This document was prepared using 2-Word-v2.0.template.dot. 848 Appendix A. "vnc" URI Template 850 This template is provided for registration of the VNC URI in the 851 IANA URI schemes registry as specified in [RFC4395]. 853 URI Scheme name: vnc 855 Status: Permanent 857 URI scheme syntax: See Section 2 of this document. 859 Scheme semantics: See Section 2 of this document. 861 Encoding considerations: See Section 2 of this document. 863 Applications/protocols that use this URI scheme name: Virtual 864 Network Computing (VNC) remote desktop applications use vnc URIs. 865 VNC applications use the Remote Framebuffer (RFB) protocol. 867 Interoperability considerations: Legacy software applications 868 respond to vnc URIs in different ways and may fail to behave as 869 expected. It is advisable to test vnc URIs with specific 870 applications or consult application-specific documentation. 872 Security considerations: See Section 3 of this document. 874 Contact: IETF Applications Area Directors 876 Author/Change Controller: See the Authors of this document. Change 877 control is through the IESG on behalf of the IETF iesg@ietf.org. 879 References: This document. 881 Authors' Addresses 883 David Warden 884 Dell Products LP 885 200 Dell Way 886 Round Rock, Texas 78682 887 U.S.A. 889 Phone: 512-728-0380 890 Email: David_Warden@dell.com 891 URI: http://www.dell.com 893 Iordan Iordanov 894 Undatech 895 260 Scarlet Road, Apt. 503 896 Toronto, ON M6N 4X6 897 CANADA 899 Email: iiordanov@gmail.com