IETF Logo Mail Archive

Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

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

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8foN-0000Oc-Ej; Fri, 26 Aug 2005 11:08:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fhF-0007qM-Qc for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:00:45 -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 LAA25157 for <secmech@ietf.org>; Fri, 26 Aug 2005 11:00:43 -0400 (EDT)
Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fhz-00014F-8M for secmech@ietf.org; Fri, 26 Aug 2005 11:01:32 -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 1E8fhC-000O7C-Az; Fri, 26 Aug 2005 11:00:42 -0400
Received: by internaut.com (Postfix, from userid 1000) id A8AE22469D; Fri, 26 Aug 2005 08:00:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 9E3122469A; Fri, 26 Aug 2005 08:00:41 -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 08:00:41 -0700
From: Bernard Aboba <aboba@internaut.com>
To: Shumon Huque <shuque@isc.upenn.edu>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <20050826143214.GA9194@isc.upenn.edu>
Message-ID: <Pine.LNX.4.61.0508260752550.18505@internaut.com>
References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> <Pine.LNX.4.61.0508252336520.5325@internaut.com> <20050826143214.GA9194@isc.upenn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
X-Mailman-Approved-At: Fri, 26 Aug 2005 11:08:06 -0400
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

> The AAA server could perform the service ticket validation on
> behalf of the NAS. This requires another round trip with the 
> AAA server, but I don't think this is too much of a problem.

How does the EAP peer figure out the scope of usage of the "network access 
service" ticket?  If each NAS is a separate Kerberos principal, then the 
peer needs a distinct ticket for each NAS;  if the AAA server is the 
principal, then it can submit the same ticket to any NAS. 

> If we need the NAS to support Kerberos, then I think the barrier 
> to practical deployment is too high. Or am I missing something?

I think that the NAS needs to be modified even in the case where the AAA 
server is the Kerberos principal, in order to be able to securely inform 
the EAP peer of the ticket scope.  Otherwise, the EAP peer can't know when 
it needs to acquire another ticket. 

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

v2.23.0 | Report a Bug | By Email