[IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt
Tero Kivinen <kivinen@iki.fi> Tue, 04 December 2012 14:24 UTC
Return-Path: <kivinen@iki.fi>
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 0BABE21F8B29 for <ipsec@ietfa.amsl.com>; Tue, 4 Dec 2012 06:24:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6Vcd+VTt-dI for <ipsec@ietfa.amsl.com>; Tue, 4 Dec 2012 06:24:55 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id CA21621F8AF2 for <ipsec@ietf.org>; Tue, 4 Dec 2012 06:24:54 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id qB4EOmZB010502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ipsec@ietf.org>; Tue, 4 Dec 2012 16:24:48 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id qB4EOlHM018597; Tue, 4 Dec 2012 16:24:47 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <20670.1967.744783.372876@fireball.kivinen.iki.fi>
Date: Tue, 04 Dec 2012 16:24:47 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
In-Reply-To: <20121204135025.24091.3591.idtracker@ietfa.amsl.com>
References: <20121204135025.24091.3591.idtracker@ietfa.amsl.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 25 min
X-Total-Time: 32 min
Subject: [IPsec] New Version Notification for draft-kivinen-ipsecme-signature-auth-00.txt
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, 04 Dec 2012 14:24:56 -0000
I posted first version of the signature authentication method. This is based on the design team work on the ECDSA, but as the design team decided not to forbid other authentication methods, I named the draft to signature-auth, not ecdsa-auth. This draft is initial version, meaning it has still some things missing. I would need some good references for different things, and then there is missing the text about the guidance how to select suitable hash functions. We decided that adding such guidance is good idea, but design team didn't specify what such guidance should say, so I need more input for that. Another thing is that we need to decide whether we want to fully support RSASSA-PSS. The current draft only includes the OID from the AlgorithmIdentifier field, thus it cannot be used with RSASSA-PSS when parameters are used (as pointed out by Sean earlier). Actually I am not sure whether we can even use it with defaults, i.e. can RSASSA-PSS be used at all. We might need to add text saying it is always used with default parameters or something. To fully support RSASSA-PSS we would need to include full AlgorithmIdentifier ASN.1 including the parameters. I myself would think that would be best option, as that would allow widest possible use for this new method, i.e. we can support whatever PKIX does. Some design team members disagreed, and we ended up with the current compromize... Other things: In my draft I say: ---------------------------------------------------------------------- For the hash truncation the method of X9.62, SEC1 and IO 14888-3 MUST be used. XXX Need reference for X9.62/SEC1 etchere XXX. ---------------------------------------------------------------------- I.e. the draft points to this hash truncation method. Does anybody have proper reference for that, and it might be good if we could summarize it here too, as not all people have access to those other specifications. In security considerations section I have text: ---------------------------------------------------------------------- The hash algorithm registry does not include MD5 as supported hash algorithm, as it is not considered safe enough for signature use. XXX Need reference for MD5 considered unsafe. XXX ---------------------------------------------------------------------- Does anybody have good reference for MD5 especially with signatures (not with HMAC). In the security considerations section I also have: ---------------------------------------------------------------------- The current IKEv2 uses RSASSA-PKCS1-v1_5, and does not allow using newer padding methods like RSASSA-PSS. This new method allows using other padding methods. XXX Need reference for RSASSA-PSS vs RSASSA-PKCS1-v1_5 security. XXX ---------------------------------------------------------------------- RFC4055 says " The RSASSA-PSS signature algorithm is preferred over the PKCS #1 Version 1.5 signature algorithm. Although no attacks are known against PKCS #1 Version 1.5 signature algorithm, in the interest of increased robustness, RSASSA-PSS signature algorithm is recommended for eventual adoption, especially by new applications." Is this still the case, or do we have some reference which would point out why RSASSA-PSS is better.... Of course if we cannot support RSASSA-PSS with the this new method properly, this text in the security considerations section might not be needed... In the security considerations section: ---------------------------------------------------------------------- XXX The text about the guidance how to select suitable hash functions is missing here. XXX ---------------------------------------------------------------------- I.e we need to guidance or references to good guidance. As this draft is no longer only ECDSA, the RFC5480 might not be enough. For RSA, or normal DSA might also need some guidance. What kind of guidance do we want here. internet-drafts@ietf.org writes: > > A new version of I-D, draft-kivinen-ipsecme-signature-auth-00.txt > has been successfully submitted by Tero Kivinen and posted to the > IETF repository. > > Filename: draft-kivinen-ipsecme-signature-auth > Revision: 00 > Title: Signature Authentication in IKEv2 > Creation date: 2012-12-04 > WG ID: Individual Submission > Number of pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-kivinen-ipsecme-signature-auth-00.txt > Status: http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth > Htmlized: http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-00 > > > Abstract: > The Internet Key Exchange Version 2 (IKEv2) protocol has limited > support for the Elliptic Curve Digital Signature Algorithm (ECDSA). > The current support only includes support for three Elliptic Curve > groups, and there is fixed hash algorithm tied to each curve. This > document generalizes the IKEv2 signature support so it can support > any signature method supported by the PKIX and also adds signature > hash algorithm negotiation. This generic mechanism is not limited to > ECDSA, but can also be used with other signature algorithms. -- kivinen@iki.fi
- [IPsec] New Version Notification for draft-kivine… Tero Kivinen
- Re: [IPsec] New Version Notification for draft-ki… Johannes Merkle
- Re: [IPsec] New Version Notification for draft-ki… Johannes Merkle
- Re: [IPsec] New Version Notification for draft-ki… Tero Kivinen
- Re: [IPsec] New Version Notification for draft-ki… Johannes Merkle
- Re: [IPsec] New Version Notification for draft-ki… Tero Kivinen