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

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Feb 2010 22:39:57 +0200

Alfred,

Thanks for your response. A few additional thoughts inline:

> (1)
> EAP is asymmetric, and so far EAP support in IKEv2 only serves to
> authenticate the IKE initiator to the IKE responder.
> The IKE responder (most likly actually a server or a security
> gateway protecting the server) still authenticates to the
> client via other means, e.g. using a certificate.
>
> (That's almost fairly described in the draft charter.)
>   

EAP is asymmetric in the sense of how the protocol works. However, there 
are plenty of EAP methods that are mutually authenticating. We need to 
distinguish between the underlying protocol mechanics and the security 
properties. We absolutely need mutual authentication. We also need the 
ability of either side in the exchange to initiate, but I think that 
could be arranged with EAP, too.

> The EAP integration with IKEv2 has been purposely designed for
> the the asymmetrical network access scenario and unidirectional
> authentication.
>   

Yeah. Well, that was made with a particular use of EAP in mind. Not 
necessarily the use that I would recommend, or even the most widely used 
mode of EAP. Note that the charter already fixes another bug from the 
original IKEV2 EAP design: it removes the requirement to do 
cert-authentication of the IKEv2 responder when EAP is used.

> (2)
> EAP adds additional round trips to the IKE handshake - most
> likeley two or more full round trips (depending on the EAP
> method), and thus it adds delay to the setup of the IKE SA.
>
> (That seems to miss from the reasoning in the draft charter.)
>   

True. My mail was not necessarily trying to say that we can't do this, 
but try to search for better reasons why we can't use EAP. Maybe 
roundtrips is one, but again, I'm not that convinced. I would be far 
more convinced about that argument for the millions of remote access 
clients. But those are very likely to employ EAP anyway, for a variety 
of reasons, including the ability to use the same credentials for 802.11 
and IKEv2 access.

> Existing EAP methods contain elements and functionality not needed
> in IKE, e.g. because IKE performs SA negotiation on its own.
>   

Some do. The question is whether there's an EAP method that is based on 
weak secrets and is otherwise suitable. Not all EAP methods may carry 
extra baggage.

> (3)
> The target scenario is _symmetric_, i.e. it is indeterminate
> which peer will be in the role of IKE initiator and IKE responder,
> and this balance in role should preferably be reflected in the
> mutual authentication method(s) used.
>
> If you wanted to apply EAP authentication bidirectionally,
> either a second EAP exchange would have to be carried out
> (sequentially or in parallel), or there would be the need
> forcibly overlay bidirectionality to the EAP/IKEv2 integration.
>   

No, even IKEv2 itself is asymmetric as a protocol exchange. You could 
dictate that for this type of an application, EAP should be run in the 
same direction as IKEv2 exchange happens to run. This would seem to 
solve the problem, or am I missing something? Of course the EAP method 
needs to be mutually authenticating. But as noted there are plenty of those.

(If the argument for this work is that there is no mutually 
authenticating EAP method that can use weak secrets, then, well, maybe 
we should standardize one.)

> IMO, the latter would be very questionable from an
> architectural PoV.  Note that in this model, IKEv2 would have
> to be changed in a non-trivial manner, since the 'embedding'
> of an EAP exchange into IKEv2 takes the proper sequencing of
> messages (payloads) and actions into account ('proper' from a
> cryptographical point-of-view).  The interface to EAP would
> need to be changed to carry information about the state and
> outcome of authentication in both directions: both peers
> at a minimum need the two bits of information indicating
> "we have authenticated the peer" and "the peer has successfully
> authenticated us", and at different stages of the IKE handshake.
>
> In the former case (using two independent EAP exchanges
> with existimg EAP methods and the current interface between
> EAP and IKE, and initiated by the two peers "independently"),
> non-trivial changes to IKEv2 payload sequences and state machine
> would perhaps be needed as well, and a lot more messages would
> need to be exchanged.
>
> So it looks like using EAP for bidirectional authentication
> in IKE would make necessary a lot of changes, and result in
> a solution that could not be faster than in the case of
> unidirectional EAP authentication, with more round trips
> needed and greater latency.
>   

See above. But maybe we should first decide what the criteria for 
quality is. I'm not sure its the number of roundtrips. Code size might 
be a better criteria. But if you have to do EAP and this new thing, 
that's more code than just EAP.

> Note that existing EAP methods that make use of passwords
> and provide mutual authentication (EAP-PAK comes into mind)
> do so in an asymmetric manner -- still the client/server roles
> are defined (I apologize for not using EAP terminology in this
> context but designating higher level roles of the entities),
> and the (network access) server is authenticated by other means.
> Thus, EAP-PAK follows the same model as IKEv2 with EAP in general,
> includes functionality already provided by IKE on its own, and
> hence does not offer a solution for the problem under consideration.
>   

Lets assume there are two peers A and B, and they share a secret S. Lets 
further assume there's an EAP method X that can use S to do mutual 
authentication. Now, if the IKEv2 initiator is required to act as the 
EAP peer and use X, can you see any problem with this model?

> I'd appreciate some elaborations to this end in the revised
> charter in order to make the rationale behind that
> statement-of-direction more transparent to folks with less
> intimate knowledge of IKEv2 internals than typically found
> in the WG.
>
> (4)
> While I agree that EAP does not _need_ backend AAA, its
> design apparently is customized for such environments.
> EAP integration with IKEv2 was designed to leverage existing EAP
> implementations and infrastructure, where possible, and thus is
> also oriented towards such environments.
>   

Well, but there isn't really anything additional in the protocols to 
force you to use AAA. Its possible that an implementation only offers a 
RADIUS API, of course.

> (5)
> Existing wireless network deployments have to deal with asymmetrical
> cases, most importantly authentication between mobile clients and
> "the network", and network-internal symmetrical peer-to-peer
> authentication, e.g. between access routers for secure fast handover
> management.  Whereas EAP seems appropriate (an indeed is used) for
> the former case, I've never heard that EAP would also be used, or
> there be a requirement to use it for the latter purpose -- even in
> other SDO / proprietary protocol stacks.
>
> However, you have much better insight into such deploymants and
> standards than I have;  so please tell me if I'm wrong.
>   

I can't think of any peer-to-peer deployments of EAP either. But by 
definition the proposed new scheme isn't deployed either :-) Can we 
discuss this based on the actual capabilities of the protocols instead?

Jari

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 16 Feb 2010 20:51:38 +0100 (MEZ)

Jari,
reading your contribution
  <http://www.IETF.ORG/mail-archive/web/ietf/current/msg60267.html>,
a few point come to mind.

I have not been actively participating in the discussion of the
revised ipsecme charter, so this note gives me an opportunity
to point to facts and arguments that could be taken into account
in clarifying and further enhancing the revised charter.

(1)

(2)

(3)

(4)

(5)

(6)
Last week, RFC 5683 has been published, which specifies the PAK
(Password-Authenticated Key Diffie-Hellman Exchange) scheme for
the IETF.  At first glance, the one-and-half round-trips needed for
PAK (three messages,  A --> B --> A --> B ) seems well suited for
instantiation/adaption and integration in the basic IKEv2 handshake.
So there indeed seem to exist candidate building blocks already
approved by other SDOs that promise a solution that matches well
with the goals of efficiency and short delay.

This should not be taken as a statement of endorsement of PAK for
this purpose; I simply want to point out that there is recent
evidence that this work item plan and the goals in the revised
ipsecme charter seem to be sound.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+