eap Mailing List: Expert review of draft-urien-eap-smartcard-type-02.txt

[Glen Zorn (gwz) (gwz]

EAP Type Code Allocation Review Template

As noted in RFC 3748, for EAP methods to obtain a 
Type Code, Expert Review with Specification is
required.  The following list of issues is provided
as a guideline to potential expert reviewers and
method authors.  

1. Does the method document its security properties
in sufficient manner, as required by Section 7.2
of RFC 3748?

[gwz] Yes and no: although all of the required sections are present, the
method in fact appears to possess no security properties of its own;
those security properties that are claimed (see below) are possessed by
smart cards, not by the EAP-SC method.


1a. Mechanism. Is the mechanism explained?

[gwz] Yes and no: this document does not actually define an
authentication mechanism, nor does it define EAP support for any
particular authentication mechanism.  What it does define is a method
for demultiplexing EAP type packets on the peer (this does not appear to
be necessary on the authenticator side).  This demultiplexing method is
explained adequately.


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

[gwz] Yes.


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

[gwz] Yes and no: the references for those claims that are made (for
Confidentiality, Key Derivation, Dictionary Attacks, Cryptographic
Binding and Channel Binding) are internal to the document itself and
refer to (claimed) properties of smart cards in general, rather than
EAP-SC per se.


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

[gwz] N/A.


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

[gwz] N/A.

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

[gwz] N/A.


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

[gwz] Much space is dedicated in this document to the praise of the
security capabilities claimed by smart cards; without discussing the
validity of those claims, it appears that EAP-SC itself provides no
assurance or even evidence of the actual presence or usage of a smart
card in the peer system.  For enable, I can find no protection against a
Trojan horse, for example, having access to appropriate credentials
claiming to be an EAP-SC client in the absence of a smart card.

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

[gwz] Yes.


3. Compliance with EAP behavior

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

[gwz] N/A.


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

[gwz] N/A.


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

[gwz] N/A.


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

[gwz] N/A.


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

[gwz] N/A.


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

[gwz] N/A.


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

[gwz] N/A.


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

[gwz] N/A.


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?

[gwz] No.

4b. Does the method comply with other IANA requirements in
the IETF standards track RFCs? 

[gwz] Yes.


For instance, does the
method attempt to allocate TLS extensions (which would
only be possible for standards track RFCs)?