eap Mailing List: EAP-SIM/AKA identity selection after counter-too-small

[Jouni Malinen (jkmaline]

I have implemented peer part of EAP-SIM (draft 13) and EAP-AKA
(draft 12) and have been trying to complete full interop tests for
more or less all features in the drafts with an authentication
server. Successful authentication cases seem to work fine: full
authentication with both permanent id and change to pseudonym works
and so does fast reauthentication. Many of the error cases, both
client error and notifications, are also interoperating. However,
testing AT_COUNTER_TOO_SMALL has had some problems, both due to
implementation bugs and mismatches in interpretation of the draft.

Bugs are now mostly fixed, but since there were mismatches in
interpretation, it might be useful to consider extending the example
of fast reauthentication when counter is not fresh (figure 9 of
EAP-SIM draft 13) to include the full authentication part with
explicitly mentioning the used identities for each message and the
identity used in MK derivation.

While going through the details of how the identity is selected for MK
derivation I noticed a potential issue with the drafts. I'm covering
EAP-SIM case here, but it looks like EAP-AKA (draft 12) has, in
practice, identical construction for fast-reauth and consequently, the
same problem is present (just replace SIM with AKA and subtype Start
with Identity in the description).

Chapter 4.6 Key Generation of EAP-SIM draft 13 gives two
possible sources for Identity that is used as data for SHA1(). It can
be either from the AT_IDENTITY of the previous EAP-Response/SIM/Start
or from the identity included in the previous EAP-Response/Identity.
However, there is one case in which neither of these is available,
namely, counter-not-fresh case when EAP-Request/Identity is not used.
How should the identity in MK derivation be selected for this case?

The example message sequences below show more details. The first case
is with EAP-Request/Identity and this can be completed based on the
draft description. Using reauth_id in MK derivation, i.e., in fullauth
case, is potentially confusing, but that seems to be the way to go
when following the current draft (it is the identity from previous
EAP-Response/Identity since previous EAP-Response/SIM/Start did not
include AT_IDENTITY).

The second case is from situation where EAP-Request/Identity is not
used at all. Authentication starts with EAP-Request/SIM/Start with
AT_ANY_ID_REQ, followed by AT_IDENTITY in EAP-Response/SIM/Start.
However, counter-not-fresh case (chapter 4.3.5) specifies that server
MUST NOT include any of the ID_REQ attributes in EAP-Request/SIM/Start
and consequently, following EAP-Response/SIM/Start does not include
AT_IDENTITY. This will trigger the case where it is not clear which
identity would be used in MK derivation.


With EAP-Request/Identity:

A: EAP-Request/Identity
P: EAP-Response/Identity (1|IMSI = permanent id)
A: EAP-Request/SIM/Start (AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
    *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
   (use 1|IMSI as the Identity in MK derivation)
P: EAP-Response/SIM/Challenge (AT_MAC)
A: EAP-Success


A: EAP-Request/Identity
P: EAP-Response/Identity (20000 [at] example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
    *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
    *AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER,
    *AT_PADDING, AT_MAC)
A: EAP-Success


A: EAP-Request/Identity
P: EAP-Response/Identity (20001 [at] example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
    *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
    *AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
    *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
A: EAP-Request/SIM/Start (AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
    *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
   (use 20001 [at] example.com as the Identity in MK derivation, i.e.,
   AT_NEXT_REAUTH_ID from the last successful fullauth/reauth, not
   AT_NEXT_REAUTH_ID of the reauth attempt with too small counter)
P: EAP-Response/SIM/Challenge (AT_MAC)
A: EAP-Success



Without EAP-Request/Identity:

A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
AT_SELECTED_VERSION)
    (identity = 1|IMSI = permanent id)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
    *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)
   (use 1|IMSI as the Identity in MK derivation)
P: EAP-Response/SIM/Challenge (AT_MAC)
A: EAP-Success


A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
AT_SELECTED_VERSION)
    (identity = 20000 [at] example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
    *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
    *AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA, *AT_COUNTER,
    *AT_PADDING, AT_MAC)
A: EAP-Success


A: EAP-Request/SIM/Start (AT_ANY_ID_REQ, AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_IDENTITY, AT_NONCE_MT,
AT_SELECTED_VERSION)
    (identity = 20001 [at] example.com = reauth_id from prev auth)
A: EAP-Request/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
    *AT_COUNTER, *AT_NONCE_S, *AT_NEXT_REAUTH_ID, *AT_PADDING,
    *AT_NONCE_S, AT_MAC)
P: EAP-Response/SIM/Reauthentication (AT_IV, AT_ENCR_DATA,
    *AT_COUNTER_TOO_SMALL, *AT_COUNTER, *AT_PADDING, AT_MAC)
A: EAP-Request/SIM/Start (AT_VERSION_LIST)
P: EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)
A: EAP-Request/SIM/Challenge (AT_RAND, AT_IV, AT_ENCR_DATA,
    *AT_NEXT_PSEUDONYM, *AT_NEXT_REAUTH_ID, *AT_PADDING, AT_MAC)

Which Identity should be used in MK derivation now? Previous
EAP-Response/SIM/Start did not have AT_IDENTITY (since AS already
learned identity from the failed reauth attempt) and
EAP-Response/Identity was not used. Chapter 4.6 Key Generation
mentions these two options for Identity, but neither one is available
here.. Should this be specified to use reauth_id from the AT_IDENTITY
of the previous SIM/Start or permanent id (which should always be
known by both AS and Peer at this point) or something else?


-- 
Jouni Malinen                                            PGP id EFC895FA