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

[Uma Shankar Ch (umas]

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   

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)

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.,
20001 [at] example.com --- 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, henry.haverinen [at] nokia.com 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

-----Original Message-----

From: ext Uma Shankar Ch [mailto:umas [at] intotoinc.com]

Sent: 17 September, 2004 07:28

To: Haverinen Henry (Nokia-ES/Jyvaskyla); jkmaline [at] cc.hut.fi; jsalowey [at] cisco.com; jari.arkko [at] ericsson.com

Cc: eap [at] frascone.com

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, henry.haverinen [at] nokia.com wrote:

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:jm [at] jm.kir.nu]On Behalf Of ext

> Jouni Malinen

> Sent: 15 September, 2004 06:35

> To: Haverinen Henry (Nokia-ES/Jyvaskyla); jsalowey [at] cisco.com;

> jari.arkko [at] ericsson.com

> Cc: eap [at] frascone.com

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

>

_______________________________________________

eap mailing list

eap [at] frascone.com

http://mail.frascone.com/mailman/listinfo/eap