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

From: Henry Haverinen <[email-masked]>
Date: Wed, 28 Jun 2000 11:43:10 +0300

Hello Pat,

Thank you for your comments!

> 1. The title is misleading.

Yes, adding "key generation" to the title could clarify it.
I don't think it's possible or even necessary to split up
the functionality into authentication and key generation.

> There has been some talk in 3GPP2 to support NAIs on the SIM
> card. Is 3GPP
> looking at something similar?

I don't know. Storing the NAI on the SIM card would of course be
very useful. With traditional SIM cards, the mobile node software
probably needs to map the IMSI to a NAI. We could use NAIs like
IMSI@realm. Since we currenly have no way of deducing the realm
from IMSI, the realm could be configured to the Mobile IP software.
This is what I intented to say in my draft, but it obviously needs
clarification.

I think that IMSI conforms to RFC2486 as the user part of a NAI.

> What is needed is an Internet Draft that defines the components of
> the IMSI, and how
> an AAA server determines where the Home AAA server is.

The IMSI is composed of a three digit Mobile Contry Code (MCC),
a two digit Mobile Network Code (MNC) and a not more than 10 digit
Mobile Subscriber Identification Number (MSIN). MCC and MNC uniquely
identify the GSM operator.
I guess we could reserve well known AAA domains for GSM operators,
for example domains operator<MNC><MCC>.gsm.org. Then an IMSI could be mapped

to a NAI like this: MSIN@operator<MNC><MCC>.gsm.org.

Or perhaps GSM operators could establish a broker AAA server (for
example gsm.org) which would know where to route the AAA requests.
In this case we could use NAIs like [email-masked].

Once such a convention is established, an (informational?) Internet-Draft
would be useful.

> 3. Section 1.0 states:
>   "The SIM key exchange uses two Mobile
>    IP registration round trips.
> This is a fairly substantitive change to Mobile IP, and there
> are high chances
> that the authentication will be done with an AAA server.

