From nobody Sun Mar 1 19:02:53 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5B01A1A30 for ; Sun, 1 Mar 2015 19:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmtQDYTn4K2n for ; Sun, 1 Mar 2015 19:02:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B89301A19E4 for ; Sun, 1 Mar 2015 19:02:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kwR9N1Dgpz5H9; Mon, 2 Mar 2015 04:02:48 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=MMALOreT; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GmwRbvu-EZti; Mon, 2 Mar 2015 04:02:46 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 2 Mar 2015 04:02:46 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CB4C3813B1; Sun, 1 Mar 2015 22:02:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425265365; bh=nLAsu5eOosfW99fdf3P7l8hx1UwFwrWPCiTaG2wmjCc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MMALOreTjbhyIvN1zFdq8RC1tcJEEKyCuSF61GuqEjDqpTr0Uz5xva18KYqoQWYmf IuwuUq+qKiInHoMHNZe66XmxQbwZSUQM2QS1yXd8JLkcRtME7AyCMBWouVgkwevlKg qz4hD980kZcEcG+wVJlq8Rk4wXknbNHZ/U7KQtOI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2232j6n005053; Sun, 1 Mar 2015 22:02:45 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 1 Mar 2015 22:02:45 -0500 (EST) From: Paul Wouters To: Yoav Nir In-Reply-To: <4D31B839-3CC7-4499-AC14-533DCF8EC4B3@gmail.com> Message-ID: References: <798DAF77-94CB-4AF4-AECC-5039808F147F@gmail.com> <4D31B839-3CC7-4499-AC14-533DCF8EC4B3@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] ChaCha20 + Poly1305 for IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 03:02:51 -0000 On Fri, 27 Feb 2015, Yoav Nir wrote: >>> [2] https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-05 >> >> Can we rename ESP_ChaCha20-Poly1305 to ESP_ChaCha20_Poly1305 ? That >> allows implementors to match the literal IANA string into C-code, which >> does not allow a "-" symbol. > > Hmm, it’s like version -10 all over again: > http://www.ietf.org/rfcdiff?url1=draft-irtf-cfrg-chacha20-poly1305-09&url2=draft-irtf-cfrg-chacha20-poly1305-10 Good :) >> The problem is that if future advances in cryptanalysis reveal a >> weakness in AES, VPN users will be in an unenviable position. With >> the only other widely supported cipher being the much slower 3DES, >> >> I'm not sure if that is completely true. We do have Camellia, although >> I'm not a cryptographer and it might be too similar to AES. So I still >> agree with the sentiment of the text. > > There are several algorithms that exist, and even quite a few that are defined for IPsec. But none are as universally implemented as 3DES and AES. So as a developer I can implement Camellia (and I have no idea about its speed relative to AES), but as a user with an existing version of some software that has to interoperate with some other user of some other version of some other software, only with AES and 3DES it’s safe to assume that we can achieve interoperability. The point is, you cannot predict that chacha20/poly1305 will become widely supported either. Regardless, I don't care that much about this bit of text, so if you want to leave it as-is that's fine. >> The length of the ciphertext as a 32-bit network order quantity. >> >> Can we clarify the number of octets used here without needing to go into >> another reference document? > > Mmm, 4? Network order is the controversial part, because everything else in ChaCha20 is little-endian. It would be good for implementors to see that number in this document. >> Although perhaps we can go back to CRFG and ask if they can give us >> something that is not based on the SHA2 family? > > Why don’t you like SHA2? Is it about the performance or just a general dislike of NIST algorithms? I see this as a category ciphers that are non-NIST, grass-roots. So it would make logical sense not to depend no an SHA2/SHA3 family. > Anyway, perhaps you’d like blake2 better: > http://tools.ietf.org/html/draft-saarinen-blake2-01 Seeing that blake2 is based on chacha, I do think that is a better fit to use compared to sha2. > Still seems like a shame to brink that in just for the PRF. The C code is in the RFC, it's not that hard to bring in :P >> I have no strong opinions about Diffie-Hellman groups. > > Perhaps Curve25519 after CFRG finish recommending it. That would make sense. Paul From nobody Mon Mar 2 14:10:10 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E551A89A5 for ; Mon, 2 Mar 2015 14:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qAsL7BHesEr for ; Mon, 2 Mar 2015 14:10:07 -0800 (PST) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE6561A8958 for ; Mon, 2 Mar 2015 14:10:07 -0800 (PST) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1YSYXN-0003Hn-5A for ipsec@ietf.org; Mon, 02 Mar 2015 23:10:05 +0100 Received: from c73-202.rim.net ([208.65.73.202]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Mar 2015 23:10:05 +0100 Received: from kathywan501 by c73-202.rim.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 02 Mar 2015 23:10:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ipsec@ietf.org From: Kathy Wan Date: Mon, 2 Mar 2015 21:54:27 +0000 (UTC) Lines: 15 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 208.65.73.202 (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36) Archived-At: Subject: [IPsec] question about Certificate Encoding type: Hash and URL of X.509 bundle in RFC7296 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 22:10:09 -0000 Hi, In the RFC7296 Internet Key Exchange Protocol Version 2 (IKEv2) , the "Hash and URL of a bundle" type defines the X.509 bundle as a sequence of CertificateOrCRL. Let us say it is a sequence of certificates. My understanding is the bundle file which can be fetched from the url is DER encoded and contains multiple certificates. The question is what is the exact format of the DER encoded bundle file especially how multiple certificates are delimited. Is it just simple concatenation of individual der- encoded certificate? Thanks. Kathy From nobody Tue Mar 3 23:45:04 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0401A03FF for ; Tue, 3 Mar 2015 23:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.47 X-Spam-Level: * X-Spam-Status: No, score=1.47 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq2smXwVaEbB for ; Tue, 3 Mar 2015 23:45:03 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC8D1A0381 for ; Tue, 3 Mar 2015 23:45:02 -0800 (PST) Received: by lbvp9 with SMTP id p9so19439127lbv.8 for ; Tue, 03 Mar 2015 23:45:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=r5Ix1pLQ3BPynZWLhbsP4z92Z81r64TfO/3QhIZXlnQ=; b=EFYdIXk+TZ0mwooXZC7cnMLi+wCeMdtswZ22cUUprmOimoAaBCCp+ILDEz7PBCt4GT +RNmZDQ5SYpbfVvv+gpiu6RQxPxmBeJxwY9Gk0h/ON8NwzLsZ0zNfYprgMCJqF4AlIc3 wBxtHUjAWrmNeMZNINBsL/ASGjQqgm0idAw1lsSOgcsiNhHuMEAK3pHTY3Q2K1GyME++ AEKuLBq3CbLnfbdCAT4eVw3slt9+6aPND/ITLOmFT5vblXO/cKPmoDiJB1IadV+P1zAc gsQW+Y9NwBEA8OmXo/W9pwlFkIJQsOOz25Ckeef8OZ7mXoqBWOmxKYOF4M9acrMgQl97 yPDg== X-Received: by 10.152.246.41 with SMTP id xt9mr2262683lac.110.1425455101124; Tue, 03 Mar 2015 23:45:01 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id w9sm605395lae.35.2015.03.03.23.45.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Mar 2015 23:45:00 -0800 (PST) Message-ID: <4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc> From: "Valery Smyslov" To: "IPsecME WG" References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc> Date: Wed, 4 Mar 2015 10:45:28 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Yoav Nir Subject: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 07:45:04 -0000 Hi all, I've updated my previous pull request. The source file and changes are available at https://github.com/ietf-ipsecme/drafts/pull/2 Now it is completely described using puzzles in the IKE_SA_INIT and IKE_AUTH exchanges. Payload formats and IANA considerations are also provided. Regards, Valery Smyslov. From nobody Wed Mar 4 03:00:47 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960901A1B2D for ; Wed, 4 Mar 2015 03:00:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NUZERiI66zd for ; Wed, 4 Mar 2015 03:00:44 -0800 (PST) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79A201A1B1F for ; Wed, 4 Mar 2015 03:00:44 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id bm13so32883795qab.2 for ; Wed, 04 Mar 2015 03:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=C5ouAKfI5p2r3Qzff66sGXurkt4+1rGbyEdCjHF5tVY=; b=EEl1GiOZa4klzxTGK6UvKhlEMDbB6IupA2nj2U+tF9CV9xbMXHD+3e1Z+t/yzRCwCr 5P57900/xsIxYooPAIEPt3uwzwFNG/kkv5/8aKKlQdNkLRWg+tZkj+21MT/zWBvbQXTx vt0ml67bT4624lw8v8gOY5LaLE54oYmtUTQSnUBe2MUkpuvwJ7nEV54pU7fQRUqST9rp XaZAEf+KqaJ5vKmLLGKpa720TNF6hK9MSjcDR+mDAUpE2LaRYBn4u2ke4Obe5zty077g a1qyiJ9vQ00Ev4KSTz+9Wt9MRSf3zHJltbKgNWOnPVjR9ErF6TPgiO8aJlA2lWWR1hTP zx2g== X-Received: by 10.229.95.74 with SMTP id c10mr5024348qcn.17.1425466843823; Wed, 04 Mar 2015 03:00:43 -0800 (PST) Received: from [10.20.10.5] (ip-64-134-96-199.public.wayport.net. [64.134.96.199]) by mx.google.com with ESMTPSA id v19sm129830qav.16.2015.03.04.03.00.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 03:00:42 -0800 (PST) Message-ID: <54F6E5D3.6040600@gmail.com> Date: Wed, 04 Mar 2015 06:00:35 -0500 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Valery Smyslov , IPsecME WG References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc> <4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc> In-Reply-To: <4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 11:00:46 -0000 Hi Valery, to make it easier for everyone, I suggest that you submit a new draft version. Commenting on the pull request, specifically: "If the puzzle is successfully verified and the SK_* key are calculated, but the message authenticity check fails, the responder SHOULD save the calculated keys in the IKE SA state while waiting for the retransmissions from the initiator. In this case the responder may skip verification of the puzzle solution and ignore the Puzzle Solution payload in the retransmitted messages." It seems to me that if any authenticity check fails, the responder MUST NOT make any changes at all to its saved state. Anything else would complicate implementations and create hard to analyze vulnerabilities. The only gain here is saving a single PRF operation on the responder's side, and it is not worth it. Thanks, Yaron On 04/03/2015 02:45, Valery Smyslov wrote: > Hi all, > > I've updated my previous pull request. > The source file and changes are available at > https://github.com/ietf-ipsecme/drafts/pull/2 > > Now it is completely described using puzzles in the IKE_SA_INIT and > IKE_AUTH exchanges. > Payload formats and IANA considerations > are also provided. > > Regards, > Valery Smyslov. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Mar 4 04:46:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B0E1A0AF7 for ; Wed, 4 Mar 2015 04:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsBgmbursP1i for ; Wed, 4 Mar 2015 04:46:50 -0800 (PST) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058CB1A0086 for ; Wed, 4 Mar 2015 04:46:50 -0800 (PST) Received: by lamq1 with SMTP id q1so21075667lam.9 for ; Wed, 04 Mar 2015 04:46:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=mQMw8tsdoom8d9NuZx5m3NThwwab5fGX8vPno4NpZlI=; b=vCHMtypbHhxMnhUX/mJNtxpY34Nb0rNUTCcL5QL+cleLQnypXU2kQTCZ7k/tW+Wj2Q YlZeahIaHgGVubgj6fpiznWelNUfysi1usGJ7YQz7gT79l6k1WQe4imMvAOYsJ3JhD1+ CcYe1u04orJslcdlwtkCBX5DdkyHeVsM6TkWHhaGsT3Rh1C6/reSlEty0SFt31Qwgflo IgQxnJlx8CdV+f937eVtq6MeP7cIBgupWCImC5oLL7rkcVlasksgmjhj817iyG9IJm4g twC0SVulGJZSxqamOmB9/PFFjmA3LeRudWCeUDrutYU72HwU+pi6G6dVrB1ptq5eBagd cMuw== X-Received: by 10.152.116.18 with SMTP id js18mr3261445lab.106.1425473208565; Wed, 04 Mar 2015 04:46:48 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id rg11sm524568lbc.44.2015.03.04.04.46.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 04 Mar 2015 04:46:47 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" , "IPsecME WG" References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc> <4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc> <54F6E5D3.6040600@gmail.com> Date: Wed, 4 Mar 2015 15:47:04 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 12:46:55 -0000 Hi Yaron, > Hi Valery, > > to make it easier for everyone, I suggest that you submit a new draft > version. I completely agree with you - the amount of changes makes it difficult to track them. We will definitely issue a new version shortly. > Commenting on the pull request, specifically: > > "If the puzzle is successfully verified and the SK_* key are calculated, > but the message authenticity check fails, the responder SHOULD save the > calculated keys in the IKE SA state while waiting for the retransmissions > from the initiator. In this case the responder may skip verification of > the puzzle solution and ignore the Puzzle Solution payload in the > retransmitted messages." > > It seems to me that if any authenticity check fails, the responder MUST > NOT make any changes at all to its saved state. Anything else would > complicate implementations and create hard to analyze vulnerabilities. The > only gain here is saving a single PRF operation on the responder's side, > and it is not worth it. I probably wasn't clear enough. I was talking about the situation when IKE_SA_INIT exchange has been already completed and the responder is waiting for the first IKE_AUTH message. At this point the responder has all the needed information to compute the Diffie-Hellman shared key, the SKEYSEED and the SK_* keys. However, I assume that the responder should not do it immediately, as the IKE_AUTH message could never arrive and it would be just a waste of resources (and a subject to attack). Instead, the responder starts computing the keys only when the IKE_AUTH request message arrives. Moreover, if the responder gives a puzzle to the initiator, then there is no point of doing any expensive computational operations until the puzzle is verified, and this only can be done when the first IKE_AUTH message arrives. Once the IKE_AUTH message is received and the puzzle solution it contains is verified the responder starts calculating DH shared secret, SKEYSEED and the SK_* keys. Only after that can it verify authenticity of the received IKE_AUTH message. And if this check fails, then the message must be discarded. However, what the point to discard SK_* keys in this situation? All the information to compute them was in the IKE_SA_INIT, that has been already finished. We have only postponed the calculation to defend ourselves against possible attack, but once the keys are calculated, we should keep them, since their calculation is costly. And the IKE_AUTH message we've just discarded could be accidentally altered in the network, so probably the next retransmitted message would be valid, so there is no point in discarding the keys and making hard work twice. Does this clarifies the idea? Regards, Valery. > Thanks, > Yaron > > On 04/03/2015 02:45, Valery Smyslov wrote: >> Hi all, >> >> I've updated my previous pull request. >> The source file and changes are available at >> https://github.com/ietf-ipsecme/drafts/pull/2 >> >> Now it is completely described using puzzles in the IKE_SA_INIT and >> IKE_AUTH exchanges. >> Payload formats and IANA considerations >> are also provided. >> >> Regards, >> Valery Smyslov. >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From nobody Wed Mar 4 08:38:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4929D1A9098 for ; Wed, 4 Mar 2015 08:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psWuKa0ErYxs for ; Wed, 4 Mar 2015 08:38:36 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1321A908C for ; Wed, 4 Mar 2015 08:38:36 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t24GcYC3004034 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 4 Mar 2015 09:38:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Content-Type: multipart/signed; boundary="Apple-Mail=_0D1185A2-4115-47F3-8404-AD4E42EA1C51"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Pgp-Agent: GPGMail 2.5b5 From: Paul Hoffman In-Reply-To: Date: Wed, 4 Mar 2015 08:38:31 -0800 Message-Id: References: To: "ipsec@ietf.org" X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 16:38:37 -0000 --Apple-Mail=_0D1185A2-4115-47F3-8404-AD4E42EA1C51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 27, 2015, at 9:05 AM, Kathleen Moriarty = wrote: > Section 2.4 > I see that this draft does not update RFC4301, but in reading this = section, should it? It seems that people here would be happy either way. I propose that I = add to the shepherd report: Our AD asked whether or not this document should be labeled as "Updates = 4301" based on the text in Section 2.4. There was a bit of discussion = about whether or not this document fits the general definition of = "updates" for another RFC, with no strong feelings either way. The WG = defers this question to the IESG and will accept whatever the IESG wants = for this. If you object to this outcome, please say so before Monday. Thanks! --Paul Hoffman --Apple-Mail=_0D1185A2-4115-47F3-8404-AD4E42EA1C51 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJU9zUKAAoJEJz/fXByZmLZAaUH/28l6576s1BCXzSW1+iglfdY vv0UaNtfaw3s8Sz/R4Nc66KUS0eQ2nrCK3xM3O5Td9hWcN5j82KJCp+EjYPk5yVv 3/oUFcLmrrV3X9uPHsWnKXLhg5IuwVuJ7lI9oi1Bkt429xizjAveSWaqN30fvc0R GWmkPkWsHj0fR2QhtVFKP7FRJM5K/npL84ej5eAeYtbW6L9quIQvm0RWmpJWO+EL al9hm9hTWPsuQjmWzrN8L12y+gHFamX+bVU4bkeu8kK7RjclT6/8Ciu4BMhUNXHs uOn+zNAfxdVRKT339kFQ6j5iaRpc1rSZFtHZAJ/A77j0FssTlndjKZZa3MBxBJs= =zWZh -----END PGP SIGNATURE----- --Apple-Mail=_0D1185A2-4115-47F3-8404-AD4E42EA1C51-- From nobody Wed Mar 4 12:26:49 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACD41ACE63; Wed, 4 Mar 2015 12:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii4SkOaWXjUM; Wed, 4 Mar 2015 12:26:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3591ACE44; Wed, 4 Mar 2015 12:26:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304202647.3968.91721.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 12:26:47 -0800 From: IETF Secretariat Archived-At: Subject: [IPsec] ID Tracker State Update Notice: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 20:26:48 -0000 IESG state changed to AD Evaluation from Publication Requested ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ From nobody Thu Mar 5 18:17:54 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 671091A90FC for ; Thu, 5 Mar 2015 18:17:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0keTqH_UW4lZ for ; Thu, 5 Mar 2015 18:17:49 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DF31A90FA for ; Thu, 5 Mar 2015 18:17:49 -0800 (PST) Received: by paceu11 with SMTP id eu11so33591950pac.4 for ; Thu, 05 Mar 2015 18:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=y1j0vRwkoMXDDLOpYMrkGOFqkIyvN0FGgBYNnQCt9Fw=; b=eMtuDn9PvEL3ozgK8plLtffS/8KFAkkO6fkQltTCEjfvX06aYUmS1XrZq8T0hqH8tl V8n2WP8PscIyWVMXL5Jt4xxBtnFE2nb/F5SeJ4LkpcrtruFB3JNJhO655D+bui0HTMrb piKQxOI3VMVZQ22v3zjImqBEIok4pMZuFOjpHwlvnj3O/b/OVJLALn7QulYRl7Gib1yi DIizYj16LJFcD6JBBB1np37qOVIIHzxq2aJWJyGsU4b4muTzAfCUZajqCBY0yOmfGDg2 k9w2GozIy0Nv76sTKy1mfNQaiBbd4vGnRHzFZPfn63BS6nFXDVc5qsMC6dffSDhuSruj LGLw== X-Received: by 10.66.124.129 with SMTP id mi1mr20912370pab.21.1425608268919; Thu, 05 Mar 2015 18:17:48 -0800 (PST) Received: from [50.94.94.250] ([50.94.94.250]) by mx.google.com with ESMTPSA id hx2sm8085853pbc.68.2015.03.05.18.17.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 18:17:47 -0800 (PST) Message-ID: <54F8FDEC.6050902@gmail.com> Date: Thu, 05 Mar 2015 20:07:56 -0500 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Valery Smyslov , IPsecME WG References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc> <4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc> <54F6E5D3.6040600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 02:17:52 -0000 Hi Valery, Thanks for the detailed clarification, and I still disagree... This situation is very unlikely with correctly functioning peers, and I don't think we should recommend acting on unauthenticated information, even if it slightly improves performance. Actually, I think it is a prototypical premature optimization. Besides, if this is really a message that was "altered in the network", how do we know that we produced correct key material? Thanks, Yaron On 04/03/2015 07:47, Valery Smyslov wrote: > Hi Yaron, > >> Hi Valery, >> >> to make it easier for everyone, I suggest that you submit a new draft >> version. > > I completely agree with you - the amount of changes makes it difficult > to track them. We will definitely issue a new version shortly. > >> Commenting on the pull request, specifically: >> >> "If the puzzle is successfully verified and the SK_* key are >> calculated, but the message authenticity check fails, the responder >> SHOULD save the calculated keys in the IKE SA state while waiting for >> the retransmissions from the initiator. In this case the responder >> may skip verification of the puzzle solution and ignore the Puzzle >> Solution payload in the retransmitted messages." >> >> It seems to me that if any authenticity check fails, the responder >> MUST NOT make any changes at all to its saved state. Anything else >> would complicate implementations and create hard to analyze >> vulnerabilities. The only gain here is saving a single PRF operation >> on the responder's side, and it is not worth it. > > I probably wasn't clear enough. > > I was talking about the situation when IKE_SA_INIT exchange has been > already completed and the responder is waiting for the first IKE_AUTH > message. At this point the responder has all the needed information > to compute the Diffie-Hellman shared key, the SKEYSEED and the SK_* keys. > However, I assume that the responder should not do it immediately, > as the IKE_AUTH message could never arrive and it would be just > a waste of resources (and a subject to attack). Instead, the responder > starts computing the keys only when the IKE_AUTH request message > arrives. Moreover, if the responder gives a puzzle to the initiator, > then there is no point of doing any expensive computational operations > until the puzzle is verified, and this only can be done when the first > IKE_AUTH message arrives. > > Once the IKE_AUTH message is received and the puzzle solution it contains > is verified the responder starts calculating DH shared secret, SKEYSEED > and the SK_* keys. Only after that can it verify authenticity of the > received > IKE_AUTH message. And if this check fails, then the message must be > discarded. > However, what the point to discard SK_* keys in this situation? All > the information > to compute them was in the IKE_SA_INIT, that has been already finished. > We have only postponed the calculation to defend ourselves against > possible > attack, but once the keys are calculated, we should keep them, since > their calculation > is costly. And the IKE_AUTH message we've just discarded could be > accidentally altered in the network, so probably the next > retransmitted message > would be valid, so there is no point in discarding the keys and making > hard work twice. > > Does this clarifies the idea? > > Regards, > Valery. > >> Thanks, >> Yaron >> >> On 04/03/2015 02:45, Valery Smyslov wrote: >>> Hi all, >>> >>> I've updated my previous pull request. >>> The source file and changes are available at >>> https://github.com/ietf-ipsecme/drafts/pull/2 >>> >>> Now it is completely described using puzzles in the IKE_SA_INIT and >>> IKE_AUTH exchanges. >>> Payload formats and IANA considerations >>> are also provided. >>> >>> Regards, >>> Valery Smyslov. >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >> > From nobody Thu Mar 5 23:41:12 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEFB1ACD0F for ; Thu, 5 Mar 2015 23:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNRrZY4jls3r for ; Thu, 5 Mar 2015 23:41:10 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B411ACD0B for ; Thu, 5 Mar 2015 23:41:09 -0800 (PST) Received: by labgm9 with SMTP id gm9so16300090lab.7 for ; Thu, 05 Mar 2015 23:41:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=I7qH3q8MPYXw0SgbexygmGXytm+1zxfuOJCMlbTJs74=; b=UKs0KXc0pLN3+nBiLo73JKz3v10d+SGwjHKGj4Gpu6pe0mBbGpn3BGX/XFXJn5ymgP JUhzjPSLI9rHu4hUoMr47ZYIeU9QhwN8caBo/4u4KNs1WMRwvRnRCL0tTupP7kzWKDp/ ol8VBcBMLV0FZ22KGuDZdH9NAwz06dWnZJch0GVKN+X8BstHHinUtY3tMPZLir8HurO7 uDb4ezRf4/XjNsyKh1dGSbeYIZSUNj9elhnxnvICc8sr+aBPjyotrj/H/Nh15Caa0KhY 5hJbtOxs8xZ9Q1DNZGin5l7vwzQR4H/P7AhUm5/CyfaxHLZ57Mh4F0vAVaUzD3oinwaa VpVg== X-Received: by 10.152.28.5 with SMTP id x5mr11321246lag.112.1425627668048; Thu, 05 Mar 2015 23:41:08 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id ci4sm1657893lad.16.2015.03.05.23.41.06 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Mar 2015 23:41:07 -0800 (PST) Message-ID: <0003F871DD31464F9D2DDE36CC4EC9E1@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "IPsecME WG" References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc> <4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc> <54F6E5D3.6040600@gmail.com> <54F8FDEC.6050902@gmail.com> Date: Fri, 6 Mar 2015 10:41:14 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 07:41:12 -0000 Hi Yaron, > Hi Valery, > > Thanks for the detailed clarification, and I still disagree... This > situation is very unlikely with correctly functioning peers, and I don't > think we should recommend acting on unauthenticated information, even if > it slightly improves performance. Actually, I think it is a prototypical > premature optimization. What else could we recommend to do in this situation? If responder deletes IKE SA in case it receives IKE_AUTH message that doesn't pass ICV check, then it would give an attacker an easy way to prevent legitimate initiator to connect - just monitor the network and once IKE_SA_INIT from the legitimate client is finished, inject IKE_AUTH message containing garbage. If responder keeps half-open IKE SA for a while waiting for more IKE_AUTH messages, then I see no reason to repeat calculating D-H shared secret with every received message - the result will be exacly the same. BTW, you youself suggested that the responder cache the SKEYSEED once it is computed. Let me quote your message from 5 December: ---------------------------------------------------------------- [...] There are two cases: - The IKE SA is set up by a valid initiator. - The IKE SA is set up by an attacker. In the first case, the responder needs to compute SKEYSEED anyway. It should compute it once and cache it, even if it sees multiple bogus IKE_AUTH messages sent by attackers. [...] In the second case, the attacker also pays the price if we have a puzzle attached to IKE_SA_INIT. And the responder only computes SKEYSEED once, and caches the result. [...] ---------------------------------------------------------------- So, have you changed your mind or is there some misunderstanding? > Besides, if this is really a message that was "altered in the network", > how do we know that we produced correct key material? If the ICV check of IKE_AUTH message passed, then we know that at least we are talking with the same peer who generated IKE_AUTH message and KEi/r and Ni/r payloads in the IKE_SA_INIT message that we've received. If the check failed, then either IKE_AUTH messages was altered, of some parts of IKE_SA_INIT messages (KEi/r, Ni/r) were altered. If the latter is the case, then nothing can be done - IKE_SA_INIT is already over. But if the former is the case, then there is a chance that the next received IKE_AUTH message (would it be retransmission or just a genuine IKE_AUTH message from legitimate initiator which an attacker was able to outpace with a bogus one) would pass ICV check. Regards, Valery. > Thanks, > Yaron > > On 04/03/2015 07:47, Valery Smyslov wrote: >> Hi Yaron, >> >>> Hi Valery, >>> >>> to make it easier for everyone, I suggest that you submit a new draft >>> version. >> >> I completely agree with you - the amount of changes makes it difficult >> to track them. We will definitely issue a new version shortly. >> >>> Commenting on the pull request, specifically: >>> >>> "If the puzzle is successfully verified and the SK_* key are calculated, >>> but the message authenticity check fails, the responder SHOULD save the >>> calculated keys in the IKE SA state while waiting for the >>> retransmissions from the initiator. In this case the responder may skip >>> verification of the puzzle solution and ignore the Puzzle Solution >>> payload in the retransmitted messages." >>> >>> It seems to me that if any authenticity check fails, the responder MUST >>> NOT make any changes at all to its saved state. Anything else would >>> complicate implementations and create hard to analyze vulnerabilities. >>> The only gain here is saving a single PRF operation on the responder's >>> side, and it is not worth it. >> >> I probably wasn't clear enough. >> >> I was talking about the situation when IKE_SA_INIT exchange has been >> already completed and the responder is waiting for the first IKE_AUTH >> message. At this point the responder has all the needed information >> to compute the Diffie-Hellman shared key, the SKEYSEED and the SK_* keys. >> However, I assume that the responder should not do it immediately, >> as the IKE_AUTH message could never arrive and it would be just >> a waste of resources (and a subject to attack). Instead, the responder >> starts computing the keys only when the IKE_AUTH request message >> arrives. Moreover, if the responder gives a puzzle to the initiator, >> then there is no point of doing any expensive computational operations >> until the puzzle is verified, and this only can be done when the first >> IKE_AUTH message arrives. >> >> Once the IKE_AUTH message is received and the puzzle solution it contains >> is verified the responder starts calculating DH shared secret, SKEYSEED >> and the SK_* keys. Only after that can it verify authenticity of the >> received >> IKE_AUTH message. And if this check fails, then the message must be >> discarded. >> However, what the point to discard SK_* keys in this situation? All the >> information >> to compute them was in the IKE_SA_INIT, that has been already finished. >> We have only postponed the calculation to defend ourselves against >> possible >> attack, but once the keys are calculated, we should keep them, since >> their calculation >> is costly. And the IKE_AUTH message we've just discarded could be >> accidentally altered in the network, so probably the next retransmitted >> message >> would be valid, so there is no point in discarding the keys and making >> hard work twice. >> >> Does this clarifies the idea? >> >> Regards, >> Valery. >> >>> Thanks, >>> Yaron >>> >>> On 04/03/2015 02:45, Valery Smyslov wrote: >>>> Hi all, >>>> >>>> I've updated my previous pull request. >>>> The source file and changes are available at >>>> https://github.com/ietf-ipsecme/drafts/pull/2 >>>> >>>> Now it is completely described using puzzles in the IKE_SA_INIT and >>>> IKE_AUTH exchanges. >>>> Payload formats and IANA considerations >>>> are also provided. >>>> >>>> Regards, >>>> Valery Smyslov. >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> > From nobody Fri Mar 6 01:52:49 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E279E1A005F for ; Fri, 6 Mar 2015 01:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.269 X-Spam-Level: X-Spam-Status: No, score=0.269 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yw7Iau6967L for ; Fri, 6 Mar 2015 01:52:46 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E921A0053 for ; Fri, 6 Mar 2015 01:52:45 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t269qfCX029457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Mar 2015 11:52:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t269qe0h025124; Fri, 6 Mar 2015 11:52:40 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21753.30951.971050.440835@fireball.kivinen.iki.fi> Date: Fri, 6 Mar 2015 11:52:39 +0200 From: Tero Kivinen To: Kathy Wan In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 14 min Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] question about Certificate Encoding type: Hash and URL of X.509 bundle in RFC7296 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 09:52:48 -0000 Kathy Wan writes: > In the RFC7296 Internet Key Exchange Protocol Version 2 (IKEv2) , > the "Hash and URL of a bundle" type defines the X.509 bundle > as a sequence of CertificateOrCRL. > > Let us say it is a sequence of certificates. > My understanding is the bundle file which can be fetched from the url is DER > encoded and contains multiple certificates. Yes. > The question is what is the exact format of the DER encoded bundle file > especially how multiple certificates are delimited. It is what is defined in the RFC7296: CertBundle { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cert-bundle(34) } DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS Certificate, CertificateList FROM PKIX1Explicit88 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) } ; CertificateOrCRL ::= CHOICE { cert [0] Certificate, crl [1] CertificateList } CertificateBundle ::= SEQUENCE OF CertificateOrCRL END > Is it just simple concatenation of individual der- > encoded certificate? No, it is ANS.1 sequence of CertificateOrCRL, where CertificateOrCRL is choise of Certificate or CRL. So it is not simple concatenation of certificates. -- kivinen@iki.fi From nobody Fri Mar 6 03:48:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444741ACD8E for ; Fri, 6 Mar 2015 03:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecNpeaVpSFMX for ; Fri, 6 Mar 2015 03:48:34 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379F71ACD95 for ; Fri, 6 Mar 2015 03:48:34 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t26BmS60021194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 6 Mar 2015 13:48:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t26BmRMw021081; Fri, 6 Mar 2015 13:48:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21753.37899.450149.362726@fireball.kivinen.iki.fi> Date: Fri, 6 Mar 2015 13:48:27 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <0003F871DD31464F9D2DDE36CC4EC9E1@buildpc> References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc> <4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc> <54F6E5D3.6040600@gmail.com> <54F8FDEC.6050902@gmail.com> <0003F871DD31464F9D2DDE36CC4EC9E1@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 9 min Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 11:48:36 -0000 Valery Smyslov writes: > > Thanks for the detailed clarification, and I still disagree... This > > situation is very unlikely with correctly functioning peers, and I don't > > think we should recommend acting on unauthenticated information, even if > > it slightly improves performance. Actually, I think it is a prototypical > > premature optimization. > > What else could we recommend to do in this situation? > If responder deletes IKE SA in case it receives IKE_AUTH > message that doesn't pass ICV check, then it would give > an attacker an easy way to prevent legitimate initiator > to connect - just monitor the network and once IKE_SA_INIT > from the legitimate client is finished, inject IKE_AUTH message > containing garbage. I suggest we do similar thing we do for IKEv2 in general. I.e. if you get IKE_AUTH message which does not pass ICV, you simply drop it. I would expect most of the implementations do that already. Also before you can verify the ICV you need to know the SK_a and to be able to get that you need to calculate SKEYSEED, which requires g^ir, i.e 2nd half of Diffie-Hellman. So at that point you have already calculated the Diffie-Hellman. Also implementation would be completley stupid if it would not store the SKEYSEED and SK_* keys once it has calculated them, so I would expect every implementation do that already, i.e. they will already keep them, and there is no need to say anything about this in here. > If responder keeps half-open IKE SA for a while waiting > for more IKE_AUTH messages, then I see no reason to repeat > calculating D-H shared secret with every received message - > the result will be exacly the same. Why would anybody ever repeat the D-H secret calculation, when they have already calculated SKEYSEED (and SK_*) earlier? Do we also need to say that for future notificaitons it would be nice for implementations to keep the "cached" SK_* values stored in IKE SA, and not to calculate the SK_* from the KE payloads for every single packet? I do not think we need to say such thing, and I do not think we need to say that once you have calculated the SK_* you keep them until you delete the IKE SA. -- kivinen@iki.fi From nobody Fri Mar 6 04:34:26 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3971ACDD7 for ; Fri, 6 Mar 2015 04:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iatLK97RVEjf for ; Fri, 6 Mar 2015 04:34:20 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228AC1ACDC6 for ; Fri, 6 Mar 2015 04:34:20 -0800 (PST) Received: by lbdu14 with SMTP id u14so36083705lbd.0 for ; Fri, 06 Mar 2015 04:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=DVdCEfnUxYwCU9HyN3R62ZEjWtIpBVKx9Fr1KbPkT2M=; b=YUX0CxKpoRzHqhQm6G/F5aMEBxACCXyIm6C2d5Fd5dvofkixDixn5TyRI7p0rI3eU6 MYjd7+GxoMTIohdTxFKf0ICwxA8N4tzp9L0sFXbj33vBNTqeFMGE6EcGb+3sobFFAu3S A45RKXq2CrkZvMhDLTiUIFxyMumEMG9zvQpUrCP54SLhXSo4KOJGU1nlr/XPnGJC/x06 7N3o0kJZOKhuFcJkKJ/+Ms5oE+8cMFvPTAKWh1mVeAFkzI5SyYGmeiYEzI7kf7Vmn6MN ugzBqaobLmtt04Q7520kVdOGqXaF6AuIruPDCJ4nAsK94XRVzUIRg+h27omSrFj+R+hy Fzxw== X-Received: by 10.152.88.71 with SMTP id be7mr12273459lab.119.1425645258611; Fri, 06 Mar 2015 04:34:18 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id w9sm1787707lag.37.2015.03.06.04.34.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 06 Mar 2015 04:34:18 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc><4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc><54F6E5D3.6040600@gmail.com><54F8FDEC.6050902@gmail.com><0003F871DD31464F9D2DDE36CC4EC9E1@buildpc> <21753.37899.450149.362726@fireball.kivinen.iki.fi> Date: Fri, 6 Mar 2015 15:34:25 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 12:34:25 -0000 >> What else could we recommend to do in this situation? >> If responder deletes IKE SA in case it receives IKE_AUTH >> message that doesn't pass ICV check, then it would give >> an attacker an easy way to prevent legitimate initiator >> to connect - just monitor the network and once IKE_SA_INIT >> from the legitimate client is finished, inject IKE_AUTH message >> containing garbage. > > I suggest we do similar thing we do for IKEv2 in general. I.e. if you > get IKE_AUTH message which does not pass ICV, you simply drop it. I > would expect most of the implementations do that already. Also before > you can verify the ICV you need to know the SK_a and to be able to get > that you need to calculate SKEYSEED, which requires g^ir, i.e 2nd half > of Diffie-Hellman. Agree. > So at that point you have already calculated the Diffie-Hellman. Also > implementation would be completley stupid if it would not store the > SKEYSEED and SK_* keys once it has calculated them, so I would expect > every implementation do that already, i.e. they will already keep > them, and there is no need to say anything about this in here. I think there is no harm if the draft recommends such behaviour explicitely. After all, it is about DDoS protection, so every thing that concerns the desense, even evident, should be spelled out. >> If responder keeps half-open IKE SA for a while waiting >> for more IKE_AUTH messages, then I see no reason to repeat >> calculating D-H shared secret with every received message - >> the result will be exacly the same. > > Why would anybody ever repeat the D-H secret calculation, when they > have already calculated SKEYSEED (and SK_*) earlier? > > Do we also need to say that for future notificaitons it would be nice > for implementations to keep the "cached" SK_* values stored in IKE SA, > and not to calculate the SK_* from the KE payloads for every single > packet? That's what the draft recommends. > I do not think we need to say such thing, and I do not think > we need to say that once you have calculated the SK_* you keep them > until you delete the IKE SA. It's better to spell this out, then to let implementers to do it wrong. Regards, Valery. From nobody Fri Mar 6 08:01:24 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFE91A005C for ; Fri, 6 Mar 2015 08:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJT2E7A6HVjF for ; Fri, 6 Mar 2015 08:01:20 -0800 (PST) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22CD81A00B5 for ; Fri, 6 Mar 2015 08:01:18 -0800 (PST) Received: from [10.20.30.109] (142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t26G1HEr060703 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Mar 2015 09:01:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-245.dsl.dynamic.fusionbroadband.com [142.254.17.245] claimed to be [10.20.30.109] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> Date: Fri, 6 Mar 2015 08:01:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> To: IPsecME WG X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 16:01:22 -0000 On Feb 26, 2015, at 2:11 PM, Paul Hoffman wrote: > Greetings again. A few people have expressed interest in having = https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG = item for IPsecME. If you want this as a WG document, and you are willing = to review drafts as they move through, please say so on this thread. If = you are opposed to this being a WG document, please say so (and say = why). Thanks in advance. This got very little interest, which surprised me. Without a few more = people who will commit to review the document and offer comments, we = can't really call it a WG work item. Is there really so little interest = in new algorithms that are being adopted in other protocols? If you are an IPsec implementer, it would be very useful to know whether = or not you would support adding this algorithm to your implementation, = and why. --Paul Hoffman= From nobody Fri Mar 6 10:46:51 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720B31A1A45 for ; Fri, 6 Mar 2015 10:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ve0y2Ae_ikd for ; Fri, 6 Mar 2015 10:46:48 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE01A1A1A10 for ; Fri, 6 Mar 2015 10:46:47 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3kzHwh27TKzC2j; Fri, 6 Mar 2015 19:46:44 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=LNe7OrGl; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ah4d8BipwuPm; Fri, 6 Mar 2015 19:46:43 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 6 Mar 2015 19:46:42 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 10D08813B1; Fri, 6 Mar 2015 13:46:42 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425667602; bh=t/1GApVTARmqtLRJIS4Y9W5qePgAkaQppOL/NnkBZMk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LNe7OrGlDs8+YWLH4LLRug2RjaKdrHLmQgn77ZpDLiY7sr2avM2YJO0aM2KvqcmWA zjkLSQ17PltracrrDnkEIRhx4hr6GAhcLt7Yj4q7rVDNxA45Flok+tJI4jX2hjWOw9 c7OE+OsmiEzMvaxkBnnSSKSnoW9lb3Mgc7oCySlg= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t26IkfY6024541; Fri, 6 Mar 2015 13:46:41 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 6 Mar 2015 13:46:41 -0500 (EST) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:46:49 -0000 On Fri, 6 Mar 2015, Paul Hoffman wrote: > This got very little interest, which surprised me. Without a few more people who will commit to review the document and offer comments, we can't really call it a WG work item. Is there really so little interest in new algorithms that are being adopted in other protocols? > > If you are an IPsec implementer, it would be very useful to know whether or not you would support adding this algorithm to your implementation, and why. libreswan will add support for this algorithm in IKE and use the kernel implementation for ESP. Even with low "interest", this should be taken on by the WG, or else we will just get another private use number like SERPENT(252) or TWOFISH(253) or KAME_NULL(251) that everyone will use. Paul From nobody Fri Mar 6 10:53:26 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550391A1BB8 for ; Fri, 6 Mar 2015 10:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRcSnYfPoE-j for ; Fri, 6 Mar 2015 10:53:21 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5041A1A45 for ; Fri, 6 Mar 2015 10:53:20 -0800 (PST) Received: by wggx12 with SMTP id x12so4288736wgg.13 for ; Fri, 06 Mar 2015 10:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=lGFBxDkRkQmrYgaiG9HUZe438ruzavUrmi2130GJ4pQ=; b=X2dcVu04Ren0wLujEFUDcd7j8bzZdH3amO3A0yVb2a7qZwiMM2k0FhZYpfMqCiifWr CzV39EuEgeNAti59ACkXMFmbsxiuLZPlSxqm3wQacVwhQmhBFLhad2mFxUkb9kk1Ucjx yxCRVOAB1gId3OmMEHeBl3VJFwyfUoqYvb/bK0ZS+u4ZjVeEHvDmXa4fVPVVDj0itTxD BXrSJ/FeHP6pdakXv6djZ6UtHiQaQuVoQrB/GgLktddvzdk4LdJLsFbKZjtYMUaWgwK0 8b7YwbGSrLfXL9yFklqn198VZtAnDIB2UiHXwXJ4v7xWq4Tm6MzbpH1vEBj7KhC9nnhL vFyg== X-Received: by 10.180.81.7 with SMTP id v7mr35839601wix.27.1425667999167; Fri, 06 Mar 2015 10:53:19 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id dn7sm3400206wid.12.2015.03.06.10.53.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Mar 2015 10:53:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Fri, 6 Mar 2015 20:53:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 18:53:25 -0000 > On Mar 6, 2015, at 6:01 PM, Paul Hoffman = wrote: >=20 > On Feb 26, 2015, at 2:11 PM, Paul Hoffman = wrote: >> Greetings again. A few people have expressed interest in having = https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG = item for IPsecME. If you want this as a WG document, and you are willing = to review drafts as they move through, please say so on this thread. If = you are opposed to this being a WG document, please say so (and say = why). Thanks in advance. >=20 > This got very little interest, which surprised me. Without a few more = people who will commit to review the document and offer comments, we = can't really call it a WG work item. Is there really so little interest = in new algorithms that are being adopted in other protocols? >=20 > If you are an IPsec implementer, it would be very useful to know = whether or not you would support adding this algorithm to your = implementation, and why. >=20 Obviously I=E2=80=99m in favor of adoption, as I=E2=80=99m the author. [vendor hat on] If (when?) this becomes an RFC, Check Point will implement this, in all = likelihood this year or early next year. I of course can=E2=80=99t promise dates or versions when this is = delivered as a feature in our product - that is more of a UI decision, = and out of my hands. Yoav From kathywan501@gmail.com Fri Mar 6 12:10:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E251A6FFC for ; Fri, 6 Mar 2015 12:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXlcgTexo2gx for ; Fri, 6 Mar 2015 12:10:12 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3081A1AF0 for ; Fri, 6 Mar 2015 12:10:12 -0800 (PST) Received: by lbvn10 with SMTP id n10so6029114lbv.1 for ; Fri, 06 Mar 2015 12:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+Bowdf/w4BlaL3Lcz/LwVFY0IGj+S5pThCIPOqoofiA=; b=L3ZkakO9LUEhIfGoPTLv1FiMFvcSz5xvPMCYbKRWnHnHhR1xmR/H+tVoj1Oao45EJI ldJU5TdGHrPtZtCpvVC0AFhCoqe8sEGybQudVIxxUcibLRF2O2ICeMXjx6yPTI6KF+s1 dy7K27NDln3hB/eU8pzxSVWngvoC90EedYLdIJ4sVrazj8+7ggK60iGDgl1wDZHRBOtV DCeZ2htEFHwqbIWFdnCj68hGiLtR44IOTwPDxJjHyNJtoduW1I+ddBXYPu7CZHtBPH9q 0o2HLFaCs6cR7+MSkeIHCojQ2yMKeOM9DByp93hcyM+MBpA+LRhXxpn6+DhK7AkJBk14 trmQ== MIME-Version: 1.0 X-Received: by 10.152.45.1 with SMTP id i1mr14411571lam.61.1425672610669; Fri, 06 Mar 2015 12:10:10 -0800 (PST) Received: by 10.112.91.132 with HTTP; Fri, 6 Mar 2015 12:10:10 -0800 (PST) In-Reply-To: <21753.30951.971050.440835@fireball.kivinen.iki.fi> References: <21753.30951.971050.440835@fireball.kivinen.iki.fi> Date: Fri, 6 Mar 2015 15:10:10 -0500 Message-ID: From: Lihua Wan To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11c27c84866a430510a445ee Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] question about Certificate Encoding type: Hash and URL of X.509 bundle in RFC7296 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:19:24 -0000 --001a11c27c84866a430510a445ee Content-Type: text/plain; charset=UTF-8 Thanks Kivinen for your explanation. Understand now. On Fri, Mar 6, 2015 at 4:52 AM, Tero Kivinen wrote: > Kathy Wan writes: > > In the RFC7296 Internet Key Exchange Protocol Version 2 (IKEv2) , > > the "Hash and URL of a bundle" type defines the X.509 bundle > > as a sequence of CertificateOrCRL. > > > > Let us say it is a sequence of certificates. > > My understanding is the bundle file which can be fetched from the url is > DER > > encoded and contains multiple certificates. > > Yes. > > > The question is what is the exact format of the DER encoded bundle file > > especially how multiple certificates are delimited. > > It is what is defined in the RFC7296: > > CertBundle > { iso(1) identified-organization(3) dod(6) internet(1) > security(5) mechanisms(5) pkix(7) id-mod(0) > id-mod-cert-bundle(34) } > > DEFINITIONS EXPLICIT TAGS ::= > BEGIN > > IMPORTS > Certificate, CertificateList > FROM PKIX1Explicit88 > { iso(1) identified-organization(3) dod(6) > internet(1) security(5) mechanisms(5) pkix(7) > id-mod(0) id-pkix1-explicit(18) } ; > > CertificateOrCRL ::= CHOICE { > cert [0] Certificate, > crl [1] CertificateList } > > CertificateBundle ::= SEQUENCE OF CertificateOrCRL > > END > > > Is it just simple concatenation of individual der- > > encoded certificate? > > No, it is ANS.1 sequence of CertificateOrCRL, where CertificateOrCRL > is choise of Certificate or CRL. So it is not simple concatenation of > certificates. > -- > kivinen@iki.fi > --001a11c27c84866a430510a445ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Kivinen for your explanation. Understand now.=C2=A0=

