issue-#50: Add statement about authentication of MN-AR CARD Requests

The issue is:

    Are MN-AR CARD Requets to be authenticated from ARs, or do
    ARs just reply to all requests that appear below a given max
    request rate?

    If CARD Requests are to be authenticated, which mechanisms
    should be used?

    Should a clarifying section be added to chapter 6 "Security
    Considerations"?

In response to this, we need to think about the prerequisites for MN-AR CARD
Requests to be authenticated. In order for this to occur, there needs to be
some kind of security association between the MN and the AR. To set up this
security association would require either a prior AAA transaction to
exchange shared keys, or that the MN possess a certificate.
In general, any security protocol that requires end hosts to be provisioned
with certificates will have a difficult time being deployed, because most
service providers don't have the infrastructure to do certificate
provisioning to end hosts. While most service providers do have some form of
AAA, support for end host provisioning of a key for this purpose typically
doesn't exist. Also an important class of operators, the 802.11 WISP
operators, don't do standard AAA but rather use a HTML/credit card
authentication and authorization. So requiring the CARD Request to be
authenticated would require the existence of AAA or PKI infrastructure that
currently doesn't exist. In essence, it has the same infrastructure
requirements as requiring the MN and AR to use IKE to set up an IPsec SA,
which the IESG has already identified as too heavy weight.

One argument against this point is that CARD is an experimental protocol
anyway, perhaps by the time it is standardized there will be such support
for end hosts. While this argument may have some validity, one has to look
deeper at what authenticating the MN-AR CARD Request means. It means that
the AR isn't ready to give out the information about CARs except to hosts
that can authenticate themselves to prove their authorization to receive
that information. But isn't the authorization to have this information
granted by link access in the first place, since the information provided is
a means whereby the MN maintains link access during handover? Therefore, it
seems as if the initial AAA transaction to allow the MN onto the link should
be sufficient to authorize it for obtaining further information on link
access. In that sense, it is exactly like Router Advertisements, and
requiring any further authentication from the MN would be redundant.

In contrast, CARD Replys must be authenticated because the MN must make sure
that they are coming from a router that can be trusted. Returning to the
802.11 WISP example, a bogus AP connected to a bogus AR could be used to
spoof the MN into connecting to an AR that would steal its traffic, if the
MN doesn't authenticate the CARD Replys. The MN must authenticate Router
Advertisements (in SEND) for the same reason.

So the recommended resolution for this issue is that we add the following
paragraph to Section 6:

      No authentication is required for CARD Requests on the AR. CARD
      information is provided by the AR to facilitate link access, and the
      MN's authorization to obtain such information is implicitly granted
      by the admission procedure used to grant link access to the MN in
      the first place. In contrast, CARD Reply authentication is required
      on the MN because a bogus AR could provide the MN with
      CARD information that would lead the MN to handover to a
      bogus router which could steal traffic or propagate a denial of
      service attack on the MN. The asymmetry of the authentication
      requirement is the same as that involving Router Advertisements
      in IPv6 router discovery [SEND].



                jak