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

Re: IKEv2 and SIGMA



Dan,

Let me answer to two main points. Other issues can be discussed in another
opportunity (it is 2am here:)
I have good news and bad news for you:

(1) *Good news* I think that the use of ESP in Appendix B instead of the complex
language of IKE's appendix B is a GOOD THING. I recommend keeping it.
HOWEVER, as I already said, use it ONLY for the purpose of 
ID PROTECTION (not for protocol authentication)!!!

For KEY-EXCHNAGE AUTHENTICATION all you need to add is a prf-ed HASH!
That is straigthforward to specify (I already did in few lines)
and requires no change in Appendix B.

(2) *Bad news* In response to my example (7) you write:

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

IT IS VERY DANGEROUS! DOING WHAT YOU SUGGEST IS INSECURE!

That's the whole point. These things are NOT intuitive!
(Or become intuitive only after years of formal analysis of protocols)

I have said this since 1995:
SIGNING YOUR OWN ID IS NOT ENOUGH: YOU MUST APPLY TO THE ID A PRF (OR MAC)
KEYED WITH THE DH KEY!!!

Hugo

PS: an angry comment at 2 AM: some people recommend using 8000-bit DH 
exponents for security, but we can easily accept key exchange protocols 
with flawed authentication! :(



On Mon, 26 Nov 2001, Dan Harkins wrote:

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



References: