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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf