Re: [IPsec] Error in RFC6290

"Valery Smyslov" <svanru@gmail.com> Wed, 26 December 2012 17:58 UTC

Return-Path: <svanru@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 0693621F8CB0 for <ipsec@ietfa.amsl.com>; Wed, 26 Dec 2012 09:58:51 -0800 (PST)
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 Zzr+v0bUyMIG for <ipsec@ietfa.amsl.com>; Wed, 26 Dec 2012 09:58:50 -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 A3FDB21F8C6C for <ipsec@ietf.org>; Wed, 26 Dec 2012 09:58:49 -0800 (PST)
Received: by mail-la0-f49.google.com with SMTP id r15so10823902lag.22 for <ipsec@ietf.org>; Wed, 26 Dec 2012 09:58:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; bh=9kudY7aGC0FljxEqsbqPihLHnBxmAND0wuw3u26VZbA=; b=BugvHUV6wnXuhCSaYzIaJ/EEu+XdfpXWeCmVHU2xZXoPJzF2eyNG+6XTwpGlUck7BX OeTE/NP15OnNZTe6vlwM9HUm/UN7yrnifyDvB5Ww3kEvyPxQ/wqaqhs6eXg7/5TtQS1+ XDjxuYm3t+SBBZUVrkfYM4Wv4FqSV69kT2au5VgU8ZNVnDupCMeISDYnj24T6etClR2a 6iDI1r8h3spd/5mThUM7EV8lpYohGMtqOi0U/HSIPu6iMVrHTxVNRetE+Kw0mw2wlTRa 4wYH4AIW55dvHzK1e4/t7ZZIt/s8Z4eaOailOMVznoDbHLm58kcTKF5V0fjFOHJ7mVZn nPxw==
X-Received: by 10.152.47.75 with SMTP id b11mr25677845lan.14.1356544728109; Wed, 26 Dec 2012 09:58:48 -0800 (PST)
Received: from chichi (ppp91-77-170-54.pppoe.mtu-net.ru. [91.77.170.54]) by mx.google.com with ESMTPS id hc20sm10321300lab.11.2012.12.26.09.58.46 (version=SSLv3 cipher=OTHER); Wed, 26 Dec 2012 09:58:47 -0800 (PST)
Message-ID: <472FFB92C2804A6B8EDFD96421D52B42@chichi>
From: Valery Smyslov <svanru@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>, Yoav Nir <ynir@checkpoint.com>
References: <20121203223404.5441.71025.idtracker@ietfa.amsl.com> <E7FA5DBC7DB747779E6E6D73460A6615@buildpc> <4613980CFC78314ABFD7F85CC30277210EDFD9D0@IL-EX10.ad.checkpoint.com> <B1F8AE12E3604526980FA756C8F2DB09@buildpc> <DF562289B5D540F095DA9CD3B21AB3D0@buildpc> <4613980CFC78314ABFD7F85CC30277210EE0910F@IL-EX10.ad.checkpoint.com> <50DB30CF.7010604@gmail.com>
Date: Wed, 26 Dec 2012 21:58:41 +0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Error in RFC6290
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, 26 Dec 2012 17:58:51 -0000

Hi Yaron,

oh, you've catched one more error in this text - it mixed up terms "ticket"
(used in RFC5723 as Session Resumption ticket) and "token"
(used in RFC6290 as QCD token). I din't notice that. You are right,
that "ticket" (Session Resumption) is sent in IKE_SESSION_RESUME,
but RFC6290 talks where QCD token must be sent. And from my understanding
of the whole protocol it must not be sent in clear under any circumstances
(otherwise eavesdropper can easily tear down IKE SA), so the only logical
place for it in case of IKE SA resumption is IKE_AUTH exchange
that immediately follows IKE_SESSION_RESUME. So, I think,
correct text should be:

     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 IKE_AUTH exchange
     that immediately followes 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.

Best wishes,
Valery.


> Hi Yoav, Valery,
>
> Valery is right that the IKE_SESSION_RESUME exchange does not have a protected payload.
>
> But his new text is incorrect, since the (session resumption) ticket is sent in IKE_SESSION_RESUME 
> and not in the immediately following IKE_AUTH (he might have got it mixed with the ticket sent 
> when *requesting* a ticket). So I guess we should just replace "within the protected payload of 
> the IKE_SESSION_RESUME exchange" by "within the  IKE_SESSION_RESUME exchange".
>
> According to http://en.wikipedia.org/wiki/Christmas#Listing, it's still more than a week until the 
> Eastern Churches' Christmas. So Merry Christmas to some of us, and a Happy New Year to all.
>
> Thanks,
> Yaron
>
>
> On 12/26/2012 10:42 AM, Yoav Nir wrote:
>> Hi
>>
>> I agree with point #2. I'll leave it to some of the session resumption experts to comment on 
>> point #1.
>>
>> It's a little late for "Merry Christmas", so just happy new year.
>>
>> Yoav
>>
>> -----Original Message-----
>> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov
>> Sent: Wednesday, December 26, 2012 8:11 AM
>> To: ipsec@ietf.org
>> Subject: [IPsec] Error in RFC6290
>>
>> Hi,
>>
>> RFC6290 (Quick Crash Detection) contains an error. In Section 4.3 it states:
>>
>>     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.
>>
>> But IKE_SESSION_RESUME exchange, as specified in RFC5723, doesn't contain any protected payload - 
>> it is completely in clear and must be followed by IKE_AUTH exchange. I suspect this error came 
>> from early versions of IKE SA Resumption protocol that, as far as I remember, did contain 
>> protected payload. But currently this para should look like:
>>
>>     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 in IKE_AUTH exchange
>>     that immediately followed 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.
>>
>>
>>
>> And one more consideration. In Section 4.1 RFC6290 states:
>>
>>     o  Protocol ID (1 octet) MUST be 1, as this message is related to an
>>        IKE SA.
>>
>>     o  SPI Size (1 octet) MUST be zero, in conformance with Section 3.10
>>        of [RFC5996].
>>
>> I think here we have contradiction with RFC5996 (despite clamed conformance with it). In 
>> abovementioned Section 3.10 it is written:
>>
>>     o  Protocol ID (1 octet) - If this notification concerns an existing
>>        SA whose SPI is given in the SPI field, this field indicates the
>>        type of that SA.  For notifications concerning Child SAs, this
>>        field MUST contain either (2) to indicate AH or (3) to indicate
>>        ESP.  Of the notifications defined in this document, the SPI is
>>        included only with INVALID_SELECTORS and REKEY_SA.  If the SPI
>>        field is empty, this field MUST be sent as zero and MUST be
>>        ignored on receipt.
>>
>> Let me emphasize that RFC5996 clearly requires that If the SPI field is empty, Protocol ID field 
>> MUST be sent as zero and MUST be ignored on receipt, but RFC6290 while requiring SPI field to be 
>> empty, requres Protocol ID field to be non-zero. Actually, I see no value in this requirement, as 
>> Protocol ID MUST be ignored on receipt anyway (if SPI field is empty), so it just complicates 
>> protocol and makes it cumbersome.
>>
>> Merry Christmas,
>> Valery Smyslov.
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>> Email secured by Check Point
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>