Vijay Devarapalli writes:
> There at least three people who think that the IKE_AUTH response
> message should itself contain the REDIRECT payload. I went through the
> email exchange between Fan and Tero. There was no new information
> that came out of that discussion for me to make this change in the
> draft.
>
> Does any one else have an opinion?
>
> Otherwise I suggest the WG chairs to make a call on this.
>
> Both solutions, 1) sending a REDIRECT payload in the IKE_AUTH response
> 2) sending a NO_ADDITIONAL_SAS in the IKE_AUTH response followed by a
> REDIRECT message, would work.
If you add text allowing REDIRECT with IKE_AUTH, then add also text
explaining how REDIRECT is used with other different extensions,
including EAP and multi auth. I.e. what happens if the server returns
REDIRECT before the first EAP exchange is finished, or what happens if
the server returns REDIRECT after the first EAP has succeeded, but
before the AUTH payload exchange after that, or what happens if server
returns REDIRECT even when the client wants to do another AUTH
negotiation etc.
I.e. if we take following example from the RFC4739:
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERTREQ+], [IDr],
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
EAP(Request) }
5. HDR, SK { EAP(Response) } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Success) }
9. HDR, SK { AUTH,
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 10. HDR, SK { AUTH }
11. HDR, SK { IDi } -->
<-- 12. HDR, SK { EAP(Request) }
13. HDR, SK { EAP(Response) } -->
<-- 14. HDR, SK { EAP(Request) }
15. HDR, SK { EAP(Response) } -->
<-- 16. HDR, SK { EAP(Success) }
17. HDR, SK { AUTH } -->
<-- 18. HDR, SK { AUTH, SA, TSi, TSr }
In which packets is the REDIRECT allowed. Is it only allowed in the
final 18th message? Is it also allowed in packet 10? Can it be sent
during any time of the EAP exachanges?
This is actually something that is bit unclear already in the RFC4306.
For notification payloads belonging to the IPsec SA (IPCOMP_SUPPORTED,
ADDITIONAL_TS_POSSIBLE, USE_TRANSPORT_MODE,
ESP_TFC_PADDING_NOT_SUPPORTED, NON_FIRST_FRAGMENTS_ALSO), it is quite
logical that the payloads containing SA and TS* payloads are the ones
where they should be in, but for example ESP_TFC_PADDING_NOT_SUPPORTED
and NON_FIRST_FRAGMENTS_ALSO do not contain explicit text listing
where they should be.
For others there are other defined places (i.e.
HTTP_CERT_LOOKUP_SUPPORTED should be in the payload containing
CERTREQ, REKEY_SA should be same packet as SA payload, COOKIE and
NAT_DETECTION_*_IP are used only in IKE_SA_INIT).
For status notifications like INITIAL_CONTACT and SET_WINDOW_SIZE there
is no defined or logical place to send them, so most likely they can
be in any packet during IKE_AUTH exchange (or after that as separate
INFORMATIONAL exchange).
The RFC4478 defines one more status notification i.e. AUTH_LIFETIME
and that is defined to be in last IKE_AUTH message, or as separate
INFORMATIONAL exchange.
MOBIKE (RFC 4555) defines that the new status notifications which can
be in IKE_AUTH (MOBIKE_SUPPORTED and ADDITIONAL_IP*_ADDRESSES) are in
the IKE_AUTH message containing the SA payload.
I assume that REDIRECT is going to be status notification, which means
that the IKE SA is created even when that is returned during IKE_AUTH,
and then the resulting IKE_AUTH still needs to be deleted with
separate INFORMATIONAL exchange containing delete payloads.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
