RE: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt

Bernard Aboba <bernarda@windows.microsoft.com> Mon, 09 April 2007 13:14 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Haths-0000sW-JP; Mon, 09 Apr 2007 09:14:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZTub-0005fQ-Hp for ietf@ietf.org; Thu, 05 Apr 2007 11:30:09 -0400
Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZTuU-0007Dr-1C for ietf@ietf.org; Thu, 05 Apr 2007 11:30:09 -0400
Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Thu, 5 Apr 2007 08:30:01 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.25; Thu, 5 Apr 2007 08:30:01 -0700
Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Apr 2007 08:30:00 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 05 Apr 2007 08:29:22 -0700
Message-ID: <0C7B902B470A264FA64D66CBF76FB8210358C4E4@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
thread-index: Acd3IBm1iLanayR3Q8yjB3uWpe8WoQAcK20q
References: <41825.12.108.168.179.1171660575.squirrel@www.trepanning.net><tslwt2hiybm.fsf@cz.mit.edu><C24CB51D5AA800449982D9BCB90325134F192B@NAEX13.na.qualcomm.com><tslfy947pol.fsf@cz.mit.edu> <45D73CEB.2000701@qualcomm.com><C24CB51D5AA800449982D9BCB90325134F192D@NAEX13.na.qualcomm.com><0C7B902B470A264FA64D66CBF76FB821014CD3F6@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com><C24CB51D5AA800449982D9BCB90325134F1947@NAEX13.na.qualcomm.com><tsld52qipph.fsf_-_@cz.mit.edu><52310.69.12.173.8.1175549276.squirrel@www.trepanning.net><tsl7ist2dif.fsf@cz.mit.edu><14965.12.108.168.179.1175731583.squirrel@www.trepanning.net> <tsltzvvei2w.fsf@cz.mit.edu>
From: Bernard Aboba <bernarda@windows.microsoft.com>
To: Sam Hartman <hartmans-ietf@mit.edu>, Dan Harkins <dharkins@lounge.org>
X-OriginalArrivalTime: 05 Apr 2007 15:30:00.0870 (UTC) FILETIME=[466D8C60:01C77797]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5
X-Mailman-Approved-At: Mon, 09 Apr 2007 09:14:48 -0400
Cc: ietf@ietf.org
Subject: RE: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1264510399=="
Errors-To: ietf-bounces@ietf.org

O, I definitely think they are session keys.
 
[BA]  They are not TSKs according to the definition in the EAP Key Management Framework. 

Wait, what's wrong with giving 100 authenticators 100 different keys
provided that each authenticator is authorized to claim the identity
it plans to claim?  Isn't that exactly the sort of thing we do want to do?
 
[BA] The creation of cryptographically separate keys for each authenticator is not sufficient;  the EAP Key Management Framework describes the problems that can result without authentication and authorization.  
 
As an example,  Proactive Key Distribution as proposed in http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-04.txt distributes keys in advance of peer arrival at an authenticator.  The problem is that evidence is not provided to the AAA server that the peer actually arrived at an authenticator to whom a proactive key was provided. 
 
Since accounting records can now be created without a corresponding AAA conversation, new classes of attacks become possible.  For example, a rogue authenticator can claim that the authenticator has connected to itself or another authenticator in the neighbor graph by issuing bogus accounting records.  Since Bogus accounting records can be created without fear of detection, financial fraud becomes possible.  
 
Corruption of the neighbor graph is also possible unless the AAA server only creates neighbor graph entries in response to successful authentications between the peer and AAA server.  Without this, a rogue authenticator could corrupt the neighbor graph by submitting bogus accounting records, causing proactive keys to be distributed outside their authorized scope (e.g. only to legitimate 'neighbors'). 
 
Note that proactive key distribution actually provides more security safeguards than some other 'fast handoff' proposals because the creation of a neighbor graph based on successful authentications limits the scope of potential mischief.  For example, an authenticator in Hawaii cannot claim to be a neighbor of one in New York without providing evidence that a peer had actually authenticated via both. 
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf