Re: The remaining IKEv2 issues

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Aug 22, 2003 at 01:29:31PM +0300, Tero Kivinen wrote:
> I agree that "MUST NOT" will be crippling the deployment, but "SHOULD
> NOT" is fine. From the RFC-2119:
> 
> ----------------------------------------------------------------------
> 4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
>    there may exist valid reasons in particular circumstances when the
>    particular behavior is acceptable or even useful, but the full
>    implications should be understood and the case carefully weighed
>    before implementing any behavior described with this label.
> ----------------------------------------------------------------------
> 
> So I think non-kg EAP methods SHOULD NOT be used. There are cases
> where they are acceptable, or even useful, but the full implications
> of using them should be understood...

SHOULD NOT seems to be a good compromise for this issue.  In order to
move things along, I'm taking off my wg chair hat, and proposing the
following text.  Any comments from the working group, before I suggest
that Charlie make the changes to the ike v2 document?

						- Ted

Proposed change, in section 2.16, in the second to last paragraph,
which currently reads:

   For EAP methods that create a shared key as a side effect of
   authentication, that shared key MUST be used by both the Initiator
   and Responder to generate an AUTH payload using the syntax for shared
   secrets specified in section 2.15. The shared key generated during an
   IKE exchange MUST NOT be used for any other purpose. For EAP methods
   that do not establish a shared key, there will be no AUTH payloads in
   the final messages.

Delete the last sentence, ("For EAP methods that do not establish...")
and add the following paragraph:

EAP methods that do not establish a shared key SHOULD NOT be used, as
they are subject a number of man-in-the-middle attacks if these EAP
methods are used in other protocols that do not use a
server-authenticated tunnel.  Please see the Security Considerations
section for more details.  If EAP methods that do not generate a
shared key are used, there will be no AUTH payloads in the final
messages.

In the security considerations section, replace the last paragraph
with the following text:

When using an EAP authentication method that does not generate a
shared key for protecting a subsequent AUTH payload, certain
man-in-the-middle and server impersonation attacks are
possible.[EAPMITM] These vulnerabilities occur when EAP is also used
in protocols which are not protected within a secure tunnel.  Since
EAP is a general-purpose authentication protocol, which is often used
to provide single-signon facilities, an deployed IPSEC solution which
relies on an EAP authentication method that does not generate a shared
key can become compromised due to the deployment of an entirely
unrelated application that also happens to use EAP, but in an
unprotected fashion.  Note that this vulnerability is not limited to
just EAP, but can occur in other scenarios where an authenticatoin
infrastructure is reused.  For example, if the EAP mechanism used by
IKEv2 utilizes a token authenticator, and the enterprise deploys a
non-encrypted web form which accepts the input from the token
authenticator, a man-in-the-middle attacker could impersonate the web
server, intercept the token authentication exchange, and use it to
initiate an IKEv2 connection.  For this reason, use of EAP methods
which do not generated shared keys SHOULD be avoided where possible.
Where they are used, it is extremely important that all usages of
these EAP methods SHOULD utilize a protected tunnel, where the
initiator validates the responder's certificate before initiating the
EAP exchange.  Implementors SHOULD describe the vulnerabilities of
using non-key-generating EAP mechanisms in the documentation of their
implementations so that the administrators deploying IPSEC solutions
are aware of these dangers.

Add the following reference:

[EAPMITM]   N. Asokan, Valtteri Nierni, and Kaisa Nyberg,
	"Man-in-the-Middle in Tunneled Authentication Protocols",
	http://eprint.iacr.org/2002/163, November 11, 2002.