RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

"Salowey, Joe" <jsalowey@cisco.com> Fri, 26 August 2005 15:35 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gEu-00010z-Jw; Fri, 26 Aug 2005 11:35:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gEr-0000zC-Ny for secmech@megatron.ietf.org; Fri, 26 Aug 2005 11:35:31 -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 LAA27328 for <secmech@ietf.org>; Fri, 26 Aug 2005 11:35:27 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gFb-0002Oj-GE for secmech@ietf.org; Fri, 26 Aug 2005 11:36:16 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 26 Aug 2005 08:35:20 -0700
X-IronPort-AV: i="3.96,144,1122879600"; d="scan'208"; a="336080344:sNHT32015388"
Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7QFZHQM009431; Fri, 26 Aug 2005 08:35:17 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Date: Fri, 26 Aug 2005 08:40:10 -0700
Message-ID: <7210B31550AC934A8637D6619739CE6905C8BF3D@e2k-sea-xch2.sea-alpha.cisco.com>
Thread-Topic: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Thread-Index: AcWqT6gsgxmbX/YDQEiO1EZfHBo1KAAADmGQ
From: "Salowey, Joe" <jsalowey@cisco.com>
To: "Bernard Aboba" <aboba@internaut.com>, "Shumon Huque" <shuque@isc.upenn.edu>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Content-Transfer-Encoding: quoted-printable
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

 

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Friday, August 26, 2005 8:01 AM
> To: Shumon Huque
> Cc: Salowey, Joe; secmech@ietf.org
> Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
> 
> > 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. 
> 

[Joe] I don't think there is necessarily a problem service ticket for
the AAA.  This is how EAP typically works today. 

> > 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. 

[Joe] How would the NAS know anything about the ticket scope?  If you
are concerned about scope why would you trust the NAS to tell you?  It
would seem that this information needs to encoded in the ticket. Perhaps
scope can be derived from the service principal name. 


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