Hi Tero, On 5/5/09 4:51 AM, "Tero Kivinen" wrote:
>>> Secondly, it is not clear whether the "In such cases" only refers to >>> the cases wher gateway decides to do something (interact with AAA >>> server/ use external authentication server), or in all cases where EAP >>> or multiple authentication is used. If it is in all cases where EAP or >>> multiple authentication is used, then that means gateway cannot >>> redirect in first IKE_AUTH (which is fine for me, but I am not sure if >>> that was meant). If it is only when gateway needs AAA/external >>> authentication server, then how can client enforce the "MUST NOT >>> accept redirect in an earlier IKE_AUTH message", if it does not know >>> whether gateway needs to consult external authentication server or AAA >>> server... >>> >>> In general the text is so confusing that I am not sure what is meant. >>> One easy way to solve this problem is to say things clearly, i.e. >>> either add one of the following texts: >>> >>> If multiple IKE_AUTH exchanges are used the REDIRECT notification >>> payload MUST be in the IKE_AUTH response from gateway to the client, >>> which also includes the gateways AUTH payload. With EAP, there is >>> two possible places (first IKE_AUTH and last IKE_AUTH). With >>> multiple authentication support there are AUTH payload after each >>> authentication finished, thus server can redirect after each >>> authentication step is finished. REDIRECT notification MUST NOT be >>> sent or accepted in any other messages than those having AUTH >>> payload. >>> >>> or >>> >>> If multiple IKE_AUTH exchanges are used the REDIRECT notification >>> payload MUST be in the final IKE_AUTH response from the gateway to >>> the client, i.e the one that contains the AUTH payload, and that >>> would also contain the Child SA SA payload and traffic selectors, >>> if connection would not have redirected. REDIRECT notification MUST >>> NOT be sent or accepted in any of the earlier IKE_AUTH messages. >> >> If the gateway decides to redirect after the first authentication, >> it would be the same as the exchange in section 6. The second >> authentication would not even happen. > > If initiator decides to use EAP, then the exchange is not same as in > section 6, as the initiator has not proven his identity yet. The first > authentication only authenticates the identity of the server. > > If Shared secret or certificates are used then both ends identities > are authenticated during the first IKE_AUTH exchange. > > With multiple authentications the server can at any point decided that > it has had enough authentication and ignore the ANOTHER_AUTH_FOLLOWS > wish from client (as far as I understand the rfc4739), thus it can at > any point when authentication is finished decided to finish the whole > IKE_SA creation and send final AUTH. > > I think we need bit more text there explaining how this is supposed to > work. > >> If the redirect is as a result of interaction with an external >> authentication server, then the redirect happens in the final >> IKE_AUTH message. > > How is the client supposed to know whether server decides to redirect > as a result of interaction with an external authentication server, and > make sure server cannot redirect during first IKE_AUTH exchange. > > The MUST in draft says that client MUST NOT accept redirect in any > earlier message. > > As there is no way for client to know for this, there is no point of > putting such requirement there. Lets discuss the multiple auth case in today's virtual meeting. I have a slide on that. >> I think we should use the same IANA registry for both. > ... >> I added the following text to the IANA section. >> >> This document creates a new namespace called the "Gateway Identity >> Type". This is used to indicate the type of information regarding >> the VPN gateway that is carried in the REDIRECT Section 7.2 and >> REDIRECTED_FROM Section 7.3 Notification payloads. The following >> values are assigned. >> >> 1 - IPv4 address of the new VPN gateway >> 2 - IPv6 address of the new VPN gateway >> 3 - FQDN of the new VPN gateway >> >> Values '0', and 4-255 are reserved. New values can be allocated by >> expert review. > > So FQDN is allowed in the REDIRECTED_FROM payload too? No. I added text in both sections 7.2 and 7.3 that says which values are valid in the REDIRECT and REDIRECTED_FROM payload. > It is bad idea to share the registries if they can have different > values. We already had this problem in the IKEv2, as the encryption > algorithms registry was shared with both IKEv2 and ESP, and not all of > the algorithms could be used in IKEv2 (combined mode ciphers), and the > registry didn't indicate this in any way. > > So either use two registries, or specify explicitly which values are > usable in which payload. I did the latter. Vijay _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
