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

Nicolas Williams <> Fri, 16 October 2009 21:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60EA23A688F for <>; Fri, 16 Oct 2009 14:28:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.524
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M9p61RkkEZbL for <>; Fri, 16 Oct 2009 14:28:10 -0700 (PDT)
Received: from (brmea-mail-2.Sun.COM []) by (Postfix) with ESMTP id 55ADD3A682B for <>; Fri, 16 Oct 2009 14:28:10 -0700 (PDT)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id n9GLSEOk028203 for <>; Fri, 16 Oct 2009 21:28:14 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9GLSDpV011363 for <>; Fri, 16 Oct 2009 15:28:13 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost []) 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 using -f
Date: Fri, 16 Oct 2009 16:16:52 -0500
From: Nicolas Williams <>
To: "Laganier, Julien" <>
Message-ID: <20091016211652.GV892@Sun.COM>
References: <20091015221608.GC907@Sun.COM> <> <20091016203953.GQ892@Sun.COM> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
Cc: "" <>
Subject: Re: [btns] Minor connection-latch problem in AUTH48
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Better-Than-Nothing-Security Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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.