On Thu, 19 Oct 2006, Petri Jokela wrote:
(apologies for the rather long delay, but I believe there
was no comment
on the two last open issues)
> List of issues that I do not necessarily require
immediate actions or
> that I haven't modified:
>
>
> 16. Risk with using the same D-H value and random
puzzle
>
> "The security consideration section indicates
there is a risk in using
> the same D-H value and random puzzle, but it does not
describe what the
> risk is. This makes it difficult to balance with the
tradeoff
> described. "
>
> - I haven't made any modifications related to this. Any
input for this?
With fixed puzzles, an initiating attacker does not have to
calculate
cookies after the first R1. Combined with reused D-H key,
the initiating
attacker can use prebuilt I2 messages and thus avoid also
signature
calculation. This way, the attacker exchanges I1 and R1, and
then
infinitely send I2 messages, forcing the responder to verify
the I2
signatures and calculate new R2 messages.
The responder has state at this point (R2-SENT) and can
implement caching
of sent R2 messages. However, the caching is only valid
until the prebuilt
R1 message pool is refreshed and the received I2 remains the
same. Also,
the responder can go to ESTABLISHED after timeouting in
R2-SENT, but it
still has to accept the I2 packets in this state. As an
alternative
implementation strategy, the responder may also implement
"fair" rate
control for incoming R1 packets that guarantees valid
initiators to be
served eventually.
> 17. Sigma
>
> "The draft claims to be based on the SIGMA
exchange. While it is similar
> there are some differences. In particular the
signature on the
> responder's exponential is not required to be
validated.
> I think it looks OK since the last MAC is signed by the
responder, but it
> would probably be good to have another set of eyes look
at it. "
The R1 signature covers the responder's exponential. The MAC
in R2 is derived
using the exponential and the signature covers the MAC, so I
don't see a
problem.
The original discussion is here:
http://www1.ietf.org/mail-archive/web/hipsec/c
urrent/msg00922.html
I could stop here, but I analyzed the SIGMA compliancy
slightly further. I
would actually claim that the base exchange is a hybrid of
"basic ISO KE"
and "basic SIGMA" of the SIGMA paper, which are
both secure according to
the SIGMA paper.
Both the basic ISO and basic SIGMA have three messages, but
HIP has four.
The difference is the extra I1 "trigger" packet in
the beginning of base
exchange that allows responder to be stateless. The trigger
packet can be
added also to the beginning of the ISO and SIGMA protocols,
which just
"reverts" the roles of the peers. Below, I am
assuming that both ISO and
SIGMA are modified to have the extra trigger packet in the
beginning, just
to match the base exchange packet numbers.
>From ISO, base exchange inherits the "intended
recipient property" which
means that the public keys are exposed earlier than in SIGMA
(i.e. in the
first messages). This, and the derivation of HITs from
public keys
especially for the otherwise unprotected trigger packet,
protects the
initiator from attacks where middleman is able to modify the
packet. With
the use of opportunistic HIP, the "intented recipient
property" (which
"degrades" base exchange to level of SIGMA), but
this is not in primary
scope of the base draft anymore.
Optional public key protection against active attacks is
provided as
described in "identity protection variant of the ISO
protocol" in the
SIGMA paper. In short, the initiator encrypts the public key
and makes use
of hashes (HITs). I believe this might be subject to crypto
analysis and
may not provide as strong identity protection as SIGMA-I and
SIGMA-R,
because those encrypt also the signatures and MACs.
>From SIGMA, the base exchange borrows the use of MACs.
The main use of
MACs in SIGMA is to "decouple the authentication of the
DH exponentials
from the binding of key and identities". However, since
public keys are
sent in plaintext (with the exception that initiator *can*
encrypt it),
the decoupling possibility introduced by MACs is not really
used in HIP.
IMHO, the MAC of I2 acts mainly as light-weight signature
that provides
some guarantee for the responder that the time-consuming
DSA/RSA signature
is worth of verifying. This increases the DoS protection for
the
responder. Despite the current limited use of the MAC, it
allows extending
the base exchange v2 towards SIGMA-I and SIGMA-R in my view.
HIP differs from SIGMA and ISO in the way the signatures and
exponentials
are used. In SIGMA and ISO, a signature covers both
initiator and
responder exponentials within the same signature. In both
ISO and SIGMA, a
signature covers explicitly both two exponentials. In HIP, a
signature
covers only a single exponential explicitly. However, we
must remember
that (1) the HITs affect the MAC key derivation and (2) HITs
are covered
by the signatures. Putting (1) and (2) together assures an
"implicit"
binding between the exponentials.
--
Miika Komu http://www.iki.fi/miika/
_______________________________________________
Hipsec mailing list
Hipsec lists.ietf.org
https:/
/www1.ietf.org/mailman/listinfo/hipsec
|