Subject: [eap] eap pax expert review

From: Jari Arkko <[email-masked]>
Date: Sun, 17 Apr 2005 23:41:07 +0300

This an expert review of EAP PAX, draft-clancy-eap-pax-02.txt,
based on RFC 3748 requirements and the review template
at http://www.drizzle.com/%7Eaboba/EAP/template.txt

Note that an expert review is a not an analysis to find out
if the method is suitable for any specific purpose; we just
make sure that the method does not break EAP and that
its sufficiently well documented. Also, I didn't review
compliance to IEEE method requirements. (Any takers?)

Overall, the verdict is "pass", although a couple of editorial
clarifications might be useful. Inline:

 > 1. Does the method document its security properties
 > in sufficient manner, as required by Section 7.2
 > of RFC 3748?
 >
 > 1a. Mechanism. Is the mechanism explained?

Yes. See Sections 2 and 3.

 > 1b. Security claims. Are the claimed and not claimed
 > properties listed?

Yes. See Section 4.3.

Note: 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.

 > 1c. Justifications for the claims? Is an explanation or
 > reference provided to each of the claims?

Yes.

 > 1d. Key strength. Is the key strength documented?

Yes.

 > 1e. Description of key hierarchy. Is the key hierarchy
 > documented?

Yes. See Section 2.3 and 2.1.

 > [Optional, at least for now: does it conform to EAP
 > keying framework?]

Yes. Note: the keying framework is still being worked
on.

 > 1f. Indication of vulnerabilities. Are the known vulnerabilities
 > documented?

Yes. See Sections 2.2 and 4.

 > [Note: it seems unreasonable to require the documentation
 > of unknown vulnerabilities :-) The "known" may of course be
 > "known to reviewer" or "known to author" or "known to the
 > community", but that appears to be best we can do.]
 >
 > 2. Compliance with EAP packet formats
 >
 > 2a. Does the method comply with the packet formats
 > defined in Section 4 of RFC 3748?

Yes.

 > 3. Compliance with EAP behaviour
 >
 > 3a. Does the method comply with Success/Failure usage
 > as defined in Sections 2, 2.2, and 4.2?

Yes. (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.)

 > 3b. Does the method comply with sequence usage as defined
 > in Section 2.1 of RFC 3748?

Yes. No sequences are used.

 > 3c. Does the method comply with request/response processing
 > rules as defined in Section 4.1 of RFC 3748?

Yes.

 > 3d. Does the method comply with retransmission rules
 > as defined in Section 4.3 of RFC 3748?

Yes.

 > 3e. Does the method comply with the usage defined for
 > Identity, as defined in Section 5.1 of RFC 3748?

Yes.

 > 3f. Does the method comply with the usage defined for
 > Notification, as defined in Section 5.2 of RFC 3748?

Yes. No Notifications are used.

 > 3g. Does the method comply with the usage defined for
 > Nak and Expanded-Nak as defined in Section 5.3 of RFC 3748?

Yes.

 > 3h. Does the method comply with the MIC usage requirements
 > from Sections 3.1, 7.5, and 7.8 of RFC 3748?

Yes. See Section 2.4, for instance.

Note: 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.

 > 4. Compliance with IANA requirements
 >
 > 4a. Does the method comply with EAP-based IANA requirements
 > defined in Section 6 of RFC 3748? That is, if it requests
 > the allocation of new numbers in the EAP namespace [not
 > applicable if the numbers have already been allocated],
 > is the type of the document and process appropriate for the
 > desired action?

Yes.

 > 4b. Does the method comply with other IANA requirements in
 > the IETF standards track RFCs? For instance, does the
 > method attempt to allocate TLS extensions (which would
 > only be possible for standards track RFCs)?

Yes, the document complies with the IANA requirements,
as there are no other number spaces used than those in
EAP.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Apr 2005 10:10:32 -0700 (PDT)

[BA] It would be useful to have PAX document the key name and scope, as in
Appendix E in the Key Management framework.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "T. Charles Clancy" <[email-masked]>
Date: Thu, 21 Apr 2005 00:51:17 -0400 (EDT)

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

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

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

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 ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap