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

Re: IKEv2 and SIGMA



Charlie, find several responses below.

> 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).
> 
 As I already explained in quite a lengthy response to Dan on this
same issue, I do NOT see these "clarifications" as a replacement 
for good, robust and provable protocol design.
For all the reasons I mentioned in that note you have to include the 
prf under the signature, and use ESP only for identity encryption.

> 
>  >
>  > 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?

ESP specifications are defined to secure raw data, not functioning
as an authentication mechansim in a key exchange protocol. 

In your current specification you are not using ESP for the purpose 
it was specified and then you are not ensuring the security of the protocol
and are taking unnecessary risks.

The reason that I agree with ESP for identity protection is that in this case
the required functionality is the same as defined for ESP: the raw data being
protected is the identities (and signature).



> 
> I prefer specifying the fields to be concatenated and signed rather than
> the HMAC construction because of the complexity of specifying signing an

I am all for simplicity and elegance, but not at the expense of essential
security. And the design I propose is not less simple or elegant
(and has a proof of security). 
It even saves communication and latency.

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

This is a misunderstanding. 
The prf (or HMAC) under the signature does NOT replace the hashing done 
by the signature scheme. In the case of DSS the initiator will compute 
SIG_I as DSS_I(SHA-1(HASH_I).  (Here DSS_I means DSS using I's private key).

Same if you were using RSA under some hash-based standard format.

If this is not clear please let me know (this may well deserve a 
clarification in the specifications).




> 
>  > 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?

I, too, am RELUCTANT to have options. (This does not mean that no option
is admissible -- e.g. you have optional stuff in your protocol too. The
issue is to minimize options without sacrificing basic requirements and 
without penalizing the whole protocol because of functionality that is not
always required: e.g., DH in phase 2 or Dos protection in phase 1.)

My proposal is simple: replace your Phase 1 protocol with SIGMA-0 (sec 2.1
of my draft). In the cases that DoS protection is activated by the responder
this becomes the protocol SIGMA depicted in sec 2.2
(In other words, SIGMA is just the expansion of SIGMA-0 to the case 
that DoS protection has been activated.)

The only optional payload that I have and you dont is OIDi in the first 
message, something that can be very useful in helping the responder 
to make policy decisions immediately after receiving the first 
message from I. From my real-life experience with IPsec this is a
USEFUL thing to have. 

The other difference is that I left unspecified the piggy-backing of 
IPsec "traffic selectors". Your solution using the TS payload 
fits perfectly well in SIGMA.

As for pre-shared mode: I present that in my draft as a basis for discussion.
However, discussing this is "out of scope" now since we are far from
any consensus in the need to have such a mode.
My intention with this description was to show how that pre-shared mode can be
made "identical" to signature mode. Note that SIGMA-0 is EXACTLY P-SIGMA
where on top of HASH you apply a signature. Anyway, this is subject for
further discussion at some other time.


> 
>  > 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

P-SIGMA does not have this problem. You can have a pointer to the key 
via OIDi, or you can decouple SKEYSEED_e from SKEYID. In the latter 
case you give up on active protection of I's identity and you pay 
with (at least) one extra message.

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

agreed.

> 
>  > 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

I am not inventing new cryptographic algorithms. 
I am designing a secure protocol with EXISTING mechanisms.
But I need to have full control of how these mechanisms are defined to
be able to ensure the protocol's security.

> use it than to do something a little different because it simplifies
> analysis.

It does not just simplify analysis. It enables it.
Do not underestimate analysis for these protocols.  They are immensely 
subtle!  This approach also makes the protocol secure and robust 
to "environment changes".  And the most important thing: you get these
fundamental benefits with some performance improvement bonus too :)

It is not my fault that the need for these mechansims is so un-intuitive.
But I can show you in the analysis where each of these "little details" 
become essential.
People seem to think: "what's the big deal of changing this or other detail"
Well, these are the details that move you from being secure to insecure
(or viceversa)

> 
> 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).

As I said, we can agree to keep ESP for identity protection only 
(and then have specific algorithms as must-to-implement).

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

I am sure that all disgreements will disappear over a napkin.
I will make an effort to come to the meeting but I am not sure yet.
It is a long trip and in class time...

In one way or another I hope we will keep making progress
towards convergence of our proposals.

Hugo

> 
>            --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: References: