Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05

  Hello,   I agree with Tero here. This "tightening" is not necessary. There's no security benefit by disallowing the RFC 7296 RECOMMENDED method of treating AEAD ciphers. The only thing this will do is require pointless changes to existing RFC 7296 compliant implementations.   regards,  

Re: [IPsec] I-D Action: draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-05.txt

  Gee maybe someone is blocking email :/ On 7/11/21 8:38 PM, Paul Wouters wrote: Hmm, it used to be that if you are subscribed to one IETF list, you can post to any of them. That does not seem to work for the ipsec list :/ -- Forwarded message - From: *Paul Wouters*

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

SHOULD/MUST but maybe that is an editorial choice. Yours, Daniel Yours, Daniel On Mon, Jun 28, 2021 at 7:17 PM Dan Harkins mailto:dhark...@lounge.org>> wrote:    Hi, On 6/28/21 1:23 AM, Valery Smyslov wrote: > Hi, >

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

  Hi, On 6/28/21 1:23 AM, Valery Smyslov wrote: Hi, I think document is mostly ready. Few observations: - FWIW I think that Dan's efforts to make draft's language less speculative and more concrete are valid and should be reflected in the document. - Is it OK that the intended status is

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

On 6/27/21 7:02 PM, Paul Wouters wrote: On Sun, 27 Jun 2021, Dan Harkins wrote:   Thanks for facilitating this discussion (especially given the editor's issues with interacting with me). I don't want to keep focussing on this, but again I need to defense myself. I have no i

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

IKEv2 drafts, so it’s not relevant to the draft now in WGLC. Can I assume the unaddressed points are those in the third message? Yoav On 27 Jun 2021, at 10:27, Dan Harkins <mailto:dhark...@lounge.org>> wrote:   I sent substantive comments on this draft to the list on May 6th of this

Re: [IPsec] WGLC for draft-ietf-ipsecme-ikev1-algo-to-historic

  I sent substantive comments on this draft to the list on May 6th of this year. They were not addressed so they apply to this WGLC.   Dan. On 6/26/21 1:38 AM, Yoav Nir wrote: Hi, all. Although this draft is really new, having been submitted in April of this year, its predecessor draft has b

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

  Hi Tero,   Thanks for the clarification. I don't want to resurrect the idea here but I feel compelled to respond to this: On 5/9/21 4:21 AM, Tero Kivinen wrote: And also I think shared key authentication also offeres exactly same benefits than authentication with public key encryption for th

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

On 5/6/21 12:21 PM, Paul Wouters wrote: On Wed, 5 May 2021, Dan Harkins wrote:   - the first two bullet points in section 3 are basically speculation,     "a number of..." is meaningless. These bullet points are ultimately     not even necessary to make the case being made. De

Re: [IPsec] mailer childishness... Re: Delivery Notification: Delivery has failed

top being such a hypocrite. On 5/5/21 9:25 PM, Paul Wouters wrote: On May 5, 2021, at 23:15, Dan Harkins wrote:   OK, this is ridiculous. "non-inclusive behaviour"? Bullying? Gimme a break. I actually tried giving you a break last time you brought this up, but literally days laters y

[IPsec] mailer childishness... Re: Delivery Notification: Delivery has failed

lounge.org> Date: Wed, 05 May 2021 20:08:35 -0700 From: Dan Harkins To: Paul Wouters , ipsec@ietf.org Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt Your message cannot be delivered to the following recipients: Recipient address: p...@n

Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev1-algo-to-historic-00.txt

  Paul,   Thanks for doing this. A few comments:   - the first two bullet points in section 3 are basically speculation,     "a number of..." is meaningless. These bullet points are ultimately     not even necessary to make the case being made. Delete these, please.   - fourth bullet in sectio

[IPsec] comments on graveyard draft, became Re: Delivery Notification: Delivery has failed

  Oh for gaia's sake On 3/8/21 6:33 AM, PMDF Internet Messaging wrote: This report relates to a message you sent with the following header fields: Message-id: Date: Mon, 08 Mar 2021 06:33:15 -0800 From: Dan Harkins To: Paul Wouters Subject: comments on graveyard

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

on the CFRG list but I don't think he's on this one. If you have trust issues with OCB then maybe bring them up with him there.   Dan. -------- *From: *Dan Harkins *Sent: *Mar 4, 2021 5:29 PM *To: *Dan Brown ; ipsec@

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

n. Dan *From:* IPsec *On Behalf Of *Dan Harkins *Sent:* Wednesday, March 3, 2021 2:37 PM *To:* ipsec@ietf.org *Subject:* Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)   Faster and more secure seem to be compelling reasons. Those reasons are probably more com

Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

  Faster and more secure seem to be compelling reasons. Those reasons are probably more compelling for ESP than they are for IKE.   The license for OCB always had some caveats like the code could not be used for military purposes which is something of a nightmare for a manufacturer of general

Re: [IPsec] graveyard: deprecate->historic

On 1/12/20 10:35 PM, Benjamin Kaduk wrote: On Fri, Jan 10, 2020 at 12:01:39AM -0800, Dan Harkins wrote: On 12/23/19 10:46 AM, Benjamin Kaduk wrote: Since we're in pedantic process mode... [snip] Perhaps something like "IKEv1 is no longer relevant for Internet systems" would

Re: [IPsec] graveyard: deprecate->historic

On 12/23/19 10:46 AM, Benjamin Kaduk wrote: Since we're in pedantic process mode... [snip] Perhaps something like "IKEv1 is no longer relevant for Internet systems" would work, though I suspect we could even get away without such an intro sentence and just dive in straight with "Systems runni

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

On 8/30/19 10:51 AM, Paul Wouters wrote: On Fri, 30 Aug 2019, Dan Harkins wrote:  Administrators doing site-to-site VPNs are better of using a true random  strong PSK instead of a weaker PAKE.   Well how many administrators generate a nice string of 256-bits of "true random stron

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

On 8/30/19 9:16 AM, Paul Wouters wrote: On Fri, 30 Aug 2019, Dan Harkins wrote:   Sure we can. We could do the thing that was done in TLS-pwd. When the client registers his username and password she gets a static DH public key of the server (TLS-pwd made this be a p256 curve for its compact

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

On 8/30/19 2:27 AM, Tero Kivinen wrote: Dan Harkins writes: How does the responder know which of the one million username password pairs to pick to generate the generator when calculating D-H in the IKE_SA_INIT? The actual identity of the user is only sent in the encrypted IKE_AUTH message

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

On 8/29/19 7:55 PM, Michael Richardson wrote: Dan Harkins wrote: >   I had some discussions with several people in Montreal on the subject of > using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is > quite cumbersome. I was told I should

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

On 8/29/19 5:11 PM, Tero Kivinen wrote: [removed cfrg from CC, as I do not think this issue really belongs there as we are discussing IKE signaling here]. Dan Harkins writes:   First of all this suggestion is for a particular PAKE and I'm not suggesting that any of the other candidates

Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

  Hello,   I had some discussions with several people in Montreal on the subject of using a PAKE in IKE without using the RFC 6467 "PAKE framework", which is quite cumbersome. I was told I should bring it up on the IPsec list so here goes (copying CFRG since that's where the PAKE work is being d

Re: [IPsec] Quantum Resistant IKEv2

Hi Michael, On 2/13/17 11:06 AM, Michael Richardson wrote: Paul Wouters wrote: >> Michael Richards also suggested we attempt to address how to >> distribute the PPKs. However, I would agree with Valery Smyslov; this >> is out >> of scope for this document; for example, t

[IPsec] OIDs for IKE DH groups

Greetings, Are there defined OIDs for IKE DH groups 14 to 18 (from RFC 3526)? If so, does anyone know what they are? Thanks in advance, Dan. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

On Mon, November 2, 2015 8:58 pm, Yoav Nir wrote: > >> On 3 Nov 2015, at 1:33 PM, Tero Kivinen wrote: >> >> Yoav Nir writes: >>> There is 1 for “RSA Digital Signature” and you can encode any hash >>> function the you would like, but for ECDSA there is: >>> 9 - ECDSA with SHA-256 on the P-256

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote: > >> On 2 Nov 2015, at 11:44 AM, Paul Wouters wrote: >> >> On Mon, 2 Nov 2015, Yoav Nir wrote: >> >>> P.S. Someone’s asked me off-list whether there is any IPsecME >>> document that says not to trust SHA-1 in signatures, both AUTH payload >>> a

[IPsec] PSK mode

https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml "CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant implementations of the IKE standard (IKEv1) together with large, high-entropy, pre-shared keys and the AES-256 encryption algorithm. RFC 2409 is t

Re: [IPsec] everything old is new again

And of course by, "does this implicit construction imply some kind of concatenation…" I don't mean concatenation at all. I mean some sort of chopping off 32 bits. Sorry for the confusion. Dan. On Mon, March 16, 2015 4:37 pm, Dan Harkins wrote: > > Hello, > >

[IPsec] everything old is new again

Hello, I'm leaving too early to attend the ipsecme meeting at IETF 92 but I notice that draft-mglt-6lo-aes-implicit-iv is on the agenda as "other documents". The idea of using an implicit IV was brought up in the IPsec WG back in 1997 and rejected (yes, this was just for CBC mode but that'

Re: [IPsec] Charter review

On Fri, November 7, 2014 12:03 am, Yaron Sheffer wrote: > > > Regarding formal security proofs, I strongly disagree. > > The current wording is extremely mild. It does not require an actual > security proof (which would not be realistic), but says "The solution > should be in line with current b

Re: [IPsec] Charter review

On Tue, November 4, 2014 7:21 pm, Brian Weis wrote: > On Oct 31, 2014, at 4:05 PM, Kathleen Moriarty > wrote: > >> Hi, >> >> The chairs provided text for an updated charter in line with the newly >> adopted working group items. The recharter text has been posted and >> I'd like to give the WG a

[IPsec] new version of IKEv3

ds, Dan. -- A new version of I-D, draft-harkins-ikev3-01.txt has been successfully submitted by Dan Harkins and posted to the IETF repository. Filename:draft-harkins-ikev3 Revision:01 Title: The (Real) Internet Ke

Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks

Hello, I think it looks fine and I have a nit that the authors can ignore if they like. I don't like the fact that RFC 5903 does not list a specific value for "a" in the parameter set definition and instead just says -3 in the equation for the curve. This draft does the same sort of thing

Re: [IPsec] IANA ikev2 registry and FC values

Hello, On Thu, January 17, 2013 10:23 am, Yaron Sheffer wrote: > I agree that sharing registries with related but different protocols is > not a good thing. I just think this is not one of these cases. I agree that this is not the case but sharing registries should not be a problem. We use O

Re: [IPsec] IANA ikev2 registry and FC values

Hello, On Thu, January 17, 2013 9:03 am, Tero Kivinen wrote: > I got question now about the values allocated for the "IKEv2 in the > Fibre Channel Security Association Management Protocol" and their use > in the normal IPsec use over IP. This question was about support for > AUTH_HMAC_MD5_128 a

[IPsec] ID on adding Brainpool ECC curve's to RFC2409's registry

Hello, At the Security Area Directorate's lunch at IETF 84 it was agreed that I would write up an I-D to assign code points for brainpool elliptic cubes to the registry created by RFC 2409 as a way of addressing a liaison request from another SDO. Even though this is not an IPsecME working gr

Re: [IPsec] New draft on IKE Diffie-Hellman checks

On Thu, December 13, 2012 7:57 am, Scott Fluhrer (sfluhrer) wrote: > >> -Original Message- >> From: Johannes Merkle [mailto:johannes.mer...@secunet.com] >> Sent: Thursday, December 13, 2012 5:41 AM >> To: Scott Fluhrer (sfluhrer) >> Cc: Dan Harkins; Yar

Re: [IPsec] New draft on IKE Diffie-Hellman checks

On Tue, December 11, 2012 1:36 pm, Dan Brown wrote: > >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Tuesday, December 11, 2012 4:32 PM >> To: Dan Harkins >> Cc: IPsecme WG &

Re: [IPsec] New draft on IKE Diffie-Hellman checks

I made a mistake below. Thanks to Dan Brown for pointing it out. On Tue, December 11, 2012 10:06 am, Dan Harkins wrote: [snip] > - I think it should be mentioned that elliptic curve groups > have a co-factor, h, and if h > 1 that a further check is > also required, name

Re: [IPsec] New draft on IKE Diffie-Hellman checks

Hello, I have a few comments. - The Introduction says that "It turns out using EC groups in some scenarios require...additional tests. This document defines these tests." Well the memo is defining more than EC. I think the Intro should introduce us to the why, which is

Re: [IPsec] New draft on IKE Diffie-Hellman checks

Hello, On Mon, December 10, 2012 10:43 am, Yaron Sheffer wrote: > Hi, > > following the recent discussion on the mailing list, Scott Fluhrer and > myself just published a draft that updates RFC 5996 by adding the > required recipient-side tests for ECDH. Please see > http://www.ietf.org/interne

Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

. The >> Brainpool Curves are (again) of prime order; this implies that the D-H >> common value is the point at infinity only if the peer's public value is >> the point at infinity (which ought to be forbidden), or our secret value >> is a multiple of the curve order (i

Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

Hi Johannes, On Fri, November 30, 2012 4:11 am, Johannes Merkle wrote: > We have submitted a new revision of the Internet Draft on > Using the ECC Brainpool Curves (defined in RFC 5639) for IKEv2 Key > Exchange > https://datatracker.ietf.org/doc/draft-merkle-ikev2-ke-brainpool/ > > Since there

Re: [IPsec] Question about IKEv1 and ECDSA

Hello, On Wed, November 28, 2012 12:07 am, Yoav Nir wrote: > Hi > > I know we don't like IKEv1 questions, but RFC 4754 does mention it, so > here goes. And sorry if this has been discussed before. I couldn't find > it. What do you mean "we"? :-) > In IKEv1 the authentication method is negot

Re: [IPsec] New I-D on IKEv3

Hi Valery, On Wed, November 7, 2012 10:18 pm, Valery Smyslov wrote: > Hi Dan, > > I suspect the IKEv3 in its current form is susceptible to very simple DoS > attack. > Suppose we have Alice, Bob and Malory. Alice wants to communicate with > Bob, > Malory wants to not allow her to do it. For thi

Re: [IPsec] I-D on Using the ECC Brainpool Curves for IKEv2 Key Exchange

Hi Derek, On Wed, November 7, 2012 10:27 am, Derek Atkins wrote: > Hi, > > On Wed, November 7, 2012 1:21 pm, Johannes Merkle wrote: >> Hi David, >> >> Point compression is simply the ommission of the x-value, and for point >> expansion, functions are included in OpenSSL and >> other crypto libr

Re: [IPsec] Comments to the draft-smyslov-ipsecme-ikev2-fragmentation-00.txt

On Sun, November 4, 2012 5:29 am, Paul Hoffman wrote: > On Nov 3, 2012, at 10:37 PM, Tero Kivinen wrote: > >> A general comment: I think we already decided in the WG that we will >> go with the tcp approach, not with this fragmentation layer in the >> IKEv2. Why do we have this document here? >

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

Hi Michael, On Fri, October 19, 2012 6:08 am, Michael Richardson wrote: > >>>>>> "Dan" == Dan Harkins writes: > Dan> The thing is, they're not just for 802.11. RFC 5931 uses them > Dan> too. > > But, you don't use the value

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

ough an AD, or through the ISE. > > spt > > On 10/15/12 10:54 PM, Dan Harkins wrote: >> >>Hi Sean, >> >> On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: >>> >>> On 10/12/12 2:32 AM, Dan Harkins wrote: >>>> >>>> On Thu

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

o update the >> registry in question it's clear: RFC required. You can get an RFC >> through a WG, through an AD, or through the ISE. >> >> spt >> >> On 10/15/12 10:54 PM, Dan Harkins wrote: >>> >>>Hi Sean, >>> >>> On Mon, Oc

Re: [IPsec] Call for agenda items

On Wed, October 17, 2012 7:38 am, Paul Hoffman wrote: > Greetings again. We have a 2-hour time slot in Atlanta, which is way more > than we asked for. We don't need to be talking about > draft-ietf-ipsecme-p2p-vpn-problem because it's finished with WG LC and is > being sent to the AD for review. T

Re: [IPsec] New I-D on IKEv3

emote access VPN client. Why not support EAP >> authentication? >> >> Regards, >> David >> >> -Original Message- >> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf >> Of Dan Harkins >> Sent: Friday, October 12, 201

Re: [IPsec] New I-D on IKEv3

ted in using with EAP? Dan. > Regards, > David > > -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of > Dan Harkins > Sent: Friday, October 12, 2012 7:02 PM > To: ipsec@ietf.org > Subject: [IPsec] New I-D on IKEv3 > &

Re: [IPsec] New I-D on IKEv3

Hi Paul, On Sat, October 13, 2012 2:35 pm, Paul Wouters wrote: > On Fri, 12 Oct 2012, Dan Harkins wrote: > >> Subject: [IPsec] New I-D on IKEv3 > > Some remarks > > - stateless IKE > > I like not dealing with lingering IKE SA's, but how to tell if a > con

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

Hi Sean, On Mon, October 15, 2012 5:00 pm, Sean Turner wrote: > > On 10/12/12 2:32 AM, Dan Harkins wrote: >> >> On Thu, October 11, 2012 5:47 pm, Sean Turner wrote: >>> >>> I'm going to run my proposal and Michael's by the IESG on an informal >&

[IPsec] New I-D on IKEv3

Hello, I just submitted a new I-D that defines version 3 of IKE. The goals of this draft are to make a more easily understood, and simpler protocol that has a high degree of probability of achieving interoperability. It should be easier to read, easier to understand, and easier to implement.

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

On Fri, October 12, 2012 4:56 am, Tero Kivinen wrote: > Dan Harkins writes: >> Again, this could've been just like RFC 5114-- no fuss, no mess, >> no hullaballo. If precedence has been followed, none of this nonsense >> would've happened. > > It is even eas

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

en if the IESG agrees to do that is that someone somewhere might use a brainpool curve with IKEv1. The odds are slim, but they're not zero. And if that happens then so what? Really. So what? Dan. > spt > > On 9/21/12 4:42 PM, Dan Harkins wrote: >> >>Hi Sean, >>

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

en if the IESG agrees to do that is that someone somewhere might use a brainpool curve with IKEv1. The odds are slim, but they're not zero. And if that happens then so what? Really. So what? Dan. > spt > > On 9/21/12 4:42 PM, Dan Harkins wrote: >> >>Hi Sean, >>

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

On Tue, September 25, 2012 4:02 am, Tero Kivinen wrote: > Dan Harkins writes: >> I voiced support but there was some opposition along the lines of: >> >> * we cannot update the IANA registry of an obsoleted protocol. >> * it is not appropriate for a protocol

Re: [IPsec] brainpool summary, suggested way ahead, and comments on draft

Hi Sean, There's some missing (pre)history and context. Let me try to fill it in. Back in early July, Johannes Merkle sent a note to the list saying he wanted to use the elliptic curves proposed by the ECC Brainpool with IKE and IPsec. He asked a series of questions, one of which was: "

Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt

On Tue, August 28, 2012 11:18 am, Paul Hoffman wrote: > > On Aug 28, 2012, at 10:49 AM, Dan Harkins wrote: > >> When the IEEE liaison brought up this issue, your co-chairman >> said, "Yaron and I should "not* be part of this discussion because >> the issue is

Re: [IPsec] [secdir] I-D Action: draft-harkins-brainpool-ike-groups-00.txt

t maybe you guys should go off and decide what you want. Dan. > > Thanks, > Yaron > > On 08/28/2012 06:48 PM, Dan Harkins wrote: >> >>Hi Tim, >> >> On Tue, August 28, 2012 7:28 am, Polk, William T. wrote: >>> hi Dan, >>> >>

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Fri, July 27, 2012 12:13 am, Yoav Nir wrote: > > On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote: > >> >> On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: >>> Dan Harkins writes: >>>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >>>>

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: > Dan Harkins writes: >> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >> > the fact that we need to study the protocol details and go into the >> > ASN.1 bits to ascertain that we have a problem, strongly suggest

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: > Hi Tero, > > the fact that we need to study the protocol details and go into the > ASN.1 bits to ascertain that we have a problem, strongly suggests to me > that non-EC DSA is not terribly important. So if we can have a *simple* > solution that

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Thu, July 26, 2012 11:06 am, Yoav Nir wrote: > In IKE we only have the bitstring, so we must infer the OID from something > else. Which is why I suggested we take some of the second bunch of RESERVED bits in the AUTH payload. Not to indicate an OID (not enough bits) but to just enumerate the

Re: [IPsec] ECDSA in IKEv2

On Tue, July 24, 2012 11:04 am, Yoav Nir wrote: > - Flexibility in associating hash functions should not a unlimited. There > is no reason to allow a 521-bit EC group with MD4 as the hash function, > or even with SHA2-256 as the hash function. I'm perfectly happy to limit > that curve to SHA2-51

Re: [IPsec] ECDSA in IKEv2

Hello, I would like to participate. The problem I see is that the selection of the hash algorithm has to be decoupled from the indication of the authentication method. So I propose the following: 1. Determining the Domain Parameter Set The curve SHALL be identified by name in the subjectP

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Tue, July 24, 2012 4:17 am, Johannes Merkle wrote: >> If the mapping between curve and hash function is fixed then I don't >> see what you mean by "not hash-independent but only curve-independent". >> Seems that there is nothing independent, it's all fixed. > > I have the impression that we m

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Mon, July 23, 2012 12:15 pm, Johannes Merkle wrote: If we're gonna recharter, maybe we should just work on an IKEv3 because the problems in IKEv2 are becoming apparent. This "new authentication mode" suggestion, or the need for a "generic ECDSA" algorithm are just hac

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Mon, July 23, 2012 2:19 am, Tero Kivinen wrote: > Dan Harkins writes: >> So instead of being able to use the negotiated hash function to >> compute an ECDSA signature we're forced to eat through the "scarce >> resource" of the authentication method registry

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Mon, July 23, 2012 4:31 am, Johannes Merkle wrote: >> >> The particular curve can be determined from the subjectPublicKeyInfo. >> Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool >> curves. > > Actually, this is not strictly correct: > ANSI X9.62 defies three ways to sp

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Sun, July 22, 2012 6:53 am, Yoav Nir wrote: > > With ECDSA, the hashes are the same sizes as the signatures, so there's no > room within the signature to encode the hash algorithm. You need to know > what it is by some other means. So they chose to encode it using the AUTH > method. Not very ec

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Sat, July 21, 2012 10:50 am, Yoav Nir wrote: > > On Jul 21, 2012, at 7:28 PM, Dan Harkins wrote: > >> On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: [snip] >>> I think the way forward is to take this WG and as whether WG would be >>> willing to recharter

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: > Johannes Merkle writes: >> > Adding them for authentication use (ECDSA use) will most likely get >> > more opposition. First of all, I am not at all happy how the ECDSA >> > groups are added to the IKEv2 authentication method. The >> > authentic

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Wed, July 18, 2012 5:14 pm, Tero Kivinen wrote: > Dan Harkins writes: >> Nobody said anything about "adding everything". That is a complete >> straw >> man argument. In fact, it is decidedly not the case that "everything" is >> being >>

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Wed, July 18, 2012 3:12 pm, Tero Kivinen wrote: > Dan Harkins writes: >> > I would be strongly against for including support for protocol which >> > has been obsoleted 7 years ago. If people want to use this kind of >> > groups in IKEv1 they can use the new g

Re: [IPsec] Using ECC Brainpool curves with ipsec

On Wed, July 18, 2012 11:45 am, Tero Kivinen wrote: [snip] >> [Question 1] Should we include IKEv1 in the specs as well? It seems >> that some people in the WG do not like the idea of updating this >> obsolete protocol. On the other hand, many applications still use >> IKEv1 and specifying the use

Re: [IPsec] Using ECC Brainpool curves with ipsec

Hello, On Wed, July 18, 2012 11:51 am, Tero Kivinen wrote: > Dan Harkins writes: >> Absolutely yes. There are still a lot of IKEv1 implementations out >> there >> and also there are other protocols that use the IANA registry from >> IKEv1, >> namely IEEE 80

Re: [IPsec] Using ECC Brainpool curves with ipsec

Hello, On Tue, July 3, 2012 8:59 am, Johannes Merkle wrote: > Hi, > > in RFC 5639, we have specified a new set of elliptic curve parameters for > use in cryptographic applications. Meanwhile, > support for these "Brainpool Curves" has been included in some crypto > libraries as openssl (recentl

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

that. >> >> To ask bluntly - what is the problem with soliciting AD sponsorship for >> the simple addition? >> >> IMHO, "Specification Required" by itself is entirely too weak for >> security protocols. >> >> Thanks, >> --David >>

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

Hi David, On Tue, March 27, 2012 7:39 am, david.bl...@emc.com wrote: > Hi Dan, > > One process note: > >> It appears that all the PAKE drafts got one "yes" from the sponsoring >> AD and the remaining votes were "no objection" so it doesn't seem like >> the IESG is really interested in this to

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

On Tue, March 27, 2012 7:39 am, Tero Kivinen wrote: > Dan Harkins writes: >> That said, the problem I want to fix-- IKEv1's susceptibility to >> dictionary attack, it's binding of a PSK to an IP address, and the >> prevalence of XAUTH because there's no oth

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote: > Dan Harkins writes: >> I guess I'd like to register an objection. I wrote a draft a few >> months >> ago to address this: >> >> http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt >>

Re: [IPsec] ipsec-registry change for IPSEC Authentication Methods (Value 3) registration policy

Hi Tero, I guess I'd like to register an objection. I wrote a draft a few months ago to address this: http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt That suggested making it "Specification Required". You mentioned that someone was opposed to it being "Specification Require

Re: [IPsec] Possible update to isakmp-registry

On Fri, February 10, 2012 12:13 pm, Yaron Sheffer wrote: > Hi Paul, > > sorry, I don't understand your statement. Yes, IKEv1 is popular but > (formally) obsolete. It is still our responsibility to ensure that it > doesn't gain new and insecure extensions in its old age. The way we do > it is thro

Re: [IPsec] Avoiding Authentication Header (AH)

On Thu, January 5, 2012 6:23 am, Tero Kivinen wrote: > Bhatia, Manav (Manav) writes: [snip] >> If a WG ends up mandating AH (when ESP could have been used) then >> Yes it's a problem for everyone, right from the vendors to the >> users, who have to now support AH too in their products and >> netw

Re: [IPsec] Avoiding Authentication Header (AH)

Hello, On Mon, January 2, 2012 7:43 am, Venkatesh Sriram wrote: > If ESP and AH continue to co-exist then I see the following happening: > (i) standard for feature foo1 using ESP-NULL + SW effort + QA effort + > interop effort(ii) standard for feature foo1 using AH + SW effort + QA > effort + i

[IPsec] I-D Action: draft-harkins-ike-iana-update-00.txt

tories. > > Title : A Modest Proposal to Update IKE's IANA Registry > Author(s) : Dan Harkins > Filename: draft-harkins-ike-iana-update-00.txt > Pages : 5 > Date: 2011-11-17 > > The "IPSEC Aut

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem

Hello, On Tue, November 1, 2011 1:56 pm, Paul Wouters wrote: > On Tue, 1 Nov 2011, Yoav Nir wrote: >> Raw RSA keys work. If there is an introducer that tells both sides about >> each other, a shared secret also works. Shared secrets are very secure >> if you generate them randomly. > > PSK's ha

Re: [IPsec] New -00 draft: Creating Large Scale Mesh VPNs Problem Statement

Sounds like TED: http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/ted.html Dan. On Thu, October 13, 2011 10:23 pm, Yoav Nir wrote: > Hi all > > For years, one of the barriers to the adoption of IPsec was that > configuration didn't scale. With thousands of peers, the PAD and S

Re: [IPsec] Perfect Forward secrecy

Hi Naveen, Yoav is right that increasing the size of the secret, and ensuring it is uniformly random, will mitigate this sort of dictionary attack. And the 3 drafts he mentions will basically foil it entirely. But the attack you mention does not affect "perfect forward secrecy". That is th

Re: [IPsec] Role of the IANA expert reviewer

On Mon, August 1, 2011 9:11 am, Paul Hoffman wrote: > On Aug 1, 2011, at 7:42 AM, Tero Kivinen wrote: >> I have stated my reasons why I consider allocating multiple payload >> numbers etc for exactly same thing a bad thing. > > The three proposals do not do "exactly the same thing": they each have

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

Hi Yaron, On Fri, July 29, 2011 2:47 pm, Yaron Sheffer wrote: > Hi Dan, > > there are three drafts on the table, and they are NOT identical. Crypto > protocols, as you know well, are a mixture of cryptography and > engineering. While the engineering on all three is very similar, the > cryptogra

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

On Wed, July 27, 2011 10:49 pm, Yaron Sheffer wrote: > Unfortunately Dan cannot accept that there may be objective, non > political reasons for the group not to adopt his work. Which is the > reason why three alternative proposals were published several months > after his proposed PAKE solution.

Re: [IPsec] Last Call: (Secure Password Framework for IKEv2) to Informational RFC

Paul, The existence of this draft shows a failure of YOUR leadership (and that of your co-chairman) of the working group. Consensus was achieved to add an authentication method based on a simple password yet you seemingly worked to do everything possible to create division in the working grou

Re: [IPsec] DH keys calculation performance

Hello, On Tue, July 26, 2011 6:03 am, Prashant Batra (prbatra) wrote: > Thanks Yoav and Yaron for the suggestions. > > Even I was thinking and tried generating and storing the key pair well > in the beginning,. This helped to some extent. > > > > The secret calculation is also very expensive

  1   2   >