Hi, Pasi and Jouni,
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
Summary - this draft is ready for publication as an Experimental RFC. I
noticed a few Nits, noted below, but the draft is comprehensible and
reasonable, so I have no non-Nit comments.
Please look at these comments along with any other Last Call comments you
may receive.
Thanks,
Spencer Dawkins
Abstract
IKEv2 supports several mechanisms for authenticating the parties,
including signatures with public-key certificates, shared secrets,
and Extensible Authentication Protocol (EAP) methods. Currently,
each endpoint uses only one of these mechanisms to authenticate
itself. This document specifies an extension to IKEv2 that allows
the use of multiple authentication exchanges, either using different
mechanisms or the same mechanism. This extension allows, for
instance, performing certificate-based authentication of the client
host followed by an EAP authentication of the user. When backend
Spencer/Nit - phrasing a bit rough here. Perhaps "For example, this
extension allows certificate-based authentication of the client host
followed by an EAP authentication of the user."
authentication servers are used, they can belong to different
administrative domains, such as the network access provider and the
service provider.
1. Introduction
IKEv2 [IKEv2] supports several mechanisms for parties involved in the
IKE_SA. These include signatures with public-key certificates,
shared secrets, and Extensible Authentication Protocol (EAP) methods.
Currently, each endpoint uses only one of these mechanisms to
authenticate itself. However, there are scenarios where making the
authorization decision in IKEv2 (whether to allow access or not)
would benefit from using several of these methods.
For instance, it may be necessary to authenticate both the host
(machine) requesting access, and the user currently using the host.
These two authentications would use two separate sets of credentials
(such as certificates and associated private keys), or even different
Spencer/Nit: s/or even/and might even use/
authentication mechanisms.
To take an another example, when an operator is hosting a VPN gateway
service for a third party, it may be necessary to authenticate the
client both to the operator (for billing purposes) and the third
Spencer/Nit: s/both to/to both/
party's AAA server (for authorizing access to the third party's
internal network).
1.1. Usage Scenarios
Figure 1 shows an example architecture of an operator hosted VPN
Spencer/Nit: s/operator hosted/operator-hosted/
scenario that could benefit from a two phase authentication within
the IKEv2 exchange. First the client authenticates towards the
Network Access Provider (NAP) and gets access to the NAP-hosted VPN
gateway. The first phase authentication involves the backend AAA
server of the NAP. After the first authentication, the client
initiates the second authentication round that also involves Third
Party's backend AAA server. If both authentications succeed, the
required IPsec tunnels are set up and the client can access protected
networks behind the Third Party.
2.1. Solution Overview
The AUTH payloads are calculated as specified in [IKEv2] Section 2.15
and 2.16. If EAP methods that do not generated shared keys are used,
it is possible that several AUTH payloads with identical contents are
sent. With this kind of EAP methods, the purpose of the AUTH payload
Spencer/Nit: s/methods/method/
is simply to delimit the authentication exchanges, and ensure that
the IKE_SA_INIT request/response messages were not modified.
2.3. Example 2: Mixed EAP and Certificate Authentications
Another example is shown in Figure 3: Here both the initiator and the
responder are first authenticated using certificates (or shared
secrets); this is followed by an EAP authentication exchange.
5. Security Considerations
Security considerations for IKEv2 are discussed in [IKEv2]. The
reader is encouraged to pay special attention to considerations
relating to the use of EAP methods which do not generate shared keys.
However, the use of multiple authentication exchanges result in some
new security considerations as well.
Spencer/Nit: s/some new security considerations/at least one new security
consideration/?
In normal IKEv2, the initiator authenticates the responder before
revealing its identity. When multiple authentication exchanges are
used to authenticate the responder, the initiator has to reveal its
identity before all of the responder authentication exchanges have
been completed.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
