Subject: [MOBILE-IP] Comments on draft-haverinen-mobileip-gsmsim-00.txt

From: "[email-masked]" <[email-masked]>
Date: Mon, 26 Jun 2000 13:53:01 -0700

I have some comments on the above mentioned Internet Draft.

PatC

1. The title is misleading. It currently reads "GSM SIM Authentication for
Mobile IP", and perhaps should be changed to "GSM SIM Authentication and Key
Generation for Mobile IP". An alternative is to split up the functionality
into two, but I am not sure whether one could use the authentication scheme
described in the draft without key generation.

2. Section 1.0 states:
  "GSM subscribers are identified by an IMSI (International Mobile
   Subscriber Identifier), which is a string of digits. The format of
   IMSI is specified in [3]. The mobile node sends its IMSI to the
   mobility agent it is registering with in the first Registration
   Request."
There has been some talk in 3GPP2 to support NAIs on the SIM card. Is 3GPP
looking at something similar? It would terribly useful for the existing AAA
infrastructure to be able to key off the same information to determine where
the requests must be forwarded to.

3. Section 1.0 states:
  "The SIM key exchange uses two Mobile
   IP registration round trips. One reason for using two round trips is
   to let the GSM infrastructure generate the RANDs. This aims at
   facilitating the integration with the existing GSM networks. Another
   reason for using two round trips is to protect against SIM cracking
   attacks."
This is a fairly substantitive change to Mobile IP, and there are high chances
that the authentication will be done with an AAA server. 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.
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

So, a change to the Challenge/Response draft may be necessary. I would much
prefer that this doesn't require a change in the current draft, but rather a
change in the PS->DS document (at which point we should have a pretty good
idea whether this draft will survive).

4. Section 3.1, figure 1 shows:
   Mobile Node                                     Mobility Agent
       |                                                 |
       | Reg. Request + NAI ext. + SIM Key Request ext.  |
       | Auth. ext. calculated with old key (if exists)  |
       |------------------------------------------------>|
I would prefer that we remove Mobility Agent, and substitute it for
"Authenticating Entity". Of course, the AE MAY be the Home Agent, but it could
also be an AAA server.

5. Section 3.1 states:
   "In this context, the NAI extension contains the user's IMSI."
An IMSI does NOT conform to the syntactical rules specified in RFC 2486, so
unless some changes are done to the AAA protocol, the AAA servers will not
know how to "route" the requests. I do remember some work a while back that
proposed using IMSI to map to NAI (or something along these lines). 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.

6. Section 3.1 states:
   "The mobile node SHOULD use a good source of randomness for generating
    nonceMN."
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

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?
Furthermore, is  h(n*Kc | nonceMN) using traditional MD5, while MAC(K, n*RAND
| key lifetime) uses the HMAC version?

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. If this is the
case, I would prefer to not see the NAI be overloaded, and a new extension
created to contain the IMSI.

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.

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.

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

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.

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.

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. A Mobility Entity
that receives an non-skippable and unrecognzied extension should return an
error. Otherwise, you have no idea why no response is being received. Is it
because the Mobility Agent is no longer available, is it the request?

15. Section 2.6 states:
   "Later, we can specify support for parallel processing of SIM Key
    Request in the Foreign Agent. This means that the foreign agent may
    forward a Registration Request to the home agent and do the new
    session key exchange in parallel. The foreign agent would wait for
    the home agent's reply and insert the SIM Key Reply extension to it.
    This would speed up the first registration and allow grace periods.
    Adding this won't require any changes to the specified protocol
    messages."
Is this an editor's note?

16. Section 4.3 states:
     "Error code

        The MN-FA SIM Key Reply and MN-HA SIM Key Reply extensions use
        the following error codes:

        1 Reason unspecified
        2 Operator does not have a roaming agreement with user's home
          operator.
        3 Users calls are barred.
        4 Insufficient resources.
        5 User does not have the service subscribed."
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.