[IPsec] Question about RFC 5114
Joy Latten <latten@austin.ibm.com> Fri, 26 March 2010 21:46 UTC
Return-Path: <latten@austin.ibm.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB5F3A67D3 for <ipsec@core3.amsl.com>; Fri, 26 Mar 2010 14:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level:
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzX+gh6nu+0J for <ipsec@core3.amsl.com>; Fri, 26 Mar 2010 14:46:21 -0700 (PDT)
Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by core3.amsl.com (Postfix) with ESMTP id 6BDBC3A63EC for <ipsec@ietf.org>; Fri, 26 Mar 2010 14:46:21 -0700 (PDT)
Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e34.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o2QLdsDH024153 for <ipsec@ietf.org>; Fri, 26 Mar 2010 15:39:54 -0600
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o2QLkEn9145772 for <ipsec@ietf.org>; Fri, 26 Mar 2010 15:46:14 -0600
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o2QEkEtx016868 for <ipsec@ietf.org>; Fri, 26 Mar 2010 08:46:14 -0600
Received: from austin.ibm.com (netmail2.austin.ibm.com [9.41.248.176]) by d03av03.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o2QEkD7F016857; Fri, 26 Mar 2010 08:46:13 -0600
Received: from [9.41.41.43] (faith.austin.ibm.com [9.41.41.43]) by austin.ibm.com (8.13.8/8.12.10) with ESMTP id o2QLkDmm046370; Fri, 26 Mar 2010 16:46:13 -0500
From: Joy Latten <latten@austin.ibm.com>
To: mlepinski@bbn.com, kent@bbn.com
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 26 Mar 2010 16:25:01 -0500
Message-Id: <1269638701.2838.303.camel@faith.austin.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10)
Content-Transfer-Encoding: 8bit
Cc: ipsec@ietf.org, avagarwa@redhat.com
Subject: [IPsec] Question about RFC 5114
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: latten@austin.ibm.com
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Fri, 26 Mar 2010 21:46:22 -0000
Hi, I am looking to implement modp groups 22, 23, and 24 into IKE but have a question. RFC 5114 gives the prime, p, the generator, g and a subgroup, q, with a specific size... Because prior rfcs for modp groups did not specify a "q", I was not sure if this was a new constant or just stating a size requirement? So I took a look at NIST 800-56A. In particular, 5.6.1 Private/Public Key Pair Generation 5.6.1.1 FFC Key Pair Generation For the FFC schemes, each static and ephemeral private key and public key shall be generated using an Approved method and the selected valid domain parameters (p, q, g{, SEED,pgenCounter}) (see Appendix B of FIPS 186-3). ... I then took a look at FIPS 186-3, Appendix B, which documents 2 methods for finite field cryptography (FFC) key pair generation. For example, one method is "Key Pair Generation Using Extra Random Bits". It actually states that "q" is an input and it is used to do an additional computation to compute "x". I am somewhat confused, are the modp groups 22, 23 & 24 suppose to use one of these new methods and that is why "q" is given in rfc 5114? Or am I to ignore this and just continue with existing way where "q" is not used and there aren't any additional computations to compute x. I am not even sure this is correct place to ask, but any advice would be welcome. regards, Joy (Cut-n-paste from FIPs 186-3 below to show input and process) Input: (p, q, g) The subset of the domain parameters that are used for this process. p, q and g shall either be provided as integers during input, or shall be converted to integers prior to use. Process: 1. N = len(q); L = len(p). Comment: Check that the (L, N) pair is specified in Section 4.2. 2. If the (L, N) pair is invalid, then return an ERROR indicator, Invalid_x, and Invalid_y. 3. requested_security_strength = the security strength associated with the (L, N) pair; see SP 800-57. 4. Obtain a string of N+64 returned_bits from an RBG with a security strength of requested_security_strength or more. If an ERROR indication is returned, then return an ERROR indication, Invalid_x, and Invalid_y. 5. Convert returned_bits to the (non-negative) integer c (see Appendix C.2.1). 6. x = (c mod (q–1)) + 1. Comment: 0 ≤ c mod (q–1) ≤ q–2 and implies that 1 ≤ x ≤ q–1. 7. y = gx mod p. 8. Return SUCCESS, x, and y.
- [IPsec] Question about RFC 5114 Joy Latten
- Re: [IPsec] Question about RFC 5114 Kaz Kobara
- Re: [IPsec] Question about RFC 5114 Dan Harkins
- Re: [IPsec] Question about RFC 5114 Scott Fluhrer (sfluhrer)
- Re: [IPsec] Question about RFC 5114 Kaz Kobara
- Re: [IPsec] Question about RFC 5114 Scott Fluhrer (sfluhrer)
- Re: [IPsec] Question about RFC 5114 Joy Latten
- Re: [IPsec] Question about RFC 5114 Richard Barnes
- Re: [IPsec] Question about RFC 5114 Joy Latten