On Fri, Mar= 6, 2015 at 4:52 AM, Tero Kivinen <kivinen@iki.fi> wrote:
Kathy Wan writes:
> In the RFC7296 Internet Key Exchange Protocol Version 2 (IKEv2) ,
> the "Hash and URL of a bundle" type defines the X.509 bundle=
> as a sequence of CertificateOrCRL.
>
> Let us say it is a sequence of certificates.
> My understanding is the bundle file which can be fetched from the url = is DER
> encoded and contains multiple certificates.

Yes.

> The question is what is the exact format of the DER encoded bundle fil= e
> especially how multiple certificates are delimited.

It is what is defined in the RFC7296:

=C2=A0 =C2=A0CertBundle
=C2=A0 =C2=A0 =C2=A0{ iso(1) identified-organization(3) dod(6) internet(1)<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0security(5) mechanisms(5) pkix(7) id-mod(0)
=C2=A0 =C2=A0 =C2=A0 =C2=A0id-mod-cert-bundle(34) }

=C2=A0 =C2=A0DEFINITIONS EXPLICIT TAGS ::=3D
=C2=A0 =C2=A0BEGIN

=C2=A0 =C2=A0IMPORTS
=C2=A0 =C2=A0 =C2=A0Certificate, CertificateList
=C2=A0 =C2=A0 =C2=A0FROM PKIX1Explicit88
=C2=A0 =C2=A0 =C2=A0 =C2=A0 { iso(1) identified-organization(3) dod(6)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 internet(1) security(5) mechanisms(5) pk= ix(7)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 id-mod(0) id-pkix1-explicit(18) } ;

=C2=A0 =C2=A0CertificateOrCRL ::=3D CHOICE {
=C2=A0 =C2=A0 =C2=A0cert [0] Certificate,
=C2=A0 =C2=A0 =C2=A0crl=C2=A0 [1] CertificateList }

=C2=A0 =C2=A0CertificateBundle ::=3D SEQUENCE OF CertificateOrCRL

=C2=A0 =C2=A0END

> Is it just simple concatenation of individual der-
> encoded certificate?

No, it is ANS.1 sequence of CertificateOrCRL, where CertificateOrCRL
is choise of Certificate or CRL. So it is not simple concatenation of
certificates.
--
kivinen@iki.fi

