RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

"Salowey, Joe" <jsalowey@cisco.com> Fri, 26 August 2005 15:02 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fid-0008FI-3E; Fri, 26 Aug 2005 11:02:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fib-0008E5-8S for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:02:09 -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 LAA25219 for <secmech@ietf.org>; Fri, 26 Aug 2005 11:02:07 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fjK-00017V-J5 for secmech@ietf.org; Fri, 26 Aug 2005 11:02:56 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2005 08:01:58 -0700
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7QF1qQM021684; Fri, 26 Aug 2005 08:01:53 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Date: Fri, 26 Aug 2005 08:06:48 -0700
Message-ID: <7210B31550AC934A8637D6619739CE6905C8BF21@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Thread-Index: AcWqCcdGZ+WYoNU1T9eJ2IHMCl+A1wARDwPQ
From: "Salowey, Joe" <jsalowey@cisco.com>
To: "Bernard Aboba" <aboba@internaut.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Content-Transfer-Encoding: quoted-printable
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

 

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Thursday, August 25, 2005 11:40 PM
> To: Salowey, Joe
> Cc: Ali Fessi; secmech@ietf.org
> Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
> 
> > > EAP-Kerb/IAKERB/GSS is inherently different other EAP methods 
> > > because it requires support for the method on the NAS.  
> That is, the 
> > > NAS needs to support Kerberos for a peer to be able to 
> submit a TGS 
> > > to the NAS in order to obtain network access.
> > > 
> > [Joe] I'm not quite sure what you mean. If a AAA server is not 
> > involved then this is not really any different than 
> terminating EAP-TLS on a NAS.
> 
> It's different because the NAS needs to support Kerberos even 
> if it is operating in "Pass-through" mode.  

[Joe] Then its not operating in "Pass-through" mode, it is terminating
EAP (acting as an EAP server).

> In contrast, a 
> NAS operating in pass-through mode for EAP-TLS doesn't need 
> to validate the client certificate. 
> 
> > 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. 

[Joe] If this is done in the same method execution instance it seems
problematic to me, because you have in effect two EAP-servers (one in
the AAA and one in the NAS) processing the EAP messages.  This is not
EAP. 

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