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

Dan Brown <dbrown@certicom.com> Tue, 09 April 2013 14:03 UTC

Return-Path: <prvs=6811d4ab8c=dbrown@certicom.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BFE21F86C3 for <ipsec@ietfa.amsl.com>; Tue, 9 Apr 2013 07:03:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.772
X-Spam-Level:
X-Spam-Status: No, score=-4.772 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1afuO7kXsshs for <ipsec@ietfa.amsl.com>; Tue, 9 Apr 2013 07:03:39 -0700 (PDT)
Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id BE02521F8700 for <ipsec@ietf.org>; Tue, 9 Apr 2013 07:03:38 -0700 (PDT)
X-AuditID: 0a41282f-b7f1a6d0000054a3-5c-51641fa98881
Received: from XCT105CNC.rim.net (xct105cnc.rim.net [10.65.161.205]) by mhs060cnc.rim.net (SBG) with SMTP id 3D.39.21667.9AF14615; Tue, 9 Apr 2013 09:03:21 -0500 (CDT)
Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.02.0328.009; Tue, 9 Apr 2013 10:03:20 -0400
From: Dan Brown <dbrown@certicom.com>
To: 'Michael Richardson' <mcr+ietf@sandelman.ca>, "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
Thread-Topic: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks
Thread-Index: AQHONKJ+NLt7HaOtnk2NvnDv7KiS3JjNdr0AgAAV3ACAAJjvAP//xcCg
Date: Tue, 9 Apr 2013 14:03:20 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF513E325@XMB111CNC.rim.net>
References: <9F821C79-A855-4060-A356-ED8E5C50048B@vpnc.org> <5697.1365476466@sandelman.ca> <A113ACFD9DF8B04F96395BDEACB3404209060652@xmb-rcd-x04.cisco.com> <17925.1365514002@sandelman.ca>
In-Reply-To: <17925.1365514002@sandelman.ca>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.252]
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJKsWRmVeSWpSXmKPExsXC5bjwrO5K+ZRAg5mv1Cz2b3nBZtFzqJ/d YmqLnwOzx5TfG1k9liz5yeTRMmcPcwBzVAOjTVJiSVlwZnqevp1NYl5efkliSapCSmpxsq2S T2p6Yo5CQFFmWWJypYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6JrVJiQUFqXoqSHZcC BrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLLTTejkydi08Q5rwULOikVvFrM3ME5h72Lk 4JAQMJG4e9Ksi5ETyBSTuHBvPRuILSSwilFixUP/LkYuIHsLo8SepueMIAk2AVWJ+0fPMYP0 iggkS5zbqg4SZhaQl9j8ZRdYr7CAp8SkSR1gtoiAl0T3kS+MELabRN/jZWA2i4CKxOdlE5hA bF6g+IIfb9ggdh1klNi+YA0LSIJTQEfiRtdpdhCbUUBWYvfZ60wQy8Qlbj2ZzwRxtIDEkj3n mSFsUYmXj/+xQtiKEs/uLGWHqNeRWLD7ExuErS2xbOFrZojFghInZz5hmcAoNgvJ2FlIWmYh aZmFpGUBI8sqRsHcjGIDM4PkvGS9osxcvbzUkk2M4LShob+D8e17i0OMAhyMSjy8ScIpgUKs iWXFlbmHGCU4mJVEeA9JAYV4UxIrq1KL8uOLSnNSiw8xugKDZSKzFHdyPjCl5ZXEGxsY4OYo ifP+Fo4OFBJIB6ak7NTUgtQimDlMHJwge7ikRIqBiSW1KLG0JCMelP7ii4EJUKqBUepncqbT mxftm+pTthXXLjE+/nLLNdnPF+S3WT8WeP+9UELbwvLyw3dSXTmvmSOYVBa+/crmOEfVsVW9 WDfOsKnk/yvOipqSPfMtu+723u+xi8w8KMHwYpvI+6NyZu4LVjYly5ya1Vu5XrD5d9rWujbW jDvH2W/ZfubfPufCqi/tHaHbJjcnKbEUZyQaajEXFScCAKSteM1cAwAA
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] NUDGE: WG Last Call for draft-ietf-ipsecme-dh-checks
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 14:03:39 -0000

> -----Original Message-----
> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
> Of Michael Richardson
> Aha.... so:
> 
>    o  It MUST check both that the peer's public value is in range (1 <
> r
>       < p-1) and that r**q = 1 mod p (where q is the size of the
> 
> ...
>    o  It MUST NOT reuse DH private values (that is, the DH private
> value
>       for each DH exchange MUST be generated from a fresh output of a
> 
> So, in section 2.2 we talk both about what we should do with something
> received, and also place a mandate about generating.
> 
> Perhaps these things belong in seperate sections.
> It seems that from the receiver of g^x's point of view, point two
> repeats point one, since the receiver is not in a position to know if
> the DH private value was reused.
> 
[DB] The concern is that receiver wants to protect her own reused private key from an invalid public key from a malicious peer.  To do this, the receiver checks the received value to make sure it is valid and safe to combine with her reused private key.  Another option for the receiver is not reusing the private key at all. 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.