--001a11c27c84866a430510a445ee-- From nobody Fri Mar 6 12:58:18 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C901A86E3 for ; Fri, 6 Mar 2015 12:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.678 X-Spam-Level: X-Spam-Status: No, score=-6.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGmSGvIq6kqA for ; Fri, 6 Mar 2015 12:58:12 -0800 (PST) Received: from es8300.sonicwall.com (mail.sonicwall.com [67.115.118.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69F221A8029 for ; Fri, 6 Mar 2015 12:58:11 -0800 (PST) Received: from es8300.sonicwall.com (127.0.0.1) id hv8ae60171sv for ; Fri, 6 Mar 2015 12:57:50 -0800 (envelope-from ) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonicwall.com; s=20131206; h=Received:Received:From:To:Date: Subject:Thread-Topic:Thread-Index:Message-ID:References: In-Reply-To:Accept-Language:Content-Language:acceptlanguage: Content-Type:Content-Transfer-Encoding:MIME-Version; bh=vBBuY8om CffpP1sfG9vRERDvG4jlwEMjg2DeYXFv45U=; b=GFSrlPHacxxSAMQQqRpk3CBc 9rZXKRj2aY0UivqsIIK9AqJzujhfIm20GxKZLwZ/JwuWzjBMkjzGJ/Ekqf3EIWiB G3ndeUTYbcTGa0OfLizFGRlbsauK7VcdokEPKOGXtxEkm/KdQh2ahwkUeBWe0W0K S+i/r5MJjIZ/o656pBQ6cHNAUYhyCGTBXX6yN7vMZET1H2I3iORjeFQbhBc9Sf6m Ez4ahJP3URaLUO4MpjYl/0IjoMOGBoqbtAxM8OaTE7fcrRHDPfFhUXJOHaV7Xbt0 FCBu4zT4XmIxJD+sF2SmzY5Eapn5/Csjv2lpoZXSsSKCKhPW0ObArRK3Gc68UQ== Received: from US0EXCHT03.us.sonicwall.com ([10.50.129.199]) by es8300.sonicwall.com (SonicWALL 8.0.7.3057) with ESMTPS (version=TLSv1 cipher=AES128-SHA bits=128/128) id 201503062057500010336; Fri, 06 Mar 2015 12:57:50 -0800 Received: from US0SCC01.us.sonicwall.com ([10.50.128.34]) by US0EXCHT03.us.sonicwall.com ([fe80::f8fb:fc84:1cac:ff59%10]) with mapi; Fri, 6 Mar 2015 12:57:50 -0800 From: Jim Knowles To: IPsecME WG Date: Fri, 6 Mar 2015 12:57:48 -0800 Thread-Topic: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 Thread-Index: AdBYJtLULozwSKe4RyqlzVrzPQv9NAAKM1Pg Message-ID: References: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 8.0.7.3057 X-Mlf-UniqueId: o201503062057500010336 Archived-At: Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 20:58:17 -0000 I've read the draft and favor adoption as a working group item. Although I= can't speak for my company, I would push for, and expect, support to be ad= ded to a future product release once reviewed and advanced. Jim Knowles -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Friday, March 06, 2015 8:01 AM To: IPsecME WG Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1= 305 On Feb 26, 2015, at 2:11 PM, Paul Hoffman wrote: > Greetings again. A few people have expressed interest in having https://t= ools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG item for IPs= ecME. If you want this as a WG document, and you are willing to review draf= ts as they move through, please say so on this thread. If you are opposed t= o this being a WG document, please say so (and say why). Thanks in advance. This got very little interest, which surprised me. Without a few more peopl= e who will commit to review the document and offer comments, we can't reall= y call it a WG work item. Is there really so little interest in new algorit= hms that are being adopted in other protocols? If you are an IPsec implementer, it would be very useful to know whether or= not you would support adding this algorithm to your implementation, and wh= y. --Paul Hoffman _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 6 20:32:00 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDC01A89A1 for ; Fri, 6 Mar 2015 20:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.143 X-Spam-Level: X-Spam-Status: No, score=0.143 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F20UI4N-bPwo for ; Fri, 6 Mar 2015 20:31:58 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2C551A89AA for ; Fri, 6 Mar 2015 20:31:45 -0800 (PST) Received: by padbj1 with SMTP id bj1so23172239pad.12 for ; Fri, 06 Mar 2015 20:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9wDV88J5LSZ1yW5WXgSgUuKc7fMofnEBnOi1vyiX4sg=; b=Bq92w2WJO8QGA8IfZ919oppkcc1mmT3Lb+PLg2AFaGWY+NOoXJOtkbNQKp3BL4Y+yj Xi+/PsolEOTkz7H6oGiEdhcldx6RRxGyAZwReWxdSuOzOid2fguHHyxuL69sZV42j4Eq qlmbtZ2/NNbCOZbWdgAGEfu+EUEnvPrTlqCJ3OFCnkG0FOhFzW7aIptN2zicWfUVmvdy DpsyqrK29lZkqe9ySnJsgKeY4gSPY7G1hIgzQkST6/lMZDMJHC4+xuDj6LuDYQ8YhVnG eKfNncKKkA05wWKscb60mnZfw+A5cEBFddrWZIsYS0ssEn2lhqPeT42g29JDsVOtXvBg jGOQ== X-Received: by 10.70.95.166 with SMTP id dl6mr15347162pdb.140.1425702705692; Fri, 06 Mar 2015 20:31:45 -0800 (PST) Received: from [192.168.6.78] (ip-64-134-220-82.public.wayport.net. [64.134.220.82]) by mx.google.com with ESMTPSA id kn10sm1721985pbc.64.2015.03.06.20.31.43 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 20:31:44 -0800 (PST) Message-ID: <54FA0ECD.4060901@gmail.com> Date: Fri, 06 Mar 2015 12:32:13 -0800 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Valery Smyslov , Tero Kivinen References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc><4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc><54F6E5D3.6040600@gmail.com><54F8FDEC.6050902@gmail.com><0003F871DD31464F9D2DDE36CC4EC9E1@buildpc> <21753.37899.450149.362726@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 04:31:59 -0000 Hi Valery, Sorry if I was inconsistent on this one. This is a performance optimization, and it's a trade off for the responder: Do I want to cache keys, thereby saving on CPU but wasting more memory on potentially useless SAs? So I suggest to make it a MAY, not a SHOULD. Thanks, Yaron On 03/06/2015 04:34 AM, Valery Smyslov wrote: >>> What else could we recommend to do in this situation? >>> If responder deletes IKE SA in case it receives IKE_AUTH >>> message that doesn't pass ICV check, then it would give >>> an attacker an easy way to prevent legitimate initiator >>> to connect - just monitor the network and once IKE_SA_INIT >>> from the legitimate client is finished, inject IKE_AUTH message >>> containing garbage. >> >> I suggest we do similar thing we do for IKEv2 in general. I.e. if you >> get IKE_AUTH message which does not pass ICV, you simply drop it. I >> would expect most of the implementations do that already. Also before >> you can verify the ICV you need to know the SK_a and to be able to get >> that you need to calculate SKEYSEED, which requires g^ir, i.e 2nd half >> of Diffie-Hellman. > > Agree. > >> So at that point you have already calculated the Diffie-Hellman. Also >> implementation would be completley stupid if it would not store the >> SKEYSEED and SK_* keys once it has calculated them, so I would expect >> every implementation do that already, i.e. they will already keep >> them, and there is no need to say anything about this in here. > > I think there is no harm if the draft recommends such behaviour > explicitely. > After all, it is about DDoS protection, so every thing that > concerns the desense, even evident, should be spelled out. > >>> If responder keeps half-open IKE SA for a while waiting >>> for more IKE_AUTH messages, then I see no reason to repeat >>> calculating D-H shared secret with every received message - >>> the result will be exacly the same. >> >> Why would anybody ever repeat the D-H secret calculation, when they >> have already calculated SKEYSEED (and SK_*) earlier? >> >> Do we also need to say that for future notificaitons it would be nice >> for implementations to keep the "cached" SK_* values stored in IKE SA, >> and not to calculate the SK_* from the KE payloads for every single >> packet? > > That's what the draft recommends. > >> I do not think we need to say such thing, and I do not think >> we need to say that once you have calculated the SK_* you keep them >> until you delete the IKE SA. > > It's better to spell this out, then to let implementers to do it wrong. > > Regards, > Valery. > From nobody Fri Mar 6 21:50:14 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF551A89B5 for ; Fri, 6 Mar 2015 21:50:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfwtdZTVz-2y for ; Fri, 6 Mar 2015 21:50:11 -0800 (PST) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2741A89B4 for ; Fri, 6 Mar 2015 21:50:10 -0800 (PST) Received: by lbjf15 with SMTP id f15so33600412lbj.2 for ; Fri, 06 Mar 2015 21:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=6R+lv4wG8jZyZKjQl3xLvr1gE0oPXNY7RBMk2DOGgCQ=; b=g0KwKBugNDBr+X7LkTaoEueg/CEgEXOa0mGXdV0vjWLaSsm/xrTDIF2VUSVS47a91S uoZUUConMJ+NtbOAdQ5j5juKVSU8u+yVtRWFcqQ8uYUstA38hsU8ao9WnGTMRIAxuH/x 2jnixsV/rMSBVlD4f4N9KDWCTXU1Ghv+6Iibq3YcbnN654cTEBgpVoFW+EukBSOjTZSc P32N0tOtYIHSE+PTE4q73L6pBNi8Tei/zaA4S0qNHEUlf1xZaVY9nWechbFTXn/D9RRh C4WAOs8Jjf9sbFwyf8MSkkCSJD4HZpU+RFjZKhDlFBndFVS1FX1p1SHVyNsthG7qddAZ dL0Q== X-Received: by 10.152.6.34 with SMTP id x2mr11201102lax.47.1425707409313; Fri, 06 Mar 2015 21:50:09 -0800 (PST) Received: from chichi (ppp83-237-34-104.pppoe.mtu-net.ru. [83.237.34.104]) by mx.google.com with ESMTPSA id h3sm2138881lam.49.2015.03.06.21.50.08 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Mar 2015 21:50:08 -0800 (PST) Message-ID: <6AB1AC668ADA4C23AF30C8C893C3BCEC@chichi> From: "Valery Smyslov" To: "Yaron Sheffer" , "Tero Kivinen" References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc><4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc><54F6E5D3.6040600@gmail.com><54F8FDEC.6050902@gmail.com><0003F871DD31464F9D2DDE36CC4EC9E1@buildpc> <21753.37899.450149.362726@fireball.kivinen.iki.fi> <54FA0ECD.4060901@gmail.com> In-Reply-To: <54FA0ECD.4060901@gmail.com> Date: Sat, 7 Mar 2015 08:50:02 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 05:50:12 -0000 Hi Yaron, > Hi Valery, > > Sorry if I was inconsistent on this one. > > This is a performance optimization, and it's a trade off for the > responder: Do I want to cache keys, thereby saving on CPU but wasting more > memory on potentially useless SAs? So I suggest to make it a MAY, not a > SHOULD. At this point of our defense line we are defending against CPU consumption, not memory consumption. We've already agreed to create an IKE SA state and the keys, while computed, adds relatively little to the size of the state. So I'm reluctant to make it "MAY". Probably a lowercase "should" with some explanations of the reasons will satisfy you? Regards, Valery. > Thanks, > Yaron From nobody Fri Mar 6 22:03:05 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3E1A89B5 for ; Fri, 6 Mar 2015 22:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zin136rEf59z for ; Fri, 6 Mar 2015 22:03:03 -0800 (PST) Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2123E1A89B4 for ; Fri, 6 Mar 2015 22:03:02 -0800 (PST) Received: by qcwr17 with SMTP id r17so3558885qcw.2 for ; Fri, 06 Mar 2015 22:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=biQUzonMNnzdP+5liPHHWEAMenCARqxffrMqfil0c1I=; b=uXFv+toAwzu9xXIYpsHCqFTzsXmpS/sBijVeh3KmKSMt5bf/I21WGHWVGc2q0uOGdq CRx27tUDMM0GdAP8zbte4YnrHb3OaqueKnQqp/eiTuyILf3wkPVFmnjmce+YjppzfRlC I74Xanb0xrl2kkXDoOithPmS7V3dhZfrNoswoQgZeV61DfBtROxyM6iCTd1nda+Nmi56 jamJFYBppXilq7Z+npMd0Eh0a+N4faHRhfHozSaUKY4f7rgFjNK/PT6OntQdqsae/vTY /Z9h3xxLpkmTBGbTNAUONNjfbKgeM30mxYryWy6sueCYm5EexhM8W2Ghyk7l5TQB9YrH EooA== X-Received: by 10.140.104.242 with SMTP id a105mr23201404qgf.89.1425708182282; Fri, 06 Mar 2015 22:03:02 -0800 (PST) Received: from [192.168.6.206] (ip-64-134-220-82.public.wayport.net. [64.134.220.82]) by mx.google.com with ESMTPSA id 63sm7258814qhx.31.2015.03.06.22.03.00 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Mar 2015 22:03:01 -0800 (PST) Message-ID: <54FA9493.7030205@gmail.com> Date: Fri, 06 Mar 2015 22:02:59 -0800 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Valery Smyslov , Tero Kivinen References: <9C28D10A26B74F029D76E0E6811FEF2F@buildpc><4C0276B5DD7F4F15ACF0F3D32C4C0929@buildpc><54F6E5D3.6040600@gmail.com><54F8FDEC.6050902@gmail.com><0003F871DD31464F9D2DDE36CC4EC9E1@buildpc> <21753.37899.450149.362726@fireball.kivinen.iki.fi> <54FA0ECD.4060901@gmail.com> <6AB1AC668ADA4C23AF30C8C893C3BCEC@chichi> In-Reply-To: <6AB1AC668ADA4C23AF30C8C893C3BCEC@chichi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG , Yoav Nir Subject: Re: [IPsec] Puzzles in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 06:03:04 -0000 Please keep it a SHOULD, but include the explanation. Thanks, Yaron On 03/06/2015 09:50 PM, Valery Smyslov wrote: > Hi Yaron, > >> Hi Valery, >> >> Sorry if I was inconsistent on this one. >> >> This is a performance optimization, and it's a trade off for the >> responder: Do I want to cache keys, thereby saving on CPU but wasting >> more memory on potentially useless SAs? So I suggest to make it a MAY, >> not a SHOULD. > > At this point of our defense line we are defending against CPU consumption, > not memory consumption. We've already agreed to create an IKE SA state > and the keys, > while computed, adds relatively little to the size of the state. > > So I'm reluctant to make it "MAY". Probably a lowercase "should" with some > explanations of the reasons will satisfy you? > > Regards, > Valery. > >> Thanks, >> Yaron > From nobody Fri Mar 6 22:07:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BBD1A89E9 for ; Fri, 6 Mar 2015 22:07:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dymAl4i_bnq9 for ; Fri, 6 Mar 2015 22:07:29 -0800 (PST) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8324F1A89C4 for ; Fri, 6 Mar 2015 22:07:29 -0800 (PST) Received: by labgm9 with SMTP id gm9so22026613lab.7 for ; Fri, 06 Mar 2015 22:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:importance; bh=kej+3xUjeRY9yjBLn//nFDf7IkOMgi1q5pXYfRjqYFg=; b=VCZvSdtb6ZzK8b0RKbazQeUoPJTtIcSx3NBY4HkunfqBPHcUhfC4r5lIuPsza1cCpF v1YWwauvISQ2k8eUKTYxq0+Xri8gQi7KfGhLfUqQ7J6P3KQaQas+4ieKmdee57l0d8tk MdVbTCzO/cd/7ouoem+bVRMDCs3NMPpGKrSnLcAgAbJ/jFX5AhDv3ctvJjh/esT0tpB4 tqsSHOz1YuKs6WjpenqO2oKGjv0PfzH2qJ8iIgH9DhJvUuM64BZFnx6tszxt/voDQcfe rOjLlbcesqSobieJD4JsflLV36n2Ex7je8pfnJpNagOWwQzprkyIDG3PIJ6BNpOAZFN/ Ylmw== X-Received: by 10.152.206.70 with SMTP id lm6mr16345541lac.35.1425708447954; Fri, 06 Mar 2015 22:07:27 -0800 (PST) Received: from chichi (ppp83-237-34-104.pppoe.mtu-net.ru. [83.237.34.104]) by mx.google.com with ESMTPSA id j9sm2158741lbp.7.2015.03.06.22.07.26 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 06 Mar 2015 22:07:27 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Hoffman" , "IPsecME WG" References: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> In-Reply-To: Date: Sat, 7 Mar 2015 09:07:20 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] Call for WG adoption:draft-nir-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 06:07:31 -0000 > On Feb 26, 2015, at 2:11 PM, Paul Hoffman wrote: > > Greetings again. A few people have expressed interest in having > > https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG > > item for IPsecME. If you want this as a WG document, and you are willing > > to review > drafts as they move through, please say so on this thread. > > If you are opposed to this being a WG document, please say so (and say > > why). Thanks in advance. > > This got very little interest, which surprised me. Without a few more > people > who will commit to review the document and offer comments, we can't really > call it a WG work item. Is there really so little interest in new > algorithms that > are being adopted in other protocols? > > If you are an IPsec implementer, it would be very useful to know whether > or not you > would support adding this algorithm to your implementation, and why. We (ELVIS-PLUS) will add this algorithm into our products if it is widely deployed (with some definition of "widely"). And since the algorithm is popular it seems to be the case. Anyway I'm in favour of adopting the document so that we don't have interoperability problems in the future. Valery. > --Paul Hoffman From nobody Mon Mar 9 14:21:22 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ADB1ACD7C; Mon, 9 Mar 2015 14:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zywW5gcm3XT; Mon, 9 Mar 2015 14:21:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 253721ACD8F; Mon, 9 Mar 2015 14:21:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309212110.6909.5143.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 14:21:10 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:21:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Protecting Internet Key Exchange (IKE) Implementations from Distributed Denial of Service Attacks Authors : Yoav Nir Valery Smyslov Filename : draft-ietf-ipsecme-ddos-protection-01.txt Pages : 25 Date : 2015-03-09 Abstract: This document recommends implementation and configuration best practices for Internet-connected IPsec Responders, to allow them to resist Denial of Service and Distributed Denial of Service attacks. Additionally, the document introduces a new mechanism called "Client Puzzles" that help accomplish this task. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 19:31:33 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3E71A00BD for ; Mon, 9 Mar 2015 19:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAz5v9CSTCrz for ; Mon, 9 Mar 2015 19:31:29 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA5D1A00CF for ; Mon, 9 Mar 2015 19:31:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l1L5T1fmqz8d; Tue, 10 Mar 2015 03:31:25 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=c6QO/i8i; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id i5adUAbZdlKc; Tue, 10 Mar 2015 03:31:22 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Mar 2015 03:31:22 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B55FC82A1E; Mon, 9 Mar 2015 22:31:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425954681; bh=No/5k2Emy4mGnF+qjMo/2kPq0oF/ccSlc8x3lfWiUwQ=; h=Date:From:To:cc:Subject; b=c6QO/i8iUq1cAfjZ0Lb39ADVkwKUKujOTVNCiez45OeLEwRMi4XiSDXq53mdHaNNS ugDGEQsNUzwGaPVk1PmkaebyyKEnPLs9KnQKlJ3CDEvy8eEbl7otMfhhwzzDKzK+sR 1ApvPFwTmC6ro45Vy5oKH6D2VTYegpsEq7jsH7Tw= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2A2VKZv007309; Mon, 9 Mar 2015 22:31:21 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 9 Mar 2015 22:31:19 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: Tero Kivinen Subject: [IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 02:31:31 -0000 I was looking at the interaction of draft-kivinen-ipsecme-oob-pubkey and IPSECKEY, since IPSECKEY has an algorithm number but oob-pubkey uses the SubjectPublicKeyInfo that encodes the algorithm in the SPKI value itself. So first, if we were to fix this for IPSECKEY (and I'm not yet convinced we are there yet, as we might end up with updating IPSECKEY due to other issues we'll find over the next few months) we might consider allocating a special algorithm number to signify this in the IKE Authentication Method registry at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 For instance, 255 :) Then I noticed that in fact the registry is a two octet value, while in the IPSECKEY record this is a one octet value: https://tools.ietf.org/html/rfc4025#section-2.1 That's clearly a bug. Is it worth filing an ERRATA for this or should we wait and see if we will replace IPSECKEY anyway? Paul From nobody Mon Mar 9 19:50:53 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7F61A00DC for ; Mon, 9 Mar 2015 19:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBnnlXavvIbA for ; Mon, 9 Mar 2015 19:50:51 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263EE1A00B0 for ; Mon, 9 Mar 2015 19:50:51 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l1LWs5SxSz8d for ; Tue, 10 Mar 2015 03:50:49 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=Q4FFhbjr; dkim-adsp=pass X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id uyZWC4Jp46Lh for ; Tue, 10 Mar 2015 03:50:48 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 10 Mar 2015 03:50:48 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A60E582A1E for ; Mon, 9 Mar 2015 22:50:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1425955847; bh=h/4kO6ewkkcpiNLvkQHLXW/a1AjH1JUa+htSQjToMrU=; h=Date:From:To:Subject; b=Q4FFhbjr/UvNrACTWS8LA8lf0IcRzwwA8MIe2uWIJYnU4DUqRIr/8wtq0Cz/rSsjJ 0UHxMwLOVZTA1e6DBg18+sZpQBq6kjcYM3lpCbvi9UniuK/2gQTQEKTjpX/sHvUyEj Kcd7SeqQF+MpH7PuZ0TAsdvCXGNND7b0LdTEzimc= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2A2ol0Y005253 for ; Mon, 9 Mar 2015 22:50:47 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 9 Mar 2015 22:50:47 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] draft-antony-ipsecme-oppo-nat-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 02:50:52 -0000 Hi, We submitted a -00 draft on how to support NATed IPsec peers for use with Opportunistic IPsec. https://tools.ietf.org/html/draft-antony-ipsecme-oppo-nat-00 We hope that this will start some discussion on the issue to see if we are on the right path for this. Paul From nobody Tue Mar 10 03:10:15 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E1E1A874A for ; Tue, 10 Mar 2015 03:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyM4w0e6bCBv for ; Tue, 10 Mar 2015 03:10:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 0386B1A00C0 for ; Tue, 10 Mar 2015 03:10:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 959FD180207; Tue, 10 Mar 2015 03:09:21 -0700 (PDT) To: kivinen@iki.fi, jms@opus1.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150310100921.959FD180207@rfc-editor.org> Date: Tue, 10 Mar 2015 03:09:21 -0700 (PDT) Archived-At: Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org, a.yousar@informatik.hu-berlin.de Subject: [IPsec] [Editorial Errata Reported] RFC7427 (4295) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 10:10:13 -0000 The following errata report has been submitted for RFC7427, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4295 -------------------------------------- Type: Editorial Reported by: Annie Yousar Section: A.4.2 Original Text ------------- Here the parameters are present and contain the default parameters, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField of 1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 001a : NULL 001c : CONTEXT 1 001e : SEQUENCE 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002b : SEQUENCE 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 0034 : NULL 0036 : CONTEXT 2 0038 : INTEGER 0x14 (5 bits) 003b : CONTEXT 3 003d : INTEGER 0x1 (1 bits) Name = RSASSA-PSS with default parameters, oid = 1.2.840.113549.1.1.10 Length = 64 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 Corrected Text -------------- If the default parameters are used, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField of 1, the parameters MUST NOT be encoded according to the Distiguished Encoding Rules (DER) of ASN.1. Therefore the encoding is the same as of A.4.1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE Name = RSASSA-PSS with default parameters, oid = 1.2.840.113549.1.1.10 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 Notes ----- Section 3 requires the use of DER: The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7427 (draft-kivinen-ipsecme-signature-auth-07) -------------------------------------- Title : Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) Publication Date : January 2015 Author(s) : T. Kivinen, J. Snyder Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Mar 10 03:16:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1891A8750 for ; Tue, 10 Mar 2015 03:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB4o6vT9NdOy for ; Tue, 10 Mar 2015 03:16:35 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4151A873C for ; Tue, 10 Mar 2015 03:16:35 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4237E180207; Tue, 10 Mar 2015 03:15:51 -0700 (PDT) To: kivinen@iki.fi, jms@opus1.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, paul.hoffman@vpnc.org, yaronf.ietf@gmail.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150310101551.4237E180207@rfc-editor.org> Date: Tue, 10 Mar 2015 03:15:51 -0700 (PDT) Archived-At: Cc: ipsec@ietf.org, rfc-editor@rfc-editor.org, a.yousar@informatik.hu-berlin.de Subject: [IPsec] [Editorial Errata Reported] RFC7427 (4296) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 10:16:37 -0000 The following errata report has been submitted for RFC7427, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4296 -------------------------------------- Type: Editorial Reported by: Annie Yousar Section: A.4.3 Original Text ------------- Here the parameters are present and contain hashAlgorithm of SHA-256, | maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 001e : NULL 0020 : CONTEXT 1 0022 : SEQUENCE | 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002f : SEQUENCE 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 003c : NULL 003e : CONTEXT 2 0040 : INTEGER 0x20 (6 bits) | 0043 : CONTEXT 3 | 0045 : INTEGER 0x1 (1 bits) Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 | Length = 72 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 | 0040: 0201 20a3 0302 0101 Corrected Text -------------- Here the parameters are present and contain hashAlgorithm of SHA-256, | maskGenAlgorithm of MGF1 with SHA-256, saltLength of 32, and | trailerField of 1. | Note that since the trailerField has the default value it MUST NOT be | encoded according to the Distiguished Encoding Rules (DER) of ASN.1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 001e : NULL 0020 : CONTEXT 1 0022 : SEQUENCE | 0024 : OBJECT IDENTIFIER id-mgf1 (1.2.840.113549.1.1.8) 002f : SEQUENCE 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 003c : NULL 003e : CONTEXT 2 0040 : INTEGER 0x20 (6 bits) Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 | Length = 67 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 | 0040: 0201 20 Notes ----- 1. The maskGenAlgorithm is in fact not SHA-256 (2.16.840.1.101.3.4.2.1), but MGF1 (1.2.840.113549.1.1.8) based on SHA-256 (2.16.840.1.101.3.4.2.1). 2. Section 3 requires the use of DER: The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7427 (draft-kivinen-ipsecme-signature-auth-07) -------------------------------------- Title : Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) Publication Date : January 2015 Author(s) : T. Kivinen, J. Snyder Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Mar 11 11:54:24 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD1E1A0056 for ; Wed, 11 Mar 2015 11:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBKvkoT18sYj for ; Wed, 11 Mar 2015 11:54:22 -0700 (PDT) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id D75831A003B for ; Wed, 11 Mar 2015 11:54:21 -0700 (PDT) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 9BC469A4021 for ; Wed, 11 Mar 2015 14:54:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id QCVsgbeT--HU for ; Wed, 11 Mar 2015 14:54:11 -0400 (EDT) Received: from [192.168.2.100] (pool-96-255-133-185.washdc.fios.verizon.net [96.255.133.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 3DAD59A401E for ; Wed, 11 Mar 2015 14:54:11 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Mar 2015 14:54:00 -0400 Message-Id: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> To: IETF IPsec Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Archived-At: Subject: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 18:54:23 -0000 About two years ago, I was at a workshop where someone claimed that the = Vendor Identifiers that are exchanged in IKE are very useful for dealing = with bugs. The claim was that following the report of a bug, others = could adjust their behaviors to avoid the circumstances that enable the = bug. In the worst case, they could refuse to talk to the badly broken = version, but accept connections to later versions where the bug has been = repaired. Does anyone have operation experience doing this kind of thing? I want = to know if is real experience or speculation about what could be done. Thanks in advance, Russ From nobody Wed Mar 11 12:44:47 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4E1A6ED9 for ; Wed, 11 Mar 2015 12:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGb2VeaCShzn for ; Wed, 11 Mar 2015 12:44:43 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08EA1A6F15 for ; Wed, 11 Mar 2015 12:44:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l2NzB4rKYzDZ6; Wed, 11 Mar 2015 20:44:38 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=E5Jq3VjQ; dkim-adsp=pass X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 3AZBob45uIsa; Wed, 11 Mar 2015 20:44:37 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 11 Mar 2015 20:44:36 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1F373803E0; Wed, 11 Mar 2015 15:44:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426103076; bh=nUaWd61OPgVlT3UJ0MgZOMRyiqYVEEsJSa56JbNZfoU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=E5Jq3VjQYt5YMZSkrPAwCzLGh9NzM1iR3jvXnfRtnTenvnzBMEBi7iirA06EQs7Mj 4b2b6m4K1TYog4GdFwKgx1FTwFLLU1ILTxn7HxlsC/l0eaRdEaGKNUI3bLiyFdZQHt 5QjMr3zGZZPGW2TSLVqmwKyHSgNAxs92lYWmAOyI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2BJiZK3022996; Wed, 11 Mar 2015 15:44:35 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 11 Mar 2015 15:44:35 -0400 (EDT) From: Paul Wouters To: Russ Housley In-Reply-To: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> Message-ID: References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:44:46 -0000 On Wed, 11 Mar 2015, Russ Housley wrote: > About two years ago, I was at a workshop where someone claimed that the Vendor Identifiers that are exchanged in IKE are very useful for dealing with bugs. The claim was that following the report of a bug, others could adjust their behaviors to avoid the circumstances that enable the bug. In the worst case, they could refuse to talk to the badly broken version, but accept connections to later versions where the bug has been repaired. > > Does anyone have operation experience doing this kind of thing? I want to know if is real experience or speculation about what could be done. Although it is more used in the reverse. Vendor X supports a feature and adds a VID that will use it when seen. Now other vendors will have to send that VID to interoperate. What some call feature others call bug of course: Example 1: /* If state has VID_NORTEL, import it to activate workaround */ if (md->nortel) { DBG(DBG_CONTROLMORE, DBG_log("peer requires Nortel Contivity workaround")); st->st_seen_nortel_vid = TRUE; } [..] /* * If we are the responder and the client is in * "Contivity mode", * we need to initiate Quick mode */ if (!(smc->flags & SMF_INITIATOR) && IS_MODE_CFG_ESTABLISHED(st->st_state) && (st->st_seen_nortel_vid)) { libreswan_log("Nortel 'Contivity Mode' detected, starting Quick Mode"); change_state(st, STATE_MAIN_R3); /* ISAKMP is up... */ set_cur_state(st); quick_outI1(st->st_whack_sock, st, st->st_connection, st->st_connection->policy, 1, SOS_NOBODY ); break; } /* wait for modecfg_set */ Another example illustrated by the man page of ipsec.conf on libreswan: cisco-unity whether to send a CISCO_UNITY payload to the peer. Acceptable values are: no (the default) and yes. It is recommended to leave this option unset, unless the remote peer (Cisco client or server) requires it. This option does not modify local behaviour. It can be needed to connect as a client to a Cisco server. It can also be needed to act as a server for a Cisco client, which otherwise might send back an error DEL_REASON_NON_UNITY_PEER. I know we had something with SOFTREMOTE as well, but I don't think we detectd it via VID - it had to be a compile time option. Paul From nobody Wed Mar 11 12:50:21 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678C21A6F15 for ; Wed, 11 Mar 2015 12:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOVkHKGpJJce for ; Wed, 11 Mar 2015 12:50:14 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A713A1A6ED9 for ; Wed, 11 Mar 2015 12:50:14 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=bEuCi37bpIzsm5n4luiPk6P6bS3ZnsWDFHir6eY9UdAL3Fq7K1XdZBV+ KtEBHafenXhi1ijW8zV1LM0A+OSXvbMciDolDnkheZ5kfBzU+CR5IaMJb PZmUBGZyKNP4hvupTwA5u5KhaoAANN0aHuTp8o07V4XXYTrSE18H5pb8I g=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1426103414; x=1457639414; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Z7N2HYZIzOUlYp7lLMpkbNJ+KaCgNyadD7Jq+uPWWWM=; b=wa42xOi0yl3e1dZIM/Ck5YjnRCWH+qB7FyX0uFBvhsRsi3dLjj3omt5h lFYGVKYA8uSjGDRf54h0CUPdV2Zl8vUPMZefm/qN/zL/v2PyZXXVoT3cg 86SKb3tfeLg5m5fHsEigdiV1cAsrZ97BqleZNhTORxbF+VldKlgSbfjVo o=; X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.11,383,1422943200"; d="scan'208";a="631189965" From: To: Thread-Topic: [IPsec] Vendor Identifiers Thread-Index: AQHQXCz1JZ1P6gLbzU+hvSTMQj7SBJ0YBKCA Date: Wed, 11 Mar 2015 19:50:10 +0000 Message-ID: References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> In-Reply-To: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.92] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 19:50:20 -0000 In our work we have not encountered any situations where the Vendor Identif= ication was relevant. paul > On Mar 11, 2015, at 2:54 PM, Russ Housley wrote: >=20 > About two years ago, I was at a workshop where someone claimed that the V= endor Identifiers that are exchanged in IKE are very useful for dealing wit= h bugs. The claim was that following the report of a bug, others could adj= ust their behaviors to avoid the circumstances that enable the bug. In the= worst case, they could refuse to talk to the badly broken version, but acc= ept connections to later versions where the bug has been repaired. >=20 > Does anyone have operation experience doing this kind of thing? I want t= o know if is real experience or speculation about what could be done. From nobody Wed Mar 11 14:24:08 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5A81A87C4 for ; Wed, 11 Mar 2015 14:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU7lrNdYcsMo for ; Wed, 11 Mar 2015 14:24:02 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516151A87C1 for ; Wed, 11 Mar 2015 14:24:02 -0700 (PDT) Received: by wivr20 with SMTP id r20so15290370wiv.3 for ; Wed, 11 Mar 2015 14:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AVwxXpqE7gMdH/rocLHoFurfF/mXhX6m4P80YuuaRcU=; b=ZDWwbGq7YyMb7j+rzsRWFXD99Y+s8dhkNW2m2ZO+WKecHsphAuK+PKDdBzzxPvD4hX 4UlkFHcfJG8lsYWVwSvstdfi60eZTiiT22rQyzm6nsDKp/dAgH8BcWxjl8lVwBTza3kI ey3U3/qtfUtQhF5IdEsCUR1JRhLmJlgF+7UMnYCvQxVuTql/+aTRdid6bBr+hH/50g5S OC+qwIBIIiO34+LArn8K9LhglESgXL6nnku5UfrxfgmsL8eqDwrUA4NqVh/JGsQX/eW2 SodUSERsH8abr3I8iITUPYyY+LamVAnNRQrrZw6gK16U/L/3BCC2EP5S+keWso2i4YXM SV2w== X-Received: by 10.180.21.206 with SMTP id x14mr27687134wie.65.1426109041080; Wed, 11 Mar 2015 14:24:01 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id i10sm7063567wja.40.2015.03.11.14.24.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Mar 2015 14:24:00 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> Date: Wed, 11 Mar 2015 23:23:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> To: Russ Housley X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 21:24:07 -0000 > On Mar 11, 2015, at 8:54 PM, Russ Housley = wrote: >=20 > About two years ago, I was at a workshop where someone claimed that = the Vendor Identifiers that are exchanged in IKE are very useful for = dealing with bugs. The claim was that following the report of a bug, = others could adjust their behaviors to avoid the circumstances that = enable the bug. In the worst case, they could refuse to talk to the = badly broken version, but accept connections to later versions where the = bug has been repaired. >=20 > Does anyone have operation experience doing this kind of thing? I = want to know if is real experience or speculation about what could be = done. I haven=E2=80=99t encountered this kind of use of a VendorID. Years ago = there was a push by auditors for vendors to stop revealing their = versions in protocols. As a result, our VendorID has not changed in ten = years. I suspect the same is true for other vendors. So if a bug is = fixed, the VendorID is not changed. I don=E2=80=99t believe the VendorID = is a good way to identify buggy implementations. Yoav From nobody Wed Mar 11 16:38:36 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1631A8983 for ; Wed, 11 Mar 2015 16:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Rf-6fMryJTc for ; Wed, 11 Mar 2015 16:38:34 -0700 (PDT) Received: from ausxippc110.us.dell.com (AUSXIPPC110.us.dell.com [143.166.85.200]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27A91A897E for ; Wed, 11 Mar 2015 16:38:33 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=Za+EJaeXFqc3dMBuZcjd8H121b4Cbp6sXpcvY6pUOeFKqGgEBo9dBgmh F5kgS/LStX+TWJrKaLZi5nkwpONhJUMaR+U9pcHb38YqppZ3nnrMTe4Cn csJt60oLcsKMmqqYjAOtbVEPXWr0wHYYCZ83rgMc3aPBuuHnOuWRXQZtk Y=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1426117114; x=1457653114; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ewQpDSL+oHuMLRrGi8BhDtnInH69u/Vv0Z9hG7XltWw=; b=hlj3a89l2IiO/9sG+5h+Ezg1/kU2Ac14z49tLpeqcTk9S/zfTFvLTe2U kvhC+K0kSKLj4N1Up3ySE6SCs0BkWyMB4Y/xvlUluk9zstuoReXOGyjpW /t8ZZPAgG0bVJuy+G59oprIVv6ID7vJHVrLA4VIUDCoZDWkMsnCapjmFR M=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.11,385,1422943200"; d="scan'208";a="136913997" From: To: Thread-Topic: [IPsec] Vendor Identifiers Thread-Index: AQHQXCz1JZ1P6gLbzU+hvSTMQj7SBJ0YHtYAgAAlmQA= Date: Wed, 11 Mar 2015 23:38:32 +0000 Message-ID: References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.91] Content-Type: text/plain; charset="utf-8" Content-ID: <8E5EF34606FDA1428BB8374171A5FDEA@dell.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 23:38:35 -0000 DQo+IE9uIE1hciAxMSwgMjAxNSwgYXQgNToyMyBQTSwgWW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFp bC5jb20+IHdyb3RlOg0KPiANCj4gDQo+PiBPbiBNYXIgMTEsIDIwMTUsIGF0IDg6NTQgUE0sIFJ1 c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNlYy5jb20+IHdyb3RlOg0KPj4gDQo+PiBBYm91dCB0 d28geWVhcnMgYWdvLCBJIHdhcyBhdCBhIHdvcmtzaG9wIHdoZXJlIHNvbWVvbmUgY2xhaW1lZCB0 aGF0IHRoZSBWZW5kb3IgSWRlbnRpZmllcnMgdGhhdCBhcmUgZXhjaGFuZ2VkIGluIElLRSBhcmUg dmVyeSB1c2VmdWwgZm9yIGRlYWxpbmcgd2l0aCBidWdzLiAgVGhlIGNsYWltIHdhcyB0aGF0IGZv bGxvd2luZyB0aGUgcmVwb3J0IG9mIGEgYnVnLCBvdGhlcnMgY291bGQgYWRqdXN0IHRoZWlyIGJl aGF2aW9ycyB0byBhdm9pZCB0aGUgY2lyY3Vtc3RhbmNlcyB0aGF0IGVuYWJsZSB0aGUgYnVnLiAg SW4gdGhlIHdvcnN0IGNhc2UsIHRoZXkgY291bGQgcmVmdXNlIHRvIHRhbGsgdG8gdGhlIGJhZGx5 IGJyb2tlbiB2ZXJzaW9uLCBidXQgYWNjZXB0IGNvbm5lY3Rpb25zIHRvIGxhdGVyIHZlcnNpb25z IHdoZXJlIHRoZSBidWcgaGFzIGJlZW4gcmVwYWlyZWQuDQo+PiANCj4+IERvZXMgYW55b25lIGhh dmUgb3BlcmF0aW9uIGV4cGVyaWVuY2UgZG9pbmcgdGhpcyBraW5kIG9mIHRoaW5nPyAgSSB3YW50 IHRvIGtub3cgaWYgaXMgcmVhbCBleHBlcmllbmNlIG9yIHNwZWN1bGF0aW9uIGFib3V0IHdoYXQg Y291bGQgYmUgZG9uZS4NCj4gDQo+IEkgaGF2ZW7igJl0IGVuY291bnRlcmVkIHRoaXMga2luZCBv ZiB1c2Ugb2YgYSBWZW5kb3JJRC4gWWVhcnMgYWdvIHRoZXJlIHdhcyBhIHB1c2ggYnkgYXVkaXRv cnMgZm9yIHZlbmRvcnMgdG8gc3RvcCByZXZlYWxpbmcgdGhlaXIgdmVyc2lvbnMgaW4gcHJvdG9j b2xzLiBBcyBhIHJlc3VsdCwgb3VyIFZlbmRvcklEIGhhcyBub3QgY2hhbmdlZCBpbiB0ZW4geWVh cnMuIEkgc3VzcGVjdCB0aGUgc2FtZSBpcyB0cnVlIGZvciBvdGhlciB2ZW5kb3JzLiBTbyBpZiBh IGJ1ZyBpcyBmaXhlZCwgdGhlIFZlbmRvcklEIGlzIG5vdCBjaGFuZ2VkLiBJIGRvbuKAmXQgYmVs aWV2ZSB0aGUgVmVuZG9ySUQgaXMgYSBnb29kIHdheSB0byBpZGVudGlmeSBidWdneSBpbXBsZW1l bnRhdGlvbnMuDQoNCkFzIGZvciBidWdneSBpbXBsZW1lbnRhdGlvbnMsIEkgdGhpbmsgdGhhdCBp dCBpc27igJl0IG5lZWRlZCBmb3IgdGhhdC4gIElmIHNvbWVvbmUgaGFzIGEgYnVnIHRoYXQgYnJl YWtzIGludGVyb3BlcmFiaWxpdHksIHdlIHdvdWxkIGluIGdlbmVyYWwgdGFrZSB0aGUgdmlldyBv ZiDigJxpZiB0aGV5IGZpeCBpdCwgaXQgd2lsbCB3b3Jr4oCdIOKAlCBpbiBvdGhlciB3b3Jkcywg dmVuZG9ycyBub3JtYWxseSBkb27igJl0IHRha2Ugb24gdGhlIGpvYiBvZiB3b3JraW5nIGFyb3Vu ZCBzb21lb25lIGVsc2XigJlzIG1pc3Rha2VzLg0KDQpJbnRlcmVzdGluZyBzdG9yeSBhYm91dCBh dWRpdG9ycy4gIEkgaGF2ZW7igJl0IHJ1biBpbnRvIGFueSBzdWNoIHRoaW5nLiAgSSB3b3VsZCBo b3BlIHRoYXQgbW9zdCBhdWRpdG9ycyBoYXZlIG1vcmUgc2Vuc2UgdGhhbiB0aGF0Lg0KDQoJcGF1 bA0KDQo= From nobody Wed Mar 11 17:03:06 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8401A8952 for ; Wed, 11 Mar 2015 17:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvU5e9ZCF9ZL for ; Wed, 11 Mar 2015 17:03:02 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ACC71A894F for ; Wed, 11 Mar 2015 17:03:01 -0700 (PDT) Received: by wghl2 with SMTP id l2so12777252wgh.8 for ; Wed, 11 Mar 2015 17:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fGxZDFdYZCnXJCDJUOKB5ghrkBxZtoFPKIiQoNZhi28=; b=xsN+hQR5ckh9MnyPu1a4rxD+g6U0GK4AEr3ekiWiaO5eJHpsr0hHQ+6XkMXktgEMet RNBSv/2kd1nHDRDVpJ/jwXzGsS4KY7pHwrwQeJA6kFVU3fIDUqNOLhR//ESf4p4RUWyF xLl4wi1CbUy+yRY6IRJ5RyYvGXK8Qr50YIn2DWbMETXXYEvWB7ODhL5dqNDKOgYNbhhs PNKhyF+gN7n0LUdc5zvR1yMRnuwxpya+xUsYnN7FseGfr/i7mPsqM2+RWUnU5u0OC4pZ a1uADLP/yWl5P3lh52J9K+Ci7pb7bBTiKgTbFqTZ3rhgl8JySaUwfMw00OTF4UWJ4d+c CkRQ== X-Received: by 10.194.122.98 with SMTP id lr2mr84055034wjb.115.1426118580713; Wed, 11 Mar 2015 17:03:00 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id hn8sm8217303wib.18.2015.03.11.17.02.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Mar 2015 17:02:59 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 12 Mar 2015 02:02:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> To: Paul_Koning@Dell.com X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 00:03:04 -0000 > On Mar 12, 2015, at 1:38 AM, Paul_Koning@Dell.com wrote: >=20 >>=20 >> On Mar 11, 2015, at 5:23 PM, Yoav Nir wrote: >>=20 >>=20 >>> On Mar 11, 2015, at 8:54 PM, Russ Housley = wrote: >>>=20 >>> About two years ago, I was at a workshop where someone claimed that = the Vendor Identifiers that are exchanged in IKE are very useful for = dealing with bugs. The claim was that following the report of a bug, = others could adjust their behaviors to avoid the circumstances that = enable the bug. In the worst case, they could refuse to talk to the = badly broken version, but accept connections to later versions where the = bug has been repaired. >>>=20 >>> Does anyone have operation experience doing this kind of thing? I = want to know if is real experience or speculation about what could be = done. >>=20 >> I haven=E2=80=99t encountered this kind of use of a VendorID. Years = ago there was a push by auditors for vendors to stop revealing their = versions in protocols. As a result, our VendorID has not changed in ten = years. I suspect the same is true for other vendors. So if a bug is = fixed, the VendorID is not changed. I don=E2=80=99t believe the VendorID = is a good way to identify buggy implementations. >=20 > As for buggy implementations, I think that it isn=E2=80=99t needed for = that. If someone has a bug that breaks interoperability, we would in = general take the view of =E2=80=9Cif they fix it, it will work=E2=80=9D = =E2=80=94 in other words, vendors normally don=E2=80=99t take on the job = of working around someone else=E2=80=99s mistakes. >=20 > Interesting story about auditors. I haven=E2=80=99t run into any such = thing. I would hope that most auditors have more sense than that. Unfortunately, it=E2=80=99s far easier to stop sending the version than = to argue against this. http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2004-2679 Yoav From nobody Wed Mar 11 17:37:20 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343D41A8973 for ; Wed, 11 Mar 2015 17:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iyAjg_ZDKEt for ; Wed, 11 Mar 2015 17:37:17 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DBA61A884F for ; Wed, 11 Mar 2015 17:37:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l2WSK1S43zp8; Thu, 12 Mar 2015 01:36:49 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=icuPi+oS; dkim-adsp=pass X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id OEmpJ04vyKh8; Thu, 12 Mar 2015 01:36:47 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 12 Mar 2015 01:36:47 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A03FE813B1; Wed, 11 Mar 2015 20:26:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426120011; bh=HjwBiWnfleZo2o5Q8iPC+6bsIc5ZFEORJgdTWHbq2jg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=icuPi+oSJ71D0dkQZ/uQ0oouP78QiLiNRqh94/wXbnQF58IMNbDTV2nfKftQKuUAo TObpTvCZp2dq9N5+j6VrTVGZHyja8IEF9hPOzujeTr99ZY4cC8qEonNDiSNcbZKbMx VsqwB4pF+eiuDl1+bHcd+XER37+aQA9NSXuHhCL0= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2C0QowW029660; Wed, 11 Mar 2015 20:26:51 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Wed, 11 Mar 2015 20:26:50 -0400 (EDT) From: Paul Wouters To: Paul_Koning@Dell.com In-Reply-To: Message-ID: References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 00:37:19 -0000 On Wed, 11 Mar 2015, Paul_Koning@Dell.com wrote: > As for buggy implementations, I think that it isn’t needed for that. I agree with that. > If someone has a bug that breaks interoperability, we would in general take the view of “if they fix it, it will work” — in other words, vendors normally don’t take on the job of working around someone else’s mistakes. That I don't agree with. For openswan/libreswan I have done plenty of workarounds or additional checks. It is just that usually the bugs are clear enough that you do not need a vendorid to figure it out. For instance: commit f853f44177155f75ff2910a8fe2b96d95f8050e5 Author: Paul Wouters Date: Wed May 14 10:22:45 2014 -0400 DPD: openbsd isakmpd bug workaround for duplicate DPD seqno openbsd mistakenly re-uses the same DPD sequence number when its DPD probe did not receive an answer. If the probe hit the other endpoint, but got lost on the return, it means openbsd sends a duplicate DPD seqno, which according to RFC 3706 Section 7 "Security Considerations" we detect as a replayed packet that we drop. This patch introduced the same kludge openbsd uses to interop with itself. That is, we allow and answer 3 dupliates before we remain quiet and assume it is a DDOS attack. If you read this and have openbsd commit access, please do: isakmpd/dpd.c around line 350: - ISAKMP_NOTIFY_STATUS_DPD_R_U_THERE, isakmp_sa->dpd_seq); + ISAKMP_NOTIFY_STATUS_DPD_R_U_THERE, isakmp_sa->dpd_seq++); We could have done this based on VID, but why not do it directly on the bad DPD seq_no. Our IKEv1 code is full of these gems. Writing one from scratch according to spec will cause you to have to relearn years of interoperability bugs. Even today, I found a bug in whatever IKE daemon Amazon AWS is using, although in this case, there is just no practical workaround because it is just too broken: https://libreswan.org/wiki/Interoperability#Multiple_tunnels_fail_with_Amazon.27s_VPN So, while some vendors might be able to say "fix your stuff", the opensource people don't often have that luxury. Or, perhaps it is because we _do_ have the luxury of writing new code :) Paul From nobody Wed Mar 11 19:09:39 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F221A89AB for ; Wed, 11 Mar 2015 19:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxnRfs7Xzkbl for ; Wed, 11 Mar 2015 19:09:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0136.outbound.protection.outlook.com [207.46.100.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FEE1A8990 for ; Wed, 11 Mar 2015 19:09:33 -0700 (PDT) Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB667.namprd05.prod.outlook.com (10.141.230.23) with Microsoft SMTP Server (TLS) id 15.1.106.15; Thu, 12 Mar 2015 02:09:32 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.01.0106.007; Thu, 12 Mar 2015 02:09:32 +0000 From: Praveen Sathyanarayan To: "Paul_Koning@Dell.com" , "ynir.ietf@gmail.com" Thread-Topic: [IPsec] Vendor Identifiers Thread-Index: AQHQXCzNM4G81UuM2EuvyhHFeRNuXZ0XywUAgAAlmQD//7T/gA== Date: Thu, 12 Mar 2015 02:09:31 +0000 Message-ID: References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/15.3.0.141024 x-originating-ip: [66.129.239.10] authentication-results: Dell.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO2PR05MB667; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(979002)(6009001)(51444003)(377454003)(479174004)(24454002)(46102003)(50986999)(86362001)(76176999)(83716003)(102836002)(87936001)(40100003)(99286002)(122556002)(77096005)(2501003)(62966003)(2950100001)(2900100001)(66066001)(36756003)(92566002)(2656002)(33656002)(83506001)(82746002)(19580405001)(77156002)(106116001)(54356999)(19580395003)(7059030)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR05MB667; H:CO2PR05MB665.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:CO2PR05MB667; BCL:0; PCL:0; RULEID:; SRVR:CO2PR05MB667; x-forefront-prvs: 05134F8B4F Content-Type: text/plain; charset="utf-8" Content-ID: <354E55E0EB9FCB40AC53CA71FCAEA7E3@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2015 02:09:31.5833 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR05MB667 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 02:09:37 -0000 DQoNCg0KDQoNCk9uIDMvMTEvMTUsIDExOjM4IFBNLCAiUGF1bF9Lb25pbmdARGVsbC5jb20iIDxQ YXVsX0tvbmluZ0BEZWxsLmNvbT4gd3JvdGU6DQoNCj5BcyBmb3IgYnVnZ3kgaW1wbGVtZW50YXRp b25zLCBJIHRoaW5rIHRoYXQgaXQgaXNu4oCZdCBuZWVkZWQgZm9yIHRoYXQuICBJZiANCj5zb21l b25lIGhhcyBhIGJ1ZyB0aGF0IGJyZWFrcyBpbnRlcm9wZXJhYmlsaXR5LCB3ZSB3b3VsZCBpbiBn ZW5lcmFsIHRha2UgDQo+dGhlIHZpZXcgb2Yg4oCcaWYgdGhleSBmaXggaXQsIGl0IHdpbGwgd29y a+KAnSDigJQgaW4gb3RoZXIgd29yZHMsIHZlbmRvcnMgDQo+bm9ybWFsbHkgZG9u4oCZdCB0YWtl IG9uIHRoZSBqb2Igb2Ygd29ya2luZyBhcm91bmQgc29tZW9uZSBlbHNl4oCZcyBtaXN0YWtlcy4N Cg0KSXQgcHJvYmFibHkgbm90IGp1c3QgZm9yIHdvcmsgYXJvdW5kIG9mIHNvbWVvbmUgZWxzZSBt aXN0YWtlLCBidXQgYWxzbyBmb3IgDQp5b3VyIG93biBpbXBsZW1lbnRhdGlvbiB0aGF0IGhhcyBi dWdzLiBFdmVuIHRob3VnaCBpc3N1ZSBpcyBmaXhlZCBpbiBuZXdlciANCnJlbGVhc2UsIGZvciBh IGxhcmdlIGN1c3RvbWVyLCBpdCBtYXkgdGFrZSB0byB0aW1lIHRvIHVwZ3JhZGUgdG8gbGF0ZXN0 IA0KdmVyc2lvbiwgYmFzZWQgb24gdGhlIHNpemUgb2YgdGhlIGRlcGxveW1lbnQuIEFzIGEgd29y ayBhcm91bmQsIHRvIA0KZmFjaWxpdGF0ZSBzb2Z0d2FyZSB1cGdyYWRlLCB2ZW5kb3ItaWQgdHJp Y2sgY291bGQgYmUgaWRlYWwuIEl0IGlzIGEgDQp0ZW1wb3Jhcnkgd29yayBhcm91bmQgYW5kIG5v dCBwZXJtYW5lbnQuIFRodXMgaW5jbHVkaW5nIGEgc29mdHdhcmUgdmVyc2lvbiANCmluIHZlbmRv ci1pZCB3b3VsZCBiZSBpZGVhbCBmb3Igc3VjaCBpc3N1ZS4gDQo= From nobody Thu Mar 12 07:02:54 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A041A0231 for ; Thu, 12 Mar 2015 07:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMqW-t-ldLUx for ; Thu, 12 Mar 2015 07:02:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A05E41A01EA for ; Thu, 12 Mar 2015 07:02:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CAF94E1B3; Thu, 12 Mar 2015 10:11:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 34C1E63784; Thu, 12 Mar 2015 10:02:50 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1BB2963770; Thu, 12 Mar 2015 10:02:50 -0400 (EDT) From: Michael Richardson To: Paul_Koning@Dell.com In-Reply-To: References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: ipsec@ietf.org, ynir.ietf@gmail.com Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:02:53 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable wrote: > As for buggy implementations, I think that it isn=E2=80=99t needed fo= r that. > If someone has a bug that breaks interoperability, we would in general > take the view of =E2=80=9Cif they fix it, it will work=E2=80=9D =E2= =80=94 in other words, > vendors normally don=E2=80=99t take on the job of working around some= one else=E2=80=99s > mistakes. Hahaha, that's really funny. I guess you don't need to interop with anything you didn't buy. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVQGch4CLcPvd0N1lAQLRdQf/SZSxw1/WTYjCATAfFenuOSTdUyHpz5dJ PlwqXM/1BtuLiRsl5SIXpfcOj9YXxbVXeMKHMZ1NEpJW1h0hzKUDbm78VeAIqQwq TBADXSUbeYCnnIgOKkzeZVoJK+7n8euFV5ygBxVa9/nj6mlt0yqDWQKiih+kJq/T 9r5c0yu/DDzl28Gv3wB/3+dETH1tnbsmH4woy6GXmdGzoKP3uj6bqcEt8xG5ewYT EJ4pGeB8u/fbxU7GHa7iAGxui475vW2vlu8qoph5i/GD/+VW7AAbxL5M+J36AHAh SNDpXiZ8AAmVnX1TV1/eJQ6LKCWk0opA8dkpdP8DH6ZabOrddNMLXw== =N60U -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 12 07:09:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9791A0383 for ; Thu, 12 Mar 2015 07:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYT2zeuTyK6O for ; Thu, 12 Mar 2015 07:08:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED841A0233 for ; Thu, 12 Mar 2015 07:08:58 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E8056E1B5; Thu, 12 Mar 2015 10:18:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 59C9D63784; Thu, 12 Mar 2015 10:08:57 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3D80363770; Thu, 12 Mar 2015 10:08:57 -0400 (EDT) From: Michael Richardson To: Russ Housley In-Reply-To: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 14:09:00 -0000 --=-=-= Content-Type: text/plain Russ Housley wrote: > About two years ago, I was at a workshop where someone claimed that the > Vendor Identifiers that are exchanged in IKE are very useful for > dealing with bugs. The claim was that following the report of a bug, > others could adjust their behaviors to avoid the circumstances that > enable the bug. In the worst case, they could refuse to talk to the > badly broken version, but accept connections to later versions where > the bug has been repaired. I'm surprised it was only two years ago. This is the argument that I made for VendorID with I wrote it up back in 1997. I invented this while working at SSH on the IKEv1 system there, and we did use it for short periods of time to work around things we couldn't fix without a flag day. I agree that this hasn't gotten much use by the "major" VPN vendors, and I note that we still have code to work around their bugs, and those bugs often are still seen in the field on a regular basis. The vendor ID string is supposed to be opaque and seemingly random. The VendorID was then also used to qualify use of private use types. I'm sad that the audit people think that knowing the version enables attacks, as opposed to: knowing the version enables one to proactively repair things. It seems like an argument for classifying encryption algorithms to me. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVQGd9oCLcPvd0N1lAQJReQf/fdu9jxX+sxEBsMDOHc3o0Pd0tqidyzuG HgPrM4zpkRQDXgESvN07nM2CLohY/6L0//6CDioWvV36lg8lbTrNFfpU+xeJ8DmD kAY5OLTAzI2c6qrS7t/eBwca7ji9eYqemPNh+cPuYejLEUKQjS+JUM60WDmxkYH7 46m8rSllwTDnLLFjAj6qF1F/ZoAkwWcr3LMciZuwsja4rXz73Tsrpt3bygBiQT/R nN7LsvQpXQ8TDqD15ONvm2woAGd0yjlwNyZHIi/pqG3XMh6JMqOSX6HjFf7tKSkF lfZtjr3hm4oNMNqSWfy199pRCK22wkyXof987mpf3LJY2Iag8Us/iA== =qCwf -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 12 08:20:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 465AC1A8880 for ; Thu, 12 Mar 2015 08:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M-xeNNWNC5S for ; Thu, 12 Mar 2015 08:20:29 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4991A885F for ; Thu, 12 Mar 2015 08:20:27 -0700 (PDT) Received: by widem10 with SMTP id em10so33887219wid.2 for ; Thu, 12 Mar 2015 08:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NkZBmftwGDu/fXNC4gVFWxFdqQujQ1SJSptYJD0zeWk=; b=g/4W6QbFQDOSz/7ObFKaLXXRZrph4NRAzOKaGFODhiR6U7UheUiqOC2VSotfjdmnZx /Q+P760R7FnygNp/MuymEjfC0kAyoX1Ui4kdzhOY9/t1lFE0EFF3jIEwh2NXFFwhDnwD O4Dd1YJWSN65I6LH8iUuR5L3yDzPW33S6azzpmbo+Tfckn+57bhEdPIfrVfz5GwrSLV9 YvcGyw/TXP7BQkxePuHmZtuC1RS2f98gZ7O4vEtTJ1nuBOy0aVoOBzTEjV+I7fOJw4xx WllCAeR3Pm5Pn7Kts4HB+Vdv2lYuB0mF90Fqc5+SoHRmjYeBczh2+rnv9LciFk1HR5Pn 09Hw== X-Received: by 10.180.218.71 with SMTP id pe7mr117236753wic.70.1426173626567; Thu, 12 Mar 2015 08:20:26 -0700 (PDT) Received: from [172.24.249.226] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id vq9sm10530122wjc.6.2015.03.12.08.20.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 08:20:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 12 Mar 2015 17:20:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <86AC7585-93BD-456D-B75E-F85D2D2A2D7F@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for WG adoption: draft-nir-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 15:20:31 -0000 > On Mar 6, 2015, at 6:01 PM, Paul Hoffman = wrote: >=20 > On Feb 26, 2015, at 2:11 PM, Paul Hoffman = wrote: >> Greetings again. A few people have expressed interest in having = https://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305 as a WG = item for IPsecME. If you want this as a WG document, and you are willing = to review drafts as they move through, please say so on this thread. If = you are opposed to this being a WG document, please say so (and say = why). Thanks in advance. >=20 > This got very little interest, which surprised me. Without a few more = people who will commit to review the document and offer comments, we = can't really call it a WG work item. Is there really so little interest = in new algorithms that are being adopted in other protocols? >=20 > If you are an IPsec implementer, it would be very useful to know = whether or not you would support adding this algorithm to your = implementation, and why. Counting both threads, we=E2=80=99ve seen support from MCR, Tero, Paul = W, Valery, and Jim Knowles. Together with me this represents at least 5 = independent implementations. I think this should be enough for algorithms that some are suggesting = should be the MTI for TLS 1.3 ([1]), and where the algorithms themselves = can be considered =E2=80=9Cvetted=E2=80=9D. I know TLS is a different = protocol, but there=E2=80=99s no real difference in the way IPsec and = TLS use symmetric crypto. Yoav [1] http://www.ietf.org/mail-archive/web/tls/current/msg15452.html= From nobody Thu Mar 12 23:51:52 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5275E1A8A7F for ; Thu, 12 Mar 2015 23:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBptFEkIIjcd for ; Thu, 12 Mar 2015 23:51:50 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE55D1A8A79 for ; Thu, 12 Mar 2015 23:51:49 -0700 (PDT) Received: by lbvp9 with SMTP id p9so20807451lbv.8 for ; Thu, 12 Mar 2015 23:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=hr+PFjh/k9wSS/BfciGCY5BXGu/dzsYxbBq8qeCfN3s=; b=tMNKHwLOhKuqC17Ngh1tN69V3Ou0yfxT3M02TlrCb80jVhVYc7VtCozATQr+kQS6Km HiIyizwDdpsobaseWhWCndGICPLK6wAbaU9Dcc19T6ScD6N9fSTgaR+PVg9wtKOA7BCF gbKXJ2ZjNYCvFUgzmy8oMP9ExFVq6OvGo/7MSNU5M6x+Z04GVZjty2vGNet7BOd5BxF8 9NJCSEE/0UTpwIm9m9MlaSQ4ZPpklEG5pl38aiN9CMm0CdtLQu4C1Dj7iklXo+YNODJY B02ZWLLr6W38N0iHJr8wSWzsLdtW8Cw/6ktKkA6FRCSUHNVvXPJfcnY52qthGz6imfTG mOaw== X-Received: by 10.112.201.231 with SMTP id kd7mr21489477lbc.35.1426229508386; Thu, 12 Mar 2015 23:51:48 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id ao5sm206155lac.48.2015.03.12.23.51.47 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Mar 2015 23:51:47 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Russ Housley" , "IETF IPsec" References: <867FB98D-FE63-47FA-A3AC-4B749F2D1B94@vigilsec.com> Date: Fri, 13 Mar 2015 09:51:29 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Vendor Identifiers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 06:51:51 -0000 Hi Russ, it is not exactly as you described, but very close. When RFC is unclear fifferent vendors treat it differently. IKEv1 had quite a lot of moot places, much fewer are in IKEv2. Anyway, when you try to interoperate you sometimes encounter a situation when your peer behaves very-very strange in some cases (from you point of view, of course). Let's not call it a bug, but more mildly - a feature. Anyway, if interoperability is broken, major vendors might not care, but smaller vendors have to deal with it. And in this situation Vendor Identifiers (and any other information that could help indentify the peer) are really used to adjust your behaviour to get interoperability. Regards, Valery Smyslov. > About two years ago, I was at a workshop where someone claimed that the > Vendor Identifiers that are exchanged in IKE are very useful for dealing > with bugs. The claim was that following the report of a bug, others could > adjust their behaviors to avoid the circumstances that enable the bug. In > the worst case, they could refuse to talk to the badly broken version, but > accept connections to later versions where the bug has been repaired. > > Does anyone have operation experience doing this kind of thing? I want to > know if is real experience or speculation about what could be done. > > Thanks in advance, > Russ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Mar 14 08:11:39 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356D81A8965; Fri, 13 Mar 2015 10:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.01 X-Spam-Level: X-Spam-Status: No, score=-5.01 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5xQ1Jp5BPXN; Fri, 13 Mar 2015 10:11:39 -0700 (PDT) Received: from emvm-gh1-uea08.nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id 135771A8A9A; Fri, 13 Mar 2015 10:11:33 -0700 (PDT) X-TM-IMSS-Message-ID: <8a06fd0800122d48@nsa.gov> Received: from MSHT-GH1-UEA01.corp.nsa.gov (msht-gh1-uea01.corp.nsa.gov [10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 8a06fd0800122d48 ; Fri, 13 Mar 2015 13:11:26 -0400 Received: from MSMR-GH1-UEA08.corp.nsa.gov (10.215.225.3) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.2.347.0; Fri, 13 Mar 2015 13:11:31 -0400 Received: from MSMR-GH1-UEA04.corp.nsa.gov ([10.215.228.141]) by MSMR-GH1-UEA08.corp.nsa.gov ([10.215.225.3]) with mapi id 14.02.0347.000; Fri, 13 Mar 2015 13:11:30 -0400 From: "Boyle, Vincent M" To: "'saag@ietf.org'" Thread-Topic: looking to hold a TLS VPN side meeting at IETF 92 Thread-Index: AdBdsL81XCyfXC5pQPeZlyI69acR3g== Date: Fri, 13 Mar 2015 17:11:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.225.46] Content-Type: multipart/alternative; boundary="_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Sat, 14 Mar 2015 08:11:38 -0700 Cc: "'ipsec@ietf.org'" , "'tls@ietf.org'" Subject: [IPsec] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 17:11:43 -0000 --_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I'm planning to hold a side meeting at IETF 92 to gauge int= erest in creating a standard for TLS VPNs. One motivating use case for my o= rganization is the need to protect data between an app on a mobile device = and the enterprise network that it connects to. For many of our customers,= a TLS-based solution is preferable to IPSec (perhaps because their vendors= support the former). For some sensitive military applications, there is a = requirement to provide two layers of encryption, so using TLS for the secon= d layer makes sense. Having each app invoke TLS is problematic because it i= ntroduces validation costs for each app before it is deployed (to ensure th= at it correctly implements TLS or makes the appropriate OS calls). We would= prefer the option of validating a TLS VPN product and having it available = for use by all apps on the device. To create the necessary validation requi= rements and test activities, we need to have a standard that we can point t= o. The development of an open standard would provide a consistent and fair= method of measuring security (using Protection Profiles) which scales to e= nable the validation and testing of TLS VPNs. Beyond this specific (but fairly pressing) use case, we bel= ieve that there are many organizations that would benefit from the availabi= lity of a standards-based, validated mechanism to protect communications be= tween their mobile devices and the enterprise network. Please discuss on the saag mail list. I will schedule a me= eting time at a local drinking establishment for either Monday or Wednesday= at 7:30 PM (local Dallas time). I'd appreciate feedback on the meeting tim= es (if you expect to attend) as well as any comment on the usefulness or fe= asibility of this effort. Thanks, Mike Boyle Standards Lead Information Assurance Directorate, NSA --_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

        &nbs= p;       I’m planning to hold a side me= eting at IETF 92 to gauge interest in creating a standard for TLS VPNs. One= motivating use case for my organization is the need to  protect data = between an app on a mobile device and the enterprise network that it connects to.  For many of our customers, a TLS-based = solution is preferable to IPSec (perhaps because their vendors support the = former). For some sensitive military applications, there is a requirement t= o provide two layers of encryption, so using TLS for the second layer makes sense. Having each app invoke TLS is = problematic because it introduces validation costs for each app before it i= s deployed (to ensure that it correctly implements TLS or makes the appropr= iate OS calls). We would prefer the option of validating a TLS VPN product and having it available for use= by all apps on the device. To create the necessary validation requirements= and test activities, we need to have a standard that we can point to. &nbs= p;The development of an open standard would provide a consistent and fair method of measuring security (using Pr= otection Profiles) which scales to enable the validation and testing of TLS= VPNs.

 

        &nbs= p;       Beyond this specific (but fairly pre= ssing) use case, we believe that there are many organizations that would be= nefit from the availability of a standards-based, validated mechanism to pr= otect communications between their mobile devices and the enterprise network.

 

        &nbs= p;       Please discuss on the  saag mai= l list. I will schedule a meeting time at a local drinking establishment fo= r either Monday or Wednesday at 7:30 PM (local Dallas time). I’d appr= eciate feedback on the meeting times (if you expect to attend) as well as any comment on the usefulness or feasibility = of this effort.

 

Thanks,

Mike Boyle

Standards Lead

Information Assurance Directorate, NSA

--_000_E18BF42C3D667642ABC0EF4B6064EB67D0918938MSMRGH1UEA04cor_-- From nobody Sat Mar 14 11:21:42 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44271A00EF; Sat, 14 Mar 2015 11:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY16nLt8tbbQ; Sat, 14 Mar 2015 11:21:38 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F8971A00C8; Sat, 14 Mar 2015 11:21:38 -0700 (PDT) Received: by wixw10 with SMTP id w10so11399445wix.0; Sat, 14 Mar 2015 11:21:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=HCkgWH9OcYpZ+v8LcK8G6NZ5+Ccwc7sz1b6y6K+rqN4=; b=KcGVOmA90gwS+xsK53RbuD/AhMLbwk4/Ny+P5XNVgrqj8IJjdMVNnWaW5R4qziQLEg aYAiYL3yEvUsdIGUND1M5srU07gqiXVzFEb1IQPiBbDT5qsSIITqfPQCBnkVdkXf5ZgH HgTQ0UQSQHt71nXuzHq5loUrm4P/y2lNAXIZqupF4pUVQrtu7JzPbbyPCipNSx87OLUV Zid0sSgVCFCrgY4Em3j6VU4FbhsyAE4phB74uIVaj8+t/Wt241cdoe072yUH9oiodPUA s5Iz2LsGq1KMhwg5iKzTYR1bz18mdGQlLwFEVajW2wKeozRFingjYW55IebWlLmB+RzY A4vQ== X-Received: by 10.180.98.67 with SMTP id eg3mr40191276wib.11.1426357297004; Sat, 14 Mar 2015 11:21:37 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by mx.google.com with ESMTPSA id ka1sm7996177wjc.2.2015.03.14.11.21.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Mar 2015 11:21:36 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sat, 14 Mar 2015 20:21:34 +0200 Message-Id: References: To: "Boyle, Vincent M" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ipsec@ietf.org" , Security Area Advisory Group , "tls@ietf.org" Subject: Re: [IPsec] [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 18:21:39 -0000 --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Mike > Please discuss on the saag mail list. I will schedule = a meeting time at a local drinking establishment for either Monday or = Wednesday at 7:30 PM (local Dallas time). I=E2=80=99d appreciate = feedback on the meeting times (if you expect to attend) as well as any = comment on the usefulness or feasibility of this effort. On Wednesday there is going to be a I2NSF side meeting that is likely to = attract many of the same people. I would go with Monday. Yoav= --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Mike

      =           Please discuss on the  saag mail = list. I will schedule a meeting time at a local drinking establishment = for either Monday or Wednesday at 7:30 PM (local Dallas time). I=E2=80=99d= appreciate feedback on the meeting times (if you expect to attend) as = well as any comment on the usefulness or feasibility of this = effort.

On Wednesday there is going to be a = I2NSF side meeting that is likely to attract many of the same people. I = would go with Monday.

Yoav
= --Apple-Mail=_F704F348-AB4A-4A80-B0EB-8D23AC87B890-- From nobody Sat Mar 14 12:47:54 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67A71A0204; Sat, 14 Mar 2015 12:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFumaO-AK18y; Sat, 14 Mar 2015 12:47:51 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1FE1A0194; Sat, 14 Mar 2015 12:47:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EF90120012; Sat, 14 Mar 2015 15:57:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7D49263784; Sat, 14 Mar 2015 15:47:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 67D48636B6; Sat, 14 Mar 2015 15:47:49 -0400 (EDT) From: Michael Richardson To: "Boyle\, Vincent M" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: "'ipsec@ietf.org'" , "'saag@ietf.org'" , "'tls@ietf.org'" Subject: Re: [IPsec] [saag] looking to hold a TLS VPN side meeting at IETF 92 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2015 19:47:53 -0000 --=-=-= Content-Type: text/plain I sure hope that you will give us a definition of a TLS VPN. It's really important that we know what is in scope and what is not. My take is that solutions that run TCP and/or HTTPS proxy over TLS, are not TLS VPNs, because they don't pass the "N"etwork part of VPN. They are useful mechanisms, and I'm all for standardizing them, but the word VPN should not be applied. OpenVPN is a TLS keyed VPN. It can and does run over a single TCP port, but that has congestion issues (tcp over tcp), so running the data part it over UDP is preferrale, but not always possible. (Meanwhile,there are IPsec vendors that run ESP over TCP in non-standard fashions...) I'd like to see some convergence at the dataplane side. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVQSQZYCLcPvd0N1lAQJyIAf/c7X5sxRvcVQgaY2Lll11d8IxEFqh0/q3 U/dBnT6EJHW4h6g1rRlqVFmFyUPXSwqZZiPvSfG1s1bE2ew4Q7k9Fspj1sbUGBL5 U294sZpxCeCrSBUhnqH/nopap5hReAU54VgEjlEebmn8PGHuNn7y537+tIq09yQM os+uIf/O1OAgTwcX8WzYMg4BQuUb7hQqA21JzENeBSxsYgim4aPKAQXCu3krlguz ZTXSH+7Bkne/z/6PhHkdqg7BpDhPgxqZwT/rmrmmAAJu0a5Ou5iQdaa+HWgPZibe 6QIMS/9Ah0TBFjrT3MJ/EoR1cLoU/GTZvA3xM6rcDsY/7Bvkigieig== =7djO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 16 16:37:40 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9FD31ACD40 for ; Mon, 16 Mar 2015 16:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t094ybqTT0gi for ; Mon, 16 Mar 2015 16:37:38 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id C699E1ACD3D for ; Mon, 16 Mar 2015 16:37:38 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A383E1FE01EA; Mon, 16 Mar 2015 16:37:38 -0700 (PDT) Received: from 104.36.248.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 16 Mar 2015 16:37:38 -0700 (PDT) Message-ID: Date: Mon, 16 Mar 2015 16:37:38 -0700 (PDT) From: "Dan Harkins" To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: draft-mglt-6lo-aes-implicit-iv.all@tools.ietf.org Subject: [IPsec] everything old is new again X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:37:39 -0000 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's because CCM and GCM were not designed yet). Why is this a good idea now? The "unpredictable"-ness of an IV for CBC mode addresses a chosen plaintext attack that would otherwise reduce CBC mode down to ECB mode (and enable a codebook attack). I _think_ the draft addresses this because the IV ends up being secret but that requires reading a bit into section 4. Namely, does one take the "clear text payload" as plaintext and the "dedicated 16 byte key" as the key for a single ECB-style encryption using AES? It says there's a payload and a key and it says AES is used as a PRP but no normative text to say exactly what to do to get this IV. Also, if that is the way the IV is (secretly) generated then does this propose using a 128-bit IV, the block length of AES, for GCM? Most implementations use the default 96-bit IV so does this implicit construction imply some kind of concatenation or does it propose to use a 128-bit IV with GCM? SP 800-38D describes an RBG-based IV construction, is that what this draft is doing? As an aside, the Security Considerations of this draft need work. It says that IV generation "has been left to the implementation as long as certain security requirements are met." What are they? Do the different modes have different requirements? Are these requirements met by this draft? If so, how? regards, Dan. From nobody Mon Mar 16 17:03:11 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53851ACD50 for ; Mon, 16 Mar 2015 17:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkpj818_L8jf for ; Mon, 16 Mar 2015 17:03:08 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF521ACD4E for ; Mon, 16 Mar 2015 17:03:08 -0700 (PDT) Received: by lamx15 with SMTP id x15so53917050lam.3 for ; Mon, 16 Mar 2015 17:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+lINVJ+TZNLJ8G+wqxHLTfzhU4c84F7RouYexRWQ+Ek=; b=spO+ujoKY3OChH8EuIFM/S34K7VbgRooSF8zku9dA42j2RXpFEf/vIaYgl29dY81KA SLfjIC1qCqcj2AhLcuEuId42+y2OxRh16isl/5W0hixVW0PaxqMcON1LsMfbhmjvt/My 6GoPePV1y+mpnQSuaqaUmPIoq+Y8+Uco9uQfKZa3hDvzB/aAKHQttpakFczU9bMJ/tBm k01SzDI92E57PIMffPi0TrCmtWHGe0IQPJRqu/29pDVv5QTCqDKRsuDIHjKBKx+IKXvg rdG+oyGxGMxTHH1H7bTDvxioGfNag+eKRxVpr1YtqEHdD537hqxGpmxQ6H7xOOfG51kY nHTA== MIME-Version: 1.0 X-Received: by 10.152.178.197 with SMTP id da5mr59031555lac.56.1426550586666; Mon, 16 Mar 2015 17:03:06 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Mon, 16 Mar 2015 17:03:06 -0700 (PDT) Date: Mon, 16 Mar 2015 20:03:06 -0400 Message-ID: From: Kathleen Moriarty To: "ipsec@ietf.org" Content-Type: multipart/alternative; boundary=001a11340c68f8f6b0051170b0f1 Archived-At: Subject: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 00:03:10 -0000 --001a11340c68f8f6b0051170b0f1 Content-Type: text/plain; charset=UTF-8 Hello, Thank you for your work on draft-ietf-ipsecme-ikev2-null-auth, it's great to see progress on OS in protocols. I have a nit and a couple of comments/questions before we progress the draft. Comments & questions: Security Considerations: The following sentence may ned a little work: Implementations might have made assumptions that are no longer valid. I assume this is referring to the assumption that one would only want authenticated sessions to preventing man-in-the-middle attacks. It could be read as the assumptions being that we are fine with main-in-the-middle attacks now, as opposed to we now understand the need for additional use cases to support both authenticated and unauthenticated sessions. How about the following (assuming I'm making the right assumption about your assumptions ;-) ): Implementations might have made assumed there were no scenarios where a connection without authentication would be desired, which is no longer valid. Section 3.1 Shouldn't this new requirement only apply to unauthenticated sessions? Wouldn't requirements for existing authenticated sessions remain in terms of audit capabilities and logging? This should be made clear to help implementers. Nits: Section 2.3, first sentence of last paragraph: Implementations should weight the resource consumption of sending s/weight/weigh/ Thanks. -- Best regards, Kathleen --001a11340c68f8f6b0051170b0f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thank you for your work on=C2=A0= draft-iet= f-ipsecme-ikev2-null-auth, it's great to see progress on OS in protocol= s.=C2=A0 I have a nit and a couple of comments/questions before we progress= the draft.


Comments & questions:

Security Considerations:

The following sentence may ned a little work:
=

   Implementations might have made
   assumptions that are no longer valid. 

I assume this is referring to the as=
sumption that one would only want authenticated sessions to preventing man-=
in-the-middle attacks.  It could be read as the assumptions being that we a=
re fine with main-in-the-middle attacks now, as opposed to we now understan=
d the need for additional use cases to support both authenticated and unaut=
henticated sessions.

How about the following (assuming I'm making the righ=
t assumption about your assumptions ;-) ):

   Implementations might have made
   assumed there were no scenarios where a connection without authenticatio=
n would be desired, which is no longer valid. 


Section 3.1
 Shouldn't this ne=
w requirement only apply to unauthenticated sessions?  Wouldn't require=
ments for existing authenticated sessions remain in terms of audit capabili=
ties and logging?  This should be made clear to help implementers.


Nits:
Section 2.3, first sentence of last paragraph:
Im=
plementations should weight the resource consumption of sending
s/weight/weigh/=



Thanks.


<= /div>--

Best r= egards,
Kathleen
--001a11340c68f8f6b0051170b0f1-- From nobody Mon Mar 16 17:10:51 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF821ACD78 for ; Mon, 16 Mar 2015 17:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxId4_FjztyZ for ; Mon, 16 Mar 2015 17:10:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60241A1BE3 for ; Mon, 16 Mar 2015 17:10:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l5Zdz03V0z7WH; Tue, 17 Mar 2015 01:10:47 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass reason="1024-bit key; unprotected key" header.d=nohats.ca header.i=@nohats.ca header.b=icxD927w; dkim-adsp=pass X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id MIyjr_66Hn-l; Tue, 17 Mar 2015 01:10:46 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 17 Mar 2015 01:10:46 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 97CAD819A0; Mon, 16 Mar 2015 20:10:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426551045; bh=Eo7COLkZlY9Fhq65U1aBnjtipvisIeWaALBn+Gz4pqw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=icxD927wdeqYLlQFbzL8XL8Ic0JziHJJRNuyE34hYBaQY4UHMY5agcwHr1B9F8P7Q nzKnj0BMRUepU0x5tJEvziKyWjt9mOMsKD32l2YcwOWNQ/RrSSbK6vKth8IRwIvVVV bZE5yQn0OWiKJXN7aSUlwqxlAdzhWyw0uAabussI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2H0Aj1u019827; Mon, 16 Mar 2015 20:10:45 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 16 Mar 2015 20:10:45 -0400 (EDT) From: Paul Wouters To: Kathleen Moriarty , Valery Smyslov In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 00:10:50 -0000 On Mon, 16 Mar 2015, Kathleen Moriarty wrote: > The following sentence may ned a little work: > > Implementations might have made > assumptions that are no longer valid. > I assume this is referring to the assumption that one would only want authenticated sessions to preventing man-in-th > e-middle attacks. It could be read as the assumptions being that we are fine with main-in-the-middle attacks now, a > s opposed to we now understand the need for additional use cases to support both authenticated and unauthenticated s > essions. > How about the following (assuming I'm making the right assumption about your assumptions ;-) ): > Implementations might have made > assumed there were no scenarios where a connection without authentication would be desired, which is no longer va > lid. We actually meant the assumption that you "know who is connecting to you" because they authenticate. And by authenticating, it means you have a way to address abusive behaviour or the client - as in you probably know where they live :) With auth_null, these people are untracable strangers. > Section 3.1 > Shouldn't this new requirement only apply to unauthenticated sessions? Wouldn't requirements for existing authenti > cated sessions remain in terms of audit capabilities and logging? This should be made clear to help implementers. Would this work: old: An established IKE session [...] new: An established IKE session using AUTH_NULL [...] > Nits: > Section 2.3, first sentence of last paragraph: > Implementations should weight the resource consumption of sending > s/weight/weigh/ Will fix, thanks! Paul From nobody Mon Mar 16 17:15:18 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB1E1ACD80 for ; Mon, 16 Mar 2015 17:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07Pq28aqwnyA for ; Mon, 16 Mar 2015 17:15:14 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522A21ACD83 for ; Mon, 16 Mar 2015 17:15:09 -0700 (PDT) Received: by lbcds1 with SMTP id ds1so42203370lbc.3 for ; Mon, 16 Mar 2015 17:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zxeZ3oUaDEucaxcEFRTVbKkaUrD0MByGd/vpqKg6mnY=; b=sBYDow94/N669GktP82UaCaQ2ewyAHM1AvmDuHKobC6Og17c2myWx154nF1QwUyNrM BYwhct9r3Uq0h70SXXKslimpay+IDeB3O3KO1OEl4ul2H+fTFGHVlRmc0ivR2NbgiJBC ShShPSGfkUGsIBB1UBHC1ec6NXYsF8bTCRBdbaCpAcAR/T4Y18y3bJtrS+/izI9dXjMu Brnen88RVU+qoAqsExyAgwleq+H52SMLFZsGSof8rNgKcN7mB16FXp4ZgyvfZm+aW4Z0 TSnkiB0kYNP6jkXgNSIInhYNl08tu7jbs2wfjF8mO7IQsYTR2XtEb+w6RchlagyJepNQ BSDw== MIME-Version: 1.0 X-Received: by 10.152.179.68 with SMTP id de4mr43403003lac.65.1426551307869; Mon, 16 Mar 2015 17:15:07 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Mon, 16 Mar 2015 17:15:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 20:15:07 -0400 Message-ID: From: Kathleen Moriarty To: Paul Wouters Content-Type: multipart/alternative; boundary=001a11342ef2f5a49c051170db8b Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 00:15:16 -0000 --001a11342ef2f5a49c051170db8b Content-Type: text/plain; charset=UTF-8 Thanks for the quick response! Inline. On Mon, Mar 16, 2015 at 8:10 PM, Paul Wouters wrote: > On Mon, 16 Mar 2015, Kathleen Moriarty wrote: > > The following sentence may ned a little work: >> >> Implementations might have made >> assumptions that are no longer valid. I assume this is referring to >> the assumption that one would only want authenticated sessions to >> preventing man-in-th >> e-middle attacks. It could be read as the assumptions being that we are >> fine with main-in-the-middle attacks now, a >> s opposed to we now understand the need for additional use cases to >> support both authenticated and unauthenticated s >> essions. >> How about the following (assuming I'm making the right assumption about >> your assumptions ;-) ): >> Implementations might have made >> assumed there were no scenarios where a connection without >> authentication would be desired, which is no longer va >> lid. >> > > We actually meant the assumption that you "know who is connecting to > you" because they authenticate. And by authenticating, it means you > have a way to address abusive behaviour or the client - as in you > probably know where they live :) > > With auth_null, these people are untracable strangers. Ok, can you update the text with the assumption you meant? Thanks! > > > Section 3.1 >> Shouldn't this new requirement only apply to unauthenticated sessions? >> Wouldn't requirements for existing authenti >> cated sessions remain in terms of audit capabilities and logging? This >> should be made clear to help implementers. >> > > Would this work: > > old: > > An established IKE session [...] > > new: > > An established IKE session using AUTH_NULL [...] Yes, thanks. That helps and is that what the WG had agreed upon or was it not discussed? > > > Nits: >> Section 2.3, first sentence of last paragraph: >> Implementations should weight the resource consumption of sending >> s/weight/weigh/ >> > > Will fix, thanks! Thank you! > > > Paul > -- Best regards, Kathleen --001a11342ef2f5a49c051170db8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the quick response!=C2=A0 Inline.

On Mon, Mar 16, 2015 at 8:10 PM= , Paul Wouters <paul@nohats.ca> wrote:
On Mon, 16 Mar 2015, Kathleen Moriarty wrote:
The following sentence may ned a little work:

=C2=A0 =C2=A0Implementations might have made
=C2=A0 =C2=A0assumptions that are no longer valid. I assume this is referri= ng to the assumption that one would only want authenticated sessions to pre= venting man-in-th
e-middle attacks.=C2=A0 It could be read as the assumptions being that we a= re fine with main-in-the-middle attacks now, a
s opposed to we now understand the need for additional use cases to support= both authenticated and unauthenticated s
essions.
How about the following (assuming I'm making the right assumption about= your assumptions ;-) ):
=C2=A0 =C2=A0Implementations might have made
=C2=A0 =C2=A0assumed there were no scenarios where a connection without aut= hentication would be desired, which is no longer va
lid.

 We actually meant the assumption that you "know who is connecting to you" because they authenticate. And by authenticating, it means you have a way to address abusive behaviour or the client - as in you
probably know where they live :)

With auth_null, these people are untracable strangers.
Ok, can you update the text with the assumption you meant?=C2= =A0 Thanks!


Section 3.1
=C2=A0Shouldn't this new requirement only apply to unauthenticated sess= ions?=C2=A0 Wouldn't requirements for existing authenti
cated sessions remain in terms of audit capabilities and logging?=C2=A0 Thi= s should be made clear to help implementers.

 Would this work:

old:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 An established IKE session [...]

new:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 An established IKE session using AUTH_NULL [...= ]

Yes, thanks.=C2=A0 That helps and is that= what the WG had agreed upon or was it not discussed?=C2=A0


Nits:
Section 2.3, first sentence of last paragraph:
Implementations should weight the resource consumption of sending
s/weight/weigh/

 Will fix, thanks!

Thank you!=C2=A0
=

Paul



--

Best regards,
Kathleen
--001a11342ef2f5a49c051170db8b-- From nobody Mon Mar 16 19:49:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356211A914B for ; Mon, 16 Mar 2015 19:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHiFTjBolkag for ; Mon, 16 Mar 2015 19:48:58 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id AFD811A9131 for ; Mon, 16 Mar 2015 19:48:58 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D29341FE01EA; Mon, 16 Mar 2015 19:48:57 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 16 Mar 2015 19:48:58 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Mon, 16 Mar 2015 19:48:58 -0700 (PDT) From: "Dan Harkins" To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: draft-mglt-6lo-aes-implicit-iv.all@tools.ietf.org Subject: Re: [IPsec] everything old is new again X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 02:49:00 -0000 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, > > 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's because CCM and GCM were not designed yet). Why is > this a good idea now? > > The "unpredictable"-ness of an IV for CBC mode addresses a > chosen plaintext attack that would otherwise reduce CBC mode > down to ECB mode (and enable a codebook attack). I _think_ > the draft addresses this because the IV ends up being secret > but that requires reading a bit into section 4. Namely, does one > take the "clear text payload" as plaintext and the "dedicated 16 > byte key" as the key for a single ECB-style encryption using AES? > It says there's a payload and a key and it says AES is used as > a PRP but no normative text to say exactly what to do to get > this IV. > > Also, if that is the way the IV is (secretly) generated then does > this propose using a 128-bit IV, the block length of AES, for GCM? > Most implementations use the default 96-bit IV so does this > implicit construction imply some kind of concatenation or does > it propose to use a 128-bit IV with GCM? SP 800-38D describes > an RBG-based IV construction, is that what this draft is doing? > > As an aside, the Security Considerations of this draft need work. > It says that IV generation "has been left to the implementation as > long as certain security requirements are met." What are they? Do > the different modes have different requirements? Are these > requirements met by this draft? If so, how? > > regards, > > Dan. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Mar 17 06:26:16 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9221B1A0AF1 for ; Tue, 17 Mar 2015 06:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynygdrKWRJf3 for ; Tue, 17 Mar 2015 06:26:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D271A066B for ; Tue, 17 Mar 2015 06:26:11 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2HDQ64S013469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 Mar 2015 15:26:06 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2HDQ6CN026565; Tue, 17 Mar 2015 15:26:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21768.11118.578977.23100@fireball.kivinen.iki.fi> Date: Tue, 17 Mar 2015 15:26:06 +0200 From: Tero Kivinen To: Kathleen Moriarty In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 39 min X-Total-Time: 10 min Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 13:26:14 -0000 Kathleen Moriarty writes: > Section 3.1 > =A0Shouldn't this new requirement only apply to unauthenticat= ed > sessions=3F=A0 Wouldn't requirements for existing authenti > cated sessions remain in terms of audit capabilities and logg= ing=3F=A0 > This should be made clear to help implementers. >=20 > Would this work: > =20 > old: > =20 > =A0 =A0 =A0 =A0 An established IKE session [...] > =20 > new: > =20 > =A0 =A0 =A0 =A0 An established IKE session using AUTH=5FNULL [...= ] >=20 > Yes, thanks.=A0 That helps and is that what the WG had agreed upon or= was it > not discussed=3F=A0 The IKE sessions using AUTH=5FNULL is subset of IKE sessions, and as only that subset can have sessions which do not have verifiable entity, the statement is still true if we add "using AUTH=5FNULL". On the other hand the architectural change this draft does is that now IKE sessions might not have verifiable authenticated entity associated with it anymore, and that means the meaning of IKE sessions is changed.=20 The rest of the section is talking about assumptions for IKE sessions in general, i.e. originally when you could not have unauthenticated IKE sessions, your implementation might have assumed that certain level of trust can be put on the information you receive from the other end. Those assumptions might not be valid anymore when unauthenticated IKE sessions are added. Those assumptions needs to be verified for all IKE sessions, i.e. if it matters whether the IKE session is unauthenticated or not, then specific checks needs to be added that IKE session is properly authenticated before trusting information. So I think it would be better to keep the original version talking about IKE sessions in general, and not limiting it only to AUTH=5FNULL cases, as implementations need to verify all cases where it make assumptions about IKE sessions and peers associated to it.=20 --=20 kivinen@iki.fi From nobody Tue Mar 17 12:20:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6B61A888F for ; Tue, 17 Mar 2015 12:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y5DW70edims for ; Tue, 17 Mar 2015 12:19:57 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5118E1A8888 for ; Tue, 17 Mar 2015 12:19:57 -0700 (PDT) Received: by labjg1 with SMTP id jg1so17509064lab.2 for ; Tue, 17 Mar 2015 12:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ap/djZ6Z/PH8iMvdPRYZf6rne+EUGEbQKnEuYAFHc6c=; b=nVsthN6uJYT20YF7UTQdeQvM/tt7Z3X6QS+EA9YnhDUjHQj/SbUUgVonNcd3uDJWpN Ud6/C4/cVkSWu/YymU2rwGojYgjobzp+35R36PplZppaf6AAtjjj57yj6KId6ZYk64zN /T472/rTfCgeNJzjOF3M56/x4QF2IDsHnfSEbI2Ys17q1yOlsn/ClzyJTutoaeuiTrts yBITEKYNeskXLq1OZqESTlbFhON0g5dtnnLxmq7bqNSwfbveEMhFggBf7n0N/LHzJDV4 /eSshZFfhEoNRYYyFCiqtt5gusVZKKpJ5yxY6m/ypYXTuPDxmHvC68HH67f9bm6DNYTI sXiQ== MIME-Version: 1.0 X-Received: by 10.152.179.68 with SMTP id de4mr47117414lac.65.1426619995832; Tue, 17 Mar 2015 12:19:55 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 17 Mar 2015 12:19:55 -0700 (PDT) In-Reply-To: <21768.11118.578977.23100@fireball.kivinen.iki.fi> References: <21768.11118.578977.23100@fireball.kivinen.iki.fi> Date: Tue, 17 Mar 2015 15:19:55 -0400 Message-ID: From: Kathleen Moriarty To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11342ef214c7d3051180da07 Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 19:20:00 -0000 --001a11342ef214c7d3051180da07 Content-Type: text/plain; charset=UTF-8 Hi Tero, Thanks for your response, just one question inline. On Tue, Mar 17, 2015 at 9:26 AM, Tero Kivinen wrote: > Kathleen Moriarty writes: > > Section 3.1 > > Shouldn't this new requirement only apply to unauthenticated > > sessions? Wouldn't requirements for existing authenti > > cated sessions remain in terms of audit capabilities and > logging? > > This should be made clear to help implementers. > > > > Would this work: > > > > old: > > > > An established IKE session [...] > > > > new: > > > > An established IKE session using AUTH_NULL [...] > > > > Yes, thanks. That helps and is that what the WG had agreed upon or was > it > > not discussed? > > The IKE sessions using AUTH_NULL is subset of IKE sessions, and as > only that subset can have sessions which do not have verifiable > entity, the statement is still true if we add "using AUTH_NULL". On > the other hand the architectural change this draft does is that now > IKE sessions might not have verifiable authenticated entity associated > with it anymore, and that means the meaning of IKE sessions is > changed. > Yes, I like the addition, but wanted to make sure the WG agreed that audit features only change for NULL authentication and expectations of fully authenticated sessions remain in tact. > > The rest of the section is talking about assumptions for IKE sessions > in general, i.e. originally when you could not have unauthenticated > IKE sessions, your implementation might have assumed that certain > level of trust can be put on the information you receive from the > other end. Those assumptions might not be valid anymore when > unauthenticated IKE sessions are added. > OK, is there a way to distinguish trust for authenticated vs. unauthenticated sessions so trust assumptions would vary based on connection type? If this can be made distinct, it would serve the user bases equally well for their intended scenarios. If not, then we are affecting trust levels for existing scenarios where this is implemented and I don't think that's what we want to do. I'd just like to make sure it's clear. > > Those assumptions needs to be verified for all IKE sessions, i.e. if > it matters whether the IKE session is unauthenticated or not, then > specific checks needs to be added that IKE session is properly > authenticated before trusting information. > OK, I think we are in agreement here and just want to make sure the draft reflects this. > > So I think it would be better to keep the original version talking > about IKE sessions in general, and not limiting it only to AUTH_NULL > cases, as implementations need to verify all cases where it make > assumptions about IKE sessions and peers associated to it. > I think that muddies the water for existing IKE sessions with authentication and could affect their assumptions of trust levels. Once we get this sorted, we can move the draft to IETF last call. I just want to make sure the WG agrees on this point before going forward (whatever that agreement is - it's fine to tell me I am wrong and why). Thanks, Kathleen > -- > kivinen@iki.fi > -- Best regards, Kathleen --001a11342ef214c7d3051180da07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tero,

Thanks for your response, just= one question inline.

On Tue, Mar 17, 2015 at 9:26 AM, Tero Kivinen &= lt;kivinen@iki.fi&g= t; wrote:
Kathlee= n Moriarty writes:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Section 3.1
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Shouldn't this new requirem= ent only apply to unauthenticated
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0sessions?=C2=A0 Wouldn't requirem= ents for existing authenti
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cated sessions remain in terms of aud= it capabilities and logging?=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This should be made clear to help imp= lementers.
>
>=C2=A0 =C2=A0 =C2=A0Would this work:
>
>=C2=A0 =C2=A0 =C2=A0old:
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 An established IKE sess= ion [...]
>
>=C2=A0 =C2=A0 =C2=A0new:
>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 An established IKE sess= ion using AUTH_NULL [...]
>
> Yes, thanks.=C2=A0 That helps and is that what the WG had agreed upon = or was it
> not discussed?=C2=A0

The IKE sessions using AUTH_NULL is subset of IKE sessions, and as only that subset can have sessions which do not have verifiable
entity, the statement is still true if we add "using AUTH_NULL". = On
the other hand the architectural change this draft does is that now
IKE sessions might not have verifiable authenticated entity associated
with it anymore, and that means the meaning of IKE sessions is
changed.

Yes, I like the addition, but = wanted to make sure the WG agreed that audit features only change for NULL = authentication and expectations of fully authenticated sessions remain in t= act.

The rest of the section is talking about assumptions for IKE sessions
in general, i.e. originally when you could not have unauthenticated
IKE sessions, your implementation might have assumed that certain
level of trust can be put on the information you receive from the
other end. Those assumptions might not be valid anymore when
unauthenticated IKE sessions are added.

OK, is there a way to distinguish trust for authenticated vs. unauthentica= ted sessions so trust assumptions would vary based on connection type?=C2= =A0 If this can be made distinct, it would serve the user bases equally wel= l for their intended scenarios.=C2=A0 If not, then we are affecting trust l= evels for existing scenarios where this is implemented and I don't thin= k that's what we want to do.=C2=A0 I'd just like to make sure it= 9;s clear.

Those assumptions needs to be verified for all IKE sessions, i.e. if
it matters whether the IKE session is unauthenticated or not, then
specific checks needs to be added that IKE session is properly
authenticated before trusting information.

<= div>OK, I think we are in agreement here and just want to make sure the dra= ft reflects this.=C2=A0

So I think it would be better to keep the original version talking
about IKE sessions in general, and not limiting it only to AUTH_NULL
cases, as implementations need to verify all cases where it make
assumptions about IKE sessions and peers associated to it.
=

I think that muddies the water for existing IKE session= s with authentication and could affect their assumptions of trust levels.

Once we get this sorted, we can move the draft to I= ETF last call.=C2=A0 I just want to make sure the WG agrees on this point b= efore going forward (whatever that agreement is - it's fine to tell me = I am wrong and why).

Thanks,
Kathleen=C2= =A0
--
kivinen@iki.fi



--

Best regards,
Kathleen
--001a11342ef214c7d3051180da07-- From nobody Wed Mar 18 08:43:22 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BEE71A1B28 for ; Wed, 18 Mar 2015 08:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uyj7il3m3428 for ; Wed, 18 Mar 2015 08:43:20 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C401A1ADF for ; Wed, 18 Mar 2015 08:43:20 -0700 (PDT) Received: by lagg8 with SMTP id g8so39460092lag.1 for ; Wed, 18 Mar 2015 08:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=19HgGOSh1xCuKLz5rfDvTChLctFUFIvoQAp8102Cqp8=; b=kCKpH1qagWgTODySpJ5WD4LXGC94RX1OWiDB/wMZONgaQtV5xjHGDg5Ai3JCpu6Osi Xn2V65KElbwVi7m6UIPhQFZ3Y1knWZfIyWe/8cUS0eY4CY4NyA4Qq8pUsJnoZu7+Z24V valeHco0+TjyWagD6AXiiHwrwLjes7u3foED6QTP9gQf423LBVzrXOoxlf+Ae91bC4MK TX3YfTx0YuDHS4DgGvM3/vsO3mDrW7tVlAuDewNBS66ZaX+O4AxarsTTS+t/4j32G4ZE e70bJTte+xDgZYhUv8UOchctqS6ZmHPLQnlR7ro+X9VRzle7GbybUKv/UZvXKdovZNrH 6iQQ== X-Received: by 10.112.137.164 with SMTP id qj4mr52917162lbb.17.1426693398483; Wed, 18 Mar 2015 08:43:18 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id ds8sm3458672lbb.18.2015.03.18.08.43.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 18 Mar 2015 08:43:17 -0700 (PDT) Message-ID: <14FA7C92C27C4280B9EEE5230E895001@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "Kathleen Moriarty" References: <21768.11118.578977.23100@fireball.kivinen.iki.fi> Date: Wed, 18 Mar 2015 18:43:11 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:43:21 -0000 Hi Tero, > Kathleen Moriarty writes: > > Section 3.1 > > Shouldn't this new requirement only apply to unauthenticated > > sessions? Wouldn't requirements for existing authenti > > cated sessions remain in terms of audit capabilities and > > logging? > > This should be made clear to help implementers. > > > > Would this work: > > > > old: > > > > An established IKE session [...] > > > > new: > > > > An established IKE session using AUTH_NULL [...] > > > > Yes, thanks. That helps and is that what the WG had agreed upon or was > > it > > not discussed? > > The IKE sessions using AUTH_NULL is subset of IKE sessions, and as > only that subset can have sessions which do not have verifiable > entity, the statement is still true if we add "using AUTH_NULL". On > the other hand the architectural change this draft does is that now > IKE sessions might not have verifiable authenticated entity associated > with it anymore, and that means the meaning of IKE sessions is > changed. > > The rest of the section is talking about assumptions for IKE sessions > in general, i.e. originally when you could not have unauthenticated > IKE sessions, your implementation might have assumed that certain > level of trust can be put on the information you receive from the > other end. Those assumptions might not be valid anymore when > unauthenticated IKE sessions are added. > > Those assumptions needs to be verified for all IKE sessions, i.e. if > it matters whether the IKE session is unauthenticated or not, then > specific checks needs to be added that IKE session is properly > authenticated before trusting information. > > So I think it would be better to keep the original version talking > about IKE sessions in general, and not limiting it only to AUTH_NULL > cases, as implementations need to verify all cases where it make > assumptions about IKE sessions and peers associated to it. How about the following variant: old: An established IKE session [...] new: With NULL Authentication an established IKE session [...] Just to emphasize that it is support for NULL Authentication that could make some assumptions about IKE SAs uncertain. Regards, Valery. From nobody Fri Mar 20 06:45:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325191B2D6D for ; Fri, 20 Mar 2015 06:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooZdBCL8q_CH for ; Fri, 20 Mar 2015 06:45:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BF91B2D6A for ; Fri, 20 Mar 2015 06:45:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1F91E203C6; Fri, 20 Mar 2015 09:55:30 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 55E0D63B76; Fri, 20 Mar 2015 09:45:53 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 40CAC63731; Fri, 20 Mar 2015 09:45:53 -0400 (EDT) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: Paul Wouters , Tero Kivinen Subject: Re: [IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 13:45:57 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: > I was looking at the interaction of draft-kivinen-ipsecme-oob-pubkey = and > IPSECKEY, since IPSECKEY has an algorithm number but oob-pubkey uses = the > SubjectPublicKeyInfo that encodes the algorithm in the SPKI value > itself. IPSECKEY having been authored some significant time prior to IKEv2, otherwi= se it would have reused some IKEv2 registry for the algorithm number. I agree that the algorithm number in IPSECKEY is significantly lacking. > So first, if we were to fix this for IPSECKEY (and I'm not yet convin= ced > we are there yet, as we might end up with updating IPSECKEY due to ot= her > issues we'll find over the next few months) we might consider > allocating a special=20 > algorithm number to signify this in the IKE Authentication Method reg= istry at > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xht= ml#ikev2-parameters-12 > For instance, 255 :) I don't really undersatnd what you are saying. Are you saying that we need= a special IKE Authentication Method that signifies to use IPSECKEY, or are you saying that a new IPSECKEY would juse use this registery for the algorithm number? > Then I noticed that in fact the registry is a two octet value, while = in > the IPSECKEY record this is a one octet value: > https://tools.ietf.org/html/rfc4025#section-2.1 > That's clearly a bug. Is it worth filing an ERRATA for this or should= we > wait and see if we will replace IPSECKEY anyway? But, IPSECKEY doesn't use an IKEv2 parameter, it has it's own registry. What you write above seems to suggest that it somehow references the IKEv2 registry. Maybe I don't understand the email. If we were to do anything, I'd say that we should create IPSECKEY algorithm type 3, and say that it uses the same SubjectPublicKeyInfo minimal ASN.1 encoding that oop-pubkey uses. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVQwkjoCLcPvd0N1lAQKsUwf/apDnkzR6R1RKIm4Sz/BlLES7l9bNhKkO OVgfO1kcZEGPzE8BxXGJn3nbURQCnYs/zE0qFGAhjqSRCNch6ESQpXDdZPszCzsS 06iZWgC1UX8zMWRMc/kYDk9ro8IuXKeRXN0MCE550lR75lBoTjGTGG6iq959a56v rYb1oKZ6UMhk9FbZ37VRi/mTlXubx0gM0BMFsRzUsQusbt2b5dX/z9kTD7h+fgGu 4/zbUMh8EdEs/AerpACIwnAeXtdAykoMiZc9HGe3g9yLCAOQE1qIOOOaQ2AD11n0 s4WgRD0eGKYe5n4U82hrt1wkikaLckDx3QIptcorUCF7zjlAqxElwQ== =YSEa -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 20 11:51:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A411A88B9 for ; Fri, 20 Mar 2015 11:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKTn8Dofw0FC for ; Fri, 20 Mar 2015 11:51:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 582AF1A8896 for ; Fri, 20 Mar 2015 11:51:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l7vMl66Zpz79Q; Fri, 20 Mar 2015 19:51:31 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=gGsZzZnj X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id jy6bdc01-9ws; Fri, 20 Mar 2015 19:51:29 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 20 Mar 2015 19:51:29 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9D4C780416; Fri, 20 Mar 2015 14:51:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1426877488; bh=Zy/d/hld2+frVWFEZEKQAXI4Ug25Vnao6MFAkny0mW0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gGsZzZnjpIABcL0HaXwkihynHcKZp6pq+u4HLqbPSD5KBGkOPjGtnPBE/hLVQd2OH cPS6GQgNuwGyM07MmHhSLnBM7NXY5huwctQMzoXjgrSITRLDTWjAuM90W5t6p58TOq 2SfNnezm1tc6DU0xvygEuyidHUu4MEvh4+JKBGvo= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2KIpS4L013270; Fri, 20 Mar 2015 14:51:28 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 20 Mar 2015 14:51:28 -0400 (EDT) From: Paul Wouters To: Michael Richardson In-Reply-To: <5250.1426859153@sandelman.ca> Message-ID: References: <5250.1426859153@sandelman.ca> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Cc: "ipsec@ietf.org WG" , Tero Kivinen Subject: Re: [IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 18:51:37 -0000 On Fri, 20 Mar 2015, Michael Richardson wrote: > Paul Wouters wrote: > > I was looking at the interaction of draft-kivinen-ipsecme-oob-pubkey and > > IPSECKEY, since IPSECKEY has an algorithm number but oob-pubkey uses the > > SubjectPublicKeyInfo that encodes the algorithm in the SPKI value > > itself. > > IPSECKEY having been authored some significant time prior to IKEv2, otherwise > it would have reused some IKEv2 registry for the algorithm number. I understand, but even for IKEv2 there will be no all knowing registry of valid algorithm numbers once we allow any kind of SPKI. > > So first, if we were to fix this for IPSECKEY (and I'm not yet convinced > > we are there yet, as we might end up with updating IPSECKEY due to other > > issues we'll find over the next few months) we might consider > > allocating a special > > algorithm number to signify this in the IKE Authentication Method registry at > > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 > > > For instance, 255 :) > > I don't really undersatnd what you are saying. Are you saying that we need a > special IKE Authentication Method that signifies to use IPSECKEY, or are you > saying that a new IPSECKEY would juse use this registery for the algorithm > number? I'm saying we can't specify an algorithm number for all the possible SPKI's. > > Then I noticed that in fact the registry is a two octet value, while in > > the IPSECKEY record this is a one octet value: > > > https://tools.ietf.org/html/rfc4025#section-2.1 > > > That's clearly a bug. Is it worth filing an ERRATA for this or should we > > wait and see if we will replace IPSECKEY anyway? > > But, IPSECKEY doesn't use an IKEv2 parameter, it has it's own registry. > What you write above seems to suggest that it somehow references the IKEv2 > registry. Maybe I don't understand the email. I guess you are right here. I thought it would map 1:1 to: https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-8 I guess I wasn't around the IETF at this time so I'm not sure why IPSECKEY had to have its own registry. It still means you cannot use all IKE(v2) algorithms in IPSECKEY records. Who determines which ones are allowed and what are the selection criteria? > If we were to do anything, I'd say that we should create IPSECKEY algorithm > type 3, and say that it uses the same SubjectPublicKeyInfo minimal ASN.1 > encoding that oop-pubkey uses. Except if you have multiple algorithms, you can no longer use the IPSECKEY record to lookup which one to use. Does the remote want RSA or ECDSA? Well it will take some SPKI but you won't know until you're in IKE_AUTH (and they possibly rejected yours) Paul From nobody Fri Mar 20 17:03:05 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFFE1ACEAA for ; Fri, 20 Mar 2015 17:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jfIukDWqUaN for ; Fri, 20 Mar 2015 17:03:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2801ACEA9 for ; Fri, 20 Mar 2015 17:03:02 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 462A6203BB for ; Fri, 20 Mar 2015 20:12:39 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1738A63B76; Fri, 20 Mar 2015 20:03:00 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EC14B636B6 for ; Fri, 20 Mar 2015 20:03:00 -0400 (EDT) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: References: <5250.1426859153@sandelman.ca> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 00:03:04 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: >> Paul Wouters wrote: >> > I was looking at the interaction of draft-kivinen-ipsecme-oob-pubk= ey and >> > IPSECKEY, since IPSECKEY has an algorithm number but oob-pubkey us= es the >> > SubjectPublicKeyInfo that encodes the algorithm in the SPKI value >> > itself. >>=20 >> IPSECKEY having been authored some significant time prior to IKEv2, = otherwise >> it would have reused some IKEv2 registry for the algorithm number. > I understand, but even for IKEv2 there will be no all knowing registry > of valid algorithm numbers once we allow any kind of SPKI. Sure, that makes sense, but wasn't the point of punting it all to SubjectPublicKeyInfo, because if you are going to do new assymetric algorithms, you are going to have to define how the signature works, and so specify that part anyway? >> > Then I noticed that in fact the registry is a two octet value, whi= le in >> > the IPSECKEY record this is a one octet value: >>=20 >> > https://tools.ietf.org/html/rfc4025#section-2.1 >>=20 >> > That's clearly a bug. Is it worth filing an ERRATA for this or sho= uld we >> > wait and see if we will replace IPSECKEY anyway? >>=20 >> But, IPSECKEY doesn't use an IKEv2 parameter, it has it's own regist= ry. >> What you write above seems to suggest that it somehow references the= IKEv2 >> registry. Maybe I don't understand the email. > I guess you are right here. I thought it would map 1:1 to: > https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#= ipsec-registry-8 > I guess I wasn't around the IETF at this time so I'm not sure why > IPSECKEY had to have its own registry. I'd say that the IKEv1 registry wasn't easy to reference, IANA was kinda a mess on those days, and IKEv2 was coming soon... In hindsight, it should have referenced something else. Also the IPSECKEY was the first RR that we= nt through in what was supposed to be the "easier" RR approval process, and I think that any additional references would have scared the reviewers over there.=20=20 > It still means you cannot use all IKE(v2) algorithms in IPSECKEY > records. Who determines which ones are allowed and what are the > selection criteria? I think that ipsecme-oob-pubkey could add new items to the algorithm field, which is defined as IETF Consensus. I suggest adding one, which says that = it comes in SubjectPublicKeyInfo format: >> If we were to do anything, I'd say that we should create IPSECKEY al= gorithm >> type 3, and say that it uses the same SubjectPublicKeyInfo minimal A= SN.1 >> encoding that oop-pubkey uses. > Except if you have multiple algorithms, you can no longer use the > IPSECKEY record to lookup which one to use. Does the remote want RSA = or > ECDSA? Well it will take some SPKI but you won't know until you're in > IKE_AUTH (and they possibly rejected yours) We have that problem right now: one could have RSA or DSA RR. How is this any different? I think that IKEv2 has no requirement that the two ends authenticate with the same algorithm. I agree that this makes it difficult to know which of many algorithms to use; I think the answer is that CERTREQ payloads must be present. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVQy1MoCLcPvd0N1lAQI2zQf+PmAmkq8de0QuYtvkCIQr4Uc99C02GpOv t47KFMmp4qyRO+/Fx3PvHLyVwCF0cX57Rkdrv4xtoXDRJQ5gg9VaWZYj05EEuky9 +W8z931CHU1rrHj2uwJYhq2VZ6Zbjkg1KW42aPjIHEXlg0ryA4z7OOd+Onzm1HIq BL1T+cAudALBKoRZGrEhvDfGZeuhpbCaJo18+8ZFiijg4S23ZsntK2mRF4pPM4r8 HhlhFxDu05E+Q0rZFiEoT7hnsUK2ykUhVLpukgh+t0/qNXaGLKaJY8XJ18c70TIY pJLtqxGgJvfx4Gxz15IxKg1K5UHxXxYyPDhs+rWzC/2OQ1MLmokN/Q== =KEA5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Mar 23 13:01:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63FBF1A1A2D for ; Mon, 23 Mar 2015 13:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inwTFFyQhKFh for ; Mon, 23 Mar 2015 13:01:31 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8871A0636 for ; Mon, 23 Mar 2015 13:01:31 -0700 (PDT) Received: from dhcp-89d0.meeting.ietf.org (dhcp-89d0.meeting.ietf.org [31.133.139.208] (may be forged)) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2NK1SjJ029189 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Mar 2015 13:01:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman X-Priority: 3 In-Reply-To: <14FA7C92C27C4280B9EEE5230E895001@buildpc> Date: Mon, 23 Mar 2015 15:01:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <39D3A948-CE13-4D67-BC71-A17FF98E146A@vpnc.org> References: <21768.11118.578977.23100@fireball.kivinen.iki.fi> <14FA7C92C27C4280B9EEE5230E895001@buildpc> To: Valery Smyslov , Paul Wouters X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IPsecME WG , Kathleen Moriarty Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:01:33 -0000 The window is open for submitting new drafts. It would be great to have = the -05 dealing with Kathleen's requests submitted this week, before the = meeting Friday. --Paul Hoffman= From nobody Mon Mar 23 13:22:15 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC2A1A0404 for ; Mon, 23 Mar 2015 13:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZccSGgw8wOq for ; Mon, 23 Mar 2015 13:22:13 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E871A03D5 for ; Mon, 23 Mar 2015 13:22:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3l9nDw4Nc1z1Hx; Mon, 23 Mar 2015 21:22:08 +0100 (CET) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=hdhQEAvP X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 60XoUYeSZGZw; Mon, 23 Mar 2015 21:22:07 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 23 Mar 2015 21:22:07 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 069FA80A01; Mon, 23 Mar 2015 16:22:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427142126; bh=7D7Fe0W4rWOsHOpnT0wKV6oHz+wRz7tXw7rXWo+jddU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hdhQEAvPTPlspmvTai5zucxV4HZFb/RbtLPJVQ19hKUAvkzIa10Ken6LPf0sIZtUn Mc+VrX4xSj63sOTfuGUUGb/P5AEvAnS9jwMduBk2NByNc6zNqYwn3VLELO6iTooEjl Sb1bJqr8kEE/xxdanQXw0oDGDofsTcF2pX2mdfIA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2NKM5mv000960; Mon, 23 Mar 2015 16:22:05 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 23 Mar 2015 16:22:05 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: <39D3A948-CE13-4D67-BC71-A17FF98E146A@vpnc.org> Message-ID: References: <21768.11118.578977.23100@fireball.kivinen.iki.fi> <14FA7C92C27C4280B9EEE5230E895001@buildpc> <39D3A948-CE13-4D67-BC71-A17FF98E146A@vpnc.org> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Valery Smyslov , Kathleen Moriarty Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 20:22:15 -0000 On Mon, 23 Mar 2015, Paul Hoffman wrote: > Subject: Re: [IPsec] AD review of draft-ietf-ipsecme-ikev2-null-auth > > The window is open for submitting new drafts. It would be great to have the -05 dealing with Kathleen's requests submitted this week, before the meeting Friday. I'll send the updated version to Valerie today, so it should be in for you tomorrow if Valerie has some time to check it while we sleep. Paul From nobody Tue Mar 24 08:56:08 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D57FC1A9056 for ; Tue, 24 Mar 2015 08:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ItPFV-1CsLrN for ; Tue, 24 Mar 2015 08:56:02 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44BC1A900A for ; Tue, 24 Mar 2015 08:56:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2OFtpUq023219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Mar 2015 17:55:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2OFtn1q009669; Tue, 24 Mar 2015 17:55:49 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21777.35077.256865.60502@fireball.kivinen.iki.fi> Date: Tue, 24 Mar 2015 17:55:49 +0200 From: Tero Kivinen To: RFC Errata System In-Reply-To: <20150310100921.959FD180207@rfc-editor.org> References: <20150310100921.959FD180207@rfc-editor.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 19 min Archived-At: Cc: a.yousar@informatik.hu-berlin.de, paul.hoffman@vpnc.org, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, jms@opus1.com, stephen.farrell@cs.tcd.ie Subject: [IPsec] [Editorial Errata Reported] RFC7427 (4295) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:56:04 -0000 RFC Errata System writes: > The following errata report has been submitted for RFC7427, > "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4295 > > -------------------------------------- > Type: Editorial > Reported by: Annie Yousar > > Section: A.4.2 > > Original Text > ------------- > Here the parameters are present and contain the default parameters, > i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, > saltLength of 20, and trailerField of 1. > > 0000 : SEQUENCE > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > 000d : SEQUENCE > 000f : CONTEXT 0 > 0011 : SEQUENCE > 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) > 001a : NULL > 001c : CONTEXT 1 > 001e : SEQUENCE > 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 > 002b : SEQUENCE > 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) > 0034 : NULL > 0036 : CONTEXT 2 > 0038 : INTEGER 0x14 (5 bits) > 003b : CONTEXT 3 > 003d : INTEGER 0x1 (1 bits) > > Name = RSASSA-PSS with default parameters, > oid = 1.2.840.113549.1.1.10 > Length = 64 > 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 > 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 > 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b > 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 > > > > Corrected Text > -------------- > If the default parameters are used, i.e., hashAlgorithm of SHA-1, > maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField > of 1, the parameters MUST NOT be encoded according to the > Distiguished Encoding Rules (DER) of ASN.1. Therefore the encoding > is the same as of A.4.1. Not true. In the RFC 4055 the section 3.1 says that even when the default values are used the implementation MUST understand both formats, i.e. the case where the default value is omitted and the case where the default value is explictly given: >From RFC4055 section 3.1: hashAlgorithm The hashAlgorithm field identifies the hash function. It MUST be one of the algorithm identifiers listed in Section 2.1, and the default hash function is SHA-1. Implementations MUST support SHA-1 and MAY support any of the other one-way hash functions listed in Section 2.1. Implementations that perform signature generation MUST omit the hashAlgorithm field when SHA-1 is used, indicating that the default algorithm was used. Implementations that perform signature validation MUST recognize both the sha1Identifier algorithm identifier and an absent hashAlgorithm field as an indication that SHA-1 was used. In this case we are not actually doing either one of those options, we are not generating signature, and we are not validating them. In this document we are simply indicating what kind of signature will follows this binary blob. Yes, when generating those ASN.1 objects for default values implementations should use the A.4.1 version, but they might also want to understand the version specified in the A.4.2. Note, that in some cases the implementations might simply take the AlgorithmIdentifier pieces from their own cerificate and not generate it at all, and this might cause them to take whatever the CA vendor generated for them. Actually when checking for the RFC4055 I notice it says that same thing (MUST omit in generate, MUST recognize both) for everything else (hashAlgorithm, maskGenAlgorithm, and trailerField) expect for saltLength... I do not know if this means that for saltLength we should actually not encode the default as number or if this is just sloppy writing of the RFC4055... > 0000 : SEQUENCE > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > 000d : SEQUENCE > > Name = RSASSA-PSS with default parameters, > oid = 1.2.840.113549.1.1.10 > Length = 15 > 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 > > > Notes > ----- > Section 3 requires the use of DER: > The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. Yes, when generating them they needs to be in DER, when matching the values sent from the other end, the matching can be looser. We could add note saying that format A.4.1 MUST be used when generating the RSASSA-PSS with default parameters, but A.4.2 can also be recognized. If the implementation has real ASN.1 parser this is exactly what it will do automatically. -- kivinen@iki.fi From nobody Tue Mar 24 09:03:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B321A900A for ; Tue, 24 Mar 2015 09:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccnd-roZbGhE for ; Tue, 24 Mar 2015 09:02:53 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30F891B2E5C for ; Tue, 24 Mar 2015 09:01:09 -0700 (PDT) Received: by lagg8 with SMTP id g8so163269842lag.1 for ; Tue, 24 Mar 2015 09:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N9r7QdeWk/nQ8xY6GGUOvnPjU93/PYCP+ReCXqLc0CQ=; b=PoBkZUHWzpDAWoJgR1y/b5MICMi4hRU3pNyO0RsIO3i4uQzwSJHk6jkqfRV2lmAV6r PMFZXWrpe1w18ruT14xoUaE6aDFgIEmVCex4qZIBE+OwudwsX5zhIlSzIGbIw2QIsDDy 0tk8LcqO2LylabPF/LNi1Qh176xh2N2u+P2BmL17Qj4zX2HR7351XEwEub3dWyjIi+0U y1gtOGFP0clWWcqfY1arsDYN5cwZpz/E3PSvWFBUG9DCFcgQk7+0N21HlDETYdAJMpQ6 VCWCH7RmLKJguGujAd5gnEWQMCYkWDmQzKPy+Fn3S77akGkwmhMz7APjncAnqigiFtEx TAig== MIME-Version: 1.0 X-Received: by 10.112.218.5 with SMTP id pc5mr4586910lbc.32.1427212867584; Tue, 24 Mar 2015 09:01:07 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 24 Mar 2015 09:01:07 -0700 (PDT) In-Reply-To: <21777.35077.256865.60502@fireball.kivinen.iki.fi> References: <20150310100921.959FD180207@rfc-editor.org> <21777.35077.256865.60502@fireball.kivinen.iki.fi> Date: Tue, 24 Mar 2015 12:01:07 -0400 Message-ID: From: Kathleen Moriarty To: Tero Kivinen Content-Type: multipart/alternative; boundary=001a11c322f6fdca1e05120ae3ae Archived-At: Cc: a.yousar@informatik.hu-berlin.de, Paul Hoffman , "ipsec@ietf.org" , RFC Errata System , Joel Snyder , Stephen Farrell Subject: Re: [IPsec] [Editorial Errata Reported] RFC7427 (4295) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:02:56 -0000 --001a11c322f6fdca1e05120ae3ae Content-Type: text/plain; charset=UTF-8 Thanks for your review of this errata report. As I read your response, this should be rejected. If a note like you suggest might be added, "We could add note saying that format A.4.1 MUST be used when generating the RSASSA-PSS with default parameters, but A.4.2 can also be recognized." should be added, then I think that should be in a separate editorial errata and this one should be rejected. Does that sound good? Thanks. On Tue, Mar 24, 2015 at 11:55 AM, Tero Kivinen wrote: > RFC Errata System writes: > > The following errata report has been submitted for RFC7427, > > "Signature Authentication in the Internet Key Exchange Version 2 > (IKEv2)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4295 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Annie Yousar > > > > Section: A.4.2 > > > > Original Text > > ------------- > > Here the parameters are present and contain the default parameters, > > i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, > > saltLength of 20, and trailerField of 1. > > > > 0000 : SEQUENCE > > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > > 000d : SEQUENCE > > 000f : CONTEXT 0 > > 0011 : SEQUENCE > > 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) > > 001a : NULL > > 001c : CONTEXT 1 > > 001e : SEQUENCE > > 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 > > 002b : SEQUENCE > > 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) > > 0034 : NULL > > 0036 : CONTEXT 2 > > 0038 : INTEGER 0x14 (5 bits) > > 003b : CONTEXT 3 > > 003d : INTEGER 0x1 (1 bits) > > > > Name = RSASSA-PSS with default parameters, > > oid = 1.2.840.113549.1.1.10 > > Length = 64 > > 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 > > 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 > > 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b > > 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 > > > > > > > > Corrected Text > > -------------- > > If the default parameters are used, i.e., hashAlgorithm of SHA-1, > > maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField > > of 1, the parameters MUST NOT be encoded according to the > > Distiguished Encoding Rules (DER) of ASN.1. Therefore the encoding > > is the same as of A.4.1. > > Not true. In the RFC 4055 the section 3.1 says that even when the > default values are used the implementation MUST understand both > formats, i.e. the case where the default value is omitted and the case > where the default value is explictly given: > > From RFC4055 section 3.1: > > hashAlgorithm > > The hashAlgorithm field identifies the hash function. It MUST > be one of the algorithm identifiers listed in Section 2.1, and > the default hash function is SHA-1. Implementations MUST > support SHA-1 and MAY support any of the other one-way hash > functions listed in Section 2.1. Implementations that perform > signature generation MUST omit the hashAlgorithm field when > SHA-1 is used, indicating that the default algorithm was used. > Implementations that perform signature validation MUST > recognize both the sha1Identifier algorithm identifier and an > absent hashAlgorithm field as an indication that SHA-1 was > used. > > In this case we are not actually doing either one of those options, we > are not generating signature, and we are not validating them. In this > document we are simply indicating what kind of signature will follows > this binary blob. Yes, when generating those ASN.1 objects for default > values implementations should use the A.4.1 version, but they might > also want to understand the version specified in the A.4.2. > > Note, that in some cases the implementations might simply take the > AlgorithmIdentifier pieces from their own cerificate and not generate > it at all, and this might cause them to take whatever the CA vendor > generated for them. > > Actually when checking for the RFC4055 I notice it says that same > thing (MUST omit in generate, MUST recognize both) for everything else > (hashAlgorithm, maskGenAlgorithm, and trailerField) expect for > saltLength... I do not know if this means that for saltLength we > should actually not encode the default as number or if this is just > sloppy writing of the RFC4055... > > > 0000 : SEQUENCE > > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > > 000d : SEQUENCE > > > > Name = RSASSA-PSS with default parameters, > > oid = 1.2.840.113549.1.1.10 > > Length = 15 > > 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 > > > > > > Notes > > ----- > > Section 3 requires the use of DER: > > The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of > PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished > encoding rules (DER) [CCITT.X690.2002]. > > Yes, when generating them they needs to be in DER, when matching the > values sent from the other end, the matching can be looser. > > We could add note saying that format A.4.1 MUST be used when > generating the RSASSA-PSS with default parameters, but A.4.2 can also > be recognized. > > If the implementation has real ASN.1 parser this is exactly what it > will do automatically. > -- > kivinen@iki.fi > -- Best regards, Kathleen --001a11c322f6fdca1e05120ae3ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your review of this errata report.=C2=A0 As I r= ead your response, this should be rejected.=C2=A0 If a note like you sugges= t might be added,

"We could add note saying that format A.4.1 MUST be used when
generating the RSAS= SA-PSS with default parameters, but A.4.2 can also
be re= cognized."
should be a= dded, then I think that should be in a separate editorial errata and this o= ne should be rejected.

Does that sound good?

Thanks.

On Tue, Mar 24, 2015 at 11:55 AM, Tero Kivinen <kivinen@iki.fi> wrote:
RFC Errata System writes:
> The following errata report has been submitted for RFC7427,
> "Signature Authentication in the Internet Key Exchange Version 2 = (IKEv2)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D7427&eid=3D4295
>
> --------------------------------------
> Type: Editorial
> Reported by: Annie Yousar <a.yousar@informatik.hu-berlin.de>
>
> Section: A.4.2
>
> Original Text
> -------------
>=C2=A0 =C2=A0 Here the parameters are present and contain the default p= arameters,
>=C2=A0 =C2=A0 i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA= 1,
>=C2=A0 =C2=A0 saltLength of 20, and trailerField of 1.
>
>=C2=A0 =C2=A0 0000 : SEQUENCE
>=C2=A0 =C2=A0 0002 :=C2=A0 =C2=A0OBJECT IDENTIFIER=C2=A0 RSASSA-PSS (1.= 2.840.113549.1.1.10)
>=C2=A0 =C2=A0 000d :=C2=A0 =C2=A0SEQUENCE
>=C2=A0 =C2=A0 000f :=C2=A0 =C2=A0 =C2=A0CONTEXT 0
>=C2=A0 =C2=A0 0011 :=C2=A0 =C2=A0 =C2=A0 =C2=A0SEQUENCE
>=C2=A0 =C2=A0 0013 :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OBJECT IDENTIFIER= =C2=A0 id-sha1 (1.3.14.3.2.26)
>=C2=A0 =C2=A0 001a :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NULL
>=C2=A0 =C2=A0 001c :=C2=A0 =C2=A0 =C2=A0CONTEXT 1
>=C2=A0 =C2=A0 001e :=C2=A0 =C2=A0 =C2=A0 =C2=A0SEQUENCE
>=C2=A0 =C2=A0 0020 :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OBJECT IDENTIFIER= =C2=A0 1.2.840.113549.1.1.8
>=C2=A0 =C2=A0 002b :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SEQUENCE
>=C2=A0 =C2=A0 002d :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0OBJECT IDE= NTIFIER=C2=A0 id-sha1 (1.3.14.3.2.26)
>=C2=A0 =C2=A0 0034 :=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NULL
>=C2=A0 =C2=A0 0036 :=C2=A0 =C2=A0 =C2=A0CONTEXT 2
>=C2=A0 =C2=A0 0038 :=C2=A0 =C2=A0 =C2=A0 =C2=A0INTEGER=C2=A0 =C2=A00x14= (5 bits)
>=C2=A0 =C2=A0 003b :=C2=A0 =C2=A0 =C2=A0CONTEXT 3
>=C2=A0 =C2=A0 003d :=C2=A0 =C2=A0 =C2=A0 =C2=A0INTEGER=C2=A0 =C2=A00x1 = (1 bits)
>
>=C2=A0 =C2=A0 Name =3D RSASSA-PSS with default parameters,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oid =3D 1.2.840.113549.1.1.10<= br> >=C2=A0 =C2=A0 Length =3D 64
>=C2=A0 =C2=A0 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0
>=C2=A0 =C2=A0 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016
>=C2=A0 =C2=A0 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b
>=C2=A0 =C2=A0 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101
>
>
>
> Corrected Text
> --------------
>=C2=A0 =C2=A0 If the default parameters are used, i.e., hashAlgorithm o= f SHA-1,
>=C2=A0 =C2=A0 maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trail= erField
>=C2=A0 =C2=A0 of 1, the parameters MUST NOT be encoded according to the=
>=C2=A0 =C2=A0 Distiguished Encoding Rules (DER) of ASN.1. Therefore the= encoding
>=C2=A0 =C2=A0 is the same as of A.4.1.

Not true. In the RFC 4055 the section 3.1 says that even when t= he
default values are used the implementation MUST understand both
formats, i.e. the case where the default value is omitted and the case
where the default value is explictly given:

>From RFC4055 section 3.1:

=C2=A0 =C2=A0 =C2=A0 hashAlgorithm

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The hashAlgorithm field identifies the ha= sh function.=C2=A0 It MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be one of the algorithm identifiers liste= d in Section 2.1, and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the default hash function is SHA-1.=C2=A0= Implementations MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support SHA-1 and MAY support any of the = other one-way hash
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0functions listed in Section 2.1.=C2=A0 Im= plementations that perform
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0signature generation MUST omit the hashAl= gorithm field when
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHA-1 is used, indicating that the defaul= t algorithm was used.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Implementations that perform signature va= lidation MUST
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recognize both the sha1Identifier algorit= hm identifier and an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0absent hashAlgorithm field as an indicati= on that SHA-1 was
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0used.

In this case we are not actually doing either one of those options, we
are not generating signature, and we are not validating them. In this
document we are simply indicating what kind of signature will follows
this binary blob. Yes, when generating those ASN.1 objects for default
values implementations should use the A.4.1 version, but they might
also want to understand the version specified in the A.4.2.

Note, that in some cases the implementations might simply take the
AlgorithmIdentifier pieces from their own cerificate and not generate
it at all, and this might cause them to take whatever the CA vendor
generated for them.

Actually when checking for the RFC4055 I notice it says that same
thing (MUST omit in generate, MUST recognize both) for everything else
(hashAlgorithm, maskGenAlgorithm, and trailerField) expect for
saltLength... I do not know if this means that for saltLength we
should actually not encode the default as number or if this is just
sloppy writing of the RFC4055...

>=C2=A0 =C2=A0 0000 : SEQUENCE
>=C2=A0 =C2=A0 0002 :=C2=A0 =C2=A0OBJECT IDENTIFIER=C2=A0 RSASSA-PSS (1.= 2.840.113549.1.1.10)
>=C2=A0 =C2=A0 000d :=C2=A0 =C2=A0SEQUENCE
>
>=C2=A0 =C2=A0 Name =3D RSASSA-PSS with default parameters,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0oid =3D 1.2.840.113549.1.1.10<= br> >=C2=A0 =C2=A0 Length =3D 15
>=C2=A0 =C2=A0 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00
>
>
> Notes
> -----
> Section 3 requires the use of DER:
> The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier = of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished enc= oding rules (DER) [CCITT.X690.2002].

Yes, when generating them they needs to be in DER, when matching the=
values sent from the other end, the matching can be looser.

We could add note saying that format A.4.1 MUST be used when
generating the RSASSA-PSS with default parameters, but A.4.2 can also
be recognized.

If the implementation has real ASN.1 parser this is exactly what it
will do automatically.
--
kivinen@iki.fi



--

Best regards,
Kathleen
--001a11c322f6fdca1e05120ae3ae-- From nobody Tue Mar 24 09:06:59 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531C21A907B for ; Tue, 24 Mar 2015 09:06:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HloLrFI8eFnA for ; Tue, 24 Mar 2015 09:06:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9744A1A9029 for ; Tue, 24 Mar 2015 09:04:45 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2OG4eKb029285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Mar 2015 18:04:40 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2OG4dwd014374; Tue, 24 Mar 2015 18:04:39 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21777.35607.852024.161621@fireball.kivinen.iki.fi> Date: Tue, 24 Mar 2015 18:04:39 +0200 From: Tero Kivinen To: RFC Errata System In-Reply-To: <20150310101551.4237E180207@rfc-editor.org> References: <20150310101551.4237E180207@rfc-editor.org> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Archived-At: Cc: a.yousar@informatik.hu-berlin.de, paul.hoffman@vpnc.org, ipsec@ietf.org, Kathleen.Moriarty.ietf@gmail.com, jms@opus1.com, stephen.farrell@cs.tcd.ie Subject: [IPsec] [Editorial Errata Reported] RFC7427 (4296) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:06:57 -0000 RFC Errata System writes: > The following errata report has been submitted for RFC7427, > "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4296 > > -------------------------------------- > Type: Editorial > Reported by: Annie Yousar > > Section: A.4.3 > > Original Text > ------------- > Here the parameters are present and contain hashAlgorithm of SHA-256, > | maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1. > > 0000 : SEQUENCE > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > 000d : SEQUENCE > 000f : CONTEXT 0 > 0011 : SEQUENCE > 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) > 001e : NULL > 0020 : CONTEXT 1 > 0022 : SEQUENCE > | 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 > 002f : SEQUENCE > 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) > 003c : NULL > 003e : CONTEXT 2 > 0040 : INTEGER 0x20 (6 bits) > | 0043 : CONTEXT 3 > | 0045 : INTEGER 0x1 (1 bits) > > Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 > | Length = 72 > 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 > 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 > 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 > 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 > | 0040: 0201 20a3 0302 0101 > > > Corrected Text > -------------- > Here the parameters are present and contain hashAlgorithm of SHA-256, > | maskGenAlgorithm of MGF1 with SHA-256, saltLength of 32, and > | trailerField of 1. > | Note that since the trailerField has the default value it MUST NOT be > | encoded according to the Distiguished Encoding Rules (DER) of ASN.1. > > 0000 : SEQUENCE > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > 000d : SEQUENCE > 000f : CONTEXT 0 > 0011 : SEQUENCE > 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) > 001e : NULL > 0020 : CONTEXT 1 > 0022 : SEQUENCE > | 0024 : OBJECT IDENTIFIER id-mgf1 (1.2.840.113549.1.1.8) > 002f : SEQUENCE > 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) > 003c : NULL > 003e : CONTEXT 2 > 0040 : INTEGER 0x20 (6 bits) > > Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 > | Length = 67 > 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 > 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 > 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 > 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 > | 0040: 0201 20 > > > Notes > ----- > 1. The maskGenAlgorithm is in fact not SHA-256 > (2.16.840.1.101.3.4.2.1), but MGF1 (1.2.840.113549.1.1.8) based on > SHA-256 (2.16.840.1.101.3.4.2.1). The id-mgf1 oid is there in the example, the tool I used didn't know the name for it thus it just printed out the oid. As this does not affect the binary object at all there is no problem in here. > 2. Section 3 requires the use of DER: > The ASN.1 used here is the same ASN.1 used in the > AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), > encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. Yes, but RFC4055 says that: trailerField The trailerField field is an integer. It provides compatibility with IEEE Std 1363a-2004 [P1363A]. The value MUST be 1, which represents the trailer field with hexadecimal value 0xBC. Other trailer fields, including the trailer field composed of HashID concatenated with 0xCC that is specified in IEEE Std 1363a, are not supported. Implementations that perform signature generation MUST omit the trailerField field, indicating that the default trailer field value was used. Implementations that perform signature validation MUST recognize both a present trailerField field with value 1 and an absent trailerField field. I.e. you should recognize both formats. Yes, we could have another example also showing the object value to used when generating these and when omitting the default values (like we do have for SHA-1). > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7427 (draft-kivinen-ipsecme-signature-auth-07) > -------------------------------------- > Title : Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) > Publication Date : January 2015 > Author(s) : T. Kivinen, J. Snyder > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Area : Security > Stream : IETF > Verifying Party : IESG -- kivinen@iki.fi From nobody Tue Mar 24 09:09:12 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4791A8FD6 for ; Tue, 24 Mar 2015 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHQpj70PH4cK for ; Tue, 24 Mar 2015 09:08:59 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3481A87B9 for ; Tue, 24 Mar 2015 09:07:55 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2OG7oJE013372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Mar 2015 18:07:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2OG7oLh015154; Tue, 24 Mar 2015 18:07:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21777.35798.689660.780227@fireball.kivinen.iki.fi> Date: Tue, 24 Mar 2015 18:07:50 +0200 From: Tero Kivinen To: Kathleen Moriarty In-Reply-To: References: <20150310100921.959FD180207@rfc-editor.org> <21777.35077.256865.60502@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Cc: a.yousar@informatik.hu-berlin.de, Paul Hoffman , "ipsec@ietf.org" , RFC Errata System , Joel Snyder , Stephen Farrell Subject: Re: [IPsec] [Editorial Errata Reported] RFC7427 (4295) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:09:00 -0000 Kathleen Moriarty writes: > Thanks for your review of this errata report.=A0 As I read your respo= nse, this > should be rejected.=A0 If a note like you suggest might be added, >=20 > "We could add note saying that format A.4.1 MUST be used when > generating the RSASSA-PSS with default parameters, but A.4.2 can also= > be recognized." >=20 > should be added, then I think that should be in a separate editorial = errata > and this one should be rejected. >=20 > Does that sound good=3F Works for me. > On Tue, Mar 24, 2015 at 11:55 AM, Tero Kivinen wrote= : >=20 > RFC Errata System writes: > > The following errata report has been submitted for RFC7427, > > "Signature Authentication in the Internet Key Exchange Version = 2 (IKEv2) > ". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata=5Fsearch.php=3Frfc=3D7427&eid=3D= 4295 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Annie Yousar > > > > Section: A.4.2 > > > > Original Text > > ------------- > >=A0 =A0 Here the parameters are present and contain the default = parameters, > >=A0 =A0 i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SH= A1, > >=A0 =A0 saltLength of 20, and trailerField of 1. > > > >=A0 =A0 0000 : SEQUENCE > >=A0 =A0 0002 :=A0 =A0OBJECT IDENTIFIER=A0 RSASSA-PSS (1.2.840.11= 3549.1.1.10) > >=A0 =A0 000d :=A0 =A0SEQUENCE > >=A0 =A0 000f :=A0 =A0 =A0CONTEXT 0 > >=A0 =A0 0011 :=A0 =A0 =A0 =A0SEQUENCE > >=A0 =A0 0013 :=A0 =A0 =A0 =A0 =A0OBJECT IDENTIFIER=A0 id-sha1 (1= .3.14.3.2.26) > >=A0 =A0 001a :=A0 =A0 =A0 =A0 =A0NULL > >=A0 =A0 001c :=A0 =A0 =A0CONTEXT 1 > >=A0 =A0 001e :=A0 =A0 =A0 =A0SEQUENCE > >=A0 =A0 0020 :=A0 =A0 =A0 =A0 =A0OBJECT IDENTIFIER=A0 1.2.840.11= 3549.1.1.8 > >=A0 =A0 002b :=A0 =A0 =A0 =A0 =A0SEQUENCE > >=A0 =A0 002d :=A0 =A0 =A0 =A0 =A0 =A0OBJECT IDENTIFIER=A0 id-sha= 1 (1.3.14.3.2.26) > >=A0 =A0 0034 :=A0 =A0 =A0 =A0 =A0 =A0NULL > >=A0 =A0 0036 :=A0 =A0 =A0CONTEXT 2 > >=A0 =A0 0038 :=A0 =A0 =A0 =A0INTEGER=A0 =A00x14 (5 bits) > >=A0 =A0 003b :=A0 =A0 =A0CONTEXT 3 > >=A0 =A0 003d :=A0 =A0 =A0 =A0INTEGER=A0 =A00x1 (1 bits) > > > >=A0 =A0 Name =3D RSASSA-PSS with default parameters, > >=A0 =A0 =A0 =A0 =A0 =A0oid =3D 1.2.840.113549.1.1.10 > >=A0 =A0 Length =3D 64 > >=A0 =A0 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 > >=A0 =A0 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 > >=A0 =A0 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b > >=A0 =A0 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 > > > > > > > > Corrected Text > > -------------- > >=A0 =A0 If the default parameters are used, i.e., hashAlgorithm = of SHA-1, > >=A0 =A0 maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trai= lerField > >=A0 =A0 of 1, the parameters MUST NOT be encoded according to th= e > >=A0 =A0 Distiguished Encoding Rules (DER) of ASN.1. Therefore th= e encoding > >=A0 =A0 is the same as of A.4.1. > =20 > Not true. In the RFC 4055 the section 3.1 says that even when the= > default values are used the implementation MUST understand both > formats, i.e. the case where the default value is omitted and the= case > where the default value is explictly given: > =20 > >From RFC4055 section 3.1: > =20 > =A0 =A0 =A0 hashAlgorithm > =20 > =A0 =A0 =A0 =A0 =A0The hashAlgorithm field identifies the hash fu= nction.=A0 It MUST > =A0 =A0 =A0 =A0 =A0be one of the algorithm identifiers listed in = Section 2.1, and > =A0 =A0 =A0 =A0 =A0the default hash function is SHA-1.=A0 Impleme= ntations MUST > =A0 =A0 =A0 =A0 =A0support SHA-1 and MAY support any of the other= one-way hash > =A0 =A0 =A0 =A0 =A0functions listed in Section 2.1.=A0 Implementa= tions that perform > =A0 =A0 =A0 =A0 =A0signature generation MUST omit the hashAlgorit= hm field when > =A0 =A0 =A0 =A0 =A0SHA-1 is used, indicating that the default alg= orithm was used. > =A0 =A0 =A0 =A0 =A0Implementations that perform signature validat= ion MUST > =A0 =A0 =A0 =A0 =A0recognize both the sha1Identifier algorithm id= entifier and an > =A0 =A0 =A0 =A0 =A0absent hashAlgorithm field as an indication th= at SHA-1 was > =A0 =A0 =A0 =A0 =A0used. > =20 > In this case we are not actually doing either one of those option= s, we > are not generating signature, and we are not validating them. In = this > document we are simply indicating what kind of signature will fol= lows > this binary blob. Yes, when generating those ASN.1 objects for de= fault > values implementations should use the A.4.1 version, but they mig= ht > also want to understand the version specified in the A.4.2. > =20 > Note, that in some cases the implementations might simply take th= e > AlgorithmIdentifier pieces from their own cerificate and not gene= rate > it at all, and this might cause them to take whatever the CA vend= or > generated for them. > =20 > Actually when checking for the RFC4055 I notice it says that same= > thing (MUST omit in generate, MUST recognize both) for everything= else > (hashAlgorithm, maskGenAlgorithm, and trailerField) expect for > saltLength... I do not know if this means that for saltLength we > should actually not encode the default as number or if this is ju= st > sloppy writing of the RFC4055... > =20 > >=A0 =A0 0000 : SEQUENCE > >=A0 =A0 0002 :=A0 =A0OBJECT IDENTIFIER=A0 RSASSA-PSS (1.2.840.11= 3549.1.1.10) > >=A0 =A0 000d :=A0 =A0SEQUENCE > > > >=A0 =A0 Name =3D RSASSA-PSS with default parameters, > >=A0 =A0 =A0 =A0 =A0 =A0oid =3D 1.2.840.113549.1.1.10 > >=A0 =A0 Length =3D 15 > >=A0 =A0 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 > > > > > > Notes > > ----- > > Section 3 requires the use of DER: > > The ASN.1 used here is the same ASN.1 used in the AlgorithmIden= tifier of > PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguis= hed > encoding rules (DER) [CCITT.X690.2002]. > =20 > Yes, when generating them they needs to be in DER, when matching = the > values sent from the other end, the matching can be looser. > =20 > We could add note saying that format A.4.1 MUST be used when > generating the RSASSA-PSS with default parameters, but A.4.2 can = also > be recognized. > =20 > If the implementation has real ASN.1 parser this is exactly what = it > will do automatically. > -- > kivinen@iki.fi >=20 > -- >=20 > Best regards, > Kathleen >=20 --=20 kivinen@iki.fi From nobody Tue Mar 24 09:11:05 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36AF51A8F42 for ; Tue, 24 Mar 2015 09:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIhvJWazAoEn for ; Tue, 24 Mar 2015 09:10:59 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33D51A903F for ; Tue, 24 Mar 2015 09:09:46 -0700 (PDT) Received: by obcjt1 with SMTP id jt1so130679088obc.2 for ; Tue, 24 Mar 2015 09:09:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4H3ty60AuUwA0hOoQyqCduDLFQ70Q/XXR7CnR4+9Njw=; b=ZjouL1LESviY3EzvyxuAg/VZMSBLf0RHQZEg5zqzOqQKnQccIkLLkXV5o9rhluiY9v frvK+EHq77hRWSffWuH5EOH+H+bTGHq9hNemCy+S2ilSello0RV5uHQpB5aIaxes4Jr+ s35qsglvAnRBRZHiDyPleVuZP8ICaJp6FA+ufrjGBcuk4lIyq10028WsYV2oC1cNmAs/ yEDdGTCOEQk0YLIJ8CYR0axwXFbMNis/s1SijIOnx2iv8A2fQ6suwEQo+wVBrlYm3bFK d2NZXmqWmCFxsYVeHGgTEY13COzrvO4Jq6TSP3cXhs5A8O0SA3PmL9XN7+OYreyPyews emUA== X-Received: by 10.182.72.225 with SMTP id g1mr3963501obv.80.1427213386434; Tue, 24 Mar 2015 09:09:46 -0700 (PDT) Received: from [10.51.33.223] (mobile-166-173-059-024.mycingular.net. [166.173.59.24]) by mx.google.com with ESMTPSA id na2sm2385681obb.28.2015.03.24.09.09.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Mar 2015 09:09:44 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <21777.35607.852024.161621@fireball.kivinen.iki.fi> Date: Tue, 24 Mar 2015 11:09:43 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <07BE3F57-6E5D-4942-8E0D-20777A9B1DC2@gmail.com> References: <20150310101551.4237E180207@rfc-editor.org> <21777.35607.852024.161621@fireball.kivinen.iki.fi> To: Tero Kivinen Archived-At: Cc: "a.yousar@informatik.hu-berlin.de" , "paul.hoffman@vpnc.org" , "ipsec@ietf.org" , RFC Errata System , "jms@opus1.com" , "stephen.farrell@cs.tcd.ie" Subject: Re: [IPsec] [Editorial Errata Reported] RFC7427 (4296) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:11:02 -0000 Thank you, Tero. I'll reject this errata. Best regards, Kathleen=20 Sent from my iPhone > On Mar 24, 2015, at 11:04 AM, Tero Kivinen wrote: >=20 > RFC Errata System writes: >> The following errata report has been submitted for RFC7427, >> "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)"= . >>=20 >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D7427&eid=3D4296 >>=20 >> -------------------------------------- >> Type: Editorial >> Reported by: Annie Yousar >>=20 >> Section: A.4.3 >>=20 >> Original Text >> ------------- >> Here the parameters are present and contain hashAlgorithm of SHA-256, >> | maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1. >>=20 >> 0000 : SEQUENCE >> 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) >> 000d : SEQUENCE >> 000f : CONTEXT 0 >> 0011 : SEQUENCE >> 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) >> 001e : NULL >> 0020 : CONTEXT 1 >> 0022 : SEQUENCE >> | 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 >> 002f : SEQUENCE >> 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) >> 003c : NULL >> 003e : CONTEXT 2 >> 0040 : INTEGER 0x20 (6 bits) >> | 0043 : CONTEXT 3 >> | 0045 : INTEGER 0x1 (1 bits) >>=20 >> Name =3D RSASSA-PSS with sha-256, oid =3D 1.2.840.113549.1.1.10 >> | Length =3D 72 >> 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 >> 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 >> 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 >> 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 >> | 0040: 0201 20a3 0302 0101 >>=20 >>=20 >> Corrected Text >> -------------- >> Here the parameters are present and contain hashAlgorithm of SHA-256, >> | maskGenAlgorithm of MGF1 with SHA-256, saltLength of 32, and=20 >> | trailerField of 1. >> | Note that since the trailerField has the default value it MUST NOT be >> | encoded according to the Distiguished Encoding Rules (DER) of ASN.1. >>=20 >> 0000 : SEQUENCE >> 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) >> 000d : SEQUENCE >> 000f : CONTEXT 0 >> 0011 : SEQUENCE >> 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) >> 001e : NULL >> 0020 : CONTEXT 1 >> 0022 : SEQUENCE >> | 0024 : OBJECT IDENTIFIER id-mgf1 (1.2.840.113549.1.1.8) >> 002f : SEQUENCE >> 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) >> 003c : NULL >> 003e : CONTEXT 2 >> 0040 : INTEGER 0x20 (6 bits) >>=20 >> Name =3D RSASSA-PSS with sha-256, oid =3D 1.2.840.113549.1.1.10 >> | Length =3D 67 >> 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 >> 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 >> 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 >> 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 >> | 0040: 0201 20 >>=20 >>=20 >> Notes >> ----- >> 1. The maskGenAlgorithm is in fact not SHA-256 >> (2.16.840.1.101.3.4.2.1), but MGF1 (1.2.840.113549.1.1.8) based on >> SHA-256 (2.16.840.1.101.3.4.2.1). >=20 > The id-mgf1 oid is there in the example, the tool I used didn't know > the name for it thus it just printed out the oid. As this does not > affect the binary object at all there is no problem in here. >=20 >> 2. Section 3 requires the use of DER: >> The ASN.1 used here is the same ASN.1 used in the >> AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), >> encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. >=20 > Yes, but RFC4055 says that: >=20 > trailerField >=20 > The trailerField field is an integer. It provides > compatibility with IEEE Std 1363a-2004 [P1363A]. The value > MUST be 1, which represents the trailer field with hexadecimal > value 0xBC. Other trailer fields, including the trailer field > composed of HashID concatenated with 0xCC that is specified in > IEEE Std 1363a, are not supported. Implementations that > perform signature generation MUST omit the trailerField field, > indicating that the default trailer field value was used. > Implementations that perform signature validation MUST > recognize both a present trailerField field with value 1 and an > absent trailerField field. >=20 > I.e. you should recognize both formats. Yes, we could have another > example also showing the object value to used when generating these > and when omitting the default values (like we do have for SHA-1). >=20 >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >>=20 >> -------------------------------------- >> RFC7427 (draft-kivinen-ipsecme-signature-auth-07) >> -------------------------------------- >> Title : Signature Authentication in the Internet Key Exchan= ge Version 2 (IKEv2) >> Publication Date : January 2015 >> Author(s) : T. Kivinen, J. Snyder >> Category : PROPOSED STANDARD >> Source : IP Security Maintenance and Extensions >> Area : Security >> Stream : IETF >> Verifying Party : IESG > --=20 > kivinen@iki.fi From nobody Tue Mar 24 09:38:23 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2411A8A42; Tue, 24 Mar 2015 09:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9M1lGBU7ifM; Tue, 24 Mar 2015 09:38:08 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id BC8EA1A913A; Tue, 24 Mar 2015 09:37:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 81957180205; Tue, 24 Mar 2015 09:36:21 -0700 (PDT) To: a.yousar@informatik.hu-berlin.de, kivinen@iki.fi, jms@opus1.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150324163621.81957180205@rfc-editor.org> Date: Tue, 24 Mar 2015 09:36:21 -0700 (PDT) Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] [Errata Rejected] RFC7427 (4295) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:38:11 -0000 The following errata report has been rejected for RFC7427, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4295 -------------------------------------- Status: Rejected Type: Editorial Reported by: Annie Yousar Date Reported: 2015-03-10 Rejected by: Kathleen Moriarty (IESG) Section: A.4.2 Original Text ------------- Here the parameters are present and contain the default parameters, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField of 1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 001a : NULL 001c : CONTEXT 1 001e : SEQUENCE 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002b : SEQUENCE 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 0034 : NULL 0036 : CONTEXT 2 0038 : INTEGER 0x14 (5 bits) 003b : CONTEXT 3 003d : INTEGER 0x1 (1 bits) Name = RSASSA-PSS with default parameters, oid = 1.2.840.113549.1.1.10 Length = 64 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 Corrected Text -------------- If the default parameters are used, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField of 1, the parameters MUST NOT be encoded according to the Distiguished Encoding Rules (DER) of ASN.1. Therefore the encoding is the same as of A.4.1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE Name = RSASSA-PSS with default parameters, oid = 1.2.840.113549.1.1.10 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 Notes ----- Section 3 requires the use of DER: The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. KM: Reviewed by expert and response provided. --VERIFIER NOTES-- Reviewed by expert and answer provided as to why this is not correct. -------------------------------------- RFC7427 (draft-kivinen-ipsecme-signature-auth-07) -------------------------------------- Title : Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) Publication Date : January 2015 Author(s) : T. Kivinen, J. Snyder Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Mar 24 09:41:14 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17CF1A9165; Tue, 24 Mar 2015 09:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_fgjwk_sc6w; Tue, 24 Mar 2015 09:41:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id D78EF1A9164; Tue, 24 Mar 2015 09:41:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A2402180205; Tue, 24 Mar 2015 09:39:38 -0700 (PDT) To: a.yousar@informatik.hu-berlin.de, kivinen@iki.fi, jms@opus1.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150324163938.A2402180205@rfc-editor.org> Date: Tue, 24 Mar 2015 09:39:38 -0700 (PDT) Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] [Errata Rejected] RFC7427 (4296) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:41:09 -0000 The following errata report has been rejected for RFC7427, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4296 -------------------------------------- Status: Rejected Type: Editorial Reported by: Annie Yousar Date Reported: 2015-03-10 Rejected by: Kathleen Moriarty (IESG) Section: A.4.3 Original Text ------------- Here the parameters are present and contain hashAlgorithm of SHA-256, | maskGenAlgorithm of SHA-256, saltLength of 32, and trailerField of 1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 001e : NULL 0020 : CONTEXT 1 0022 : SEQUENCE | 0024 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002f : SEQUENCE 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 003c : NULL 003e : CONTEXT 2 0040 : INTEGER 0x20 (6 bits) | 0043 : CONTEXT 3 | 0045 : INTEGER 0x1 (1 bits) Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 | Length = 72 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 | 0040: 0201 20a3 0302 0101 Corrected Text -------------- Here the parameters are present and contain hashAlgorithm of SHA-256, | maskGenAlgorithm of MGF1 with SHA-256, saltLength of 32, and | trailerField of 1. | Note that since the trailerField has the default value it MUST NOT be | encoded according to the Distiguished Encoding Rules (DER) of ASN.1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 001e : NULL 0020 : CONTEXT 1 0022 : SEQUENCE | 0024 : OBJECT IDENTIFIER id-mgf1 (1.2.840.113549.1.1.8) 002f : SEQUENCE 0031 : OBJECT IDENTIFIER id-sha256 (2.16.840.1.101.3.4.2.1) 003c : NULL 003e : CONTEXT 2 0040 : INTEGER 0x20 (6 bits) Name = RSASSA-PSS with sha-256, oid = 1.2.840.113549.1.1.10 | Length = 67 0000: 3046 0609 2a86 4886 f70d 0101 0a30 39a0 0010: 0f30 0d06 0960 8648 0165 0304 0201 0500 0020: a11c 301a 0609 2a86 4886 f70d 0101 0830 0030: 0d06 0960 8648 0165 0304 0201 0500 a203 | 0040: 0201 20 Notes ----- 1. The maskGenAlgorithm is in fact not SHA-256 (2.16.840.1.101.3.4.2.1), but MGF1 (1.2.840.113549.1.1.8) based on SHA-256 (2.16.840.1.101.3.4.2.1). 2. Section 3 requires the use of DER: The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. --VERIFIER NOTES-- Per Tero Kivinen: The id-mgf1 oid is there in the example, the tool I used didn't know the name for it thus it just printed out the oid. As this does not affect the binary object at all there is no problem in here. > 2. Section 3 requires the use of DER: > The ASN.1 used here is the same ASN.1 used in the > AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), > encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. Yes, but RFC4055 says that: trailerField The trailerField field is an integer. It provides compatibility with IEEE Std 1363a-2004 [P1363A]. The value MUST be 1, which represents the trailer field with hexadecimal value 0xBC. Other trailer fields, including the trailer field composed of HashID concatenated with 0xCC that is specified in IEEE Std 1363a, are not supported. Implementations that perform signature generation MUST omit the trailerField field, indicating that the default trailer field value was used. Implementations that perform signature validation MUST recognize both a present trailerField field with value 1 and an absent trailerField field. I.e. you should recognize both formats. Yes, we could have another example also showing the object value to used when generating these and when omitting the default values (like we do have for SHA-1). -------------------------------------- RFC7427 (draft-kivinen-ipsecme-signature-auth-07) -------------------------------------- Title : Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) Publication Date : January 2015 Author(s) : T. Kivinen, J. Snyder Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Mar 26 11:27:50 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9B21A9244; Thu, 26 Mar 2015 11:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENQtuXN9EsVj; Thu, 26 Mar 2015 11:27:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BD81A90AF; Thu, 26 Mar 2015 11:27:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326182747.1559.37011.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 11:27:47 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:27:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : The NULL Authentication Method in IKEv2 Protocol Authors : Valery Smyslov Paul Wouters Filename : draft-ietf-ipsecme-ikev2-null-auth-05.txt Pages : 13 Date : 2015-03-26 Abstract: This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 26 11:27:54 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6731A90C5; Thu, 26 Mar 2015 11:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1IhJ9f3ej6h; Thu, 26 Mar 2015 11:27:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAC01A90EF; Thu, 26 Mar 2015 11:27:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150326182747.1559.98009.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 11:27:47 -0700 Archived-At: Subject: [IPsec] New Version Notification - draft-ietf-ipsecme-ikev2-null-auth-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:27:49 -0000 A new version (-05) has been submitted for draft-ietf-ipsecme-ikev2-null-auth: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-null-auth-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Thu Mar 26 11:31:47 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F72B1A9248 for ; Thu, 26 Mar 2015 11:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdCCsofkH7xi for ; Thu, 26 Mar 2015 11:31:44 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19CC1A90BE for ; Thu, 26 Mar 2015 11:31:39 -0700 (PDT) Received: by lahp7 with SMTP id p7so33778834lah.2 for ; Thu, 26 Mar 2015 11:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=7/GWXXejtkEvjpUMQRKubhDxbNURTAhwrEPtY96PEHI=; b=YWU+BTk508h38SAPjmU3wBiR/Qb0canp6FE0izy6tg83C/OePgSBh1m+qigvRcjHbV 9Rc0S7Db1yxWWcvBTPCr3bB22M/ImFds6JeFr4ZzZdy0FcAPg3Z7vNtZwNZHntG1m7Hm hag6Ey7ETdf2eUcfwkDESFnnSqg1l7d/X1Fuw5uRjtV2Gohb9WxX6iPn1t7P5GL/B9AJ 24KTFl3CyTPbJjOA2TLgbk0ljACBMD+CdpkcLMnf/sy8vfcCIBdhbaMo1dq39hXyGgPo Qs3/nu2pQll1c4b7Pn5kln+yDrXIdnS8oHZEfZVGnWMFzi67fYLjy8wSFYPFPIBotfuw xkGg== X-Received: by 10.152.28.5 with SMTP id x5mr14261298lag.112.1427394698071; Thu, 26 Mar 2015 11:31:38 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id o2sm1099442lbs.4.2015.03.26.11.31.37 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 11:31:37 -0700 (PDT) Message-ID: <389D176E29774BDC91DBB5AD282E569A@buildpc> From: "Valery Smyslov" To: References: <20150326182747.1559.37011.idtracker@ietfa.amsl.com> Date: Thu, 26 Mar 2015 21:31:37 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-null-auth-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 18:31:46 -0000 Hi all, a new version of the draft is issued. It addresses the comments received from AD review and also fixes found typos and grammar errors. Valery & Paul. > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : The NULL Authentication Method in IKEv2 Protocol > Authors : Valery Smyslov > Paul Wouters > Filename : draft-ietf-ipsecme-ikev2-null-auth-05.txt > Pages : 13 > Date : 2015-03-26 > > Abstract: > This document specifies the NULL Authentication method and the > ID_NULL Identification Payload ID Type for the IKEv2 Protocol. This > allows two IKE peers to establish single-side authenticated or mutual > unauthenticated IKE sessions for those use cases where a peer is > unwilling or unable to authenticate or identify itself. This ensures > IKEv2 can be used for Opportunistic Security (also known as > Opportunistic Encryption) to defend against Pervasive Monitoring > attacks without the need to sacrifice anonymity. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-null-auth-05 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 26 16:08:08 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6D51A1A76; Thu, 26 Mar 2015 16:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVaux4iuOcSS; Thu, 26 Mar 2015 16:08:06 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A08D1A1AE6; Thu, 26 Mar 2015 16:08:02 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2QN80kW012729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Mar 2015 01:08:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2QN80nl020796; Fri, 27 Mar 2015 01:08:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21780.37200.119692.51021@fireball.kivinen.iki.fi> Date: Fri, 27 Mar 2015 01:08:00 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Cc: draft-ietf-ipsecme-ikev2-null-auth@ietf.org Subject: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 23:08:08 -0000 In the -05 version the last paragraph of the section 3 was changed, but I think it is missing some words: unauthenticated IKE peers. Implementations might have made assumptions remote peers are identified. With NULL Authentication I think it should be "Implementations might have made assumptions that remote peers are identified", or similar. -- kivinen@iki.fi From nobody Thu Mar 26 23:07:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676941A6EF4; Thu, 26 Mar 2015 23:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZELjpq2oo0s; Thu, 26 Mar 2015 23:07:35 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B071A1A62; Thu, 26 Mar 2015 23:07:34 -0700 (PDT) Received: by lbbzt2 with SMTP id zt2so4165062lbb.1; Thu, 26 Mar 2015 23:07:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=L3ddE1z2bb7eTVjjYi2EY1Iq2SgAj1ucigJMHaPJHBg=; b=M96Xd1f8bZzRiuhmY7uzdQWvbq4Rgba6vYN1wgbfNn0L/aX+451VZeP6rO7rhEhfmQ RT/QtcIOcsf7Xs6NErK2zkpNxHzvBfeBwzkrRAT0B7hAhdPueKnk8aRg0jMnFesevw91 iHD0hgf4YUv7JVh4aBqqMtwmF6rGjkNxLEl2L1LRhN/TtlzYs3aLT2yVUXqTqsuGtIzk EoRK/COrzcgiuNj35dPyf71QtBQQ3vl6dqsj7zl2UiyMsT3McMM3o35Vv6Op4LQ5IaOe jCr6wfRa248YJoZ5KHRxQ3VdPSCU6NDcGaSXT8NfX205Hb83tP/UutRE1U7vcv2kYAFp Zh2A== X-Received: by 10.112.235.38 with SMTP id uj6mr16711216lbc.9.1427436453206; Thu, 26 Mar 2015 23:07:33 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id kd7sm153225lbc.42.2015.03.26.23.07.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 26 Mar 2015 23:07:32 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> Date: Fri, 27 Mar 2015 09:07:31 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: draft-ietf-ipsecme-ikev2-null-auth@ietf.org Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 06:07:36 -0000 Hi Tero, I think the current text (with reduced "that") is grammatically correct and its meaning is clear. However, if you think that addind "that" would improve text clarity, I (and hopely Paul) have no objections to that. Regards, Valery. > In the -05 version the last paragraph of the section 3 was changed, > but I think it is missing some words: > > unauthenticated IKE peers. Implementations might have made > assumptions remote peers are identified. With NULL Authentication > > I think it should be "Implementations might have made assumptions that > remote peers are identified", or similar. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Mar 27 05:33:51 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA6E1ACD91 for ; Fri, 27 Mar 2015 05:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OT5HIcV-ielP for ; Fri, 27 Mar 2015 05:33:48 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85A891ACD93 for ; Fri, 27 Mar 2015 05:33:48 -0700 (PDT) Received: from dhcp-9076.meeting.ietf.org (dhcp-9076.meeting.ietf.org [31.133.144.118]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2RCX0X8072574 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Mar 2015 05:33:48 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 27 Mar 2015 07:33:47 -0500 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] Slides for today's meeting X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 12:33:49 -0000 ...are posted. You can find them at = https://datatracker.ietf.org/meeting/92/materials.html --Paul Hoffman= From nobody Fri Mar 27 11:21:36 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859D91B2AE5 for ; Fri, 27 Mar 2015 11:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, J_CHICKENPOX_45=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5wcMzG5wJCr for ; Fri, 27 Mar 2015 11:21:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C211B2B20 for ; Fri, 27 Mar 2015 11:20:19 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lDBLT43yNzJsJ for ; Fri, 27 Mar 2015 19:20:17 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1edfpEOhm_yt for ; Fri, 27 Mar 2015 19:20:15 +0100 (CET) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP for ; Fri, 27 Mar 2015 19:20:15 +0100 (CET) Received: by ns0.nohats.ca (Postfix, from userid 500) id 8CBB83F7EE; Fri, 27 Mar 2015 14:20:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id 8541A3F400 for ; Fri, 27 Mar 2015 14:20:15 -0400 (EDT) Date: Fri, 27 Mar 2015 14:20:15 -0400 (EDT) From: paul@nohats.ca To: ipsec@ietf.org Message-ID: User-Agent: Alpine 2.11 (LRH 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] IETF092 draft minutes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Mar 2015 18:21:34 -0000 IPsecME IETF-92 Dallas draft minutes [lots of technical projection issues] WG status report http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-0.pdf - authnull going into IETF LC https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-null-auth/ PaulW: we have an implementation, please interop test: oe.libreswan.org PaulW: we changed the word "audit" as someone told us that would require them to deliver a stack of papers as audit. Otherwise only language changes based on Kathleen's suggestions and questions. - ddos-protection https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/ chairs: draft not yet ready for WGLC. chairs: please keep discussion on the mailing list - not github chairs: more review needed, lots of new text. some interaction of authnull and ddos chairs: lets set an example in this WG for ideas useful in other WGs Tero: HIP also had some non-hashing method Yoav presenting his slide deck Some discussion about clients and how many bits to solve (while my laptop crashed and burned) Tero: dont have to limit IKE window size to 1 - you can just wait processing these Brian Wise: NO_ADDITIONL_SAS can be avoied by a new exchange? Tero: yes Miquel: you send puzzles to everyone - you dont know who that is. Same policy for phone and computer? Tero: there is no way out of that. channeled jabber: Tero adds: you can use different IKE window size for AUTH_NULL clients versus other Yaron: why not use puzzles after IKE SA is established? Tero: need to think/discuss about Tero: client could send multiple answers even before puzzle solved - and hope to get it before puzzle solved Brian: Yaron: complexity discussions. for cases when you dont like initiator response just fail it. don't add complexity The zero value. as initiator how do i decide what my peers are doing and how can i get in front of the queue? Tero: we have different initiators, the same puzzle level cannot fit all client types Yaron: desktops will have the upper hand to swamp the responder Brian: I thought the zero was silly. do we have to do computation first? Yaov: we have the key so it is one turn of the PRF and counting the number of zero bits Brian: zero is like half the solution, there needs to be more description on what happens on the responder side Tero: Two parts of the document. one describe the protocol for interop/implementors. second part (appendix?) on implementation details, on why we use certain heuristics for something and how various devices should try and implement. PaulH (no hats): Tero gave a very clear split suggestion - however with zero value the client side is that goes in between both. I dont want to see an appendix here. Implementors really needs to make a lot of guesses. belongs in main body of the document. Brian: I'm fine with tero's description. Valery: Mic: If responder figures out that the initiator solved relatively easy puzzle, but it takes it quite a lot of time Valery: Mic: The responder could figure out that the initiator is weak and give it more priority Valery: Mic: I agree with Tero that some kind of algorithm for responder must be in the draft. Yaron: determination. Scotts idea to make it more deterministic is worth while - even if it does not fix all issues of phone vs laptop Tero: as long as we keep the puzzle the way it is we have to set it to the worst case. occasionally initiators get lucky and get the easy puzzle. PaulH: while not busy pre-calculate to determine if it is easy or hard puzzle and remember Brian: Valery: Mic: I think that we cannot make puzzles deterministic givin the diversity of computational power of different clients Valery: Mic: Look at puzzle as to lottery - some are more lucky Tero: and botnets are usually desktops - the most powerful clients we have - chacha20poly1305 http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-2.pdf Yoav presenting Yaron: does arm have aes acceleration? Yoav: no. it has something called neon - not in phones but in tablets. has some advantages Steve Kent: the "civilian part" keep in mind several industry sectors make use of FIPS approved algos for liability purpose. If the motivation is performance, that is not a good argument anymore. Russ Housley chatted with NIST people and made optimized miplementation og P-256 so the performance of Curve25519 is not different enough. Performance is not a good reason. Tero: you cannor use curve25519 .... same for blake.... ? Tero: I hate the names A B and C. C for civilian is not a good name. Move UI out and do UI in separate document Yoav: I thought we'd have the answer of CRFG by now.... ??? from NIST: We received documents and proposal claiming they have to implement P-256 faster than Curve25519. Has not been verified. It is just a claim. PaulH: who will support with review or code: Tero,PaulW, Michael and Valery - AES CCM http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-3.pdf Daniel presenting Tero: get rid of aes-cbc. all small devices use ccm anyway Steve Kent: the process that generates the nonce or IV is within the boundary of the [application?] [ more talk about FIPS / certification ] We looked at this in the past - we provided citations to Daniel From nobody Fri Mar 27 23:26:15 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4A01A1BF8 for ; Fri, 27 Mar 2015 23:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFK6CzmRSjsO for ; Fri, 27 Mar 2015 23:26:10 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3551A1BE7 for ; Fri, 27 Mar 2015 23:26:10 -0700 (PDT) Received: from BY1PR03MB1339.namprd03.prod.outlook.com (25.162.109.21) by BY1PR03MB1338.namprd03.prod.outlook.com (25.162.109.20) with Microsoft SMTP Server (TLS) id 15.1.125.19; Sat, 28 Mar 2015 06:25:53 +0000 Received: from BY1PR03MB1339.namprd03.prod.outlook.com ([25.162.109.21]) by BY1PR03MB1339.namprd03.prod.outlook.com ([25.162.109.21]) with mapi id 15.01.0125.002; Sat, 28 Mar 2015 06:25:53 +0000 From: "suram@freescale.com" To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt Thread-Index: AQHQZxoJLoD+MINOh025/QrmNHmLWZ0xcGAQ Date: Sat, 28 Mar 2015 06:25:53 +0000 Message-ID: References: <20150325163740.23454.94089.idtracker@ietfa.amsl.com> In-Reply-To: <20150325163740.23454.94089.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [117.195.186.117] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1338; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377424004)(13464003)(377454003)(450100001)(77156002)(1720100001)(40100003)(106116001)(110136001)(102836002)(15975445007)(33656002)(2656002)(230783001)(46102003)(107886001)(2351001)(2420400003)(2501003)(122556002)(76176999)(54356999)(2950100001)(2900100001)(74316001)(50986999)(76576001)(92566002)(86362001)(19580405001)(99286002)(66066001)(19580395003)(87936001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1338; H:BY1PR03MB1339.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY1PR03MB1338; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1338; x-forefront-prvs: 05299D545B Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2015 06:25:53.1448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1338 Archived-At: Subject: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 06:26:13 -0000 SGksDQpBIG5ldyBJbnRlcm5ldCBEcmFmdCBpcyBwb3N0ZWQgdG8gdGhlIHdvcmtpbmcgZ3JvdXAu DQpUaGUgZHJhZnQgYWRkcmVzc2VzIGEgcHJvYmxlbSB3aGVyZSBOQVQgaXMgZW5hYmxlZCBkeW5h bWljYWxseSAoYWZ0ZXIgSVBzZWMgU0EgaXMgY3JlYXRlZCkgYmVjYXVzZSBvZiB3aGljaCB0cmFm ZmljIHN0b3BzLg0KVGhlIGRyYWZ0IHVzZXMgdGhlIGV4aXN0aW5nIElLRXYyIGZyYW1ld29yayAo d2l0aG91dCBkZWZpbmluZyBhbnkgbmV3IHBheWxvYWRzKSBhbmQgbWFpbnRhaW5zIGJhY2t3YXJk IGNvbXBhdGliaWxpdHkgd2l0aCBvbGRlciBpbXBsZW1lbnRhdGlvbnMgb2YgSUtFdjIgdGhhdCBk b2VzIG5vdCBzdXBwb3J0IHRoaXMgZHJhZnQuDQoNCldlIHJlcXVlc3QgeW91ciBmZWVkYmFjayBv biB0aGUgc2FtZS4NCg0KVGhhbmtpbmcgeW91Lg0KDQpSZWdhcmRzDQpzdXJhbQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjUs IDIwMTUgMTA6MDggUE0NClRvOiBCYXRjaHUgUmFtcHVsbGFpYWgtQjM4NTI2OyBWZW11bGFwYWxs aSBKeW90aGktQjM3Nzg0OyBCYXRjaHUgUmFtcHVsbGFpYWgtQjM4NTI2OyBTdXJhbSBDaGFuZHJh IFNla2hhci1CMzg1MjM7IFZlbXVsYXBhbGxpIEp5b3RoaS1CMzc3ODQ7IFN1cmFtIENoYW5kcmEg U2VraGFyLUIzODUyMw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1zdXJhbS1keW5hbWljLW5hdC10cmF2ZXJzYWwtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LXN1cmFtLWR5bmFtaWMtbmF0LXRyYXZlcnNhbC0wMC50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU3VyYW0gQ2hhbmRyYSBTZWtoYXIgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtc3VyYW0tZHluYW1pYy1u YXQtdHJhdmVyc2FsDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJSVBzZWMgdHJhdmVyc2FsIGluIER5 bmFtaWMgTkFUDQpEb2N1bWVudCBkYXRlOgkyMDE1LTAzLTI1DQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQk2DQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtc3VyYW0tZHluYW1pYy1uYXQtdHJhdmVyc2FsLTAwLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXN1cmFtLWR5bmFtaWMtbmF0LXRyYXZlcnNhbC8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdXJhbS1keW5hbWljLW5hdC10cmF2ZXJzYWwtMDANCg0K DQpBYnN0cmFjdDoNCiAgIE5BVCBjYW4gYmUgZW5hYmxlZCBvbiBhIFNlY3VyaXR5IEdhdGV3YXkg YnkgYWRtaW5pc3RyYXRvciBhdCBhbnkNCiAgIHBvaW50IG9mIHRpbWUuICBUaGlzIGNhbiBiZSBj YWxsZWQgYXMgRHluYW1pYyBOQVQuICBUaGUgZXhpc3RpbmcNCiAgIElLRXYyIFJGQyBkb2VzIG5v dCBhZGRyZXNzIHRoZSBzY2VuYXJpbyBvZiBOQVQgYmVpbmcgZW5hYmxlZCBvbiBhDQogICBzZWN1 cml0eSBnYXRld2F5IGFmdGVyIElLRXYyIG5lZ290aWF0aW9uLiAgSW4gc3VjaCBhIHNjZW5hcmlv LA0KICAgdHJhZmZpYyBzZW50IG92ZXIgdGhlIElQc2VjIFNBIHdpbGwgZWl0aGVyIGJlIGRyb3Bw ZWQgb3IgZG9lcyBub3QNCiAgIHJlYWNoIHRoZSBwZWVyIHNlY3VyaXR5IGdhdGV3YXkuICBUaGlz IGRvY3VtZW50IGRlZmluZXMgYSBtZXRob2QgdG8NCiAgIGVuc3VyZSB0aGF0IElQc2VjIHRyYWZm aWMgZmxvdyBzZWFtbGVzc2x5IGluIHN1Y2ggYSBzY2VuYXJpby4NCg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Sat Mar 28 10:16:00 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B9F1A7035 for ; Sat, 28 Mar 2015 10:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.59 X-Spam-Level: * X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sXB-8oEe92lG for ; Sat, 28 Mar 2015 10:15:56 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3211A88BF for ; Sat, 28 Mar 2015 10:15:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lDmsW4BdgzJsq; Sat, 28 Mar 2015 18:15:43 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id G1dHJwtMiYeG; Sat, 28 Mar 2015 18:15:42 +0100 (CET) Received: from ns0.nohats.ca (ns0.nohats.ca [IPv6:2a03:6000:1004:1::102]) by mx.nohats.ca (Postfix) with ESMTP; Sat, 28 Mar 2015 18:15:42 +0100 (CET) Received: by ns0.nohats.ca (Postfix, from userid 500) id 94BF53F464; Sat, 28 Mar 2015 13:15:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by ns0.nohats.ca (Postfix) with ESMTP id 91C0C3F431; Sat, 28 Mar 2015 13:15:42 -0400 (EDT) Date: Sat, 28 Mar 2015 13:15:42 -0400 (EDT) From: paul@nohats.ca To: "suram@freescale.com" In-Reply-To: Message-ID: References: <20150325163740.23454.94089.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.11 (LRH 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 17:15:58 -0000 On Sat, 28 Mar 2015, suram@freescale.com wrote: > A new Internet Draft is posted to the working group. > The draft addresses a problem where NAT is enabled dynamically (after IPsec SA is created) because of which traffic stops. > The draft uses the existing IKEv2 framework (without defining any new payloads) and maintains backward compatibility with older implementations of IKEv2 that does not support this draft. I was not aware this was a problem. So we should really support the use case. I'm not sure yet if this is the right approach. Does this typically happen "once" to a user, or these type of gateways keep switching the NATing on and off? If I'm correct, IKEv2 already requires peers to accept ESPinUDP even without NAT, and so an IKE peer could just enable that, upon which for at least tunnel mode, everything should keep on working. Detection of this based on ESP packets is a little tricky. It requires that the kernel makes a decision based on src/dst IP and existing policy to inform the IKE daemon in userland. Maybe this would be better attached to a liveness probe? There the IKE daemon itself becomes aware of the changed src/dst IP and could enable ESPinUDP. I think that would not even require a protocol change? Paul From nobody Sat Mar 28 14:08:12 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24291A872F for ; Sat, 28 Mar 2015 14:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ek4clReVp3y for ; Sat, 28 Mar 2015 14:08:10 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1899B1A1B96 for ; Sat, 28 Mar 2015 14:08:10 -0700 (PDT) Received: by wgbgs4 with SMTP id gs4so41594557wgb.0 for ; Sat, 28 Mar 2015 14:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Eb5q17z+EtLi7eUhLmsr6cFGOufWm2KbPSHyH98z3dM=; b=mAvaGeKXVfjBAKcSm4XDlewedSqevkmKTP6rOkNDfQtKe8GdLXtO0ED/Gfklre9TiL AD1AYhqDAvcVc0xzSUvaRNwBKLu8K6fQ3H7ja14O6ROhoNZsLcc07jOrprWxybvLN6MR CYUz8lBs5qq3E8JFVKv1qmjnrtYHthKt3ZqQhVpPemxu/z1ZEtP2R1KKWWTnjQGas1/w bf7ldduLg0XyTyNaPHB48azUSUCo39my5PhFvCPTqvFp6MF8pUU/CyL1nmIrtAB+vmKD hTp3udw5nzhyhVHKUZf59h+ZUyHLQmRj9lZ7Hswzpp3gJVJQ7UL+OQNU2b2AWkfjohei Y0vQ== X-Received: by 10.180.95.102 with SMTP id dj6mr8591905wib.45.1427576888812; Sat, 28 Mar 2015 14:08:08 -0700 (PDT) Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id hw7sm8600042wjb.24.2015.03.28.14.08.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Mar 2015 14:08:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Sun, 29 Mar 2015 00:08:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3B9D675A-309C-4F3F-BEC9-9D1A34BB62C9@gmail.com> References: To: IETF IPsec X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] Review for ChaCha20 draft (was: Re: IETF092 draft minutes) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 21:08:11 -0000 > On Mar 27, 2015, at 9:20 PM, paul@nohats.ca wrote: > - chacha20poly1305 = http://www.ietf.org/proceedings/92/slides/slides-92-ipsecme-2.pdf >=20 > Yoav presenting >=20 > Yaron: does arm have aes acceleration? > Yoav: no. it has something called neon - not in phones but in tablets. = has some advantages > Steve Kent: the "civilian part" keep in mind several industry sectors = make use of FIPS approved algos for liability > purpose. If the motivation is performance, that is not a good argument = anymore. Russ Housley chatted with NIST people > and made optimized miplementation og P-256 so the performance of = Curve25519 is not different enough. Performance is not > a good reason. > Tero: you cannor use curve25519 .... same for blake.... ? > Tero: I hate the names A B and C. C for civilian is not a good name. = Move UI out and do UI in separate document > Yoav: I thought we'd have the answer of CRFG by now.... > ??? from NIST: We received documents and proposal claiming they have = to implement P-256 faster than Curve25519. Has not > been verified. It is just a claim. > PaulH: who will support with review or code: Tero,PaulW, Michael and = Valery Hi In the meeting Kathleen asked how long the draft was. With all the = algorithm details moved to the CFRG draft, the entire document is six = pages, including introduction, IANA and security considerations, = references, and the UI suite stuff (that I agree with Tero that should = be moved out). The real =E2=80=9Cmeat=E2=80=9D of the document is section 2, which = spans a little over one page. HTH Yoav From nobody Sat Mar 28 14:36:33 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4B91A9035 for ; Sat, 28 Mar 2015 14:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HYYoNF0FvKfl for ; Sat, 28 Mar 2015 14:36:32 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E79BF1A9032 for ; Sat, 28 Mar 2015 14:36:31 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2SLaSVb043317 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Mar 2015 14:36:29 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 28 Mar 2015 14:36:27 -0700 Message-Id: <95AF2495-38BB-4547-8E90-F46635F10C6B@vpnc.org> To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Yoav Nir Subject: [IPsec] Adopted as a WG work item: Chacha20-Poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 21:36:32 -0000 Greetings again. At the Dallas meeting, we asked again about adoption of = draft-nir-ipsecme-chacha20-poly1305. We got one more promise to review, = so with at least five reviewers (Tero Kivinen, Paul Wouters, Jim = Knowles, Valery Smyslov, and Michael Richardson), the chairs believe = that this represents enough commitment for the WG to take on this work. At the meeting, the WG seemed inclined to not want the material in = Section 4 for a variety of reasons. Yoav: please publish = draft-ietf-ipsecme-chacha20-poly1305-00, minus Section 4, soon. We will = update the charter to indicate this work item, with an expected time to = IETF Last Call in May. --Paul Hoffman and Yaron Sheffer From nobody Sat Mar 28 17:35:24 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45FE31A90ED for ; Sat, 28 Mar 2015 17:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0zF8MEa95lM for ; Sat, 28 Mar 2015 17:35:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4E61A90EA for ; Sat, 28 Mar 2015 17:35:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150329003520.20311.11778.idtracker@ietfa.amsl.com> Date: Sat, 28 Mar 2015 17:35:20 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 00:35:22 -0000 Changed milestone "IETF Last Call on null authentication", set due date to April 2015 from December 2015. URL: http://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Sat Mar 28 17:37:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EB21A01A8 for ; Sat, 28 Mar 2015 17:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uwSFn1kSxgf for ; Sat, 28 Mar 2015 17:37:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C52011A0275 for ; Sat, 28 Mar 2015 17:37:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150329003725.20182.93210.idtracker@ietfa.amsl.com> Date: Sat, 28 Mar 2015 17:37:25 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 00:37:27 -0000 Deleted milestone "IETF Last Call on large scale VPN use cases and requirements". URL: http://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Sat Mar 28 17:37:43 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E8C1A02BE for ; Sat, 28 Mar 2015 17:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NceOFrJNrbor for ; Sat, 28 Mar 2015 17:37:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1B61A0338 for ; Sat, 28 Mar 2015 17:37:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150329003740.18953.57479.idtracker@ietfa.amsl.com> Date: Sat, 28 Mar 2015 17:37:40 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 00:37:41 -0000 Deleted milestone "IETF last call on IKE fragmentation solution". URL: http://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Sat Mar 28 17:37:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C561A00DB for ; Sat, 28 Mar 2015 17:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1all55tEQ3uA for ; Sat, 28 Mar 2015 17:37:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 723061A037C for ; Sat, 28 Mar 2015 17:37:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150329003752.14400.81951.idtracker@ietfa.amsl.com> Date: Sat, 28 Mar 2015 17:37:52 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 00:37:56 -0000 Deleted milestone "IETF last call on new mandatory-to-implement algorithms". URL: http://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Sat Mar 28 17:40:52 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD541A037C for ; Sat, 28 Mar 2015 17:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7lT9QKfZq3M for ; Sat, 28 Mar 2015 17:40:50 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7EF1A036C for ; Sat, 28 Mar 2015 17:40:50 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2T0ensI048204 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Mar 2015 17:40:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 28 Mar 2015 17:40:48 -0700 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] That last bunch of milestone changes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 00:40:51 -0000 Greetings. I deleted the old "done" milestones from the charter because = no one will understand them any more. I also moved the expectation for = IETF Last Call for null-auth to April, after Kathleen finishes her = re-review. I also put in a request to Kathleen to accept a milestone for = Chacha20-Poly1305. --Paul Hoffman= From nobody Mon Mar 30 06:16:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2096A1A899F for ; Mon, 30 Mar 2015 06:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWzUbnmlwiEU for ; Mon, 30 Mar 2015 06:16:34 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F5C51A87E2 for ; Mon, 30 Mar 2015 06:16:33 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2UDGPxE025531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Mar 2015 16:16:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2UDGOsT026039; Mon, 30 Mar 2015 16:16:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21785.19623.491977.563080@fireball.kivinen.iki.fi> Date: Mon, 30 Mar 2015 16:16:23 +0300 From: Tero Kivinen To: "suram\@freescale.com" In-Reply-To: References: <20150325163740.23454.94089.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: Cc: "ipsec@ietf.org" Subject: [IPsec] FW: New Version Notification for draft-suram-dynamic-nat-traversal-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 13:16:36 -0000 suram@freescale.com writes: > A new Internet Draft is posted to the working group. > The draft addresses a problem where NAT is enabled dynamically > (after IPsec SA is created) because of which traffic stops. This is already supported when MOBIKE is used, and without MOBIKE the IP-addresses cannot change, thus NAT cannot suddenly appear in the middle. Can you explain in which situations the NAT will be enbled after the IKEv2 connection has been creteated in such way that IP-addresses of both end points stay same? If the IP-addresses change, then to be able to keep the same IKEv2 connection you need to use MOBIKE and MOBIKE will already automatically enable NAT if it detects NAT while moving traffic from one IP-address to another. > The draft uses the existing IKEv2 framework (without defining any > new payloads) and maintains backward compatibility with older > implementations of IKEv2 that does not support this draft. > > We request your feedback on the same. Can you explain what is problem with the already standardized solution to this problem, and why do you think it does not solve the issue? -- kivinen@iki.fi From nobody Mon Mar 30 06:32:39 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF291ACEC9; Mon, 30 Mar 2015 06:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7awNeh3k5ZI; Mon, 30 Mar 2015 06:32:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7B81ACEC1; Mon, 30 Mar 2015 06:32:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> Date: Mon, 30 Mar 2015 06:32:37 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 13:32:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IPsec Author : Yoav Nir Filename : draft-ietf-ipsecme-chacha20-poly1305-00.txt Pages : 6 Date : 2015-03-29 Abstract: This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 30 07:07:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ABC1ACEED for ; Mon, 30 Mar 2015 07:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcyFy7G30J7S for ; Mon, 30 Mar 2015 07:07:23 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39BFD1ACEFF for ; Mon, 30 Mar 2015 07:06:46 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2UE6iuJ009605 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Mar 2015 07:06:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4A981ECD-54EE-4C28-93CE-3A138E4AF07F@vpnc.org> Date: Mon, 30 Mar 2015 07:06:44 -0700 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] Please review draft-ietf-ipsecme-chacha20-poly1305 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 14:07:24 -0000 Greetings. We have a new short draft in the WG, and would like to get = reviews soon so we can move it into WG Last Call in about two weeks. We = are not in a rush, but we also don't need to delay this too much. We have five committed reviewers, but it would very useful if we had a = few more. If you are an implementer, or just good at crypto, please = consider doing a review now. If you have questions about how to review, = feel free to reach out to me in personal mail. --Paul Hoffman= From nobody Mon Mar 30 07:40:00 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B083C1A877A; Mon, 30 Mar 2015 07:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ3Ecac-d8K3; Mon, 30 Mar 2015 07:39:54 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBE41A1EEE; Mon, 30 Mar 2015 07:39:54 -0700 (PDT) Received: by wicne17 with SMTP id ne17so34207337wic.0; Mon, 30 Mar 2015 07:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TJCqEykSf0agogng3IQ1ykkWtRFZViBWKsUCW4iDzo0=; b=mpn775ep4h9FoGGoqLDOx/oKlQ+YLFUR4bQsPN9VKVSez2tMLcvg5ZEObnBVVgq1Ws ZMQkt0H0QrHTRtaNkVvL/tgVjzY1EPFZLDCdDLP0G2mHvDYzIQlQNoU/csNcLm2AX0VY XLq8A3t/St9ODXMG8mLWUAjN1gn5BApXjMDQUrcnYLgRKkEschGmVjtAkxAuUQ9yQpwj YP7PJkiBtVmfnLa0cQHDkTCu3QOGPZdi61awXypbhkZQX5tTYkFXs10yrC2l5expn61x hZ1P+47+JUlHfuoyy31tWafN/TUrIl8t4e2sSG9r4jjbbbKjNwgCkAJ2ffVMEo8FFAPy 9DnA== X-Received: by 10.180.24.233 with SMTP id x9mr23767050wif.9.1427726392790; Mon, 30 Mar 2015 07:39:52 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ch6sm16049304wjc.3.2015.03.30.07.39.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Mar 2015 07:39:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> Date: Mon, 30 Mar 2015 17:39:48 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: ipsec@ietf.org, i-d-announce@ietf.org Subject: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 14:39:58 -0000 Hi, There is two questions I would like guidance from the group about. First is the nonce/IV question: In the current draft, there is a 64-bit = IV with guidance not to repeat them (so use a counter or LFSR). The = function itself accepts a 96-bit input nonce, so the nonce is = constructed from the 64-bit IV and 32 zero bits. The reason for doing = this is so the algorithm could be used in a multi-sender case such as = GDOI, where the 32-bit zero can be replaced by a sender ID. = Alternatively, we could generate a 32-bit salt value from the key = material, but I don=E2=80=99t see a reason why we=E2=80=99d want that. = Another thing we could do is what some people are advocating for TLS: = Since a counter is a fine IV (no need for secrecy), we don=E2=80=99t = need a 64-bit IV that has the exact same value as the replay counter. We = might as well save 8 bytes per packet and just feed the replay counter = to the function. The argument against this is that some crypto modules = may have the API set up in such a way that the IVs are generated within = the module and could be something other than a counter (like an LFSR). = The proposal will break such APIs. Second issue is about UI advice. Some implementations (yes, mine is = included) allow the user to configure encryption algorithm, MAC = algorithm, and D-H group. There is no setting for PRF since such UIs = date back to IKEv1. The PRF is usually just taken from the setting for = MAC algorithm. This works fine as long as all supported MAC algorithms = are HMAC, XCBC, and CMAC. AES-GCM would have the same issue, but RFC = 5282 makes no mention of this issue. I=E2=80=99m wondering if we should = recommend to pair this algorithm in IKE with PRF_HMAC_SHA2_256. Thanks Yoav= From nobody Mon Mar 30 08:15:17 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607051AD05C for ; Mon, 30 Mar 2015 08:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DpnnjwZ9f0dL for ; Mon, 30 Mar 2015 08:15:14 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1659D1AD060 for ; Mon, 30 Mar 2015 08:15:12 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so134629716wib.1 for ; Mon, 30 Mar 2015 08:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=Yh2IMp3mP9r8ri1+z3X+1TL4HYDVHaBlgE6MZVbQtb0=; b=zlZ+5DC4wShEXKjyjzrw8XKpNK9uhSxXsIG4f3xzy6tylRiABm2qXwj1dfHzHeOh9a rmJYV9KgLkBBfVwoW8kg7gY+82IIR7+/FOzW7U+lrkOpdw/oWyr/0tiXqVp5ARoqV9iT j+kMeBxBXGDsNLTcy5clF/qNNYAOkUpYmg5ClpeRXfp/oEjWd7yrytYepUYldQB7Kl82 6v1TlR0MWOHcI9K60YzUIzPDYHHWkBIznRfA0dKOy/IoNQygNORYBe1ue9vS4mPnZ+JQ gQCW9PTaPqAGKVlRc986EDGV+TfAimsNoRzxmBawEAix2sH6gFEkwGLO7KOQ/eKBl7CN a/UA== X-Received: by 10.180.77.166 with SMTP id t6mr24082546wiw.52.1427728510763; Mon, 30 Mar 2015 08:15:10 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id y14sm16151249wjr.39.2015.03.30.08.15.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Mar 2015 08:15:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> Date: Mon, 30 Mar 2015 18:15:07 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <82E3B176-6865-4137-859D-CFD36FDB030F@gmail.com> References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> To: IETF IPsec X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 15:15:15 -0000 Arrgh. Please don=E2=80=99t reply-all to my previous message, because it = was mistakenly directed to I-D announce=E2=80=A6 > On Mar 30, 2015, at 5:39 PM, Yoav Nir wrote: >=20 > Hi, >=20 > There is two questions I would like guidance from the group about. >=20 > First is the nonce/IV question: In the current draft, there is a = 64-bit IV with guidance not to repeat them (so use a counter or LFSR). = The function itself accepts a 96-bit input nonce, so the nonce is = constructed from the 64-bit IV and 32 zero bits. The reason for doing = this is so the algorithm could be used in a multi-sender case such as = GDOI, where the 32-bit zero can be replaced by a sender ID. = Alternatively, we could generate a 32-bit salt value from the key = material, but I don=E2=80=99t see a reason why we=E2=80=99d want that. = Another thing we could do is what some people are advocating for TLS: = Since a counter is a fine IV (no need for secrecy), we don=E2=80=99t = need a 64-bit IV that has the exact same value as the replay counter. We = might as well save 8 bytes per packet and just feed the replay counter = to the function. The argument against this is that some crypto modules = may have the API set up in such a way that the IVs are generated within = the module and could be something other than a counter (like an LFSR). = The proposal will break such APIs. >=20 >=20 > Second issue is about UI advice. Some implementations (yes, mine is = included) allow the user to configure encryption algorithm, MAC = algorithm, and D-H group. There is no setting for PRF since such UIs = date back to IKEv1. The PRF is usually just taken from the setting for = MAC algorithm. This works fine as long as all supported MAC algorithms = are HMAC, XCBC, and CMAC. AES-GCM would have the same issue, but RFC = 5282 makes no mention of this issue. I=E2=80=99m wondering if we should = recommend to pair this algorithm in IKE with PRF_HMAC_SHA2_256. >=20 > Thanks >=20 > Yoav From nobody Mon Mar 30 10:42:31 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579BF1A907A; Mon, 30 Mar 2015 10:42:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFa1UzXFpkH1; Mon, 30 Mar 2015 10:42:29 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7D581A9068; Mon, 30 Mar 2015 10:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3108; q=dns/txt; s=iport; t=1427737349; x=1428946949; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Rj/ivOqOpnlFiO5vp5zmv8u5jMculqouFF3Aefn6/EY=; b=PL7DCyj6KY8Gr5RnQT7U2oaFvV3vmryOvHNldKJylnPvaLOeTZF9RIX7 Ds6UafFk8Hu5BcoKjZAqpC6SZvNQ3KakbYF0r8cNNBiG5UoLaT0s/y8Lp 6siJEB7bYVJ60AQyPhBJsMRufXjQ2+In1VFrgJLJ9rEqA7s7oYc2JESKL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AvBQBLihlV/5xdJa1cgwaBLgSDD8gfAhyBHUwBAQEBAQF9hBQBAQEDASMRRQUHBAIBCA4DBAEBAwIGHQMCAgIwFAEICAIEAQ0FCIgfCLJImHcBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKCIRHFhsHBoJiL4EWAQSQXJ4pIoNub4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,495,1422921600"; d="scan'208";a="136697522" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 30 Mar 2015 17:42:28 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t2UHgRnK001598 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Mar 2015 17:42:27 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Mon, 30 Mar 2015 12:42:27 -0500 From: "Scott Fluhrer (sfluhrer)" To: Yoav Nir , "internet-drafts@ietf.org" Thread-Topic: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 Thread-Index: AQHQavdqfbVtITbEkkWmolKMjGVLV501RvGA Date: Mon, 30 Mar 2015 17:42:27 +0000 Message-ID: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> In-Reply-To: <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.87] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , "i-d-announce@ietf.org" Subject: Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 17:42:30 -0000 DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSVBzZWMgW21haWx0bzppcHNlYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9hdiBOaXINClNlbnQ6IE1vbmRheSwgTWFy Y2ggMzAsIDIwMTUgMTA6NDAgQU0NClRvOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCkNjOiBp cHNlY0BpZXRmLm9yZzsgaS1kLWFubm91bmNlQGlldGYub3JnDQpTdWJqZWN0OiBbSVBzZWNdIFR3 byBxdWVzdGlvbnMgYWJvdXQgZHJhZnQtaWV0Zi1pcHNlY21lLWNoYWNoYTIwLXBvbHkxMzA1LTAw DQoNCj4gSGksDQo+IA0KPiBUaGVyZSBpcyB0d28gcXVlc3Rpb25zIEkgd291bGQgbGlrZSBndWlk YW5jZSBmcm9tIHRoZSBncm91cCBhYm91dC4NCj4gDQo+IEZpcnN0IGlzIHRoZSBub25jZS9JViBx dWVzdGlvbjogSW4gdGhlIGN1cnJlbnQgZHJhZnQsIHRoZXJlIGlzIGEgNjQtYml0IElWIHdpdGgg Z3VpZGFuY2Ugbm90IHRvIHJlcGVhdCB0aGVtIChzbyB1c2UgYSBjb3VudGVyIG9yIExGU1IpLiBU aGUgZnVuY3Rpb24gaXRzZWxmIGFjY2VwdHMgYSA5Ni1iaXQgaW5wdXQgbm9uY2UsIHNvIHRoZSBu b25jZSBpcyBjb25zdHJ1Y3RlZCBmcm9tIHRoZSA2NC1iaXQgSVYgYW5kIDMyIHplcm8gYml0cy4g VGhlIHJlYXNvbiBmb3IgZG9pbmcgdGhpcyBpcyBzbyB0aGUgYWxnb3JpdGhtIGNvdWxkIGJlIHVz ZWQgaW4gYSBtdWx0aS1zZW5kZXIgY2FzZSBzdWNoIGFzIEdET0ksIHdoZXJlIHRoZSAzMi1iaXQg emVybyBjYW4gYmUgcmVwbGFjZWQgYnkgYSBzZW5kZXIgSUQuIA0KDQpUaGlzIGlkZWEgYWJvdXQg dGhlIG11bHRpLXNlbmRlciBjYXNlIHdvcmtzIG9ubHkgaWYgdGhlIHRoZXJlJ3MgYSBzZW5kZXIg aWQgc29tZXdoZXJlIGluIHRoZSBlbmNyeXB0ZWQgcGFja2V0Lg0KDQo+IEFsdGVybmF0aXZlbHks IHdlIGNvdWxkIGdlbmVyYXRlIGEgMzItYml0IHNhbHQgdmFsdWUgZnJvbSB0aGUga2V5IG1hdGVy aWFsLCBidXQgSSBkb27igJl0IHNlZSBhIHJlYXNvbiB3aHkgd2XigJlkIHdhbnQgdGhhdC4NCg0K SGVyZSdzIHRoZSByZWFzb24gdGhhdCB3ZSBkbyB1c2UgdGhlIDMyLWJpdCBzYWx0IHZhbHVlIGZv ciBHQ00gLSB0byBwcmV2ZW50IGJhdGNoaW5nIGF0dGFja3MuDQoNCkNvbnNpZGVyIHRoZSBjYXNl IHRoYXQgYW4gYXR0YWNrZXIgaXMgYWJsZSB0byBjb2xsZWN0IHBhY2tldHMgZnJvbSBhIGJpbGxp b24gKDJeMzApIHNlc3Npb25zOyBlYWNoIHN1Y2ggc2Vzc2lvbiBjb250YWlucyBhIHBhY2tldCB3 aXRoIHRoZSBzYW1lIElWIChzYXksIElWPTApLCBhbmQgY29udGFpbnMgYSBwYWNrZXQgd2l0aCB0 aGUgc2FtZSBrbm93biBwbGFpbnRleHQgKG9yLCBhdCBsZWFzdCwgcGxhaW50ZXh0IHRoYXQgc2F0 aXNmaWVzIHRoZSBzYW1lIGtub3duIGxpbmVhciBlcXVhdGlvbnMpLiAgVGhlbiwgd2hhdCBhbiBh dHRhY2tlciBjYW4gZG8gaXMgY2hlY2sgYSBrZXkgdG8gc2VlIGlmIGFueSBvZiB0aGUgSVY9MCBw YWNrZXRzIHVzZWQgdGhhdCBrZXksIGluIGNvbnN0YW50IHRpbWUuICBUaGUgcmVkdWNlcyB0aGUg ZWZmb3J0IGZvciBhbiBhdHRhY2tlciB0byBmaW5kIHRoZSBuIGJpdCBrZXkgZm9yIHNvbWUgc2Vz c2lvbiBmcm9tIDJebiB0byAyXntuLTMwfS4gIFdoYXQgdGhlIHNhbHQgZG9lcyBpcyBtdWx0aXBs eSB0aGUgZWZmb3J0IGludm9sdmVkIGluIHRoaXMgc3BlY2lmaWMgYXR0YWNrIGJ5IGEgZmFjdG9y IG9mIDJeMzIgKGJlY2F1c2UgdGhlIGF0dGFja2VyIG5lZWRzIHRvIGd1ZXNzIHRoZSBrZXkgYW5k IHRoZSBzYWx0KTsgdGhhdCB3YXksIHRoZSBhdHRhY2tlciBuZWVkcyB0byBjb2xsZWN0IDQgYmls bGlvbiBzZXNzaW9ucyBiZWZvcmUgdGhpcyBhdHRhY2sgc3RhcnRzIHRvIGhhdmUgYW55IGFkdmFu dGFnZSBvdmVyIGEgc2ltcGxlciBhdHRhY2sgdGhhdCBqdXN0IGF0dGFja3MgYSBzaW5nbGUgcGFj a2V0ICh3aGljaCB0aGUgc2FsdCBkb2VzbuKAmXQgcHJvdGVjdCBhZ2FpbnN0KS4NCg0KTm93LCBv ZiBjb3Vyc2UsIGNoYWNoYTIwIGhhcyAyNTYgYml0IGtleXM7IGhlbmNlIGV2ZW4gaWYgd2UgZGVj aWRlZCBub3QgdG8gYXBwbHkgdGhlIHNhbWUgcHJvdGVjdGlvbiwgc29tZW9uZSB3aXRoIGEgY29s bGVjdGlvbiBvZiBhIGJpbGxpb24gc2Vzc2lvbnMgbWlnaHQgYmUgYWJsZSB0byB1c2UgdGhpcyB0 byByZWR1Y2UgdGhlIGVmZm9ydCB0byAyXjIyNi4NCg0KSSdsbCBsZXQgeW91IGRlY2lkZSB3aGV0 aGVyIHRoaXMgaXMgYSBjb21wZWxsaW5nIGFyZ3VtZW50IG9yIG5vdC4uLg0KDQo= From nobody Mon Mar 30 13:56:28 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91751ACEE6; Mon, 30 Mar 2015 13:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z7uHN33ljM9; Mon, 30 Mar 2015 13:56:25 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3CA31A89A1; Mon, 30 Mar 2015 13:56:22 -0700 (PDT) Received: by lbdc10 with SMTP id c10so49885700lbd.2; Mon, 30 Mar 2015 13:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vO067PXVjnQIwM7PA2nEqRIUznRArlRXNQfBYk4hm8A=; b=o58+YE68GrxLUQT/JbTbr5tb6AMh8F5gA5/T/Y79kTsa3K3QhHPUt27/zjnmKs+umI wpJx7j3+IWWpkV2kikqzKfRVjeTuozuJlWcAXjPPnu9Kn738LC2f3z7h34eUpibZ0dpG E7g3La1XkQju5BHJbyXHqJHTN/03srM4YoMX5EPQ0142fFWYXt245Jya/2GQjffnMaR1 nZBEFlleetLsFB0tWKzpI4VawMVQxAiUIk2EIxFquIAZwJMddZ6fLMnqUxRCKd/9/ypK uA1IlMNB9Mrhl6xLLn7vjEmW8qwyV6dXfzIa/62u8f9J9x//lNOvvhgQVkEF5ufimxkm Uj9A== MIME-Version: 1.0 X-Received: by 10.152.19.199 with SMTP id h7mr29025233lae.32.1427748981369; Mon, 30 Mar 2015 13:56:21 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Mon, 30 Mar 2015 13:56:21 -0700 (PDT) In-Reply-To: References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> Date: Mon, 30 Mar 2015 16:56:21 -0400 Message-ID: From: Kathleen Moriarty To: Valery Smyslov Content-Type: multipart/alternative; boundary=089e014942aadcf191051287b64d Archived-At: Cc: "ipsec@ietf.org" , draft-ietf-ipsecme-ikev2-null-auth@ietf.org, Tero Kivinen Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2015 20:56:27 -0000 --089e014942aadcf191051287b64d Content-Type: text/plain; charset=UTF-8 Hello, Thanks for making most of the suggested changes to the draft. I see nothing happened in section 2.4 with the 'updates' text. Since this requires changes to the referenced draft, it's easier to just state what is being updated in the previous RFC with this draft. Could we work on that change and have it ready soon? I'd rather do this before IETF last call or in IESG review as I think it pretty clearly should be done. The next telechat is April 9th and this won't make it on it, so there is time to get this update ready without holding up the draft. Thanks! On Fri, Mar 27, 2015 at 2:07 AM, Valery Smyslov wrote: > Hi Tero, > > I think the current text (with reduced "that") is grammatically correct and > its meaning is clear. However, if you think that addind "that" would > improve text clarity, I (and hopely Paul) have no objections to that. > > Regards, > Valery. > > > In the -05 version the last paragraph of the section 3 was changed, >> but I think it is missing some words: >> >> unauthenticated IKE peers. Implementations might have made >> assumptions remote peers are identified. With NULL Authentication >> >> I think it should be "Implementations might have made assumptions that >> remote peers are identified", or similar. >> -- >> kivinen@iki.fi >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Best regards, Kathleen --089e014942aadcf191051287b64d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Thanks for making most of the su= ggested changes to the draft.=C2=A0 I see nothing happened in section 2.4 w= ith the 'updates' text.=C2=A0 Since this requires changes to the re= ferenced draft, it's easier to just state what is being updated in the = previous RFC with this draft.=C2=A0 Could we work on that change and have i= t ready soon?=C2=A0 I'd rather do this before IETF last call or in IESG= review as I think it pretty clearly should be done.

The next telechat is April 9th and this won't make it on it, so ther= e is time to get this update ready without holding up the draft.
=
Thanks!

On Fri, Mar 27, 2015 at 2:07 AM, Valery Smyslov <svanru@g= mail.com> wrote:
Hi Tero,=

I think the current text (with reduced "that") is grammatically c= orrect and
its meaning is clear. However, if you think that addind "that" wo= uld
improve text clarity, I (and hopely Paul) have no objections to that.

Regards,
Valery.


In the -05 version the last paragraph of the section 3 was changed,
but I think it is missing some words:

=C2=A0 unauthenticated IKE peers.=C2=A0 Implementations might have made
=C2=A0 assumptions remote peers are identified.=C2=A0 With NULL Authenticat= ion

I think it should be "Implementations might have made assumptions that=
remote peers are identified", or similar.
--
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
=

Best regards,
Kathleen
--089e014942aadcf191051287b64d-- From nobody Mon Mar 30 17:51:21 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3993F1A7021; Mon, 30 Mar 2015 17:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-Wm5H4GMM8G; Mon, 30 Mar 2015 17:51:19 -0700 (PDT) Received: from proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD5D1A7002; Mon, 30 Mar 2015 17:51:19 -0700 (PDT) Received: from [10.20.30.101] (50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95]) (authenticated bits=0) by proper.com (8.15.1/8.14.9) with ESMTPSA id t2V0pFED073674 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Mar 2015 17:51:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-51-95.dsl.dynamic.fusionbroadband.com [50.1.51.95] claimed to be [10.20.30.101] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Paul Hoffman In-Reply-To: Date: Mon, 30 Mar 2015 17:51:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21780.37200.119692.51021@fireball.kivinen.iki.fi> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov , draft-ietf-ipsecme-ikev2-null-auth@ietf.org, Tero Kivinen Subject: Re: [IPsec] draft-ietf-ipsecme-ikev2-null-auth-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 00:51:20 -0000 On Mar 30, 2015, at 1:56 PM, Kathleen Moriarty = wrote: > Thanks for making most of the suggested changes to the draft. I see = nothing happened in section 2.4 with the 'updates' text. Since this = requires changes to the referenced draft, it's easier to just state what = is being updated in the previous RFC with this draft. Could we work on = that change and have it ready soon? I'd rather do this before IETF last = call or in IESG review as I think it pretty clearly should be done. My interpretation from the WG discussion was that there was consensus = that this document doesn't need to be marked as "updates RFC 4301". I = updated the shepherd report to indicate that the WG defers to the IESG = on judgement about this. > The next telechat is April 9th and this won't make it on it, so there = is time to get this update ready without holding up the draft. Unless you want us to make more changes to the draft, you might as well = put this into IETF Last Call now, even though it will miss the next = telechat. --Paul Hoffman= From nobody Tue Mar 31 02:15:27 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044F21A1AAA for ; Tue, 31 Mar 2015 02:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCSLqj_8lEgo for ; Tue, 31 Mar 2015 02:15:24 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 179121A1B0B for ; Tue, 31 Mar 2015 02:15:24 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so17708249wib.1 for ; Tue, 31 Mar 2015 02:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=va6lqKBeUg6guzLEia7Bo6XGKOSlx+PkdA4Cd5l9qQg=; b=syPJXRs2U+es5BMssFPGYU6I8NdInD8jY0CArg34WG2ATQNH/g+6uML/+go9stsn02 gUHpJcMm/Zv8EpYR/6mytD3oekDUMV+0AAtAeYO6H/8KpqZj1qgiLtwSNj4ALZTx0bU7 SEpMBKjD7rYCrw86z93Sv7eqnVT/q05QsTt3h0PPMkXBk0msunkRCmBAuSCrj5q3SGXC YATEWvxreKdpYLXZ28sAdJPLLF46GJ+zD+U+P0WkHCu+uGmxwz4a+bjrqrHkmyvfWmeB mPAmOEAc20h4txWkYf2wSerp5gbmmMYMq/Ace2IcKskqWMQuoPvnwLEtlPCw4OOfgAj8 /AbQ== X-Received: by 10.180.86.162 with SMTP id q2mr3771107wiz.26.1427793321710; Tue, 31 Mar 2015 02:15:21 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ey10sm20041255wib.2.2015.03.31.02.15.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 02:15:20 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_7CF2D17A-71CA-4DCE-BF36-C4979050869B" Date: Tue, 31 Mar 2015 12:15:17 +0300 References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> To: IETF IPsec Message-Id: Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 09:15:26 -0000 --Apple-Mail=_7CF2D17A-71CA-4DCE-BF36-C4979050869B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One more thing. I would like to request early code point assignment for = ESP_ChaCha20-Poly1305. I know that it is the goal of the chairs to bring this to LC sooner = rather than later, but I would like to get started on implementation = sooner rather than later, and the IETF process takes three months at = best, and six months in the more common case. Thanks Yoav > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > To: > Date: March 30, 2015 at 4:32:37 PM GMT+3 > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action: = draft-ietf-ipsecme-chacha20-poly1305-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >=20 > Title : ChaCha20, Poly1305 and their use in IPsec > Author : Yoav Nir > Filename : draft-ietf-ipsecme-chacha20-poly1305-00.txt > Pages : 6 > Date : 2015-03-29 >=20 > Abstract: > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > IPsec. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_7CF2D17A-71CA-4DCE-BF36-C4979050869B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii One more thing.

I would like to request early code point assignment = for ESP_ChaCha20-Poly1305.

I know that it is the goal of the = chairs to bring this to LC sooner rather than later, but I would like to = get started on implementation sooner rather than later, and the IETF = process takes three months at best, and six months in the more common = case.

Thanks

Yoav

Begin forwarded = message:

From: = internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Date: = March 30, 2015 at 4:32:37 PM = GMT+3
Cc: = ipsec@ietf.org
Subject: = [IPsec] I-D = Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt


A = New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IP Security = Maintenance and Extensions Working Group of the IETF.

       Title =           : ChaCha20, = Poly1305 and their use in IPsec
=        Author =          : Yoav Nir
= Filename        : = draft-ietf-ipsecme-chacha20-poly1305-00.txt
Pages =           : 6
= Date =            : = 2015-03-29

Abstract:
=   This document describes the use of the ChaCha20 stream = cipher along
  with the Poly1305 authenticator, = combined into an AEAD algorithm for
  IPsec.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-po= ly1305/

There's also a htmlized version = available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305= -00


Please note that it may = take a couple of minutes from the time of submission
until = the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_7CF2D17A-71CA-4DCE-BF36-C4979050869B-- From nobody Tue Mar 31 03:05:06 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5267B1A8A27 for ; Tue, 31 Mar 2015 03:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCI53cWd4wPh for ; Tue, 31 Mar 2015 03:05:03 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F9F1A8A11 for ; Tue, 31 Mar 2015 03:05:01 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2VA4tCb005855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 13:04:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2VA4sln002035; Tue, 31 Mar 2015 13:04:54 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21786.28998.830814.421934@fireball.kivinen.iki.fi> Date: Tue, 31 Mar 2015 13:04:54 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 43 min Archived-At: Cc: "ipsec@ietf.org WG" Subject: [IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:05:05 -0000 Paul Wouters writes: > I was looking at the interaction of draft-kivinen-ipsecme-oob-pubkey and > IPSECKEY, since IPSECKEY has an algorithm number but oob-pubkey uses the > SubjectPublicKeyInfo that encodes the algorithm in the SPKI value > itself. I am missing what is the issue here. When you get public key inside the IKEv2 in raw form, you extract the key from there (i.e. decode the ASN.1 and get the key out in internal public key representation). Then you fetch the key from IPSECKEY records and do the same, i.e. again parse the key from DNS record to the internal public key representation. Now you have two public keys, and after that you simply compare them, and thats it. If they match you know that the key used in IKE is same than in DNS. Another use is that you fetch the public key for the other end directly from the IPSECKEY DNS records, and use it, i.e. you ignore the key other end sends to you. > So first, if we were to fix this for IPSECKEY (and I'm not yet > convinced we are there yet, as we might end up with updating > IPSECKEY due to other issues we'll find over the next few months) we > might consider allocating a special algorithm number to signify this > in the IKE Authentication Method registry at > > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 > > For instance, 255 :) The keys in IPSECKEY are either DSA or RSA keys, and you can use those in authentication either by using RSA(1), DSA(3) or Digital Signature (14) methods. I do not think we need separate authentication method for it. > Then I noticed that in fact the registry is a two octet value, while in > the IPSECKEY record this is a one octet value: > > https://tools.ietf.org/html/rfc4025#section-2.1 > > That's clearly a bug. Is it worth filing an ERRATA for this or should we > wait and see if we will replace IPSECKEY anyway? Which registry is two octet value? Now I am really confused... -- kivinen@iki.fi From nobody Tue Mar 31 03:50:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA12E1A90A1 for ; Tue, 31 Mar 2015 03:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9Jf8IAXwvfa for ; Tue, 31 Mar 2015 03:50:00 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F3A1A907C for ; Tue, 31 Mar 2015 03:50:00 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2VAnvMp008593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 13:49:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2VAnuGk016426; Tue, 31 Mar 2015 13:49:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21786.31700.388695.942729@fireball.kivinen.iki.fi> Date: Tue, 31 Mar 2015 13:49:56 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <6E938E70-324A-424E-9D20-7067BD278165@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 24 min X-Total-Time: 38 min Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:50:02 -0000 Yoav Nir writes: > First is the nonce/IV question: In the current draft, there is a > 64-bit IV with guidance not to repeat them (so use a counter or > LFSR). The function itself accepts a 96-bit input nonce, so the > nonce is constructed from the 64-bit IV and 32 zero bits. The reason > for doing this is so the algorithm could be used in a multi-sender > case such as GDOI, where the 32-bit zero can be replaced by a sender > ID. Alternatively, we could generate a 32-bit salt value from the > key material, but I don=E2=80=99t see a reason why we=E2=80=99d want = that. Reserving that 32-bits as sender-ID is fine... > Another thing we could do is what some people are advocating for > TLS: Since a counter is a fine IV (no need for secrecy), we don=E2=80= =99t > need a 64-bit IV that has the exact same value as the replay > counter. We might as well save 8 bytes per packet and just feed the > replay counter to the function. The argument against this is that > some crypto modules may have the API set up in such a way that the > IVs are generated within the module and could be something other > than a counter (like an LFSR). The proposal will break such APIs. As Kent explained in the meeting, if you move the IV generation out from the crypto operation, then that also moves the FIPS boundary, i.e. if the uniqueness of the IV generation (counter) is inside the IPsec module, not in the ChaCha20 module, then you need to FIPS certify whole thing. On the other hand with IPsec I think you mostly need to FIPS certify quite a lot of stuff anyways... On the other hand, I think it would be possible to do things other way around, i.e. make cipher to internally generate IV, but define that IV MUST be running counter starting from 0, and use that counter as sequence number in the ESP and compress sequence number out from the packet. I.e. we would still have IV (coming form inside the crypto boundary), but we compress the sequence number away, as it would always be the same as IV... Currently we cannot do that, as we do not define how the IVs are generated, thus the IPsec part cannot know for sure that IVs are generated in such way. On the other hand if we define this cipher in such way that IV MUST be generated such way, then we could make sequence number compression option in the future, which would compress sequence number away from the actual packet... I.e. gain the same effect, but not compressing the IV, but compressing the sequence number... This would save 32-bits from the packet, as only 32-bits of the sequence number is transmitted, not the full 64-bits, but that would still be something, and if even more IV compression is needed, there would be ways to only transmit smaller part of the IV and then reconstruct it before decryption and verification. These compression extensions could happen after ESP encryption and before ESP decryption, so the actual ESP packets seen by the engine would be exactly same, only difference would be that they would need to maintain strict requirement that SEQ matches IV... > Second issue is about UI advice. Some implementations (yes, mine is > included) allow the user to configure encryption algorithm, MAC > algorithm, and D-H group. There is no setting for PRF since such UIs > date back to IKEv1. The PRF is usually just taken from the setting > for MAC algorithm. This works fine as long as all supported MAC > algorithms are HMAC, XCBC, and CMAC. AES-GCM would have the same > issue, but RFC 5282 makes no mention of this issue. I=E2=80=99m wonde= ring if > we should recommend to pair this algorithm in IKE with > PRF=5FHMAC=5FSHA2=5F256.=20 There is no need in IKEv2 to tie the PRF to other algorithms, so I see no reason to do so in this draft. On the other hand the other draft making the UI suite for this will of course need to select suitable PRF, but that draft might want to wait for new EC curves, so we could have complete DJB suite... Btw, in the draft introduction you have text which says: weakness in AES, VPN users will be in an unenviable position. With the only other widely supported cipher being the much slower 3DES, i= t is not feasible to re-configure IPsec installations to use 3DES. [standby-cipher] describes this issue and the need for a standby cipher in greater detail. I do not think the problem with 3DES is the speed, I think the bigger problem is the way too short block length of it. As RFC7321 says: The Triple Data Encryption Standard (TDES) is obsolete because of it= s small block size; as with all 64-bit block ciphers, it SHOULD NOT be= used to encrypt more than one gigabyte of data with a single key [M13]. Its key size is smaller than that of the Advanced Encryption= Standard (AES), while at the same time its performance and efficienc= y are worse. Thus, its use in new implementations is discouraged. With gigabit links that would mean rekeying every ten seconds or so...=20= --=20 kivinen@iki.fi From nobody Tue Mar 31 03:55:50 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D3621A90C1; Tue, 31 Mar 2015 03:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8DYme_0Hk4k; Tue, 31 Mar 2015 03:55:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 281591A905B; Tue, 31 Mar 2015 03:55:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150331105545.775.28233.idtracker@ietfa.amsl.com> Date: Tue, 31 Mar 2015 03:55:45 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:55:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : ChaCha20, Poly1305 and their use in IKE & IPsec Author : Yoav Nir Filename : draft-ietf-ipsecme-chacha20-poly1305-01.txt Pages : 6 Date : 2015-03-31 Abstract: This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for IPsec. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 31 03:58:04 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E782B1A00E2 for ; Tue, 31 Mar 2015 03:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14aBuDNDq6xL for ; Tue, 31 Mar 2015 03:58:00 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D9F1A0037 for ; Tue, 31 Mar 2015 03:57:59 -0700 (PDT) Received: by wibgn9 with SMTP id gn9so20965632wib.1 for ; Tue, 31 Mar 2015 03:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=UDjqDh+GR45RtOdLVs6H6vNKFGhmISnL54EDt1kxb94=; b=TPXC5+mCh3XpF3RWUsE0TwoYcRjj+WUEIth1AYuBHWHIV1I1K9cQ+hhyYerNhf/Ylj mFngnAtxHl8+wjf7dDbJMiEsmk9PzysXm9KqDkZvsCfulC+pQl8ZhVK/iAPX0qDhF59R x50H2Mpy/AXLblxTLhO62Lxk/qj0lDJ9aBmju5ob8MN4H13Mi0em5/C8X2qJj6BQETzr nHr9vTh8J6bT4OlvpE4PXntsuH3COYN61pu7o2sFPOk00uVPa16dIsTBZa2yvQkBac7A Ht5EPx824ek2MtDOeVx+9D8LMKa0E+M4KP9wrGWmHOm+S0OK7iL6DsDl31SMA4OzzYED xhow== X-Received: by 10.194.60.173 with SMTP id i13mr71489117wjr.124.1427799478192; Tue, 31 Mar 2015 03:57:58 -0700 (PDT) Received: from [172.24.250.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id p9sm19819779wje.12.2015.03.31.03.57.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 03:57:57 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_B84BE58B-A6AA-4D31-A940-32F071DD9A44" Message-Id: <09B9FFB9-3C87-45F6-96CD-BB02B08C83F1@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Date: Tue, 31 Mar 2015 13:57:54 +0300 References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> To: IETF IPsec In-Reply-To: X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 10:58:03 -0000 --Apple-Mail=_B84BE58B-A6AA-4D31-A940-32F071DD9A44 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Seeing as none of the transform names begins with =E2=80=9CESP_=E2=80=9D = and that we=E2=80=99re specifying the algorithm for IKE as well as ESP, = I=E2=80=99ve changed the identifier to ENCR_ChaCha20_Poly1305. Yoav > On Mar 31, 2015, at 12:15 PM, Yoav Nir wrote: >=20 > One more thing. >=20 > I would like to request early code point assignment for = ESP_ChaCha20-Poly1305. >=20 > I know that it is the goal of the chairs to bring this to LC sooner = rather than later, but I would like to get started on implementation = sooner rather than later, and the IETF process takes three months at = best, and six months in the more common case. >=20 > Thanks >=20 > Yoav >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> To: > >> Date: March 30, 2015 at 4:32:37 PM GMT+3 >> Cc: ipsec@ietf.org >> Subject: [IPsec] I-D Action: = draft-ietf-ipsecme-chacha20-poly1305-00.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >>=20 >> Title : ChaCha20, Poly1305 and their use in IPsec >> Author : Yoav Nir >> Filename : draft-ietf-ipsecme-chacha20-poly1305-00.txt >> Pages : 6 >> Date : 2015-03-29 >>=20 >> Abstract: >> This document describes the use of the ChaCha20 stream cipher along >> with the Poly1305 authenticator, combined into an AEAD algorithm = for >> IPsec. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/ = >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_B84BE58B-A6AA-4D31-A940-32F071DD9A44 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Seeing as none of the transform names begins with =E2=80=9CESP_= =E2=80=9D and that we=E2=80=99re specifying the algorithm for IKE as = well as ESP, I=E2=80=99ve changed the identifier to ENCR_ChaCha20_Poly1305.

