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

From: Henry Haverinen <[email-masked]>
Date: Fri, 30 Jun 2000 12:50:52 +0300

Hello Pat,

This mail contains comments from N. Asokan ([email-masked]),
thanks Asokan!

[IMSI format]
> I do believe that an Internet-Draft needs to be written that
> describes the
> format above, and informational would be fine. The only issue
> I have is that
> the above implies that both the phone AND the laptop (in the
> case where the
> browser is on the laptop) need to be configured. One with IMS
> and the other
> with the NAI. I am not sure if most phones can have their
> IMSI's retrieved via
> a standard fashion, otherwise Mobile IP will have to run on
> the phone (and
> then they don't have access to the other information on the laptop).

I'll craft an appendix to the GSM SIM draft about the IMSI
format and the use of the IMSI as part of the NAI. An appendix
should be enough, since GSM IMSI issues are specific to this
contribution.

In addition to getting the IMSI from the SIM card, the Mobile IP
software needs to use the SIM card for getting the Kc keys that
correspond to given RANDs.
We could use smart card readers on the laptop. For example,
the Nokia 11 Mbit/s WLAN card has a built-in smart card reader.
Or we could run Mobile IP on PDA type of phones.

> My point was that ALL registration requests will have to
> include either the MN-HA (and perhaps MN-FA), or the MN-AAA
> authentication extension. I believe that your model works
> very well with the MN-AAA. The Mobile can use the key it
> shares with the AAA server (perhaps even the one it uses to
> decrypt the key), to generate the MN-AAA authentication extension.
> All that  would need to be done would be to provide the Registration
> Request to the SIM,  and have it generate the response, which is then
> included in the RegReq.

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.

In other words, the mobile node doesn't have any key available until
the first round trip has been completed. Thus, the first round trip
will have to use some sort of bogus authentication extensions or
bogus AAA extensions.

Using dummy MN-AAA authentication extension instead of dummy
MN-FA or MN-HA authentication extensions does seem to have the
advantage that it avoids the need for mobility agents (FA or HA) to
know about the GSM Key Request sub types: when they see an MN-AAA
authentication extension, they'll promptly forward the key request and
the authext to the AAA server. This needs further study.

> > > 7. Section 3.1 states:
> > >    "The default hash function is MD5 [6] and the default MAC
> > > function is
> > >     HMAC-MD5 [7]"
> > > Is the above stating that both MD5 (in the traditional sense)
> > > and HMAC MD5 are
> > > simultaneously used? Is this for compatibility with the
> > > existing SIM card?
> >
> > It's not for compatibility, it's just that the key is generated
> > with a one-way hash function h(), which is not a message
> authentication
> > code, and there are actual message authentication codes
> used as well.
> > MD5 is used as the one-way hash function for generating the key.
>
> MD5 is not a key generation algorithm, unless you have a
> REALLY good random
> generator function, and the output it put through MD5, but I
> don't see the
> benefits. Did you, perhaps, mean to state that MD5 is used to
> "mask" the key?

Yes, MD5 is not a key generation algorithm, and it wasn't our intent.
We use the hash function as a mixing function to combine several
session keys (Kc's) generated by the GSM authentication procedure into a
single key to be used in Mobile IP.  The reason for this is twofold:
- the current GSM session keys are at most 64 bits; so two or more of
  them are needed to generate a 128 bit key
- by using a one-way hash function to combine the keys, we are assured
  that the even if an attacker manages to learn the key used in Mobile
  IP, it doesn't help him in learning the original GSM Kc's.  This
  seems to be a reasonable precaution given that we are using GSM SIM
  authentication procedure in ways not intended by the original
  designers.

> 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).  The gateway between the GSM and the IP world
cannot know Ki. The Mobile IP software on the mobile node cannot know it
either, since the SIM card does not have (and is not allowed to have)
an interface for retrieving Ki. Hence, it is not possible to
use MN-AAA authentication extensions in the normal way.

> Well, if a key is bi-directional, you could have the mobile
> "suggest" the SPI
> to use when communicating with it, and the same for the Home
> Agent.

RFC 2002 bis reads that SPI is "an index identifying a security context
between a pair of nodes among the contexts available in the Mobility
Security Association". A Mobility Security Association is
"a collection of security contexts, between a pair of nodes,
which may be applied to Mobile IP protocol messages exchanged between them."

Our keys are bi-directional. Since a Mobile IP entity is able to uniquely
identify the security context with the pair (SPI, peer's IP address),
I think it's enough if the mobile node suggests the SPI. It doesn't matter
if the mobility agent is already using the same SPI with some other
Mobile IP entity, since the security context is identified with the
above mentioned pair.

But we still need a well-known SPI for "bogus authentication extension".
I'll rewrite the SPI assignment section in the draft.

> Simplicity is nice, but keep in mind that EVEN with RFC 2002,
> it is possible
> for the Home Agent to have a problem with the request, and
> the Foreign Agent
> to have a problem with the reply. In this case, both nodes
> would insert their
> error code into the reply. Since there is a precendence, I
> would prefer that
> this method be re-used.

I agree. I'll remove the reply code from the SIM Key Reply
extensions and specify that the code in the Reg.Reply will be
used.

Best regards,
Henry

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 30 Jun 2000 07:19:58 -0700

> should be enough, since GSM IMSI issues are specific to this

That sounds very reasonable.

> the authext to the AAA server. This needs further study.

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 :)

>   authentication procedure in ways not intended by the original

ok, and perhaps that is the answer to my previous question. However, if so, I
would argue that the amount of traffic generated using the long lived key will
not provide enough data for the malicious hacker to find the key, short of a
brute force attack. >
> 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?

PatC