Re: [kitten] RFC2743 errata 4251

Greg Hudson <ghudson@mit.edu> Mon, 15 December 2014 18:37 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82F51A8739 for <kitten@ietfa.amsl.com>; Mon, 15 Dec 2014 10:37:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTG3id6E59BB for <kitten@ietfa.amsl.com>; Mon, 15 Dec 2014 10:37:58 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40671A872E for <kitten@ietf.org>; Mon, 15 Dec 2014 10:37:57 -0800 (PST)
X-AuditID: 12074424-f791c6d000000d25-09-548f2a844bf2
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 84.90.03365.48A2F845; Mon, 15 Dec 2014 13:37:56 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id sBFIboaX013633; Mon, 15 Dec 2014 13:37:50 -0500
Received: from [18.101.8.106] (vpn-18-101-8-106.mit.edu [18.101.8.106]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id sBFIbmMI024545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 15 Dec 2014 13:37:49 -0500
Message-ID: <548F2A7B.2040400@mit.edu>
Date: Mon, 15 Dec 2014 13:37:47 -0500
From: Greg Hudson <ghudson@mit.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <alpine.GSO.1.10.1411241330400.19231@multics.mit.edu> <20141124185114.GM3200@localhost> <alpine.GSO.1.10.1412091618550.23489@multics.mit.edu> <20141209215519.GI12979@localhost> <alpine.GSO.1.10.1412091856160.23489@multics.mit.edu> <20141210002441.GP12979@localhost> <alpine.GSO.1.10.1412101349030.23489@multics.mit.edu> <548F185E.70701@mit.edu> <20141215175033.GF3241@localhost> <548F23E5.1020401@mit.edu> <20141215182502.GI3241@localhost>
In-Reply-To: <20141215182502.GI3241@localhost>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrNui1R9isP+nlMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGX03PrJXLCdu+Ln12ssDYwzObsYOTkkBEwk thw5yQphi0lcuLeeDcQWEljMJLH2IUsXIxeQvZFR4sXlJ8wQzhEmiebmZ2AdvAJqEgvW72Hq YuTgYBFQlbhx1wwkzCagLLF+/1YWkLCoQJjE1KU8ENWCEidnPmEBsUUENCWuz1sKtotZwFji Us96sInCQPGdX2+xQqw6zCzxbu9dRpA5nAJ6Evceu0LU60nsuP6LFcKWl2jeOpt5AqPgLCQr ZiEpm4WkbAEj8ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdc73czBK91JTSTYyg4GV3UdnB2HxI 6RCjAAejEg9vBGNfiBBrYllxZe4hRkkOJiVRXgWF/hAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxK IrzSykA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJXitNoEbBotT0 1Iq0zJwShDQTByfIcB6g4VIgNbzFBYm5xZnpEPlTjIpS4rwCIAkBkERGaR5cLyy5vGIUB3pF mHc5SBUPMDHBdb8CGswENPgyYw/I4JJEhJRUA6NUnu7RhXYbdPYLzkq6Hnar2CjHNvLPrfoF 8sVGxz4Lnb9ue2dTYPi+vqyp1qGeGdu+VDvwSM+dsNX5J/eP9818Erc28+18svGG/NHl64Ju ny6ZOmm91erpbamvnd9U2PKH+CeaTnzRtZot9MtBIUtBH8X+R+/Fp1l3yyVvqrh+U2St5fx5 wk1KLMUZiYZazEXFiQAP1Ue9CQMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/r33Qmf2YoVme7TdkIF2oBL_mLmA
Cc: kitten@ietf.org
Subject: Re: [kitten] RFC2743 errata 4251
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Dec 2014 18:38:00 -0000

On 12/15/2014 01:25 PM, Nico Williams wrote:
>> I don't think that is really specified in RFC 2743.  Section 2.2.4 says
>> "one use..." and then "another use..." but doesn't say that's a
>> comprehensive list of context token types.  If the authors had intended
>> for these two uses to be a comprehensive list, I would have expected
>> more specific language than "impact on context-level state information"
>> in the preceding sentence.
> 
> By elimination we know that no other outcomes are possible in the v2u1
> API.

I don't follow this argument, and I think this point is pretty fundamental.

>> It can try to keep going, and terminate the context when it runs into an
>> error or a transport-level or application-level closure.  I think this
>> is the right behavior to encourage given the text in RFC 2743.
> 
> But why bother with async context tokens then?

To communicate better error information to callers?  To support
re-keying or other mechanism-specified context tokens which might
improve security?

> I do see an argument for continuing: that an error token might have no
> integrity protection and the app can't tell, therefore the app should
> continue just in case.

This is not my reasoning; my reasoning is simply that the application
has no strong reason to believe that the context has been terminated,
and that encouraging applications to make this assumption unnecessarily
closes the door to other uses.