[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKEv2 and SIGMA

On Mon, 26 Nov 2001, Hugo Krawczyk wrote:

 > I'd like to address one fundamental issue
 > related to the cryptographic soundness of the current design.
 > Namely, the protocol does not achieve a strong cryptographic binding
 > between the exchanged DH key and the party identities (an essential
security
 > requirement put forth by the STS paper [DVW]).
 >
 > This can be indirectly achieved in IKEv2 via ESP if one MANDATES
 > strong integrity in ESP (otherwise integrity is optional in ESP),
 > but even then a truly sound key exchange protocol should not rely on
 > external mechanisms to provide the most essential security properties
 > (in contrast, using ESP for id protection is perectly reasonable).

You're quite right; the spec should say that an integrity protection
algorithm is mandatory (and it sort of does in Appendix B, but it should
be more prominent and mentioned in the Security Considerations section).

 >
 > The solution to this problem is quite simple: put back the prf (or HASH)
 > computation under the signature; a detailed specification can be found in

 > my recent SIGMA proposal [SIGMA].
 >

This is certainly an alternative. As specified, the concatenation of the
first two messages is signed, which had a certain elegance and ease of
specification. But including additional fields under the hash would not
be difficult. I believe that for the protection of Phase 2, it is necessary
to make the integrity protection mandatory anyway. And I believe that if
the integrity protection in ESP turns out to be inadequate, having a fix
that works only for key management is of little value. How strongly do you
feel that it's important?

I prefer specifying the fields to be concatenated and signed rather than
the HMAC construction because of the complexity of specifying signing an
HMAC with DSS when DSS specifies that you must sign the SHA-1 of something.
But this is only a specification challenge, not an implementation
challenge,
so if there is a good security reason to use the HMAC construction, we
could do that too.

 > Moreover, I would recommend integrating the SIGMA protocol to the current
 > IKEv2 specification framework.  This would have the effect of providing
full
 > cryptographic security AND improving performance by reducing the number
of
 > messages and the latency of SA activation. Given the IKEv2 draft,
specifying
 > SIGMA in this context requires minimal work.

I agree it would be straightforward. SIGMA proposes several protocols with
different properties. I am reluctant to have options, since they limit
interoperability. Is there one that you believe would be workable as *the*
protocol that has advantages over the current proposal?

 > In addition, the SIGMA protocol would allow to have, in addition to the
 > main PK-based protocol, a single mode that simultaneously supports
 > Phase 2 functionality AND provides support for pre-shared keys.

I agree that support for pre-shared keys would be a useful alternative, but
I think the mechanism for it requires more thought. IKEv1 main mode has
the problem (and SIGMA duplicates it to some degree) that identities are
hidden on the wire but the protocol can't complete if the two ends don't
know the identities of the peers by some out of band mechanism (like based
on IP addresses). This fails in the common case of a mobile user connecting
in via IPsec to a corporate firewall. We decided not to muddy the debate
over
a single simple-every-implementation-interoperates-with-every-other
proposal for IKEv2, but if the other issues seem stable we could start
discussing this.

 > As I said in my note, I believe (and hope that you agree) that
 > A TRULY SOUND KEY EXCHANGE PROTOCOL SHOULD NOT RELY ON
 > EXTERNAL MECHANISMS TO PROVIDE ITS MOST ESSENTIAL SECURITY PROPERTIES
 >
 > In particular, the protocol MUST DEFINE ITS OWN AUTHENTICATION
MECHANISMS.

I disagree. I believe protocols should not unnecessarily invent new
authentication mechanisms any more than they should invent new
cryptographic
algorithms. If there is an existing one that is suitable, it's better to
use it than to do something a little different because it simplifies
analysis.

But I agree that assumptions about those protocols must be made explicit,
so that changes in those protocols later a less likely to introduce
weaknesses. By specifying that we use the ESP Integrity Protection
mechanisms, we're assuming that ESP has no weak Integrity Protection
algorithms (which it currently doesn't, but could in the future). I'd
be willing to narrow the reference to specific ESP options (e.g. HMAC MD5
and HMAC SHA1), or even a single one. That would prohibit later
introduction of weaker algorithms in the future, while still making
it syntactically obvious how we would migrate to a stronger one
(e.g. HMAC SHA2).

----------

But I believe all of what appears to be disagreement is largely
theoretical.
If IKEv2 includes some additional fields under the signature as you
propose,
the basic security properties are guaranteed even without depending on the
strength of the Integrity Protection algorithm, and that change seems both
easy and conservative.

Will you be at the upcoming IETF? This conversation might be easier over
a whiteboard or a napkin.

           --Charlie

This footnote confirms that either (1) this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including computer
viruses, (2) this email message was sent by a virus that appends this
footnote, or (3) (most likely) the sender of this message is trying to
raise awareness of how foolish it would be to place any confidence in
footnotes like this.
Follow-Ups: