Re: Final editing changes to IKEv2

[Yoav Nir <ynir@checkpoint.com>]

This is one message that proposed two options, and did not receive any 
responses.  Is this a consensus?

Anyway, EAP is originally a PPP protocol.  The last message 
(success/failure) is not meant to be reliable.  If it is lost, its 
existence can be inferred in PPP by what happens next (IPCP in case of 
success, or LCP terminate in case of failure).  There is never any 
response to the EAP success message, so there is no need for the IKE 
machine to send it to the client as soon as it is received.

If the EAP machine first sends the Authentication success, and 
afterwards sends the key (or the reverse), the IKE machine should 
buffer whichever comes first until the other arrives, and then send 
both the EAP success and the auth payload in one message just as it is 
specified in -12.

It should be possible to resolve the ambiguity by saying that the 
client sends the AUTH payload as soon as it can, while the server sends 
it in the last packet along with the Success/Failure message.  I don't 
see a reason to add an extra roundtrip.

On Mar 16, 2004, at 7:54 PM, Theodore Ts'o wrote:

>
> The following represent the final changes that we believe the IPSEC
> working group has developed a consensus to make to IKEv2.  If anyone
> has any problems to these set of changes, please make them known within
> 48 hours.  Otherwise, they will represent editing instructions to the
> IKEv2 document editor before we submit this document to the Area
> Director for IETF Last Call.
>
> 2. Add an additional round trip when utilizing  EAP to avoid the
>    ambiguity of what "after having sufficient information to compute 
> the
>    key" might mean.  This is commonly done in most other applications
>    that utilize EAP.
>
>     http://www.vpnc.org/ietf-ipsec/mail-archive/msg02719.html
>