Hi Matt,
As commented by Andreas, IKEv2 allows any EAP method to be used.
For instance, the OpenIKEv2 implementation
(http://openikev2.sourceforge.net) allows you to configure the VPN
gateway as an EAP pass-throwgh authenticator, that is, just forwarding
the received EAP packets from the client
pasi.ero...@nokia.com writes:
> RFC 4543 specifies how to use AES-GMAC mode in AH and ESP and how to
> negotiate them in IKEv1 and IKEv2 (see Section 5, 1st paragraph).
>
> However, as Soo-Fei Chew pointed out, the IANA considerations text in
> the final document didn't actually ask IANA to assign
Thanks for looking into this, Tero!
I would propose we just allocate both AH transform identifier
and Authentication Algorithm numbers for AH_AES_128/192/256_GMAC.
This is what e.g. RFC 3566 did for XCBC-PRF.
While in theory it could be nice to have more text explaining how this
works, compared
Vijay Devarapalli wrote:
> In the redirect-during-IKE_AUTH cases, the only time the IKEv2 SA is
> not valid is when EAP is used and the redirect is done based on the
> unauthenticated ID. In all other cases, the IKEv2 SA is valid and
> should be torn down with an INFORMATIONAL exchange.
>
> IMHO,
