[Spice-devel] [PATCH] protocol: RFC: add common channel caps for AUTH mechanism selection

[Hans de Goede]

Hi,

On 02/13/2011 03:23 PM, Marc-André Lureau wrote:
> Current version 2.0 of the SPICE protocol describes how the client
> reply to the server SpiceLinkReply message with a RSA_public_encrypt()
> of the password.
>
> Instead of using the current Spice AUTH mechanism, we would like to
> offer different AUTH mechanisms, in particular SASL, which is a
> framework allowing different underlying mechanisms such as
> GSSAPI/Kerberos v5 (and optionally adding a data security layer).
>
> We could bump the protocol version, but that would make this feature
> mandatory for the implementer of the protocol. By using the channel
> caps, the client and server are left to negotiate and alter the AUTH
> part of the protocol as follows:
>
> - SPICE_CHANNEL_CAP_PROTOCOL_AUTH_SELECTION, if set, the
>    authentication mechanism can be chosen. If both client and server
>    have this caps, the client MUST reply to SpiceLinkReply with a
>    SpiceLinkAuthMechanism message, with the value of the CAP_AUTH
>    mechanism choosen (uint32 auth_mechanism). The following authentication
>    steps are described by the selected authentication mechanism.
>
> The differents mechanisms selectable via
> SPICE_CHANNEL_CAP_PROTOCOL_AUTH_SELECTION are also specified as part
> of the common channel caps. They can be used only if both client and
> server offer them.
>

In general I like, I do have a few remarks though.

> Ex: no AUTH selection
> C: SpiceLinkMess
> S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION not in common caps
> - The client can't choose AUTH, and fallback on Spice RSA mechanism
>
> Ex: AUTH selection
> C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION in common caps
> S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION in common caps
> - The client MUST reply with SpiceLinkAuthMechanism
> C: SpiceLinkAuthMechanism (with a matching CAP_AUTH)
>
> - SPICE_CHANNEL_CAP_AUTH_SPICE, the following steps and authentication
>    mechanism are the same as with version 2.0: a RSA_public_encrypt()
>    of the password is sent.
>
> - SPICE_CHANNEL_CAP_AUTH_SASL, the authentication exchange follows
>    SASL protocol has defined in RFC 2222.
>
> Ex: AUTH selection, followed by SASL authentication
>
> AUTH Selection:
> C: SpiceLinkMess, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
> S: SpiceLinkReply, CAP_PROTOCOL_AUTH_SELECTION + CAP_AUTH_SASL in common caps
> - The client MUST reply with SpiceLinkAuthMechanism

I would like to state in the spec, and see in this example, that
SPICE_CHANNEL_CAP_AUTH_SPICE must always be supported, and thus set
in the capabilities field. This way we ensure that their will always be
one auth method both sides support.

> C: SpiceLinkAuthMechanism CAP_AUTH_SASL
>
> Init:
> S:  u32 mechlist-length
>      u8-array mechlist-string
>
> Start:
> C:  u32 mechname-length
>      u8-array mechname-string
>      u32 clientout-length
>      u8-array clientout-string
> S:  u32 serverin-length
>      u8-array serverin-string
>      u8 continue
>
> Step: (while continue)
> C:  u32 clientout-length
>      u8-array clientout-string
> S:  u32 serverin-length
>      u8-array serverin-string
>      u8 continue
>
> See also VNC SASL protocol description, which uses the same protocol:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=20100719125155.GA14166%40evileye.atkac.brq.redhat.com&forum_name=tigervnc-rfbproto
> ---
>   spice/protocol.h |   10 ++++++++++
>   1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/spice/protocol.h b/spice/protocol.h
> index d6a2041..77458db 100644
> --- a/spice/protocol.h
> +++ b/spice/protocol.h
> @@ -51,6 +51,12 @@ typedef struct SPICE_ATTR_PACKED SpiceLinkHeader {
>       uint32_t size;
>   } SpiceLinkHeader;
>
> +enum {
> +    SPICE_CHANNEL_CAP_PROTOCOL_AUTH_SELECTION,
> +    SPICE_CHANNEL_CAP_AUTH_SPICE,
> +    SPICE_CHANNEL_CAP_AUTH_SASL,
> +};
> +

So I guess there have been no common channel caps defined so far? (too
lazy too check on a sunday) also maybe we should put COMMON in the
names (I know they are long enough as is) ?

Regards,

Hans