Re: [btns] rfc 5387

[Nicolas Williams <[e-mail]>]

On Thu, Apr 23, 2009 at 04:15:59PM -0500, [e-mail] wrote:
> Hello!  I am a student taking Internet Communications and our class is
> just finishing up our "security" section and I have a few questions about
> rfc 5387.
> 
> 
> -In the section 1.1 (Authentication) it is mentioned that is possible to
> use a trusted third party, could this be a third “peer”, proxy, and or
> STUN server?

The "trusted third party" thing wasn't the important thing -- what was
relevant in that sentence was "[o]ut-of-band authentication can be
done".  The particular method by which out-of-band authentication is
done is not terribly important because there's an enormous variety of
mechanisms that you could use.

> -Could BTNS use Chords?

What is Chords?

> -In section 1.2, it is mentioned “the peer's identity is the same for the
> lifetime of the packet flow”, can this identity be reused so it is open to
> attacks?

The identity can be reused, of course, but I don't understand the "so it
is open to attacks" part.

> -In this RFC it is mentioned that obtaining a security certificate could
> take a while.  I’ve never had to get one, so how long does it take?  Why
> would it be necessary to skip?

That's unfortunate.  The problem isn't how long it takes to get a
certificate (it could be as little as seconds with an online CA using
something else for authentication -- think "kca", a kerberized CA), but
the fact that deploying a PKI is usually difficult for a variety of
reasones.

> -MitM attacks are mentioned frequently, how are users detecting them to
> ensure they can use BTNS?

If BTNS is used like SSH leap-of-faith, then there's no protection on
the first connection, but there is thereafter if there was no MITM on
that first connection.

If channel binding is used then channel binding detects MITMs.

> -Although it can be cumbersome, what’s wrong with having redundancy?
> “. . . authentication at both the network layer and a higher layer for the
>    same connection.”  Or is this where one authentication might fail?

This isn't about authentication redundancy.  It's about pushing session
cryptographic protection to lower layers.

The canonical example for the IPsec channel case would be any protocol
that uses RDMA/RDDP.  In such protocols you have a header between the
transport (TCP, SCTP, UDP, ...) and the application protocol, and that
header tells the "RNIC" (RDDP-capable NIC) that some parts of the
application data payloads should be delivered directly into pre-arranged
RDMA buffers.  In order to make RNICs + session security feasible while
still retaining the performance benefits of RDDP you need the
application layer to be in cleartext relative to the RDDP header, which
means that session cryptographic protection has to be done below it,
either at the transport layer or IP.

In the case of other apps, like, say, IMAP, you can also benefit from
pushing crypto to lower layers, such as TLS.  In the TLS case the
benefit comes from having already-deployed TLS concentrators that can be
used to offload the crypto from the server.

> -Is BTNS a form of best effort encryption?

If used alone, yes.  If used with channel binding or out-of-band
authentication, no.

> -From section 4, BTNS protects security associations after they are
> established by reducing vulnerability to attacks from parties that are not
> participants in the association.”  Doest this include MitM attacks?

Yes.

Nico
--