Re: [IPsec] [Technical Errata Reported] RFC6290 (3448)

Yaron Sheffer <yaronf.ietf@gmail.com> Wed, 09 January 2013 12:13 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 D7A8C21F8712 for <ipsec@ietfa.amsl.com>; Wed, 9 Jan 2013 04:13:25 -0800 (PST)
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 qvhWOxBrsqnv for <ipsec@ietfa.amsl.com>; Wed, 9 Jan 2013 04:13:25 -0800 (PST)
Received: from mail-la0-f49.google.com (mail-la0-f49.google.com [209.85.215.49]) by ietfa.amsl.com (Postfix) with ESMTP id D8B9721F86F8 for <ipsec@ietf.org>; Wed, 9 Jan 2013 04:13:24 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id fk20so1725057lab.22 for <ipsec@ietf.org>; Wed, 09 Jan 2013 04:13:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=X/q0Nzqw0nT5OskHCjwfk+UXJcEb42OI8iM1NWKXyU8=; b=prBxv/eZzhGc0ivCJ6wsEu7tRDRdAhlJFk6LlP8BIljjM/NvR1dH1x0qLiiRLFgNF7 +YRh1GpSBo7848cDkvtX0bD0Eje7ejOxG6Be0WJI1japYREkMGhBhqlem8i4s3ByqnZB E9dqA445gcmORFYnXZt3Fjh5eGBnIG/sTlQxQgZ7NxUTCr5xKs8IAe8N1s97ru0JuEfx 0kqtoA6mCtfIROVjmpYYU8jWbYH+aBiKT7b1TwbjaxeijS6Cn16vEoqOKoAUwrjHZbJj LWxIJ8bs/5RpUZBTnI9UanEsflA2QQYzcJgdJoq9L7wKrv3uJH+oIn3DsQ4gwQxk5m2O R78A==
X-Received: by 10.112.87.97 with SMTP id w1mr26314228lbz.91.1357733601772; Wed, 09 Jan 2013 04:13:21 -0800 (PST)
Received: from [10.0.0.13] (85-250-110-45.bb.netvision.net.il. [85.250.110.45]) by mx.google.com with ESMTPS id fh4sm23869503lbb.7.2013.01.09.04.12.58 (version=SSLv3 cipher=OTHER); Wed, 09 Jan 2013 04:13:20 -0800 (PST)
Message-ID: <50ED5EC8.6000602@gmail.com>
Date: Wed, 09 Jan 2013 14:12:56 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: RFC Errata System <rfc-editor@rfc-editor.org>
References: <20130109115304.51DCAB1E002@rfc-editor.org>
In-Reply-To: <20130109115304.51DCAB1E002@rfc-editor.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 09 Jan 2013 04:15:12 -0800
Cc: valery@smyslov.net, ynir@checkpoint.com, paul.hoffman@vpnc.org, ipsec@ietf.org, fd@cisco.com, psethi@cisco.com, turners@ieca.com, wierbows@us.ibm.com, stephen.farrell@cs.tcd.ie
Subject: Re: [IPsec] [Technical Errata Reported] RFC6290 (3448)
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: Wed, 09 Jan 2013 12:13:26 -0000

This is in line with the WG discussion, and I recommend to mark it as 
verified.

Thanks,
	Yaron

On 01/09/2013 01:53 PM, RFC Errata System wrote:
> The following errata report has been submitted for RFC6290,
> "A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6290&eid=3448
>
> --------------------------------------
> Type: Technical
> Reported by: Valery Smyslov <valery@smyslov.net>
>
> Section: 4.3
>
> Original Text
> -------------
>     For session resumption, as specified in [RFC5723], the situation is
>     similar.  The responder, which is necessarily the peer that has
>     crashed, SHOULD send a new ticket within the protected payload of the
>     IKE_SESSION_RESUME exchange.  If the Initiator is also a token maker,
>     it needs to send a QCD_TOKEN in a separate INFORMATIONAL exchange.
>
> Corrected Text
> --------------
>     For session resumption, as specified in [RFC5723], the situation is
>     similar.  The responder, which is necessarily the peer that has
>     crashed, SHOULD send a new QCD_TOKEN in the IKE_AUTH exchange
>     that immediately followes the IKE_SESSION_RESUME exchange.
>     If the Initiator is also a token maker, it needs to send a QCD_TOKEN in
>     the same IKE_AUTH exchange.
>
>
> Notes
> -----
> Original text mixes up terms "ticket" (as Session Resumption ticket from RFC5723) and "token" (as QCD token from this RFC). As QCD token must never be sent in an unprotected message (see section 9.2 from this RFC) it cannot be sent in the IKE_SESSION_RESUME exchange because this exchange is done in clear. So, QCD token must be sent in the IKE_AUTH exchange that immediately followes the IKE_SESSION_RESUME exchange. In this case there is no need for the separate INFORMATIONAL exchange the Initiator's QCD token (if any) to be sent in, because it could be sent in the same IKE_AUTH exchange.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC6290 (draft-ietf-ipsecme-failure-detection-08)
> --------------------------------------
> Title               : A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)
> Publication Date    : June 2011
> Author(s)           : Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi
> Category            : PROPOSED STANDARD
> Source              : IP Security Maintenance and Extensions
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>