Subject: [Uri-review] URI Review of VNC Scheme

From: <[email-masked]>
Date: Tue, 22 Sep 2015 12:28:25 -0500

Hi everyone,

I've submitted a VNC scheme document:
http://www.ietf.org/id/draft-warden-appsawg-vnc-scheme-04.txt 

Hopefully this will allow VNC clients to be launched from other applications while avoiding conflicts among competing schemes. 

Review and comments from members of this list are welcome. 

This document has been reviewed to some extent in the applications area working group (apps-discuss) and by publishers of VNC clients. Upon advice of the area director, we plan to publish this as an independent submission. As part of this process, I have been advised to request additional review on this list. 

Thanks,

David Warden
Software Development Principal Engineer
Dell | Enterprise Solutions Group

---

From: Dirk-Willem van Gulik <[email-masked]>
Date: Wed, 23 Sep 2015 12:02:00 +0200

> Hopefully this will allow VNC clients to be launched from other applications while avoiding conflicts among competing schemes. 

First of all - lovely to see this documented; and I am hard pressed to find anything that does not document current practice.

Now all the forms of _integrated_ ssh auth are in lieu of VNC auth. And some (older) VNC servers seem to only need a password.

Secondly - it is not uncommon for URI libraries to understand the sensitivity of the userinfo as in <scheme>://< userinfo >@<server><path> and understand that the credentials are a colon separated username and password. 

RFC 2386 describes this user info as an opaque blob (i.e. leaves the colon separation to the schema def’s) - but also notes that:

	 "In particular, the use of a password within the 'userinfo' component of a URL is strongly disrecommended except in those rare cases where the 'password' parameter is intended to be public.”

So I am wondering if

-	it can be said that _if_ there are credentials that one conceivably would convey in the URI - that there are generally only ONE set; i.e. VNC password -or- VNC username/password -or- SSH username/password.

And if that is the case (happy to bow to the experts here) — if it then makes sense to:

-	Move the credentials themselves to the <userinfo> section of the URI

as to give implementors a bit more room to understand their sensitive, not print them, store them in keychains and so on.

Just a thought - but do not let this derail your effort; having these VNC url’s formalised is worth it regardless.

Dw.

---

From: <[email-masked]>
Date: Wed, 23 Sep 2015 12:27:33 -0500

> First of all - lovely to see this documented; and I am hard pressed to find anything that does not document current practice.

Thanks for your comments Dirk-Willem,

> Now all the forms of _integrated_ ssh auth are in lieu of VNC auth. And some (older) VNC servers seem to only need a password.

For purposes of the URI scheme, SSH authentication is integrated on the client side, not necessarily on the server. For example, some users may expose SSH over the Internet and use VNC authentication on the LAN. In this case the VNC server treats the forwarded SSH connection as a local connection from the same network. Depending on the environment:
- The SSH server may expect a username/password and the VNC client may expect the same username/password 
- The SSH server may expect a username/password and the VNC server may expect a different username/password
- The SSH server may expect a username/password and the VNC server may expect just a password
- The SSH server may expect a username/password and the VNC server not use any authentication

The SSH server may also take a certificate based on an extended parameter that could be added to the IANA registry in the future. 

>Secondly - it is not uncommon for URI libraries to understand the sensitivity of the userinfo as in <scheme>://< userinfo >@<server><path> and understand that the 
> credentials are a colon separated username and password. 
> "In particular, the use of a password within the 'userinfo' component of a URL is strongly disrecommended except in those rare cases where the 'password' parameter is 
> intended to be 
> public.”
> So I am wondering if
> -	it can be said that _if_ there are credentials that one conceivably would convey in the URI - that there are generally only ONE set; i.e. VNC password -or- VNC 
> username/password - or- SSH username/password.

Based on the above, there is a need for separate VNC and SSH credentials. In practice, bVNC, iTeleport, and Remoter currently support separate SSH/VNC credentials in their URI (but in different ways). 

> as to give implementors a bit more room to understand their sensitive, not print them, store them in keychains and so on.

The purpose of allowing the userinfo section is for backwards compatibility. I don't believe it should be used going forward. Part of the reason is spoofing:
Vnc://binx.uiuc.edu&ViewOnly=false&ColorLevel=[email-masked]

This looks at first like it will connect to a uiuc system, but it really goes to attacker.com (which then steals the credentials). 

One of the primary use cases of the scheme is for mobile apps to launch other mobile apps, in which case the receiving app can be expected to use keychains etc. the correct way. It would often be advisable to avoid including passwords on a web page or more generic context. In any event, we need to support credentials in the query part to support our use cases and for general compatibility.  

For reference here are what some apps actually do:
bVNC (Android) - vnc creds and ssh creds in query
http://remoterlabs.com/main/remoter-url-handling/ - vnc credentials in userinfo, ssh creds in query
http://www.iteleportmobile.com/support/url - no vnc username, vnc password and ssh creds in query
http://helpdocs.edovia.com/apps/screens/iOS/3.2/en/url-schemes.html - username in userinfo, password in query, separate scheme for ssh
https://www.realvnc.com/products/ios/release-notes/ - vnc creds in userinfo, no ssh support
The historic android vnc client had vnc credentials in the path (no ssh)

Thanks,

David

---

From: [email-masked]
Date: Wed, 23 Sep 2015 21:41:46 +0200

> On 23 Sep 2015, at 19:27, <[email-masked]> <[email-masked]> wrote:
> 
> 
….
> The SSH server may also take a certificate based on an extended parameter that could be added to the IANA registry in the future. 
…
> Based on the above, there is a need for separate VNC and SSH credentials. In practice, bVNC, iTeleport, and Remoter currently support separate SSH/VNC credentials in their URI (but in different way…

So in short; to many permutation to use the <userinfo> block of RFC 2386 (unless you go way beyond the current foo ‘:’ bar structure.

> Vnc://binx.uiuc.edu&ViewOnly=false&ColorLevel=[email-masked]

I understand that argument - but at the same time - we also have URI handlers which are clever about it - and parse this well.
..
> One of the primary use cases of the scheme is for mobile apps to launch other mobile apps, in which case the receiving app can be expected to use keychains etc. the correct way. It would often be a…

So right now - your security section says

   Remote desktop connectivity requires the transmission of security
   credentials, which may be included in a URI.  If those credentials
   are not kept secure, an attacker may gain access to any systems
   using those credentials.  Host addresses and connection parameters
   may also be considered sensitive, as such information can be used in
   planning an attack.

perhaps add something like that bit of text to it — and perhaps some guidance as how to deal with those URIs and keychains.

Dw.