Subject: [eap] EAP-SIM/AKA identity selection after counter-too-small

From: Jouni Malinen <[email-masked]>
Date: Tue, 14 Sep 2004 20:35:17 -0700

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 ([email-masked] = 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 ([email-masked] = 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 [email-masked] 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 = [email-masked] = 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 = [email-masked] = 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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Suresh" <[email-masked]>
Date: Thu, 16 Sep 2004 15:29:30 +0530

Hi,
I have a query regarding retransmission in RFC-3579.

The setup.

 EAP-Client                           (RFC-3579)--------- RADIUS Server
     |                                    |
 Lower layer x -------------------- Lower layer x

Assume that lower layer supports retransmission and RADIUS server sent
an Access-Challenge packet with EAP packet and also set session timeout
attribute.

1) Should the retransmission time interval of the Lower layer
be over rided with the Access-Challenge session timeout attribute value
for that EAP-packet?

OR

2) Should Authenticator ignore the value of Access-challenge session timeout
attribute and leave the retransmission functionality to the Lower layer?

Thanks
-Suresh

---

From: "Suresh" <[email-masked]>
Date: Fri, 17 Sep 2004 12:17:54 +0530

But the RFC-3579 section 2.3 Retransmission says

   It may be necessary to adjust retransmission strategies and
   authentication timeouts in certain cases.  For example, when a token
   card is used additional time may be required to allow the user to
   find the card and enter the token.  Since the NAS will typically not
   have knowledge of the required parameters, these need to be provided
   by the RADIUS server.  This can be accomplished by inclusion of
   Session-Timeout attribute within the Access-Challenge packet.

-----Original Message-----
From: Srinivasa Rao Addepalli [mailto:[email-masked]]
Sent: Friday, September 17, 2004 12:53 AM
To: Suresh; [email-masked]
Subject: Re: [eap] Retransmission in EAP-Relay

I suggest option 2. I don't think session timeout is meant for this anyway.

Srini
Intoto Inc.
www.intoto.com

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Thu, 16 Sep 2004 12:23:17 -0700

Srini
Intoto Inc.
www.intoto.com