Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Shumon Huque <shuque@isc.upenn.edu> Fri, 26 August 2005 14:32 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fFt-0000JP-64; Fri, 26 Aug 2005 10:32:29 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fFp-0000Gn-D9 for secmech@megatron.ietf.org; Fri, 26 Aug 2005 10:32:27 -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 KAA23799 for <secmech@ietf.org>; Fri, 26 Aug 2005 10:32:21 -0400 (EDT)
Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fGW-0000DU-MW for secmech@ietf.org; Fri, 26 Aug 2005 10:33:09 -0400
Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id ED7B84477; Fri, 26 Aug 2005 10:32:14 -0400 (EDT)
Date: Fri, 26 Aug 2005 10:32:14 -0400
From: Shumon Huque <shuque@isc.upenn.edu>
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050826143214.GA9194@isc.upenn.edu>
References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com> <Pine.LNX.4.61.0508252336520.5325@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.61.0508252336520.5325@internaut.com>
User-Agent: Mutt/1.4.2.1i
Organization: University of Pennsylvania
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
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

On Thu, Aug 25, 2005 at 11:40:04PM -0700, Bernard Aboba wrote:
> 
> > It could also be possible to still involve a AAA and have it terminate
> > the method and talk to the KDC. If you are trying to implement a method
> > that is evaluated by both the NAS and the AAA in the same transaction
> > you are really doing something other than EAP. 
> 
> In all the EAP Kerberos proposals I've seen the method is terminated on
> either the NAS or AAA server, but not both.  But in any scenario, the
> NAS still needs to support Kerberos, in order to validate the "network
> access" service ticket. 

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.
If we need the NAS to support Kerberos, then I think the barrier 
to practical deployment is too high. Or am I missing something?


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