Subject: Re: [MOBILE-IP] Comments on draft-haverinen-mobileip-gsmsim-00.tx t

From: Henry Haverinen <[email-masked]>
Date: Tue, 25 Jul 2000 11:05:51 +0300

Hello Pat,

I'm sorry it took me so long to reply your mail.

> > The "AAA server" in this case is deep within the GSM cloud.
> > Therefore, the "MN-AAA key" (which is the GSM SIM key Ki) cannot be
> > used in arbitrary ways. The mobile node must get the RAND values
> > from the AAA server before it is able to generate a usable key.
> >
...
> OK, here is where my mis-understanding is. I was under the
> impression that the
> Mobile has a secret that it shared with some entity in its
> home network. Be it
> a AAA server, the Authentication Center, the HLR, whatever.
> This is the key
> that is used to decrypt the dynamic keys, and the one I was
> proposing that is
> used to generate the authentication extensions.
>
> Is there a particular reason why this long lived key cannot
> be used in the
> initial round trip? Or is there truly NO long lived key, and
> there is magic
> involved in the key decryption that I am unaware of :)

There truly is a long lived key (Ki) on the SIM, but it can only be
used as input to the GSM authentication algorithms that run
on the SIM. The SIM card does not (and must not) have an interface for
reading Ki. The reason is to make it harder to duplicate SIM cards.
The GSM SIM specification (02.17) reads:
"All reasonable steps shall be taken to ensure that the algorithms
(A3 and A8) and subscriber authentication key (Ki) cannot be
read, altered, manipulated or bypassed in such a way as to reveal
secret information."

On the mobile node, we could input "well-known" RANDs, or RANDs
that are based on the time of day, for instance, to the SIM
authentication algorithms and generate an authentication key for
the first round trip. However, since
we want to leverage the existing GSM networks, we wouldn't
be able to generate the same keys on the network side. In the
GSM world, the authentication center must generate the RANDs.
By not requiring changes to the GSM network, we'll be able to
use the existing GSM roaming and authentication
infrastructure.

What we have in mind is a gateway box on the border of the GSM and IP
networks. The gateway box talks standard GSM protocols (MAP) to the
GSM network and an AAA protocol to the IP network. Given an IMSI, the
gateway box is able to obtain the RAND challenges and the Kc keys that
correspond the RANDs from the authentication center of the subsriber's
home operator.  Thus, we need the first round trip for delivering the IMSI
to the gateway box and getting the RANDs back to the terminal.

I think we need to add a section about this architectural stuff
to the gsmsim draft to make it more understandable.

> > > How about all registrations (perhaps except the last reply)
> > > include the MN-AAA. This solves all of your problems, and you
> > > can REALLY ignore any un-authenticated message (which is what you
> > > should do!).
> > [...]
> > > What I am missing here is the lack of authentication
> > > extensions. The SIM Key Request is not an authentication
> extension,
> > > correct? Since  the Mobile already has a secret with the
> key generating
> > > entity, simply re-use that to secure the initial messages...
> >
> > As explained above, the equivalent of the MN-HAAA key (Ki)
> is known to
> > the SIM card on the MN and the GSM AuC (authentication
> center), the latter
> > does not participate in the Mobile IP authorization process
> (because it is
> > deep
> > within the GSM cloud).
>
> Ahhh... here is my answer. Can the AuC then not perform some
> hashing of its
> own to generate the authentication extension response? Can it
> be modified in
> any way to handle this?

We don't want to modify the AuC or any other component of the GSM
network (as explained above). Thus we have to do all the Mobile IP
and Internet AAA specific tasks (generate the authentication extensions)
on the gateway box or on the mobility agents.

Regards,
Henry