Subject: Multi-Part Authentication over RTSP

From: "Kirk Shoop" <[email-masked]>
Date: Wed, 10 Jun 1998 11:59:40 -0700

Hi.

I am working on the RealNetworks implementation of RTSP.  I am trying to add
authentication.  We would like to support more than just Basic and Digest
authentication as these are not designed to be particularly secure.  Most of
the more secure methods of authentication require 4 or more sequential data
exchanges.  This requires us to associate the messages which make up a
particular conversation.  We would also like to prevent a "man in the
middle"
from using an authenticated session to request new content, change the
destination of an existing stream etc..

Here is how we would like to do this:

There will be a full authentication conversation for each DESCRIBE
method, and there will be another full authentication conversation
for each session. This will occur at the first SETUP message.  If
the client tries to associate a separate file to an authenticated
session, then it's up to the server to refuse the request (at least,
in our implementation).  In the event that we allow things like
redirection of streams to new destinations or other "session changing"
features, we need to make sure we evaluate the tradeoffs of
re-authenticating or not re-authenticating.

Now for the details:

We will add a header which uniquely identifies an authorization session.
This value will be returned by the server on the initial denial (along
with the initial challenge).  "AuthConversation-ID" is an appropriate
name for this field.  The value could contain an MD5 hash of the
URL and the CSeq of the initial message.

Whatever we do, we would like it to inter-operate! :) So please help us
work out any kinks you see in this.

Thanks,
Kirk