Return-Path: 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 ; 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 ; 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 ; 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 To: "Tschofenig, Hannes (NSN - FI/Espoo)" Date: Tue, 9 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: 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 , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2010 16:19:57 -0000 --_000_E1C26A5EAB6E43BABD8B29D03248781Ebridgewatersystemscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 appropria= te 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 s= aying is essentially that the pre-shared key isn't really the user's long-t= erm 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 criter= ia as a guide for the text that one might want to find in the security cons= ideration sections of such a document. This helps to point out some securit= y 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) betwee= n 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 reus= e what has been defined in http://www.ietf.org/id/draft-ietf-dime-local-key= tran-00.txt ? 3) Security The security in the document is a bit fuzzy to me. I believe what you are s= aying is essentially that the pre-shared key isn't really the user's long-t= erm 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 criter= ia as a guide for the text that one might want to find in the security cons= ideration sections of such a document. This helps to point out some securit= y threats in a more structured fashion. Does this make sense to you? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E1C26A5EAB6E43BABD8B29D03248781Ebridgewatersystemscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Hannes,

<= div>Comment 1 is okay.  We will reword etc..

= Comment 2 we will look at the draft.  Hopefully it will be ready befor= e 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.<= /div>

Comment 3

3) Security

The security in the document is a bit fuzz= y to me. I believe what you are saying is essentially that the pre-shared k= ey isn't really the user's long-term shared key but rather something that h= as been dynamically established (and thus short lived) based on a previous = network access authentication run (or something like that). Is my understan= ding correct?

Avi;  Yes

In any case, I believe it would be helpful to go through the Hou= sley criteria as a guide for the text that one might want to find in the se= curity consideration sections of such a document. This helps to point out s= ome security threats in a more structured fashion. Does this make sense to = you?

Avi:  I agree.  We will do that.
<= /blockquote>

On 14-01-2010, at 17:15 , Tschofen= ig, Hannes (NSN - FI/Espoo) wrote:

H= i Avi,

I have three comments at this point = in time:

1) Editorial

There is some room for improvement o= n the editorial side. An example:

FROM:

Abstract

   Internet Key Exchange is a component of IPsec used for perform= ing
   mutual authentication as well as establishing and maintaining<= br>    security associations (SAs) between two parties such as a user= and a
   network entity.  Internet Key Exchange v2 (IKEv2) protoco= l allows
   several different mechanisms for authenticating a user, namely= the
   Extensible Authentication Protocol, certificates, and pre-shar= ed
   secrets.  To authenticate and/or authorize the user, the = network
   element such as the Access Gateway may need to dynamically boo= tstrap
   a security association based on interaction with the Diameter = server.
   This document specifies the interaction between the Access Gat= eway
   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 parti= es. IKEv2 supports several different authenti= cation
   mechanisms, such as the Extensible = Authentication Protocol (EAP)<= /font>,
   certificates, and pre-shared secret= s.

   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 specif= ication focused on the usage of EAP and did not
   include support for = pre-shared secret based authentication available
   with IKEv2. This doc= ument 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-ke= ytran-00.txt

Instead of defining your own key rel= ated AVP wouldn't it make sense to reuse what has been defined in http://www.ietf.org/id/draf= t-ietf-dime-local-keytran-00.txt ?

3) Security

The security in the document is a bi= t fuzzy to me. I believe what you are saying is essentially that the pre-sh= ared 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 pre= vious network access authentication run (or something like that). Is my und= erstanding correct?

In any cas= e, I believe it would be helpful to go through the Housley criteria as a gu= ide 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
https://www.ietf.org/mai= lman/listinfo/dime

= --_000_E1C26A5EAB6E43BABD8B29D03248781Ebridgewatersystemscom_--