RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Bernard Aboba <> Fri, 26 August 2005 15:08 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E8foN-0000P1-Mk; Fri, 26 Aug 2005 11:08:07 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E8fmd-0000C8-GH for; Fri, 26 Aug 2005 11:06:19 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id LAA25379 for <>; Fri, 26 Aug 2005 11:06:17 -0400 (EDT)
Received: from ([] ident=mailnull) by with esmtp (Exim 4.43) id 1E8fnN-0001Eh-1j for; Fri, 26 Aug 2005 11:07:06 -0400
Received: from ([] by with esmtpa (Exim 4.51) id 1E8fmZ-000OoW-Ao; Fri, 26 Aug 2005 11:06:15 -0400
Received: by (Postfix, from userid 1000) id 7B1842469D; Fri, 26 Aug 2005 08:06:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CC552469A; Fri, 26 Aug 2005 08:06:14 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: aboba
Date: Fri, 26 Aug 2005 08:06:14 -0700 (PDT)
From: Bernard Aboba <>
To: Josh Howlett <>
Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <191B6A09CAEEC043419A68E5@cumulus>
Message-ID: <>
References: <7210B31550AC934A8637D6619739CE6905C8BEEC@e2k-sea-xch2.sea-alpha.> <> <191B6A09CAEEC043419A68E5@cumulus>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
X-Mailman-Approved-At: Fri, 26 Aug 2005 11:08:06 -0400
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

> Just to clarify - it would be possible for the AAA server to authenticate
> against the KDC and return an EAP-Success to the NAS as per other EAP types,
> without the NAS needing to understand Kerberos. However, the NAS would need to
> understand Kerberos in order to allow a service ticket to be used for, ie,
> fast reconnect (...which is undesirable for secret hygene).
> Right?

Yes, if the NAS needs to act as a Kerberos principal, it needs to support 
Kerberos.  Note that "fast handoff" typically refers to situations in 
which the AAA server does not need to be contacted during a handoff.  If 
the EAP peer needs to obtain a new ticket for each NAS, and each ticket 
request requires a round-trip to the KDC, that is not "fast handoff" as 
the term is normally used.  If in addition the NAS needs a round-trip to 
the AAA server in order to validate each ticket (e.g. the case where the 
AAA server is the service principal) then an EAP-Kerberos scheme will 
perform more poorly than existing EAP methods.  

SECMECH mailing list