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

[no subject]



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: <F5F4EC6358916448A81370AF56F211A50127B15B@RED-MSG-51.redmond.corp.microsoft.com>
Thread-Topic: Possible problem in IKEv2?
thread-index: AcOflFhkn62JH09oTWaVIAAE8m9cMAYtXn6w
From: "Charlie Kaufman" <charliek@microsoft.com>
To: <Pasi.Eronen@nokia.com>, <ipsec@lists.tislabs.com>
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: owner-ipsec@lists.tislabs.com
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: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com] On Behalf Of
Pasi.Eronen@nokia.com
Sent: Friday, October 31, 2003 1:50 AM
To: ipsec@lists.tislabs.com
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