Re: [btns] Minor connection-latch problem in AUTH48

Nicolas Williams <Nicolas.Williams@sun.com> Fri, 16 October 2009 21:28 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: btns@core3.amsl.com
Delivered-To: btns@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60EA23A688F for <btns@core3.amsl.com>; Fri, 16 Oct 2009 14:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.524
X-Spam-Level:
X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9p61RkkEZbL for <btns@core3.amsl.com>; Fri, 16 Oct 2009 14:28:10 -0700 (PDT)
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 55ADD3A682B for <btns@ietf.org>; Fri, 16 Oct 2009 14:28:10 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9GLSEOk028203 for <btns@ietf.org>; Fri, 16 Oct 2009 21:28:14 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9GLSDpV011363 for <btns@ietf.org>; Fri, 16 Oct 2009 15:28:13 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9GLGqLD002251; Fri, 16 Oct 2009 16:16:52 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9GLGqMf002250; Fri, 16 Oct 2009 16:16:52 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Fri, 16 Oct 2009 16:16:52 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
Message-ID: <20091016211652.GV892@Sun.COM>
References: <20091015221608.GC907@Sun.COM> <BF345F63074F8040B58C00A186FCA57F1C2A67DF98@NALASEXMB04.na.qualcomm.com> <20091016203953.GQ892@Sun.COM> <BF345F63074F8040B58C00A186FCA57F1C2A67DFC1@NALASEXMB04.na.qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C2A67DFC1@NALASEXMB04.na.qualcomm.com>
User-Agent: Mutt/1.5.7i
Cc: "btns@ietf.org" <btns@ietf.org>
Subject: Re: [btns] Minor connection-latch problem in AUTH48
X-BeenThere: btns@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <btns.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/btns>
List-Post: <mailto:btns@ietf.org>
List-Help: <mailto:btns-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/btns>, <mailto:btns-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Oct 2009 21:28:11 -0000

On Fri, Oct 16, 2009 at 02:13:13PM -0700, Laganier, Julien wrote:
> Nicolas Williams wrote
> > Perhaps the WG would say that we should REQUIRE that the key manager
> > initiate IKE/child SAs ahead of any triggering packet as a
> > simplification of the model (then we don't need a LARVAL state).  But I
> > could certainly see implementors not wanting to do that (for one it
> > makes the CREATE_CONNECTION_LATCH() call slow).
> 
> I think this is the external behavior that we want to capture. The
> specifics of how a given implementation achieves that need not to be
> specified in the RFC as long as the conceptual behavior is clear and
> guarantees interoperability.

Let me re-think the text.  Perhaps I'll simply add a note that an
implementor whose key manager does not immediately initiake IKE/child
SAs on CREATE_CONNECTION_LATCH() must have a larval state that we don't
describe.

Would that work?

> Both style of implementation would conform to that behavior, whether
> or not the triggering occurs directly as a result of latch creation,
> or indirectly via triggering by the first packet.

The external behavior will only show differences in timing.

> > An alternative would be to say "must" instead of "MUST" and then
> > explain that if the key manager does not initiate IKE/child SAs as part of the
> > CREATE_CONNECTION_LATCH() call, then it must have a LARVAL state that
> > we have not defined.
> 
> FWIW - from my perspective there's no difference between "must" and
> "MUST", RFC 2119 says about key word that "These words are often
> capitalized", but does not make it a must.

When those terms are used in capitals I think the intent is clear; when
they are not the intent may be clear from the fact that the same
document also uses those terms in capitalized form.

> > Indeed.  We don't absolutely need the LARVAL state.  Perhaps we should
> > describe it as an OPTIONAL state, since an implementation might not
> > have such a state at all.
> 
> I tend to think that we do not need the state at all. It is a valid
> implementation strategy, but it does not need to be captured in the
> standard since there are as-valid alternatives (e.g., Latch Manager
> triggers key Management directly)_

OK.  I'll propose new text later today.