eap Mailing List: EAP-AKA review

[Jari Arkko (jari.arkko]

This is Yoshihiro's review of EAP-AKA.

--

The following is RFC 3748 compliance checklist for EAP-AKA.

My detailed comments are available at:
http://www.opendiameter.org/draft-arkko-pppext-eap-aka-12_ohba-comments.txt.

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

Yes.

    1a. Mechanism. Is the mechanism explained?

Yes.

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

Yes.

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

Missing reference or explanation for mutual authentication in Section
10.

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

Yes.

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

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

The two TEKs defined in EAP-AKA, namely K_aut and K_encr, do not seem
to comply with the EAP keying framework.  (In the EAP keying
framework, it is not allowed to use TEKs across an EAP conversation
while in EAP-AKA the TEKs are used in full authentication and
subsequent fast re-authentications.

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

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

Yes.

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 behavior

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

Yes.

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

Yes.

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

The following text in section 7.13 of
draft-arkko-pppext-eap-aka-12.txt does not seem to comply with EAP
request/response processing if "another EAP-Request/AKA-Identity with
the same attributes as in the previous request" means a new EAP
request.  (According to section 4.1 of RFC 3748, the EAP server is not
allowed to generate a new EAP request until a valid EAP response is
received, an optional retry counter expires, or a lower layer failure
indication is received.)

"
   After sending EAP-Response/
   AKA-Identity, if the peer receives another EAP-Request/AKA-Identity
   with the same attributes as in the previous request, then the peer's
   response to the first request must have been lost. In this case the
   peer must not include the first request and its response in the
   calculation of the checkcode.
"


    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?

It is unclear whether EAP Notification is allowed or prohibited in
EAP-AKA.

    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.

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.