[Seamoby] issue-#50: Add statement about authentication of MN-AR CARD Requests
"James Kempf" <kempf@docomolabs-usa.com> Thu, 06 May 2004 20:43 UTC
Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17952 for <seamoby-archive@odin.ietf.org>; Thu, 6 May 2004 16:43:25 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpbp-00048C-1H for seamoby-archive@odin.ietf.org; Thu, 06 May 2004 16:36:45 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i46KajVU015881 for seamoby-archive@odin.ietf.org; Thu, 6 May 2004 16:36:45 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpVK-00008O-Sg for seamoby-web-archive@optimus.ietf.org; Thu, 06 May 2004 16:30:02 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17420 for <seamoby-web-archive@ietf.org>; Thu, 6 May 2004 16:30:00 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLpVJ-0006nC-0m for seamoby-web-archive@ietf.org; Thu, 06 May 2004 16:30:01 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpUN-0006NO-00 for seamoby-web-archive@ietf.org; Thu, 06 May 2004 16:29:04 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BLpTO-0005xi-00 for seamoby-web-archive@ietf.org; Thu, 06 May 2004 16:28:02 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpNb-0005UI-3S; Thu, 06 May 2004 16:22:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BLpKf-0003Ta-G9 for seamoby@optimus.ietf.org; Thu, 06 May 2004 16:19:01 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17061 for <seamoby@ietf.org>; Thu, 6 May 2004 16:18:58 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BLpKd-0002CR-On for seamoby@ietf.org; Thu, 06 May 2004 16:18:59 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BLpJg-0001nq-00 for seamoby@ietf.org; Thu, 06 May 2004 16:18:01 -0400
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1BLpIz-0001PQ-00 for seamoby@ietf.org; Thu, 06 May 2004 16:17:17 -0400
Message-ID: <014701c433a7$37fe1550$366115ac@dcml.docomolabsusa.com>
From: James Kempf <kempf@docomolabs-usa.com>
To: seamoby@ietf.org
Date: Thu, 06 May 2004 13:17:54 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Subject: [Seamoby] issue-#50: Add statement about authentication of MN-AR CARD Requests
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-BeenThere: seamoby@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=unsubscribe>
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
List-Post: <mailto:seamoby@ietf.org>
List-Help: <mailto:seamoby-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/seamoby>, <mailto:seamoby-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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 _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby