On Tue, 2009-03-03 at 20:18 +0200, Yaron Sheffer wrote:
> Yaron: Sec. 1: 'intended to replace': the status WRT IKEv1 and IKEv2
> is obviously very different. I suggest:
>
> [4306] has obsoleted the IKEv1 document set. The current document
> replaces [IKEv2] and [Clarif] by a single unified descr
On Tue, 2009-03-03 at 20:14 +0200, Yaron Sheffer wrote:
> Yaron:
>
> 2.3: The first paragraph contains an apparent contradiction. It
> mentions that pipelining is done 'if the other endpoint has indicated
> its ability to handle such requests' and then goes on to describe how
> a pipelining imple
On Wed, 2009-03-11 at 13:24 +0100, pasi.ero...@nokia.com wrote:
> Hmm... it seems Tero is right; since the SPI is in the notification
> data (not the "SPI" field of the Notify payload), the "Protocol ID"
> field would be zero, and the recipient doesn't know whether the SPI
> was for ESP or AH.
>
On Tue, 2009-03-03 at 20:18 +0200, Yaron Sheffer wrote:
> 2.2. Use of Sequence Numbers for Message ID
>
> The Message ID is a 32-bit quantity, which is zero for the IKE_SA_INIT
> messages (including retries of the message due to responses such as
> COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}),
On Thu, 2009-03-12 at 11:14 +0100, pasi.ero...@nokia.com wrote:
> Joy Latten wrote:
>
> > > I think Tero's proposal about just noting this fact (i.e. not
> > > changing how this work) would be OK and sufficient.
> >
> > I could be missing s
On Thu, 2009-04-09 at 12:29 -0400, Scott C Moonen wrote:
>
> Can anyone comment on current / best practices with AES-GCM ICV
> lengths? I note that algorithm identifiers are defined for ICV
> lengths of 8, 12 and 16 octets. I also see that RFC 4869 defines
> standard AES-GCM suites using 16-octe
Hi,
New versions of labeled ipsec drafts are available for review.
Please send any comments to lat...@austin.ibm.com.
Thanks!
regards,
Joy Latten
A new version of I-D, draft-jml-ipsec-ikev2-security-context-01.txt has
been successfuly submitted by Joy Latten and posted to the IETF
repository
to pass over the ESP or AH
> SA.
>
> This is what the Traffic Selectors in IKEv2 do.
>
Thanks for reviewing. This sounds like an idea I would like
to look into. I am on vacation, but will look into it as soon as I get
back.
Thanks!
regards,
Joy Latten
On Sun, 2009-11-29 at 19:59 -0500, Stephen Kent wrote:
> I think that there has been insufficient discussion of whether those
> who wish to make use of IPsec to enforce mandatory access controls
> require the facilities described by the folks who have proposed this.
> At the WG meeting 2 weeks a
On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote:
> 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 i
On Fri, 2009-12-04 at 13:39 -0500, Dan McDonald wrote:
> On Fri, Dec 04, 2009 at 12:09:50PM -0600, Joy Latten wrote:
>
>
>
> > I believe they are becoming more mainstream. For example, SELinux and
> > Simplified Mandatory Access Control (SMACK) in Linux Operating
On Mon, 2009-12-07 at 15:02 -0600, Nicolas Williams wrote:
> 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 l
On Mon, 2009-12-07 at 16:37 -0500, Paul Moore wrote:
> On Monday 07 December 2009 11:10:15 am Joy Latten wrote:
> > On Fri, 2009-12-04 at 12:46 -0600, Nicolas Williams wrote:
> > > On Fri, Dec 04, 2009 at 01:39:46PM -0500, Dan McDonald wrote:
> > > > The bigger point
On Mon, 2009-12-07 at 18:41 -0600, Nicolas Williams wrote:
> 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
On Wed, 2010-01-06 at 15:42 -0700, Grewal, Ken wrote:
> Paul,
>
> this topic! :-)>
>
> My 2 cents...
>
> Some people have jumped to conclusions that because we want to differentiate
> between encrypted and non-encrypted traffic by explicitly signaling in the
> packet, that WESP is now a repl
Hi,
I am looking to implement modp groups 22, 23, and 24 into IKE but have a
question.
RFC 5114 gives the prime, p, the generator, g and a subgroup, q, with a
specific size...
Because prior rfcs for modp groups did not specify a "q", I was not sure
if this was a new constant or just stating a s
On Fri, 2010-03-26 at 19:48 -0700, Scott Fluhrer (sfluhrer) wrote:
>
> > -Original Message-
> > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
> > Of Joy Latten
> > Sent: Friday, March 26, 2010 5:25 PM
> > To: mlepin...@bbn.com; k.
On Tue, 2010-04-06 at 12:54 -0400, Richard Barnes wrote:
> > Thanks so much for the detail. It has helped greatly.
> > I did take a look at NIST SP 800-56A section 5.6.2.4 for validating
> > the
> > public value. I am in learning mode, so I found the 2nd step
> > confusing...
> > 1. Verify that 2
The last paragraph of section 2.5 in RFC 4306 states:
Although new payload types may be added in the future and may appear
interleaved with the fields defined in this specification,
implementations MUST send the payloads defined in this specification
in the order shown in the figures i
;s in RESERVED field?
Or does "ignoring content" of RESERVED field mean initiator
can safely assume/build the IDr payload using 0's for RESERVED field
when he computes MACedIDForR? Of course in this case the authentication
will fail... would that
On Thu, 2010-07-01 at 14:35 -0400, Dan McDonald wrote:
> On Thu, Jul 01, 2010 at 01:02:20PM -0500, Joy Latten wrote:
>
> > I am thinking it can be concluded that responder computed MACedIDForR with
> > 1's in the RESERVED field.
>
> That seems valid (though clearly
21 matches
Mail list logo
