idnits 2.17.1 draft-warden-appsawg-vnc-scheme-00.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 (March 24, 2015) is 3321 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: September 2015 Undatech 5 March 24, 2015 7 The "vnc" URI Scheme 8 draft-warden-appsawg-vnc-scheme-00.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 August 27, 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................................10 68 2.3.1. The "Integrated SSH" Security Type..................10 69 2.3.2. The "Secure Tunnel" Security Type...................11 70 3. Security Considerations.......................................12 71 3.1. Application Trust........................................13 72 3.2. URI Transmission.........................................13 73 3.3. Host Identification......................................14 74 3.4. Connection Database Integrity............................14 75 4. IANA Considerations...........................................15 76 4.1. "vnc" Scheme.............................................15 77 4.2. Remote Framebuffer Security Types........................15 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...............................................18 84 Appendix A. "vnc" URI Template...................................19 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 rules are 132 defined in [RFC3986]. 134 vnc-uri = "vnc://" [ host [ ":" port ] ] [ "?" [ vnc-params ] ] 136 vnc-params = param "=" value *("&" param "=" value) ["&"] 138 param = 1*( param-char ) 140 value = *( param-char ) 141 param-char = unreserved / pct-encoded / unreserved-symbols 143 unreserved-symbols = ":" / "/" / "#" / "[" / "]" / "@" / "!" / 145 "$" / "'" / "(" / ")" / "*" / "," / ";" 147 The "?", "=", and "&" characters are used to delimit VNC parameters 148 and must be percent-encoded when representing a data octet as 149 specified in [RFC3986]. Within the portion of a "vnc" 150 URI the do not have special meaning and need 151 not be percent-encoded when representing a data octet. 153 A "vnc" URI has the general form: 155 vnc://host:port?parm1=value1¶m2=value2... 157 The host information and each parameter value specify information 158 used in establishing or operating the remote desktop session as 159 specified in Section 2.1.1. 161 For example: 163 vnc://10.0.0.1:5901?VncPassword=secret&SecurityType=2 165 Indicates a vnc connection to the host at IP "10.0.0.1" on port 166 "5901" with VNC password "secret" using VNC security. 168 2.1.1. URI Parameters 170 A description of host information and URI parameters is provided in 171 this section. Information on the constraints of various data types 172 is provided in Section 2.1.2. All parameters are considered 173 optional, however a client will not be able to connect without 174 sufficient information. 176 The and values in the "vnc" URI specify the address of 177 the VNC server on the remote host: 179 +------------+------------+-----------------------------+----------+ 180 | Name | Type | Description | Default | 181 +------------+------------+-----------------------------+----------+ 182 | host | string | VNC server hostname or IP | | 183 +------------+------------+-----------------------------+----------+ 184 | port | ushort | VNC server port | 5900 | 185 +------------+------------+-----------------------------+----------+ 186 The "vnc" URI parameter values specify remote desktop connection or 187 session properties, including aspects of client operation, 188 usability, and security as specified in the table below: 190 +---------------+---------+-----------------------------+----------+ 191 | Name | Type | Description | Default | 192 +---------------+---------+-----------------------------+----------+ 193 |ConnectionName | string | Name of connection profile | | 194 +---------------+---------+-----------------------------+----------+ 195 |VncUsername | string | VNC server username | | 196 +---------------+---------+-----------------------------+----------+ 197 |VncPassword | string | VNC server password | | 198 +---------------+---------+-----------------------------+----------+ 199 |SecurityType | enum | VNC security type used | 2 | 200 | | | |(VNC Auth)| 201 +---------------+---------+-----------------------------+----------+ 202 |SshHost | string | SSH server hostname or IP | | 203 +---------------+---------+-----------------------------+----------+ 204 |SshPort | ushort | SSH server port | 22 | 205 +---------------+---------+-----------------------------+----------+ 206 |SshUsername | string | SSH username | | 207 +---------------+---------+-----------------------------+----------+ 208 |SshPassword | string | SSH password | | 209 +---------------+---------+-----------------------------+----------+ 210 |IdHashAlgorithm| enum | Hash algorithm used with | 2 | 211 | | | "IdHash" parameter | (SHA1) | 212 +---------------+---------+-----------------------------+----------+ 213 |IdHash | string | Expected hash of remote | | 214 | | | public key or certificate | | 215 +---------------+---------+-----------------------------+----------+ 216 |ColorModel | enum | Client color depth/mode | 7 | 217 | | | | (24-bit) | 218 +---------------+---------+-----------------------------+----------+ 219 |ViewOnly | boolean | Client is view only | false | 220 +---------------+---------+-----------------------------+----------+ 221 |SaveConnection | boolean | Store connection info | true | 222 +---------------+---------+-----------------------------+----------+ 223 |LaunchKey | string | Caller identification | | 224 +---------------+---------+-----------------------------+----------+ 226 o ConnectionName, SaveConnection 228 The "ConnectionName" is used to identify a connection profile in 229 both the launching application and VNC client. Profiles are 230 applied as described in Section 2.2.2. If omitted, the client 231 MAY generate a name based on the host, port, and/or other 232 parameters. The VNC client MAY normalize the name as required. 234 If true, "SaveConnection" indicates a connection profile should 235 be created or updated and stored in the client connection 236 database. If false, no profile should be updated or persisted. 238 o VncUsername, VncPassword, SecurityType 240 The SecurityType parameter indicates which RFB security type 241 applies to the connection. VNC security types are recorded in 242 the IANA "Remote Framebuffer Security Types" registry created by 243 [RFC6143]. The VNC client will use this information to determine 244 which parameters are required and establish the connection. 246 The "VncUsername" and "VncPassword" are used when applicable to 247 authenticate to the VNC server using the specified 248 "SecurityType". 250 o SshHost, SshPort, SshUsername, SshPassword 252 The SSH parameters are intended for use with the "Integrated SSH" 253 security type described in Section 2.3.1. These parameters can 254 also be used with any future SSH-based security types. 256 o IdHashAlgorithm, IdHash 258 The "IdHashAlgorithm" and "IdHash" values are used to verify the 259 expected identity of the remote system based on its public key or 260 certificate. Use of these values in the context of the 261 "Integrated SSH" and "Secure Tunnel" security types is provided 262 in Section 2.3. 264 o ColorModel 266 The "ColorModel" parameter specifies the color model to use for 267 data transfer and display as specified in Section 2.1.2. If the 268 requested color model is unsupported, the VNC client SHOULD 269 select the supported color model closest to the requested model 270 among those having higher color fidelity. If no supported models 271 have higher fidelity, it SHOULD select the model having the 272 highest fidelity available. 274 o ViewOnly 276 If true, the VNC client should operate in a display-only mode and 277 refrain from sending input data including KeyEvent, PointerEvent, 278 and ClientCutText messages specified in Section 7.5 of [RFC6143]. 280 o LaunchKey 282 If provided, the launch key MAY be used by a client to enable 283 licensed features. The key can help identify a launching 284 application for greater security, however if used to enable 285 security-sensitive parameters, the VNC client SHOULD perform 286 additional verification. 288 Parameter names and values shall be interpreted in a case sensitive 289 manner, unless otherwise noted. 291 Additional parameters likely to be useful with multiple VNC clients 292 can be added to the "VNC URI Parameters" registry as specified in 293 Section 4.4 of this document. Individual clients MAY support 294 parameters specific to that client. VNC Clients supporting 295 application-specific parameters SHOULD include a distinguishing 296 prefix within the parameter name, such as the name of the 297 application package specified in source code. For example: 299 vnc://?com.dell.vncclient.ScreenMode=2& 301 It can also be expected that clients will maintain backward 302 compatibility with legacy URI formats and parameters. 304 2.1.2. Data Types 306 As "vnc" URIs may be percent-encoded as specified in [RFC3986] and 307 must be decoded. After decoding, the following type constraints and 308 semantics apply: 310 o string 312 Values of "string" type are UTF-encoded strings as specified in 313 [RFC3629]. 315 The "string" subtype used in the "IdHash" consists of colon- 316 delimited ":" octets displayed in hexadecimal. For example: 318 5D:D2:39:57 320 Comparison of "string" values shall be case-insensitive, 321 however the uppercase notation is preferred for readability. 323 o enum 325 The "enum" types consist of specific enumerated subtypes and are 326 represented by their decimal index value. 328 The "enum" values represent a VNC security type included 329 in the IANA "Remote Framebuffer Security Types" registry created 330 by [RFC6143]. 332 Values of the "enum" parameter represent secure hash 333 algorithms in the "VNC Hash Algorithms" registry created by 334 Section 4.3 of this document. The initial values include: 336 Value Description 337 -------- ------------ 338 1 MD5 339 2 SHA1 340 4 SHA256 342 The MD5 algorithm is described in [RFC1321]. The SHA1 and SHA256 343 algorithms are described in [SHS]. 345 Values of the "enum" subtype represent a color model. In 346 the table below, the columns have the meaning specified in 347 Section 7.4 of [RFC6143]: 349 BPP = bits-per-pixel 350 TC = true-color-flag 351 RM = red-max 352 GM = green-max 353 BM = blue-max 354 RS = red-shift 355 GS = green-shift 356 BS = blue-shift 358 The values are: 360 Value Description BPP Depth TC RM GM BM RS GS BS 361 ----- --------------- --- ----- -- ---- ---- ---- -- -- -- 362 1 Black and White 8 3 t 1 1 1 2 1 0 363 2 Greyscale 8 6 t 3 3 3 4 2 0 364 3 8 Colors 8 3 t 1 1 1 2 1 0 365 4 64 Colors 8 6 t 3 3 3 4 2 0 366 5 256 Colors 8 8 t 7 7 3 0 3 6 367 6 16-bit Color 16 16 t 31 63 31 11 5 0 368 7 24-bit Color 32 24 t 255 255 255 16 8 0 369 8 30-bit Color 32 30 t 1023 1023 1023 0 10 20 371 A value of "t" indicates the true-color-flag should be set, the 372 big-endian-flag should be set as required for the system. 374 o ushort 376 The "ushort" values represent unsigned 16-bit integers expressed 377 in decimal digits with value between 0-65535 inclusive. 379 o boolean 381 "boolean" values represent conditions that are true or false and 382 are represented as either "true" or "false" respectively. For 383 maximum compatibility, clients SHOULD accept the value "1" as 384 representing true values and "0" as representing false values. 385 Clients SHOULD perform parsing of "boolean" values in a case 386 insensitive manner. 388 An example "vnc" URI including several of these data types is: 390 vnc://localhost:5900?ConnectionName=Server&SecurityType=2& 391 IdHash=0D:3A:72:08:57:EA:4D:30&SaveConnection=false& 393 2.2. Processing URIs 395 In general, when a VNC client receives a "vnc" URI it will initiate 396 an RFB protocol remote desktop connection using the specified host 397 information and parameter values. Initiating the connection using 398 an integrated security mechanism such as those specified in Section 399 2.3 may require processing prior to establishing the RFB connection. 400 To best integrate with other applications the VNC client SHOULD 401 initiate the connection with minimal or no user intervention, 402 whenever sufficient information is available and adequate security 403 is preserved. 405 Host information and parameter values may be provided through 406 connection profiles. When a parameter value is not available from 407 either a URI or a connection profile described in Section 2.2.2, the 408 default value specified in Section 2.1.1 should be applied. If 409 available parameters are not sufficient to establish a connection, 410 the VNC client SHOULD present a session initiation data-entry 411 screen. Canceling the dialog or ending the session SHOULD terminate 412 the application. 414 2.2.1. Error Handling 416 If an error prevents a session from being established, the VNC 417 client MUST present an error message to the user. When the message 418 is acknowledged, the console application MAY show a session 419 initiation data-entry screen populated with available session 420 parameters or it MAY terminate. If an error occurs after a session 421 is successfully established which terminates the connection, the VNC 422 client MUST present a termination notification to the user. When 423 the termination notification is acknowledged, the client MAY present 424 a reconnection prompt or MAY terminate. 426 2.2.2. Connection Profile Matching 428 VNC clients MAY store remote desktop session settings in connection 429 profiles. If the client is able to uniquely identify and associate 430 a connection request with a connection profile based on the 431 "ConnectionName" parameter value, remote host IP address, or 432 hostname/fully-qualified domain name, the VNC client SHOULD apply 433 profile values for those settings which do not have values supplied 434 in the "vnc" URI. When profile data is unavailable, the VNC client 435 MAY apply global application defaults for settings not supplied in 436 the URI and for which the scheme does not specify a default value. 437 The VNC client MUST NOT override supplied parameters with profile 438 values or global defaults. 440 When the "SaveConnection" parameter value is true, a connection 441 profile SHOULD be created or updated with the values supplied in the 442 "vnc" URI. Profile updates and storage should be consistent with 443 the recommendations in Section 3.4. 445 2.3. Integrated Security Types 447 2.3.1. The "Integrated SSH" Security Type 449 The "Integrated SSH" security type is establishes an SSH connection 450 to a host, authenticates with SSH password authentication, 451 establishes a secure tunnel to the VNC host/port, and then connects 452 to the VNC server using "VNC Authentication". The secure tunnel 453 will provide encryption and data integrity, while verifying the 454 public key authenticates the server. The SSH architecture is 455 specified in [RFC4251]. The steps are detailed below: 457 1. The VNC client initiates a transport-level connection to the 458 "SshHost" on the "SshPort" specified in the parameter values with 459 a key exchange as described in [RFC4253]. 461 2. When the VNC client receives the server key (or certificate), the 462 hash of the key (or certificate) is computed using the algorithm 463 corresponding to the "IdHashAlgorithm" parameter value and 464 compared with the expected "IdHash" value (if available). If the 465 certificate hash cannot be verified, the client MUST alert the 466 user. The alert MUST provide the remote system's identifying 467 information including the hash value and allow the user to 468 terminate the connection. The alert MAY allow the user to accept 469 the key and continue establishing the connection. 471 3. The SSH client authenticates the user using the "SshUsername" and 472 "SshPassword" parameter values according to the "password" 473 authentication mechanism described in [RFC4252]. 475 4. The SSH client opens a TCP/IP channel as specified in [RFC4254] 476 from the local system to the system indicated by the and 477 information values. 479 5. The VNC client establishes a RFB connection to the VNC server 480 over the channel and authenticates using VNC Security as 481 described in [RFC6143] and the "VncPassword" parameter. 483 The VNC client MAY establish the connection described in this 484 section using an external SSH client, by launching the client and 485 then connecting to a secure tunnel created between a local port and 486 the VNC server. 488 If the VNC client is supplied with additional parameters outside the 489 scope of this document, it MAY perform a variation of these steps 490 consistent with the underlying protocols, for example by using 491 "publickey" SSH client authentication [RFC4252] or providing another 492 form of authentication to the VNC server. 494 While the SHA1 hash algorithm is the default, many SSH clients 495 present key hashes using MD5 and it can be expected that launching 496 applications MAY specify the hash be displayed in the manner its 497 users are familiar with. 499 2.3.2. The "Secure Tunnel" Security Type 501 The "Secure Tunnel" security type establishes a TLS connection with 502 a remote server using certificate authentication, over which a 503 connection to the VNC server is established using "VNC 504 Authentication". The secure tunnel will provide encryption and data 505 integrity, while verifying the certificate authenticates the server. 506 The TLS protocol is specified in [RFC5246]. The steps are detailed 507 below: 509 1. The VNC client initiates the TLS Handshake Protocol with a system 510 indicated by the and information values. 512 2. When the server certificate is received, the hash of the key 513 certificate is computed using the algorithm corresponding to the 514 "IdHashAlgorithm" parameter value and compared with the expected 515 "IdHash" value (if available). If the certificate hash cannot be 516 verified, the client MUST alert the user. The alert MUST provide 517 the remote system's identifying information and allow the user to 518 terminate the connection. The alert MAY allow the user to accept 519 the key and continue establishing the connection. 521 When providing identifying information of a host identified by an 522 X509 certificate [x.509], the certificate subject, issuer, 523 validity period, and certificate hash MUST be included. The VNC 524 client MAY give users the option of verifying the certificate 525 name, certificate authority, certificate revocation list, and 526 validity period. If information on the validity of a certificate 527 is not displayed, the console application MUST include a 528 statement indicating such information has not been verified. 530 3. The client finishes establishing the TLS tunnel. 532 4. The VNC client establishes a RFB connection to the VNC server 533 over the channel and authenticates using VNC Security as 534 described in [RFC6143] and the "VncPassword" parameter. 536 If the VNC client is supplied with additional parameters, it may 537 perform a variation of these steps consistent with the underlying 538 protocols, for example by providing another form of authentication 539 to the VNC server. 541 Since the TLS protocol provides backwards compatibility with SSLv3, 542 and SSL tunnel MAY be used if supported. 544 3. Security Considerations 546 General security concerns involving URI schemes are discussed in 547 [RFC3986]. In implementing support for the "vnc" URI scheme, areas 548 for particular consideration include application trust, URI 549 transmission, host identification, and connection database security. 551 Remote desktop connectivity requires the transmission of security 552 credentials, which may be included in a URI. If those credentials 553 are not kept secure, an attacker may gain access to any systems 554 using those credentials. Host addresses and connection parameters 555 may also be considered sensitive, as such information can be used in 556 planning an attack. 558 URIs can also contain host identification information. It is 559 important to securely identify the remote host system connected to. 560 If a user connects to an attacker's system, user data, including 561 credentials, may be exposed. 563 Note that the RFB protocol itself does not encrypt data. To protect 564 data in transit, RFB should be tunneled over TLS [RFC5246], SSH 565 [RFC4251], or another secure protocol. 567 Some VNC systems can be used without authentication. To protect the 568 remote host, strong passwords or other authentication mechanisms 569 should be used. 571 3.1. Application Trust 573 A malicious application receiving VNC credentials via URI or other 574 means can obviously misuse those credentials. To protect against 575 this, users should only install applications from trusted sources. 576 The integrity of application packages can be verified through 577 digital signatures. 579 Applications launching VNC clients MAY wish to launch only 580 particular trusted clients, and can specify those clients through 581 platform-specific mechanisms. Package integrity can be verified 582 programmatically by querying the package manager for digital 583 signatures or other platform-specific means. 585 The risk to a VNC client from a launching application is generally 586 much lower, since the launching application will not receive 587 credentials or data from the client. A VNC client MAY verify its 588 caller thorough platform-specific means. 590 VNC clients SHOULD NOT accept potentially destructive parameters 591 from untrusted launching applications without explicit user 592 confirmation. For example, a client-specific parameter that runs an 593 arbitrary command upon establishing a SSH connection used for VNC 594 tunneling is potentially destructive and high risk. 596 3.2. URI Transmission 598 Within a mobile or desktop environment, application launch will 599 typically involve in-memory URI data transmission facilitated and 600 secured by the OS. 602 If sensitive URI information is exchanged across a network, for 603 example by providing a list of connection URIs in a web page, the 604 data should be encrypted in transit and only be accessible to 605 authorized users. 607 3.3. Host Identification 609 In the absence of verifiable host identification, a VNC client 610 application is vulnerable to spoofing and man-in-the-middle attacks 611 which capture VNC or host OS credentials and user data. To prevent 612 such attacks, administrators SHOULD secure their VNC communications 613 with TLS [RFC5246] or SSH [RFC4251] tunnels or other connection 614 mechanisms identifying remote hosts via certificate or public key. 615 VNC clients MUST verify the respective certificates or public keys 616 to confirm the remote host's identity. 618 An application launching a VNC client via URI MAY provide a 619 certificate hash or public key hash identifying the remote host. 620 VNC clients maintaining a connection database MAY also store 621 certificate or public key data suitable for validating a host's 622 identity. 624 If connecting to a system identified by certificate or public key 625 and a remote system ID hash cannot be matched to available 626 identifying data, the VNC client MUST alert the user. The alert 627 MUST provide the remote system's identifying information and allow 628 the user to terminate the connection. The alert MAY allow the user 629 to accept the information and continue establishing the connection. 631 When providing identifying information of a host identified by an 632 X509 certificate [x.509], the certificate subject, issuer, validity 633 period, and certificate hash MUST be included. The VNC client MAY 634 give users the option of verifying the certificate name, certificate 635 authority, certificate revocation list, and validity period. If 636 information on the validity of a certificate is not displayed, the 637 console application MUST include a statement indicating such 638 information has not been verified. 640 Identifying information of a host identified by public key, such as 641 the endpoint of an SSH connection using a raw key, MUST include a 642 hash of the key. 644 3.4. Connection Database Integrity 646 A VNC client application and/or launching application MAY maintain a 647 connection database containing remote host information, credentials, 648 and/or connection parameters. Applications MUST NOT store 649 credentials unless the credentials are stored in an encrypted format 650 with a decryption process requiring user-supplied or device-specific 651 data. If supported, an application SHOULD have a setting disabling 652 storage of credentials. 654 If available, the VNC client connection database SHOULD store 655 certificate or public key data used to verify host identification. 656 To prevent a malicious URI from overriding the database, if 657 identification information in the URI conflicts with information in 658 the database, the user MUST be prompted to accept the new 659 information prior to updating the database. 661 4. IANA Considerations 663 The "vnc" scheme should be registered in the URI schemes registry. 665 The IANA "Remote Framebuffer Security Types", "VNC ID Hash 666 Algorithms", and "VNC URI Parameters" registries support elements of 667 the scheme. Future assignments to these registries should be made 668 through the "Expert Review" or "IESG Approval" process described in 669 [RFC5226]. 671 4.1. "vnc" Scheme 673 The "vnc" scheme should be listed in the URI schemes registry with 674 description "Remote Framebuffer Protocol" and reference to this 675 document. A registration template is provided in Appendix A. 677 4.2. Remote Framebuffer Security Types 679 This document references the existing IANA "Remote Framebuffer 680 Security Types" registry in specifying security type options. The 681 registry includes entries for the "Secure Tunnel" and "Integrated 682 SSH" security types described in this document and should refer to 683 this document. 685 Future RFB security types will be supported in "vnc" URIs. Any new 686 security mechanism integrated with a VNC client which alters the 687 process by which a connection is established should also be 688 reflected in the registry to avoid overlapping numeric assignments. 690 This applies even if the mechanism does not involve a change to the 691 VNC server implementation or RFB protocol itself. For example, the 692 "Secure Tunnel" security type does not require RFB modification, but 693 indicates to the client that it must establish a TLS tunnel prior to 694 initiating RFB communications. Without inclusion in the registry, a 695 URI-launched client will be unable to distinguish future client- 696 initiated and protocol-based security mechanisms. 698 4.3. VNC ID Hash Algorithms 700 The ID hash algorithms should be maintained in a "VNC ID Hash 701 Algorithms" sub-registry within the "Remote Framebuffer (RFB)" 702 protocol registry. The registry should include the enumeration 703 value, description, and reference document/contact person. 705 The initial hash algorithms specified are a subset of the algorithms 706 contained in the "TLS HashAlgorithm Registry". The initial contents 707 of the registry are: 709 Value Description Reference 710 -------- ------------ --------------- 711 1 MD5 (this document) 712 2 SHA1 (this document) 713 4 SHA256 (this document) 715 4.4. VNC URI Parameters 717 The URI parmeters should be maintained in a "VNC URI Parameters" 718 sub-registry within the "Remote Framebuffer (RFB)" protocol 719 registry. 721 The initial contents are described in this document. They are: 723 +-----------------+-----------------------------+-----------------+ 724 | Name | Description | Reference | 725 +-----------------+-----------------------------+-----------------+ 726 | ConnectionName | Name of connection profile | (this document) | 727 +-----------------+-----------------------------+-----------------+ 728 | VncUsername | VNC server username | (this document) | 729 +-----------------+-----------------------------+-----------------+ 730 | VncPassword | VNC server password | (this document) | 731 +-----------------+-----------------------------+-----------------+ 732 | SecurityType | VNC security type used | (this document) | 733 +-----------------+-----------------------------+-----------------+ 734 | SshHost | SSH server hostname or IP | (this document) | 735 +-----------------+-----------------------------+-----------------+ 736 | SshPort | SSH server port | (this document) | 737 +-----------------+-----------------------------+-----------------+ 738 | SshUsername | SSH username | (this document) | 739 +-----------------+-----------------------------+-----------------+ 740 | SshPassword | SSH password | (this document) | 741 +-----------------+-----------------------------+-----------------+ 742 +-----------------+-----------------------------+-----------------+ 743 | IdHashAlgorithm | Hash algorithm used with | (this document) | 744 | | "IdHash" parameter | | 745 +-----------------+-----------------------------+-----------------+ 746 | IdHash | Expected hash of remote | (this document) | 747 | | public key or certificate | | 748 +-----------------+-----------------------------+-----------------+ 749 | ColorModel | Client color depth/mode | (this document) | 750 +-----------------+-----------------------------+-----------------+ 751 | ViewOnly | Client is view only | (this document) | 752 +-----------------+-----------------------------+-----------------+ 753 | SaveConnection | Store connection info | (this document) | 754 +-----------------+-----------------------------+-----------------+ 755 | LaunchKey | Caller identification | (this document) | 756 +-----------------+-----------------------------+-----------------+ 758 5. References 760 5.1. Normative References 762 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 763 April 1992. 765 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 766 Requirement Levels", BCP 14, RFC 2119, March 1997. 768 [RFC3629] Yergeau, F., "UTF-8, a transformation format of 769 ISO 10646", STD 63, RFC 3629, November 2003. 771 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 772 Resource Identifier (URI): Generic Syntax", STD 66, RFC 773 3986, January 2005. 775 [RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 776 Protocol Architecture", RFC 4251, January 2006. 778 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 779 Authentication Protocol", RFC 4252, January 2006. 781 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 782 Transport Layer Protocol", RFC 4253, January 2006. 784 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 785 Connection Protocol", RFC 4254, January 2006. 787 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for 788 Syntax Specifications: ABNF", STD 68, RFC 5234, January 789 2008. 791 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 792 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 794 [RFC6143] Richardson, T., and J. Levine, "The Remote Framebuffer 795 Protocol", RFC 6143, March 2011. 797 [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National 798 Institute of Standards and Technology, U.S. Department of 799 Commerce, August 2002. 801 [X.509] ITU-T Recommendation X.509 (2005) | ISO/IEC 9594-8:2005, 802 Information technology - Open Systems Interconnection - 803 The Directory: Public-key and attribute certificate 804 frameworks. 806 5.2. Informative References 808 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 809 Registration Procedures for New URI Schemes", BCP 35, RFC 810 4395, February 2006. 812 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 813 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 814 May 2008. 816 6. Acknowledgments 818 RFB and VNC are registered trademarks of RealVNC Ltd. in the U.S. 819 and in other countries. 821 This document was prepared using 2-Word-v2.0.template.dot. 823 Appendix A. "vnc" URI Template 825 This template is provided for registration of the VNC URI in the 826 IANA URI schemes registry as specified in [RFC4395]. 828 URI Scheme name: vnc 830 Status: Permanent 832 URI scheme syntax: See Section 2 of this document. 834 Encoding considerations: See Section 2 of this document. 836 Applications/protocols that use this URI scheme name: Virtual 837 Network Computing (VNC) remote desktop applications use vnc URIs. 838 VNC applications use the Remote Framebuffer (RFB) protocol. 840 Interoperability considerations: Legacy software applications 841 respond to vnc URIs in different ways and may fail to behave as 842 expected. It is advisable to test vnc URIs with specific 843 applications or consult application-specific documentation. 845 Security considerations: See Section 3 of this document. 847 Contact: IETF Applications Area Directors 849 Author/Change Controller: See the Authors of this document. Change 850 control is through the IESG on behalf of the IETF iesg@ietf.org. 852 References: This document. 854 Authors' Addresses 856 David Warden 857 Dell Products LP 858 200 Dell Way 859 Round Rock, Texas 78682 860 U.S.A. 862 Phone: 512-728-0380 863 Email: David_Warden@dell.com 864 URI: http://www.dell.com 866 Iordan Iordanov 867 Undatech 868 260 Scarlet Road, Apt. 503 869 Toronto, ON M6N 4X6 870 CANADA 872 Email: iiordanov@gmail.com