ietf
[Top] [All Lists]

RE: WG Review: Recharter of IP Security Maintenance and Extensions (ipsecme)

2010-02-18 13:01:34
Hi Jari,

You're right that implementing a "weak shared secret" EAP method (both
the EAP peer and EAP server roles) on both IPsec nodes, combined with
the "EAP mutual authentication" work item (also in the new charter)
could be used in this situation, and would result in roughly the same
functionality (perhaps with slightly more roundtrips/other overhead --
but that's probably not a critical factor here).

The WG discussed this at length (both in Hiroshima and on the list
afterwards), and the general feeling was that having a simple
IKEv2-only solution would still be desirable, and could be more likely
to get implemented/deployed in situations that currently don't use
EAP.

Perhaps the currently proposed text is slightly misleading about
this; it could be read to say that EAP would not work. As we
discussed on the IESG telechat earlier today, that paragraph
would benefit from slightly more clearer explanation, e.g:

OLD:
   However, user-configured shared secrets are still useful for many
   other IPsec scenarios, such as authentication between two servers
   or routers. These scenarios are usually symmetric: both peers know
   the shared secret, no back-end authentication servers are involved,
   and either peer can initiate an IKEv2 SA. These features make using
   EAP (with its strict client-server separation) undesirable.
NEW:
   However, user-configured shared secrets are still useful for many
   other IPsec scenarios, such as authentication between two servers
   or routers. These scenarios are usually symmetric: both peers know
   the shared secret, no back-end authentication servers are involved,
   and either peer can initiate an IKEv2 SA. While it would be
   possible to use EAP in such situations (by having both peers
   implement both the EAP peer and the EAP server roles of an EAP
   method intended for "weak" shared secrets) with the mutual
   EAP-based authentication work item (above), a simpler solution may
   be desirable in many situations.

Comments? 

Best regards,
Pasi

-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
ext Jari Arkko
Sent: 16 February, 2010 14:08
To: IETF Discussion
Subject: Re: WG Review: Recharter of IP Security Maintenance and
Extensions (ipsecme)

This new charter looks great otherwise, but I did have a reaction on
this:

- IKEv2 supports mutual authentication with a shared secret, but this
mechanism is intended for "strong" shared secrets. User-chosen
passwords are typically of low entropy and subject to off-line
dictionary attacks when used with this mechanism. Thus, RFC 4306
recommends using EAP with public-key based authentication of the
responder instead. This approach would be typically used in
enterprise
remote access VPN scenarios where the VPN gateway does not usually
even have the actual passwords for all users, but instead typically
communicates with a back-end RADIUS server.

However, user-configured shared secrets are still useful for many
other IPsec scenarios, such as authentication between two servers or
routers. These scenarios are usually symmetric: both peers know the
shared secret, no back-end authentication servers are involved, and
either peer can initiate an IKEv2 SA. These features make using EAP
(with its strict client-server separation) undesirable.

The WG will develop a standards-track extension to IKEv2 to allow
mutual authentication based on "weak" (low-entropy) shared
secrets. The goal is to avoid off-line dictionary attacks without
requiring the use of certificates or EAP. There are many
already-developed algorithms that can be used, and the WG would need
to pick one that both is believed to be secure and is believed to
have
acceptable intellectual property features. The WG would also need to
develop the protocol to use the chosen algorithm in IKEv2 in a secure
fashion. It is noted up front that this work item poses a higher
chance of failing to be completed than other WG work items; this is
balanced by the very high expected value of the extension if it is
standardized and deployed.


Frankly, I'm not too convinced about the arguments above. First of all,
EAP does not require separate back-end servers. And with IKEv2 itself
already having to decide which side initiates, I do not see a problem
running a password-based EAP method in the same direction.

Also, it is true that a new native scheme is slightly easier to
implement on top of IKEv2 than EAP + an EAP method. However, if you
look at the issue from a system level, does that mean that you are
forced to implement this new scheme *and* EAP, because you already
need EAP for many other situations? For someone working with a
full-blown, all features supported implementation of IKEv2 this
means *more* code, not less.

Perhaps there are some better arguments why you must choose a
non-EAP solution. Or maybe the charter should require specific
functionality to not dictate the solution by excluding EAP. Or maybe
existing standards are already sufficient and we just need guidance
on how to apply them in the best way for this problem.

In any case, I would like to understand better why this work is in the
charter.

Jari

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf