Hi!
Den 2008-12-14 17:53 skrev Daniel P. Berrange:
> I have defined a mapping of the SASL authentication scheme into the RFB
> authentication protocol. Please could you allocate an official security
> type code for use with this auth scheme, under the name "SASL".
*snip*
I looked a bit at this and spotted a few typos, see diff in
attachment (I replaced 100 with 20 before making the diff, I figured
those changes were not very interesting).
I also have a couple of questions:
1. Is there any compelling reason to *not* sasl_encode/sasl_decode
the 6.1.3 SecurityResult message when there is a SSF layer? I think
using sasl_encode/sasl_decode on that message as well would simplify
implementations, as the need to hook in after the SecurityResult
disappears. It would be enough to make the needed stream modification
while still running in "sasl territory".
2. Not knowing much about SASL, I'm curious to know if this security
type is useful on reversed connections? Are there any implications
to consider?
3. And finally, does this security type spec have a home somewhere on
the Internet?
Cheers,
Peter
--- README.sasl.orig 2008-12-17 07:19:28.046875000 +0100
+++ README.sasl.new 2008-12-17 07:21:50.437500000 +0100
@@ -174,5 +174,5 @@
If the "sasl_server_start" call is successfull, the returned
-"serverout" data will need to be sent to the server.
+"serverout" data will need to be sent to the client.
@@ -201,5 +201,5 @@
&clientin,
&clientinlen,
- &servertout,
+ &serverout,
&serveroutlen);
@@ -219,5 +219,5 @@
write_u8(1)
} else {
- write_u8(0)
+ write_u32(0)
write_u8(0)
}
@@ -241,5 +241,5 @@
If the "sasl_client_step" call is successfull, and the previously
-received "6.2.20.3 sever start' or "6.2.20.5 server step"
+received "6.2.20.3 server start' or "6.2.20.5 server step"
message had the "continue" value set to 0, the client protocol
continues to 6.2.20.6 client security check". The final call
@@ -267,6 +267,6 @@
sasl_client_step(saslconn,
- &serverin,
- &serverinlen,
+ serverin,
+ serverinlen,
&clientout,
&clientoutlen)
@@ -320,6 +320,6 @@
err = sasl_server_step(saslconn,
- &clientin,
- &clientinlen,
+ clientin,
+ clientinlen,
&servertout,
&serveroutlen);
@@ -340,5 +340,5 @@
write_u8(1)
} else {
- write_u8(0)
+ write_u32(0)
write_u8(0)
}
@@ -354,5 +354,5 @@
At this point the client and server have completed the SASL negotiation
-process. If the client had requested an SSF layer during its initial
+process. If the client had requested an SSF layer during its initialization
it should now validate that a suitable SSF layer was negotiated with
the server. If the SSF layer is unsuitable it shall drop the connection
@@ -380,5 +380,5 @@
The client and server are now authenticated, but before continuing, if
-the server had requested an SSF layer during its initial it should
+the server had requested an SSF layer during its initialization it should
now validate that a suitable SSF layer was negotiated with the client.
If the SSF layer is unsuitable it shall send a "6.1.3 SecurityResult"
@@ -386,5 +386,5 @@
connection to the client.
-If the SSF layer is enabled, and suitable for the client, all messages
+If the SSF layer is enabled, and suitable for the server, all messages
transmitted over the RFB protocol AFTER the "6.1.3 SecurityResult"
message shall be passed through the "sasl_encode" API, and all messages
_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
