[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: compare-jfk-sigma.txt
I for one would really like to NOT consider negotiation of ciphersuites.
At present the set 'possible ciphers' is very large, the set 'recommended
ciphers' is actually small.
We have RSA, DSA, DH, AES, SHA-1 and the AES SHA.
I have yet to see a cryptographic negotiation that adds security over 'try
your strongest cipher, if that is rejected read the list of acceptable
ciphers and choose the strongest'.
I have seen plenty of rational implementations that will behave
disastrously. for example if you build a crypto application on top of CAPI a
rational implementation choice would be to search through the cipher store
for supported algorithms and offer that set. This is a bit of a lose however
when someone installs a cryptographic provider that implements a broken
cipher such as MD4 or (worse) a test cipher suite such as NULL or Rot 13.
Looking at Sigma the reason I hate it is that the initiator does not know if
the operation succeeded. To me that is bad design practice. In XKASS the
responder doe not know if the protocol completes, but the responder does not
care.
It seems to me that you have to add in some sort of acknowledgement message
into the protocol and that it has to incorporate some sort of cryptographic
assurance from the responder that the protocol completed successfully and
that this has to be included in the analysis of the cryptography. In effect
you have failed to specify a necessary and important message. This should
appear up front:
1. HDR, SA, KE, Ni [, OIDii] -->
2. <-- HDR, SA, KE, Nr, <IDir>*,
[ <CERT>*, ] <SIG_R>*
3. HDR, <IDii>*,
[ <CERT>*, ] <SIG_I>* -->
4. <-- New message to be specified.
After adding this in the comparison between JFK and Sigma does not appear to
be as strongly differentiated as it appears in the paper.
Specifically to reply to the points raised in the paper:
(1) JFK FORCES the disclosure of R's identity.
So what? The whole idea that you can keep your identity secret in IPSEC is
pretty questionable, the idea that both parties can conceal their identity
in an IP exchange is pretty wierd. If I am accessing the amazon.com web site
I will first resolve the name to an address via DNS and proceed.
One can make a case for concealling the identity of the client. BUT THE
SERVER??? What are folk smoking? What is the use case here? Why should an
infrastructure protocol support such a mode? Is identity conceallment in the
key exchange algorithm suffiecient to conceal identity in the mode of use? I
don't think so. As with Chaum's digital cash, what is the point of using
e-coins if the merchant is running a double click ad server on their site?
If you insist on identity conceallment for the client I don't think that
either JFK or Sigma succeeds when the entire use case is considered.
2) If the responder does not want to generate such
a new signature with each exchange it MUST keep g^r for several
(and possibly many) different exchanges.
Why not pre-compute g^r and the signature? It is a trivial matter for a
responder to pre-compute new cryptographic parameters and store them ready
for the next request. If one was building a really high performance
implementation this could even be done on a separate processor.
I do not approave of the conflation of an imagined performance optimization
here being described as a security issue. Clearly JFK can be implemented
securely and nobody who shared use of g^r would be unaware of the
consequences.
3) Yet another security cost of JFK's design is that it suffices for the
attacker to find a single pair (r,SIG(g^r)) (e.g. via the exposure of
a single session state) to be able to trick all initiators in
subsequent exchanges with R to disclose their identities.
Again, I am exceptionally skeptical as to the possibility of identity
conceallment. Sigma may be imune to the attack as you claim, but I am almost
certainly going to be able to uncover your identity from your IP address so
what are you actually gaining?
However the objection does appear to call into question the value of the
pre-exchange from the point of view of identity conceallment. The DoS
protection ability still remains of course. But should a protocol require an
extra round trip on every occasion for that sole purpose? Wouldn't it be
better to start the exchange assuming it will complete in one round trip and
only require cookies to be sent on the occasions when the responder is
actually under a DoS attack?
4) By forcing a signature of each party on the peer's identity JFK always
leaves a transferable proof of communication for each exchange.
This can be used to provide a proof (to a judge, journalist or business
competitor) that a communication with certain peer happened.
Again, look at the IP traces. Believe me, no judge has ever demanded that a
digital communication be digitally signed before accepting it as evidence
that a communication took place between the parties. The purpose of a
digital signature is to authenticate the contents of the transmission.
In order to guarantee concealment of identity you would need to use some
sort of anonymizer service to conceal the packets (go ask Austin Hill about
the economic viability of such an enterprise). So allow the anonymizer to
perform an intermediate key agreement under its credentials, or issue users
with 'disposable credentials' that are used once only for the sole purpose
of establishing a secure channel for a key agreement.
I strongly suspect that there is no protocol that provides perfect identity
conceallment which does not do so by in effect performing a complete
duplicate key agrement. The reason being that to securely exchange
credentials requires the very assurances a public key exchange is meant to
establish.
Identity concealment is a wonderful subject for academic study. It is a
bogus requirement for IPSEC.
(5) The DoS defense mechanism at JFK is computationally wasteful,
a cost that may be crucial during actual DoS attacks. The reason
is that the input to HMAC for generating the DoS cookie is very long.
This complaint appears to be scraping the barrel. HMAC functions are cheap
compared to an exponentiation. In XKASS we put everything we can through the
HMAC because that makes the proofs much easier. I could care less about
being miserly with computational costs, round trips and exponentiations are
the overheads here.
In contrast, the DoS mechanism in SIGMA is used at the discretion of
the responder (and only in periods of time during which the
responder's node discovers actual DoS activity).
Which is precisely the modification I am proposing to JFK, junk the identity
conceallment which will never really work anyway and cut the exchange down
from two round trips to one.
CONCLUSION: SIGMA does a better job than JFK both in respect to
security and performance. In particular, it provides:
I don't think you make a case. The only grounds on which you made any points
were on the identity concealment issue which I repeat is bogus and should be
excised from the requirements anyway.
Moreover, the extra costs and weaknesses in JFK (maybe with the exception
of point (5)) are all UNAVOIDABLE without a re-design of the core
cryptographic protocol.
Yet, I want to emphasize the "provable secure" nature of JFK.
This was stated as a main goal by the protocol authors,
and is achieved for the core cryptographic protocol.
I don't give a hoot for 'provable'. I only care about 'proven'. If people
want to claim that they have analysed the security properties of a protocol
in a formal protocol that is great. However until the proof and the calculus
are shown it is a bit like the difference between 'B2 equivalent' and 'B2
certified' the number of copies of 'B2 equivalent' UNIX installations that
shipped with a version of sendmail that had been broken 3 years earlier in
the 1990s was very high.
On section C, XKASS requires two messages, JFK four, SIGMA three or five
under DoS attack, four or six if you add in the acks. Incorporating the JFK
cookie concept into XKASS gives us two or four under Dos attack.
Conclusions
1. Sigma is not a noticable improvement over JFK or XKASS. It is claimed to
provide better protection against irrelevant risks and requires an extra
round trip under realistic ones.
2. The proposal to separate the DoS cookie into a separate exchange is a
good one however and may be achieved through a minor modification which will
reduce the number of round trips required to one at the cost of eliminating
the not very usefull identity concealment feature and making the protocol
look pretty much identical to XKASS.
Phill
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
Phillip