No Subject

[owner-ipsec@lists.tislabs.com]

(1Cust116.tnt1.sedona.az.da.uu.net [68.129.19.116])
	by TheWorld.com (8.12.8p1/8.12.8) with ESMTP id h7LGk3HU010376;
	Thu, 21 Aug 2003 12:46:15 -0400
Message-Id: <5.1.1.6.0.20030821012129.00adc220@pop.theworld.com>
X-Sender: dpj@pop.theworld.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Date: Thu, 21 Aug 2003 02:37:08 -0400
To: Jari Arkko <jari.arkko@kolumbus.fi>
From: David Jablon <dpj@theworld.com>
Subject: Re: EAP-IKEv2 MITM prevention (Was: Re: The remaining IKEv2
   issues)
Cc: ipsec@lists.tislabs.com
In-Reply-To: <3F42A76A.1050800@kolumbus.fi>
References: <E19oneL-0003NU-00@think.thunk.org>
  <E19oneL-0003NU-00@think.thunk.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

It's confusing to discuss patent infringement issues in a statement of
what is "cryptographically possible".  It introduces the notion of something
being "cryptographically possible" in some parts of the world, but not
elsewhere.  For this and other reasons one should separate statements
of technological possibility from statements about IP rights or other
deployment issues.

At 01:40 AM 8/20/2003 +0300, Jari Arkko wrote:
>[...]
>USERNAME AND PASSWORD AUTH
>===========================
>
>Charlie: I am disappointed that
>EAP does not include simple user name and password, but am reassured that
>people assure me that you can do it by telling EAP it's a one time password.
>
>I don't believe it's cryptographically possible to do better than EAP in IKEv2
>does if you assume the user has a password and the server holds a non-password
>equivalent and doesn't either infringe a patent or require periodic reset
>(as with OTP). I believe this case is important. Tell me how I'm wrong.

Also, I don't know exactly what is believed to be possible in the above, but
there are augmented password-authenticated key agreement methods
(see IEEE P1363.2) that are available, under the above assumptions, for use
in most of the world.   (semi-plug:  And, of course, it's possible for any
vendor to acquire appropriate license for their customers to use any
cryptographically possible method anywhere, should they care to do so.)

>[...]
>Bernard:  It's very hard to argue that support of PAP is a requirement
>because RFC 2865 supported CHAP as well as does every RADIUS server I've
>ever seen, and MD5-Challenge is mandatory-to-implement in RFC 2284.
>
>If you buy the idea that all legacy RADIUS servers support CHAP or
>MD5-Challenge, then this implies that those same servers have access to
>cleartext passwords and could be upgraded to support RADIUS/EAP with a
>variety of methods.  All the commercial RADIUS servers and several of the
>free ones support MS-CHAPv2 in some form, or other password based methods
>offering mutual auth and key derivation (Interlink even supports EAP
>SKEME).

Correction:  I think that mutual auth password based method is EAP SPEKE,
Simple Password-authenticated blah blah blah, not SKEME.

-- David