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.
--
kivinen(_at_)iki(_dot_)fi
Scanned by Check Point Total Security Gateway.