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)
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.)
The EAP integration with IKEv2 has been purposely designed for
the the asymmetrical network access scenario and unidirectional
authentication.
(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.)
Existing EAP methods contain elements and functionality not needed
in IKE, e.g. because IKE performs SA negotiation on its own.
(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.
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.
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.
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.
(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.
(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: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf