Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Nicolas Williams <> Fri, 26 August 2005 04:51 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E8WBI-0006Yh-4Z; Fri, 26 Aug 2005 00:51:08 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E8WBG-0006Yc-4q for; Fri, 26 Aug 2005 00:51:06 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id AAA13197 for <>; Fri, 26 Aug 2005 00:51:01 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1E8WBq-0007d7-8o for; Fri, 26 Aug 2005 00:51:45 -0400
Received: from centralmail1brm.Central.Sun.COM ([]) by (8.12.10/8.12.9) with ESMTP id j7Q4otHT007732 for <>; Thu, 25 Aug 2005 21:50:55 -0700 (PDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7Q4osfc010307 for <>; Thu, 25 Aug 2005 22:50:55 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7Q4osxO017245; Thu, 25 Aug 2005 23:50:54 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7Q4oqeU017244; Thu, 25 Aug 2005 23:50:52 -0500 (CDT)
Date: Thu, 25 Aug 2005 23:50:52 -0500
From: Nicolas Williams <>
To: "Salowey, Joe" <>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050826045052.GI15718@binky.Central.Sun.COM>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc:, Bernard Aboba <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Thu, Aug 25, 2005 at 08:48:57PM -0700, Salowey, Joe wrote:
> > 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. 

I agree.  It isn't even the case that the peer's realm would have to
have a cross-realm Kerberos V path to the NAS's realm; if there was an
x-realm path from the EAP peer to the NAS then the NAS could just be the
EAP server.  And if there be no such x-realm path then the NAS need not
even know a thing about Kerberos V.

Or am I missing some way in which EAP-Kerb/IAKERB/GSS is fundamentally
different from existing EAP methods [in some bad way]?


SECMECH mailing list