[Mobopts] Fwd: RG Last Call for Media-independent Pre-Authentication Document

"Rajeev Koodli" <rajeev.koodli@gmail.com> Wed, 04 June 2008 18:33 UTC

Return-Path: <mobopts-bounces@ietf.org>
X-Original-To: mobopts-archive@megatron.ietf.org
Delivered-To: ietfarch-mobopts-archive@core3.amsl.com
Received: from [] (localhost []) by core3.amsl.com (Postfix) with ESMTP id A26E93A6CFF; Wed, 4 Jun 2008 11:33:24 -0700 (PDT)
X-Original-To: mobopts@core3.amsl.com
Delivered-To: mobopts@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id E91E43A6CFA for <mobopts@core3.amsl.com>; Wed, 4 Jun 2008 11:33:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id J1A-MqWNlQJ1 for <mobopts@core3.amsl.com>; Wed, 4 Jun 2008 11:33:19 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com []) by core3.amsl.com (Postfix) with ESMTP id D79F83A6CFB for <mobopts@irtf.org>; Wed, 4 Jun 2008 11:33:19 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 24so160208wfg.7 for <mobopts@irtf.org>; Wed, 04 Jun 2008 11:33:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=l4wPQAr7G/2RUW/5EnsobdgN7bhY5RSUW/SzyVonltg=; b=L165GC9iFHQz3Ln2lLVw3bLcoXhQ00GGcdbnGYcLw6iaOTUaqiWW+2F//8PkpLKXx4 ZXdt35H4sD0xxv2Lh8pBMjLAlBzGVhg5WHYxtKF49upDLJoVdcRFuyNguWaRjXmc884X R+3uC2kNvZIcRKHylK4UNY/6JO2NGWxRxzbkg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rkrQ2YfB0Ma9KsQDuL9F7mNlI+z/2/9Q9p9Y5FTeDNeNk9bR+NGAKS6BowAw3N18xY /6NiBT0RlTEihBS6m1TpwgvTtDCl4/eMVe8XTOp25MbKDRN/B3pRPOo2ZsE/thBL4R+B WIuFDZNp2gP1PGiTQHn26a8jN+ZJVz251f3l4=
Received: by with SMTP id l12mr93992wfj.272.1212604404250; Wed, 04 Jun 2008 11:33:24 -0700 (PDT)
Received: by with HTTP; Wed, 4 Jun 2008 11:33:24 -0700 (PDT)
Message-ID: <3d57679a0806041133w671823cqee16d3294b87c768@mail.gmail.com>
Date: Wed, 4 Jun 2008 11:33:24 -0700
From: "Rajeev Koodli" <rajeev.koodli@gmail.com>
To: "mobopts@irtf.org" <mobopts@irtf.org>
In-Reply-To: <13E2E485D9AA7240A1C55B0B464198B201E46202@ct11exm63.ds.mot.com>
MIME-Version: 1.0
Content-Disposition: inline
References: <4D35478224365146822AE9E3AD4A266602706812@exchtewks3.starentnetworks.com> <3d57679a0805161455l60264f1as95047174ebd0b0ed@mail.gmail.com> <13E2E485D9AA7240A1C55B0B464198B201DF500C@ct11exm63.ds.mot.com> <3d57679a0805221945r4d43416bwbf560b46ecc41749@mail.gmail.com> <3d57679a0805291124p2bb61609je8b3a3a89428e907@mail.gmail.com> <13E2E485D9AA7240A1C55B0B464198B201E46202@ct11exm63.ds.mot.com>
Cc: Nakhjiri Madjid-VXT746 <Madjid.Nakhjiri@motorola.com>
Subject: [Mobopts] Fwd: RG Last Call for Media-independent Pre-Authentication Document
X-BeenThere: mobopts@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobility Optimizations <mobopts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/mobopts>
List-Post: <mailto:mobopts@ietf.org>
List-Help: <mailto:mobopts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: mobopts-bounces@ietf.org
Errors-To: mobopts-bounces@ietf.org

