eap Mailing List: Re: eap pax expert review

[Jari Arkko (jari.arkko]

Looks good to me. --Jari

T. Charles Clancy wrote:

> [Sorry if this gets posted twice -- the first time I sent it from the 
> wrong email address, so it's in the moderator's queue.]
>
> Jari, thanks for your time and your review. I've put together -03 to 
> address your comments and updates some of the references. I will be 
> submitting it shortly. Meanwhile, a copy can be found here:
>
> http://www.cs.umd.edu/~clancy/eap-pax/draft-clancy-eap-pax-03.txt
>
> > [JA] Also, I didn't review compliance to IEEE method requirements.
> > (Any takers?)
>
>
> For anyone interested in this, it's outlined in the last paragraph of 
> the introduction.
>
> > [JA] The claim for "cryptographic binding" (RFC 3748, Section 7.2.1)
> > is not documented for PAX, as this claim is relevant for tunnel
> > methods only. But for completeness sake it would be desirable to
> > mention why its not being listed.
>
>
> Ah... I have channel binding but not cryptographic binding. I've added 
> it to section 4.3.
>
> > [JA] (Editorial note: the document talks explicitly about
> > the conditions upon which an EAP Failure needs to be sent.
> > However, while it can be understood and implied, it doesn't
> > actually say that an EAP Success should be sent otherwise.)
>
>
> I've added the following to section 2.4:
>
> If PAX-ACK is received in response to a message fragment, the receiver
> continues the protocol execution. If PAX-ACK is received in response
> to PAX_STD-3 or PAX_SEC-5, then the server MUST send an EAP-Success
> message. This indicates a successful execution of PAX.
>
> > [JA] Regarding RFC 3748 Section 7.8 (optional) behaviour for
> > detecting bidding down attacks using Naks, EAP PAX does not do this.
> > Might be useful to note this.
>
>
> I've added the following to section 4.3:
>
> EAP is susceptible to an attack where an attacker uses NAKs to
> convince an EAP client and server to use a less secure method, and can
> be prevented using method-specific integrity protection on NAK
> messages. Since EAP-PAX does not have suitable keys derived for this
> integrity protection at the begining of a PAX conversation, this is
> not included.
>
> > [BA] It would be useful to have PAX document the key name and scope,
> > as in Appendix E in the Key Management framework.
>
>
> I've added the following to section 2.3:
>
> The EAP Key Managment Framework [I-D.ietf-eap-keying] recommends
> specification of key names and scope. The EAP-PAX Method-ID is the
> MID value computed as described above. The EAP peer name is the CID
> value exchanged in PAX_STD-2 and PAX_SEC-2. The EAP server name is
> an empty string.
>
> [ t. charles clancy ]--[ tcc [at] umd.edu ]--[ www.cs.umd.edu/~clancy ]
> [ computer science ]-----[ university of maryland | college park ]
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap