Nico Williams writes: > We already have three generic authentication frameworks: SASL, > GSS-API, and EAP. Must we add a fourth one? (We also have a number > of less generic ones, such as the ones in SSHv2, TLS, ...).
I do not consider this to be generic authentication framework. I consider this being IKEv2 payload format for encapsulating different secure password authentication methods to the IKEv2 so those different methods can co-exist in the same implementation without lots of extra code. > Considering that: a) we have EAP in IKEv2, Which WG decided was not enough for secure password authentication because it was not symmetric especially in the implementation side. The secure password authentication method we are trying to add needs to be completely symmetric i.e. either end can start sessions without any problems from the authentication methods point of view. Most of the IKEv2 implementations only support EAP client side or EAP server side but not both at the same time. Also if you want to support EAP server side in both ends of the VPN gateway to gateway communication you need EAP AAA infrastructure in both ends too, which is not usually the case or you need to implement the EAP AAA infrastructure inside the VPN gateway, which also is not usually done. > b) there are reserved numbers for using the GSS-API in IKEv1, and we > could make it usable in IKEv2, If I remember right GSS-API is also asymmetric meaning only there is clear separation of client and server side, and usually you cannot assume that if I can act as GSS-API client side and connect to the server the implementation can also act as GSS-API server side. I might be wrong on that issue, as I do not know GSS-API that well. Also getting all those 4 secure password authentication methods convereted to GSS-API methods is going to require quite a lot of work, and also binding GSS-API authentication to the IKEv2 authentication also requires work. In this system I proposing I do plan to leave those details for the mehods themselves, i.e. the methods need to describe what kind of payloads are sent inside the generic payload, and how the AUTH payload sent inside the IKEv2 needs to be calculated to do the authentication. The generic framework just offers common way to agree on the method to be used, and provide generic payload format for transmitting the methods specific payloads. > c) we have a plethora of EAP methods and GSS-API mechanisms > available now or soon, ... why create a new framework? Because WG needs to have symmetric secure password authentication method. We wanted to have one, but unfortunately we failed and now it looks we are going to have multiple, and those different methods as written now do not co-exist nicely, and every single one of them do require modifications to the standard IKEv2. If we create common payload format which those methods can use, and common way to agree on which method to use, then the IKEv2 protocol modifications need to be done only once, and the method specific code can be in separate module. This module will still tightly integrate to the IKEv2, as it changes number of exchanges, and adds payloads to the messages, and also affects how the AUTH payload in the IKEv2 is calculated, but at least the basic code can be shared between different methods. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
