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 metzdowd.com
|