eap Mailing List: Re: EAP-AKA review

[Jari Arkko (jari.arkko]

A couple of comments (with the author hat on):

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

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?

>     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.
> "

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.

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

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