Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08
Vijay Devarapalli writes:
In section 6 it should be:
(IP_R:500 - IP_I:500)
-- HDR(A,B), SK {IDr, [CERT,] AUTH,
N(REDIRECT, New_GW_ID,)}
Fixed all of the above.
(Again changed the N[] to N()). This section does not say whether the
Ni is included in the response, but I assume it is omitted as there is
no need for it. This section should make it clear whether it is
included or omitted.
It is included only in the IKE_SA_INIT response. Section 7.2 says
The 'Nonce Data' field
is present in the REDIRECT payload only when the REDIRECT payload is
sent in the IKE_SA_INIT response message. It MUST NOT be included in
the REDIRECT payload if sent in an IKE_AUTH response or in a gateway-
initiated redirect message.
I hope this is sufficient.
I found that later, but when I was reading the protocol description in
section 6 I was wondering whether the nonce is included or not. It
might be enough to explain that in the description of the payload
itself, especially now if the N(REDIRECT, New_GW_ID,) in example
clearly indicates nonce is empty.
In section 6 the text:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST NOT send and the
client MUST NOT accept a redirect in an earlier IKE_AUTH message.
is bit confusing. First it says the gateway (lowercase) should send
REDIRECT in final IKE_AUTH response that carries the AUTH payload and
traffic selectors. Then it says that gateway MUST NOT send redirect in
earlier messages.
Firstly the final IKE_AUTH response willnot include the traffic
selectors, as they are omitted if client is redirected. Thus it is
misleading to say that carries the AUTH payload and traffic
selectors.
Please see my response to Pasi's email. This text has been updated. Redirect
during the first IKE_AUTH response is always allowed even when EAP or
multiple authentication is used.
The text was not very clear about this. I will wait to see next
version to see if that is clearer.
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
Re: [IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08
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
[IPsec] Comments to draft-ietf-ipsecme-ikev2-redirect-08
Section 3 says:
The gateway MUST include the nonce data from the Ni payload sent by
the initiator in the REDIRECT payload. This prevents certain Denial-
but the figures showing how redirect is done does not include Ni data
in the N(REDIRECT, IP_R). Also as GW identity can also be FQDN, it is
bit misleading to use IP_R in the payload, perhaps New_GW_ID would be
better. I.e. it would be better to write the reply as:
(Initial_IP_R:500 - IP_I:500)
-- HDR(A,0), N(REDIRECT, New_GW_ID, Ni_data)
Similar change is also needed in later sections too.
---
In section 5 it should be:
-- HDR, SK {N(REDIRECT, New_GW_ID,)}
(also changed the N[] to N() as is used normally).
---
In section 6 it should be:
(IP_R:500 - IP_I:500)
-- HDR(A,B), SK {IDr, [CERT,] AUTH,
N(REDIRECT, New_GW_ID,)}
(Again changed the N[] to N()). This section does not say whether the
Ni is included in the response, but I assume it is omitted as there is
no need for it. This section should make it clear whether it is
included or omitted.
---
In section 6 the text:
In such cases, the gateway should send the REDIRECT notification
payload in the final IKE_AUTH response message that carries the AUTH
payload and the traffic selectors. The gateway MUST NOT send and the
client MUST NOT accept a redirect in an earlier IKE_AUTH message.
is bit confusing. First it says the gateway (lowercase) should send
REDIRECT in final IKE_AUTH response that carries the AUTH payload and
traffic selectors. Then it says that gateway MUST NOT send redirect in
earlier messages.
Firstly the final IKE_AUTH response willnot include the traffic
selectors, as they are omitted if client is redirected. Thus it is
misleading to say that carries the AUTH payload and traffic
selectors.
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.
---
In section 7.2 the first paragraph says that The message includes the
new responder's IP address., but this payload can also include FQDN,
I think it should be changed to The message includes the
new responder's IP address or DNS name..
---
In section 7.2. the GW Identity Type should be made to be IANA
allocated registry. We have already had all kind of problems when we
have such registries which are not clearly defined, and then someone
wanted to add entries to there.
It would also be good to explicitly say that IPv4 address are encoded
as 4 octects, and IPv6 addresses are encoded as 16 octets, and that
the FQDN of the new VPN gateway is encoded as dns name without any
terminators (e.g., NUL, CR, etc). Perhaps it would be good to
cut paste the similar parts from the section 3.5 of the rfc4306.
---
In section 7.3 it is not clear whether this registry used for GW Ident
Type is same as in section 7.2 or not. As it does not have same
values, I assume it is supposed to be separate registry. In that case
it would be better to use some different name for it, so there is no
confusion which registry is used (for eaxmple Original GW Ident
Type).
As a separate registry it also need to be
