Subject: Re: [P2PSIP] Bootstrap redirection authentication [was Re: Fwd: I-D Action: draft-petithuguenin-p2psip-reload-one-to-many-00.txt]

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 03 Mar 2013 13:06:23 -0800

On 02/26/2013 09:50 AM, Marc Petit-Huguenin wrote:
> I did not release a new version of this draft because as I was working on 
> improving it I discovered some issues and I was not able to decide on the 
> right solution.  So I will present this in Orlando if I get presentation
> time, but I would like to start the discussion now.
> 
> The problem with Anycast is that there is no guarantee on the long term
> that the same physical endpoint will be reached when using such address.
> This is not a problem for short-term association, and even TCP is known to
> work fine in this case.  But in some cases (RELOAD section 3.2.1 second
> bullet) a client can establish a long-term association with a bootstrap
> server, and this association may fail.  So the solution used in
> -one-to-many-00 is to first send a STUN binding to the Anycast address
> which will be answered with a 300 redirect that contains a Unicast address
> that can be used for long term association.  This also works fine with
> multicast and broadcast.  No problem so far.
> 
> The problem is that it is relatively easy to redirect the client to the
> wrong IP address, which is why this kind of mechanism requires some form
> of authentication, so the client knows that the answer is from the real
> server. Note that the client will anyway quickly discover that the IP
> address does not use a correct certificate, so perhaps this attack is
> harmless.
> 
> One solution is to use the long-term authentication mechanism of STUN,
> using the same username and password that was used to acquire the RELOAD 
> certificate.  The client checks the MESSAGE-INTEGRITY in the response to 
> verify that the server really knows the password.  I do not really like
> this solution, because it requires to distribute and synchronize the 
> usernames/passwords on a lot of different servers.
> 
> Another solution may be to use the fact that the bootstrap servers are 
> contacted after a certificate is retrieved from the enrollment server 
> (although an implementation may want to query the real address in parallel)
> to establish a DTLS connection with the Anycast address, using this newly 
> acquired certificate, and then send the STUN Binding over it.  That's my 
> preferred solution, but that looks a little bit complex for that purpose 
> (although it does not add more code to an implementation, as DTLS is
> required for RELOAD anyway).

Reading the notes I took when trying to implement this, there is another issue
which is that DTLS was never defined as transport for STUN (or TURN).  So that
would require an additional draft.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug