eap Mailing List: Re: eap pax expert review

[T. Charles Clancy (clancy]

[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 ]