Re: [Seamoby] issue-#48: Use of trusted-anchor sub-option between Access Routers

"James Kempf" <kempf@docomolabs-usa.com> Tue, 11 May 2004 18:01 UTC

Received: from optimus.ietf.org (iesg.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12680 for <seamoby-archive@odin.ietf.org>; Tue, 11 May 2004 14:01:42 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbSF-00018I-JF for seamoby-archive@odin.ietf.org; Tue, 11 May 2004 13:54:12 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i4BHsB1S004350 for seamoby-archive@odin.ietf.org; Tue, 11 May 2004 13:54:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNbIP-0007aI-QD for seamoby-web-archive@optimus.ietf.org; Tue, 11 May 2004 13:44: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 NAA11459 for <seamoby-web-archive@ietf.org>; Tue, 11 May 2004 13:43:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNbIN-0002hV-Nw for seamoby-web-archive@ietf.org; Tue, 11 May 2004 13:43:59 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNbHP-0002H6-00 for seamoby-web-archive@ietf.org; Tue, 11 May 2004 13:43:00 -0400
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1BNbGT-0001r0-00 for seamoby-web-archive@ietf.org; Tue, 11 May 2004 13:42:01 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNb4w-0003qa-AK; Tue, 11 May 2004 13:30:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BNatF-0000xN-Vi for seamoby@optimus.ietf.org; Tue, 11 May 2004 13:18: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 NAA09702 for <seamoby@ietf.org>; Tue, 11 May 2004 13:17:59 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BNatE-0006uW-1h for seamoby@ietf.org; Tue, 11 May 2004 13:18:00 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BNasE-0006UG-00 for seamoby@ietf.org; Tue, 11 May 2004 13:16:58 -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 1BNarF-00062i-00 for seamoby@ietf.org; Tue, 11 May 2004 13:15:58 -0400
Message-ID: <00c901c4377b$b7456520$366115ac@dcml.docomolabsusa.com>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Marco Liebsch" <marco.liebsch@ccrle.nec.de>
Cc: <seamoby@ietf.org>
References: <01db01c432ef$630b8b50$366115ac@dcml.docomolabsusa.com> <40A10023.8030507@ccrle.nec.de>
Subject: Re: [Seamoby] issue-#48: Use of trusted-anchor sub-option between Access Routers
Date: Tue, 11 May 2004 10:16:35 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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

Marco,

>
> Another point: Is the Trusted Anchor always to be sent from a mobile to
> it current AR in case of
> certificates are requested? If the current AR and a CAR share the same
> CA, the chain from the mobile's
> trusted CA to the ARs' CA should have been validated already in a
> previous request.

The Trusted Anchor only needs to be sent once, and only if the certificates
are required. If the mobile node has the certificate chain, either through
preconfiguration or through having received it through a previous router,
then the Trusted Anchor doesn't need to be sent. But the Trusted Anchor does
need to be sent if certs are required, otherwise the router won't know what
chain to reply with.

Can you suggest a place in the text where this should be made clearer?

> Hence, subsequent cert requests do not necessarily require a Trusted
> Anchor to be sent
> with the MN-AR CARD Request, right?
> Here, the flag could serve for the same purpose in the MN-AR CARD Request.
>

The cert request doesn't ever have to be done except once (and not even then
if the mobile node has the certs through some other means).

As for using the flag, I doubt the mobile node would really want to get all
the certs. Of course, access router certs are not yet deployed, so it is
difficult at this time to know exactly how many cert chains will be
necessary, but if this develops anything like the certs used for browser
traffic, then there could be hundreds of certs required on the router. I
don't think we want to encourage the mobile node to download all the cert
chains (if there are more than one), when it really only needs one.

> Furthermore, do we have to distinguish between a requested certificate
> of a CAR or
> a requested cert of a mobile's current AR?

Yes. The mobile uses the cert chain for the current AR to perform validation
of CARD messages on the current AR, it uses the cert chain for CARs to
perform CARD on other ARs.

> Well, I think the current
> mechanism
> uses the L2-ID for that. If the L2-ID belongs to an Access Point
> associated with the
> current AR, the cert of the current AR will be sent back, otherwise the
> cert of the CAR will
> be sent in the reply. Shouldn't we de-couple a cert request from the L2-ID
> sub-option?
>
> What do you think?
>

I think we need to distinguish. It is possible that an WISP would use one
set of certs for one part of the access network and another for another
part. If the mobile is in transition between the two, it must be able to
distinguish which certs belong to which routers. The L2-ID distinguishes,
and is included in the cert request in order to identify which AR is
designated.

            jak



_______________________________________________
Seamoby mailing list
Seamoby@ietf.org
https://www1.ietf.org/mailman/listinfo/seamoby