Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Jari Arkko <jari.arkko@piuha.net> Thu, 25 August 2005 13:53 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAW-00084i-MO; Thu, 25 Aug 2005 09:53:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8IAV-00084V-CN for secmech@megatron.ietf.org; Thu, 25 Aug 2005 09:53:23 -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 JAA18328 for <secmech@ietf.org>; Thu, 25 Aug 2005 09:53:21 -0400 (EDT)
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8IB2-0003uz-H1 for secmech@ietf.org; Thu, 25 Aug 2005 09:53:56 -0400
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2732D89864; Thu, 25 Aug 2005 16:53:13 +0300 (EEST)
Message-ID: <430DCD55.5090908@piuha.net>
Date: Thu, 25 Aug 2005 16:53:25 +0300
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@sun.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
References: <7210B31550AC934A8637D6619739CE6905C06505@e2k-sea-xch2.sea-alpha.cisco.com> <20050819181222.GG6659@binky.Central.Sun.COM> <20050819181423.GA6658@binky.Central.Sun.COM>
In-Reply-To: <20050819181423.GA6658@binky.Central.Sun.COM>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Content-Transfer-Encoding: 7bit
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

>I forgot to mention the counter-argument, namely that, in the short-term
>at least, a round-trip is a small price to pay for lowering the cost, in
>time and effort, of making EAP's or SASL/GSS-API's mechanisms available
>to the other.
>  
>
Roundtrips are important, but I don't think anyone expects
everything to happen in the minimum number of round
trips, in ALL cases. That is, I think we need e.g. shared secret
mechanisms with a small number of roundtrips in EAP, and
we need some mechanisms that have a small number of
roundtrips. But we already have today TLS-based EAP
tunneling schemes, some of which are quite chatty.
So I think it would be fine to have some additional
roundtrips when you using something from another
framework.

(Nevertheless, I'm in favor of the bindings approach.)

--Jari


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