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