On Tue, May 25, 2010 at 04:24:38PM -0500, Nicolas Williams wrote:
> A thought about PAKEs and ZKPPs...
I should also mention that the benefits of the SCRAM-with-cb
approach: a) simplicity (doesn't get much simpler!), b) this is
completely unencumbered to the best of my knowledge[*].
A thought about PAKEs and ZKPPs...
In the SASL space we pursued a DIGEST-MD5-like mechanism. Yup, SCRAM is
vulnerable to off-line dictionary attacks by passive attackers. Except
that SCRAM is intended to be used with channel binding to TLS, with
confidentiality protection from the same TLS chann
ate machines (where it had been the case, in RFC 4306, that an
> implementation only needed to do one), and the introduction of problems
> that didn't use to exist (like the "lying NAS" problem). The WG added
> this work item for a very good reason.
Allow me to quote myself:
>
On Mon, May 24, 2010 at 02:50:23PM -0700, Paul Hoffman wrote:
> At 2:07 PM -0700 5/24/10, Dan Harkins wrote:
> > This is out-of-line.
>
> Would it have been less out-of-line if I, the other co-chair wrote it?
> Or if someone who is not a co-chair but understands how the IETF
> process is supposed
On Fri, Jan 08, 2010 at 11:14:06AM -0800, Joseph Tardo wrote:
> -Original Message-
>
> Also, anything QoS related should really happen outside ESP anyways.
>
>
> In an ideal world maybe. Sometimes the netwwork needs to mark traffic
> at the edge switch but doesn't 'trust' the endpoint
On Thu, Jan 07, 2010 at 06:10:10PM -0600, Nicolas Williams wrote:
> On Tue, Jan 05, 2010 at 12:27:26AM +0200, Yaron Sheffer wrote:
> > - The current draft
> > (http://tools.ietf.org/html/draft-ietf-ipsecme-traffic-visibility-11)
> > defines the ESP trailer's ICV calcu
On Fri, Jan 08, 2010 at 07:39:47AM +0530, Jack Kohn wrote:
> > Yes, but it's useful to know what they could possibly do. If a
> > middlebox wants to drop all encrypted IPsec traffic then it needs to
> > know if it's encrypted. Knowing WESP -> ESP-null, ESP -> unknown, is
> > sufficient.
>
> Yup,
On Thu, Jan 07, 2010 at 03:51:04PM -0900, Melinda Shore wrote:
> On Jan 7, 2010, at 3:45 PM, Jack Kohn wrote:
> >I am just trying to understand what a WESP powered middle box thats
> >interested in deep inspecting packets, should do when it sees a native
> >ESP packet. Should it make an attempt to
On Tue, Jan 05, 2010 at 12:27:26AM +0200, Yaron Sheffer wrote:
> We have had a few "discusses" during the IESG review of the WESP
> draft. To help resolve them, we would like to reopen the following two
> questions to WG discussion. Well reasoned answers are certainly
> appreciated. But plain "yes"
On Thu, Dec 10, 2009 at 10:12:54AM +0200, Alper Yegin wrote:
> > The "Do phase 1 first, and phase 2 as traffic demands it" motivation is
> > from the remote access VPN domain (though may be useful for others).
> >
> > The "Do only phase 1, because we don't need encryption and MAC, just
> > peer aut
On Thu, Dec 03, 2009 at 10:18:48PM -0500, Michael Richardson wrote:
> Dan Harkins wrote:
> > 2. solves the specific problem it is aimed at poorly-- doubling of
> >the number of messages, requiring writing and testing of new
> >state EAP state machines that are, otherwise, unnece
On Mon, Dec 07, 2009 at 06:59:13PM -0500, Paul Moore wrote:
> On Monday 07 December 2009 06:20:31 pm Dan McDonald wrote:
> > On Mon, Dec 07, 2009 at 05:53:59PM -0500, Paul Moore wrote:
> > > Why spend the time and effort to develop two specifications (not to
> > > mention the actual implementations
On Mon, Dec 07, 2009 at 04:40:05PM -0500, Sean Turner wrote:
> Nicolas Williams wrote:
> ...snip...
> > - A separate I-D for adding labeling information to certificates.
>
> Are you suggesting that you'd label a certificate? I suspect what
> you're talking about
On Mon, Dec 07, 2009 at 04:37:50PM -0500, Paul Moore wrote:
> At the SELinux Developer's Summit a few months ago there was a bit of a
> general discussion about DOIs and label representation between myself (Linux
> labeled networking), Dave Quigley (labeled NFS, added to CC) and Casey
> Schaufle
On Mon, Dec 07, 2009 at 10:10:15AM -0600, Joy Latten wrote:
> > The proposed work item is, at first glance anyways, too SELinux-
> > specific.
> >
> > Note that SMACK encodes its labels as CIPSO labels, so a scheme that
> > uses CIPSO can possibly be used in SMACK and non-SMACK environments, and
>
On Fri, Dec 04, 2009 at 10:46:02PM +0200, Yaron Sheffer wrote:
> Please remember that it is up to the WG to define the work item. The
> I-D is just a possible starting point, so if there's strong interest
> in this area, you may wish to reach consensus on a charter item - and
> to convince the rest
On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote:
> The bigger point being missed by this thread, I think, is that it
> seems that any work in multi-level security needs to deal with
> successful interoperability. If it doesn't, there's little point in
> documenting a single-platform s
On Wed, Oct 14, 2009 at 02:36:20PM +0300, Tero Kivinen wrote:
> Nicolas Williams writes:
> > - Section 8.3, 1st paragraph, 2nd sentence: this sentence is
> >grammatically incorrect, and I'm unsure as to what is meant.
>
> This was commented already by others and wa
On Tue, Oct 13, 2009 at 01:34:24PM -0500, Nicolas Williams wrote:
> Done.
One more comment:
- State keeping by intermediate nodes is described as an optimization,
however: a) I'm not sure that that necessarily follows, since state
keeping and cache index lookups are not free, and
Note: I did not review the appendix nor its sub-sections.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
- Section 7, 1st paragraph: MOBIKE is mentioned without a reference.
- Section 7, 2nd paragraph: s/avare/aware/
- Section 8.1, next to last sentence: this sentence is grammatically
incorrect, I think. How about:
If the protocol (also known as the, "next header") of thepacket is
On Thu, Aug 13, 2009 at 09:33:41AM +0300, Yoav Nir wrote:
> Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, as
> RFC 4306 calls it, "liveness check"). These messages are very easy to
> spoof.
Also, my reading of RFC4306 is that unprotected INVALID_IKE_SPI or
INVALID_SPI message
On Thu, Aug 13, 2009 at 09:33:41AM +0300, Yoav Nir wrote:
> Any "INVALID_IKE_SPI" or "INVALID_SPI" message can trigger DPD (or, as
> RFC 4306 calls it, "liveness check"). These messages are very easy to
> spoof.
>
> But liveness check is just one round trip between the peers and it's
> supposed to
Over at BTNS WG we're wondering how hard it is for off-path attackers to
cause a node to think that a peer is dead. We'd appreciate your input.
See forwarded post.
Thanks,
Nico
- Forwarded message from Nicolas Williams -
Date: Wed, 12 Aug 2009 13:06:08 -0500
From: Nicola
On Mon, Apr 20, 2009 at 11:20:55AM -0700, Paul Hoffman wrote:
> At 11:15 PM +0530 4/20/09, Lakshminath Dondeti wrote:
> >Before the one roundtrip mechanism is deleted, could you summarize
> >how the security issue that was raised is applicable under the threat
> >model we work with?
>
> No, I can
25 matches
Mail list logo
