Hi Raj
What Yaron suggested, was to create a new payload type, and mark that as
critical.
I don't like either Yaron's or Tero's suggestions, as both lead to a kind of
"take it or leave it" behavior. The initiator proposes doing "childless", and
if the responder does not agree, the IKE SA break
Hi Tero,
Thanks for your valuable inputs.
Please find re inputs inline.
On Wed, Jul 8, 2009 at 1:00 AM, Tero Kivinen wrote:
> Raj Singh writes:
> > Your suggestion of having "critical" bit set on childless notify/VID
> payload
> > from initiator in IKE_SA_INIT exchange will define the bahavior
Hi Sean,
Sounds good. We will make the change in the next revision.
Thanks
Suresh
On 09-07-07 11:49 AM, Sean Turner wrote:
Suresh,
I think the last recommendation in 5.3.1 wrt the hashing algorithms in
PKIX certificates needs to be reworded: r/for PKIX certificates signed
with HMAC-SHA-256
Tero,
> AES-XCBC cannot be used with IKEv1. It can be used for ESP/AH as
> http://www.iana.org/assignments/isakmp-registry registry has values
> for it, but http://www.iana.org/assignments/ipsec-registry registry
> which is used for IKEv1 SA itself does not have any entries for
> AES-XCBC.
Aah,
At 11:13 PM +0300 7/7/09, Yaron Sheffer wrote:
>Content-Language: en-US
>We have one working group draft dealing with new ESP-null implementations.
>We have another draft dealing with unchanged ESP-null implementations. I
>suggest we don't confuse everybody by adding a third category:
>just-a-littl
Yaron Sheffer writes:
> We have one working group draft dealing with new ESP-null implementations.
> We have another draft dealing with unchanged ESP-null implementations. I
> suggest we don't confuse everybody by adding a third category:
> just-a-little-tiny-bit changed implementations. In other w
Hi Tero,
We have one working group draft dealing with new ESP-null implementations.
We have another draft dealing with unchanged ESP-null implementations. I
suggest we don't confuse everybody by adding a third category:
just-a-little-tiny-bit changed implementations. In other words, I think the
se
Scott C Moonen writes:
> Generally, for authentication and PRF purposes, IKEv1 uses HMAC forms of
> authentication algorithms. For most algorithms (e.g., MD5, SHA1, etc.)
> there is both a non-keyed form of the hash and also a keyed HMAC form.
> This doesn't seem to be true for AES-XCBC, which
Paul Hoffman writes:
> > Title : Heuristics for Detecting ESP-NULL packets
> S, that was two months ago, and there has been no discussion.
> Has anyone other than the document authors (and the WESP authors)
> read the document? Does the WG find this to be useful?
>
> Tero and Da
Raj Singh writes:
> Your suggestion of having "critical" bit set on childless notify/VID payload
> from initiator in IKE_SA_INIT exchange will define the bahavior as mentioned
> below.
That is not correct way of using critical bit. Critical bit means that
if it is set and the PAYLOAD TYPE is not u
All,
Below is an I-D that might be of interest to this group.
-Violeta
-Original Message-
From: IETF I-D Submission Tool [mailto:idsubmiss...@ietf.org]
Sent: Thursday, July 02, 2009 10:40 AM
To: Cakulev, Violeta (Violeta)
Cc: a...@bridgewatersystems.com
Subject: New Version Notificatio
Suresh,
I think the last recommendation in 5.3.1 wrt the hashing algorithms in
PKIX certificates needs to be reworded: r/for PKIX certificates signed
with HMAC-SHA-256, -384, and -512./for PKIX certificates hashed with
SHA-256, -384, and -512.
spt
Suresh Krishnan wrote:
Hi Folks,
We have
Generally, for authentication and PRF purposes, IKEv1 uses HMAC forms of
authentication algorithms. For most algorithms (e.g., MD5, SHA1, etc.)
there is both a non-keyed form of the hash and also a keyed HMAC form.
This doesn't seem to be true for AES-XCBC, which is explicitly defined as
a key
I've read it again, and it seems fine. One minor issue, though.
Section 2 describes the WESP header format. It has the following:
HdrLen, 8 bits: Offset to the beginning of the Payload Data in
octets. The receiver MUST ensure that this field matches with
the header offset computed fro
14 matches
Mail list logo
