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

Re: IKEv2 and SIGMA

On Mon, 26 Nov 2001, Dan Harkins wrote:

>   Hugo,
> 
>   Thanks for pointing this out. It is our intent that the integrity
> check in ESP be mandatory when ESP is protecting IKEv2 messages.
> The peers sign each D-H exponential and each nonce and SKEYID_a,
> derived from the D-H exponentials and the nonces, is used as the
> key to the ESP integrity check. I think some wordsmithing in Appendix
> B is in order.
> 

Dan, 

while you can formally "solve" the immediate security issue by rewording 
Appendix B, I believe that the design weakness still stays there after 
the re-wording:

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.

By using ESP for the AUTHENTICITY of the protocol you are violating this
principle. This is no just a dogmatic approach to design. I can see
many things going wrong by using ESP. I am attaching at the end a 
sample list of 7 different specific weaknesses due to reliance on ESP.
(I am moving this long list to the end for the benefit of the rushing
readers; however, anyone that is interested in the REAL SECURITY of these 
protocols should seriously consider these subtle but essential issues).

Now, Dan, what makes this discussion quite unnecessary is that you are not 
gaining anything by resorting to an external authentication mechanism! 
You can do it RIGHT and at the same processing/performance/complexity 
cost (or less)!

Hugo

PS: On the inappropriateness of using ESP for providing authentication 
in IKEv2 - seven examples (please, read them seriously)

(1) authentication in ESP is optional (as we said, IKEv2 should mandate 
its use with STRONG integrity protection);

(2) the specification of ESP, or its underlying assumptions (such as MUST 
vs MAY), may change one day without relation to its use in IKE in a way that 
will compromise IKE's security (this concern would be valid even for a stable 
protocol, more so for ESP whose version 3 was just posted)

(3) already now IKEv2 VIOLATES one of the current assumptions of ESP: 
IKEv2 uses the same SKEYSEED_a/e in both directions while ESP
ASSUMES unidirectional keys for protecting traffic. This violation
can easily break a perfectly secure ESP mechanism (stream ciphers are an
example).
[Yes, I know that can be re-specified too in IKEv2, but that is not the point]

(4) since the session identifier contained in HDR is NOT included under 
the ESP scope, the the binding between the key and party IDs to the specific 
session is not fully achieved.  This is important when several simultaneous 
sessions between the same peers are run (which is certainly a case 
that IKE should care about).

(5) the application of ESP in IKEv2 is mainly motivated by a secondary
security requirement, namely identity protection, and the essential role
of ESP in protocol authentication is not made explicit in the protocol design;

(6) This "obscurity" may cause seemingly unrelated changes in the protocol
to break its security. For example, if one eventually decides to make 
ID protection optional (this happened in the past to both Photuris 
and IKEv1 -- the latter via aggressive mode) then the WHOLE security of 
IKEv2 is compromised 

(7) more subtle, seemingly unrelated changes in the protocol may turn the
protocol insecure. An example:
Assume that we decide (and I would suggest doing that) to add an optional
identity payload in the first message from I to R (similar to the field OIDii
in SIGMA) to facilitate R's policy decisions from the start of the protocol
(e.g. to help deciding on SA responses). Then someone (that does not need
ID protection) could send IDi in this first message and omit it from
message 3. Apparently, this should not change the protocol security
but it DOES. In this case the integrity transform of ESP will NOT be applied
to IDi and the security of the protocol would be BROKEN.
This is subtle, true and dangerous...


On Mon, 26 Nov 2001, Dan Harkins wrote:

>   Hugo,
> 
>   Thanks for pointing this out. It is our intent that the integrity
> check in ESP be mandatory when ESP is protecting IKEv2 messages.
> The peers sign each D-H exponential and each nonce and SKEYID_a,
> derived from the D-H exponentials and the nonces, is used as the
> key to the ESP integrity check. I think some wordsmithing in Appendix
> B is in order.
> 
>   Dan.
> 
> On Mon, 26 Nov 2001 13:28:56 +0200 you wrote
> >
> > 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).
> > 
> > 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].
>
Follow-Ups: References: