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-0000Oc-Ej; Fri, 26 Aug 2005 11:08:07 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E8fhF-0007qM-Qc for; Fri, 26 Aug 2005 11:00:45 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id LAA25157 for <>; Fri, 26 Aug 2005 11:00:43 -0400 (EDT)
Received: from ([] ident=mailnull) by with esmtp (Exim 4.43) id 1E8fhz-00014F-8M for; Fri, 26 Aug 2005 11:01:32 -0400
Received: from ([] by with esmtpa (Exim 4.51) id 1E8fhC-000O7C-Az; Fri, 26 Aug 2005 11:00:42 -0400
Received: by (Postfix, from userid 1000) id A8AE22469D; Fri, 26 Aug 2005 08:00:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E3122469A; Fri, 26 Aug 2005 08:00:41 -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:00:41 -0700 (PDT)
From: Bernard Aboba <>
To: Shumon Huque <>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: 0.1 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
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: <>, <>

> The AAA server could perform the service ticket validation on
> behalf of the NAS. This requires another round trip with the 
> AAA server, but I don't think this is too much of a problem.

How does the EAP peer figure out the scope of usage of the "network access 
service" ticket?  If each NAS is a separate Kerberos principal, then the 
peer needs a distinct ticket for each NAS;  if the AAA server is the 
principal, then it can submit the same ticket to any NAS. 

> If we need the NAS to support Kerberos, then I think the barrier 
> to practical deployment is too high. Or am I missing something?

I think that the NAS needs to be modified even in the case where the AAA 
server is the Kerberos principal, in order to be able to securely inform 
the EAP peer of the ticket scope.  Otherwise, the EAP peer can't know when 
it needs to acquire another ticket. 

SECMECH mailing list