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

[Uma Shankar Ch (umas]

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