[Gen-art] Gen-ART review ofdraft-eronen-ipsec-ikev2-multiple-auth-02.txt

["Spencer Dawkins" <[e-mail]>]

I had reviewed the 01 version at Last Call time, and found nothing except 
nits to mention. Version 02 is good to go as an Experimental RFC, from my 
perspective.

Thanks,

Spencer


> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/gen-art
> 



_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art