Yoav

On Mar 31, 2015, at 12:15 PM, Yoav Nir <ynir.ietf@gmail.com>= wrote:

One more = thing.

I would like = to request early code point assignment for ESP_ChaCha20-Poly1305.

I know that it is the goal of the = chairs to bring this to LC sooner rather than later, but I would like to = get started on implementation sooner rather than later, and the IETF = process takes three months at best, and six months in the more common = case.

Thanks

Yoav

Begin forwarded = message:

From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Date: March 30, 2015 at 4:32:37 PM GMT+3
Cc: ipsec@ietf.org
Subject: [IPsec] I-D Action: = draft-ietf-ipsecme-chacha20-poly1305-00.txt


A = New Internet-Draft is available from the on-line Internet-Drafts = directories.
This draft is a work item of the IP Security = Maintenance and Extensions Working Group of the IETF.

       Title =           : ChaCha20, = Poly1305 and their use in IPsec
=        Author =          : Yoav Nir
= Filename        : = draft-ietf-ipsecme-chacha20-poly1305-00.txt
Pages =           : 6
= Date =            : = 2015-03-29

Abstract:
=   This document describes the use of the ChaCha20 stream = cipher along
  with the Poly1305 authenticator, = combined into an AEAD algorithm for
  IPsec.


The IETF datatracker status = page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-po= ly1305/

There's also a htmlized version = available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305= -00


Please note that it = may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_B84BE58B-A6AA-4D31-A940-32F071DD9A44-- From nobody Tue Mar 31 07:03:27 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCE01ACD5F for ; Tue, 31 Mar 2015 07:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mf1Rlv6BJrC0 for ; Tue, 31 Mar 2015 07:03:21 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3785C1ACD66 for ; Tue, 31 Mar 2015 07:03:21 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lGXS74xy1zCGw; Tue, 31 Mar 2015 16:03:19 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=e3Ob0n5b X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 1EGY16_C7PRo; Tue, 31 Mar 2015 16:03:18 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 31 Mar 2015 16:03:18 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B8397819A0; Tue, 31 Mar 2015 10:03:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427810597; bh=Jn/YMWEaAO56sDDMCxxEPawkZfRvnO3I6VgtUHU8iOo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=e3Ob0n5bcnsb9dc9ABIoZt9cwBFrjZ+IfLJLqH6tt2N/VP2w3AVrPF1z7fiQiKv9V DbYIQcIMmwjHnB14l3yDsJqOa2ZB6oDGsqzoNszrW2WFLVakgCVwt0LpXo2eLotI/a 9PKGIensCUEu5OB6NEgoLZmmyQFcXTJZ1SdNwVMI= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2VE3GLQ014159; Tue, 31 Mar 2015 10:03:16 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 31 Mar 2015 10:03:16 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <09B9FFB9-3C87-45F6-96CD-BB02B08C83F1@gmail.com> Message-ID: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <09B9FFB9-3C87-45F6-96CD-BB02B08C83F1@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 14:03:25 -0000 On Tue, 31 Mar 2015, Yoav Nir wrote: > Seeing as none of the transform names begins with “ESP_” and that we’re specifying the algorithm for IKE as well as ESP, I’ve changed > the identifier to ENCR_ChaCha20_Poly1305. > Yoav Can we make it ENCR_CHACHA20_POLY1305 ? Currently IANA mostly has no CamelCase and it is kind of a C habbit to have defines in CAPS :) Paul From nobody Tue Mar 31 07:16:33 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6031ACD5F for ; Tue, 31 Mar 2015 07:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YfuxD31aNWW for ; Tue, 31 Mar 2015 07:16:31 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16E501ACD6E for ; Tue, 31 Mar 2015 07:16:31 -0700 (PDT) Received: by wiaa2 with SMTP id a2so27953958wia.0 for ; Tue, 31 Mar 2015 07:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HXncUfw6oEeUKU+pYhfATG/C4iuT08E3wSfXbb5baXc=; b=mPPNHpn+N4FVvxP+d86pZUGZmD0VK+2qstohp3b4EMj1IL+7pWtcdq8xeYfThYfTS5 93AmzTQJqn4Pn7yp72AvDU0IjrRGhdcLDpIYi/fhm4kvRjTD8bRuc76u+oziiZsrDIHp +VRrqD6r1woni/vTpDY1pllSmTq1sqAsTaJFFl0OomTE0uHE8vaKs7Neagka7krzcw9t 3ILvPzi4dGBsDN+7G0UPzFgjiYi4QX/Zu2XxvzjGY/vtkbc1h6oNEaiTVztuXGzehsu2 wun1vuUmKNWrouDocZvpDpyMVkaV5NuT5NXCXauJb5/Vz9TjLagJ36NZTHTzgqp4FhJ5 hv4w== X-Received: by 10.194.133.199 with SMTP id pe7mr75481900wjb.120.1427811389716; Tue, 31 Mar 2015 07:16:29 -0700 (PDT) Received: from [172.24.250.177] ([194.29.32.131]) by mx.google.com with ESMTPSA id bp1sm20554189wjb.31.2015.03.31.07.16.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 31 Mar 2015 07:16:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Yoav Nir In-Reply-To: Date: Tue, 31 Mar 2015 17:16:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9F071A62-C101-4683-AEBD-71BDD4D2BFBC@gmail.com> References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <09B9FFB9-3C87-45F6-96CD-BB02B08C83F1@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 14:16:32 -0000 > On Mar 31, 2015, at 5:03 PM, Paul Wouters wrote: >=20 > On Tue, 31 Mar 2015, Yoav Nir wrote: >=20 >> Seeing as none of the transform names begins with =E2=80=9CESP_=E2=80=9D= and that we=E2=80=99re specifying the algorithm for IKE as well as ESP, = I=E2=80=99ve changed >> the identifier to ENCR_ChaCha20_Poly1305. >> Yoav >=20 > Can we make it ENCR_CHACHA20_POLY1305 ? >=20 > Currently IANA mostly has no CamelCase and it is kind of a C habbit to > have defines in CAPS :) I guess, although some of the names don=E2=80=99t quite work as = identifiers: "AES-GCM with a 8 octet ICV=E2=80=9D or = "ENCR-AES-CCM_12=E2=80=9D, which is surprisingly different in terms of = dashes vs underscores than =E2=80=9CENCR_AES-CCM_8=E2=80=9D. Yoav From nobody Tue Mar 31 07:41:03 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE00E1ACDB9 for ; Tue, 31 Mar 2015 07:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je5RxQnYffWE for ; Tue, 31 Mar 2015 07:41:01 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D581ACDB2 for ; Tue, 31 Mar 2015 07:41:00 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lGYHb1P5qzCGw; Tue, 31 Mar 2015 16:40:59 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=KJLdESoY X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id pACS0LJRGFQb; Tue, 31 Mar 2015 16:40:58 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 31 Mar 2015 16:40:58 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5D016819A0; Tue, 31 Mar 2015 10:40:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427812857; bh=PwLDC+VYSzB16CO0K+bOZwr6RoQVCjwzpVRjHxwmY3U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KJLdESoYMXqYSczGPStYxP25AMSAPeRmx8tseQlg5jxnHQngKF8pGALECSrfBE+IG o6r2DfKJllTpI8M6STauhxUAypHjJQLkJwbPHnkm4d/3gG++uU7yJFRGZinq3rqQfT sDxqn5ZxbfK67JdZLlbzbflYeV7r//iNzSu0Lyew= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2VEeuR2013179; Tue, 31 Mar 2015 10:40:56 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 31 Mar 2015 10:40:56 -0400 (EDT) From: Paul Wouters To: Yoav Nir In-Reply-To: <9F071A62-C101-4683-AEBD-71BDD4D2BFBC@gmail.com> Message-ID: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <09B9FFB9-3C87-45F6-96CD-BB02B08C83F1@gmail.com> <9F071A62-C101-4683-AEBD-71BDD4D2BFBC@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IETF IPsec Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 14:41:02 -0000 On Tue, 31 Mar 2015, Yoav Nir wrote: >> Can we make it ENCR_CHACHA20_POLY1305 ? >> >> Currently IANA mostly has no CamelCase and it is kind of a C habbit to >> have defines in CAPS :) > > I guess, although some of the names don’t quite work as identifiers: "AES-GCM with a 8 octet ICV” or "ENCR-AES-CCM_12”, which is surprisingly different in terms of dashes vs underscores than “ENCR_AES-CCM_8”. And I've poked both PaulH and Tero to never ever add more names with a "-" in it because that has to be replaced by "_" in C. My apologies I wasn't very active at the time this happened :) Paul From nobody Tue Mar 31 08:34:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 129A11A9248 for ; Tue, 31 Mar 2015 08:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tDLvNmg7Nyj for ; Tue, 31 Mar 2015 08:34:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8014A1A907B for ; Tue, 31 Mar 2015 08:34:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lGZTc5yy7z752; Tue, 31 Mar 2015 17:34:44 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=kbeYxeSX X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NFNU4dYQiuya; Tue, 31 Mar 2015 17:34:42 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 31 Mar 2015 17:34:41 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 709B6803E0; Tue, 31 Mar 2015 11:34:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427816080; bh=b13syG7Zu714HtOtuwiph9ymfm/9tSNc/bcXjX43G0k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kbeYxeSXrcCbDRQFAmhNztpjqZ9/nmw8Hq6IsQ64ejdj+p3BSyAu4kAE+U2GetXBd hHsODkP/cnRY2kZ1N0JaDF1yGyyx569a/P35Kl7GmEI682nDh6oZ7/ktsNXWhwLB5W GXR+mEVxVlmXQih6EtBfQMQSTmWzoxIVwJDbvnM8= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2VFYdxT025162; Tue, 31 Mar 2015 11:34:39 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 31 Mar 2015 11:34:39 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21786.28998.830814.421934@fireball.kivinen.iki.fi> Message-ID: References: <21786.28998.830814.421934@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 15:34:55 -0000 On Tue, 31 Mar 2015, Tero Kivinen wrote: > When you get public key inside the IKEv2 in raw form, you extract the > key from there (i.e. decode the ASN.1 and get the key out in internal > public key representation). Then you fetch the key from IPSECKEY > records and do the same, i.e. again parse the key from DNS record to > the internal public key representation. Now you have two public keys, > and after that you simply compare them, and thats it. If they match > you know that the key used in IKE is same than in DNS. What if you get RSA keys but the IPSECKEY algo number was DSA? The problem is that the approach you describe is required for supporting bare public keys in IKE, but we have no algorithm identifier for that to put in the IPSECKEY record. Hence my suggestion for 255 or something for this case, which would mean "the algorithm as derived from the SPBI". > Another use is that you fetch the public key for the other end > directly from the IPSECKEY DNS records, and use it, i.e. you ignore > the key other end sends to you. It has the same problem. >> So first, if we were to fix this for IPSECKEY (and I'm not yet >> convinced we are there yet, as we might end up with updating >> IPSECKEY due to other issues we'll find over the next few months) we >> might consider allocating a special algorithm number to signify this >> in the IKE Authentication Method registry at >> >> http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 >> >> For instance, 255 :) > > The keys in IPSECKEY are either DSA or RSA keys, and you can use those > in authentication either by using RSA(1), DSA(3) or Digital Signature > (14) methods. I do not think we need separate authentication method > for it. Bare public keys could be algorithm FOO once you parse their ASN.1. Are you saying that we will only ever support SPKI's of known IKE algorithms? I thought part of the idea here was that people could do AUTH for different algorithms without IKE needing to assign an algorithm for each? Like if someone wanted to use RSASSA-PSS instead of RSA-PKCS1-v1_5 ? In IKE you cannot specify the type of RSA key, but in SPKI you can. >> Then I noticed that in fact the registry is a two octet value, while in >> the IPSECKEY record this is a one octet value: >> >> https://tools.ietf.org/html/rfc4025#section-2.1 >> >> That's clearly a bug. Is it worth filing an ERRATA for this or should we >> wait and see if we will replace IPSECKEY anyway? > > Which registry is two octet value? > > Now I am really confused... This is two octets: http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-8 This is one octet: http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 And ipseckey uses one octet: https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml#ipseckey-rr-parameters-1 But as Michael pointed out, the algo value of IPSECKEY is its own registry and (for some odd reason probably to exclude PSK) does not just re-use the same value of the other registry. And I guess it is missing a private use range to accomodate people using a a private value (eg 65001 in IKEv1 or 201 in IKEv2) As I said, I think we are looking at updating IPSECKEY anyway, so it is not a big problem, but I think we do need to take these issues into consideration when designing something new. Paul From nobody Tue Mar 31 09:51:24 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2616C1A0404 for ; Tue, 31 Mar 2015 09:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCXh4v302mez for ; Tue, 31 Mar 2015 09:51:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE1D21A037C for ; Tue, 31 Mar 2015 09:51:09 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2VGp6CG021439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 19:51:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2VGp6Av010345; Tue, 31 Mar 2015 19:51:06 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21786.53369.684762.294419@fireball.kivinen.iki.fi> Date: Tue, 31 Mar 2015 19:51:05 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <09B9FFB9-3C87-45F6-96CD-BB02B08C83F1@gmail.com> <9F071A62-C101-4683-AEBD-71BDD4D2BFBC@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 26 min Archived-At: Cc: IETF IPsec , Yoav Nir Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:51:16 -0000 Paul Wouters writes: > On Tue, 31 Mar 2015, Yoav Nir wrote: > >> Can we make it ENCR=5FCHACHA20=5FPOLY1305 =3F > >> Currently IANA mostly has no CamelCase and it is kind of a C habbi= t to > >> have defines in CAPS :) > > > > I guess, although some of the names don=E2=80=99t quite work as > > identifiers: "AES-GCM with a 8 octet ICV=E2=80=9D or "ENCR-AES-CCM=5F= 12=E2=80=9D, > > which is surprisingly different in terms of dashes vs underscores > > than =E2=80=9CENCR=5FAES-CCM=5F8=E2=80=9D.=20 How has that happened. Hmmm... looking at the archives that was there from the beginning. And those assignments which were done at the same time as RFC4306 was published (i.e. RFC4309 and RFC4106) never went through the IANA Expert review, hey were simply added to registry without asking from anybody... This was the time when we had some communications issues between IANA and experts...=20 > And I've poked both PaulH and Tero to never ever add more names with = a > "-" in it because that has to be replaced by "=5F" in C. As an IANA expert, I try maintain the registry so it stays consistent, but unfortunately when the registry already had those ENCR=5FAES-CCM=5F= 8, ENCR-AES-CCM=5F* and AES-GCM with * octet ICV values already in before expert was every consulted, those are still there. The AEs-GCM values have annoyed me, as they are only ones without ENCR=5F* prefix. I have never really noticed that ENCR-AES-CCM had - no= t =5F in between ENCR-AES, the one between AES-CCM I have noticed, but haven't bothered to fix those yet. On the other hand all of these are just strings so they do not affect protocol.=20 > My apologies I wasn't very active at the time this happened :) If people feel it would be better to fix those, we can do that, i.e. change: 14 =09ENCR=5FAES-CCM=5F8 15 =09ENCR-AES-CCM=5F12 16 =09ENCR-AES-CCM=5F16 18 =09AES-GCM with a 8 octet ICV 19 =09AES-GCM with a 12 octet ICV 20 =09AES-GCM with a 16 octet ICV 25 =09ENCR=5FCAMELLIA=5FCCM with an 8-octet ICV 26 =09ENCR=5FCAMELLIA=5FCCM with a 12-octet ICV 27 =09ENCR=5FCAMELLIA=5FCCM with a 16-octet ICV To: 14 =09ENCR=5FAES=5FCCM=5F8 15 =09ENCR=5FAES=5FCCM=5F12 16 =09ENCR=5FAES=5FCCM=5F16 18 =09ENCR=5FAES=5FGCM with a 8 octet ICV 19 =09ENCR=5FAES=5FGCM with a 12 octet ICV 20 =09ENCR=5FAES=5FGCM with a 16 octet ICV 25 =09ENCR=5FCAMELLIA=5FCCM with an 8-octet ICV 26 =09ENCR=5FCAMELLIA=5FCCM with a 12-octet ICV 27 =09ENCR=5FCAMELLIA=5FCCM with a 16-octet ICV Or even change the "n-octet" term to be consistent: 14 =09ENCR=5FAES=5FCCM=5F8 15 =09ENCR=5FAES=5FCCM=5F12 16 =09ENCR=5FAES=5FCCM=5F16 18 =09ENCR=5FAES=5FGCM with a 8-octet ICV 19 =09ENCR=5FAES=5FGCM with a 12-octet ICV 20 =09ENCR=5FAES=5FGCM with a 16-octet ICV 25 =09ENCR=5FCAMELLIA=5FCCM with an 8-octet ICV 26 =09ENCR=5FCAMELLIA=5FCCM with a 12-octet ICV 27 =09ENCR=5FCAMELLIA=5FCCM with a 16-octet ICV Or even go wild and change them: 14 =09ENCR=5FAES=5FCCM=5F8 15 =09ENCR=5FAES=5FCCM=5F12 16 =09ENCR=5FAES=5FCCM=5F16 18 =09ENCR=5FAES=5FGCM=5F8 19 =09ENCR=5FAES=5FGCM 12 20 =09ENCR=5FAES=5FGCM=5F16 25 =09ENCR=5FCAMELLIA=5FCCM=5F8 26 =09ENCR=5FCAMELLIA=5FCCM=5F12 27 =09ENCR=5FCAMELLIA=5FCCM=5F16 --=20 kivinen@iki.fi From nobody Tue Mar 31 10:12:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6FAF1A1ADA for ; Tue, 31 Mar 2015 10:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1zh3CDQpRuQ for ; Tue, 31 Mar 2015 10:12:42 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06851A1AD0 for ; Tue, 31 Mar 2015 10:12:41 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2VHCdhq003018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 20:12:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2VHCdwO007608; Tue, 31 Mar 2015 20:12:39 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21786.54663.693682.437026@fireball.kivinen.iki.fi> Date: Tue, 31 Mar 2015 20:12:39 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21786.28998.830814.421934@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 21 min Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] IPSECKEY algorithm number oddity (and draft-kivinen-ipsecme-oob-pubkey) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:12:43 -0000 Paul Wouters writes: > On Tue, 31 Mar 2015, Tero Kivinen wrote: > > > When you get public key inside the IKEv2 in raw form, you extract the > > key from there (i.e. decode the ASN.1 and get the key out in internal > > public key representation). Then you fetch the key from IPSECKEY > > records and do the same, i.e. again parse the key from DNS record to > > the internal public key representation. Now you have two public keys, > > and after that you simply compare them, and thats it. If they match > > you know that the key used in IKE is same than in DNS. > > What if you get RSA keys but the IPSECKEY algo number was DSA? Then you make sure you get all IPSECKEY records, and see if you find RSA key too. If not, the key is wrong, and does not validate. > The problem is that the approach you describe is required for > supporting bare public keys in IKE, but we have no algorithm > identifier for that to put in the IPSECKEY record. Hence my > suggestion for 255 or something for this case, which would mean "the > algorithm as derived from the SPBI". Which algorthm you are not talking about? The one in the certificate payload i.e. the oob-key, or the one in the authentication payload? When you put the IPSECKEY record out having the key, you do know which type it has, and set the identififer in the IPSECKEY record accordingly. When you are fetching the IPSECKEY record for the remote peer, you get all the records you find, and you might find two, one for DSA and one for RSA. Then you pick the one other end used in his AUTH payload, i.e. the one it sent inside the CERT payload (either as raw public key, or self signed X.509 key, or hash and url etc). > > The keys in IPSECKEY are either DSA or RSA keys, and you can use those > > in authentication either by using RSA(1), DSA(3) or Digital Signature > > (14) methods. I do not think we need separate authentication method > > for it. > > Bare public keys could be algorithm FOO once you parse their ASN.1. Yes. > Are you saying that we will only ever support SPKI's of known IKE > algorithms? It is very hard to implement algorithms that I do not know anything about, so yes, my implementations only support for known algorithms... To be able to use some key you need to implement the support for that specific type, so if you only support RSA, and DSA keys then those are the only SPKI formats you will ever support. > I thought part of the idea here was that people could do AUTH for > different algorithms without IKE needing to assign an algorithm for > each? Yes you can do that using RFC7427, i.e. the "Digital Signature" authentication method. This has nothing to do with raw public keys, except that both of them use ASN.1 objects to tell the type of object after them. > Like if someone wanted to use RSASSA-PSS instead of RSA-PKCS1-v1_5 ? > In IKE you cannot specify the type of RSA key, but in SPKI you can. RSASSA-PSS support was added to IKEv2 in RFC7427, and if you do not implement that, you cannot use RSASSA-PSS in IKEv2. > >> Then I noticed that in fact the registry is a two octet value, while in > >> the IPSECKEY record this is a one octet value: > >> > >> https://tools.ietf.org/html/rfc4025#section-2.1 > >> > >> That's clearly a bug. Is it worth filing an ERRATA for this or should we > >> wait and see if we will replace IPSECKEY anyway? > > > > Which registry is two octet value? > > > > Now I am really confused... > > This is two octets: > > http://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml#ipsec-registry-8 This is for IKEv1, it has been obsoleted, and is not in any use anymore (I can always hope :-) It does not have any relevance for IKEv2 or for IPSECKEY when using IKEv2. > This is one octet: > > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12 Yes, and that is for IKEv2. In IKEv1 the authentication method was negotiated inside the SA payloads and because it was using basic encoding it was 16-bit field. In IKEv2 the authentication method is transmitted as a first byte of the authentication payload, and as we assumed there will not be too many of them, only one byte was used. > And ipseckey uses one octet: > > https://www.iana.org/assignments/ipseckey-rr-parameters/ipseckey-rr-parameters.xhtml#ipseckey-rr-parameters-1 This is transmitted inside the DNS records, and does not have anything to do with IKEv1 or IKEv2 authentication methods registries. This gives the type of the key, as those others give types of authentication method (for example pre-shared key). > But as Michael pointed out, the algo value of IPSECKEY is its own > registry and (for some odd reason probably to exclude PSK) does not just > re-use the same value of the other registry. Why should it reuse registry which has nothing to do with it. Public key type and Authentication methods are completely different things. > And I guess it is missing a private use range to accomodate people > using a a private value (eg 65001 in IKEv1 or 201 in IKEv2) Private ranges do not work that well in public DNS... > As I said, I think we are looking at updating IPSECKEY anyway, so it is > not a big problem, but I think we do need to take these issues into > consideration when designing something new. I assume the IPSECKEY would require update to define new key types for elliptic curves, but as those all can already be used with the "Digital Signature" authentication method (or the ECDSA with SHA-xxx on the P-yyy curve methods), I do not think there is that much issues with that. -- kivinen@iki.fi From nobody Tue Mar 31 10:24:12 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A319F1A1BCA for ; Tue, 31 Mar 2015 10:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBZHi5C-7tQ3 for ; Tue, 31 Mar 2015 10:24:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1FEC1A1B74 for ; Tue, 31 Mar 2015 10:24:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3lGcvn1Q9kzlS; Tue, 31 Mar 2015 19:24:05 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=lSkv6qtZ X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 0zVSnyPmOTl8; Tue, 31 Mar 2015 19:24:03 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 31 Mar 2015 19:24:02 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2B2F280416; Tue, 31 Mar 2015 13:24:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1427822642; bh=Vv1sk4lV7Hs+zVlmaBKmd9dadGl+Bevb8f5ItTRJQgA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lSkv6qtZ0DmN7sMy0feCpIaYV3xBrTFkatu0VLVUmFRPmRj7EZ+4/iVbXYDp7ZtIT 5i4UndlgrrZjNRoCNcE652GknEVsNEQXNon/FrqG0olsyewEkX6Nq6+bFWJC/1Nfn9 13QufKPb6DYa83nMe273MFW6pqMLkINEvd9hIQ9I= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id t2VHO1IJ012701; Tue, 31 Mar 2015 13:24:01 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 31 Mar 2015 13:24:01 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21786.53369.684762.294419@fireball.kivinen.iki.fi> Message-ID: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <09B9FFB9-3C87-45F6-96CD-BB02B08C83F1@gmail.com> <9F071A62-C101-4683-AEBD-71BDD4D2BFBC@gmail.com> <21786.53369.684762.294419@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: IETF IPsec , Yoav Nir Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:24:10 -0000 On Tue, 31 Mar 2015, Tero Kivinen wrote: > How has that happened. Hmmm... looking at the archives that was there > from the beginning. And those assignments which were done at the same > time as RFC4306 was published (i.e. RFC4309 and RFC4106) never went > through the IANA Expert review, hey were simply added to registry > without asking from anybody... > > This was the time when we had some communications issues between IANA > and experts... Is that when Camellia went through as well? :P with different numbers for IKEv1 and IKEv2 :P [insert implementer anger :)] > On the other hand all of these are just strings so they do not affect > protocol. Agreed, but it's nice to be able to grep other people's source code :P > If people feel it would be better to fix those, we can do that, i.e. > change: > Or even go wild and change them: > > 14 ENCR_AES_CCM_8 > 15 ENCR_AES_CCM_12 > 16 ENCR_AES_CCM_16 > 18 ENCR_AES_GCM_8 > 19 ENCR_AES_GCM 12 > 20 ENCR_AES_GCM_16 > 25 ENCR_CAMELLIA_CCM_8 > 26 ENCR_CAMELLIA_CCM_12 > 27 ENCR_CAMELLIA_CCM_16 It would be great if we could do that! But if we can change these, why can we not also change "-" into "_" ? Paul From nobody Tue Mar 31 12:19:27 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C0E1ABD3B for ; Tue, 31 Mar 2015 12:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv2FGWngcHKk for ; Tue, 31 Mar 2015 12:19:23 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0441A92F9 for ; Tue, 31 Mar 2015 12:19:22 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id t2VJJIfK001953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 22:19:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id t2VJJIUb008692; Tue, 31 Mar 2015 22:19:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21786.62261.747975.899762@fireball.kivinen.iki.fi> Date: Tue, 31 Mar 2015 22:19:17 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <20150330133237.21486.80504.idtracker@ietfa.amsl.com> <09B9FFB9-3C87-45F6-96CD-BB02B08C83F1@gmail.com> <9F071A62-C101-4683-AEBD-71BDD4D2BFBC@gmail.com> <21786.53369.684762.294419@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 30 min Archived-At: Cc: IETF IPsec , Yoav Nir Subject: Re: [IPsec] Early code point assignment (was: I-D Action: draft-ietf-ipsecme-chacha20-poly1305-00.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 19:19:25 -0000 Paul Wouters writes: > On Tue, 31 Mar 2015, Tero Kivinen wrote: > > > How has that happened. Hmmm... looking at the archives that was there > > from the beginning. And those assignments which were done at the same > > time as RFC4306 was published (i.e. RFC4309 and RFC4106) never went > > through the IANA Expert review, hey were simply added to registry > > without asking from anybody... > > > > This was the time when we had some communications issues between IANA > > and experts... > > Is that when Camellia went through as well? :P with different numbers > for IKEv1 and IKEv2 :P [insert implementer anger :)] The Camellia RFC 4312 only allocated numbers for IKEv1 not for IKEv2. The IKEv2 then got few allocations (ENCR_NULL_AUTH_AES_GMAC, and one for XTS-AES) between and the number 22 was not available anymore when the RFC to allocate CAMELLIA for IKEv2 came through, or to be more accurate, when the authors of RFC4312 wanted to do IANA allocation for CAMELLIA_CBC for IKEv2 too. I said as if it is going to be different number, better write new RFC, and while they did that they also added CTR, and CCM modes in it... Anyways there is no real reason to keep the IKEv1 and IKEv2. The reason we had different registries was that they are two different protocols, and for example in the IKEv2 the Encryption Algorithms registry was used by both IKEv2 SA and ESP, as in IKEv1 there were separate registries for them. Also IKEv1 is used with ESPv2 and cannot really support combine mode ciphers, but that didn't stop people defining them in IKEv1 registries too. So it was clear that they would get out of sync at one point, so each implementation had to solve that somehow anyway. The initial registries were compatible to make supporting boht IKEv1 and IKEv2, but after that changes happen. > > If people feel it would be better to fix those, we can do that, i.e. > > change: > > > Or even go wild and change them: > > > > 14 ENCR_AES_CCM_8 > > 15 ENCR_AES_CCM_12 > > 16 ENCR_AES_CCM_16 > > 18 ENCR_AES_GCM_8 > > 19 ENCR_AES_GCM 12 > > 20 ENCR_AES_GCM_16 > > 25 ENCR_CAMELLIA_CCM_8 > > 26 ENCR_CAMELLIA_CCM_12 > > 27 ENCR_CAMELLIA_CCM_16 > > It would be great if we could do that! But if we can change these, why > can we not also change "-" into "_" ? I did that, but seem to have missed one " " in ENCR_AES_GCM 12" -- kivinen@iki.fi From nobody Tue Mar 31 14:17:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF2A1A87B0; Tue, 31 Mar 2015 14:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-aVXkx9t5_n; Tue, 31 Mar 2015 14:17:49 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B2A7C1A87A2; Tue, 31 Mar 2015 14:17:49 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3283918046C; Tue, 31 Mar 2015 14:17:39 -0700 (PDT) To: a.yousar@informatik.hu-berlin.de, kivinen@iki.fi, jms@opus1.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150331211739.3283918046C@rfc-editor.org> Date: Tue, 31 Mar 2015 14:17:39 -0700 (PDT) Archived-At: Cc: ipsec@ietf.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [IPsec] [Errata Rejected] RFC7427 (4295) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 21:17:51 -0000 The following errata report has been rejected for RFC7427, "Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7427&eid=4295 -------------------------------------- Status: Rejected Type: Editorial Reported by: Annie Yousar Date Reported: 2015-03-10 Rejected by: Kathleen Moriarty (IESG) Section: A.4.2 Original Text ------------- Here the parameters are present and contain the default parameters, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField of 1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE 000f : CONTEXT 0 0011 : SEQUENCE 0013 : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 001a : NULL 001c : CONTEXT 1 001e : SEQUENCE 0020 : OBJECT IDENTIFIER 1.2.840.113549.1.1.8 002b : SEQUENCE 002d : OBJECT IDENTIFIER id-sha1 (1.3.14.3.2.26) 0034 : NULL 0036 : CONTEXT 2 0038 : INTEGER 0x14 (5 bits) 003b : CONTEXT 3 003d : INTEGER 0x1 (1 bits) Name = RSASSA-PSS with default parameters, oid = 1.2.840.113549.1.1.10 Length = 64 0000: 303e 0609 2a86 4886 f70d 0101 0a30 31a0 0010: 0b30 0906 052b 0e03 021a 0500 a118 3016 0020: 0609 2a86 4886 f70d 0101 0830 0906 052b 0030: 0e03 021a 0500 a203 0201 14a3 0302 0101 Corrected Text -------------- If the default parameters are used, i.e., hashAlgorithm of SHA-1, maskGenAlgorithm of mgf1SHA1, saltLength of 20, and trailerField of 1, the parameters MUST NOT be encoded according to the Distiguished Encoding Rules (DER) of ASN.1. Therefore the encoding is the same as of A.4.1. 0000 : SEQUENCE 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) 000d : SEQUENCE Name = RSASSA-PSS with default parameters, oid = 1.2.840.113549.1.1.10 Length = 15 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 Notes ----- Section 3 requires the use of DER: The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. KM: Reviewed by expert and response provided. --VERIFIER NOTES-- >From Tero Kivinen In the RFC 4055 the section 3.1 says that even when the default values are used the implementation MUST understand both formats, i.e. the case where the default value is omitted and the case where the default value is explicitly given: >From RFC4055 section 3.1: hashAlgorithm The hashAlgorithm field identifies the hash function. It MUST be one of the algorithm identifiers listed in Section 2.1, and the default hash function is SHA-1. Implementations MUST support SHA-1 and MAY support any of the other one-way hash functions listed in Section 2.1. Implementations that perform signature generation MUST omit the hashAlgorithm field when SHA-1 is used, indicating that the default algorithm was used. Implementations that perform signature validation MUST recognize both the sha1Identifier algorithm identifier and an absent hashAlgorithm field as an indication that SHA-1 was used. In this case we are not actually doing either one of those options, we are not generating signature, and we are not validating them. In this document we are simply indicating what kind of signature will follows this binary blob. Yes, when generating those ASN.1 objects for default values implementations should use the A.4.1 version, but they might also want to understand the version specified in the A.4.2. Note, that in some cases the implementations might simply take the AlgorithmIdentifier pieces from their own certificate and not generate it at all, and this might cause them to take whatever the CA vendor generated for them. Actually when checking for the RFC4055 I notice it says that same thing (MUST omit in generate, MUST recognize both) for everything else (hashAlgorithm, maskGenAlgorithm, and trailerField) expect for saltLength... I do not know if this means that for saltLength we should actually not encode the default as number or if this is just sloppy writing of the RFC4055... > 0000 : SEQUENCE > 0002 : OBJECT IDENTIFIER RSASSA-PSS (1.2.840.113549.1.1.10) > 000d : SEQUENCE > > Name = RSASSA-PSS with default parameters, > oid = 1.2.840.113549.1.1.10 > Length = 15 > 0000: 300d 0609 2a86 4886 f70d 0101 0a30 00 > > > Notes > ----- > Section 3 requires the use of DER: > The ASN.1 used here is the same ASN.1 used in the AlgorithmIdentifier of PKIX (see Section 4.1.1.2 of [RFC5280]), encoded using distinguished encoding rules (DER) [CCITT.X690.2002]. Yes, when generating them they needs to be in DER, when matching the values sent from the other end, the matching can be looser. The format A.4.1 MUST be used when generating the RSASSA-PSS with default parameters, but A.4.2 can also be recognized. If the implementation has real ASN.1 parser this is exactly what it will do automatically. -------------------------------------- RFC7427 (draft-kivinen-ipsecme-signature-auth-07) -------------------------------------- Title : Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) Publication Date : January 2015 Author(s) : T. Kivinen, J. Snyder Category : PROPOSED STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG