Subject: Re: Comments to the draft-nir-ipsecme-erx-07.txt

From: Yoav Nir <[email-masked]>
Date: Sun, 4 Nov 2012 22:52:21 +0200

Forwarding to the IETF mailing list, which is the proper home for this discussion.

On Nov 3, 2012, at 10:26 PM, Tero Kivinen wrote:

> In Introduction section (1) there is text saying:
> 
> ----------------------------------------------------------------------
>   Bringing these two technologies together allows a remote access IPsec
>   client to create multiple tunnels with different gateways that belong
>   to a single domain, as well as using the keys from other contexts of
>   using EAP, such as network access within the same domain, to
>   transparently connect to VPN gateways within this domain.
> ----------------------------------------------------------------------
> 
> I think that is missing one possible use for the EAP Re-authentication
> Protocol, then one that has been proposed for example in the IEEE
> 802.11ai. I.e the possibility that the client does full EAP with AAA
> backend only once, and then reuses that authentication later to
> recreate the IPsec connection when it was lost for some reason
> (network problems, device suspending, going out of range etc).
> 
> I.e. use it in similar ways as resumption protocol can be used, but
> now the state is stored in the AAA backend, not in the SGW.
> 
> In section "3. Protocol Outline" there is text saying:
> 
> ----------------------------------------------------------------------
>   The responder sends the EAP payload content to a backend AAA server,
>   and receives the rMSK and an EAP-Finish/Re-auth message.  It then
>   forwards the EAP-Finish/Re-auth message to the Initiator in an EAP
>   payload within the first IKE_AUTH response.
> ----------------------------------------------------------------------
> 
> There is possibility that even when the client has ERX connection
> still up, but the backend AAA server might have already destroyed it.
> This means that it is possible that when initiator sends the first
> EAP_Initiate/Re-Auth message to the SGW, which forwards it to the AAA
> server, the AAA server will NOT respond with EAP-Finish/Re-auth
> message, but simply starts normal full EAP. This should be explained
> here. It does not really change the actual protocol flow, as AAA
> server will send EAP packet back, and then the initiator and responder
> will exchange some number of EAP packets before responder sends the
> EAP-Finish to initiator and they do the final AUTH exchange.
> 
> If it is not mentioned here, some implementations might assume they
> always get EAP-Finish/Re-auth back and not work if the AAA server goes
> through the full EAP exchange.
> 
> In section "4. ERX_SUPPORTED Notification" there is text saying:
> 
> ----------------------------------------------------------------------
>   o  Protocol ID (1 octet) MUST be 1, as this message is related to an
>      IKE SA.
> ----------------------------------------------------------------------
> 
> This is wrong. The RFC 5996 in section 3.10 says:
> 
> ----------------------------------------------------------------------
>   o  Protocol ID (1 octet) - If this notification concerns an existing
>      SA whose SPI is given in the SPI field, this field indicates the
>      type of that SA.  For notifications concerning Child SAs, this
>      field MUST contain either (2) to indicate AH or (3) to indicate
>      ESP.  Of the notifications defined in this document, the SPI is
>      included only with INVALID_SELECTORS and REKEY_SA.  If the SPI
>      field is empty, this field MUST be sent as zero and MUST be
>      ignored on receipt.
> ----------------------------------------------------------------------
> 
> I.e. the Protocol ID MUST be sent as zero if the SPI field is empty. 
> -- 
> [email-masked]
> 
> Scanned by Check Point Total Security Gateway.