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

From: <[email-masked]>
Date: Wed, 15 Sep 2004 13:06:40 +0300

Jouni,

Many thanks for your detailed analysis! I'm glad to hear
your interoperability testing is going so well. 

I agree that the problem you pointed out exists; the drafts
are not clear on what identity to use in MK derivation
when the preceding EAP-Response/SIM/Start does not include
AT_IDENTITY, but when AT_IDENTITY was used in the EAP exchange
in an earlier EAP-Response/SIM/Start.

You already listed the two most natural resolutions:

1) The AT_IDENTITY from the previous EAP-Response/SIM/Start

2) permanent identity, although it was not used in any
identity string during the authentication exchange.

In my opinion, number 1) would be more in line with the
"spirit" of the draft -- the purpose is to protect 
the last identity string communicated in the protocol. So I think we 
should change section 6.4. (Key Generation) as follows:

   ..
   Identity denotes the peer identity string without any terminating
   null characters. It is the identity from the last AT_IDENTITY attribute
   sent by the peer in this EAP exchange, or, if AT_IDENTITY was not used 
   during the EAP exchange, the identity from the EAP-Response/Identity packet. 
   The identity string is included as-is, without any changes. 

We should also include an example message sequence of this 
AT_COUNTER_TOO_SMALL case.

Any opinions?

BR,
Henry

> -----Original Message-----
> From: Jouni Malinen [mailto:[email-masked]]On Behalf Of ext 
> Jouni Malinen
> Sent: 15 September, 2004 06:35
> To: Haverinen Henry (Nokia-ES/Jyvaskyla); [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: EAP-SIM/AKA identity selection after counter-too-small
> 
> 
> 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: Uma Shankar Ch <[email-masked]>
Date: Fri, 17 Sep 2004 18:18:07 +0530

Hi Henry,

Excuse me, you are absolutely correct. For the Figure 9 above, where EAP 
exchange started with EAP-Request/Identity, one must use the 
EAP-Response/Identity only in MK calculation for the specified case in 
4.3.5. In that sense, the statement completely holds good.

For this case

as pointed by Jouni, according to the new change introduced by you, both 
'A' and 'P' would be using the identity from the last AT_IDENTITY (ie., 
[email-masked] --- in this case) for MK calculation.

For this case, this example exchange would be really useful to understand 
things quickly in the draft.

Thanks for correcting my understanding.

--Uma

At 02:11 PM 9/17/04 +0300, [email-masked] wrote:
>
>Hi Uma,
>
>I'm not sure I understand why the last sentence (you bolded) would
>become invalid. When the counter is too small, the peer should still
>discard the new re-authentication identity which is received in the same 
>message
>as the too small a counter, even with the proposed change. That is, the 
>peer should discard
>the identity the server included in AT_NEXT_REAUTH_ID of the
>EAP-Request/SIM/Re-authentication message that has too small a counter
>value in AT_COUNTER.
>
>I think this is still valid, even when the EAP exchange consists of a 
>counter-too-small
>re-authentication and a full authentication. In this case, when 
>EAP-Response/Identity
>is not used, the peer and the server use the peer identity sent by the 
>peer to the server in
>the first EAP-Response/SIM/Start.
>
>Maybe we should clarify section 4.3.5 so that it is clear which 
>AT_NEXT_REAUTH_ID
>needs to be discarded?
>
>Best regards,
>Henry
>From: ext Uma Shankar Ch [mailto:[email-masked]]
>Sent: 17 September, 2004 07:28
>To: Haverinen Henry (Nokia-ES/Jyvaskyla); [email-masked]; 
>[email-masked]; [email-masked]
>Cc: [email-masked]
>Subject: Re: [eap] RE: EAP-SIM/AKA identity selection after counter-too-small
>
>>Hi Henry,
>>
>>Just to mention --
>>
>>With the proposed change, you may would like to remove the text as it 
>>would become invalid, in Section 4.3.5 (Fast Re-authentication Procedure 
>>when Counter is Too Small) -- the last sentence in paragraph
>>
>>    "When the peer detects that the
>>    counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
>>    attribute in EAP-Response/SIM/Re-authentication. This attribute
>>    doesn't contain any data but it is a request for the server to
>>    initiate full authentication. In this case, the peer MUST ignore the
>>    contents of the server's AT_NEXT_REAUTH_ID attribute."
>>
>>--Uma
>>
>>
>>
>>At 01:06 PM 9/15/04 +0300, [email-masked] wrote:
>>
>>>Jouni,
>>>

---

From: Uma Shankar Ch <[email-masked]>
Date: Fri, 17 Sep 2004 09:58:03 +0530

---

From: Uma Shankar Ch <[email-masked]>
Date: Thu, 16 Sep 2004 20:26:28 +0530

Hi Henry,

Just to mention --

With the proposed change, you may would like to remove the text as it would 
become invalid, in Section 4.3.5 (Fast Re-authentication Procedure when 
Counter is Too Small) -- the last sentence in paragraph

--Uma