[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