A Review. Thanks Madjid.

---------- Forwarded message ----------
From: Nakhjiri Madjid-VXT746 <madjid.nakhjiri@motorola.com>
Date: Thu, May 29, 2008 at 5:24 PM
Subject: RE: [Mobopts] RG Last Call for Media-independent
Pre-Authentication Document
To: Rajeev Koodli <rajeev.koodli@gmail.com>
Cc: Nakhjiri Madjid-VXT746 <madjid.nakhjiri@motorola.com>


 I unfortunately think the doc has too much background material and
abstraction that takes the user through a lot of text (15 pages)
before it introduces any of its framework concepts and that makes
reviewing very tough if you are time constraint, sorry

I think one of the strong points that any doc about Pre-auth needs to
make is that many of the procedures such as handover keying and
reauthentication deal with cases where there is a single source of
trust at the top and all underlying AAA domains trust that top source
of trust and any keys it generates and distributes. In cases of
multiple operators without roaming relationship, or without agreement
to participate in a key management scheme, you do have to perform a
pre-auth function to establish the security mechanisms without
assuming a common source of trust.

the first paragraph of the intro can be toned down a bit with respect
to ordering of the challenges.

Is this expects to solve the seamless mobility problem even when there
is a single L2 interface? (intro) As much as this being a noble goal,
I think with the advances in Silicon and wireless devices, this is
overcomplication of the requirements. I do agree that the
multi-interface assumption has been one of the barriers for 802.21
though. I am wondering how a mobile performs pre-auth with an
authentication agent of a new access technology, while still connected
to the old one if it is single interface, also not clear how the
mobile acquires the IP address of this agent, as section 6.3 states if
it is not tuned to the new technology, sorry if I have not gone to end
of the document and not being far.
Third, a mobility
   optimization mechanism needs to support not only multi-interface
   terminals where multiple simultaneous connectivity through multiple
   interfaces can be expected, but also single-interface terminals.
section 1.1.
I am not sure if the document needs to go into a serial analysis of
every source of delay in the system. Since this is about pre-auth and
IP address acquisition, etc, it could simply just talk about those
things. so section 1.1 can undergo a serious diet.
A QoS style description of delay would not be needed either, IMO. On
the other hand, what that section really is missing is a description
of issues around reestablishing link security (authentication, link
key management, access authorization) in conjunction to network access
and handovers (inter or intra domain), because that is really the
focus of a pre-auth framework.

section 2
This type of Inter-technology handover is often
   called as Vertical Handover since the mobile makes movement between
   two different cell sizes.
I don't think Vertical handover is defined based on cell size, it is
defined based on the type of access technology (as listed).

I think an important point about Inter-domain, is not just where the
mobile is authenticated, but also where his user profile, credentials
are stored and where his payment is associated to. Because that will
define the difference between home and visited domains from the
security standpoint, the mobile has an initial and permanent trust
relationship with its home and any interaction with a visited domain
is based on a temporary and transitive trust established based on a
mobile-home trust and a home-visited domain roaming relationship.

I know it is a sticky subject, but probably AA (authentication agent)
needs to provide some IETF or other wireless examples (EAP
authenticator, ASN GW, etc) and also how the Authentication signaling
is to traverse over the new network if there is only one interface.

The parts with pre-configuration are ok from 802.21 perspective,
however I don't think this doc or framework should get into decisions
of which network to use is a network discover issue that assumes a
general broadcasting broker (I think 802.21 calls it information
 Decision regarding which
   candidate network the mobile needs to pre-authenticate with will
   depend upon several policies, such as signaling overhead, bandwidth
   requirement (QoS), mobile's location, communication cost, and
   handover robustness etc.
This just makes the framework for this protocol too large, and
academic, specially if things like specific server (that nobody would
take ownership of in a inter-domain scenario) come in.

Mobopts mailing list