First we thought of using an Agent Solicitation and an
Agent Advertisement for the first round trip. However,
that wouldn't have worked for the key exchange with the home
agent (for example when we're using co-located addresses).

The GSM case is a good example when it makes sense to have a
different AAA home domain (the GSM operator) and Mobile IP home domain
(for example user's corporation). The AAA domain may not be
able to assign a home agent for the mobile node, but the mobile node
would be configured with a home agent address (perhaps anycast in
the IPv6 case).

The home agent could use a pull sequence to talk to the
user's HAAA server. I don't see much difference in the roles of
the foreign agent and the home agent in this case.
We're also testing the protocol with co-located care-of addresses,
so the home agent may be the first mobility agent the mobile node
is in contact with.

> Unfortunately, the
> current Challenge/Response Internet Draft, which has been
> through WG and IESG
> last call, does not allow the MN-AAA to be present in the
> Registration Reply.

Our draft uses MN-HA Key Replies, so is that an issue?
BTW, we're also using MN-HA Key Requests, which are not
specified in the current version of the generalized key
distribution extensions draft.

The GSM case shows that session keys are not always
transported to the MN but they can be derived by the MN,
based on some seed values. I suppose there could be other
similar authentication methods which could require two round
trips as well.

> However, thinking about your proposal, it would require that
> the first round
> trip response be sent by the AAA server given that:
>         1. The user hasn't been authenticated, and
>         2. There may not be a Home Agent assigned

The home agent could handle item 1 with a bogus Authentication
extension. Item 2 is more difficult. I guess dynamic home
agent assignment can only be used when the mobile node is using foreign
agent care-of addresses. In this case the HAAA server would sent the
first response. But then we couldn't use MN-HA key requests/replies?

I agree that we should wait until the PS->DS phase before
changing the Challenge/Response draft.

> I would prefer that we remove Mobility Agent, and substitute it for
> "Authenticating Entity".

OK, that shouldn't be a problem.

> I would add a reference to:
>         D. Eastlake, 3rd, S. Crocker, and J. Schiller.  Randomness
>         Recommendations for Security.  Request for Comments
>         (Informational) 1750, Internet Engineering Task
> Force, December
>         1994

Thanks!

> 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.
Message authentication codes are generated with HMAC_MD5, although
I could have specified MD5 in prefix+suffix mode (which is a MAC function)
to be used as well. Do you think this is a problem?

> 8. Section 3.2 states:
>    "This message contains a SIM Key Request
>     extension and the IMSI in a NAI extension [8]. The SIM Key Request
>     extension contains a random number nonceMN picked by the
> mobile node
>     and a key lifetime proposal. The NAI extension contains the user's
>     NAI (Network Access Identifier) [9]"
> The above implies that the request contains TWO NAI
> extensions.

No, the request contains just one NAI extension, where the NAI has been
mapped from the IMSI. I'll rewrite this part more clearly.

> 9. Section 3.3 states:
>    "In this case, the
>     mobile node may retry the key exchange immediately. If,
> however, the
>     Registration Reply doesn't contain a valid authentication
> extension,
>     the mobile node must consider this message informational.
> The mobile
>     node must not change its state or react to it in any way except
>     write an entry to a log or show an error message to the user."
> Is this true? If an unauthenticated reply is received, then it isn't
> informational at all, but a likely malicious reply. Since one cannot
> distinguish one from the other, I would simply state that
> receiving such a
> message should be logged or ignored.

I guess "informational" is not a good term.
The words "doesn't contain a valid authentication extension"
are intended to cover the bogus authentication extensions which the
home agent might need to use if there is no previous MN-HA session key.
If the error is for example "user does not have the service subscribed",
it would be good if we could show this to the user.

Maybe unsuccessful SIM Key Replies could also be accompanied with a
RANDs and MAC_RAND, just to authenticate the reply message? In this
case it would be safe to show the message to the user.

> 10. Section 3.3 states:
>    "Discussion: Instead of sending an empty authenticator, should we
>     omit the Mobile-Home Authentication extension if the
> mobile node and
>     the home agent do not share an authentication key? This should be
>     clarified once [1] is augmented with a specification of MN-HA Key
>     Request extension."
> Discussion: no. My Foreign Agent ensures that either of the
> following is
> present: 1. MN-AAA, or
> 2. MN-HA (and MN-FA is configured as mandatory)
> I would have a serious problem with a request that does not contain an
> authentication extension with the Home Domain, even if the
> information is
> bogus.

OK.

> 11. Section 3.3 states:
>    "If the mobile node and the foreign agent do not share a security
>     association, authentication extensions are not used in the..."
> I presume the above should have read:
>    "If the mobile node and the foreign agent do not share a security
>     association, the Mobile-Foreign authentication extension is not
>     used in the..."

Yes, you're right.

> Of course, this is much more problematic than the above,
> since the Foreign
> Agent would have to know that the Mobile doesn't have an SA, and the
> Mobile-Foreign contains cannot be authenticated. In the
> Challenge/Response
> draft, this is solved by not requiring that the MN-FA be
> present if the MN-AAA
> is present. How would you propose to solve this issue in this draft?

MN-FA is not required to be present in the Reg.Request if MN-FA SIM Key
Request
is present, and MN-FA is not required to be present in the Reg.Reply if
MN-FA SIM Key Reply is present? If the foreign agent
requires Mobile-Foreign Authentication, this reply would
have the code 67, "Mobile node failed authentication".

If this is not the first SIM key exchange between the mobile node and
the foreign domain, then MN-FA can be present. The authenticator is just
calculated with the previous session key.

> 12. Section 3.4 states:
>    "The mobility agent uses an AAA protocol to send the
> MAC_SRES to the GSM
>    network, which verifies it and sends an indication to the
> mobility agent."
> This is the first time that the AAA protocol is discussed to
> transport the
> Mobile IP messages. It (sort-of) implies that this is only
> done on the second
> round trip. Perhaps similar language needs to be crafter
> earlier on in the
> document when discussing the other extensions. This would
> eliminate the
> possible confusion.

Yes, I'll craft similar language for the first round trip as well.
An AAA protocol is needed there too.

> 13. Section 3.5 states:
>    "The security association created with the session key exchange
>     mechanism described above must have a Security Parameter Index
>     (SPI). We use the well-known SPI SIM_SECURITY_CONTEXT_SPI (Section
>     5.1) for SIM-generated security association. Since the Mobile IP
>     entities identify security associations with the pair (peer's IP
>     address, SPI), it is possible to use the same SPI between all the
>     entities."
> Would it be possible to have a different rule? The initial
> message cotains the
> specified SPI above, and the key generating entity forms an
> SPI with the key.
> All authentications using the generated key would use the SPI that was
> provided with the key. This way, when a new key is generated,
> a new SPI is
> used. This makes it MUCH easier to identify the key to use in order to
> authenticate.

Sure we can use a different rule. This SPI business has just always
puzzled me...

In the generalized key distribution extensions, only
the key request contains an SPI (Mobile Node SPI). The foreign agent
and the home agent do not pick an SPI.
Once the key has been distributed, is the Mobile Node SPI
in used both ways, for both Registration Requests and Replies?

> 14. Section 3.6 states:
>    "The SIM Key Request extension is a non-skippable extension, so if
>     the foreign agent doesn't support it, it silently discards the
>     Registration Request."
> Personally, I think that RFC 2002 bis MUST fix this problem.

It would make sense. I don't think this fix would make it very much
easier to bring the mobility agent to its knees with a denial
of service attack. However, in this case an unauthenticated Reg.Reply
with an error code wouldn't help much, as the mobile node would silently
discard it.

> 15. Section 2.6 states:
>    "Later, we can specify support for parallel processing ---
> Is this an editor's note?

Yes it is. I wasn't sure if such parallel processing would be feasible.
This needs further thought.

> Is there a particular reason why the code in the Registration
> Reply cannot be
> re-used? It would make it MUCH simpler to parse and find an error.

There could be MN-FA and MN-HA SIM key exchanges going on in parallel.
If a Registration Reply contains both a MN-FA SIM Key Reply and
a MN-HA SIM Key Reply, we can have two failure codes, so both
the foreign agent and the home agent cannot set the code in Registration
Reply.

Another (not so important) reason is that the registration may be successful
even if the SIM key exchange fails. This can happen when we already have
a previous key to authenticate the registration messages that contain SIM
key
exhange extensions. On the other hand, if the key exchange fails, it doesn't

help much to know that the registration was successful.

If we don't support parallel MN-FA and MN-HA key exchanges, then
I guess we could use the code in the Reg.Reply.

Best regards,
Henry

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 28 Jun 2000 09:05:33 -0700

> Thank you for your comments!

My pleasure. I found this I-D most intriguing...

I have additional comments below.

PatC

> I think that IMSI conforms to RFC2486 as the user part of a NAI.

This needs to be clarified in the draft.

> Once such a convention is established, an (informational?) Internet-Draft

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

Something that needs careful attention, IMHO.

> similar authentication methods which could require two round

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.

Of course, the above implies that I actually understand how the SIM works,
which I don't :(

> extension. Item 2 is more difficult.
I don't like bogus authentication extension... see my statement above on the
use of the MN-AAA.

> guess dynamic home
> agent care-of addresses.
Unless the mobile was able to communicate with the AAA infrastructure, but
that implies that the mobile supports AAA, and that it has a routable
address...

> In this case the HAAA server would sent the
This is not for authentication, though.

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

> to be used as well. Do you think this is a problem?

HMAC-MD5 is the correct way to do it. prefix+suffix has problems, and will
have to change when the IESG reviews the document (assuming it moves ahead, of
course).

> case it would be safe to show the message to the user.

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!).

> have the code 67, "Mobile node failed authentication".

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

> in used both ways, for both Registration Requests and Replies?
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. Or, you
could take a chance and have the key generating entity propose the SPI to both
entities. Of course, there is a 1 in 2^32 chance that the SPI is already in
use (assuming no more than 2 pending SPIs between the nodes). I think this is
a fairly safe assumption.

So, if we can (again) discuss the MN-AAA auth ext, then the Mobile Node would
use its secret, and the SPI associated with the long lived secret, to
authenticate the initial messages. When the key is distributed in the reply,
then Home Agent would authenticate it using the newly generate session key
(and its associated SPI).

> with an error code wouldn't help much, as the mobile node would silently

I wasn't discussing un-authenticated messages, but rather messages with an
unrecognized un-skippable extension. Silent discard is a problem in this case.

> This needs further thought.

I agree.

> I guess we could use the code in the Reg.Reply.

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.

PatC