IETF Logo Mail Archive

RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

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

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8V8c-0002zx-JQ; Thu, 25 Aug 2005 23:44:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8V8c-0002zQ-1y for secmech@megatron.ietf.org; Thu, 25 Aug 2005 23:44:18 -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 XAA10961 for <secmech@ietf.org>; Thu, 25 Aug 2005 23:44:15 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8V9F-0005sq-IY for secmech@ietf.org; Thu, 25 Aug 2005 23:44:58 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 25 Aug 2005 20:44:07 -0700
X-IronPort-AV: i="3.96,142,1122879600"; d="scan'208"; a="656878423:sNHT29051500"
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7Q3i4oo014467; Thu, 25 Aug 2005 20:44:04 -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: Thu, 25 Aug 2005 20:48:57 -0700
Message-ID: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Thread-Index: AcWo8smOFhG4wmLUT72KpPpe8uFvrQA/E6Mg
From: "Salowey, Joe" <jsalowey@cisco.com>
To: Bernard Aboba <aboba@internaut.com>, Ali Fessi <ali.fessi@uni-tuebingen.de>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
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

> 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 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. 


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

v2.23.0 | Report a Bug | By Email