eap Mailing List: RE: Discrepancies between 802.1XREV and RFC 2248bis

[Joseph Salowey (jsalowey]

eap-admin [at] frascone.com wrote:
> I just reread RFC 2284bis section 2.4 and 802.1XREV Section
> 6.7, and they seem miles apart.  This needs to be resolved
> before 802.1X-REV is published.
> 
> Here is my reading of the differences and what needs to be done to
> fix them: 
> 
> a. Section 6.7 of 802.1X-REV indicates that EAP
> authentication can only be uni-directional.  RFC 2284bis
> Section 2.4 states the conditions under which bi-directional
> authentication is achievable. Since 802.1X-REV now leaves
> authentication to EAP, it is not possible for IEEE 802
> encapsulation to change the fundamental properties of EAP, so
> the two specs cannot disagree on this point.
> 

[Joe] I'm looking at section 6.7 of 802-1X-REV-d8.pdf and it appears to
be somewhat ambiguous, last paragraph gives EAP-TLS as an example of
mutual authentication.  


> b. Section 6.7 appears to assume (contrary to recent
> discussion) that there is no way for the AAA server or higher
> layer to communicate the peer decision down to the lower
> layer on the authenticator side.  Given the new interface
> variables and discussion on AAA key implications, I think
> we've settled this issue. While I'm ok with not changing
> 802.1X-REV to discuss the new interface variables or AAA
> implications (this can go in the EAP State Machine document),
> I do think that the implications for the text of Section 6.7
> do need to be addresssed.
> 

[Joe] I'm still unclear as to what the "decision" really is and its
impact on authorization, but this currently does not seem to be an issue
discussed in section 6.7.  Is this discussed elsewhere in the 802.1XREV
document?

> To fix these issues, it would probably be best if Section 6.7
> referenced RFC 2284bis Section 2.4 and removed the paragraphs
> that appear to contradict RFC 2284bis. Given that 802.1X-REV
> is entering sponsor ballot, it is relatively late for these
> fixes to be put in -- but I fear that if the changes are not
> made now the pain will be much greater down the line,
> particularly since 802.1af appears to want to address some of
> the same peer-to-peer issues.
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap