Hi Ben,
> Trimming as appropriate...
Further trimming...
> > > In a similar vein, it would be good to see some more formal analysis
> > > that confirms that this construction authenticates the number of
> > > intermediate exchanges that have occurred. I am not sure that I could
> > > sketch an
Hi Valery,
Trimming as appropriate...
On Tue, Jan 11, 2022 at 05:55:45PM +0300, Valery Smyslov wrote:
>
> > Section 3.3.2
> >
> >The requirement to support this behavior makes authentication
> >challenging: it is not appropriate to add on-the-wire content of the
> >IKE_INTERMEDIATE
Hi Tero,
On Tue, Jan 11, 2022 at 02:22:53PM +0200, Tero Kivinen wrote:
> Benjamin Kaduk writes:
> > I'd also like to confirm that the current (lack of) Updates:
> > relationship between this document and RFC 7296 is correct. In §3.2, we
> > reaffirm that the normal IKE rules for assigning
On Tue, 11 Jan 2022, Valery Smyslov wrote:
This sort of construction invites ambiguity if there is ever some other
future exchange that wants to go between IKE_SA_INIT and IKE_AUTH. This
seems like a strong argument in support of the approach this draft
takes, i.e., make IKE_INTERMEDIATE fully
HI Ben,
thank you for your review.
> Hi all,
>
> The core mechanisms here seem in good shape. My main area of
> uncertainty relates to how much analysis, and with what degree of
> formalism, has been applied to the updated IKE_AUTH procedures that are
> supposed to authenticate the
Benjamin Kaduk writes:
> I'd also like to confirm that the current (lack of) Updates:
> relationship between this document and RFC 7296 is correct. In §3.2, we
> reaffirm that the normal IKE rules for assigning Message IDs apply, so
> "it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for
Hi all,
The core mechanisms here seem in good shape. My main area of
uncertainty relates to how much analysis, and with what degree of
formalism, has been applied to the updated IKE_AUTH procedures that are
supposed to authenticate the intermediate exchange(s). My comments on
§3.3.2 have more
