hamachi p2p vpn nat-friendly protocol details

[Travis H.]

On 2/24/06, Alex Pankratov <ap at hamachi.cc> wrote:
> Tero Kivinen wrote:
> >> Secondly I cannot find where it
> >> authenticates the crypto suite used at all (it is not included in the
> >> signature of the AUTH message).
>
> Crypto suite is essentially just a protocol number. It requires
> no authentication. If the server side responds with HELO.OK, it
> means that it can comprehend specified protocol revision. Similar
> to what happens during the SSH handshake.

In SSL, the lack of authentication of the cryptosuite could be used to
convince a v3 client that it is communicating with a v2 server, and
the v3 server that it is communicating with a v2 client, causing them
to communicate using SSL v2, which is called the "version rollback
attack".  This is not relevant to the hamachi protocol because there
is no negotiation.  Nevertheless, authenticating the previous
plaintext fields once a secure channel is established is considered
good form.

In Schneier's "Practical Cryptography", he suggests computing the MAC
over the entire history of sent messages, which ensures that any
tampering is detected at the next MAC.  This is eventually what was
done in SSLv3, for reasons Tero alluded to and which are successfully
thwarted for the reasons you describe.

> >> The protocol description is missing some details, so cannot say
> >> anything about them (things like what is the format of Ni, Nr, Gi, Gr
> >> when sent over wire and when put to the signatures etc, are the Gi, Gr
> >> always the lenght of modulus (2048 bits) etc).
>
> What would you like to know exactly ? The page was not meant to
> be a bit-level description of messages, merely a description of
> the security framework.

Presumably he wants to make sure that the messages like the following
have an unambiguous interpretation:
AUTH Identity Signature(Ni | Nr | Gi | Gr, Kpri_cli)
Merely concatenating them is insufficient unless all but one have a
fixed length.
I think a terse "unambiguous representation" rationale is the whole
reason for ASN.1, although it seems awfully complex for such a simple
goal.

I sort of wonder at the utility of a TCP implementation of the p2p
VPN... tunnelling TCP over TCP is well known to be a Bad Thing with
regard to interaction of the TCP timeouts.

Aside:  Can anyone tell me why the constants used in ipad and opad for
HMAC were chosen?  If they're not arbitrary, I'd like to know the
rationale behind them.
--
Security Guru for Hire http://www.lightconsulting.com/~travis/ -><-
GPG fingerprint: 9D3F 395A DAC5 5CCC 9066  151D 0A6B 4098 0C55 1484

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com