IETF Logo Mail Archive

Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Shumon Huque <shuque@isc.upenn.edu> Mon, 22 August 2005 15:06 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DsH-0002Oh-QO; Mon, 22 Aug 2005 11:06:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DsG-0002Oc-6w for secmech@megatron.ietf.org; Mon, 22 Aug 2005 11:06:08 -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 LAA21487 for <secmech@ietf.org>; Mon, 22 Aug 2005 11:06:05 -0400 (EDT)
Received: from talkeetna.isc-net.upenn.edu ([128.91.197.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ESo-0003jq-JD for secmech@ietf.org; Mon, 22 Aug 2005 11:43:56 -0400
Received: by talkeetna.isc-net.upenn.edu (Postfix, from userid 4127) id 930E4443F; Mon, 22 Aug 2005 11:06:04 -0400 (EDT)
Date: Mon, 22 Aug 2005 11:06:04 -0400
From: Shumon Huque <shuque@isc.upenn.edu>
To: Charles Clancy <clancy@cs.umd.edu>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050822150604.GA1725@isc.upenn.edu>
References: <Pine.GSO.4.60.0508191330380.16954@ismene> <20050819210308.GI6659@binky.Central.Sun.COM> <20050820031035.GA5352@isc.upenn.edu> <43074F76.8000604@cs.umd.edu> <20050822044255.GC27685@isc.upenn.edu> <Pine.GSO.4.60.0508220801430.1114@ismene> <35850EE42DFD2824F0DDBBC8@cumulus> <Pine.GSO.4.60.0508221008260.1174@ismene> <1DCACCAC04655B3AFE9733A8@cumulus> <Pine.GSO.4.60.0508221047001.1307@ismene>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.GSO.4.60.0508221047001.1307@ismene>
User-Agent: Mutt/1.4.2.1i
Organization: University of Pennsylvania
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Cc: secmech@ietf.org, Nicolas Williams <Nicolas.Williams@sun.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 Mon, Aug 22, 2005 at 10:48:45AM -0400, Charles Clancy wrote:
> On Mon, 22 Aug 2005, Josh Howlett wrote:
> 
> >Out of curiousity, what are the advantages of using native Kerberos, 
> >rather than PAP inside a tunneled method which the AAA server verifies 
> >against the KDC? (this is how FreeRADIUS currently implements "Kerberos" 
> >authentication).
> >
> >Perhaps I'm being a bit dim, but I feel like I'm missing the point.
> >
> >Or is the point simply to define a mechanism that EAP and GSS can share?
> 
> I'm not very familiar with this mechanism, but it doesn't like like you 
> could get a TGT as a result of your authentication.

That's right. TTLS+PAP used in this way is performing Kerberos
password verification via the AAA server. It isn't native
Kerberos authentication. I know that it's commonly done, but
many consider it to be a misuse of Kerberos.


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

v2.23.0 | Report a Bug | By Email