hamachi p2p vpn nat-friendly protocol details

[Alex Pankratov]

Tero Kivinen wrote:
> Alex Pankratov writes:
> 
>>>>There might be (I am not sure whether AUTH
>>>>packet is encrypted and MACed) a MAC over it, but the MAC key is not
>>>>yet authenticated as it is generated from the anonymous
>>>>Diffie-Hellman. That might give it some protection, but I am not sure
>>>>if that is enough.
>>
>>
>>A protection against what kind of attack ?
>>
[snip]
> 
> So the identity is authenticated because the server uses the identity
> given by the client to search the public key from his database and
> then uses that public key to check the signature?

Yes.

> I think that should be enough, but I wasn't sure how the server
> works with the public keys, i.e. what kind of registration is done,
> and how it makes sure there is no duplicate identities created for
> different public keys etc. Actually it is not clear what purpose the
> identity itself has. If the only purpose is to identify the public key
> already stored in the server, then hash of the public key would be
> better, but if that ID is assigned by the server on the first
> registration, then it is probably ok.

It's assigned on the first contact.

>>>>The protocol is also tied to use SHA1.
>>
>>If you are referring to HMAC-SHA1 for authentication hashes, it
>>is a part of a crypto suite (protocol revision) spec.
> 
> 
> Yes, it is part of the crypto suite, and that is not authenticated.
> I.e. if / when the SHA1 is completely broken, in a way that also
> HMAC-SHA1 is broken, then only way to change it is to put out new code
> that supports new crypto suite (with some other hash/mac) and as the
> crypto suite is not authenticated, then attacker can cause downgrading
> attacks forcing client and server to use the broken crypto suite.

Should switching to new crypto suite be required, new revision
will authenticate suite ID, and this should prevent downgrading
attacks. This will work because the suite is not negotiated,
but rather pre-selected by the client.

All in all I agree that both Identity and Suite should be
included into the hash. We'll make the change to a protocol.

> Looking at the latest development of the breaking of the hash
> algorithms, it would be better to make sure that the algorithm
> designed now would be crypto agile, i.e. make sure they do allow
> different crypto algorithms, and allows easy adding of new algorithms. 

Well, if one want to avoid *binary* upgrade in the event of
a suite being rendered useless, the binary needs to support
all known cipher/digest/mac algorithms and the protocol needs
to allow for defining suites dynamically.

I am not aware of any protocol that has this property. Which
means that should HMAC-SHA1 gets broken, all existing binaries
would still require an upgrade regardless of whether how hard
it is to add/replace the algorithms.

In our case all crypto resides in a single module behind
generic interface. Swapping it for an implementation that
uses different algorithms is a matter of minutes.

>>This is the second revision of Hamachi system. First revision
>>was using SSL for cli-srv and IKE/ESP for p2p security. It was
>>a prototype and it soon become obvious that both SSL and IKE
>>were overkills for our purposes. We did not need certificate
>>authentication of SSL, we did not want to run our own auth
>>protocol over SSL/AnonDH, which would've increased the number
>>of packets per login sequence. We didn't need the flexibility
>>(ie complexity) of IKE either.
>>
>>After stripping down IKE (ie removing SA negotiation, reworking
>>ID payloads and not doing quick mode), we essentially ended up
>>with a protocol that was also fit for securing cli-srv session.
>>It was further tweaked and replaced SSL.
> 
> 
> Now there is the IKEv2 which is much bigger improvement over IKEv1,
> especiallty if profiling it suitably (i.e. use raw RSA keys instead of
> certificates etc). 

I looked at IKEv2 and JFK when we just started. It was a couple
of years ago, IKEv2 was still pretty much in a discussion phase,
so it was as good of an option as a custom protocol. It's RFC'd
now, I will give it another read.

As a side note I want to add that there're no illusions that
given two versions of the system - one based on a custom
protocols and one based on a standard ones - the second one
is a better choice for many reasons. We had our reasons to
go with a custom protocol for the first version and it seems
to have worked out to be reasonably good.


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