Re: [IPsec] First version of RFC5996bis

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 09 August 2013 20:31 UTC

Return-Path: <yaronf.ietf@gmail.com>
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 DF1F021F9A8C for <ipsec@ietfa.amsl.com>; Fri, 9 Aug 2013 13:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSA6+DrR2DBx for <ipsec@ietfa.amsl.com>; Fri, 9 Aug 2013 13:31:11 -0700 (PDT)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4072C21E805A for <ipsec@ietf.org>; Fri, 9 Aug 2013 13:26:06 -0700 (PDT)
Received: by mail-we0-f179.google.com with SMTP id t57so3953078wes.10 for <ipsec@ietf.org>; Fri, 09 Aug 2013 13:26:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bjU5QIbGD+m2/1E+bTroygnd58k5Zw8jNSYCGtDAphM=; b=q0zK51CQ5Om0Ipjar7/ER8ZNS0xnETvy4jNN5iZGaHLFJRdWzMr8ndEHw1AeFjPypT zKFgnX+XqTQtzPQdJjkGuQvqNBOjziVJkSQJa3bf7/Ux/LJqzBl6qyTLOTIh2wp6nOON u3nrz13yWHxHF/zhNrzuGV4YuHtezUoj180+EnGJVMMJpvX0K/lAmvcWbIHdz2ir1wd6 EUe8mBSh4N8+OAj51ZkuQnudBP9Z65rWvCS9H5We5VOYyJGOMJmn9FhlBnvwQbuPAQRD oJp/QbOp5Mmwke0b6GeNIZJK+OeI7aLE5kgJ6YS1s179zZyIJUjKP545Eg/3V4ust+Bm O64Q==
X-Received: by 10.180.184.107 with SMTP id et11mr1274696wic.60.1376079965301; Fri, 09 Aug 2013 13:26:05 -0700 (PDT)
Received: from [10.0.0.6] (bzq-79-180-208-107.red.bezeqint.net. [79.180.208.107]) by mx.google.com with ESMTPSA id gg10sm4585473wib.1.2013.08.09.13.26.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 13:26:04 -0700 (PDT)
Message-ID: <5205505A.2060607@gmail.com>
Date: Fri, 09 Aug 2013 23:26:02 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <20996.61108.326911.119416@fireball.kivinen.iki.fi> <5204F9B3.8030807@gmail.com>
In-Reply-To: <5204F9B3.8030807@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Pasi Eronen <pe@iki.fi>, Charlie Kaufman <charliek@microsoft.com>, Yoav Nir <ynir@checkpoint.com>, Paul Hoffman <paul.hoffman@vpnc.org>, ipsec@ietf.org, turners@ieca.com
Subject: Re: [IPsec] First version of RFC5996bis
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Aug 2013 20:31:12 -0000

Sorry, I meant RFC 6989 (thanks Graham).

	Yaron

On 2013-08-09 17:16, Yaron Sheffer wrote:
> Hi Tero,
>
> Good stuff! Thanks a lot!
>
> One quick typo: "two Hash and URL format", should be "formats".
>
> Question: RFC 5996 is updated by a single document, which is RFC 5998
> that just got published. The new RFC adds a mandatory, security-critical
> test to IKEv2, and I would like to add to Sec. 1.2 (at the end of the
> paragraph "Both parties in the IKE_AUTH...", this sentence: Both parties
> MUST perform the Diffie-Hellman recipient tests defined in [RFC 5998]
> (and a normative reference). Do you see any issues with that?
>
> Thanks,
>      Yaron
>
> On 9.8.2013 16:29, Tero Kivinen wrote:
>> In the last IETF there has been discussion that we should start
>> driving IPsec protocols from proposed standard to full standard.
>> Mostly this needs to be done because some other standardization
>> organizations say they cannot refer to proposed standards, they can
>> only refer to real standards, and they do not see proposed standards
>> as real standards.
>>
>> Sean Turner promised that he would be willing to do the IESG legwork
>> for this process, but to start that we needed to get the actual
>> documents ready first. The process of going from proposed standard to
>> full standards is easier now, but there are still some things we need
>> to do. The first thing is that we need to take all errata we have for
>> the document and create a document which fixes that.
>>
>> To get this process starting I took the RFC5996, and put in the two
>> errata items we had for that RFC. The submitted the resulting
>> draft-kivinen-ipsecme-ikev2-rfc5996bis today.
>>
>> This version only puts in the errata, and a section "Differences
>> between RFC5996 and This Document".
>>
>> The problem is that we have been discussing in the WG about the
>> draft-kivinen-ipsecme-oob-pubkey draft, and that draft currently
>> obsoletes RAW RSA public keys from the RFC5996 and then adds new one.
>> We cannot really add new features at this point as it is not widely
>> implemented or used, but I think we can safely obsolete the RAW RSA
>> support as it has not been widely used.
>>
>> So my plan is to make new version of this draft in three weeks time (I
>> will be vacation for two weeks starting next Monday), and in that
>> draft obsolete the RAW RSA public keys. After that I will remove all
>> text about obsoleting the RAW RSA public keys from my
>> draft-kivinen-ipsecme-oob-pubkey document and it will just be one
>> normal extension adding stuff to the rfc5996bis.
>>
>> So if you have any objections for that speak up now...
>>
>> In addition to the IKEv2, we most likely want to move some other
>> documents forward too. Some of those are easy like RFC2451 "The ESP
>> CBC-Mode Cipher Algorithms", RFC3526 "More Modular Exponential (MODP)
>> Diffie-Hellman groups for Internet Key Exchange", and RFC3986 "UDP
>> Encapsulation of IPsec ESP Packets", as there is no errata, and they
>> are widely used.
>>
>> Some are harder, as we need to make new versions because of errata
>> (RFC4303 ESP). For some others we need to discuss do we want to make
>> them forward (AH, MOBIKE etc). But I think discussion about the other
>> documents should be done on the separate thread, this is just first
>> step on the road.
>>
>> ----------------------------------------------------------------------
>> From: internet-drafts@ietf.org
>> To: "Paul E. Hoffman" <paul.hoffman@vpnc.org>, Pasi Eronen <pe@iki.fi>,
>>          Charlie Kaufman <charliek@microsoft.com>,
>>          Tero Kivinen <kivinen@iki.fi>, Yoav Nir <ynir@checkpoint.com>,
>>          Paul Hoffman <paul.hoffman@vpnc.org>
>> Subject: New Version Notification for
>>     draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
>> Date: Fri, 09 Aug 2013 05:49:39 -0700
>>
>> A new version of I-D, draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
>> has been successfully submitted by Charlie Kaufman and posted to the
>> IETF repository.
>>
>> Filename:     draft-kivinen-ipsecme-ikev2-rfc5996bis
>> Revision:     00
>> Title:         Internet Key Exchange Protocol Version 2 (IKEv2)
>> Creation date:     2013-08-09
>> Group:         Individual Submission
>> Number of pages: 137
>> URL:
>> http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-ikev2-rfc5996bis-00.txt
>>
>> Status:
>> http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis
>> Htmlized:
>> http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-rfc5996bis-00
>>
>>
>> Abstract:
>>     This document describes version 2 of the Internet Key Exchange (IKE)
>>     protocol.  IKE is a component of IPsec used for performing mutual
>>     authentication and establishing and maintaining Security Associations
>>     (SAs).  This document replaces and updates RFC 4306, and includes all
>>     of the clarifications from RFC 4718.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>