Subject: [Mip6] [issue67] Removing EAP_ONLY_NOTIFICATION

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 05 Mar 2006 22:04:36 +0000

New submission from Vijay Devarapalli <[email-masked]>:

Jari Arkko wrote:

  The IKEv2 specification [4] requires that public key based mechanism
  be used to authenticate the home agent to the mobile node, when EAP
  is used.  This should be used by default by the mobile node and the
  home agent.  If the EAP method that is used, supports mutual
  authentication and key generation, then the mobile node MAY use EAP
  itself to authenticate the home agent.  The mobile node can request
  this by including the EAP_ONLY_AUTHENTICATION notification payload
  [8] in message 3.  If the home agent supports the
  EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP,
  it omits the public key based AUTH and CERT payloads in message 4.
  If the home agent does not support this mechanism, it rejects it by
  including an AUTH payload in message 4.  More details can be found in
  [8].

(snip)

    The use of EAP for authenticating the mobile node to the home agent
    is described in Section 8. This document recommends that if the EAP
    method used, supports mutual authentication, then EAP itself be used
    for authenticating the home agent to the mobile node also. This runs
    contrary to the recommendation in [4]. The home agent can ignore the
    recommendation in this document and implement EAP authentication as
    described in the IKEv2 specification. Security considerations
    related to the use of EAP with IKEv2 are described in [4] and [8].

I think that EAP-only auth mode in IKEv2 makes a lot of
sense. But I'm very concerned that a document from MIP6
WG overrides a MUST in another WG's main document.
Here's what RFC 4306 says:

  In addition to authentication using public key signatures and shared
  secrets, IKE supports authentication using methods defined in RFC
  3748 [EAP].  Typically, these methods are asymmetric (designed for a
  user authenticating to a server), and they may not be mutual.  For
  this reason, these protocols are typically used to authenticate the
  initiator to the responder and MUST be used in conjunction with a
  public key signature based authentication of the responder to the
  initiator.

My suggestion would be to take the specific extension of
IKEv2 out of the draft and pursue that separately. Obviously,
this extension is also very useful in non-MIPv6 scenarios, so
this is also logical from the point of view of keeping our specs
modular.

In any case, I think the above text would make [8] normative
dependency, which I don't think you want...

----------
category: Technical
draft: draft-ietf-mip6-ikev2-ipsec
messages: 206
nosy: vijay
priority: Must fix
status: No discussion
title: Removing EAP_ONLY_NOTIFICATION

_________________________________________________
Mip6 issue tracker <[email-masked]>
<http://www.mip4.org/issues/tracker/mip6/issue67>
_________________________________________________

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6