IETF Logo Mail Archive

RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Bernard Aboba <aboba@internaut.com> Fri, 26 August 2005 19:36 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k01-0003MB-Hu; Fri, 26 Aug 2005 15:36:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8k00-0003Lm-Jm for secmech@megatron.ietf.org; Fri, 26 Aug 2005 15:36:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10368 for <secmech@ietf.org>; Fri, 26 Aug 2005 15:36:22 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8k0m-0001iK-9h for secmech@ietf.org; Fri, 26 Aug 2005 15:37:13 -0400
Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1E8jzw-000Fcy-U2; Fri, 26 Aug 2005 15:36:21 -0400
Received: by internaut.com (Postfix, from userid 1000) id E77BB24037; Fri, 26 Aug 2005 12:36:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id D975823523; Fri, 26 Aug 2005 12:36:19 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Originating-IP: 67.182.139.247
X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information)
X-MHO-User: aboba
Date: Fri, 26 Aug 2005 12:36:19 -0700
From: Bernard Aboba <aboba@internaut.com>
To: Charles Clancy <clancy@cs.umd.edu>
Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <Pine.GSO.4.60.0508261458430.16020@ismene>
Message-ID: <Pine.LNX.4.61.0508261234240.25291@internaut.com>
References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha. cisco.com> <Pine.LNX.4.61.0508252336520.5325@internaut.com> <191B6A09CAEEC043419A68E5@cumulus> <Pine.GSO.4.60.0508261036350.16020@ismene> <Pine.LNX.4.61.0508260807091.18505@internaut.com> <Pine.GSO.4.60.0508261405280.16020@ismene> <Pine.LNX.4.61.0508261146590.23743@internaut.com> <Pine.GSO.4.60.0508261458430.16020@ismene>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89
Cc: secmech@ietf.org
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

> I say it shouldn't know.  If the NAS connects to the right AAA server, then
> the above will happen.  Otherwise it won't.

In order to minimize handoff times, the EAP peer needs to know which NASes 
it has a valid key for, so that it can choose to roam to those NASes in 
preference to ones it has no key for. 

Having said that, IEEE 802.11r is currently looking at advertising that 
kind of information (e.g. NAS-Identifer, other scope parameters).  So it 
is conceivable that the EAP peer could know whether a given NAS could talk 
to a given AAA server before attempting to use a ticket with it. 

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech

v2.23.0 | Report a Bug | By Email