Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Nicolas Williams <Nicolas.Williams@sun.com> Thu, 25 August 2005 15:53 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8K2S-0003rj-It; Thu, 25 Aug 2005 11:53:12 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8K2R-0003re-2P for secmech@megatron.ietf.org; Thu, 25 Aug 2005 11:53:11 -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 LAA25639 for <secmech@ietf.org>; Thu, 25 Aug 2005 11:53:06 -0400 (EDT)
Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8K2t-0007Wl-Gf for secmech@ietf.org; Thu, 25 Aug 2005 11:53:43 -0400
Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j7PFr3HT020310 for <secmech@ietf.org>; Thu, 25 Aug 2005 08:53:04 -0700 (PDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7PFr3fa002740 for <secmech@ietf.org>; Thu, 25 Aug 2005 09:53:03 -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 j7PFr1pD015734; Thu, 25 Aug 2005 10:53:01 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7PFr0Kh015733; Thu, 25 Aug 2005 10:53:00 -0500 (CDT)
Date: Thu, 25 Aug 2005 10:53:00 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050825155300.GA15718@binky.Central.Sun.COM>
References: <5057734.1124708889160.JavaMail.servlet@kundenserver> <20050822114112.GA343@isc.upenn.edu> <430DCD75.5040601@piuha.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <430DCD75.5040601@piuha.net>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
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 04:53:57PM +0300, Jari Arkko wrote:
> Shumon Huque wrote:
> >RFC 2712 doesn't provide for initial and service ticket 
> >acquisition. So, at the very least an EAP method that
> >allows you to do that needs to be developed.
> > 
> >
> Do you need a fix to EAP, or do you a fix to kerberos-in-TLS?
> The latter might be applicable in a number of other scenarios,
> too...

Fixing RFC2712 so it actually works with Kerberos V extensions (by not
unnecessarily making up its own Authenticator and AP exchange messages)
is eminently doable.

Fixing RFC2712 to provide IAKERB-like features is another story -- TLS
has a fixed number of round-trips!  (If you'll remember, I mentioned the
possibility for "GSS ciphersuites for TLS" at the BoF and mentioned this
problem as something that would have to be fixed in TLS).

Nico
-- 

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