Subject: Re:

From: [email-masked]
Date: Tue, 2 Dec 2003 07:53:14 -0500 (EST)

SMTPSVC(6.0.3790.1039);
	 Mon, 1 Dec 2003 12:57:34 -0800
12:57:42 -0800
Microsoft SMTPSVC(6.0.3790.0);
	 Mon, 1 Dec 2003 12:57:41 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Subject: RE: Possible problem in IKEv2?
Date: Mon, 1 Dec 2003 12:57:44 -0800
Message-ID: <[email-masked]>
Thread-Topic: Possible problem in IKEv2?
thread-index: AcOflFhkn62JH09oTWaVIAAE8m9cMAYtXn6w
From: "Charlie Kaufman" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
X-OriginalArrivalTime: 01 Dec 2003 20:57:41.0761 (UTC) FILETIME=[C2DAAF10:01C3B84D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id PAA24802
Sender: [email-masked]
Precedence: bulk

You're right!

While non-key-generating EAP methods are explicitly discouraged, it is
likely people will use them and we should make the protection as good as
we can. The AUTH payloads have two purposes in the cryptographic
exchange: to authenticate the parties and to protect the first two
messages from modification. These functions could have been provided
independently, but they weren't.

The threat here is that a man-in-the-middle could trick IKE peers using
a non-key-generating EAP method to use weaker cryptographic algorithms
than the strongest that they both support. They would both have to be
willing to use the weaker cryptographic algorithms, and if the attacker
can break the weaker algorithms in real time (during the exchange) then
there is no way we can defend against it. So this is clearly a fringe
case. But we've engineered for much more fringe cases than this in the
past.

I can think of a number of ways of fixing this, but yours has the virtue
of minimizing word changes to the spec and lines of code to an
implementation. This is very late in the process to be making
cryptographic changes, but I feel like this one is worth doing.

**Can I get a ruling from our chairs?**

	--Charlie

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, October 31, 2003 1:50 AM
To: [email-masked]
Subject: Possible problem in IKEv2?

Hi,

When using a non-key-generating EAP method, the initiator never
generates any AUTH payloads. In this case, KEi/Ni are authenticated
implicitly (by the ability to provide correct EAP Responses
that are protected with SK_ai). However, it seems the client's
AUTH payload has a second purpose as well: to provide integrity
protection for the first message.

If the initiator never generates an AUTH payload, is there anything
that prevents an attacker from, e.g., removing some proposals
from SAi1? (Or modifying some other payloads than KEi/Ni in the
first message?)

(Or have I missed some detail of this?)

If this is indeed the case, I think the easiest solution would be
to always include the AUTH payloads; if the EAP method does not
generate keys, use some known fixed string (such as a single zero
octet) as the key. Since the AUTH payload is protected by SK_ai,
this should ensure that the first message was not modified (by
someone who doesn't know the initiator's private DH value).

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 16:38:14 +0200

> we can. The AUTH payloads have two purposes in the cryptographic

Right.

> case. But we've engineered for much more fringe cases than this in the

Indeed.

> cryptographic changes, but I feel like this one is worth doing.

I agree.

--Jari

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 2 Dec 2003 21:47:20 +0200 (IST)

The solution proposed by Pasi seems fine except that instead of using a
dummy key to compute the AUTH value by the initiator why not specify (in
sec 2.16):

   "For EAP methods that do not establish a shared key, the AUTH value
    will be computed using the negotiated integrity algorithm keyed with
    the key SK_ai."

Cryptographically speaking a MAC or PRF keyed with a fixed dummy string
(say all 0's) may be, in principle, very weak and easily forgeable. SO why
not use the available key SK_ai for integrity protecting the first msg via
the AUTH value? It is important, however, that the same integrity
algorithm used under the SK{} construct (which already uses SK_ai)
be used for computing the above AUTH value.
Do you see any problem with this solution?

BTW, in passing I noted the following sentence in sec 1.2:

   The Initiator [...] integrity protects
   the contents of the first two messages using the AUTH payload (see
   section 2.15).

In the current specification of ikev2 AUTH as computed by the intiator
only protects the first msg (while the responder's AUTH protects the
second msg). I suggest to rephrase accordingly.

Hugo

> case.But we've engineered for much more fringe cases than this in the
> past.
>
> Ifthe initiator never generates an AUTH payload, is there anything
> octet) as the key. Since the AUTH payload is protectedby SK_ai,