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

Re: IKEv2 and SIGMA

On Tue, 27 Nov 2001 01:18:56 +0200 you wrote
 > 
 > 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)!

We were gaining is losing lots of text describing a separate magic number
space, chaining of IVs, padding, all that stuff that's in IKEv1 that is
much better described in ESP.

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

That can be solved by wordsmithing of Appendix B.

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

This is a good point.

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

If the bidirectional nature of the key is not a problem then it should not
matter where the specification is for how data is padded and formatted.
(assuming of course that that specification does not change in a way that
affects IKE-- point 2 above).

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

It is. Appendix B says, "Whereas in ESP the header that is integrity
protected but not encrypted is a total of 8 bytes (SPI+Sequence #)
plus the IV, in IKE it is the IKE Header which is 28 bytes plus the
IV (see section 7.1)."

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

No, it's motivated by the desire to make things simpler. There is very well
written text (which very few people have a problem understanding) describing
how to pad, encrypt, and authenticate a message which we'd like to refer to.
IKEv2 can repeat this text if such an in situ definition is required but
if it's not then it is convenient to refer to other text. 

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

I'm sorry, I'm not following. This is not ID protection related. It is
a specification of how to pad, encrypt, and authenticate a blob of bits.
IKEv2 could specify it itself but instead it refers to another specification.

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

In this case IDi would be signed by each party. Since you're proposing 
putting all things, including IDi, into the signed hash anyway why is it
dangerous to add just IDi to the mix of exponentials and nonces?

   Dan.
Follow-Ups: