Subject: [eap] EAP-AKA review

From: Jari Arkko <[email-masked]>
Date: Mon, 11 Oct 2004 10:48:55 +0300

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.

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 11 Oct 2004 15:50:43 +0300

> Missing reference or explanation for mutual authentication in Section

Yes. Section 9.2 should refer to [TS 33.102] to support this
claim, and then Section 10 should point to either Section 9.2
or the reference. Would this make your problem go away?

>    calculation of the checkcode.

It seems unnecessary to talk about lost messages. By RFC 3748,
the server will retry sending until it fails. Perhaps this part
of the text should just be deleted.

> It is unclear whether EAP Notification is allowed or prohibited in

Question: Why do you think its unclear? There's a lot of
AKA-Nofification messages, but is there some text that
talks about EAP Notification messages? If yes, that text
should probably be changed. If not, I think we can assume
that RFC 3748 is followed -- I don't think methods need
to repeat the requirements or prohibitions of RFC 3748,
as long as the methods don't themselves require something
which is in violation of RFC 3748, such as suggest sending
EAP Notifications in a place where they are not allowed.

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 10 Oct 2004 22:15:55 -0400

Yes.

> of the text should just be deleted.

I agree with you on just deleting the text.

> EAP Notifications in a place where they are not allowed.

The following text in section 9.6 made me come up with the comment on
EAP Notification:

"
   Because EAP-AKA is not a tunneling method, EAP-Request/Notification,
   EAP-Response/Notification, EAP-Success or EAP-Failure packets are not
   confidential, integrity protected or replay protected. On physically
   insecure networks, this may enable an attacker to mount denial of
   service attacks by spoofing these packets. As discussed in Section
   4.4, the peer will only accept EAP-Success after successful
   authentication. Hence, the attacker cannot force the peer to believe
   successful authentication has occurred when mutual authentication
   failed or has not happened yet.
                                                                                
   The security considerations of EAP-AKA result indications are covered
   in Section 9.8
                                                                                
   An eavesdropper will see the EAP Notification, EAP_Success and
   EAP-Failure packets sent in the clear. With EAP-AKA, confidential
   information MUST NOT be transmitted in EAP Notification packets.
"

The text seems to indicate that there is some case in which EAP
Notification packets are sent in EAP-AKA, but I failed to find some
text that explains when they are sent besides AKA-Notification
packets.

Best regards,

Yoshihiro Ohba

---

From: Jari Arkko <[email-masked]>
Date: Tue, 12 Oct 2004 07:42:23 +0300

Yoshihiro,

> text that explains when they are sent besides AKA-Notification

Ah, I see the problem now. I don't think the intention was to
allow EAP Notifications in any sense disallowed by RFC 3748.
Perhaps we could delete the Notification parts from the above,
or add a statement that the draft does not specify that they
should be used and that if they are used they should be used
according to RFC 3748. Henry?

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Oct 2004 16:29:08 +0300

Hi Yoshihiro,

Returning back to the one remaining open issue in the AKA
review...

>         [Optional, at least for now: does it conform to EAP

I guess this indeed needs to be optional until the keying
document is finalized. So perhaps the discussion is moot, but

> subsequent fast re-authentications.

I posted an issue for the keying document related to this.
Basically, after some analysis, it seems that the division
between "TEKs" and "other keying material" in the keying
document is somewhat artificial. I also provided some suggested
text to correct this. What's your opinion on this? And if you
agree, is there something else in EAP-AKA that needs to be changed
because of this? Note: I also suggested some text in EAP keying
about the relationship of fast reconnect and guarantees about the
continued possession of the original long-term keys. We could
add some discussion to the AKA document about this too, but
personally it feels sufficient if the keying document talks
about it, as it is general for all EAP methods having a fast
reconnect scheme.

--Jari