[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEv2 and SIGMA
On 28 Nov 2001, Derek Atkins wrote:
> Hugo Krawczyk <hugo@ee.technion.ac.il> writes:
>
> > ESP specifications are defined to secure raw data, not functioning
> > as an authentication mechansim in a key exchange protocol.
>
> Actually, Hugo, if you step back and view "a key exchange protocol" as
> "raw data", then ESP works perfectly well. Keep in mind that this is
> not ESP in the standard sense. Rather, this is using the ESP packet
> format with the key-exchange-protocol Security Association.
Derek,
if you step back and view "a key exchange protocol" as "raw data",
as you suggest, you will most probably end with an insecure protocol.
If you do not understand what I am talking about go over the
follwoing three exercises (you may consider this to be of
theoretical interst only, yet I ask you to do it):
(a) can you explain why the "raw data" of third and fourth message of
IKEv2 needs strong integrity protection via ESP given that we already
have a strong authentication of this data via the initiator's signature?
(b) the JFK protocol does not use the integrity protection
of HMAC in addition to the signature. Yet, their protocol is secure.
So why I insist so much that IKEv2 adopts the SIGMA design and
add the HMAC (or prf) under the signature?
(c) If one moves the ID payload from the 3rd message of IKEv2 to the first
message; is the protocol with the use of ESP, and with strong integrity,
secure?
[Please, do not dismiss this last question just because currently
IKEv2 does not allow sending the ID in the first message -- I actually
would recommend they allow for that, as in OIDi of SIGMA. But this is
anyway not the point of my question]
If you can answer all these questions then you wil really understand that
there is nothing further from security that treating the key exchange
information as raw data.
It is EACH DETAIL in the way you do authentication, such as what EXACTLY
goes under the signature, why is a signature sufficient or insufficient,
what goes in plaintext and what goes encrypted, etc that makes the
difference between a secure or insecure protocol.
One thing is to discuss functionality (yes or not weak DoS protection,
yes or not id protection, yes or not shared-mode, etc) where each one has its
own subjective (and equally arguable) reasons and taste, and it is another
VERY DIFFERENT thing to discuss the core cryptographic design of a
key exchange protocol. This should not be done through "rough consensus"
but using the mathematical design and analysis tools that we have.
Hugo
References: