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

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Feb 2010 14:07:42 +0200

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

---

From: <[email-masked]>
Date: Thu, 18 Feb 2010 20:01:02 +0100

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: [email-masked] [mailto:[email-masked]] 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)
> 
> 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.
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Feb 2010 15:39:43 +0200

Pasi,

(Adding the working group mailing list to the discussion; previous 
discussion has been at [email-masked].)

> but that's probably not a critical factor here).

OK. And yes, I agree about the significance of roundtrips.

>    be desirable in many situations.

This formulation is better than what we had previously. I can live with 
this.

But for the record, I am still surprised that I am the only one worried 
about this. In my view this additional solution, while perhaps simpler 
on its own, will increase code size and complexity for most 
implementations. For instance, a device that serves remote access 
clients has to implement at least parts of EAP. To support 
gateway-gateway weak secrets it now has to add support for another, 
completely different authentication mode and associated configuration 
mechanisms & policies. Architecturally, it would be better to rely on 
few general solutions than to build special case "simpler" solutions 
that taken together, actually become more complex. Not to mention the 
impact on interoperability.

Jari

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 20 Feb 2010 12:05:30 -0800 (PST)

Hi Jari,

  I don't believe the simpler solution will increase code size or
complexity when compared to the the reuse EAP solution. In fact,
it will be less on both counts.

  In both cases the core key exchange will have to be implemented
and in both cases some configuration glue will be needed. But in the
reuse EAP solution there is the added code to implement an EAP client
and its accompanying state machine, which no IKEv2 gateway currently
needs to implement. In addition, a true EAP server, and accompanying
state machine, will need to be implemented and IKEv2 gateways will
no longer get away with just being a "pass through authenticator".
The reuse EAP solution will also have to implement some new
fragmentation/reassembly code since EAP methods (like ones supporting
"weak" shared secrets) have to roll-their-own. The reuse EAP solution
will also have to implement other, unneeded, exchanges (which is why the
roundtrips/overhead are greater). When you compare the two, it really
is obvious that trying to use EAP in this case increases code size and
complexity versus just doing the exchange as part of IKE.

  EAP is attractive because it provides a generic authentication solution,
but here there is really only one type of authentication to do-- using a
"weak" shared secret. It is also attractive because authentication can be
centralized with one server serving many network access points. But in
this case both sides must have possession of the shared secret and both
sides must be capable of initiating the exchange so use of a centralized
server is not possible. So all of the attractive features of EAP do not
apply and we're left with the undesirable features of EAP-- duplicate
identity exchanges, yet more fragmentation/reassembly code, and
pointless overhead.

  I don't think it's better architecturally to reuse EAP in this situation.
EAP is a network access protocol where one side attempts to obtain network
access from another. There are strict roles played in EAP. In this
situation there are no roles and creating a host-to-host SA or network-
to-network SA is not really the same thing as obtaining network access.

  There are some things that EAP is not appropriate for and this is
one of them.

  regards,

  Dan.