Re: [Dime] Quick look at draft-ietf-dime-ikev2-psk-diameter-00.txt
Avi Lior <avi@bridgewatersystems.com> Tue, 09 February 2010 16:19 UTC
Return-Path: <avi@bridgewatersystems.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715CA3A73F5 for <dime@core3.amsl.com>; Tue, 9 Feb 2010 08:19:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rvDy+Xsdn4f for <dime@core3.amsl.com>; Tue, 9 Feb 2010 08:19:56 -0800 (PST)
Received: from mail29.messagelabs.com (mail29.messagelabs.com [216.82.249.147]) by core3.amsl.com (Postfix) with ESMTP id 038723A73E9 for <dime@ietf.org>; Tue, 9 Feb 2010 08:19:55 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: avi@bridgewatersystems.com
X-Msg-Ref: server-8.tower-29.messagelabs.com!1265732461!58267615!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [72.35.6.119]
Received: (qmail 15799 invoked from network); 9 Feb 2010 16:21:02 -0000
Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-8.tower-29.messagelabs.com with RC4-SHA encrypted SMTP; 9 Feb 2010 16:21:02 -0000
Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 9 Feb 2010 11:21:01 -0500
From: Avi Lior <avi@bridgewatersystems.com>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Date: Tue, 09 Feb 2010 11:20:59 -0500
Thread-Topic: [Dime] Quick look at draft-ietf-dime-ikev2-psk-diameter-00.txt
Thread-Index: Acqpo94X6ZiSHzaJQGmMedLGUoo+sQ==
Message-ID: <E1C26A5E-AB6E-43BA-BD8B-29D03248781E@bridgewatersystems.com>
References: <3D3C75174CB95F42AD6BCC56E5555B450210C0BB@FIESEXC015.nsn-intra.net>
In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450210C0BB@FIESEXC015.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_E1C26A5EAB6E43BABD8B29D03248781Ebridgewatersystemscom_"
MIME-Version: 1.0
Cc: Violeta Cakulev <cakulev@alcatel-lucent.com>, "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Quick look at draft-ietf-dime-ikev2-psk-diameter-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Feb 2010 16:19:57 -0000
Hi Hannes, Comment 1 is okay. We will reword etc.. Comment 2 we will look at the draft. Hopefully it will be ready before we are ready. The usual problem. So we will start with resusing the appropriate AVPs then if there are issue we will go to some other plan B. Comment 3 3) Security The security in the document is a bit fuzzy to me. I believe what you are saying is essentially that the pre-shared key isn't really the user's long-term shared key but rather something that has been dynamically established (and thus short lived) based on a previous network access authentication run (or something like that). Is my understanding correct? Avi; Yes In any case, I believe it would be helpful to go through the Housley criteria as a guide for the text that one might want to find in the security consideration sections of such a document. This helps to point out some security threats in a more structured fashion. Does this make sense to you? Avi: I agree. We will do that. On 14-01-2010, at 17:15 , Tschofenig, Hannes (NSN - FI/Espoo) wrote: Hi Avi, I have three comments at this point in time: 1) Editorial There is some room for improvement on the editorial side. An example: FROM: Abstract Internet Key Exchange is a component of IPsec used for performing mutual authentication as well as establishing and maintaining security associations (SAs) between two parties such as a user and a network entity. Internet Key Exchange v2 (IKEv2) protocol allows several different mechanisms for authenticating a user, namely the Extensible Authentication Protocol, certificates, and pre-shared secrets. To authenticate and/or authorize the user, the network element such as the Access Gateway may need to dynamically bootstrap a security association based on interaction with the Diameter server. This document specifies the interaction between the Access Gateway and Diameter server for the IKEv2 based on pre-shared secrets. TO: " Abstract The Internet Key Exchange protocol version 2 (IKEv2) is a component of the IPsec architecture and used to perform mutual authentication as well as to establish and to maintain IPsec security associations (SAs) between the respective parties. IKEv2 supports several different authentication mechanisms, such as the Extensible Authentication Protocol (EAP), certificates, and pre-shared secrets. With TBD-RFC the Diameter interworking for Mobile IPv6 between the Home Agent, as a Diameter client, and the Diameter server has been specified. However, that specification focused on the usage of EAP and did not include support for pre-shared secret based authentication available with IKEv2. This document therefore extends the functionality offered by TBD-RFC with pre-shared key based authentication offered by IKEv2 when no EAP is used. " 2) Reuse of draft-ietf-dime-local-keytran-00.txt Instead of defining your own key related AVP wouldn't it make sense to reuse what has been defined in http://www.ietf.org/id/draft-ietf-dime-local-keytran-00.txt ? 3) Security The security in the document is a bit fuzzy to me. I believe what you are saying is essentially that the pre-shared key isn't really the user's long-term shared key but rather something that has been dynamically established (and thus short lived) based on a previous network access authentication run (or something like that). Is my understanding correct? In any case, I believe it would be helpful to go through the Housley criteria as a guide for the text that one might want to find in the security consideration sections of such a document. This helps to point out some security threats in a more structured fashion. Does this make sense to you? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime
- [Dime] Quick look at draft-ietf-dime-ikev2-psk-di… Tschofenig, Hannes (NSN - FI/Espoo)
- Re: [Dime] Quick look at draft-ietf-dime-ikev2-ps… Avi Lior