Re: [IPsec] First version of RFC5996bis

Yaron Sheffer <yaronf.ietf@gmail.com> Fri, 09 August 2013 14:17 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 577EC21F9F7F for <ipsec@ietfa.amsl.com>; Fri, 9 Aug 2013 07:17:02 -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 RAAWwlbgUI1b for <ipsec@ietfa.amsl.com>; Fri, 9 Aug 2013 07:17:00 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 454E411E80D2 for <ipsec@ietf.org>; Fri, 9 Aug 2013 07:17:00 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id a12so3551011wgh.6 for <ipsec@ietf.org>; Fri, 09 Aug 2013 07:16:54 -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=05ndbUlhV+MUVnYYeYAunnwJFW20g3mvT8BTVzZcuDI=; b=H4wtdTErcOaoi8n4aADQsxRJNp1FEDGJnaIDdyyOyjceu4WeNQ939JWaoR1riEvXyJ 9Z9BDMSdvparsP1BWgJepNd44MEtl13iDr65hBErbqgVkQN4hNHwrtrNHXzs1etFvnoT lQeL5zs3ytkwbLfvQuphzQQ2X4S49KKhKlLnSoFygX04KIYEH0rPDnf3Cix4YK3iHZnh jzZ1YtNQO9kOqxNDmrzlb66MwpVNB/GN/Zm++G7vWjCwSzDR/W3R7kRc5WUkCU5sg1px ai4Cls5dVyoGPWcjnbGO4PXF2utHpbcTE4Shegsvyg+I1B4VJc8V9JiYROQBJV5FjHBE q8ZA==
X-Received: by 10.180.13.174 with SMTP id i14mr531782wic.49.1376057814687; Fri, 09 Aug 2013 07:16:54 -0700 (PDT)
Received: from [10.0.0.3] (bzq-79-180-208-107.red.bezeqint.net. [79.180.208.107]) by mx.google.com with ESMTPSA id a8sm3079317wie.6.2013.08.09.07.16.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 07:16:54 -0700 (PDT)
Message-ID: <5204F9B3.8030807@gmail.com>
Date: Fri, 09 Aug 2013 17:16:19 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <20996.61108.326911.119416@fireball.kivinen.iki.fi>
In-Reply-To: <20996.61108.326911.119416@fireball.kivinen.iki.fi>
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 14:17:02 -0000

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