eap pax expert review
From: Jari Arkko (jari.arkkopiuha.net)
Date: Sun, 17 Apr 2005 16:41:07 -0400 (EDT)
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.


Results generated by Tiger Technologies using MHonArc.