Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Nicolas Williams <Nicolas.Williams@sun.com> Fri, 26 August 2005 15:33 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gCV-0000DM-H4; Fri, 26 Aug 2005 11:33:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gCU-0000D9-9H for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:33:02 -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 LAA27190 for <secmech@ietf.org>; Fri, 26 Aug 2005 11:32:57 -0400 (EDT)
Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gD9-0002Ip-Hw for secmech@ietf.org; Fri, 26 Aug 2005 11:33:47 -0400
Received: from centralmail2brm.Central.Sun.COM ([129.147.62.14]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j7QFWq2B011338 for <secmech@ietf.org>; Fri, 26 Aug 2005 08:32:52 -0700 (PDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7QFWqLG000419 for <secmech@ietf.org>; Fri, 26 Aug 2005 09:32:52 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7QFWoOq017469; Fri, 26 Aug 2005 10:32:50 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7QFWnr0017468; Fri, 26 Aug 2005 10:32:49 -0500 (CDT)
Date: Fri, 26 Aug 2005 10:32:49 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: "Salowey, Joe" <jsalowey@cisco.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050826153249.GL15718@binky.Central.Sun.COM>
References: <7210B31550AC934A8637D6619739CE6905C8BF21@e2k-sea-xch2.sea-alpha.cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7210B31550AC934A8637D6619739CE6905C8BF21@e2k-sea-xch2.sea-alpha.cisco.com>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: secmech@ietf.org, Bernard Aboba <aboba@internaut.com>
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 Fri, Aug 26, 2005 at 08:06:48AM -0700, Salowey, Joe wrote: > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Thursday, August 25, 2005 11:40 PM > > > > 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). I agree. As for fast reconnect/handoff, which I'd mentioned earlier, the re-use of TGTs and service tickets (within their lifetimes), can save round trips in the IAKERB method, but doesn't really amount to fast reconnect/handoff in pass-through mode in that the method must be used everytime and so the EAP server is involved always. What is the exact definition of "fast reconnect/handoff" anyways? RFC3748's description of "fast reconnect" does not say very much. > > 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. I agree. If the NAS speaks Kerberos V and, more importantly, if there's a cross-realm path from the peer's principal's realm to the NAS's realm, then NAS is (should be) the EAP server also; if the NAS does not speak Kerberos or there is not such x-realm path then, as far as the NAS is concerned, the EAP Kerberos V method is like any other AAA method. Nico -- _______________________________________________ SECMECH mailing list SECMECH@lists.ietf.org https://www1.ietf.org/mailman/listinfo/secmech
- [SECMECH] Framework Bindings Vs. Mechanism Bridges Salowey, Joe
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Salowey, Joe
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Salowey, Joe
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Shumon Huque
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Shumon Huque
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Shumon Huque
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Josh Howlett
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Josh Howlett
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Josh Howlett
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Shumon Huque
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Salowey, Joe
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Ali Fessi
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Josh Howlett
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Jari Arkko
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Jari Arkko
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Jari Arkko
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Shumon Huque
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Josh Howlett
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Shumon Huque
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Josh Howlett
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Salowey, Joe
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Nicolas Williams
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Salowey, Joe
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy
- RE: [SECMECH] Framework Bindings Vs. Mechanism Br… Bernard Aboba
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Clint Chaplin
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… 1und1
- Re: [SECMECH] Framework Bindings Vs. Mechanism Br… Charles Clancy