Jari,
I discussed with Alper and Victor offline about this, and here is my
suggestion:
Add the following state transition entry to WAIT_EAP_MSG state of
the -11 PaC state machine so that the PaC can accept a new PAR and
pass the contained EAP message (which may carry an EAP-Request
retransmitted by EAP authenticator layer) to EAP peer:
"
Rx:PAR[] TxEAP(); WAIT_EAP_MSG
EAP_RespTimerStart();
if (eap_piggyback())
Tx:PAN[];
"
This way, the behavior under message alteration DoS attack will be
robuster than version -11 and -12, and PANA state machines still do
not need to deal with the silent discarding of an EAP message.
On the other hand, some text about eapNoReq and eapNoResp may still
be needed because EAP state machines expect these variables to set to
FALSE in lower layer.
Yoshihiro Ohba
On Wed, Jun 03, 2009 at 02:21:50PM +0300, Jari Arkko wrote:
> During IESG review we identified an issue that the state machine in its
> original form did not deal with the possibility that EAP state machine
> silently discards an EAP message.
>
> This was fixed in -12 along with a small RFC Editors note (diffs at the
> end of this mail). However, Alper has raised an issue that he believes
> there is a better way to deal with this problem. The current draft
> basically bails out of the entire process if a silent discard happens.
> Draft -11 would have stayed in WAIT_EAP_MESSAGE and waited until
> timeout; if the real authenticator would send a message during this
> time, it would not be processed.
>
> An alternative design would treat the silent discard of an EAP message
> as if the PANA message that carried was discarded. This probably means a
> slightly bigger change to the state machine.
>
> I would like to hear from the WG on what to do here. My preference is to
> ship the document as-is; no matter what we do on this, DoS attacks
> disabling the authentication process will be possible.
>
> Jari
>
> Version -12 diffs:
>
>
> http://tools.ietf.org/wg/pana/draft-ietf-pana-statemachine/draft-ietf-pana-statemachine-12-from-11.diff.html
>
> and the additional RFC Editor note:
>
> Please add the following text the last paragraph of Section 7.3:
>
> NEW:
> Note that this specification does not support silently discarding EAP
> messages. They are treated as fatal errors instead. This may have an
> impact on denial-of-service resistance.
>
> _______________________________________________
> Pana mailing list
> Pana@ietf.org
> https://www.ietf.org/mailman/listinfo/pana
>
_______________________________________________
Pana mailing list
Pana@ietf.org
https://www.ietf.org/mailman/listinfo/pana
