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

RFC Errata System <rfc-editor@rfc-editor.org> Wed, 09 January 2013 12:03 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 3A3EC21F86F6 for <ipsec@ietfa.amsl.com>; Wed, 9 Jan 2013 04:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.409
X-Spam-Level:
X-Spam-Status: No, score=-102.409 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 UoOwMTvY7NNf for <ipsec@ietfa.amsl.com>; Wed, 9 Jan 2013 04:03:26 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BF85621F86E8 for <ipsec@ietf.org>; Wed, 9 Jan 2013 04:03:26 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id 51DCAB1E002; Wed, 9 Jan 2013 03:53:04 -0800 (PST)
To: ynir@checkpoint.com, wierbows@us.ibm.com, fd@cisco.com, psethi@cisco.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20130109115304.51DCAB1E002@rfc-editor.org>
Date: Wed, 09 Jan 2013 03:53:04 -0800
X-Mailman-Approved-At: Wed, 09 Jan 2013 04:15:12 -0800
Cc: ipsec@ietf.org, valery@smyslov.net, rfc-editor@rfc-editor.org
Subject: [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:03:27 -0000

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