headers
M. Vanderveen | 2 May 2006 17:42
Picon
Favicon

Re: ICV in EAP-PAX

I think the confusion arose from the meaning of "may not" as opposed to MAY NOT. Section 3.1 as you quote it essentially says that EAP methods rely on lower layer error detection, as they may possibly have no such error detection (or an incomplete error detection) built in.
 
EAP-SAKE computes an ICV over the entire packet as an added precaution. From the way I'm reading RFC3748 ICVs are allowed, and are even a good idea as it makes the EAP method more robust (at the additional cost of putting in the extra bytes in the one-way hash function input) and less dependent on the lower layer error detection.
 
Michaela

Thomas Otto <thomas.g.otto <at> googlemail.com> wrote:
<snip>
But RFC 3748 days in Section 3.1

[...] EAP methods may not
include a MIC, or if they do, it may not be computed over all the
fields in the EAP packet, such as the Code, Identifier, Length,
or Type fields. [...]


<snip>

We should discuss whether the ICVs are allowed and/or makes sense.
(... I remember EAP-SAKE also computes an ICV over the whole packet ...)


Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
_______________________________________________
Emu mailing list
Emu <at> ietf.org
https://www1.ietf.org/mailman/listinfo/emu
Permalink | Reply | 0 comments |

Gmane