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