From nico@cryptonector.com Wed Jun 1 06:44:19 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA68DE0844 for ; Wed, 1 Jun 2011 06:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiKGC4xAaxpu for ; Wed, 1 Jun 2011 06:44:19 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7E155E0835 for ; Wed, 1 Jun 2011 06:44:19 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 4C613768059 for ; Wed, 1 Jun 2011 06:44:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=nku5LpFOU3CPxwGMnKATI GnDgSZ0HuXYTL0LLRRVkhbjBXUcXpYmMOGtVY2l/7KMOpdomtzWNkHi7v1uiFmNh 0LXdzm4SWD1QaFxxQes+d+y25//Rt0zd3pHQ+iaA4pBZ9Ay9wEBQU/S7HNmiqee2 /pUp/O4FAo0YYoT3BlPDP8= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=2ODKeqZc7XydIXIrC1ZM LQtXpBM=; b=QwoxI7RwVQaCKRh8acp89AKEnymAr/UDa10c+2npaSwU+8ga9eY/ hGp0AY5AtRUP/BVRgoGT2ZS+C2DAelM3hvdetstFCe54ttWv8yJWiRf4UOH04d6d G7feX41Z2/znzzgPYQl83iFvhPf1UB/b8Num++97L2ssyVBXb/ffm5o= Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id F214E768058 for ; Wed, 1 Jun 2011 06:44:18 -0700 (PDT) Received: by vws12 with SMTP id 12so5682513vws.31 for ; Wed, 01 Jun 2011 06:44:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.65.231 with SMTP id a7mr1146284vdt.61.1306935858127; Wed, 01 Jun 2011 06:44:18 -0700 (PDT) Received: by 10.52.112.163 with HTTP; Wed, 1 Jun 2011 06:44:17 -0700 (PDT) Received: by 10.52.112.163 with HTTP; Wed, 1 Jun 2011 06:44:17 -0700 (PDT) In-Reply-To: References: Date: Wed, 1 Jun 2011 08:44:17 -0500 Message-ID: From: Nico Williams To: Muhammad Nasir Mumtaz Bhutta Content-Type: multipart/alternative; boundary=20cf307f38e491644004a4a6b7f1 Cc: ipsec@ietf.org Subject: Re: [IPsec] IPSec implementation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 13:44:20 -0000 --20cf307f38e491644004a4a6b7f1 Content-Type: text/plain; charset=UTF-8 On Jun 1, 2011 2:23 AM, "Muhammad Nasir Mumtaz Bhutta" < muhammadnasirmumtaz@gmail.com> wrote: > i need to change the IPSec functionality, is there any implementation of IPSec in higher order languages like java, .net (vb, c#, c++) ... it can be on any platform windows or linux ... > > is there any good starting point for linux kernel implementation of IPSec... There are IKE (v2) implementations in C++, such as OpenIKEv2. As for ESP/AH, those are generally always written to run in kernel mode, thus rarely in any sort of HLL. Nico -- --20cf307f38e491644004a4a6b7f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Jun 1, 2011 2:23 AM, "Muhammad Nasir Mumtaz Bhutta" <muhammadnasirmumtaz@gmail.com= > wrote:
> i need to change the IPSec functionality, is there any implementation = of IPSec in higher order languages like java, .net (vb, c#, c++) ... it can= be on any platform windows or linux ...=C2=A0
>
> is there any good starting point for linux kernel implementation of IP= Sec...=C2=A0

There are IKE (v2) implementations in C++, such as OpenIKEv2.=C2=A0 As f= or ESP/AH, those are generally always written to run in kernel mode, thus r= arely in any sort of HLL.

Nico
--

--20cf307f38e491644004a4a6b7f1-- From Paul_Koning@Dell.com Wed Jun 1 08:23:17 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F32E083D for ; Wed, 1 Jun 2011 08:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id InBQhCeUf9k1 for ; Wed, 1 Jun 2011 08:23:16 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id 87510E0865 for ; Wed, 1 Jun 2011 08:22:41 -0700 (PDT) X-Loopcount0: from 10.152.240.141 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Paul Koning In-Reply-To: Date: Wed, 1 Jun 2011 11:22:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3ED4E7C9-93DC-42DF-9E12-1D6E2523E802@dell.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 01 Jun 2011 15:22:39.0804 (UTC) FILETIME=[BE98B7C0:01CC206F] Cc: ipsec@ietf.org, Muhammad Nasir Mumtaz Bhutta Subject: Re: [IPsec] IPSec implementation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 15:23:17 -0000 On Jun 1, 2011, at 9:44 AM, Nico Williams wrote: > On Jun 1, 2011 2:23 AM, "Muhammad Nasir Mumtaz Bhutta" = wrote: > > i need to change the IPSec functionality, is there any = implementation of IPSec in higher order languages like java, .net (vb, = c#, c++) ... it can be on any platform windows or linux ...=20 > > > > is there any good starting point for linux kernel implementation of = IPSec...=20 >=20 > There are IKE (v2) implementations in C++, such as OpenIKEv2. As for = ESP/AH, those are generally always written to run in kernel mode, thus = rarely in any sort of HLL. I did a kernel ESP implementation for an embedded system (a security = gateway router) back around 1999, in C++. But that was a closed source = implementation. paul From pepe_ml@gmx.net Thu Jun 2 04:07:01 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D721AE06BF for ; Thu, 2 Jun 2011 04:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq1qgIv4-5R9 for ; Thu, 2 Jun 2011 04:07:00 -0700 (PDT) Received: from lnx500.hrz.tu-darmstadt.de (lnx500.hrz.tu-darmstadt.de [130.83.156.225]) by ietfa.amsl.com (Postfix) with ESMTP id CD4BBE06F9 for ; Thu, 2 Jun 2011 04:06:59 -0700 (PDT) Received: from freeside.trust.cased.de (swn133.trust.informatik.tu-darmstadt.de [130.83.40.133]) by lnx500.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with SMTP id p52B6t9j022120 for ; Thu, 2 Jun 2011 13:06:56 +0200 (envelope-from pepe_ml@gmx.net) Received: (qmail 21466 invoked by uid 1000); 2 Jun 2011 13:10:50 +0200 Date: Thu, 2 Jun 2011 13:06:51 +0200 From: Steffen Schulz To: ipsec@ietf.org Message-ID: <20110602110651.GA12323@cbg.dyndns.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.2.105421 X-PMX-RELAY: outgoing Subject: Re: [IPsec] IPSec implementation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 11:07:01 -0000 Hi Muhammad, On 110601 at 08:30, Muhammad Nasir Mumtaz Bhutta wrote: > is there any good starting point for linux kernel implementation of > IPSec... I recently implemented an extension to make IPsec VPNs resilient against covert channel exploitation(not only TFC by randomization). We have a paper in submission, but I can send some code snippets to get you started. The Linux source code is the best and almost only documentation I found. Linux implements IPsec in the XFRM subsystem, as a configurable set of transformation protocols(ESP,AH,IP-Tunnel,...) on packets. The IPsec SA is then represented as a set of function pointers to these protocols. There is some documentation on programming(configuring) XFRM from userspace but I found no documentation on the actual design on kernel-side. :-/ However, if you can implement your modification as an IPsec protocol or a modification of the existing ESP/AH, you are kind of lucky. This is not very hard to implement and you can use net/ipv4/esp.c as an example. In struct xfrm_type you can define function pointers for input and output functions, these are called for each ingress and egress packet, respectively. To activate the protocol you have to make it available through the XFRM configuration layer, but this is mostly copy&paste. I advice to use the 'ip' util from iproute2 as a userspace configuration client. The packets are held in struct sk_buff, which is complex but reasonably documented: http://www.skbuff.net/ /steffen From violeta.cakulev@alcatel-lucent.com Wed Jun 1 13:04:44 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB3BE085D; Wed, 1 Jun 2011 13:04:44 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG9Gx6o1OkHx; Wed, 1 Jun 2011 13:04:43 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id EF2A5E085C; Wed, 1 Jun 2011 13:04:42 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p51K4d3J021833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 1 Jun 2011 15:04:40 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p51K4cvD008021 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Jun 2011 15:04:38 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 1 Jun 2011 15:04:38 -0500 From: "Cakulev, Violeta (Violeta)" To: Yaron Sheffer , "ietf@ietf.org" Date: Wed, 1 Jun 2011 15:04:37 -0500 Thread-Topic: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard Thread-Index: AcwYsMo/0HGmfSXETjK9JZiEqS4i5AH5KH8A Message-ID: References: <20110520135022.1622.22713.idtracker@ietfa.amsl.com> <4DD9581C.3070900@gmail.com> In-Reply-To: <4DD9581C.3070900@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 X-Mailman-Approved-At: Thu, 02 Jun 2011 08:19:07 -0700 Cc: IPsecme WG , "draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org" , "dime@ietf.org" Subject: Re: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 20:04:44 -0000 Hi Yaron, Thanks for the comments. Please see inline [VC]. -Violeta -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= aron Sheffer Sent: Sunday, May 22, 2011 2:38 PM To: ietf@ietf.org Cc: IPsecme WG; draft-ietf-dime-ikev2-psk-diameter@tools.ietf.og; dime@ietf= .org Subject: Re: [IPsec] Last Call: = (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to D= iameter Server Interaction) to Proposed Standard Hi, Having read this document only now, I think there's a number of serious iss= ues with it. This document was sent to the ipsec mailing list a while ago b= ut unfortunately got no review. Summary: 1. I think the wrong architectural choice was made, in preferring PSK over = EAP authentication. 2. There is not enough detail in the document to result in interoperable im= plementations. [VC] Please see responses to detailed comments. Detailed comments: * The appropriate ref for IKEv2 is RFC 5996. This was actually noted in the= shepherd review back in March. [VC] This is fixed in v7. * The document notes that EAP is one of the authentication modes supported = by IKEv2. EAP is designed for interaction with backend AAA servers, and is = quite capable of performing shared-secret authentication, using a variety o= f EAP methods (and see also RFC 5998, on IKEv2 mutual auth with EAP). Yet t= he document does not explain why EAP is not used, instead preferring the IK= E PSK authentication method. [VC] Diameter application for Diameter client to server communication for I= KEv2 with EAP has been specified in RFC 5778. However, there is no Diameter= application specified for IKE PSK authentication method. This is stated in= the draft both in Abstract and Introduction. The draft does not recommend = one or the other, it is simply specifying what is not specified. It is up t= o a specific use case to decide what to use. For example 3GPP2 decided to u= se IKEv2 PSK (in 2 of its specifications), and that is what triggered this = effort in IETF. * 4.1: how can the incoming SPI be used to identify the peer? [VC] As stated in Section 4.1 IDi payload is extracted from the IKE_AUTH me= ssage and this payload 'MUST contain an identity that is meaningful for the Diameter infrastructure, such as a Network Access Identifier (NA= I), since it is used by the IKEv2 Server to populate the User-Name AVP in the Diameter message'. SPI is not used to identify the peer. * Packing additional semantics into SPI may conflict with elements of the I= Psec architecture (see for example Sec. 9.3 of draft-ietf-ipsecme-failure-d= etection-08). [VC] Agreed. * 4.1, 2nd paragraph: generation of the PSK is central to this solution, so= it cannot be "outside the scope" of the document. There is no way to inter= operate otherwise. [VC] This draft focuses on IKEv2 server, as a Diameter client, to the Diame= ter server communication for IKEv2 with pre- shared secret based authentication, and specifies Diameter application f= or this communication. It is left to specifications that make use of this D= iameter application to specify where the PSK comes from and how it is gener= ated. As mentioned above, there are two 3GPP2 specs that make use of this D= iameter application and both of those specs specify generation of the PSK. * Moreover, if a single client is expected to sometimes use EAP and sometim= es PSK, there must be a way to notify it which one to use. [VC] This is not the assumption. Again this draft specifies Diameter applic= ation for Diameter client to the Diameter server communication for IKEv2 wi= th PSK. IKEv2 server knows whether EAP or PSK is used. * How does key-lifetime relate to the lifetime of the IKE SA? [VC] This should be the same as in RFC 5996, how pre-shared secret lifetime= relates to the lifetime of the IKE SA. This draft should not make any chan= ges. * Sec. 10 refers to the PSK as a "session key" which is incorrect, as PSK i= s only used for authentication and does not encrypt anything. [VC] Good point. It is changed to PSK in v7. * The same paragraph is very vague about the security properties of PSK. RFC 5996 takes PSK much more seriously, e.g. "When using pre-shared keys, a= critical consideration is how to assure the randomness of these secrets." = Again, I believe the document should specify how the PSK is derived. [VC] I absolutely agree that derivation of PSK is critical. However, as sta= ted above, this draft specifies Diameter application only. Therefore, secur= ity consideration section cannot include much more details on derivation of= PSK as it is specified elsewhere. * Why "if nonces are included" where the document says that they *must* be = included (in the AVP occurrence table). [VC] Good point. This is removed in v7. Thanks, Yaron On 05/20/2011 04:50 PM, The IESG wrote: > The IESG has received a request from the Diameter Maintenance and > Extensions WG (dime) to consider the following document: > - 'Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server > to Diameter Server Interaction' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, comments may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Internet Key Exchange protocol version 2 (IKEv2) is a component > of the IPsec architecture and is 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 [RFC5778] 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 specifies IKEv2 > server, as a Diameter client, to the Diameter server communication > for IKEv2 with pre-shared secret based authentication. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Fri Jun 3 13:32:08 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722B7E07BE; Fri, 3 Jun 2011 13:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0Vy8MeZBvm9; Fri, 3 Jun 2011 13:32:07 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B05A7E07AB; Fri, 3 Jun 2011 13:32:06 -0700 (PDT) Received: by wyb29 with SMTP id 29so1954647wyb.31 for ; Fri, 03 Jun 2011 13:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ys9/a6FOLVsH1YDb4viHsfWjgcRNUhxyv/K7HQA0Gek=; b=TK29CrE+wR2+npw9gG9QvbErnDgLbTgO/8v84HfOSKcG7hGB9BefqpmDljMDWmG2PV BaM9gkeokZPm+LLOoZeIZhC64svVkf4pJErJeBKMjzwyuH1W2FCWdHOglFyfxZRL6H9P NCZGvczViT8Vnd6gSa1Xemlm2jd+l7MEsBxUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pDFWUmDIrIKCLYM5iU0+qasB2IlJ7jjkz5H5kpHVOnOaf+4fHm2m5i+JRA+qZnnyPi FLnZDkVR3lRoOBkYrTTar1Gxp42lUtfC7YYI89kTI4+U4bbUbNpGwbf7Uwa8XzPr5vOH a3TiNIli5D7MhEzoxmRSPb5rHH4rOmhWtwr1M= Received: by 10.227.132.210 with SMTP id c18mr2355829wbt.44.1307133125437; Fri, 03 Jun 2011 13:32:05 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-178-38-173.red.bezeqint.net [79.178.38.173]) by mx.google.com with ESMTPS id et5sm1267260wbb.33.2011.06.03.13.32.02 (version=SSLv3 cipher=OTHER); Fri, 03 Jun 2011 13:32:04 -0700 (PDT) Message-ID: <4DE944C1.5020608@gmail.com> Date: Fri, 03 Jun 2011 23:32:01 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Cakulev, Violeta (Violeta)" References: <20110520135022.1622.22713.idtracker@ietfa.amsl.com> <4DD9581C.3070900@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , "draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org" , "dime@ietf.org" , "ietf@ietf.org" Subject: Re: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2011 20:32:08 -0000 Hi Violeta, thanks for your response. I understand now where you're coming from. But the next person to read the document might not have the authors so readily available :-) Implementors need to understand the motivation for this solution as well as the missing pieces. So I would suggest that you add: - A short paragraph in the Introduction putting this document in perspective and referencing (non-normative references of course) the 3GGP2 documents. - Another paragraph in the Security Considerations that says that generation/derivation of the PSK is security-critical, and provides the 3GPP2 docs again as an example of a solution to this problem. Regarding usage of the SPI, the document says: "Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2 Server uses the information received in IDi *and the SPI* if available, to determine if it has the PSK for this IKEv2 Peer."This sounds to me as if the SPI is used as part of the PSK lookup operation. Maybe the SPI should not be mentioned in the above text. Best regards, Yaron On 06/01/2011 11:04 PM, Cakulev, Violeta (Violeta) wrote: > Hi Yaron, > Thanks for the comments. > Please see inline [VC]. > > -Violeta > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: Sunday, May 22, 2011 2:38 PM > To: ietf@ietf.org > Cc: IPsecme WG; draft-ietf-dime-ikev2-psk-diameter@tools.ietf.og; dime@ietf.org > Subject: Re: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard > > Hi, > > Having read this document only now, I think there's a number of serious issues with it. This document was sent to the ipsec mailing list a while ago but unfortunately got no review. > > Summary: > 1. I think the wrong architectural choice was made, in preferring PSK over EAP authentication. > 2. There is not enough detail in the document to result in interoperable implementations. > [VC] Please see responses to detailed comments. > > Detailed comments: > * The appropriate ref for IKEv2 is RFC 5996. This was actually noted in the shepherd review back in March. > [VC] This is fixed in v7. > > > * The document notes that EAP is one of the authentication modes supported by IKEv2. EAP is designed for interaction with backend AAA servers, and is quite capable of performing shared-secret authentication, using a variety of EAP methods (and see also RFC 5998, on IKEv2 mutual auth with EAP). Yet the document does not explain why EAP is not used, instead preferring the IKE PSK authentication method. > [VC] Diameter application for Diameter client to server communication for IKEv2 with EAP has been specified in RFC 5778. However, there is no Diameter application specified for IKE PSK authentication method. This is stated in the draft both in Abstract and Introduction. The draft does not recommend one or the other, it is simply specifying what is not specified. It is up to a specific use case to decide what to use. For example 3GPP2 decided to use IKEv2 PSK (in 2 of its specifications), and that is what triggered this effort in IETF. > > > * 4.1: how can the incoming SPI be used to identify the peer? > [VC] As stated in Section 4.1 IDi payload is extracted from the IKE_AUTH message and this payload 'MUST contain an identity that is meaningful > for the Diameter infrastructure, such as a Network Access Identifier (NAI), since it is used by the IKEv2 Server to populate the User-Name > AVP in the Diameter message'. SPI is not used to identify the peer. > > > * Packing additional semantics into SPI may conflict with elements of the IPsec architecture (see for example Sec. 9.3 of draft-ietf-ipsecme-failure-detection-08). > [VC] Agreed. > > > * 4.1, 2nd paragraph: generation of the PSK is central to this solution, so it cannot be "outside the scope" of the document. There is no way to interoperate otherwise. > [VC] This draft focuses on IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre- > shared secret based authentication, and specifies Diameter application for this communication. It is left to specifications that make use of this Diameter application to specify where the PSK comes from and how it is generated. As mentioned above, there are two 3GPP2 specs that make use of this Diameter application and both of those specs specify generation of the PSK. > > > * Moreover, if a single client is expected to sometimes use EAP and sometimes PSK, there must be a way to notify it which one to use. > [VC] This is not the assumption. Again this draft specifies Diameter application for Diameter client to the Diameter server communication for IKEv2 with PSK. IKEv2 server knows whether EAP or PSK is used. > > > * How does key-lifetime relate to the lifetime of the IKE SA? > [VC] This should be the same as in RFC 5996, how pre-shared secret lifetime relates to the lifetime of the IKE SA. This draft should not make any changes. > > > * Sec. 10 refers to the PSK as a "session key" which is incorrect, as PSK is only used for authentication and does not encrypt anything. > [VC] Good point. It is changed to PSK in v7. > > > * The same paragraph is very vague about the security properties of PSK. > RFC 5996 takes PSK much more seriously, e.g. "When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets." Again, I believe the document should specify how the PSK is derived. > [VC] I absolutely agree that derivation of PSK is critical. However, as stated above, this draft specifies Diameter application only. Therefore, security consideration section cannot include much more details on derivation of PSK as it is specified elsewhere. > > > * Why "if nonces are included" where the document says that they *must* be included (in the AVP occurrence table). > [VC] Good point. This is removed in v7. > > > Thanks, > Yaron > > On 05/20/2011 04:50 PM, The IESG wrote: >> The IESG has received a request from the Diameter Maintenance and >> Extensions WG (dime) to consider the following document: >> - 'Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server >> to Diameter Server Interaction' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, comments may >> be sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The Internet Key Exchange protocol version 2 (IKEv2) is a component >> of the IPsec architecture and is 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 [RFC5778] 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 specifies IKEv2 >> server, as a Diameter client, to the Diameter server communication >> for IKEv2 with pre-shared secret based authentication. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From labon58@gmail.com Mon Jun 13 03:58:04 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0711E8086 for ; Mon, 13 Jun 2011 03:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWk4fx+pTC0H for ; Mon, 13 Jun 2011 03:58:04 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id DF37E11E8075 for ; Mon, 13 Jun 2011 03:58:03 -0700 (PDT) Received: by pwi5 with SMTP id 5so2264058pwi.31 for ; Mon, 13 Jun 2011 03:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=Hiij/mNUvWQwc8gKVFLBs9o8X3iR3R4CqmASZKsameE=; b=DAuAsdXFUCLAHeHFYVUSx/k1iru9ojLX1jZwgzEKgfAGoh1MJFnXjPiSxaTslLcRf4 mKWp2ePu2nsnJHTuX21Dey5QKZbl/ixNEIFexiKjO7Kyr1WIlKKtRFPKneq+1vtuOwEn VapiT09kRPhamdsGe5CWMLPND7OANKLzhAg/8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; b=efvhK7xGf5mW/zEzkB6/4xb52Sx60ppAFwWF5ngajU3c1+IPz2D+Z/z5+n1ZHpgIGq 5TohEDMRZGBjk3v7nYBZFz9ciQPj/JkthMb3rWIqFvzLoy4Iv4EGvaBBOMK/7yvVoQCR A3xKCxZKDhsNrbtYyeg6ssiS8sOE9SNa0CDuk= Received: by 10.68.68.194 with SMTP id y2mr1932133pbt.329.1307962683408; Mon, 13 Jun 2011 03:58:03 -0700 (PDT) Received: from PC6528 ([211.252.151.26]) by mx.google.com with ESMTPS id b8sm4571648pbj.14.2011.06.13.03.57.59 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 03:58:01 -0700 (PDT) From: "Byoung-Jin Han" To: Date: Mon, 13 Jun 2011 19:57:56 +0900 Message-ID: <003501cc29b8$c27c2960$47747c20$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acwpa91sKDKYC0mcS3ehPJrdPCUzfAATIB4A Content-Language: ko Subject: [IPsec] FW: New Version Notification for draft-seokung-ipsecme-seed-ipsec-modes-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 10:58:04 -0000 Dear all, =20 I submitted a new draft regarding "using SEED CTR, CCM, GCM modes with = IPsec ESP". =20 Any comments would be appreciated. http://tools.ietf.org/id/draft-seokung-ipsecme-seed-ipsec-modes-01.txt =20 Best Regards, Byoungjin Han -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Monday, June 13, 2011 10:52 AM To: bjhan@kisa.or.kr Cc: seokung@kisa.or.kr; hcjung@kisa.or.kr; bjhan@kisa.or.kr; = yjwon@kisa.or.kr Subject: New Version Notification for = draft-seokung-ipsecme-seed-ipsec-modes-01.txt A new version of I-D, draft-seokung-ipsecme-seed-ipsec-modes-01.txt has = been successfully submitted by Byoungjin Han and posted to the IETF = repository. Filename: draft-seokung-ipsecme-seed-ipsec-modes Revision: 01 Title: Using SEED CTR, CCM, GCM modes with IPsec ESP Creation date: 2011-06-10 WG ID: Individual Submission Number of pages: 17 Abstract: This document describes the use of the SEED block cipher algorithm in Counter (CTR) Mode, Counter with CBC-MAC (CCM) Mode and Galois/Counter Mode (GCM) as an IPsec Encapsulation Security Payload (ESP) mechanism to provide confidentiality and data origin authentication, and connectionless integrity. = =20 The IETF Secretariat From violeta.cakulev@alcatel-lucent.com Tue Jun 14 11:41:51 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1F811E80CE; Tue, 14 Jun 2011 11:41:51 -0700 (PDT) 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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMNf8+JOuY3d; Tue, 14 Jun 2011 11:41:50 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9F49D11E8072; Tue, 14 Jun 2011 11:41:50 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5EIfn6n018254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jun 2011 13:41:49 -0500 (CDT) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5EIfmV5019498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 14 Jun 2011 13:41:48 -0500 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.126]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 14 Jun 2011 13:41:48 -0500 From: "Cakulev, Violeta (Violeta)" To: Yaron Sheffer Date: Tue, 14 Jun 2011 13:41:35 -0500 Thread-Topic: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard Thread-Index: AcwiLU6FhyJ9Tdc6S5CFRmbevpIxTwIlHqyQ Message-ID: References: <20110520135022.1622.22713.idtracker@ietfa.amsl.com> <4DD9581C.3070900@gmail.com> <4DE944C1.5020608@gmail.com> In-Reply-To: <4DE944C1.5020608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: IPsecme WG , "draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org" , "dime@ietf.org" , "ietf@ietf.org" Subject: Re: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 18:41:52 -0000 Hi Yaron, Thanks for the suggestions. Please see inline. -Violeta -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Friday, June 03, 2011 4:32 PM To: Cakulev, Violeta (Violeta) Cc: ietf@ietf.org; IPsecme WG; dime@ietf.org; draft-ietf-dime-ikev2-psk-dia= meter@tools.ietf.org Subject: Re: [IPsec] Last Call: = (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to D= iameter Server Interaction) to Proposed Standard Hi Violeta, thanks for your response. I understand now where you're coming from. But the next person to read the = document might not have the authors so readily available :-) Implementors n= eed to understand the motivation for this solution as well as the missing p= ieces. [VC] And the next person indeed had the same concern. Therefore, in v8 we m= ade the changes as proposed below. So I would suggest that you add: - A short paragraph in the Introduction putting this document in perspectiv= e and referencing (non-normative references of course) the 3GGP2 documents. - Another paragraph in the Security Considerations that says that generatio= n/derivation of the PSK is security-critical, and provides the 3GPP2 docs again as an example of a solution to this problem. [VC] Please see v8. We added statements both in Introduction and Security C= onsiderations as proposed above. Regarding usage of the SPI, the document says: "Upon receiving the IKE_AUTH= message from the IKEv2 Peer, the IKEv2 Server uses the information receive= d in IDi *and the SPI* if available, to determine if it has the PSK for thi= s IKEv2 Peer."This sounds to me as if the SPI is used as part of the PSK lo= okup operation. Maybe the SPI should not be mentioned in the above text. [VC] We modified this paragraph in v8. Please see v8. Best regards, Yaron On 06/01/2011 11:04 PM, Cakulev, Violeta (Violeta) wrote: > Hi Yaron, > Thanks for the comments. > Please see inline [VC]. > > -Violeta > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Yaron Sheffer > Sent: Sunday, May 22, 2011 2:38 PM > To: ietf@ietf.org > Cc: IPsecme WG; draft-ietf-dime-ikev2-psk-diameter@tools.ietf.og; > dime@ietf.org > Subject: Re: [IPsec] Last > Call: (Diameter IKEv2 PSK: > Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server > Interaction) to Proposed Standard > > Hi, > > Having read this document only now, I think there's a number of serious i= ssues with it. This document was sent to the ipsec mailing list a while ago= but unfortunately got no review. > > Summary: > 1. I think the wrong architectural choice was made, in preferring PSK ove= r EAP authentication. > 2. There is not enough detail in the document to result in interoperable = implementations. > [VC] Please see responses to detailed comments. > > Detailed comments: > * The appropriate ref for IKEv2 is RFC 5996. This was actually noted in t= he shepherd review back in March. > [VC] This is fixed in v7. > > > * The document notes that EAP is one of the authentication modes supporte= d by IKEv2. EAP is designed for interaction with backend AAA servers, and i= s quite capable of performing shared-secret authentication, using a variety= of EAP methods (and see also RFC 5998, on IKEv2 mutual auth with EAP). Yet= the document does not explain why EAP is not used, instead preferring the = IKE PSK authentication method. > [VC] Diameter application for Diameter client to server communication for= IKEv2 with EAP has been specified in RFC 5778. However, there is no Diamet= er application specified for IKE PSK authentication method. This is stated = in the draft both in Abstract and Introduction. The draft does not recommen= d one or the other, it is simply specifying what is not specified. It is up= to a specific use case to decide what to use. For example 3GPP2 decided to= use IKEv2 PSK (in 2 of its specifications), and that is what triggered thi= s effort in IETF. > > > * 4.1: how can the incoming SPI be used to identify the peer? > [VC] As stated in Section 4.1 IDi payload is extracted from the IKE_AUTH = message and this payload 'MUST contain an identity that is meaningful > for the Diameter infrastructure, such as a Network Access Identifier = (NAI), since it is used by the IKEv2 Server to populate the User-Name > AVP in the Diameter message'. SPI is not used to identify the peer. > > > * Packing additional semantics into SPI may conflict with elements of the= IPsec architecture (see for example Sec. 9.3 of draft-ietf-ipsecme-failure= -detection-08). > [VC] Agreed. > > > * 4.1, 2nd paragraph: generation of the PSK is central to this solution, = so it cannot be "outside the scope" of the document. There is no way to int= eroperate otherwise. > [VC] This draft focuses on IKEv2 server, as a Diameter client, to the Dia= meter server communication for IKEv2 with pre- > shared secret based authentication, and specifies Diameter applicatio= n for this communication. It is left to specifications that make use of thi= s Diameter application to specify where the PSK comes from and how it is ge= nerated. As mentioned above, there are two 3GPP2 specs that make use of thi= s Diameter application and both of those specs specify generation of the PS= K. > > > * Moreover, if a single client is expected to sometimes use EAP and somet= imes PSK, there must be a way to notify it which one to use. > [VC] This is not the assumption. Again this draft specifies Diameter appl= ication for Diameter client to the Diameter server communication for IKEv2 = with PSK. IKEv2 server knows whether EAP or PSK is used. > > > * How does key-lifetime relate to the lifetime of the IKE SA? > [VC] This should be the same as in RFC 5996, how pre-shared secret lifeti= me relates to the lifetime of the IKE SA. This draft should not make any ch= anges. > > > * Sec. 10 refers to the PSK as a "session key" which is incorrect, as PSK= is only used for authentication and does not encrypt anything. > [VC] Good point. It is changed to PSK in v7. > > > * The same paragraph is very vague about the security properties of PSK. > RFC 5996 takes PSK much more seriously, e.g. "When using pre-shared keys,= a critical consideration is how to assure the randomness of these secrets.= " Again, I believe the document should specify how the PSK is derived. > [VC] I absolutely agree that derivation of PSK is critical. However, as s= tated above, this draft specifies Diameter application only. Therefore, sec= urity consideration section cannot include much more details on derivation = of PSK as it is specified elsewhere. > > > * Why "if nonces are included" where the document says that they *must* b= e included (in the AVP occurrence table). > [VC] Good point. This is removed in v7. > > > Thanks, > Yaron > > On 05/20/2011 04:50 PM, The IESG wrote: >> The IESG has received a request from the Diameter Maintenance and >> Extensions WG (dime) to consider the following document: >> - 'Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server >> to Diameter Server Interaction' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to >> the ietf@ietf.org mailing lists by 2011-06-03. Exceptionally, >> comments may be sent to iesg@ietf.org instead. In either case, please >> retain the beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> The Internet Key Exchange protocol version 2 (IKEv2) is a component >> of the IPsec architecture and is used to perform mutual >> authentication as well as to establish and to maintain IPsec securi= ty >> 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 [RFC5778] the Diameter interworking for Mobile IPv6 between th= e >> 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 specifies IKEv2 >> server, as a Diameter client, to the Diameter server communication >> for IKEv2 with pre-shared secret based authentication. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Tue Jun 14 13:18:50 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F751F0C3D; Tue, 14 Jun 2011 13:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3ndS0ORcAYx; Tue, 14 Jun 2011 13:18:49 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id B5C441F0C3C; Tue, 14 Jun 2011 13:18:48 -0700 (PDT) Received: by wyb29 with SMTP id 29so4805610wyb.31 for ; Tue, 14 Jun 2011 13:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=jpL3B0w/WgZrufXFcv9pxf5HJ/32ZhGoIMIe/CCOrbQ=; b=gG93W42Ap92IWp1wI69RAn9otmQkuOWkXP5urfIfmcoOuLnSq6PbPnU6rLQE/0nQvn tlV3ywszIosHVfaU9B/EJLfSHgAmgwOSOzcc67DwicSl9qs0OwnhXOHsY66SQScWHlOm mHsc8PzKzDHlqK/qrB10jPkEcVHBUHkyp401k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=erH1i6xaww9DtEm/OMtWaHHxO5FuNAK+vX15X/vpaUFrvKfP8I0pkMk1KS5Ga5GhNS 3Lr28VZ9YZGtZc/L7Blch+Gou/Ndu1+ScqNm7I59V1wIfjgj1PMvB+2iQjBF9Uf3etOv T6k32fRppULVzDNZSUoYyElBtKVEtbWL3ZVFs= Received: by 10.227.166.129 with SMTP id m1mr6821922wby.65.1308082726759; Tue, 14 Jun 2011 13:18:46 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-183-225-187.red.bezeqint.net [79.183.225.187]) by mx.google.com with ESMTPS id fm14sm5305523wbb.41.2011.06.14.13.18.43 (version=SSLv3 cipher=OTHER); Tue, 14 Jun 2011 13:18:44 -0700 (PDT) Message-ID: <4DF7C222.5030808@gmail.com> Date: Tue, 14 Jun 2011 23:18:42 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Cakulev, Violeta (Violeta)" References: <20110520135022.1622.22713.idtracker@ietfa.amsl.com> <4DD9581C.3070900@gmail.com> <4DE944C1.5020608@gmail.com> In-Reply-To: Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: IPsecme WG , "draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org" , "dime@ietf.org" , "ietf@ietf.org" Subject: Re: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:18:50 -0000 Hi Violeta,

I am fine with the latest version of the document.

Thank you,

    Yaron

On 06/14/2011 09:41 PM, Cakulev, Violeta (Violeta) wrote: 
Hi Yaron,
Thanks for the suggestions.
Please see inline.

-Violeta

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, June 03, 2011 4:32 PM
To: Cakulev, Violeta (Violeta)
Cc: ietf@ietf.org; IPsecme WG; dime@ietf.org; draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org
Subject: Re: [IPsec] Last Call: <draft-ietf-dime-ikev2-psk-diameter-06.txt> (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard

Hi Violeta,

thanks for your response.

I understand now where you're coming from. But the next person to read the document might not have the authors so readily available :-) Implementors need to understand the motivation for this solution as well as the missing pieces.
[VC] And the next person indeed had the same concern. Therefore, in v8 we made the changes as proposed below.


So I would suggest that you add:
- A short paragraph in the Introduction putting this document in perspective and referencing (non-normative references of course) the
3GGP2 documents.
- Another paragraph in the Security Considerations that says that generation/derivation of the PSK is security-critical, and provides the
3GPP2 docs again as an example of a solution to this problem.
[VC] Please see v8. We added statements both in Introduction and Security Considerations as proposed above.

Regarding usage of the SPI, the document says: "Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2 Server uses the information received in IDi *and the SPI* if available, to determine if it has the PSK for this IKEv2 Peer."This sounds to me as if the SPI is used as part of the PSK lookup operation. Maybe the SPI should not be mentioned in the above text.
[VC] We modified this paragraph in v8. Please see v8.

Best regards,

     Yaron

On 06/01/2011 11:04 PM, Cakulev, Violeta (Violeta) wrote:

Hi Yaron,
Thanks for the comments.
Please see inline [VC].

-Violeta

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Yaron Sheffer
Sent: Sunday, May 22, 2011 2:38 PM
To: ietf@ietf.org
Cc: IPsecme WG; draft-ietf-dime-ikev2-psk-diameter@tools.ietf.og;
dime@ietf.org
Subject: Re: [IPsec] Last
Call:<draft-ietf-dime-ikev2-psk-diameter-06.txt>  (Diameter IKEv2 PSK:
Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server
Interaction) to Proposed Standard

Hi,

Having read this document only now, I think there's a number of serious issues with it. This document was sent to the ipsec mailing list a while ago but unfortunately got no review.

Summary:
1. I think the wrong architectural choice was made, in preferring PSK over EAP authentication.
2. There is not enough detail in the document to result in interoperable implementations.
[VC] Please see responses to detailed comments.

Detailed comments:
* The appropriate ref for IKEv2 is RFC 5996. This was actually noted in the shepherd review back in March.
[VC] This is fixed in v7.


* The document notes that EAP is one of the authentication modes supported by IKEv2. EAP is designed for interaction with backend AAA servers, and is quite capable of performing shared-secret authentication, using a variety of EAP methods (and see also RFC 5998, on IKEv2 mutual auth with EAP). Yet the document does not explain why EAP is not used, instead preferring the IKE PSK authentication method.
[VC] Diameter application for Diameter client to server communication for IKEv2 with EAP has been specified in RFC 5778. However, there is no Diameter application specified for IKE PSK authentication method. This is stated in the draft both in Abstract and Introduction. The draft does not recommend one or the other, it is simply specifying what is not specified. It is up to a specific use case to decide what to use. For example 3GPP2 decided to use IKEv2 PSK (in 2 of its specifications), and that is what triggered this effort in IETF.


* 4.1: how can the incoming SPI be used to identify the peer?
[VC] As stated in Section 4.1 IDi payload is extracted from the IKE_AUTH message and this payload 'MUST contain an identity that is meaningful
    for the Diameter infrastructure, such as a Network Access Identifier (NAI), since it is used by the IKEv2 Server to populate the User-Name
    AVP in the Diameter message'. SPI is not used to identify the peer.


* Packing additional semantics into SPI may conflict with elements of the IPsec architecture (see for example Sec. 9.3 of draft-ietf-ipsecme-failure-detection-08).
[VC] Agreed.


* 4.1, 2nd paragraph: generation of the PSK is central to this solution, so it cannot be "outside the scope" of the document. There is no way to interoperate otherwise.
[VC] This draft focuses on IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre-
    shared secret based authentication, and specifies Diameter application for this communication. It is left to specifications that make use of this Diameter application to specify where the PSK comes from and how it is generated. As mentioned above, there are two 3GPP2 specs that make use of this Diameter application and both of those specs specify generation of the PSK.


* Moreover, if a single client is expected to sometimes use EAP and sometimes PSK, there must be a way to notify it which one to use.
[VC] This is not the assumption. Again this draft specifies Diameter application for Diameter client to the Diameter server communication for IKEv2 with PSK. IKEv2 server knows whether EAP or PSK is used.


* How does key-lifetime relate to the lifetime of the IKE SA?
[VC] This should be the same as in RFC 5996, how pre-shared secret lifetime relates to the lifetime of the IKE SA. This draft should not make any changes.


* Sec. 10 refers to the PSK as a "session key" which is incorrect, as PSK is only used for authentication and does not encrypt anything.
[VC] Good point. It is changed to PSK in v7.


* The same paragraph is very vague about the security properties of PSK.
RFC 5996 takes PSK much more seriously, e.g. "When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets." Again, I believe the document should specify how the PSK is derived.
[VC] I absolutely agree that derivation of PSK is critical. However, as stated above, this draft specifies Diameter application only. Therefore, security consideration section cannot include much more details on derivation of PSK as it is specified elsewhere.


* Why "if nonces are included" where the document says that they *must* be included (in the AVP occurrence table).
[VC] Good point. This is removed in v7.


Thanks,
Yaron

On 05/20/2011 04:50 PM, The IESG wrote:

The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server
     to Diameter Server Interaction'
    <draft-ietf-dime-ikev2-psk-diameter-06.txt>   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to
the ietf@ietf.org mailing lists by 2011-06-03. Exceptionally,
comments may be sent to iesg@ietf.org instead. In either case, please
retain the beginning of the Subject line to allow automated sorting.

Abstract


     The Internet Key Exchange protocol version 2 (IKEv2) is a component
     of the IPsec architecture and is 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 [RFC5778] 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 specifies IKEv2
     server, as a Diameter client, to the Diameter server communication
     for IKEv2 with pre-shared secret based authentication.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/


No IPR declarations have been submitted directly on this I-D.


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
From yaronf.ietf@gmail.com Tue Jun 14 13:47:09 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9021F84C4; Tue, 14 Jun 2011 13:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.87 X-Spam-Level: X-Spam-Status: No, score=-102.87 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VVan5xvlTGW; Tue, 14 Jun 2011 13:47:08 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBF021F84C1; Tue, 14 Jun 2011 13:47:07 -0700 (PDT) Received: by wwa36 with SMTP id 36so4223736wwa.13 for ; Tue, 14 Jun 2011 13:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5cCkchvKjej11qUKUxC7mqTDWCUb31Nlh2JM0SAgGRA=; b=rT41ILV9lnTjsNzfN2ha9VehVkmFUnlU22unhLLBO0VMRLSFmS4qOOBaQmdb8p1mR6 GRGqGWAQaFSJNBkAfLqXN2YMVau3jZIZxpaB5Z1OpFpx82g/ZkgFgvPI+sIk5UxZpyl6 WVPkHVh6NFIAolwZl7Vbr1dq92Q9VMzKQhLSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XKu+nU68viLYozunUPQ99dGp4xXpQZUMPNg6uQQJYuj0jH04va9UPfUPGZa7mSm5EB EuaW6UowGQqW7bA7HRvBu5q5uRNVDseqv/xZEh37iOu4DSnBterqbZBEOPWom0CzqloW 2X9Vby00qUumx2JfstwIHSFfSFZrkZtqcjW/0= Received: by 10.227.12.18 with SMTP id v18mr189682wbv.89.1308084424449; Tue, 14 Jun 2011 13:47:04 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-183-225-187.red.bezeqint.net [79.183.225.187]) by mx.google.com with ESMTPS id fm14sm5322493wbb.41.2011.06.14.13.47.01 (version=SSLv3 cipher=OTHER); Tue, 14 Jun 2011 13:47:03 -0700 (PDT) Message-ID: <4DF7C8C3.7020303@gmail.com> Date: Tue, 14 Jun 2011 23:46:59 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Cakulev, Violeta (Violeta)" References: <20110520135022.1622.22713.idtracker@ietfa.amsl.com> <4DD9581C.3070900@gmail.com> <4DE944C1.5020608@gmail.com> <4DF7C222.5030808@gmail.com> In-Reply-To: <4DF7C222.5030808@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , "draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org" , "dime@ietf.org" , "ietf@ietf.org" Subject: Re: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2011 20:47:09 -0000 Resending, apologies if you see it twice. On 06/14/2011 11:18 PM, Yaron Sheffer wrote: > Hi Violeta, > > I am fine with the latest version of the document. > > Thank you, > > Yaron > > On 06/14/2011 09:41 PM, Cakulev, Violeta (Violeta) wrote: >> Hi Yaron, >> Thanks for the suggestions. >> Please see inline. >> >> -Violeta >> >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Friday, June 03, 2011 4:32 PM >> To: Cakulev, Violeta (Violeta) >> Cc:ietf@ietf.org; IPsecme WG;dime@ietf.org;draft-ietf-dime-ikev2-psk-diameter@tools.ietf.org >> Subject: Re: [IPsec] Last Call: (Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server Interaction) to Proposed Standard >> >> Hi Violeta, >> >> thanks for your response. >> >> I understand now where you're coming from. But the next person to read the document might not have the authors so readily available :-) Implementors need to understand the motivation for this solution as well as the missing pieces. >> [VC] And the next person indeed had the same concern. Therefore, in v8 we made the changes as proposed below. >> >> >> So I would suggest that you add: >> - A short paragraph in the Introduction putting this document in perspective and referencing (non-normative references of course) the >> 3GGP2 documents. >> - Another paragraph in the Security Considerations that says that generation/derivation of the PSK is security-critical, and provides the >> 3GPP2 docs again as an example of a solution to this problem. >> [VC] Please see v8. We added statements both in Introduction and Security Considerations as proposed above. >> >> Regarding usage of the SPI, the document says: "Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2 Server uses the information received in IDi *and the SPI* if available, to determine if it has the PSK for this IKEv2 Peer."This sounds to me as if the SPI is used as part of the PSK lookup operation. Maybe the SPI should not be mentioned in the above text. >> [VC] We modified this paragraph in v8. Please see v8. >> >> Best regards, >> >> Yaron >> >> On 06/01/2011 11:04 PM, Cakulev, Violeta (Violeta) wrote: >>> Hi Yaron, >>> Thanks for the comments. >>> Please see inline [VC]. >>> >>> -Violeta >>> >>> -----Original Message----- >>> From:ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>> Of Yaron Sheffer >>> Sent: Sunday, May 22, 2011 2:38 PM >>> To:ietf@ietf.org >>> Cc: IPsecme WG;draft-ietf-dime-ikev2-psk-diameter@tools.ietf.og; >>> dime@ietf.org >>> Subject: Re: [IPsec] Last >>> Call: (Diameter IKEv2 PSK: >>> Pre-Shared Secret-based Support for IKEv2 Server to Diameter Server >>> Interaction) to Proposed Standard >>> >>> Hi, >>> >>> Having read this document only now, I think there's a number of serious issues with it. This document was sent to the ipsec mailing list a while ago but unfortunately got no review. >>> >>> Summary: >>> 1. I think the wrong architectural choice was made, in preferring PSK over EAP authentication. >>> 2. There is not enough detail in the document to result in interoperable implementations. >>> [VC] Please see responses to detailed comments. >>> >>> Detailed comments: >>> * The appropriate ref for IKEv2 is RFC 5996. This was actually noted in the shepherd review back in March. >>> [VC] This is fixed in v7. >>> >>> >>> * The document notes that EAP is one of the authentication modes supported by IKEv2. EAP is designed for interaction with backend AAA servers, and is quite capable of performing shared-secret authentication, using a variety of EAP methods (and see also RFC 5998, on IKEv2 mutual auth with EAP). Yet the document does not explain why EAP is not used, instead preferring the IKE PSK authentication method. >>> [VC] Diameter application for Diameter client to server communication for IKEv2 with EAP has been specified in RFC 5778. However, there is no Diameter application specified for IKE PSK authentication method. This is stated in the draft both in Abstract and Introduction. The draft does not recommend one or the other, it is simply specifying what is not specified. It is up to a specific use case to decide what to use. For example 3GPP2 decided to use IKEv2 PSK (in 2 of its specifications), and that is what triggered this effort in IETF. >>> >>> >>> * 4.1: how can the incoming SPI be used to identify the peer? >>> [VC] As stated in Section 4.1 IDi payload is extracted from the IKE_AUTH message and this payload 'MUST contain an identity that is meaningful >>> for the Diameter infrastructure, such as a Network Access Identifier (NAI), since it is used by the IKEv2 Server to populate the User-Name >>> AVP in the Diameter message'. SPI is not used to identify the peer. >>> >>> >>> * Packing additional semantics into SPI may conflict with elements of the IPsec architecture (see for example Sec. 9.3 of draft-ietf-ipsecme-failure-detection-08). >>> [VC] Agreed. >>> >>> >>> * 4.1, 2nd paragraph: generation of the PSK is central to this solution, so it cannot be "outside the scope" of the document. There is no way to interoperate otherwise. >>> [VC] This draft focuses on IKEv2 server, as a Diameter client, to the Diameter server communication for IKEv2 with pre- >>> shared secret based authentication, and specifies Diameter application for this communication. It is left to specifications that make use of this Diameter application to specify where the PSK comes from and how it is generated. As mentioned above, there are two 3GPP2 specs that make use of this Diameter application and both of those specs specify generation of the PSK. >>> >>> >>> * Moreover, if a single client is expected to sometimes use EAP and sometimes PSK, there must be a way to notify it which one to use. >>> [VC] This is not the assumption. Again this draft specifies Diameter application for Diameter client to the Diameter server communication for IKEv2 with PSK. IKEv2 server knows whether EAP or PSK is used. >>> >>> >>> * How does key-lifetime relate to the lifetime of the IKE SA? >>> [VC] This should be the same as in RFC 5996, how pre-shared secret lifetime relates to the lifetime of the IKE SA. This draft should not make any changes. >>> >>> >>> * Sec. 10 refers to the PSK as a "session key" which is incorrect, as PSK is only used for authentication and does not encrypt anything. >>> [VC] Good point. It is changed to PSK in v7. >>> >>> >>> * The same paragraph is very vague about the security properties of PSK. >>> RFC 5996 takes PSK much more seriously, e.g. "When using pre-shared keys, a critical consideration is how to assure the randomness of these secrets." Again, I believe the document should specify how the PSK is derived. >>> [VC] I absolutely agree that derivation of PSK is critical. However, as stated above, this draft specifies Diameter application only. Therefore, security consideration section cannot include much more details on derivation of PSK as it is specified elsewhere. >>> >>> >>> * Why "if nonces are included" where the document says that they *must* be included (in the AVP occurrence table). >>> [VC] Good point. This is removed in v7. >>> >>> >>> Thanks, >>> Yaron >>> >>> On 05/20/2011 04:50 PM, The IESG wrote: >>>> The IESG has received a request from the Diameter Maintenance and >>>> Extensions WG (dime) to consider the following document: >>>> - 'Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server >>>> to Diameter Server Interaction' >>>> as a Proposed Standard >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to >>>> theietf@ietf.org mailing lists by 2011-06-03. Exceptionally, >>>> comments may be sent toiesg@ietf.org instead. In either case, please >>>> retain the beginning of the Subject line to allow automated sorting. >>>> >>>> Abstract >>>> >>>> >>>> The Internet Key Exchange protocol version 2 (IKEv2) is a component >>>> of the IPsec architecture and is 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 [RFC5778] 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 specifies IKEv2 >>>> server, as a Diameter client, to the Diameter server communication >>>> for IKEv2 with pre-shared secret based authentication. >>>> >>>> >>>> >>>> >>>> The file can be obtained via >>>> http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ >>>> >>>> IESG discussion can be tracked via >>>> http://datatracker.ietf.org/doc/draft-ietf-dime-ikev2-psk-diameter/ >>>> >>>> >>>> No IPR declarations have been submitted directly on this I-D. >>>> >>>> >>>> _______________________________________________ >>>> IETF-Announce mailing list >>>> IETF-Announce@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec From iesg-secretary@ietf.org Wed Jun 15 13:26:33 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF60E21F85E4; Wed, 15 Jun 2011 13:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTZYO9xaLxfO; Wed, 15 Jun 2011 13:26:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4713C21F85E0; Wed, 15 Jun 2011 13:26:32 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce , ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110615202632.12402.3647.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 13:26:32 -0700 Subject: [IPsec] Last Call: (Suite B Profile for Internet Protocol Security (IPsec)) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 20:26:33 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Suite B Profile for Internet Protocol Security (IPsec)' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm policy for national security applications. This document specifies the conventions for using Suite B cryptography in IP Security (IPsec). The file can be obtained via http://datatracker.ietf.org/doc/draft-burgin-ipsec-suiteb-profile/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-burgin-ipsec-suiteb-profile/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1500/ From iesg-secretary@ietf.org Wed Jun 15 13:54:16 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6CB11E8189; Wed, 15 Jun 2011 13:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcqmX07sHZox; Wed, 15 Jun 2011 13:54:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6A411E8159; Wed, 15 Jun 2011 13:54:16 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce , ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110615205416.17033.74326.idtracker@ietfa.amsl.com> Date: Wed, 15 Jun 2011 13:54:16 -0700 Subject: [IPsec] Last Call: (Suite B Cryptographic Suites for IPsec) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 20:54:16 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'Suite B Cryptographic Suites for IPsec' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document proposes four cryptographic user interface suites ("UI suites") for IPsec, similar to the two suites specified in RFC 4308. The four new suites provide compatibility with the United States National Security Agency's Suite B specifications. This document obsoletes RFC 4869, which presented earlier versions of these suites. The file can be obtained via http://datatracker.ietf.org/doc/draft-law-rfc4869bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-law-rfc4869bis/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1499/ From ietf-ipr@ietf.org Tue Jun 21 07:50:11 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C4B11E81F7; Tue, 21 Jun 2011 07:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgk63XDqjGKE; Tue, 21 Jun 2011 07:50:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4E911E8197; Tue, 21 Jun 2011 07:50:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: ynir@checkpoint.com, yaronf.ietf@gmail.com X-Test-IDTracker: no Message-ID: <20110621145010.16284.23824.idtracker@ietfa.amsl.com> Date: Tue, 21 Jun 2011 07:50:10 -0700 Cc: paul.hoffman@vpnc.org, ipsec@ietf.org, turners@ieca.com, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] IPR Disclosure: Microsoft Corporation's Statement about IPR related to draft-ietf-ipsecme-ipsecha-protocol-06 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 14:50:11 -0000 Dear Rajeshwar Jenwar, Kalyani Garigipati, Yoav Nir, Yaron Sheffer, Dacheng= Zhang: An IPR disclosure that pertains to your Internet-Draft entitled "Protocol Support for High Availability of IKEv2/IPsec" (draft-ietf-ipsecme-ipsecha- protocol) was submitted to the IETF Secretariat on 2011-06-20 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1576/). The title of the IPR disclosure is "Microsoft Corporation's Statement about IPR related to draft-ietf-ipsecme- ipsecha-protocol-06.""); The IETF Secretariat From wwwrun@rfc-editor.org Tue Jun 21 18:43:50 2011 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D751221F84F3; Tue, 21 Jun 2011 18:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.838 X-Spam-Level: X-Spam-Status: No, score=-105.838 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cq8TK2gKngwb; Tue, 21 Jun 2011 18:43:50 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [64.170.98.47]) by ietfa.amsl.com (Postfix) with ESMTP id 104EB21F84F9; Tue, 21 Jun 2011 18:43:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D00A998C515; Tue, 21 Jun 2011 18:43:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110622014349.D00A998C515@rfc-editor.org> Date: Tue, 21 Jun 2011 18:43:49 -0700 (PDT) Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 6290 on A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 01:43:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6290 Title: A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) Author: Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi Status: Standards Track Stream: IETF Date: June 2011 Mailbox: ynir@checkpoint.com, wierbows@us.ibm.com, fd@cisco.com, psethi@cisco.com Pages: 22 Characters: 48891 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-failure-detection-08.txt URL: http://www.rfc-editor.org/rfc/rfc6290.txt This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. [STANDARDS-TRACK] This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC