RE: Final editing changes to IKEv2

[Pasi.Eronen@nokia.com]

Hi,

Having the responder send the AUTH payload and EAP-Success 
in the same message is OK. However, this does not solve the 
initiator's case. "As soon as it can" is still a bit ambigous, 
and in draft -12 the initiator sends the AUTH payload _before_ 
receiving EAP-Success. But EAP peer state machine currently 
"exports" the key only _after_ receiving EAP-Success.

So it seems that we need to either slightly change how EAP works 
or add another roundtrip. Both options are certainly feasible, 
but IMHO the latter requires less work...

Best regards,
Pasi

> -----Original Message-----
> From: owner-ipsec@lists.tislabs.com
> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ext Yoav Nir
> Sent: Wednesday, March 17, 2004 3:32 PM
> To: Theodore Ts'o
> Cc: ipsec@lists.tislabs.com
> Subject: Re: Final editing changes to IKEv2
> 
> 
> 
> 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
> >
> 
>