On Dec 21, 2009, at 8:54 PM, wrote:
> Dan,
>
>> If we allocate new numbers to do it right then we will, in fact, live
>> forever with an ambiguous interpretation of groups 19, 20, and 21. I
>> agree we should fix the problem and not live with ambiguity. The proposal
>> to allocate new numbers
And in case there are no extensions for using WESP with encrypted
traffic, then we will continue to use WESP for ESP-NULL only.
Jack
On Mon, Dec 21, 2009 at 6:54 PM, Yaron Sheffer wrote:
> Hi Tero,
>
> Allowing the more generic, encrypted WESP (as per the current I-D) would let
> vendors experi
+1
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org]
> On Behalf Of Brian Swander
> Sent: Tuesday, December 22, 2009 4.43 AM
> To: Yaron Sheffer; Tero Kivinen; Jack Kohn
> Cc: ipsec@ietf.org; Russ Housley
> Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecm
Tero,
> The reason I am in favor of heuristics instead of WESP, is that
> heuristics requires changes only on the middleboxes, we do not need to
> make new extension that will affect all the end nodes supporting
> IPsec.
>
> Also heuristics is not harmful, as it does not harm others, it is
> simp
I took Russ' comments about "being in the rough" to imply that we're re-opening
the consensus discussion. I'm not sure why we're reopening this, since we
already got consensus on this when it came up the first time. Since many of
our internal guys are already out for the holidays, I can't see
My understanding of Tero's mail is that the code was originally written
in 2001. It was modified sometime in 2007 to add "y". Then in July 2009
it was changed to not add "y". So I think there is a problem for a product
shipped from sometime in 2007 to July 2009 when it interoperates with
product
My understanding of Tero's mail is that *he* has such running code. Defining
the new numbers would leave these old implementations in the lurch, but would
ensure unconditional interoperability for new implementations.
Thanks,
Yaron
-Original Message-
From: ipsec-boun...@ietf.org
Dan,
I'm inclined to concur with Bill Sommerfeld and you that we don't have
a "running code" problem, but my original email suggests what could
be done to retire the old identifiers _if_ we did have such a problem.
Thanks,
--David
> -Original Message-
> From: ipsec-boun...@ietf.org [mai
Hi David,
I don't believe there is an actual "running code" problem. It's
just a documentation problem and the errata corrects it.
The thing is, _if_ a running code problem exists the proposal to
add new identifiers for the exact same ECP definitions would not fix
it.
Dan.
On Mon, Dece
As an additional datapoint:
We (Dan McDonald and I) recently extended our IKEv1 implementation to
include ECDH groups 19, 20, and 21 as well as the 5114 groups, over a
cryptographic library which only makes the "x" coordinate available.
The as-specified behavior is unimplementable using the pub
Dan,
> If we allocate new numbers to do it right then we will, in fact, live
> forever with an ambiguous interpretation of groups 19, 20, and 21. I
> agree we should fix the problem and not live with ambiguity. The proposal
> to allocate new numbers doesn't seem to do that though.
Fine, here's
Yaron,
If we allocate new numbers to do it right then we will, in fact, live
forever with an ambiguous interpretation of groups 19, 20, and 21. I
agree we should fix the problem and not live with ambiguity. The proposal
to allocate new numbers doesn't seem to do that though.
Dan.
On Mon,
No, you won't get "no proposal chosen" or "invalid KE" payload.
What you'll get, if you "guess" wrong, is garbage IKEv2 messages
because a different representation of the shared secret will be fed
into the prf that generates the keying material. That will not be
diagnosable. Things just won't wo
Section 3.8 of IKEv2bis (Authentication Payload) makes no mention of ECDSA.
Now granted, there is no mention of ECDH in the Transform substructure
section either, so perhaps that's why.
Given the recent firestorm on ECDH (4753 and its errata), it begs the
question --> does ECDSA have a similar iss
Hi Tero,
I support your position (and disagree with Yoav). We had better fix this
problem now by allocating a few more numbers, than live forever with an
ambiguous interpretation to the numbers that everybody's using.
Thanks,
Yaron
-Original Message-
From: ipsec-boun...@ietf.or
Hi,
We have published a new version of 'IKEv2 Redirect based Authentication
Offload and Proxy Session Resumption'
(draft-padmakumar-ikev2-redirect-and-auth-offload-02).
The draft may be accessed at:
http://tools.ietf.org/html/draft-padmakumar-ikev2-redirect-and-auth-offload-02
Abstract:
IKE
Hi Tero,
Allowing the more generic, encrypted WESP (as per the current I-D) would let
vendors experiment with different extensions. Yes, they might play with some
extensions that you and I find ugly or even insecure. But crippling WESP today
would mean that any such extensions are (1) limited t
Dan Harkins writes:
> The solution of allocating new numbers still doesn't really solve the
> problem because if you receive an KE payload from group 19, 20, or 21
> "you can make your guess whether they also implemented errata or not,
> and act based on that" and that sounds like a recipe for fu
Scott C Moonen writes:
> Tero, what you propose seems the right way to go in principle, but I
> suspect we are solving a problem that doesn't exist. Is there any crypto
> library or device that exposes the y coordinate for use in the ECDH
> secret? It seems pretty well established that the x c
Jack Kohn writes:
> Alternatively, since we seem to be
> having unlimited bandwidth for discussions, we might as well argue
> whether we need heuristics also or not, as there are very few people
> in IPSecMe WG who feel the need for it.
My personal feelings is that this inspecting ESP-NULL packets
Yoav Nir writes:
> If there is such an implementation, then it's not interoperating
> with all the other implementations and should be fixed.
It is following the published RFC, so why should it be fixed. I think
everybody agreed that making major non-interoperable change in the
errata was not prop
Hi Raj,
>> IKEv2 is defined and used for creating IPsec SAs.
> IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol.
> IKEv2 is not just a mean of exchanging keys but its a full package.
> This package provides mutual authentication, keys and readiness to secure
> data a
22 matches
Mail list logo
