From turners@ieca.com Mon Jul 2 16:17:52 2012 Return-Path: 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 4CC8811E80B6 for ; Mon, 2 Jul 2012 16:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 L7RPQaXwa0bl for ; Mon, 2 Jul 2012 16:17:51 -0700 (PDT) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.56.148.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7150011E80AA for ; Mon, 2 Jul 2012 16:17:51 -0700 (PDT) Received: by gateway13.websitewelcome.com (Postfix, from userid 5007) id 29737A10B54EC; Mon, 2 Jul 2012 18:17:58 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway13.websitewelcome.com (Postfix) with ESMTP id 1B180A10B54B7 for ; Mon, 2 Jul 2012 18:17:58 -0500 (CDT) Received: from [96.231.119.66] (port=41787 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SlpsS-0006aP-Q4 for ipsec@ietf.org; Mon, 02 Jul 2012 18:17:57 -0500 Message-ID: <4FF22C24.9090201@ieca.com> Date: Mon, 02 Jul 2012 19:17:56 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipsec@ietf.org References: <20120521055357.5840.39762.idtracker@ietfa.amsl.com> <68B8C17B-5EFC-4993-8AD0-2B7F666479FD@checkpoint.com> In-Reply-To: <68B8C17B-5EFC-4993-8AD0-2B7F666479FD@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.119.66]:41787 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [IPsec] AD review: draft-nir-ipsecme-erx-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 23:17:52 -0000 Yoav asked me to do an AD review of draft-nir-ipsecme-erx. We agreed that it'd be all right for me to send my comments here. They are as follows: 0) Overall: A couple of folks that I mentioned this to asked: is anybody really doing ERP? So I'm just curious if they are. This obviously non-blocking. 1) General: In case people missed it, the first EAP message for ERX is moved to the initial IKE_AUTH request. I haven't seen any objections to this but I'd like to make sure implementers are okay with this!? Maybe it's splitting hairs but could you do the following to maintain architectural integrity/purity (i.e., not mix them): first request --> EAP(EAP_Initiate/Re-auth), be this: first request --> N[EAP(EAP_Initiate/Re-auth)], I guess you could do the same thing for the first response. 2) expand AAA on first use 3) s3 contains the following: This Notify replaces the EAP-Initiate/Re-auth-Start message of ERX, and therefore contains the domain name, as specified in section 5.3.1.1 of [RFC5296bis]. Is "replaces" the right word here? I think what you're saying is that the Notify serves the same purpose as the ERX EAP-Initiate/Re-auth-Start message? I went to 5.3.1.1 and I think what you're really pointing to is the Domain-Name in 5.3.1, which is an NAI from [RFC4282]? Maybe switch the pointer to 5.3.1. 4) s3: In the intro to the protocol exchanges it says most of the optional bits are omitted, but that seems to only be true in the IKE_SA_INIT exchanges. Could the IKE_AUTH exchanged be trimmed down to (and depending on comment 0 the first line gets changed too): first request --> EAP(EAP_Initiate/Re-auth), IDi, SA, TSi, TSr, first response <-- IDr, AUTH, EAP(EAP-Finish/Re-auth), last request --> AUTH last response <-- AUTH, SA, TSi, TSr, Just curious if those optional fields aren't so optional anymore. 5) s3: Do you think the following would help the not so plugged in reader to add the following to the figure of the exchanges: IKE_SA_INIT +- | init request --> SA, KE, Ni, | | | | init response <-- SA, KE, Nr, +- N[ERX_SUPPORTED] IKE_AUTH Exchange with EAP +- | first request --> EAP(EAP_Initiate/Re-auth), | IDi, | SA, TSi, TSr, | | first response <-- IDr, AUTH, | EAP(EAP-Finish/Re-auth), | | last request --> AUTH | | last response <-- AUTH, | SA, TSi, TSr, +- 6) s3/6: Don't you have to register the Identification Payload type in IKEv2 Identification Payload ID Types? 7) s3.1: I think you need to be clear that the codes 5 and 6 came from RFC 5296: r/(5 and 6)/(5 and 6) [RFC5296] and maybe: r/or in this document/or in [RFC5296] 8) s3.2: r/EMSKName/EMSKName [RFC5295] and add it as a normative reference 9) s3.2: r/using the CLASS attribute in RADIUS and Diameter/using the CLASS attribute [RFC2865] in RADIUS [RFC2865] and Diameter [RFC3588] and add RFC2865 and RFC 3588 as an informative references 10) s3.3: r/LDAP/Lightweight Directory Access Protocol (LDAP) [RFC4511] and add RFC4511 as an informative reference 11) s4: I think you need an normative reference to 3629 for UTF-8 and you'll also need to say something more about the encoding. 12) s5: I think you did a good job explaining protecting the clients identity. Can you add some more text about exposing the servers identity first and why you don't think it's a problem? Cheers, spt On 5/21/12 3:16 AM, Yoav Nir wrote: > Hi Sean > > Since the IPsecME working group did not accept this document (or at > least did not accept it enough), we would like to have it published as > an individual submission. > > Will you take it to the IESG for us? > > Thanks > > Qin & Yoav > > Begin forwarded message: > >> *From: *"internet-drafts@ietf.org " >> > >> *Subject: **I-D Action: draft-nir-ipsecme-erx-04.txt* >> *Date: *May 21, 2012 8:53:57 AM GMT+03:00 >> *To: *"i-d-announce@ietf.org " >> > >> *Reply-To: *"internet-drafts@ietf.org >> " > > >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : An IKEv2 Extension for Supporting ERP >> Author(s) : Yoav Nir >> Qin Wu >> Filename : draft-nir-ipsecme-erx-04.txt >> Pages : 8 >> Date : 2012-05-20 >> >> This document describes an extension to the IKEv2 protocol that >> allows an IKE Security Association (SA) to be created and >> authenticated using the EAP Re-authentication Protocol extension as >> described in RFC 5296bis. >> >> NOTE TO RFC EDITOR: Replace 5296bis in the previous paragraph with >> the RFC number assigned to draft-ietf-hokey-rfc5296bis (now in the >> RFC Editor queue) >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-nir-ipsecme-erx-04.txt >> >> The IETF datatracker page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-nir-ipsecme-erx/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> Scanned by Check Point Total Security Gateway. > From Johannes.Merkle@secunet.com Tue Jul 3 08:59:28 2012 Return-Path: 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 98A2E11E8167 for ; Tue, 3 Jul 2012 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 MrWlU0Tcw4ZK for ; Tue, 3 Jul 2012 08:59:27 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3E67821F86DE for ; Tue, 3 Jul 2012 08:59:27 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id D4BF51A007B; Tue, 3 Jul 2012 17:59:34 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 02FD61A0071; Tue, 3 Jul 2012 17:59:31 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jul 2012 17:59:28 +0200 Message-ID: <4FF316DF.6050109@secunet.com> Date: Tue, 03 Jul 2012 17:59:27 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ipsec@ietf.org X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Jul 2012 15:59:29.0293 (UTC) FILETIME=[D3F67BD0:01CD5934] Cc: "Biester, Jobst" Subject: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 15:59:28 -0000 Hi, in RFC 5639, we have specified a new set of elliptic curve parameters for use in cryptographic applications. Meanwhile, support for these "Brainpool Curves" has been included in some crypto libraries as openssl (recently) and crypto++. However, in order to use the Brainpool Curves with IKE and IPSec, still some specifications and IANA registry updates are needed. We are now planning to prepare such an RFC to allow usage of the ECC Brainpool curves with ipsec. In order to go forward with this effort, we would like to discuss some questions and potential issues. The WG feedback on these is most appreciated. [Question 0] Is the WG interested in shepherding an RFC specifying all that's necessary to use the Brainpool curves in ipsec? And what category would be preferred, standard track or informational. [Question 1] Should we include IKEv1 in the specs as well? It seems that some people in the WG do not like the idea of updating this obsolete protocol. On the other hand, many applications still use IKEv1 and specifying the use of the Brainpool curves only for IKEv2 would exclude these. [Question 2] If IKEv1 is to be considered, the registry for IPSEC Authentication Methods (Value 3) needs to be updated, because the values for ECDSA are specific for each curve. What policy for updating this IANA registry can be assumed? IANA currently requires a standard track RFC, but there has recently been some discussion on relaxing this, in particular, http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . For the corresponding IKEv2 registry (Auth Method), only Expert Review is required. [Question 3] If IKEv1 is to be considered, it seems reasonable to write only one RFC covering IKEv1 and IKEv2. Actually, we also plan to prepare analogous specifications for TLS, so an option would be to write a common RFC for IKE and TLS analogously to RFC 5114. However, according to the update policy of the IANA registry EC Named Curve for TLS, such an RFC would have to be shepherded by the tls WG. Does this prevent or considerably complicate the creation of a joint RFC for IKE and TLS? Would preparing separate RFCs for IKE and TLS be preferable? [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, 320, 384, 512 two curves are defined, one being the “quadratic twist” of the other – their algebraic structure (and hence, security level) is equivalent, but one of them allows particular efficient arithmetic. In order to leave the choice of the curve for a given bit length to the implementation we propose to register IANA values (for Auth method and Diffie-Hellman Group) for both curves for each bit length. Of course, this doubles the number of number assignments. Any objections on this? [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but also ECGDSA (Elliptic Curve German Digital Signature Algorithm) according to ISO 14888-3, which is a slight variant of ECDSA. The advantage of ECGDSA over ECDSA is that signature generation does not need any inversion modulo the group order, which removes the necessity of corresponding code. This advantage is particularly interesting when using devices with limited computation power and storage like smart cards or electronic control units in cars. In particular, car manufacturers have expressed their desire to deviate from EDSA For this reason, we would like to specify values for ECGDSA (with the individual bit lengths and curves) as Authentication Method as well. Would the WG support inclusion of this additional signature algorithm? [Question 6] In cryptographic applications using elliptic curves, point compression (see Section 4.2 in RFC 6090) is frequently used in particular in environments with limited bandwidth and storage capacity. However, in IKE this mechanism is currently not supported as, according to RFC 5903, the KE payload consists of the concatenation of two components, x and y, each of which having the same length as the underlying finite field. We propose to add support for point compression for the KE Payload to IKE by allowing also the use of a compressed form of x, e.g. of 64 bits, representing only the least significant bit. In contrast to the (obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 does not specify a data format for the ECDH KE payload in which the uncompressed form is explicitly specified (e.g. in a leading byte), uncompressed and compressed form could only be implicitly distinguished by their bit length (as specified in the KE header). Does this raise any issue with implementations? What are your opinions and preferences? Johannes -- Johannes Merkle secunet Security Networks AG johannes.merkle@secunet.com www.secunet.com From thapar.dt@gmail.com Mon Jul 9 03:02:36 2012 Return-Path: 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 93F3621F87AF for ; Mon, 9 Jul 2012 03:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.398 X-Spam-Level: X-Spam-Status: No, score=-0.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] 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 1832XSYdhK-w for ; Mon, 9 Jul 2012 03:02:35 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41C8721F8637 for ; Mon, 9 Jul 2012 03:02:35 -0700 (PDT) Received: by yenq13 with SMTP id q13so10827935yen.31 for ; Mon, 09 Jul 2012 03:02:59 -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=OhQ8JqAsQfTRuN2SdVjxNeiNPh2NVs/a9dcxxrqcJP0=; b=qgzZz7mcWptGn01piqjqY1210hDJelz7BfBZJ3hsvDaM6LIcbQqzY865MPIVwLR1JH 7ffQuALdVRbvt6i04lYUDOf4hg98vG0tHvqgeRuoI2Aveeh7NSWS/E6EUrA7SPUsEAFv T5HWn8lbso4pImEWaf/mKNnyvX9mwJ2TmDk6r8hZHqXLxENm3QkcKM5SC57CG/343UwS 4hfe30OYo1erabNnCSZZFnEqJ72TN7JHwLvdE65myWmObxsoy4VYxglXYoTwqUJ5SPM6 xw+OwaVMlanYapSh/J2UpXuYl8Clsv8m3Jwqby4HMIpgdedtoZOHrcdGojI7NTitLZ3u ckgA== MIME-Version: 1.0 Received: by 10.50.6.230 with SMTP id e6mr7908265iga.47.1341828179176; Mon, 09 Jul 2012 03:02:59 -0700 (PDT) Received: by 10.64.36.163 with HTTP; Mon, 9 Jul 2012 03:02:58 -0700 (PDT) Date: Mon, 9 Jul 2012 15:32:58 +0530 Message-ID: From: DT To: ipsec@ietf.org Content-Type: multipart/mixed; boundary=e89a8f646b35f82da404c462b7a1 X-Mailman-Approved-At: Mon, 09 Jul 2012 08:13:07 -0700 Subject: [IPsec] Query about behaviour of IPSec in multicast context X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 10:03:49 -0000 --e89a8f646b35f82da404c462b7a1 Content-Type: multipart/alternative; boundary=e89a8f646b35f82da004c462b79f --e89a8f646b35f82da004c462b79f Content-Type: text/plain; charset=ISO-8859-1 Hello I am in the process of using IPSec with multicast traffic but there is one behavioural aspect I'm not clear about. I've attached the scenario along in a .doc file and I'd really appreciate if you could let me know the appropriate behaviour. -- *Regards* *Dikshit Thapar +91-9910014571 I'd rather go down swinging than not try at all.* *Laugh while you still have teeth and you may smile later on. * *We do not live to earn,we earn to live.Be a player - Life is a playground.* --e89a8f646b35f82da004c462b79f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello

I am in the process of using IPSec with multicast = traffic but there is one behavioural =A0aspect I'm not clear about. I&#= 39;ve attached the scenario along in a .doc file and I'd really appreci= ate if you could let me know the appropriate behaviour.=A0


--
Regards
Dikshit Tha= par
+91-9910014571

I'd rather go down swinging than not try a= t all.
Laugh while you still have teeth and you may smile = later on.
We do not live to earn,we earn to live.Be a player - Life= is a playground.

--e89a8f646b35f82da004c462b79f-- --e89a8f646b35f82da404c462b7a1 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Query.docx" Content-Disposition: attachment; filename="Query.docx" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h4fdset80 UEsDBBQABgAIAAAAIQDd/JU3ZgEAACAFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMtuwjAQvFfqP0S+Vomhh6qqCBz6OLZIpR9g7A1Y9Uv28vr7bgJEVQtBKuUSKVnvzOzsxIPR2pps CTFp70rWL3osAye90m5Wso/JS37PsoTCKWG8g5JtILHR8PpqMNkESBl1u1SyOWJ44DzJOViRCh/A UaXy0Qqk1zjjQchPMQN+2+vdcekdgsMcaww2HDxBJRYGs+c1fd4qiWASyx63B2uukokQjJYCSSlf OvWDJd8xFNTZnElzHdINyWD8IENdOU6w63sja6JWkI1FxFdhSQZf+ai48nJhaYaiG+aATl9VWkLb X6OF6CWkRJ5bU7QVK7Tb6z+qI+HGQPp/FVvcLnrSOY4+JE57OZsf6s0rUDlZESCihnZ1x0cHRLLs EsPvkLvGb1KAlHfgzbN/tgcNzEnKin6JiZgaOJvvV/Ja6JMiVjB9v5j738C7hLT5kz7+wYz9dVF3 H0gdb+634RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgCX3JlbHMvLnJlbHMg ogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2jILpQ217m9OfLT9ab g5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyMMaui4rOGQSQ+ImYz sKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdh b9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1nANaXg902aJ5x687 HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDWZLNR+gAAADEDAAAcAAgBd29yZC9f cmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AKySzWrDMBCE74W+g9h7LTv9oYTIuZRArq37AIq9/qGyJLSbtn77CkNShwb34otgRmjmk7Sb7Xdv xCcG6pxVkCUpCLSlqzrbKHgvdnfPIIi1rbRxFhUMSLDNb282r2g0x0PUdp5ETLGkoGX2aympbLHX lDiPNu7ULvSaowyN9Lr80A3KVZo+yTDNgPwiU+wrBWFf3YMoBh+b/892dd2V+OLKY4+Wr1TILzy8 IXO8HMVYHRpkBRMzibQgr4OslgShPxQnZw4hWxSBBxM/8/wMNOq5+scl6zmOCP62j1KOazbH8LAk Q+0sF/pgJhxn6wQhLwY9/wEAAP//AwBQSwMEFAAGAAgAAAAhAAOe9N2jCgAADzwAABEAAAB3b3Jk L2RvY3VtZW50LnhtbORbzZKjOBK+b8S8g4K9TEfYLsSfMd3lOWxPz/Rlt6J39jyBQS4TBYgA+a9P 8w5z2tebJ9lPAlyAXR7s8nZ5wtVR7UKIlDLzy9QnlP7wwyaJyYrlRcTTe42OdI2wNOBhlD7ea//5 5dPQ1Ugh/DT0Y56ye23LCu2H6Xd/+7D2Qh4sE5YKAhFp4a1wdyFE5t3dFcGCJX4x4hlLcXPO88QX uMwf7xI/f1pmw4AnmS+iWRRHYntn6LqjVWL4vbbMU68SMUyiIOcFnwv5iMfn8yhg1Uf9RN5n3PLJ j9WU1Yh3OYsxB54WiygramnJudKg4qIWsjqmxCqJ637rrM9oYe6v4Y8kLqe95nmY5TxgRYHWj+XN nUSqHxu7MqAUsXuizxTaY9YzSfwo3YmR6Oj4f+e8EZx3V459J0U9KwJbTIGlGQ+38jMjaw9YDL/c a7r+44+6++mjVjd9ZHN/GYv9Ow+yyflkW46uhOVSUv6gPlL+kHM+v5t+uNu1ZVEgph9WXrHwMya2 GSNReK/9utHx86swDY0EHJMsoq9QyaCOrg/U/xrhXpFhArIL9xAPeExoBEhe3GvJIG70ZRqZR3Es e8wxqZUnOxE/z/maP6mn5G3551zKCniaskDIydxrKSRrmDH3Yh48kZXHNhiUhRHG2s1ZypBaNdTY 6dTUp6C6NdZIKfnvTSULsY0xWsaLSEaB588KHi8Fe48YfYzSYczmwjMMOqKZqNsEz7yJO3LRso5C sfBsS10sWPS4EJ7+fh5Hmbd5/3UYpSHbeIZNnfFkbFkNJXleTqYQuS+fkgkm509srWTca3I8pRrg oDwlPadceopfuzZAgjnXBtSBxnbbCNSejBzZVprBcEbyojKDOR5Z8vKQMdyxgRy78/jbGMM+3xgH ANG1BbR/yRZk24bG2JnAMW9sDYDzXGgYE3Okd6FB9ZH9DA1bHznP5qD2aLxDRtcajjNWmaXKBm+D DfOy1rDNkflsDMsZGfKqDhSqwuZQnNiOBerxxsiAN85GBhLnpIOMITWg+3PGaFpi0kgZnSCxHOPt 8yc93xSH8mfXFA1MNC2x6YaIidX4zWGBGZwNCx0rRQcWltXMF3odHJY+MmGW1lJq2OM3z5fm5Hz1 KTX3oqLFJ1zaXDwO8wlq2980TfKVH3fohAlK1Y8/mbZK/xWnkvxpaLrNlAjq0FgfjHJ9yLlQWxOP unoLAc7E1pEMDjAmyf4EmOKMb+qpJQUfpmgaVu1ezf9ACqUGUVowMEt9oP6Bpq49sZlt/sFTgX2d vGzx8Ypi13z8ARsvXZ98sqgBPlHx9gZJb3fvkvSs5OcVTS++QgDMDL6tV9xP3QH1qzs2yN9LvTF9 uYsESfcDyWxzVrB8xbQpIRPJ/6FSySWlWPV3S11w6cpQildLt6tO57HQQ6hB7PZCDRDeZd1DSSqb q8cpoHEtFznrAqCBAjcEGvcqQIPg6gUaYz/V0MlY4WhHOU4BzdiyFV739manZhoocEOgGV8FaNQa 0WN/T63J/t72NahxLPl25AKpBhrcEGqcq0AN9n69Uo1pmeXbjwatobSkbmflGtvS1YvmV+caaHA7 qKHGVaBGxXuPXGOaE7WjaYAGS5baJJ8FGst0L0OFocDtgIZQehWowQuFXrmGTuxyu9SAjRGlz69R TuE0Jt4fXGR1wuxvCDL2VSBGea5HnjmEGFq9wj8r0RiAzUVQAw1uCDXmNaDGwNuqXnnGGGMtwga7 kWZcHG7Jd3VngYaa9CJEWCpwQ6Ch+lWgRrHRM3PNq2CjG+5FmLABKTcEG+sqUNP3rbA73qM0rwGN PTGcizBh47ZeCpNvv39S9RudwwR50HnJ8yTaPoDeHSiZ5otnjK4+djCL1x63lu/VO8cG55TxoLLl 7aVUE1dTKU8rBGpk5CU+6/MKWSUjTz9QRoP6Od02q+OLsqs0SHXQ0Ti/OFaUdODYwOh7bDCsztob FAbHSecyGNs1rItsluT8b2gp+vbb60NJxXxNUjHLKo0Gjtr7J8dSxwpHq750W1KQ12aUqvQL0VSV 8JUncteQHqrzzatIVX+JubQPhL/0PipWxX9i+k8esoLQATEHxB2QyYDYA+IMyHhAqI5f3KEGSiwZ +fzwbxagjtmfoQBz1GKGNZ5eOCc+2Hf6y4JBqpQsFjljJEEZahT4hSCPOV9mxcGnXhhheErnn6R4 Qsn3Svedwu8GpLxjVHdqk7wbnCIdVd2ndC+HNOshn23+rm3igyTgHN/vR9Y5UtS6qxbtwx6RpoWJ owLObbo29IVPCr7MA7idEz+OSddaddFDoyT5yEBSfFeC6j7t4umb2dNybV0H5z+1eKOMyJfsuR6Q 9cIX5PMfv/03IWuOSuAclerSxOsFgxnyPTvUM+hnST89KqDS6ogronTGl2lYJYrDTkENyRMTKLjm yzgkM0aqmnsWgsyE0SoKl8DElkBR5gcLkrBkBs34vIMjlSJIlKMYJUOJd7RidR+2iQoU2gBfeMhP tySMcvQg2WJbIL3EqrBcYg8mS1qTPBhiHWeW5TmdxkbObd85Xp5TL76SyjYobe211lDS7FVVT/Mx WX3zry9/rsX/I8Q/S/PCa4LlCcrofcEIvpOy9nP5NReSygQAbPodF7bmCp1qbSVG/xxihZ+8EO6H w6aTAwYkEq8E+RpfMNgTcSQocpZwgFOmqXIB/Zn5iFwyz3miWquIAJDl+icDOlXtIYuB6nwrYZzF +E4IgCtj5/vinYyOSBQkWERxmDM4YcRG6iGu8kAZNEUdEWWsrBcR4imAyxB1uQwuxBxWXr58XKhn q6ysHPfI5Uz6+mpaien2P2IWNeJR7PA03vZI2e2Aa9Kf9p1mKO4vge2+/aSokKzh2zdYP8fxEmUc qgzxFHP98dvvbXf0SVa98tIFjaH8PUWhI75rBIgj9HeUrkI50i7QV8jvt6kAqGiCZAKNziVg/wcA AP//rFNNb9swDP0rhE8bEKRuPho3aHwo2u60zUgH7CxbjC3UtgSJmZf9+lGyvSZpCwxFL4ZIie89 ks9dpR1Cg02O1oGwCN+0RAfzCSQTEK2E6yn8qBCMKJ6QQDnAtrAHQyhBUHgNl/CJrGid0Zag4frP U/hZYQvEhc/Pm31NqhCORjCLoqiYzFN6RlfpfS1DlRPNcenAniPstO2ElcxOetCa9DrDlxkPIDEo DEAvSHWQpSzorr256NaU+q8NX5PedGsDHDolt5sojhfJMo5X0Zi6w53gLl7eZD519bBcXMWRB2G8 bl1zr1tsJVqUmSjxlht+uvA3BL+beu24LdxExqJD+wujFE4EMcrIm9kjyoCfBYac0bz6PqL0+/Yc 4b/ZGOaD26e0XyxIzUv2XhgWo3gHRrBXvL84305A0bjZ/qWphfKPgunON33e4zglP6P7+zh5uAs7 eGvIaorTIEczt4XS6r0Zf4Fz6DC+dHqSfnVSt6v5dTx/p1HeUvoqrcOCsn/O8D2fcj/y/VHWd2DK xz88pG4TXc5mi9irrPi8TPgc/GjKr8JDkjacX/RPrCorRhrDXBPp5jmucXd0W6Fgn2+i1SzA77Sm o7DcUwgHukLXjtkG//uSoELq4otVkm9q1WKmqGCVc/6jepf3jQfD51oewoFL9g22lP4FAAD//wMA UEsDBBQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPb9s2 FL8P2HcgdG9jJ3YaB3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZ Omwd0K+wR1KSxVhekjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlI KpwEmPGEtL0pkd61jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjG bGm5VltdijFNPJTgGMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/A j4bkvvIQw1LBRNurmZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1 ur16Qc8AsO+DplaWMs1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz 2cEbkMU35/CNzma3u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgo okuzGPNELYq1GN/jog8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkx o/fq+fevnj9Fxw+eHT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8 eTUQ0mcmzosvn/z27MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4 wZpLBf2eihz0zSlmmXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnC auZiUsbtY3xYxbuLE8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5F HUwrTTKkIyeaZou2aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4D q6hKyMFU+GVcTyrwdEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd 0CQqYz+QBxCiGO1xVQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqXUKqdChzT5O/KMaNQ j20MXFw5hgL44uvHFZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI8/mN513JfVdyvf98 yV2Uz2cttLPaCmVX9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklxYkojeMzquoMLBTZr kODqI6qiQYRTaLDrniYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLADq/o4fxcUJAxu01o Dp85oxVN4KzMVq5kREHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig 7W733twtxgsX6SIZ4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbczuKkMrvGAna5997E S3kEz7yk8/ZEOrKknJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF 3CSowzWFtfucwk4dSIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D416QAO7quJeMx8VXZ 2aURbTv7mpVSPlFEDKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwlXfn2yuDsOGZphLNy q1M0z2QLN3lcyGDeSuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJp RP2+gMbB1A6IFriLhWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5Jl hExElcSVqRV7RA4JG+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl 1mHT0OT2L0Ss2FXterM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK 4b4H6T+w/1HhM/tlQm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJWdNmrZO2Wr5ZX3Cn W/A9YWwt2Vn8fU5jF82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIqf3Xio3vg6C24358w JU0wwTclgaH1HJg8gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQAtBt2BcAMAAB0JAAARAAAA d29yZC9zZXR0aW5ncy54bWycVl2P0zoQfUfiP0TmlW7SNm23Flkkdikf2r33igCvyEmc1lp/yXaa Lb/+jpOYthRQxL6sc2bOmRl7PO6r10+CR3tqLFMyQ9OrBEVUlqpicpuhL583k2sUWUdkRbiSNEMH atHrm+fPXrXYUufAzUYgIS1WGWqMxLbcUUHsRLDSKKtqNymVwKquWUmHf2hgmAztnNM4jgfSldJU glqtjCDOXimzjXvmnSobQaWLZ0myjA3lxEHCdse0DWrib9Ug1C6I7P9UxF7w4NdOkz95DuW2ylQ/ GGPS8wRtVEmthZ0VvC9XECaDjOVjdPr9vGeFIeZwInIDx/ZdKRG1WFNTwoZmaL1CscchrqpzRxwF q9WU864HSk4JRG/x1hAhCJxZj3Scitak4e4zKXKnNDjtCeS3miW9ZLkjhpSOmlyTEtRulXRG8eBX qX+Uu1VCG6h3YMAXcZ02tGRlfWJ+8UkpF2jQAZtFuhxieOvRkl4vkmQo6Nzye85qnc42v1R7s5qv k3mf2bna27fJ9ebOW+I+QchUYN9J/5mw2kC1kei35JaIwjASPfheA5bAhXl8w2SwFxR6np5a8qYI xsmkN1hBON/AjgYDtFlvqZjVd7TuhPkDMdujcleYwOaXKJzfxx9qvh2oeWdUo3vV1hD9QVYAh4DT NB30mHT3TATcNkUeWBJa7sTUyOrfvfGC8XGDWuxgSlC/Q/dEbsP5UTn5knvXFpfc5H6S0AeiNbQO uBTbaYY42+7c1Pejg6+KmMfuo9jOBtuss8GXt3UfpPSVgfew8A79EryGxRGbB2x+xNKApUdsEbDF EVsGbOmx3QHuGFyiR7ixYenxWnGuWlq9D2CGLqB+E+yOaArn6u8YNJjCHTBcOhvtMX2CC0wr5mBI a1YJ8pShWbLozmjw5uSgGnfm65W8sz5Do4o4Ak+AD62waTg9j9ChEasy9BV/Aivsu4MKYB4oKWnp lEFgNbTO0ItvTwn8fbPTZH496J0w4VTGMNeXTDiTEcy+R6GGk5hwcmOYofoTJpzvGObsMlvogjHM bsCcZ7sax0wvY8JzPSbm4pK5HsdcXjKn8KNhTNBuLp8XOh3XRWnXRfHQljBKzpq7G8I/3ZUWV7Rk MDDzgyiOT86Vz77FnFmXUw2vE7QtXMnu2XrpbTDOw++am/8BAAD//wMAUEsDBBQABgAIAAAAIQA0 8OyapgEAAA8FAAASAAAAd29yZC9mb250VGFibGUueG1sxJNNTsMwEIX3SNwh8p7GSQuUihSVQpcs EBxgmjqNJf9EHreB2zOxQ1mUQrtAJFKkvLFfJp/f3N69aZVshUNpTcGyAWeJMKVdSbMu2OvL4mLM EvRgVqCsEQV7F8jupudnt+2kssZjQvsNTlzBau+bSZpiWQsNOLCNMFSrrNPg6dWtU1tVshQPttxo YXyac36VOqHA07exlg2y3q09xq21btU4WwpEalar6KdBGjbtu0vaiQFNXc9ByaWTodCAsSgyqm1B FYznfMEv6dndIz7sniztHMoaHAq/W8ijXIGW6v1TxVYixkIjfVl/6ltwEpZKxBLKNRU2uOQFe8w4 5/liwaKSFWxEwmy+U3JqKl43/ZrhTqHjocaCT1iS3QQfUsin3xX6TOP57JF4kVpg8iTa5NlqiKj2 ieT8ikhcEo+OzPAkIi74BoJHEqEg8Hw2vv4iMu5/pVe+iFAaA8cfiESOxxOZ0UGpA8m4Jw6jkIw+ H3+ajP/lMAdNIwIHSHRJiInoknHajJyeiMfu/PdmhI++mZEwETRZPyTi1xnphwWnHwAAAP//AwBQ SwMEFAAGAAgAAAAhAErYipK7AAAABAEAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbIzOwWrDMAzG 8Xth7xB0X531MEpIUiijL9D1AVxHaQyxZCRt3vb0NWyX3XoUn/jx7w9faW0+UTQyDfCybaFBCjxF ug1weT8976FR8zT5lQkH+EaFw/i06UtX8HpGs/qpTVVIOxlgMcudcxoWTF63nJHqNrMkb/WUm+N5 jgHfOHwkJHO7tn11gqu3WqBLzAp/WnlEKyxTFg6oWkPS+uslHwnG2sjZYoo/eGI5ChdFcWPv/rWP dwAAAP//AwBQSwMEFAAGAAgAAAAhAMWhwXbhAQAA3wMAABAACAFkb2NQcm9wcy9hcHAueG1sIKIE ASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFNNb9swDL0P2H8wfG9kB0MWBIqKIcXQ w7YGiNueOZlOhMmSILFBs18/2m4cp9tpPj1++PH5kZa3r63NjhiT8W6dl7Miz9BpXxu3X+eP1deb ZZ4lAleD9Q7X+QlTfqs+fpDb6ANGMpgypnBpnR+IwkqIpA/YQppx2XGl8bEF4jDuhW8ao/HO65cW HYl5USwEvhK6GuubMBLmA+PqSP9LWnvd6UtP1SmwYCUrbIMFQvWjk2NntadWijErK09gK9Oims85 P0ZyC3tMinMDkM8+1kmVy6UUA5SbA0TQxBaqsvi8kGKSkF9CsEYDsbvqu9HRJ99Q9tD7kHUEUkxb JHuzQ/0SDZ1UIcU0lN+MYyk8eAAsLcI+Qji86RsjudNgccMGqAZsQikuCXmP0C13C4YFyyOtjqjJ xyyZ37zeeZ79hISdbev8CNGAI7avaxuCHtuQKKrKkGVurg1xD6dtU2w+qbJvYHDd2BEMGrhwra6f kB4a/lL6h9hyKrbXMEidyJnAccY71o1vA7gTDx8RG/wrPYbK33Un8+bhdXKy9mdDh10Azcsp5ws+ lcsBTEpyx3eCNW/0THhJyHv2O9puKr/r9life/4udCf1NPyvPG5W8NPf0DnHlzr+SOoPAAAA//8D AFBLAwQUAAYACAAAACEAVZpdoHIBAADZAgAAEQAIAWRvY1Byb3BzL2NvcmUueG1sIKIEASigAAEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLLTsMwEEX3SPxD5H1ip5F4REkqAeqKSkgUgdgZ e9qaxg/ZbtP+PU7Spo1gwc4zc+d45trFdC/raAfWCa1KlCYERaCY5kKtSvS2mMV3KHKeKk5rraBE B3BoWl1fFczkTFt4sdqA9QJcFEjK5cyUaO29yTF2bA2SuiQoVCgutZXUh9CusKFsQ1eAJ4TcYAme cuopboGxGYjoiORsQJqtrTsAZxhqkKC8w2mS4rPWg5Xuz4aucqGUwh9M2Ok47iWbs744qPdODMKm aZIm68YI86f4Y/782q0aC9V6xQBVBWe5F76GqsDnYzi57dc3MN+nhyAUmAXqta2iruEUtT5v4NBo y13oGUWhiYNjVhgfXq8njhJBXVPn5+E5lwL4w6GF/062d1jYifYPVGmnGMKwR2dbPx7wKBiR97ad Ku/Z49NihqoJSScxuY3J/YLc51mWE/LZ7jLqb43pE/I41f+IKQm4MfEE6G0Zf8bqBwAA//8DAFBL AwQUAAYACAAAACEAxGSSoagHAABhOwAADwAAAHdvcmQvc3R5bGVzLnhtbLSbUVPbOBDH32/mvoPH 7z0gUHJlmnYolGtnWo4SmHt2bIXo6lg5SynQT3+rla04dhzvYvcp2Jb2J2lX/3WC9u37p2Ua/BC5 liqbhEd/HIaByGKVyOxhEt7fXb36Mwy0ibIkSlUmJuGz0OH7d7//9vbxTJvnVOgADGT6LJ+EC2NW ZwcHOl6IZaT/UCuRwbO5ypeRgcv84UDN5zIWlypeL0VmDkaHh6cHuUgjA3C9kCsdFtYeKdYeVZ6s chULrWG0y9TZW0YyC9/B8BIVX4p5tE6Ntpf5TV5cFlf4caUyo4PHs0jHUt7BwGGKS5mp/NN5pmUI T0SkzbmW0c6HC9tq55NYm4q1DzKR4YEl6p9g80eUTsLRqLxzYUewdS+Nsofynshe3U+rI5mE/tYM 7E7CKH81PbfGDnCa5WdluqutycMVDmUVxbBwwInmRoADwR+Wk0rr6NH4tLy4XadwI1obVUDQAMCq ZuGytuLgV/Dy1EUJPBXzLyr+LpKpgQeTEFlw8/7zTS5VLs3zJHzzxjLh5lQs5SeZJMIGZXHvPlvI RPyzENm9Fsnm/rcrDLHCYqzWmYHhn44xClKdfHyKxcqGGJjOIuvha9shtWZ1hYMDWsvNaNyNGhVv /lcij5wPd1IWIrLbKMDx7wXhrNe9QSM7o+oE0C5rrMf9TZz0N/G6vwkM3n5rMe4/ChDPvh5xsVGJ SrpTjYpd8FXX4fjNnpC1PRpR1NmjETSdPRox0tmjERKdPRoR0Nmj4fDOHg3/dvZouHNvjzhC4apH 0TGuBmlj30mTCtt/rwAd9ZS6ItUEN1EePeTRahHYxFof9j6xnK5nhjZUlNOXi+XU5Cp76FwRyM52 675Ykz8uV4tIS3ij6Vj6Uc+lv4tmqQj+ymXSiXrtgq8xJ3wx2ZnCbtIoFguVJiIP7sST8yij/7UK pu4to3NwPd36RT4sTDBdYMrthJ22LHr7Sjj7X6TGNdi7mU5bptJlnOTD05a4bDf+VSRyvSyXhvA2 cur0nOHmGgKHuH+JTqyLmrurcxbWAZQpuHTBnwLaJ4zfJRe+fetjyvhdKnqhfcL4XeJ6oX2Mj/3+ ZSvNZZR/D0jba8zeuxcqVfl8nZZ7oFMexuwd7BG0KbA3sbdPEokxewdvyWdwHsfwzY0Sp2xfbHSU QWG7w1Fws9HnwnZKTfaOGDNiO6jGGjFY/bSWAWKL7q34Ie0PT9xkgCrt3zU7t/NxywpACiK9Q39b K9P9Dj1q0Twq5XMGP5doEdBoxy07j0or4snlO4aP+yU+BqhfBmSA+qVCBqglPtrfeXxOpEP6J0cG iy3LPoth2JGVecxWZg/ipYCB8ibh/atl97bHQjNvEihsBzXzJoHC9k4tl/m8SWANljcJrJas0e6j qqZyJsXOm1WQfxMgzGgY8SaAhhFvAmgY8SaA+ot3N2Q48Saw2NrgNbUq3gQQNuF81fegqngTQGxt cGpX/GZU5j20sv/L7QDiTaCwHdQUbwKF7Z028SawsAknEmosL3UE1jDiTQANI94E0DDiTQANI94E 0DDiTQD1F+9uyHDiTWCxtcFralW8CSC2PHhQVbwJIGzC0Yad4o27/peLN4HCdlBTvAkUtndqgupf UgkstoNqLC/eBBY24QRDwcLg5kxqGPEmzGgY8SaAhhFvAmgY8SaA+ot3N2Q48Saw2NrgNbUq3gQQ Wx48qCreBBBbG3aKN27GXy7eBArbQU3xJlDY3qkJqtc5AovtoBrLizeBhfHSW7wJIGzyUhBnRsOI N2FGw4g3ATSMeBNA/cW7GzKceBNYbG3wmloVbwKILQ8eVBVvAoitDTvFG/fILxdvAoXtoKZ4Eyhs 79QE1Ys3gcV2UI3lpY7AGka8CSAMzN7iTQBhkxeAcBdx3DSMeBNmNIx4E0D9xbsbMpx4E1hsbfCa WhVvAogtDx5UFW8CiK0N9pwtnBclH089agkC6jmD8lQDGThqcRIVWEzwVsxFDpVMovt0SE9gOUMG sSU8qFP8oNT3gHaw+7glQMgoOUulwiPdz3hKp1KIcDzeU0lw9/dF8MkVwDT6YUhtn7yB6qFquRCW J9nCIRineV5Byc6qPFlurUGBkK3rKkqAsA7tMxQEFWU9trOt84GGWFRV3Mb/2xZU/Btq3pKyDVSi Xb0+gWPB+KQokFJQFzdP1ePNOouNb+ma2Gooe7RZXH5sfXJdf5L8u9bm1p5U/pxt0M6g9tVYMwE1 czDlI3c0vCzOOsF/OxXFWZuL7eIsWC44pn2eyofMltiVA5hFWtieFuXqtuwiQUkcfmwVwU3C81y6 4qiy9G0S3sklVPpdi8fgVi0jPK+FpW+VxrFuNsPF1D8r9W24wDACRMMn+q7p7XgB7o6hKG2Pt4ua A38MDCsO6r5vKUzAgW2qYsplKgoUNq+xrt3WMVm3gi3jNvYw/p4x42H9vWEaYBMXEs0BQn2cW1Nf trZ7hP5gGz42s9R5Gv5wgQf1lRhNbm8lT5EzC88vRJp+jTAujFrBwrQ0TcXcRhc8PTrEF5KaqZky Ri3b++d4Xr/VAIRGdTDu0k6iPWay9XImcii427P+18omciwM3FYId/TYLaaXuDIsqKu+GVv5l373 PwAAAP//AwBQSwECLQAUAAYACAAAACEA3fyVN2YBAAAgBQAAEwAAAAAAAAAAAAAAAAAAAAAAW0Nv bnRlbnRfVHlwZXNdLnhtbFBLAQItABQABgAIAAAAIQAekRq38wAAAE4CAAALAAAAAAAAAAAAAAAA AJ8DAABfcmVscy8ucmVsc1BLAQItABQABgAIAAAAIQDWZLNR+gAAADEDAAAcAAAAAAAAAAAAAAAA AMMGAAB3b3JkL19yZWxzL2RvY3VtZW50LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhAAOe9N2jCgAA DzwAABEAAAAAAAAAAAAAAAAA/wgAAHdvcmQvZG9jdW1lbnQueG1sUEsBAi0AFAAGAAgAAAAhAJa1 reKWBgAAUBsAABUAAAAAAAAAAAAAAAAA0RMAAHdvcmQvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQA BgAIAAAAIQAtBt2BcAMAAB0JAAARAAAAAAAAAAAAAAAAAJoaAAB3b3JkL3NldHRpbmdzLnhtbFBL AQItABQABgAIAAAAIQA08OyapgEAAA8FAAASAAAAAAAAAAAAAAAAADkeAAB3b3JkL2ZvbnRUYWJs ZS54bWxQSwECLQAUAAYACAAAACEAStiKkrsAAAAEAQAAFAAAAAAAAAAAAAAAAAAPIAAAd29yZC93 ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAxaHBduEBAADfAwAAEAAAAAAAAAAAAAAAAAD8 IAAAZG9jUHJvcHMvYXBwLnhtbFBLAQItABQABgAIAAAAIQBVml2gcgEAANkCAAARAAAAAAAAAAAA AAAAABMkAABkb2NQcm9wcy9jb3JlLnhtbFBLAQItABQABgAIAAAAIQDEZJKhqAcAAGE7AAAPAAAA AAAAAAAAAAAAALwmAAB3b3JkL3N0eWxlcy54bWxQSwUGAAAAAAsACwDBAgAAkS4AAAAA --e89a8f646b35f82da404c462b7a1-- From dharkins@lounge.org Mon Jul 9 09:50:06 2012 Return-Path: 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 A7E6A21F86DC for ; Mon, 9 Jul 2012 09:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.336 X-Spam-Level: X-Spam-Status: No, score=-5.336 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 xQ-Gix6Z+b0y for ; Mon, 9 Jul 2012 09:50:05 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6E44E21F86E2 for ; Mon, 9 Jul 2012 09:50:05 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 09EDA10224008; Mon, 9 Jul 2012 09:50:30 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 9 Jul 2012 09:50:30 -0700 (PDT) Message-ID: <666d307689462a477c5f4bd47bf454ac.squirrel@www.trepanning.net> In-Reply-To: <4FF316DF.6050109@secunet.com> References: <4FF316DF.6050109@secunet.com> Date: Mon, 9 Jul 2012 09:50:30 -0700 (PDT) From: "Dan Harkins" To: "Johannes Merkle" 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 Cc: ipsec@ietf.org, "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 16:50:07 -0000 Hello, On Tue, July 3, 2012 8:59 am, Johannes Merkle wrote: > Hi, > > in RFC 5639, we have specified a new set of elliptic curve parameters for > use in cryptographic applications. Meanwhile, > support for these "Brainpool Curves" has been included in some crypto > libraries as openssl (recently) and crypto++. > However, in order to use the Brainpool Curves with IKE and IPSec, still > some specifications and IANA registry updates > are needed. We are now planning to prepare such an RFC to allow usage of > the ECC Brainpool curves with ipsec. I think that's a great idea. > In order to go forward with this effort, we would like to discuss some > questions and potential issues. The WG feedback > on these is most appreciated. > > [Question 0] Is the WG interested in shepherding an RFC specifying all > that's necessary to use the Brainpool curves in > ipsec? And what category would be preferred, standard track or > informational. I can't speak for the group but I would like to see an RFC that defines the IANA considerations for using these curves in IKE. Informational is probably fine unless the answer to question 2 below requires Standards Track. > [Question 1] Should we include IKEv1 in the specs as well? It seems that > some people in the WG do not like the idea of > updating this obsolete protocol. On the other hand, many applications > still use IKEv1 and specifying the use of the > Brainpool curves only for IKEv2 would exclude these. Absolutely yes. There are still a lot of IKEv1 implementations out there and also there are other protocols that use the IANA registry from IKEv1, namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry has to be added to the IKEv1 registry. > [Question 2] If IKEv1 is to be considered, the registry for IPSEC > Authentication Methods (Value 3) needs to be updated, > because the values for ECDSA are specific for each curve. What policy for > updating this IANA registry can be assumed? > IANA currently requires a standard track RFC, but there has recently been > some discussion on relaxing this, in > particular, > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and > http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . > For the corresponding IKEv2 registry (Auth Method), only Expert Review is > required. Hopefully that will be relaxed. > [Question 3] If IKEv1 is to be considered, it seems reasonable to write > only one RFC covering IKEv1 and IKEv2. Actually, > we also plan to prepare analogous specifications for TLS, so an option > would be to write a common RFC for IKE and TLS > analogously to RFC 5114. However, according to the update policy of the > IANA registry EC Named Curve for TLS, such an > RFC would have to be shepherded by the tls WG. Does this prevent or > considerably complicate the creation of a joint RFC > for IKE and TLS? Would preparing separate RFCs for IKE and TLS be > preferable? This seems reasonable. The body of the RFC will probably just be IANA considerations. The domain parameter sets of the curves are already defined so you just need to get IANA to allocate magic numbers for their use. > [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, > 320, 384, 512 two curves are defined, one > being the “quadratic twist” of the other – their algebraic structure > (and hence, security level) is equivalent, but one > of them allows particular efficient arithmetic. In order to leave the > choice of the curve for a given bit length to the > implementation we propose to register IANA values (for Auth method and > Diffie-Hellman Group) for both curves for each > bit length. Of course, this doubles the number of number assignments. Any > objections on this? There's approximately 65k available assignments so this shouldn't be a problem. Why would anyone want to do the untwisted version if the twisted on is more efficient? Are there any IPR considerations to the twisted version? > [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but > also ECGDSA (Elliptic Curve German Digital > Signature Algorithm) according to ISO 14888-3, which is a slight variant > of ECDSA. The advantage of ECGDSA over ECDSA is > that signature generation does not need any inversion modulo the group > order, which removes the necessity of > corresponding code. This advantage is particularly interesting when using > devices with limited computation power and > storage like smart cards or electronic control units in cars. In > particular, car manufacturers have expressed their > desire to deviate from EDSA For this reason, we would like to specify > values for ECGDSA (with the individual bit lengths > and curves) as Authentication Method as well. Would the WG support > inclusion of this additional signature algorithm? Unless this got wider acceptance my personal take is: pass. > [Question 6] In cryptographic applications using elliptic curves, point > compression (see Section 4.2 in RFC 6090) is > frequently used in particular in environments with limited bandwidth and > storage capacity. However, in IKE this > mechanism is currently not supported as, according to RFC 5903, the KE > payload consists of the concatenation of two > components, x and y, each of which having the same length as the > underlying finite field. We propose to add support for > point compression for the KE Payload to IKE by allowing also the use of a > compressed form of x, e.g. of 64 bits, > representing only the least significant bit. In contrast to the (obsolete) > draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 > does not specify a data format for the ECDH KE payload in which the > uncompressed form is explicitly specified (e.g. in a > leading byte), uncompressed and compressed form could only be implicitly > distinguished by their bit length (as specified > in the KE header). Does this raise any issue with implementations? What > are your opinions and preferences? My preference would be to leave the KE payload alone. regards, Dan. > Johannes > -- > Johannes Merkle > secunet Security Networks AG > johannes.merkle@secunet.com > www.secunet.com > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From Johannes.Merkle@secunet.com Mon Jul 9 10:12:32 2012 Return-Path: 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 780AF11E8135 for ; Mon, 9 Jul 2012 10:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 aYQko7za8HnV for ; Mon, 9 Jul 2012 10:12:31 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 35FAD21F8652 for ; Mon, 9 Jul 2012 10:12:31 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id AE4BC1A0079; Mon, 9 Jul 2012 19:12:55 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id E17791A006F; Mon, 9 Jul 2012 19:12:52 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Jul 2012 19:12:51 +0200 Message-ID: <4FFB1113.8030709@secunet.com> Date: Mon, 09 Jul 2012 19:12:51 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipsec@ietf.org References: <4FF316DF.6050109@secunet.com> <666d307689462a477c5f4bd47bf454ac.squirrel@www.trepanning.net> In-Reply-To: <666d307689462a477c5f4bd47bf454ac.squirrel@www.trepanning.net> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 09 Jul 2012 17:12:51.0945 (UTC) FILETIME=[12A05D90:01CD5DF6] Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 17:12:32 -0000 Dan, thanks for your reply. You happen to be the first one. See my comments below. >> [Question 1] Should we include IKEv1 in the specs as well? It seems that >> some people in the WG do not like the idea of >> updating this obsolete protocol. On the other hand, many applications >> still use IKEv1 and specifying the use of the >> Brainpool curves only for IKEv2 would exclude these. > > Absolutely yes. There are still a lot of IKEv1 implementations out there > and also there are other protocols that use the IANA registry from IKEv1, > namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry > has to be added to the IKEv1 registry. This is also our perception but we would prefer a WG consensus on that. > >> [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, >> 320, 384, 512 two curves are defined, one >> being the “quadratic twist” of the other – their algebraic structure >> (and hence, security level) is equivalent, but one >> of them allows particular efficient arithmetic. In order to leave the >> choice of the curve for a given bit length to the >> implementation we propose to register IANA values (for Auth method and >> Diffie-Hellman Group) for both curves for each >> bit length. Of course, this doubles the number of number assignments. Any >> objections on this? > > There's approximately 65k available assignments so this shouldn't be a > problem. Why would anyone want to do the untwisted version if the twisted on > is more efficient? Are there any IPR considerations to the twisted version? A similar question has been raised as response to my analogous posting on the tls mailing list. The reason why some people might prefer the "normal" curves is that for these it is easier to avoid patents. This is always a big issue with ECC. While the Brainpool curves avoid special primes to facilitate patent-free implementations, we still wanted to leave the implementors a choice between "fast" and "slower but more patent-safe" by introducing the quadratic twist. > >> [Question 6] In cryptographic applications using elliptic curves, point >> compression (see Section 4.2 in RFC 6090) is >> frequently used in particular in environments with limited bandwidth and >> storage capacity. However, in IKE this >> mechanism is currently not supported as, according to RFC 5903, the KE >> payload consists of the concatenation of two >> components, x and y, each of which having the same length as the >> underlying finite field. We propose to add support for >> point compression for the KE Payload to IKE by allowing also the use of a >> compressed form of x, e.g. of 64 bits, >> representing only the least significant bit. In contrast to the (obsolete) >> draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 >> does not specify a data format for the ECDH KE payload in which the >> uncompressed form is explicitly specified (e.g. in a >> leading byte), uncompressed and compressed form could only be implicitly >> distinguished by their bit length (as specified >> in the KE header). Does this raise any issue with implementations? What >> are your opinions and preferences? > > My preference would be to leave the KE payload alone. So, you mean not to allow point compression? Our proposal is *not* to change the KE payload syntax but only to allow variation in its bit length and to define rules for interpretation depending on its length. This means merely an extension of the rules defined for the NIST curves (RFC 5903), not a contradiction. BTW: TLS explicitly allows point compression. Johannes -- Johannes Merkle secunet Security Networks AG johannes.merkle@secunet.com www.secunet.com From internet-drafts@ietf.org Mon Jul 9 16:27:52 2012 Return-Path: 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 74C5311E8140; Mon, 9 Jul 2012 16:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FRpa6Cw+5CRq; Mon, 9 Jul 2012 16:27:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C10411E8141; Mon, 9 Jul 2012 16:27:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120709232752.32062.81153.idtracker@ietfa.amsl.com> Date: Mon, 09 Jul 2012 16:27:52 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-p2p-vpn-problem-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 23:27:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IP Security Maintenance and Extensions Wo= rking Group of the IETF. Title : Auto Discovery VPN Problem Statement and Requirements Author(s) : Steve Hanna Vishwas Manral Filename : draft-ietf-ipsecme-p2p-vpn-problem-02.txt Pages : 14 Date : 2012-07-09 Abstract: This document describes the problem of enabling a large number of systems to communicate directly using IPsec to protect the traffic between them. It them expands on the requirements, for such a solution. Manual configuration of all possible tunnels is too cumbersome in many such cases. In other cases the IP address of end points change or the end points may be behind NAT gateways, making static configuration impossible. The Auto Discovery VPN solution is chartered to address these requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-p2p-vpn-problem There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-p2p-vpn-problem-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-p2p-vpn-problem-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ynir@checkpoint.com Tue Jul 10 06:35:36 2012 Return-Path: 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 DBB8F21F86BD for ; Tue, 10 Jul 2012 06:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 oet2YSXtu5XL for ; Tue, 10 Jul 2012 06:35:36 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A8A9B21F86C2 for ; Tue, 10 Jul 2012 06:35:35 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6ADZhSv019040; Tue, 10 Jul 2012 16:35:43 +0300 X-CheckPoint: {4FFC2E48-1-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 10 Jul 2012 16:35:42 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 10 Jul 2012 16:35:40 +0300 From: Yoav Nir To: Sean Turner Date: Tue, 10 Jul 2012 16:35:03 +0300 Thread-Topic: [IPsec] AD review: draft-nir-ipsecme-erx-04.txt Thread-Index: Ac1eoOUthp0GTWiyS5iIpfrhwC+LZA== Message-ID: <3E67AF4C-59D8-4C5B-A609-EA4DACA3B1A6@checkpoint.com> References: <20120521055357.5840.39762.idtracker@ietfa.amsl.com> <68B8C17B-5EFC-4993-8AD0-2B7F666479FD@checkpoint.com> <4FF22C24.9090201@ieca.com> In-Reply-To: <4FF22C24.9090201@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1115a84915b94b3a03c9cb2d301bebc5bdc3abcf46 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org WG" , Qin Wu Subject: Re: [IPsec] AD review: draft-nir-ipsecme-erx-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 13:35:37 -0000 Hi Sean Thanks for the review. My answers are inline. Yoav On Jul 3, 2012, at 2:17 AM, Sean Turner wrote: > Yoav asked me to do an AD review of draft-nir-ipsecme-erx. We agreed=20 > that it'd be all right for me to send my comments here. They are as=20 > follows: >=20 > 0) Overall: A couple of folks that I mentioned this to asked: is anybody= =20 > really doing ERP? So I'm just curious if they are. This obviously=20 > non-blocking. My guess is that it is not widely deployed, because 802.1x is for now not w= idely deployed. EAP is used in some other contexts, like L2TP VPN clients a= nd cable modem/ADSL dialers, but those don't tend to need support for roami= ng. > 1) General: In case people missed it, the first EAP message for ERX is=20 > moved to the initial IKE_AUTH request. I haven't seen any objections to= =20 > this but I'd like to make sure implementers are okay with this!? >=20 > Maybe it's splitting hairs but could you do the following to maintain=20 > architectural integrity/purity (i.e., not mix them): >=20 > first request --> EAP(EAP_Initiate/Re-auth), >=20 > be this: >=20 > first request --> N[EAP(EAP_Initiate/Re-auth)], >=20 > I guess you could do the same thing for the first response. The responder has indicated support for ERX in the Initial exchange respons= e, so it is expecting to get an EAP message in the first IKE_AUTH request. = I guess architectural integrity is a matter of taste, but to me it seems th= at EAP messages should go in EAP payloads rather than Notify payloads. > 2) expand AAA on first use Last paragraph of section 2. OK, will do. > 3) s3 contains the following: >=20 > This Notify replaces the EAP-Initiate/Re-auth-Start message of ERX, > and therefore contains the domain name, as specified in section > 5.3.1.1 of [RFC5296bis]. >=20 > Is "replaces" the right word here? I think what you're saying is that=20 > the Notify serves the same purpose as the ERX EAP-Initiate/Re-auth-Start= =20 > message? >=20 > I went to 5.3.1.1 and I think what you're really pointing to is the=20 > Domain-Name in 5.3.1, which is an NAI from [RFC4282]? Maybe switch the=20 > pointer to 5.3.1. Right about the "replace". Section 5.3.1.1 talks about the authenticator op= eration (sending the EAP-Initiate/Re-auth-Start message and including the d= omain name TLV), so it seemed appropriate. On the other hand 5.3.1 contains= the format of the EAP message, which is different from that of the IKEv2 N= otify payload. How about: This Notify serves the same purpose as the EAP-Initiate/Re-auth-Start message of ERX, as specified in section 5.3.1 or [RFC5296bis]. The=20 domain name included in the payload is the same as that included in the Domain-Name TLV as specified in section 5.3.1.1 or the same=20 document. > 4) s3: In the intro to the protocol exchanges it says most of the=20 > optional bits are omitted, but that seems to only be true in the=20 > IKE_SA_INIT exchanges. Could the IKE_AUTH exchanged be trimmed down to=20 > (and depending on comment 0 the first line gets changed too): >=20 > first request --> EAP(EAP_Initiate/Re-auth), > IDi, > SA, TSi, TSr, >=20 > first response <-- IDr, AUTH, > EAP(EAP-Finish/Re-auth), >=20 > last request --> AUTH >=20 > last response <-- AUTH, > SA, TSi, TSr, >=20 > Just curious if those optional fields aren't so optional anymore. You're right. I will, however leave the CERT payload in there, so as not to= have this imply that we're not using certs anymore (we're not requiring RF= C 5998 compliance) > 5) s3: Do you think the following would help the not so plugged in=20 > reader to add the following to the figure of the exchanges: >=20 > IKE_SA_INIT > +- > | init request --> SA, KE, Ni, > | > | > | > | init response <-- SA, KE, Nr, > +- N[ERX_SUPPORTED] >=20 > IKE_AUTH Exchange with EAP > +- > | first request --> EAP(EAP_Initiate/Re-auth), > | IDi, > | SA, TSi, TSr, > | > | first response <-- IDr, AUTH, > | EAP(EAP-Finish/Re-auth), > | > | last request --> AUTH > | > | last response <-- AUTH, > | SA, TSi, TSr, > +- I guess so. I'll add headlines next version. > 6) s3/6: Don't you have to register the Identification Payload type in=20 > IKEv2 Identification Payload ID Types? I don't think so. ID_RFC822_ADDR is already registered, and that is the for= mat of the KeyName-NAI. > 7) s3.1: I think you need to be clear that the codes 5 and 6 came from=20 > RFC 5296: >=20 > r/(5 and 6)/(5 and 6) [RFC5296] >=20 > and maybe: >=20 > r/or in this document/or in [RFC5296] To clarify, an implementation supporting this specification MUST accept and transmit EAP messages with at least the codes for Initiate and Finish (5 and 6) (RFC5296bis]), in addition to the four codes enumer= ated in=20 RFC 5996. This document is intentionally silent about other EAP codes that are not enumerated in RFC 5996 or in that document. > 8) s3.2: r/EMSKName/EMSKName [RFC5295] >=20 > and add it as a normative reference >=20 > 9) s3.2: r/using the CLASS attribute in RADIUS and Diameter/using the=20 > CLASS attribute [RFC2865] in RADIUS [RFC2865] and Diameter [RFC3588] >=20 > and add RFC2865 and RFC 3588 as an informative references >=20 > 10) s3.3: r/LDAP/Lightweight Directory Access Protocol (LDAP) [RFC4511] >=20 > and add RFC4511 as an informative reference >=20 > 11) s4: I think you need an normative reference to 3629 for UTF-8 and=20 > you'll also need to say something more about the encoding. OK about the references. Not sure what I could say about this. > 12) s5: I think you did a good job explaining protecting the clients=20 > identity. Can you add some more text about exposing the servers=20 > identity first and why you don't think it's a problem? The KeyName-NAI TLV sent in the IDi payload should be meaningful enough to = the Authenticator to be able to look up the true identity of the client, so= here, as in regular IKE, the initiator goes first. It's true that for an a= ctive MitM, only the server reveals its identity, as opposed to both client= and server, but that is a good thing, no? How about: With this variant of the IKEv2 protocol, the initiator never sends its identity on the wire, while the server does. An active attacker could get the server identity from the exchange, but not the user identity. In regular IKE, both the user and gateway identities are exposed to an active attacker. > Cheers, >=20 > spt From turners@ieca.com Fri Jul 13 14:14:34 2012 Return-Path: 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 D7B5F11E80C0 for ; Fri, 13 Jul 2012 14:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.212 X-Spam-Level: X-Spam-Status: No, score=-102.212 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 27GlgWNHLqjZ for ; Fri, 13 Jul 2012 14:14:32 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.37.21]) by ietfa.amsl.com (Postfix) with ESMTP id B618011E8109 for ; Fri, 13 Jul 2012 14:14:32 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 64073B5F2B3BE; Fri, 13 Jul 2012 16:15:10 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 4CFEBB5F2B32D for ; Fri, 13 Jul 2012 16:15:10 -0500 (CDT) Received: from [96.231.119.66] (port=45236 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SpnCe-0002Ru-NG; Fri, 13 Jul 2012 16:15:09 -0500 Message-ID: <50008FDC.60304@ieca.com> Date: Fri, 13 Jul 2012 17:15:08 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Yoav Nir References: <20120521055357.5840.39762.idtracker@ietfa.amsl.com> <68B8C17B-5EFC-4993-8AD0-2B7F666479FD@checkpoint.com> <4FF22C24.9090201@ieca.com> <3E67AF4C-59D8-4C5B-A609-EA4DACA3B1A6@checkpoint.com> In-Reply-To: <3E67AF4C-59D8-4C5B-A609-EA4DACA3B1A6@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.119.66]:45236 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "ipsec@ietf.org WG" , Qin Wu Subject: Re: [IPsec] AD review: draft-nir-ipsecme-erx-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 21:14:35 -0000 Yoav, Response inline. After posting a new version, just find a non-author shepherd to do a write-up and get it me and we'll be off to the races. spt On 7/10/12 9:35 AM, Yoav Nir wrote: > Hi Sean > > Thanks for the review. My answers are inline. > > Yoav > > On Jul 3, 2012, at 2:17 AM, Sean Turner wrote: > >> Yoav asked me to do an AD review of draft-nir-ipsecme-erx. We agreed >> that it'd be all right for me to send my comments here. They are as >> follows: >> >> 0) Overall: A couple of folks that I mentioned this to asked: is anybody >> really doing ERP? So I'm just curious if they are. This obviously >> non-blocking. > > My guess is that it is not widely deployed, because 802.1x is for now not widely deployed. EAP is used in some other contexts, like L2TP VPN clients and cable modem/ADSL dialers, but those don't tend to need support for roaming. ack - thanks for the info. >> 1) General: In case people missed it, the first EAP message for ERX is >> moved to the initial IKE_AUTH request. I haven't seen any objections to >> this but I'd like to make sure implementers are okay with this!? >> >> Maybe it's splitting hairs but could you do the following to maintain >> architectural integrity/purity (i.e., not mix them): >> >> first request --> EAP(EAP_Initiate/Re-auth), >> >> be this: >> >> first request --> N[EAP(EAP_Initiate/Re-auth)], >> >> I guess you could do the same thing for the first response. > > The responder has indicated support for ERX in the Initial exchange response, so it is expecting to get an EAP message in the first IKE_AUTH request. I guess architectural integrity is a matter of taste, but to me it seems that EAP messages should go in EAP payloads rather than Notify payloads. Nobody else seems bothered by this so I'll let this go. >> 2) expand AAA on first use > > Last paragraph of section 2. OK, will do. ack >> 3) s3 contains the following: >> >> This Notify replaces the EAP-Initiate/Re-auth-Start message of ERX, >> and therefore contains the domain name, as specified in section >> 5.3.1.1 of [RFC5296bis]. >> >> Is "replaces" the right word here? I think what you're saying is that >> the Notify serves the same purpose as the ERX EAP-Initiate/Re-auth-Start >> message? >> >> I went to 5.3.1.1 and I think what you're really pointing to is the >> Domain-Name in 5.3.1, which is an NAI from [RFC4282]? Maybe switch the >> pointer to 5.3.1. > > Right about the "replace". Section 5.3.1.1 talks about the authenticator operation (sending the EAP-Initiate/Re-auth-Start message and including the domain name TLV), so it seemed appropriate. On the other hand 5.3.1 contains the format of the EAP message, which is different from that of the IKEv2 Notify payload. How about: > > This Notify serves the same purpose as the EAP-Initiate/Re-auth-Start > message of ERX, as specified in section 5.3.1 or [RFC5296bis]. The > domain name included in the payload is the same as that included in > the Domain-Name TLV as specified in section 5.3.1.1 or the same > document. that'll work >> 4) s3: In the intro to the protocol exchanges it says most of the >> optional bits are omitted, but that seems to only be true in the >> IKE_SA_INIT exchanges. Could the IKE_AUTH exchanged be trimmed down to >> (and depending on comment 0 the first line gets changed too): >> >> first request --> EAP(EAP_Initiate/Re-auth), >> IDi, >> SA, TSi, TSr, >> >> first response <-- IDr, AUTH, >> EAP(EAP-Finish/Re-auth), >> >> last request --> AUTH >> >> last response <-- AUTH, >> SA, TSi, TSr, >> >> Just curious if those optional fields aren't so optional anymore. > > You're right. I will, however leave the CERT payload in there, so as not to have this imply that we're not using certs anymore (we're not requiring RFC 5998 compliance) ack >> 5) s3: Do you think the following would help the not so plugged in >> reader to add the following to the figure of the exchanges: >> >> IKE_SA_INIT >> +- >> | init request --> SA, KE, Ni, >> | >> | >> | >> | init response <-- SA, KE, Nr, >> +- N[ERX_SUPPORTED] >> >> IKE_AUTH Exchange with EAP >> +- >> | first request --> EAP(EAP_Initiate/Re-auth), >> | IDi, >> | SA, TSi, TSr, >> | >> | first response <-- IDr, AUTH, >> | EAP(EAP-Finish/Re-auth), >> | >> | last request --> AUTH >> | >> | last response <-- AUTH, >> | SA, TSi, TSr, >> +- > > I guess so. I'll add headlines next version. ack >> 6) s3/6: Don't you have to register the Identification Payload type in >> IKEv2 Identification Payload ID Types? > > I don't think so. ID_RFC822_ADDR is already registered, and that is the format of the KeyName-NAI. ack >> 7) s3.1: I think you need to be clear that the codes 5 and 6 came from >> RFC 5296: >> >> r/(5 and 6)/(5 and 6) [RFC5296] >> >> and maybe: >> >> r/or in this document/or in [RFC5296] > > To clarify, an implementation supporting this specification MUST > accept and transmit EAP messages with at least the codes for Initiate > and Finish (5 and 6) (RFC5296bis]), in addition to the four codes enumerated in > RFC 5996. This document is intentionally silent about other EAP codes > that are not enumerated in RFC 5996 or in that document. I think would work. >> 8) s3.2: r/EMSKName/EMSKName [RFC5295] >> >> and add it as a normative reference >> >> 9) s3.2: r/using the CLASS attribute in RADIUS and Diameter/using the >> CLASS attribute [RFC2865] in RADIUS [RFC2865] and Diameter [RFC3588] >> >> and add RFC2865 and RFC 3588 as an informative references >> >> 10) s3.3: r/LDAP/Lightweight Directory Access Protocol (LDAP) [RFC4511] >> >> and add RFC4511 as an informative reference >> >> 11) s4: I think you need an normative reference to 3629 for UTF-8 and >> you'll also need to say something more about the encoding. > > OK about the references. Not sure what I could say about this. I'm still figuring out the APP area pixie dust, but I guess we can leave it to them to tell us what they think we need to say about UTF-8. >> 12) s5: I think you did a good job explaining protecting the clients >> identity. Can you add some more text about exposing the servers >> identity first and why you don't think it's a problem? > > The KeyName-NAI TLV sent in the IDi payload should be meaningful enough to the Authenticator to be able to look up the true identity of the client, so here, as in regular IKE, the initiator goes first. It's true that for an active MitM, only the server reveals its identity, as opposed to both client and server, but that is a good thing, no? > > How about: > With this variant of the IKEv2 protocol, the initiator never sends its > identity on the wire, while the server does. An active attacker could > get the server identity from the exchange, but not the user identity. > In regular IKE, both the user and gateway identities are exposed to an > active attacker. That'll work. spt From ynir@checkpoint.com Mon Jul 16 00:54:03 2012 Return-Path: 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 244C621F84BF for ; Mon, 16 Jul 2012 00:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.271 X-Spam-Level: X-Spam-Status: No, score=-10.271 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 5YH012bMo3+m for ; Mon, 16 Jul 2012 00:54:02 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD6921F84AE for ; Mon, 16 Jul 2012 00:54:01 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6G7siaf009197 for ; Mon, 16 Jul 2012 10:54:44 +0300 X-CheckPoint: {5003C710-0-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 16 Jul 2012 10:54:43 +0300 From: Yoav Nir To: "ipsec@ietf.org WG" Date: Mon, 16 Jul 2012 10:54:42 +0300 Thread-Topic: New Version Notification for draft-nir-ipsecme-ike-tcp-01.txt Thread-Index: Ac1jKEKMroNuE076RI+Qp9MtNS8kag== Message-ID: References: <20120716070717.25451.2079.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_F4DC7019D1654B20998CDA07D0841A20checkpointcom_" MIME-Version: 1.0 Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 07:54:03 -0000 --_000_F4DC7019D1654B20998CDA07D0841A20checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. I've posted version -01 of the draft, addressing some of the issues raised. Still open issues: * Should we care about IKEv1? * Should retransmissions be forbidden, or just discouraged? * Should liveness checks be sent over TCP? * Should Initial exchange be send over TCP? Hope we can have a fruitful discussion of this both on the list and in Vanc= ouver. Yoav Begin forwarded message: From: "internet-drafts@ietf.org" > Subject: New Version Notification for draft-nir-ipsecme-ike-tcp-01.txt Date: July 16, 2012 10:07:17 AM GMT+03:00 To: Yoav Nir > A new version of I-D, draft-nir-ipsecme-ike-tcp-01.txt has been successfully submitted by Yoav Nir and posted to the IETF repository. Filename: draft-nir-ipsecme-ike-tcp Revision: 01 Title: A TCP transport for the Internet Key Exchange Creation date: 2012-07-16 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-= tcp-01.txt Status: http://datatracker.ietf.org/doc/draft-nir-ipsecme-ike-tcp Htmlized: http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-nir-ipsecme-ike= -tcp-01 Abstract: This document describes using TCP for IKE messages. This facilitates the transport of large messages over paths where fragments are either dropped, or packet loss makes them unreliable. --_000_F4DC7019D1654B20998CDA07D0841A20checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi.

I'v= e posted version -01 of the draft, addressing some of the issues raised.

Still open issues:
 * Should we care = about IKEv1?
 * Should retransmissions be forbidden, or just= discouraged?
 * Should liveness checks be sent over TCP?
 * Should Initial exchange be send over TCP?

Hope we can have a fruitful discussion of this both on the list and= in Vancouver.

Yoav

Begin forward= ed message:

<= span style=3D"font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0= , 1.0);">Subject: New Version Notification for draft-nir-ipsecme-ike-tcp-0= 1.txt
Date: July 16, 2012 10:07:1= 7 AM GMT+03:00
To: Yoav Nir <ynir@checkpoint.com>


A new version of I-D, draft-nir-ipsecme-ike-tcp-01.txt
h= as been successfully submitted by Yoav Nir and posted to the
IETF reposi= tory.

Filename: draft-nir-ipsecme-ike-tcp
Revision: 01
Title: A TCP transport for the Internet Key Exc= hange
Creation date: 2012-07-16
WG ID: Individual Submission
Number of pages: 8
URL:  &n= bsp;          http:= //www.ietf.org/internet-drafts/draft-nir-ipsecme-ike-tcp-01.txt
Stat= us:          http://datatracker.iet= f.org/doc/draft-nir-ipsecme-ike-tcp
Htmlized:    &nbs= p;   http://tools.ietf.org/html/draft-nir-ipsecme-ike-tcp-01Diff:            http://tools.ietf.org/rfcdiff?url2=3Ddraft-nir-ipsecme-ike-tcp-01
<= br>Abstract:
  This document describes using TCP for IKE mess= ages.  This facilitates
  the transport of large message= s over paths where fragments are either
  dropped, or packet = loss makes them unreliable.

= --_000_F4DC7019D1654B20998CDA07D0841A20checkpointcom_-- From paul.hoffman@vpnc.org Mon Jul 16 11:35:13 2012 Return-Path: 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 9318111E808C for ; Mon, 16 Jul 2012 11:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 49m22cL5H2dl for ; Mon, 16 Jul 2012 11:35:13 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0520C11E8072 for ; Mon, 16 Jul 2012 11:35:12 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GHnvFV043404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 16 Jul 2012 10:49:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: <4FEEEC18.2030900@gmail.com> Date: Mon, 16 Jul 2012 11:35:55 -0700 Content-Transfer-Encoding: 7bit Message-Id: <185404DE-5E8B-4E5B-B2FC-9FC98A12626D@vpnc.org> References: <4FEEEC18.2030900@gmail.com> To: IPsecme WG X-Mailer: Apple Mail (2.1278) Subject: Re: [IPsec] IPsecME meeting - call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 18:35:13 -0000 Here is the proposed agenda; let us know if you think it should be different. Greetings, note well, blue sheets: 5 min draft-ietf-ipsecme-p2p-vpn-problem: 60 min draft-nir-ipsecme-ike-tcp: 15 min --Paul Hoffman From paul@nohats.ca Mon Jul 16 12:26:49 2012 Return-Path: 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 0639C21F88D0 for ; Mon, 16 Jul 2012 12:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 q5zfzDCAtIL1 for ; Mon, 16 Jul 2012 12:26:48 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7599A21F88CF for ; Mon, 16 Jul 2012 12:26:48 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 878DF84D81; Mon, 16 Jul 2012 15:18:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7A80C84D7A; Mon, 16 Jul 2012 15:18:08 -0400 (EDT) Date: Mon, 16 Jul 2012 15:18:08 -0400 (EDT) From: Paul Wouters To: Paul Hoffman , Tero Kivinen In-Reply-To: <185404DE-5E8B-4E5B-B2FC-9FC98A12626D@vpnc.org> Message-ID: References: <4FEEEC18.2030900@gmail.com> <185404DE-5E8B-4E5B-B2FC-9FC98A12626D@vpnc.org> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] IPsecME meeting - call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 19:26:49 -0000 On Mon, 16 Jul 2012, Paul Hoffman wrote: > Here is the proposed agenda; let us know if you think it should be different. > > Greetings, note well, blue sheets: 5 min > draft-ietf-ipsecme-p2p-vpn-problem: 60 min > draft-nir-ipsecme-ike-tcp: 15 min Should we add an item for: http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-00 ? Paul From paul.hoffman@vpnc.org Mon Jul 16 13:22:31 2012 Return-Path: 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 DB69121F86B1 for ; Mon, 16 Jul 2012 13:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 x+j6XEZLDbsR for ; Mon, 16 Jul 2012 13:22:31 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3999521F86C6 for ; Mon, 16 Jul 2012 13:22:31 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6GJb9PR065536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Jul 2012 12:37:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Mon, 16 Jul 2012 13:23:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <499022F7-C452-4493-9393-E1B1309836D2@vpnc.org> References: <4FEEEC18.2030900@gmail.com> <185404DE-5E8B-4E5B-B2FC-9FC98A12626D@vpnc.org> To: Paul Wouters , Tero Kivinen X-Mailer: Apple Mail (2.1278) Cc: IPsecme WG Subject: Re: [IPsec] IPsecME meeting - call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 20:22:32 -0000 On Jul 16, 2012, at 12:18 PM, Paul Wouters wrote: > On Mon, 16 Jul 2012, Paul Hoffman wrote: >=20 >> Here is the proposed agenda; let us know if you think it should be = different. >>=20 >> Greetings, note well, blue sheets: 5 min >> draft-ietf-ipsecme-p2p-vpn-problem: 60 min >> draft-nir-ipsecme-ike-tcp: 15 min >=20 > Should we add an item for: >=20 > http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-00 ? There has been no discussion of the draft since the last meeting, and = none of the authors asked for a slot, so I didn't schedule it initially. = Do either of the authors have something relevant to say in the meeting? --Paul Hoffman From kivinen@iki.fi Wed Jul 18 11:44:56 2012 Return-Path: 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 7F57C11E807F for ; Wed, 18 Jul 2012 11:44:56 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 M3mEbOC0wxjy for ; Wed, 18 Jul 2012 11:44:55 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id D0A5E21F84E4 for ; Wed, 18 Jul 2012 11:44:54 -0700 (PDT) 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 q6IIjd7H016510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 21:45:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6IIjchD025249; Wed, 18 Jul 2012 21:45:38 +0300 (EEST) 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=unknown Content-Transfer-Encoding: 7bit Message-ID: <20487.1106.571589.307917@fireball.kivinen.iki.fi> Date: Wed, 18 Jul 2012 21:45:38 +0300 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <4FF316DF.6050109@secunet.com> References: <4FF316DF.6050109@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 48 min X-Total-Time: 120 min Cc: ipsec@ietf.org, "Biester, Jobst" Subject: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 18:44:56 -0000 [I have been on vacation for a month, so thats why I am only coming back to this now]. Johannes Merkle writes: > [Question 0] Is the WG interested in shepherding an RFC specifying > all that's necessary to use the Brainpool curves in ipsec? And what > category would be preferred, standard track or informational. I think it might be good idea to get some usable elliptic curves too. The groups 19-21 is mostly unusable now as we messed up with their format in the original RFC4753 and they changes we made in RFC5903 are not backward compatible with the original RFC4753 and the interoperability problem just causes timeout on the initiator. > [Question 1] Should we include IKEv1 in the specs as well? It seems > that some people in the WG do not like the idea of updating this > obsolete protocol. On the other hand, many applications still use > IKEv1 and specifying the use of the Brainpool curves only for IKEv2 > would exclude these. I would be strongly against for including support for protocol which has been obsoleted 7 years ago. If people want to use this kind of groups in IKEv1 they can use the new group mode and negotiate groups on the fly. There is no need to add them to IKEv1. > [Question 2] If IKEv1 is to be considered, the registry for IPSEC > Authentication Methods (Value 3) needs to be updated, because the > values for ECDSA are specific for each curve. What policy for > updating this IANA registry can be assumed? IANA currently requires > a standard track RFC, but there has recently been some discussion on > relaxing this, in particular, > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and > http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . > For the corresponding IKEv2 registry (Auth Method), only Expert > Review is required. Hmm... So you are talking adding them for both Diffie-Hellman and ECDSA uses? Adding them to ECDSA is more difficult. Adding them for Diffie-Hellman use requires updating of one expert review 16-bit registry for IKEv2. The same registry in the IKEv1 is RFC required, so it does not require standard track RFC. Adding them for authentication use (ECDSA use) will most likely get more opposition. First of all, I am not at all happy how the ECDSA groups are added to the IKEv2 authentication method. The authentication methods registry is only 8-bit in IKEv2 (it is 16-bit registry in IKEv1). This does not matter if we have only few ECDSA groups with one hash algorithm for each, but when we are adding more groups it seems to bad idea for each of them having separate number. Especially if someone later decides that they want to use all ECDSA groups with SHA 3 too... I think we should have made the ECDSA support for IKEv2 in such way that we had added some subfields to the authentication field, i.e. only allocated one value for ECDSA and put the curve number inside the authentication payload and perhaps even separated the hash algorithm from it. There is 3 bytes of reserved data in the authentication payload immediately after the auth method. Perhaps we could use those. It is most likely too late now, but we still want to make sure we do not allocate too many entries from that registry, i.e. is there need to add all the groups in there, do we really need that many different strengths? Which hash algorithm do we use with what group? Also note, that authentication methods are not negotiated in IKEv2, i.e. there is no way to know whether the other end supports the authentication algorithm you wanted to use. On the other hand as you need to have credentials for the other end you are using, so most if other end would be accepting your authentication credentials it also supports the authentication method that needs to be used to use then. On the IKEv1 there is another problem. The authentication method is negotiated (in main mode), but it MUST be same for both directions, so both ends must support same types of credentials. Also as you pointed out the authentication algorithgms registry for IKEv1 is still Standard track RFC required and there has been multiple people in the WG opposing to changing it. So adding support for authentication methods do require more work for both IKEv1 and IKEv2. > [Question 3] If IKEv1 is to be considered, it seems reasonable to > write only one RFC covering IKEv1 and IKEv2. Actually, we also plan > to prepare analogous specifications for TLS, so an option would be > to write a common RFC for IKE and TLS analogously to RFC 5114. > However, according to the update policy of the IANA registry EC > Named Curve for TLS, such an RFC would have to be shepherded by the > tls WG. Does this prevent or considerably complicate the creation of > a joint RFC for IKE and TLS? Would preparing separate RFCs for IKE > and TLS be preferable? I would suggest writing separate RFCs for TLS. It might seem like good idea to write only one RFC, but that just causes confusion to the actual users of the RFC. They are either TLS or IPsec implementors, and it is confusing if you are not using the same terms which are already used in those protocols. We only write those documents once (hopefully), but they are (again hopefully) used more than once, so it is better to optimize for the reader... > [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, > 256, 320, 384, 512 two curves are defined, one being the $,1r|(Bquadratic > twist$,1r}(B of the other $,1rs(B their algebraic structure (and hence, security > level) is equivalent, but one of them allows particular efficient > arithmetic. In order to leave the choice of the curve for a given > bit length to the implementation we propose to register IANA values > (for Auth method and Diffie-Hellman Group) for both curves for each > bit length. Of course, this doubles the number of number > assignments. Any objections on this? For Diffie-Hellman groups with 16-bit registry, no. For the Authentication Algorithms registry with only 8-bit registry, yes. On the other hand if we do take those reserved fields in to use in the IKEv2 authentication payload and put the parameters there then I see no reason to limit the number of groups. > [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec > but also ECGDSA (Elliptic Curve German Digital Signature Algorithm) > according to ISO 14888-3, which is a slight variant of ECDSA. The > advantage of ECGDSA over ECDSA is that signature generation does not > need any inversion modulo the group order, which removes the > necessity of corresponding code. This advantage is particularly > interesting when using devices with limited computation power and > storage like smart cards or electronic control units in cars. In > particular, car manufacturers have expressed their desire to deviate > from EDSA For this reason, we would like to specify values for > ECGDSA (with the individual bit lengths and curves) as > Authentication Method as well. Would the WG support inclusion of > this additional signature algorithm? I think it might be good idea for IKEv2 (and bad idea for IKEv1), but at least there I think we should add it differently than what is done for the current ECDSA code, i.e not make separate number for each group (which would be 28 (i.e. >10% of the whole registry) if we add all 7 strengths with 2 formats and each with both ECDSA and ECGDSA). > [Question 6] In cryptographic applications using elliptic curves, > point compression (see Section 4.2 in RFC 6090) is frequently used > in particular in environments with limited bandwidth and storage > capacity. However, in IKE this mechanism is currently not supported > as, according to RFC 5903, the KE payload consists of the > concatenation of two components, x and y, each of which having the > same length as the underlying finite field. We propose to add > support for point compression for the KE Payload to IKE by allowing > also the use of a compressed form of x, e.g. of 64 bits, > representing only the least significant bit. In contrast to the > (obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 does not > specify a data format for the ECDH KE payload in which the > uncompressed form is explicitly specified (e.g. in a leading byte), > uncompressed and compressed form could only be implicitly > distinguished by their bit length (as specified in the KE header). > Does this raise any issue with implementations? What are your > opinions and preferences? I have been under impression that the point compression is one of those items which are patented and that is the reason why it is not been used in the IKEv2. Also as I said earlier the authentication methods are not negotiated, thus if one ends send KE payload in point compressed format and other end does not implement point compression because of licensing reasons they cannot talk to each other. So as a summary (my opinion): 1) NO for IKEv1 2) Yes, for IKEv2 Diffie-Hellman groups 3) Maybe, for the IKEv2 ECDSA Authentication methods, with stronger support if we actually allocate only one authentication method number (or two, one for ECDSA, and another for ECGDSA) and move parameters inside the reserved fields. Adding the ECDSA do require more work, and for that I would think it would be best to make this as a WG item (i.e. recharter to include it). -- kivinen@iki.fi From kivinen@iki.fi Wed Jul 18 11:50:28 2012 Return-Path: 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 DA0AB11E815C for ; Wed, 18 Jul 2012 11:50:28 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW93nC5pr96R for ; Wed, 18 Jul 2012 11:50:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id ECC2211E8150 for ; Wed, 18 Jul 2012 11:50:27 -0700 (PDT) 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 q6IIpIi3013802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 21:51:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6IIpGLY029165; Wed, 18 Jul 2012 21:51:16 +0300 (EEST) 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: <20487.1444.724711.559493@fireball.kivinen.iki.fi> Date: Wed, 18 Jul 2012 21:51:16 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <666d307689462a477c5f4bd47bf454ac.squirrel@www.trepanning.net> References: <4FF316DF.6050109@secunet.com> <666d307689462a477c5f4bd47bf454ac.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: ipsec@ietf.org, Johannes Merkle , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 18:50:29 -0000 Dan Harkins writes: > Absolutely yes. There are still a lot of IKEv1 implementations out there > and also there are other protocols that use the IANA registry from IKEv1, > namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry > has to be added to the IKEv1 registry. Why would any other protocol use IKEv1 IANA registries? Are you now talking about the authentication method registry or the diffie-hellman groups registry? It is bad idea to use registry for any other reason than where it is created, and adding stuff to IKEv1 IANA registry not for IPsec use, but for use for some other protocols seems like quite funny. My personal opinion about that is that it is IEEE 802.11-2012 problem if they use IANA registry for some other purposes than what it is intended for. -- kivinen@iki.fi From dharkins@lounge.org Wed Jul 18 11:55:42 2012 Return-Path: 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 5EFEE11E8168 for ; Wed, 18 Jul 2012 11:55:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 892Wa+VsrJIk for ; Wed, 18 Jul 2012 11:55:41 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 325B511E8132 for ; Wed, 18 Jul 2012 11:55:41 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D777F10224008; Wed, 18 Jul 2012 11:56:31 -0700 (PDT) Received: from 63.133.198.20 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 18 Jul 2012 11:56:32 -0700 (PDT) Message-ID: In-Reply-To: <20487.1444.724711.559493@fireball.kivinen.iki.fi> References: <4FF316DF.6050109@secunet.com> <666d307689462a477c5f4bd47bf454ac.squirrel@www.trepanning.net> <20487.1444.724711.559493@fireball.kivinen.iki.fi> Date: Wed, 18 Jul 2012 11:56:32 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" 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 Cc: ipsec@ietf.org, Johannes Merkle , Dan Harkins , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 18:55:42 -0000 Hello, On Wed, July 18, 2012 11:51 am, Tero Kivinen wrote: > Dan Harkins writes: >> Absolutely yes. There are still a lot of IKEv1 implementations out >> there >> and also there are other protocols that use the IANA registry from >> IKEv1, >> namely IEEE 802.11-2012. Any curve that you add to the IKEv2 registry >> has to be added to the IKEv1 registry. > > Why would any other protocol use IKEv1 IANA registries? Are you now > talking about the authentication method registry or the diffie-hellman > groups registry? The "diffie-hellman groups registry". > It is bad idea to use registry for any other reason than where it is > created, and adding stuff to IKEv1 IANA registry not for IPsec use, > but for use for some other protocols seems like quite funny. It was created to map an unsigned short to a complete domain parameter set and that is exactly how it is being used. > My personal opinion about that is that it is IEEE 802.11-2012 problem > if they use IANA registry for some other purposes than what it is > intended for. I think your opinion that this is "some other purpose" is wrong. Dan. From kivinen@iki.fi Wed Jul 18 11:55:56 2012 Return-Path: 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 7BE0511E816C for ; Wed, 18 Jul 2012 11:55:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGWjEpbqXlEt for ; Wed, 18 Jul 2012 11:55:56 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9286C11E816B for ; Wed, 18 Jul 2012 11:55:55 -0700 (PDT) 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 q6IIuj2O007601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Jul 2012 21:56:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6IIuiuO014171; Wed, 18 Jul 2012 21:56:44 +0300 (EEST) 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: <20487.1772.590105.733867@fireball.kivinen.iki.fi> Date: Wed, 18 Jul 2012 21:56:44 +0300 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <499022F7-C452-4493-9393-E1B1309836D2@vpnc.org> References: <4FEEEC18.2030900@gmail.com> <185404DE-5E8B-4E5B-B2FC-9FC98A12626D@vpnc.org> <499022F7-C452-4493-9393-E1B1309836D2@vpnc.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min Cc: IPsecme WG , Paul Wouters Subject: Re: [IPsec] IPsecME meeting - call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 18:55:56 -0000 Paul Hoffman writes: > On Jul 16, 2012, at 12:18 PM, Paul Wouters wrote: > > On Mon, 16 Jul 2012, Paul Hoffman wrote: > >> Here is the proposed agenda; let us know if you think it should be different. > >> Greetings, note well, blue sheets: 5 min > >> draft-ietf-ipsecme-p2p-vpn-problem: 60 min > >> draft-nir-ipsecme-ike-tcp: 15 min > > > > Should we add an item for: > > > > http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-00 ? > > There has been no discussion of the draft since the last meeting, > and none of the authors asked for a slot, so I didn't schedule it > initially. Do either of the authors have something relevant to say > in the meeting? We had some discussion in the last IETF, but we did got cut a bit short in the presentation with the problems with power... Anyways, I think the question is most likely what are we going to do with the old Raw RSA certificate type and that also affects whether we should be standard track or not. I think more people in the present in the WG meeting preferred to just obsolete the old format, but this is something that should be confirmed on the list. I have been bit too busy lately to be able to work on this, but I will try to get this one going forward too. -- kivinen@iki.fi From dharkins@lounge.org Wed Jul 18 12:21:14 2012 Return-Path: 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 3B17F11E8191 for ; Wed, 18 Jul 2012 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.955 X-Spam-Level: X-Spam-Status: No, score=-5.955 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 kxtmGpAf60oJ for ; Wed, 18 Jul 2012 12:21:13 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A045F11E8166 for ; Wed, 18 Jul 2012 12:21:13 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7A51310224008; Wed, 18 Jul 2012 12:22:04 -0700 (PDT) Received: from 63.133.198.20 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 18 Jul 2012 12:22:04 -0700 (PDT) Message-ID: <6e6e9b0353742bf189595bbdbe18ef2c.squirrel@www.trepanning.net> In-Reply-To: <20487.1106.571589.307917@fireball.kivinen.iki.fi> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> Date: Wed, 18 Jul 2012 12:22:04 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" 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 Cc: ipsec@ietf.org, Johannes Merkle , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:21:14 -0000 On Wed, July 18, 2012 11:45 am, Tero Kivinen wrote: [snip] >> [Question 1] Should we include IKEv1 in the specs as well? It seems >> that some people in the WG do not like the idea of updating this >> obsolete protocol. On the other hand, many applications still use >> IKEv1 and specifying the use of the Brainpool curves only for IKEv2 >> would exclude these. > > I would be strongly against for including support for protocol which > has been obsoleted 7 years ago. If people want to use this kind of > groups in IKEv1 they can use the new group mode and negotiate groups > on the fly. There is no need to add them to IKEv1. In spite of this designation IKEv1 is still widely used and I would posit that it is used more than IKEv2. IKE already has the way to handle new domain parameter sets that are publicly defined and that is through the IANA registry. Your suggestion to use New Group Mode to use brainpool ECC groups would only hamstring IKEv1 and make it harder to use. It would be a blunt club to force people into doing something that they haven't decided to do on their own (to your apparent chagrin). The IETF does not have a lot of success at forcing people to do things they do not want to do on their own and I think this sort of thing is somewhat inappropriate. Why there are two identical repositories to map unsigned shorts to complete domain parameter sets is beyond me but there are. These two repositories have been updated in concert in the past and and there is no good reason to have them diverge now. Dan. From paul.hoffman@vpnc.org Wed Jul 18 12:42:18 2012 Return-Path: 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 B109211E81A5 for ; Wed, 18 Jul 2012 12:42:18 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 RIdr65Fwgf5S for ; Wed, 18 Jul 2012 12:42:18 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E029211E81A4 for ; Wed, 18 Jul 2012 12:42:17 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6IIprGd042430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Jul 2012 11:51:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <20487.1772.590105.733867@fireball.kivinen.iki.fi> Date: Wed, 18 Jul 2012 12:43:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FEEEC18.2030900@gmail.com> <185404DE-5E8B-4E5B-B2FC-9FC98A12626D@vpnc.org> <499022F7-C452-4493-9393-E1B1309836D2@vpnc.org> <20487.1772.590105.733867@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1278) Cc: IPsecme WG , Paul Wouters Subject: Re: [IPsec] IPsecME meeting - call for agenda items X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:42:18 -0000 On Jul 18, 2012, at 11:56 AM, Tero Kivinen wrote: > Paul Hoffman writes: >> On Jul 16, 2012, at 12:18 PM, Paul Wouters wrote: >>> On Mon, 16 Jul 2012, Paul Hoffman wrote: >>>> Here is the proposed agenda; let us know if you think it should be = different. >>>> Greetings, note well, blue sheets: 5 min >>>> draft-ietf-ipsecme-p2p-vpn-problem: 60 min >>>> draft-nir-ipsecme-ike-tcp: 15 min >>>=20 >>> Should we add an item for: >>>=20 >>> http://tools.ietf.org/html/draft-kivinen-ipsecme-oob-pubkey-00 ? >>=20 >> There has been no discussion of the draft since the last meeting, >> and none of the authors asked for a slot, so I didn't schedule it >> initially. Do either of the authors have something relevant to say >> in the meeting?=20 >=20 > We had some discussion in the last IETF, but we did got cut a bit > short in the presentation with the problems with power... >=20 > Anyways, I think the question is most likely what are we going to do > with the old Raw RSA certificate type and that also affects whether we > should be standard track or not. >=20 > I think more people in the present in the WG meeting preferred to just > obsolete the old format, but this is something that should be > confirmed on the list. >=20 > I have been bit too busy lately to be able to work on this, but I will > try to get this one going forward too.=20 You did not answer the question of "Do either of the authors have = something relevant to say in the meeting?". If something has not been = discussed on the list in three or four months, I'm not sure what the = value of doing so in the meeting is. --Paul Hoffman From kivinen@iki.fi Wed Jul 18 14:12:51 2012 Return-Path: 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 4DB9111E81B1 for ; Wed, 18 Jul 2012 14:12:51 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 oczEPl5gdGkQ for ; Wed, 18 Jul 2012 14:12:49 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id EC05C11E81B0 for ; Wed, 18 Jul 2012 14:12:48 -0700 (PDT) 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 q6ILCOmE004978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 00:12:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6ILCN0G017964; Thu, 19 Jul 2012 00:12:23 +0300 (EEST) 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: <20487.9911.563311.804580@fireball.kivinen.iki.fi> Date: Thu, 19 Jul 2012 00:12:23 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <3E67AF4C-59D8-4C5B-A609-EA4DACA3B1A6@checkpoint.com> References: <20120521055357.5840.39762.idtracker@ietfa.amsl.com> <68B8C17B-5EFC-4993-8AD0-2B7F666479FD@checkpoint.com> <4FF22C24.9090201@ieca.com> <3E67AF4C-59D8-4C5B-A609-EA4DACA3B1A6@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 14 min X-Total-Time: 16 min Cc: "ipsec@ietf.org WG" , Sean Turner , Qin Wu Subject: Re: [IPsec] AD review: draft-nir-ipsecme-erx-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:12:51 -0000 Yoav Nir writes: > > 0) Overall: A couple of folks that I mentioned this to asked: is anybody > > really doing ERP? So I'm just curious if they are. This obviously > > non-blocking. > > My guess is that it is not widely deployed, because 802.1x is for > now not widely deployed. EAP is used in some other contexts, like > L2TP VPN clients and cable modem/ADSL dialers, but those don't tend > to need support for roaming. EAP-RP also got just added to the IEEE 802.11ai (fast initial link setup) specification framework document, so support for it should be coming to the 802.11 networks in the future. That might allow things like moving from the company WLAN to the VPN over 3G or similar. On the other hand you might still want to run VPN over the WLAN too... > > 1) General: In case people missed it, the first EAP message for ERX is > > moved to the initial IKE_AUTH request. I haven't seen any objections to > > this but I'd like to make sure implementers are okay with this!? > > > > Maybe it's splitting hairs but could you do the following to maintain > > architectural integrity/purity (i.e., not mix them): > > > > first request --> EAP(EAP_Initiate/Re-auth), > > > > be this: > > > > first request --> N[EAP(EAP_Initiate/Re-auth)], > > > > I guess you could do the same thing for the first response. > > The responder has indicated support for ERX in the Initial exchange > response, so it is expecting to get an EAP message in the first > IKE_AUTH request. I guess architectural integrity is a matter of > taste, but to me it seems that EAP messages should go in EAP > payloads rather than Notify payloads. I agree on that. We have EAP payload to transmit EAP payloads and we should keep that for it... I do not see any problems having EAP payload in the first IKE_AUTH request, as it is negotiated beforehand. I.e. server who did send N(ERX_SUPPORTED) do know how to process it there. > > 12) s5: I think you did a good job explaining protecting the clients > > identity. Can you add some more text about exposing the servers > > identity first and why you don't think it's a problem? > > The KeyName-NAI TLV sent in the IDi payload should be meaningful > enough to the Authenticator to be able to look up the true identity > of the client, so here, as in regular IKE, the initiator goes first. > It's true that for an active MitM, only the server reveals its > identity, as opposed to both client and server, but that is a good > thing, no? I assume you mean that the client ID that is releaved to the active MitM attacker is that ephemeral username, so it is no use for attacker? I assume that ephemeral username is still sent in the IKE EAP packet without any other encryption than normal IKEv2 packet encryption, thus it is visible to the active MitM attacker. > How about: > With this variant of the IKEv2 protocol, the initiator never sends its > identity on the wire, while the server does. An active attacker could > get the server identity from the exchange, but not the user identity. > In regular IKE, both the user and gateway identities are exposed to an > active attacker. I would replace /its identity on the wire/its real identity on the wire (only ephemeral identity is transmitted)/. -- kivinen@iki.fi From kivinen@iki.fi Wed Jul 18 14:46:45 2012 Return-Path: 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 4854C11E8132 for ; Wed, 18 Jul 2012 14:46:45 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 TWL9Ex5oG50u for ; Wed, 18 Jul 2012 14:46:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 368AF11E8197 for ; Wed, 18 Jul 2012 14:46:43 -0700 (PDT) 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 q6ILlLod009702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 00:47:21 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6ILlH2L008082; Thu, 19 Jul 2012 00:47:17 +0300 (EEST) 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: <20487.12005.11615.880731@fireball.kivinen.iki.fi> Date: Thu, 19 Jul 2012 00:47:17 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <20120716070717.25451.2079.idtracker@ietfa.amsl.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 28 min X-Total-Time: 33 min Cc: "ipsec@ietf.org WG" Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-ike-tcp-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:46:45 -0000 Yoav Nir writes: > I've posted version -01 of the draft, addressing some of the issues raised. > > Still open issues: > * Should we care about IKEv1? I do not think there is any point of making extensions to the already obsoleted prorotol. If this is one more reason for people to move from IKEv1 to IKEv2 even better... It would also make the document easier to understand when we can use only terminologiy from IKEv2 document. In the section 2.1 you describe that the TCP connection MUST be closed immediately when all responses have been received, but that will create VERY, VERY inefficient protocol, where the packet flow for IKEv2 SA creation would be: TCP SYN -> <- TCP SYN ACK TCP ACK -> TCP IKE_SA_INIT -> (As we know this is last request at this time we SHOULD half-close the session) TCP FIN -> <- TCP IKE_SA_INIT response <- TCP FIN, ACK TCP ACK -> (If we didn't half-close the TCP session before hand we MUST do it know, as we received last response, the IKE_AUTH is new separate request, and it has not yet sent so we do not have any outstanding request waiting for the response). TCP SYN -> <- TCP SYN ACK TCP ACK -> TCP IKE_AUTH -> (As we know this is last request at this time we SHOULD half-close the session) TCP FIN -> <- TCP IKE_AUTH response <- TCP FIN, ACK TCP ACK -> (and now if we start CREATE_CHILD_SA exchange we need to recreate TCP session again!) I think it would be much better to say that the TCP session can be kept open as long as either end wants and it can be reused for as many requests/responses needed. Also say that the TCP session can be closed at any time by either end, and if it is closed and either end wants to send response then it must recreate it. Note, that it might not be possible for the responder to recreate the TCP session as the initiator might be behind NAT. In section 2.2 you say: If the connection has closed before the Responder had had a chance to respond, it MUST NOT respond over UDP, but MUST instead wait for a retransmission over UDP or over another TCP connection. What does the text "but MUST instead wait for a retransmission over UDP" mean? Also why do you forbid responder of reusing the TCP connection created by the initiator in section 2.2? In section 3 you say: This way the first messages use UDP, and the Initiator can set up the TCP connection at the same time, eliminating the latency penalty of using TCP. but section 2.1 says: When the three-way handshake completes, the Initiator MUST send the request. Which I read to indicate that we cannot create TCP sessions before it is needed, meaning we must immediately send the request when the three-way handshake is completed. Now when I re-read this sentence it does not have any timelimits there, so in theory it would be ok to open the TCP session then keep it open for an hour, and then send CREATE_CHILD_SA exchange over it, and then as there is no more request to send close it after receiving the response, and then go to beginning i.e create TCP session again waiting for the next request.... I do not think this was what was meant to be said there. The 3rd paragraph in the section 3 is against the section 2.1 which says you MUST close when last response is received. You can only have multiple requests outgoing if you have window size larger than 1, which it not the common case. Also window size is 1 until the IKE_AUTH is finished, thus when IKE_SA_INIT response is received that is your last response... And some answers to your questions: > * Should retransmissions be forbidden, or just discouraged? I think it is ok to forbid retransmissions on the same channel, but I think it is mandatory to allow them on different channels, i.e. if the first TCP session gets RST while waiting for the response from the other end, then when new TCP connection is recreated it should resend the request to the other end. > * Should liveness checks be sent over TCP? Why should the be forbidden? Of course nobody should be sending periodic liveness checks and recreate TCP session every 30 seconds, but should have the mechanims described in the RFC5996 and send liveness checks only when needed... > * Should Initial exchange be send over TCP? Again why should that be exception. -- kivinen@iki.fi From kivinen@iki.fi Wed Jul 18 14:58:15 2012 Return-Path: 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 B3A0911E80A2 for ; Wed, 18 Jul 2012 14:58:15 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kl8jCR5Zj+eY for ; Wed, 18 Jul 2012 14:58:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E527311E8087 for ; Wed, 18 Jul 2012 14:58:14 -0700 (PDT) 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 q6ILx5Gh024336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 00:59:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6ILx4wb025098; Thu, 19 Jul 2012 00:59:04 +0300 (EEST) 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: <20487.12712.584240.894636@fireball.kivinen.iki.fi> Date: Thu, 19 Jul 2012 00:59:04 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <4FF316DF.6050109@secunet.com> <666d307689462a477c5f4bd47bf454ac.squirrel@www.trepanning.net> <20487.1444.724711.559493@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Cc: ipsec@ietf.org, Johannes Merkle , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 21:58:15 -0000 Dan Harkins writes: > > Why would any other protocol use IKEv1 IANA registries? Are you now > > talking about the authentication method registry or the diffie-hellman > > groups registry? > > The "diffie-hellman groups registry". > > > It is bad idea to use registry for any other reason than where it is > > created, and adding stuff to IKEv1 IANA registry not for IPsec use, > > but for use for some other protocols seems like quite funny. > > It was created to map an unsigned short to a complete domain parameter > set and that is exactly how it is being used. You forgot the "for IKEv1 use" in your reason why it was created. > > My personal opinion about that is that it is IEEE 802.11-2012 problem > > if they use IANA registry for some other purposes than what it is > > intended for. > I think your opinion that this is "some other purpose" is wrong. If they actually use IKEv1 and use that IANA registry to map group numbers to parameters for that use, then it is fine. If they are using it for some other purposes then I do not care, and I do not think we should care what they do for that, and we should not add stuff to our registry just because someone want some numbers there for some other reasons than for the IPsec use. There is no point of adding any new stuff to IKEv1 registries as it is OBSOLETED protocol. -- kivinen@iki.fi From kivinen@iki.fi Wed Jul 18 15:11:47 2012 Return-Path: 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 0895011E8087 for ; Wed, 18 Jul 2012 15:11:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nVa4gS7o75W for ; Wed, 18 Jul 2012 15:11:46 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B24C21F862B for ; Wed, 18 Jul 2012 15:11:45 -0700 (PDT) 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 q6IMCahb018749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 01:12:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6IMCa1A028523; Thu, 19 Jul 2012 01:12:36 +0300 (EEST) 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: <20487.13524.169733.687058@fireball.kivinen.iki.fi> Date: Thu, 19 Jul 2012 01:12:36 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <6e6e9b0353742bf189595bbdbe18ef2c.squirrel@www.trepanning.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <6e6e9b0353742bf189595bbdbe18ef2c.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min Cc: ipsec@ietf.org, Johannes Merkle , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 22:11:47 -0000 Dan Harkins writes: > > I would be strongly against for including support for protocol which > > has been obsoleted 7 years ago. If people want to use this kind of > > groups in IKEv1 they can use the new group mode and negotiate groups > > on the fly. There is no need to add them to IKEv1. > > In spite of this designation IKEv1 is still widely used and I would posit > that it is used more than IKEv2. It is widely used, but that does not mean we need to keep adding everything there. I do not think that is that much more widely implemented anymore. I would expect most of the implementations do support both IKEv1 and IKEv2, thus adding features to IKEv2 is enough. > IKE already has the way to handle new domain parameter sets that are > publicly defined and that is through the IANA registry. Your suggestion to > use New Group Mode to use brainpool ECC groups would only hamstring > IKEv1 and make it harder to use. I think otherwise, as using new group mode allows using them without changing any single line of code, provided the IKEv1 implementation do support ECP groups at all (and support the new group mode which is SHOULD). This is exactly why new group mode was made a SHOULD in the IKEv1, i.e. to allow adding new groups without need to changing the specification or the actual code. I agree that there might be implementations which do not support it, and for example I think we disabled it from our implementation when we added IKEv2 support, as we wanted to keep the feature set provided by our implemenation about the same regardless whether IKEv1 or IKEv2 is used, and IKEv2 do not support such feature. > It would be a blunt club to force people into doing something that > they haven't decided to do on their own (to your apparent chagrin). I agree on that. I do try to convince to switch to IKEv2, as it is MUCH better protocol and works much more robustly and has standarized features for things which IKEv1 only has multiple non-standardized non-interoperable protocols. > The IETF does not have a lot of success at forcing people to do things > they do not want to do on their own and I think this sort of thing is > somewhat inappropriate. We do not need to keep adding features to the old obsoleted protocoles either. > Why there are two identical repositories to map unsigned shorts to > complete domain parameter sets is beyond me but there are. These > two repositories have been updated in concert in the past and and there > is no good reason to have them diverge now. There is multiple repositories for diffie-hellman parameters. IKEv1, IKEv2, EAP-EKE, and in addtion SSH, TLS etc have their repositories etc. Registries are cheap, there is no point of reusing them for completely different purposes. -- kivinen@iki.fi From dharkins@lounge.org Wed Jul 18 16:06:06 2012 Return-Path: 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 07B1711E8124 for ; Wed, 18 Jul 2012 16:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 lqA638BHmdbr for ; Wed, 18 Jul 2012 16:06:05 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 3726511E80CB for ; Wed, 18 Jul 2012 16:06:05 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3E39D10224008; Wed, 18 Jul 2012 16:06:56 -0700 (PDT) Received: from 63.133.198.20 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 18 Jul 2012 16:06:56 -0700 (PDT) Message-ID: <7aaaf28d697c766d68119374252eab7a.squirrel@www.trepanning.net> In-Reply-To: <20487.13524.169733.687058@fireball.kivinen.iki.fi> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <6e6e9b0353742bf189595bbdbe18ef2c.squirrel@www.trepanning.net> <20487.13524.169733.687058@fireball.kivinen.iki.fi> Date: Wed, 18 Jul 2012 16:06:56 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" 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 Cc: ipsec@ietf.org, Johannes Merkle , Dan Harkins , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 23:06:06 -0000 On Wed, July 18, 2012 3:12 pm, Tero Kivinen wrote: > Dan Harkins writes: >> > I would be strongly against for including support for protocol which >> > has been obsoleted 7 years ago. If people want to use this kind of >> > groups in IKEv1 they can use the new group mode and negotiate groups >> > on the fly. There is no need to add them to IKEv1. >> >> In spite of this designation IKEv1 is still widely used and I would >> posit >> that it is used more than IKEv2. > > It is widely used, but that does not mean we need to keep adding > everything there. I do not think that is that much more widely > implemented anymore. I would expect most of the implementations do > support both IKEv1 and IKEv2, thus adding features to IKEv2 is enough. Nobody said anything about "adding everything". That is a complete straw man argument. In fact, it is decidedly not the case that "everything" is being added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so quick to leap to unfounded conclusions you would see this IANA update as the innocuous event that it really is. This is allowing existing implementations to have more flexibility in the ECDH operations they perform to comply with various requirements that may exist in different locales or in different circumstances or situations. >> IKE already has the way to handle new domain parameter sets that are >> publicly defined and that is through the IANA registry. Your suggestion >> to >> use New Group Mode to use brainpool ECC groups would only hamstring >> IKEv1 and make it harder to use. > > I think otherwise, as using new group mode allows using them without > changing any single line of code, provided the IKEv1 implementation do > support ECP groups at all (and support the new group mode which is > SHOULD). There is a capability in New Group Mode to accept or reject the proposal and this is to allow the recipient to verify that the group is acceptable. Enabling this in IKEv1 for the brainpool curves would be substantially more code than just using the existing code point interface that all implementation have. > This is exactly why new group mode was made a SHOULD in the IKEv1, > i.e. to allow adding new groups without need to changing the > specification or the actual code. Your recollection differs from the person who actually wrote the RFC. And when that happens one should typically defer to the author. In fact, your statement seems to differ from the RFC which says it SHOULD be supported as a mechanism to define "private groups". The brainpool groups are not private and there is no reason to treat them as such. Since groups added with New Group mode MUST be assigned private code points it would result in a case of code bi-furcation because the same domain parameter sets would be accessed using different code points. That's unnecessary code complication for implementations that support both IKEv1 and IKEv2. > I agree that there might be implementations which do not support it, > and for example I think we disabled it from our implementation when we > added IKEv2 support, as we wanted to keep the feature set provided by > our implemenation about the same regardless whether IKEv1 or IKEv2 is > used, and IKEv2 do not support such feature. > >> It would be a blunt club to force people into doing something that >> they haven't decided to do on their own (to your apparent chagrin). > > I agree on that. I do try to convince to switch to IKEv2, as it is > MUCH better protocol and works much more robustly and has standarized > features for things which IKEv1 only has multiple non-standardized > non-interoperable protocols. And bully for you! I wish you much success in your advocacy. Actively trying to make people's programmatic lives worse because your advocacy isn't as successful as you'd like is a completely different matter though and is, I think, inappropriate. The fact that you admit you want a blunt club to force compliance with your wishes speaks volumes. >> The IETF does not have a lot of success at forcing people to do things >> they do not want to do on their own and I think this sort of thing is >> somewhat inappropriate. > > We do not need to keep adding features to the old obsoleted protocoles > either. This is NOT a feature. ECDH already exists in IKEv1. This is allowing existing implementations, of which they are legion, to use certain domain parameter sets that may be required or desired in certain situations and in certain locales. >> Why there are two identical repositories to map unsigned shorts to >> complete domain parameter sets is beyond me but there are. These >> two repositories have been updated in concert in the past and and there >> is no good reason to have them diverge now. > > There is multiple repositories for diffie-hellman parameters. IKEv1, > IKEv2, EAP-EKE, and in addtion SSH, TLS etc have their repositories > etc. Registries are cheap, there is no point of reusing them for > completely different purposes. There is no reason for different repositories for IKEv1 and IKEv2. They are identical with the exception that the EC2N groups were removed in the IKEv2 repository. Interestingly, the number space that is EC2N in IKEv1 is "reserved" in IKEv2 and this is done, apparently, to have symmetry in group definitions. This way implementations can share the same mapping from code point to domain parameter set. The IKEv1 repository for Diffie-Hellman groups has been updated in the past after its designation as "deprecated". We should follow precedent and continue to keep these repositories in harmony. Dan. From kivinen@iki.fi Wed Jul 18 17:13:18 2012 Return-Path: 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 B2FBA21F85EF for ; Wed, 18 Jul 2012 17:13:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xFvcPHjJ4lG for ; Wed, 18 Jul 2012 17:13:17 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id DA55621F85EA for ; Wed, 18 Jul 2012 17:13:15 -0700 (PDT) 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 q6J0E1sw021747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 03:14:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6J0E11F025385; Thu, 19 Jul 2012 03:14:01 +0300 (EEST) 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: <20487.20809.148900.638021@fireball.kivinen.iki.fi> Date: Thu, 19 Jul 2012 03:14:01 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <7aaaf28d697c766d68119374252eab7a.squirrel@www.trepanning.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <6e6e9b0353742bf189595bbdbe18ef2c.squirrel@www.trepanning.net> <20487.13524.169733.687058@fireball.kivinen.iki.fi> <7aaaf28d697c766d68119374252eab7a.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 51 min X-Total-Time: 55 min Cc: ipsec@ietf.org, Johannes Merkle , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 00:13:18 -0000 Dan Harkins writes: > Nobody said anything about "adding everything". That is a complete straw > man argument. In fact, it is decidedly not the case that "everything" is > being > added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so quick > to leap to unfounded conclusions you would see this IANA update as the > innocuous event that it really is. Not if you count the authentication methods in to it too. That do require quite a bit of work to make sure everything is done correctly. Especially as IKEv1 exchanges are quite different depending which authentication method is used. Adding only the Diffie-Hellman groups is much easier, but I understood that the idea was to add both. And for SPSK there was also text for adding that to IKEv1 too, before it was removed. Same is now with the ike-over-tcp, which again has IKEv1 text in it. > This is allowing existing implementations to have more flexibility in the > ECDH operations they perform to comply with various requirements that > may exist in different locales or in different circumstances or situations. I would think the ECP groups we already have in the IKEv1 should be enough for the most common case, i.e. the suite-b uses. Also I still do not think that many implementations are going to update their IKEv1 implementations. > > I think otherwise, as using new group mode allows using them without > > changing any single line of code, provided the IKEv1 implementation do > > support ECP groups at all (and support the new group mode which is > > SHOULD). > > There is a capability in New Group Mode to accept or reject the proposal > and this is to allow the recipient to verify that the group is acceptable. > Enabling this in IKEv1 for the brainpool curves would be substantially more > code than just using the existing code point interface that all > implementation > have. If I remember those old times when our code actually could use new group mode, I think there was two ways to use it, either accept any group other end proposed (without any verification, very useful for testing etc), or to allow the same groups defined in the configuration file. Of course if you were using the group for IKEv1 SA you can also include all the parameters in the SA propsals from RFC2409: Groups may be directly negotiated in the SA proposal with Main Mode. To do this the component parts-- for a MODP group, the type, prime and generator; for a EC2N group the type, the Irreducible Polynomial, Group Generator One, Group Generator Two, Group Curve A, Group Curve B and Group Order-- are passed as SA attributes (see Appendix A). Alternately, the nature of the group can be hidden using New Group Mode and only the group identifier is passed in the clear during phase 1 negotiation. So what is wrong with using the already existing mechanisms of using groups directly in the SA for that already obsoleted protocol? It seems the only reason to add numbers for them is to support non IPsec use... > > This is exactly why new group mode was made a SHOULD in the IKEv1, > > i.e. to allow adding new groups without need to changing the > > specification or the actual code. > > Your recollection differs from the person who actually wrote the RFC. > And when that happens one should typically defer to the author. In fact, > your statement seems to differ from the RFC which says it SHOULD be > supported as a mechanism to define "private groups". The brainpool > groups are not private and there is no reason to treat them as such. Brainpool groups do not have number in the IANA registry, which makes them private for IKEv1 use. There is nothing there claiming that you can only use new group mode to negotiate groups that are not know for anybody else. > Since groups added with New Group mode MUST be assigned private > code points it would result in a case of code bi-furcation because > the same domain parameter sets would be accessed using different > code points. That's unnecessary code complication for implementations > that support both IKEv1 and IKEv2. Or you can simply give all the parameters in the SA payload, and not give it number at all. Then it does not matter what the number is. The whole idea of that feature was to allow adding Diffie-Hellman groups to existing implementations by just changing the configuration without modifying the actual code. Implementations supporting IKEv1 and IKEv2 already needs to keep track of separate number spaces, as IANA registries for the IKEv1 and IKEv2 are separate. Also IKEv2 does not support this feature at all, so there is no over the wire negotiated private groups there. > > I agree on that. I do try to convince to switch to IKEv2, as it is > > MUCH better protocol and works much more robustly and has standarized > > features for things which IKEv1 only has multiple non-standardized > > non-interoperable protocols. > > And bully for you! I wish you much success in your advocacy. Actively > trying to make people's programmatic lives worse because your advocacy > isn't as successful as you'd like is a completely different matter though and > is, I think, inappropriate. > > The fact that you admit you want a blunt club to force compliance > with your wishes speaks volumes. And it seems you want to get the Diffie-Hellman numbers there only for the IEEE-802.11 uses as there is no reason to add them to IKEv1 registries as there is already standardized methods to use them in IKEv1 without code line changes. I have never tried to hide the fact that I think IKEv2 is much better protocol than IKEv1. IKEv1 do have some security problems (not big enough to cause it to fail completely, but they are there). IKEv1 does not have standardized support for many things that are there for IKEv2. Many IKEv1 implementations uses methods described in the expired Internet-drafts for some things, and there are multiple of those methods different implementations use. I think IKEv1 needs to DIE. It is so broken I see no reason for it to kept alive anymore. I do not want anybody to add anything to it for two reasons: 1) I am the implementor who might need to implement them in our code. Up to this point I have been able to say we do not want to do any changes to IKEv1 code. 2) It might make people feel like IKEv1 could still be used. This is my opinion and I do stick to it, and I do continue trying to convince others to it too. I see no problem there. Are you saying that I am not allowed to try to do what I belive is right? > > We do not need to keep adding features to the old obsoleted protocoles > > either. > > This is NOT a feature. ECDH already exists in IKEv1. This is allowing > existing implementations, of which they are legion, to use certain > domain parameter sets that may be required or desired in certain situations > and in certain locales. Anything that changes the code in implementations needs to be categorized in two ways, i.e. either they are: 1) Bugs 2) Enhancements / new features I do not consider this to be bug, so it is new feature / enhancement to the IKEv1. Especially as there is already a way (actually 2 ways) to do the same thing in the standard IKEv1 protocol. > There is no reason for different repositories for IKEv1 and IKEv2. They > are identical with the exception that the EC2N groups were removed in > the IKEv2 repository. Interestingly, the number space that is EC2N in > IKEv1 is "reserved" in IKEv2 and this is done, apparently, to have symmetry > in group definitions. This way implementations can share the same > mapping from code point to domain parameter set. Check the other IANA registries for IKEv1 and IKEv2 too, and you will find more changes. The reasons why the IKEv1 and IKEv2 registries are mostly same is because the IKEv1 registry was copied to work as base for IKEv2, and at that time we removed those groups which were not defined by any RFCs (i.e. the groups 6-13 which were only defined in already expired Internet-Draft). Those 2 RFCs published after that both made same allocations in the both IKEv1 and IKEv2 registries, so thats why it still stayed in sync. There is no reason them to be in sync. > The IKEv1 repository for Diffie-Hellman groups has been updated in > the past after its designation as "deprecated". We should follow precedent > and continue to keep these repositories in harmony. Yes, RFC4753 (which was replaced by 5903) was published in 2007 and draft already existed before IKEv2 RFC was published, so it was logical for it to add groups to both IKEv1 and IKEv2. RFC5114 started around 2007 only 2 years after IKEv2 was out, and at that point it might have been still useful to update IKEv1 protocol. Now IKEv1 has been obsoleted now for 7 years, and I think situation is bit different for now work starting now. We might keep or might not keep those registeries in sync. For example the authentication algorithm registry is completely different after the initial allocation. The encryption algorithms registry is same (even when IKEv1 cannot even use some of those algorithms described there). On the other hand ISAKMP has completely different encryption algorithm registry... There is no point to make changes that on purpose make them out of sync, but also there is no need to allocate every single item from both registries, and we should still allocate first free number to new allocations. But I think we are quite far now from where this dicussion started, and I am not sure if it is useful to continue this discussion as we simply disagree whether IKEv1 should die or not. -- kivinen@iki.fi From dharkins@lounge.org Wed Jul 18 17:52:18 2012 Return-Path: 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 0E97811E80F1 for ; Wed, 18 Jul 2012 17:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.079 X-Spam-Level: X-Spam-Status: No, score=-6.079 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 bxdC7Nmbqxbs for ; Wed, 18 Jul 2012 17:52:17 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 072E111E80E3 for ; Wed, 18 Jul 2012 17:52:17 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 99E6810224008; Wed, 18 Jul 2012 17:53:08 -0700 (PDT) Received: from 63.133.198.20 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 18 Jul 2012 17:53:08 -0700 (PDT) Message-ID: <4b62e88e53cb04aea392ea3d66068766.squirrel@www.trepanning.net> In-Reply-To: <20487.20809.148900.638021@fireball.kivinen.iki.fi> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <6e6e9b0353742bf189595bbdbe18ef2c.squirrel@www.trepanning.net> <20487.13524.169733.687058@fireball.kivinen.iki.fi> <7aaaf28d697c766d68119374252eab7a.squirrel@www.trepanning.net> <20487.20809.148900.638021@fireball.kivinen.iki.fi> Date: Wed, 18 Jul 2012 17:53:08 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" 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 Cc: ipsec@ietf.org, Johannes Merkle , Dan Harkins , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 00:52:18 -0000 On Wed, July 18, 2012 5:14 pm, Tero Kivinen wrote: > Dan Harkins writes: >> Nobody said anything about "adding everything". That is a complete >> straw >> man argument. In fact, it is decidedly not the case that "everything" is >> being >> added to IKEv1 and SPSK is proof of that. Perhaps if you weren't so >> quick >> to leap to unfounded conclusions you would see this IANA update as the >> innocuous event that it really is. > > Not if you count the authentication methods in to it too. That do > require quite a bit of work to make sure everything is done correctly. > > Especially as IKEv1 exchanges are quite different depending which > authentication method is used. Adding only the Diffie-Hellman groups > is much easier, but I understood that the idea was to add both. > > And for SPSK there was also text for adding that to IKEv1 too, before > it was removed. Same is now with the ike-over-tcp, which again has > IKEv1 text in it. EXACTLY!!! That is what I was saying. "everything" is not being added to IKEv1 and we have documented evidence, you even provided another example. So your statement that this innocuous addition of code points to a registry is somehow "adding everything" is just hyperbole. >> This is allowing existing implementations to have more flexibility in >> the >> ECDH operations they perform to comply with various requirements that >> may exist in different locales or in different circumstances or >> situations. > > I would think the ECP groups we already have in the IKEv1 should be > enough for the most common case, i.e. the suite-b uses. Also I still > do not think that many implementations are going to update their IKEv1 > implementations. The brainpool curves have been defined for a purpose that, apparently, the NIST-defined curves does not satisfy. And your statement about "many implementations" is belied by your behavior. Why would someone be such a vocal advocate of a law that is not necessary? [snip] > So what is wrong with using the already existing mechanisms of using > groups directly in the SA for that already obsoleted protocol? It > seems the only reason to add numbers for them is to support non IPsec > use... They are for the situations in which the brainpool curves are necessary. That is not "to support non-IPsec use". That is not why the brainpool curves were defined. >> > This is exactly why new group mode was made a SHOULD in the IKEv1, >> > i.e. to allow adding new groups without need to changing the >> > specification or the actual code. >> >> Your recollection differs from the person who actually wrote the RFC. >> And when that happens one should typically defer to the author. In fact, >> your statement seems to differ from the RFC which says it SHOULD be >> supported as a mechanism to define "private groups". The brainpool >> groups are not private and there is no reason to treat them as such. > > Brainpool groups do not have number in the IANA registry, which makes > them private for IKEv1 use. There is nothing there claiming that you > can only use new group mode to negotiate groups that are not know for > anybody else. "Brainpool groups do not have a number in the IANA registry". What do you think the topic of this thread is? Look at the subject above. You are arguing against doing something because it hasn't been done yet and that is illogical. You know what? IKEv2 doesn't have any brainpool groups defined in its IANA registry. Are you against such a code point allocation? If not, then can I please ask you to be consistent in your positions? [snip] > I have never tried to hide the fact that I think IKEv2 is much better > protocol than IKEv1. IKEv1 do have some security problems (not big > enough to cause it to fail completely, but they are there). IKEv1 does > not have standardized support for many things that are there for > IKEv2. Many IKEv1 implementations uses methods described in the > expired Internet-drafts for some things, and there are multiple of > those methods different implementations use. > > I think IKEv1 needs to DIE. It is so broken I see no reason for it to > kept alive anymore. I do not want anybody to add anything to it for > two reasons: > > 1) I am the implementor who might need to implement them in our code. > Up to this point I have been able to say we do not want to do any > changes to IKEv1 code. > 2) It might make people feel like IKEv1 could still be used. > > This is my opinion and I do stick to it, and I do continue trying to > convince others to it too. I see no problem there. > > Are you saying that I am not allowed to try to do what I belive is > right? No, if you read what I said I wished you luck in your advocacy that people should stop using IKEv1. I'm not trying to stifle you, I'm saying that it is inappropriate to make life a programmatic hell for other people just because you, personally, want IKEv1 to die. >> > We do not need to keep adding features to the old obsoleted protocoles >> > either. >> >> This is NOT a feature. ECDH already exists in IKEv1. This is allowing >> existing implementations, of which they are legion, to use certain >> domain parameter sets that may be required or desired in certain >> situations >> and in certain locales. > > Anything that changes the code in implementations needs to be > categorized in two ways, i.e. either they are: > > 1) Bugs > 2) Enhancements / new features > > I do not consider this to be bug, so it is new feature / enhancement > to the IKEv1. If an implementation is well-written it would not require ANY changes to the implementation. It would require a domain parameter set definition (probably in a .h file) and an associated magic number. Recompile. Voila. > Especially as there is already a way (actually 2 ways) to do the same > thing in the standard IKEv1 protocol. Both of which are programmatically problematic and have security issues (checking the brainpool curves if added to the SA payload or in New Group Mode would, most likely, require changes to code. Furthermore, not all implementations support domain parameter sets being passed in SA payloads (do any?) or New Group Mode so what you are advocating for causes more of the problems you are trying to use to justify your advocacy. [snip] > But I think we are quite far now from where this dicussion started, > and I am not sure if it is useful to continue this discussion as we > simply disagree whether IKEv1 should die or not. Regrettably, yes we are quite far from where this started. Straw men and circular arguments tend to do that. IKEv1 can die, I just don't see a reason to suffocate it. People use it every day (I'm using it right now!). Different people have different requirements (hence the definition of brainpool curves). You want to force people to do something they don't currently want to do by making artificial impediments to code. It really is not appropriate to use standards bodies in this manner. Dan. From ynir@checkpoint.com Wed Jul 18 23:41:44 2012 Return-Path: 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 2C42121F850D for ; Wed, 18 Jul 2012 23:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.867 X-Spam-Level: X-Spam-Status: No, score=-9.867 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_BACKHAIR_44=1, RCVD_IN_DNSWL_HI=-8] 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 K0SpSmubL7VS for ; Wed, 18 Jul 2012 23:41:43 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFAB21F84F5 for ; Wed, 18 Jul 2012 23:41:42 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6J6gWSY016167; Thu, 19 Jul 2012 09:42:32 +0300 X-CheckPoint: {5007AA7C-2-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 19 Jul 2012 09:42:31 +0300 From: Yoav Nir To: Tero Kivinen Date: Thu, 19 Jul 2012 09:42:31 +0300 Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: Ac1leavvhuMh2P7OR32euGw0goXCsg== Message-ID: <93213A99-17A9-44C6-97A4-F910AE789872@checkpoint.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> In-Reply-To: <20487.1106.571589.307917@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Johannes Merkle , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 06:41:44 -0000 On Jul 18, 2012, at 9:45 PM, Tero Kivinen wrote: > Adding them to ECDSA is more difficult. Adding them for Diffie-Hellman > use requires updating of one expert review 16-bit registry for IKEv2. > The same registry in the IKEv1 is RFC required, so it does not require > standard track RFC. >=20 > Adding them for authentication use (ECDSA use) will most likely get > more opposition. First of all, I am not at all happy how the ECDSA > groups are added to the IKEv2 authentication method. The > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit > registry in IKEv1). This does not matter if we have only few ECDSA > groups with one hash algorithm for each, but when we are adding more > groups it seems to bad idea for each of them having separate number. > Especially if someone later decides that they want to use all ECDSA > groups with SHA 3 too... >=20 > I think we should have made the ECDSA support for IKEv2 in such way > that we had added some subfields to the authentication field, i.e. > only allocated one value for ECDSA and put the curve number inside the > authentication payload and perhaps even separated the hash algorithm > from it. There is 3 bytes of reserved data in the authentication > payload immediately after the auth method. Perhaps we could use those.=20 How about standardizing just one more authentication method? Call it "public key signature" or some such, and make the signing algorithm= depend on the public key in the CERT payload. If it's RSA, go by bit strength: - <=3D1024 - SHA-1 with RSA - 10244096 - SHA2-512 with RSA DSA - always SHA-1 ECDSA will be defined by curve. The three NIST curves that everyone uses al= ready have hashes associated with them. Any new curve would have to specify= the signature algorithm in the same document. Since the same certificate can be used with both the old authentication met= hod and the new, we'd have to signal support in a Notify, and that Notify c= ould have bits for indicating support for other signature algorithms such a= s those that go with SHA3. Wouldn't this make adding future curves and other signature variants easier= ? Yoav From liushucheng@huawei.com Thu Jul 19 00:24:37 2012 Return-Path: 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 D7B3721F86A4 for ; Thu, 19 Jul 2012 00:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, 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 uUlKlYKk6dG1 for ; Thu, 19 Jul 2012 00:24:36 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A99C721F86A2 for ; Thu, 19 Jul 2012 00:24:36 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHW74877; Thu, 19 Jul 2012 03:25:25 -0400 (EDT) Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 00:23:09 -0700 Received: from SZXEML432-HUB.china.huawei.com (10.72.61.60) by dfweml408-hub.china.huawei.com (10.193.5.134) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 00:23:14 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by SZXEML432-HUB.china.huawei.com ([10.72.61.60]) with mapi id 14.01.0323.003; Thu, 19 Jul 2012 15:23:05 +0800 From: "Will Liu (Shucheng)" To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-01.txt Thread-Index: AQHNY0vwkHVqzO47SkSBFWf+W04YTJcwNb1g Date: Thu, 19 Jul 2012 07:23:04 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [IPsec] FW: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 07:24:38 -0000 SGksDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGVudGl0 bGVkICIgTXVsdGlwbGUgUGF0aCBJUCBTZWN1cml0eSAiLiBUaGlzIGRyYWZ0IGlzIHByb3Bvc2Vk IHRvIHByZXNlbnQgYW4gYXBwcm9hY2ggdG8gZW5oYW5jZSBkYXRhIHByb3RlY3Rpb24gd2hlbiB0 cmFuc21pdHRpbmcgSVBzZWMgZGF0YWdyYW1zIGFjcm9zcyB0aGUgaW5zZWN1cmUgbmV0d29ya3Mu IFRoZSBtZXRob2QgYWZmb3JkcyB0aGUgc3Ryb25nZXIgcHJvdGVjdGlvbiB0byB0aGUgdHJhZmZp YyBieSBzcGxpdHRpbmcgaXQgYW1vbmcgYSBzZXQgb2Ygc3ViLXR1bm5lbHMuICANCg0KVGhlIGxh dGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LXpoYW5nLWlwc2VjbWUtbXVsdGktcGF0aC1pcHNlYy0wMS50eHQNCg0K QW55IGNvbW1lbnRzIHdpbGwgYmUgYXBwcmVjaWF0ZWQuDQoNClJlZ2FyZHMsDQpXaWxsDQoNCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwg SnVseSAxNiwgMjAxMiA4OjA5IFBNDQo+IFRvOiBXaWxsIExpdSAoU2h1Y2hlbmcpDQo+IENjOiBU aW5hIFRTT1U7IHZ6aGFuZzIwMDhAeWFob28uY29tDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtemhhbmctaXBzZWNtZS1tdWx0aS1wYXRoLWlwc2VjLTAx LnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGFuZy1pcHNlY21l LW11bHRpLXBhdGgtaXBzZWMtMDEudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgV2lsbCBMaXUgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiAN Cj4gRmlsZW5hbWU6CSBkcmFmdC16aGFuZy1pcHNlY21lLW11bHRpLXBhdGgtaXBzZWMNCj4gUmV2 aXNpb246CSAwMQ0KPiBUaXRsZToJCSBNdWx0aXBsZSBQYXRoIElQIFNlY3VyaXR5DQo+IENyZWF0 aW9uIGRhdGU6CSAyMDEyLTA3LTEzDQo+IFdHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K PiBOdW1iZXIgb2YgcGFnZXM6IDcNCj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC16aGFuZy1pcHNlY21lLW11bHRpLXBhdGgtaXBzZWMtMDEuDQo+IHR4 dA0KPiBTdGF0dXM6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhh bmctaXBzZWNtZS1tdWx0aS1wYXRoLWlwc2VjDQo+IEh0bWxpemVkOg0KPiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1pcHNlY21lLW11bHRpLXBhdGgtaXBzZWMtMDENCj4g RGlmZjoNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC16aGFuZy1p cHNlY21lLW11bHRpLXBhdGgtaXBzZWMtMDENCj4gDQo+IEFic3RyYWN0Og0KPiAgICBUaGlzIGRv Y3VtZW50IHByZXNlbnRzIG9uZSBhcHByb2FjaCB0byBlbmhhbmNlIGRhdGEgcHJvdGVjdGlvbiB3 aGVuDQo+ICAgIHRyYW5zbWl0dGluZyBJUHNlYyBkYXRhZ3JhbXMgYWNyb3NzIHRoZSBpbnNlY3Vy ZSBuZXR3b3Jrcy4gVGhlIG1ldGhvZA0KPiAgICBhZmZvcmRzIHRoZSBzdHJvbmdlciBwcm90ZWN0 aW9uIHRvIHRoZSB0cmFmZmljIGJ5IHNwbGl0dGluZyBpdCBhbW9uZw0KPiAgICBhIHNldCBvZiBz dWItdHVubmVscy4gIEFsbCB0aGUgU2VjdXJpdHkgQXNzb2NpYXRpb25zIChTQXMpIGFyZSBzZXQg dXANCj4gICAgaW5kZXBlbmRlbnRseSBmb3IgYWxsIHN1Yi10dW5uZWxzLiAgQm90aCB0aGUgc2Vu ZGluZyBhbmQgcmVjZWl2aW5nDQo+ICAgIGVudGl0eSBjb21iaW5lIGFsbCB0aGUgc3ViLXR1bm5l bHMgdG8gb25lIGNsdXN0ZXJlZCB0dW5uZWwuICBBcw0KPiAgICBkaWZmZXJlbnQgc3ViLXR1bm5l bCB1c2VzIGRpZmZlcmVudCBjcnlwdG8ga2V5IG1hdGVyaWFscyBhbmQNCj4gICAgcHJvY2Vzc2lu ZyBwYXJhbWV0ZXJzLCBpdCBtYXkgYWNoaWV2ZSB0aGUgc3Ryb25nZXIgcHJvdGVjdGlvbiBvZiB0 aGUNCj4gICAgdHJhZmZpYyBhY3Jvc3MgdGhlIGluc2VjdXJlIG5ldHdvcmtzLiAgSW4gYWRkaXRp b24sIGl0IGNvdWxkIHBvc3NpYmx5DQo+ICAgIGJyaW5nIG1vcmUgYmVuZWZpdHMgaW4gdGVybXMg b2YgdGhlIG5ldHdvcmsgY29udHJvbC4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFRo ZSBJRVRGIFNlY3JldGFyaWF0DQo= From Johannes.Merkle@secunet.com Thu Jul 19 03:42:32 2012 Return-Path: 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 2FC7F21F8541 for ; Thu, 19 Jul 2012 03:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 3YUAVXOQOtXy for ; Thu, 19 Jul 2012 03:42:31 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id DAC7921F8534 for ; Thu, 19 Jul 2012 03:42:30 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id F11DB1A007A; Thu, 19 Jul 2012 12:42:42 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id B0F491A006C; Thu, 19 Jul 2012 12:42:41 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Jul 2012 12:43:16 +0200 Message-ID: <5007E4C3.4080803@secunet.com> Date: Thu, 19 Jul 2012 12:43:15 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Yoav Nir References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <93213A99-17A9-44C6-97A4-F910AE789872@checkpoint.com> In-Reply-To: <93213A99-17A9-44C6-97A4-F910AE789872@checkpoint.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Jul 2012 10:43:18.0947 (UTC) FILETIME=[4F5D6730:01CD659B] Cc: "ipsec@ietf.org" , "Biester, Jobst" , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 10:42:32 -0000 > > How about standardizing just one more authentication method? > > Call it "public key signature" or some such, and make the signing algorithm depend on the public key in the CERT payload. > > If it's RSA, go by bit strength: > - <=1024 - SHA-1 with RSA > - 1024 - 2048 - >4096 - SHA2-512 with RSA > > DSA - always SHA-1 > > ECDSA will be defined by curve. The three NIST curves that everyone uses already have hashes associated with them. Any new curve would have to specify the signature algorithm in the same document. > Adding new methods giving more flexibility seems a good approach but, unfortunately, your proposal would not offer the flexibility you aim at: The Subject Public Key Algorithm OID typically used in certs are defined in RFC 3279 and these do not specify the signature algorithm. For RSA, the RSAPublicKey OID allows both RSASSA-PKCS1-v1_5 and RSASSA-PSS (currently, only an authentication method for the former is specified but the latter is definitely to be used in the future). For RSASSA-PSS, more specific public key types are specified in RFC 4055 but use of the old key identifiers is still permitted and very common. In case of ECC keys, the identifier id-ecPublicKey does also not specify the signature algorithm. Thus, unless you want to enforce usage of the id-RSASSA-PSS OID from RFC 4055 for (future) RSASA-PSS keys and restrict ECC keys to ECDSA (thus, not allowing the future use any other EC-based signature algorithm apart from ECDSA), any new authentication method should at least specify the signature algorithm (e.g. RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA). As Tero suggested, the specification of the domain parameters and hash function could possibly be required using the 3 bytes of reserved data in the authentication payload immediately after the auth method. It appears to me that an enhanced flexibility is also needed for the existing RSASSA-PKCS1-v1_5 method as soon as other hash functions than SH-1 are to be used. RFC 5996 is not very convincing in its description how this can be accomplished: --- begin extract --- Implementations can use the certificates received from a given peer as a hint for selecting a mutually understood hash function for the AUTH payload signature. Note, however, that the hash algorithm used in the AUTH payload signature doesn't have to be the same as any hash algorithm(s) used in the certificate(s). --- end extract --- So implementations are supposed to use the hash algo used by the CA (!) as an indication on what the peer uses, although this does not need to be reliable? This seems to me as a lack of proper specification. Johannes > Since the same certificate can be used with both the old authentication method and the new, we'd have to signal support in a Notify, and that Notify could have bits for indicating support for other signature algorithms such as those that go with SHA3. > > Wouldn't this make adding future curves and other signature variants easier? > > Yoav > > -- Mit freundlichen Gren, Johannes Merkle -- Dr. Johannes Merkle Principal Biometrie & Hoheitliche Dokumente secunet Security Networks AG Mergenthaler Allee 77 65760 Eschborn Germany Telefon +49 201 54 54-3091 Telefax +49 201 54 54-1325 Mobil +49 175 2224439 johannes.merkle@secunet.com www.secunet.com From ynir@checkpoint.com Thu Jul 19 04:00:34 2012 Return-Path: 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 EA52721F86BD for ; Thu, 19 Jul 2012 04:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.356 X-Spam-Level: X-Spam-Status: No, score=-10.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 tO4etFEuscGu for ; Thu, 19 Jul 2012 04:00:34 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 794FA21F86B7 for ; Thu, 19 Jul 2012 04:00:33 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6JB1NHQ004628; Thu, 19 Jul 2012 14:01:24 +0300 X-CheckPoint: {5007E725-2-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 19 Jul 2012 14:01:23 +0300 From: Yoav Nir To: Johannes Merkle Date: Thu, 19 Jul 2012 14:01:22 +0300 Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: Ac1lndVD8ZibUy2gTJG90dj1+60BcA== Message-ID: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <93213A99-17A9-44C6-97A4-F910AE789872@checkpoint.com> <5007E4C3.4080803@secunet.com> In-Reply-To: <5007E4C3.4080803@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "Biester, Jobst" , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 11:00:35 -0000 On Jul 19, 2012, at 1:43 PM, Johannes Merkle wrote: >>=20 >> How about standardizing just one more authentication method? >>=20 >> Call it "public key signature" or some such, and make the signing algori= thm depend on the public key in the CERT payload. >>=20 >> If it's RSA, go by bit strength: >> - <=3D1024 - SHA-1 with RSA >> - 1024> - 2048> - >4096 - SHA2-512 with RSA >>=20 >> DSA - always SHA-1 >>=20 >> ECDSA will be defined by curve. The three NIST curves that everyone uses= already have hashes associated with them. Any new curve would have to spec= ify the signature algorithm in the same document. >>=20 >=20 > Adding new methods giving more flexibility seems a good approach but, unf= ortunately, your proposal would not offer the > flexibility you aim at: >=20 > The Subject Public Key Algorithm OID typically used in certs are defined = in RFC 3279 and these do not specify the > signature algorithm. For RSA, the RSAPublicKey OID allows both RSASSA-PKC= S1-v1_5 and RSASSA-PSS (currently, only an > authentication method for the former is specified but the latter is defin= itely to be used in the future). For > RSASSA-PSS, more specific public key types are specified in RFC 4055 but = use of the old key identifiers is still > permitted and very common. In case of ECC keys, the identifier id-ecPubli= cKey does also not specify the signature > algorithm. >=20 > Thus, unless you want to enforce usage of the id-RSASSA-PSS OID from RFC = 4055 for (future) RSASA-PSS keys and restrict > ECC keys to ECDSA (thus, not allowing the future use any other EC-based s= ignature algorithm apart from ECDSA), any new > authentication method should at least specify the signature algorithm (e.= g. RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA). As > Tero suggested, the specification of the domain parameters and hash funct= ion could possibly be required using the 3 > bytes of reserved data in the authentication payload immediately after th= e auth method. As Tero said, the signature algorithms can be specified in the 3 reserved b= ytes, but support for such things should be indicated in the Notify payload= . Yoav > It appears to me that an enhanced flexibility is also needed for the exis= ting RSASSA-PKCS1-v1_5 method as soon as other > hash functions than SH-1 are to be used. RFC 5996 is not very convincing = in its description how this can be accomplished: >=20 > --- begin extract --- > Implementations can use the > certificates received from a given peer as a hint for selecting a > mutually understood hash function for the AUTH payload signature. >=20 > Note, however, that the hash algorithm used in the AUTH payload > signature doesn't have to be the same as any hash algorithm(s) > used in the certificate(s). > --- end extract --- >=20 > So implementations are supposed to use the hash algo used by the CA (!) a= s an indication on what the peer uses, although > this does not need to be reliable? This seems to me as a lack of proper s= pecification. >=20 > Johannes >=20 >=20 >> Since the same certificate can be used with both the old authentication = method and the new, we'd have to signal support in a Notify, and that Notif= y could have bits for indicating support for other signature algorithms suc= h as those that go with SHA3. >>=20 >> Wouldn't this make adding future curves and other signature variants eas= ier? >>=20 >> Yoav >>=20 >>=20 >=20 > --=20 >=20 > Mit freundlichen Gr=FC=DFen, > Johannes Merkle > -- > Dr. Johannes Merkle > Principal > Biometrie & Hoheitliche Dokumente > secunet Security Networks AG > Mergenthaler Allee 77 > 65760 Eschborn > Germany > Telefon +49 201 54 54-3091 > Telefax +49 201 54 54-1325 > Mobil +49 175 2224439 > johannes.merkle@secunet.com > www.secunet.com >=20 > Scanned by Check Point Total Security Gateway. From kent@bbn.com Thu Jul 19 08:15:04 2012 Return-Path: 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 3556F21F8713 for ; Thu, 19 Jul 2012 08:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.494 X-Spam-Level: X-Spam-Status: No, score=-106.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 P-nHAdwGlc-J for ; Thu, 19 Jul 2012 08:15:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0AD21F8707 for ; Thu, 19 Jul 2012 08:15:03 -0700 (PDT) Received: from dhcp89-089-116.bbn.com ([128.89.89.116]:49713) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SrsSK-0004bA-5U for ipsec@ietf.org; Thu, 19 Jul 2012 11:15:56 -0400 Message-ID: <500824AC.70002@bbn.com> Date: Thu, 19 Jul 2012 11:15:56 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: ipsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] FW: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 15:15:04 -0000 I provided a number of comments in response to the -00 version back in April. According to the diff tool in data tacker, the -01 version is identical, except that the author list and dates have changed. So it's not clear that comments really are "appreciated.";-) Steve From mcgrew@cisco.com Thu Jul 19 08:40:09 2012 Return-Path: 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 A6DAD21F84B2 for ; Thu, 19 Jul 2012 08:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 BBe20L1lHveF for ; Thu, 19 Jul 2012 08:40:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 164D821F86F3 for ; Thu, 19 Jul 2012 08:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=8042; q=dns/txt; s=iport; t=1342712462; x=1343922062; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sta4E+nsGQDRAXkzmrxt3Yfh2d08Bnwu5Q6vvStZy/0=; b=B9NLqYYI4VrQcQxFUEgnLPq8xwGqa47N0yz/V9BXZ407t8vCQcIjPW+R gpD/Ijbvqtcyt4lAOgbQJTRyZ1nRSi3Gq6OSYmMn9rMP3DpmEUewUscJv o9t4GdO80oV6eHNhCvzbtV+gQLwjnuxwpaLn4O8mIaWyfOLEsba+kd8pT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALspCFCtJV2a/2dsb2JhbABFuUGBB4IiAQQBAQEPAVgDCxIBCG0LJQIEAQ0FCRmHawueM6AIi2AGAQWGcAOIGI0sjiOBZoJfgVYBCA X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="103498275" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 19 Jul 2012 15:41:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q6JFf1gP014558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jul 2012 15:41:01 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Thu, 19 Jul 2012 10:41:00 -0500 From: "David McGrew (mcgrew)" To: Johannes Merkle , "ipsec@ietf.org" Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: AQHNWTTmZ+5hQUXnnEC8sbCYof+MZ5cw6CIA Date: Thu, 19 Jul 2012 15:41:00 +0000 Message-ID: In-Reply-To: <4FF316DF.6050109@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19050.003 x-tm-as-result: No--53.157700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <10D2FC14C22CAA458005B32B8404E457@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 15:40:09 -0000 Hi Johannes, On 7/3/12 11:59 AM, "Johannes Merkle" wrote: >Hi, > >in RFC 5639, we have specified a new set of elliptic curve parameters for >use in cryptographic applications. Meanwhile, >support for these "Brainpool Curves" has been included in some crypto >libraries as openssl (recently) and crypto++. >However, in order to use the Brainpool Curves with IKE and IPSec, still >some specifications and IANA registry updates >are needed. We are now planning to prepare such an RFC to allow usage of >the ECC Brainpool curves with ipsec. > >In order to go forward with this effort, we would like to discuss some >questions and potential issues. The WG feedback >on these is most appreciated. > >[Question 0] Is the WG interested in shepherding an RFC specifying all >that's necessary to use the Brainpool curves in >ipsec? And what category would be preferred, standard track or >informational. I think it could be reasonable to define new IKE groups based on RFC 5639. We need to avoid adding complexity to the IPsec RFC family and its implementations, so it would be important to align the use of new groups as much as possible to the existing uses of ECC in IKE, and to clarify the intended use of the new IKE groups. For instance, when should the new IKE groups be used? Which of the new groups is recommended for use? What other crypto algorithms should be used with each of those groups, to form an acceptable security policy? What are the technical merits of these new groups? I encourage you to take up these questions in your draft. Ideally, any new ECP ECC groups would retain as much of RFC 5903 as possible, such as Section 7 of that RFC, would include test cases, and would be compatible with RFC 6090. > >[Question 1] Should we include IKEv1 in the specs as well? It seems that >some people in the WG do not like the idea of >updating this obsolete protocol. On the other hand, many applications >still use IKEv1 and specifying the use of the >Brainpool curves only for IKEv2 would exclude these. The important question here is: are the anticipated users of RFC 5639 in IPsec able to use IKEv2? Perhaps this could be considered in the draft that you are planning. I would guess that the answer for most would be "yes". =20 Currently, the main driver for the use of ECC in IPsec is RFC 6380, which requires IKEv2. =20 > >[Question 2] If IKEv1 is to be considered, the registry for IPSEC >Authentication Methods (Value 3) needs to be updated, >because the values for ECDSA are specific for each curve. What policy for >updating this IANA registry can be assumed? >IANA currently requires a standard track RFC, but there has recently been >some discussion on relaxing this, in >particular,=20 >http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and >http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . >For the corresponding IKEv2 registry (Auth Method), only Expert Review is >required. > >[Question 3] If IKEv1 is to be considered, it seems reasonable to write >only one RFC covering IKEv1 and IKEv2. Actually, >we also plan to prepare analogous specifications for TLS, so an option >would be to write a common RFC for IKE and TLS >analogously to RFC 5114. However, according to the update policy of the >IANA registry EC Named Curve for TLS, such an >RFC would have to be shepherded by the tls WG. Does this prevent or >considerably complicate the creation of a joint RFC >for IKE and TLS? Would preparing separate RFCs for IKE and TLS be >preferable? > >[Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, 256, >320, 384, 512 two curves are defined, one >being the =B3quadratic twist=B2 of the other =AD their algebraic structure= (and >hence, security level) is equivalent, but one >of them allows particular efficient arithmetic. In order to leave the >choice of the curve for a given bit length to the >implementation we propose to register IANA values (for Auth method and >Diffie-Hellman Group) for both curves for each >bit length. Of course, this doubles the number of number assignments. Any >objections on this? No objection, there are about 1000 values available, and using 14 seems reasonable. =20 > >[Question 5] In Germany, not only ECDSA is in use with IKE and IPSec but >also ECGDSA (Elliptic Curve German Digital >Signature Algorithm) according to ISO 14888-3, which is a slight variant >of ECDSA. The advantage of ECGDSA over ECDSA is >that signature generation does not need any inversion modulo the group >order, which removes the necessity of >corresponding code. This advantage is particularly interesting when using >devices with limited computation power and >storage like smart cards or electronic control units in cars. In >particular, car manufacturers have expressed their >desire to deviate from EDSA For this reason, we would like to specify >values for ECGDSA (with the individual bit lengths >and curves) as Authentication Method as well. Would the WG support >inclusion of this additional signature algorithm? Adding a new algorithm brings a lot more complexity than adding a new group, and there should be some considerable technical justification put forward before new algorithms get adopted. I understand how ECGDSA avoids the modular inverse, but I do not understand how that is a significant advantage for a signature algorithm used in IKE. When ECDSA is used in IKE, the computational effort of the ECDSA modular inverse is small relative to the overall amount of computation that is done. Also, compact implementations of IKE would want to minimize the number of new algorithms that they support. Is there an expectation that users of RFC 5639 based groups in IKE would also use of ECGDSA? If not, then I encourage you to take up the ECGDSA issue in a separate draft, so that the new group work could advance independently. Are the car manufacturers that you mention potential adopters of RFC 5639 in IKE? > >[Question 6] In cryptographic applications using elliptic curves, point >compression (see Section 4.2 in RFC 6090) is >frequently used in particular in environments with limited bandwidth and >storage capacity. However, in IKE this >mechanism is currently not supported as, according to RFC 5903, the KE >payload consists of the concatenation of two >components, x and y, each of which having the same length as the >underlying finite field. We propose to add support for >point compression for the KE Payload to IKE by allowing also the use of a >compressed form of x, e.g. of 64 bits, >representing only the least significant bit. In contrast to the >(obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 >does not specify a data format for the ECDH KE payload in which the >uncompressed form is explicitly specified (e.g. in a >leading byte), uncompressed and compressed form could only be implicitly >distinguished by their bit length (as specified >in the KE header). Does this raise any issue with implementations? What >are your opinions and preferences? I think compatibility with existing standards would make both the implementations and the standards simpler, and should be the preferred direction. =20 It is true that there are limited-bandwidth scenarios in which compact representation for ECDH might be interesting, but I am somewhat skeptical that the bandwidth savings would be worth the deviation from existing RFCs. If the draft that you are preparing includes an option for compact representation, I suggest that these potential bandwidth savings be quantified and compared to the overall bandwidth used by IKE. Regards, David > >Johannes >-- >Johannes Merkle >secunet Security Networks AG >johannes.merkle@secunet.com >www.secunet.com >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Thu Jul 19 08:55:11 2012 Return-Path: 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 0E54D21F8790 for ; Thu, 19 Jul 2012 08:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 iOMi0-Udhg1z for ; Thu, 19 Jul 2012 08:55:07 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C895421F871A for ; Thu, 19 Jul 2012 08:55:05 -0700 (PDT) Received: from [10.20.30.102] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6JF4h49011512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Jul 2012 08:04:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1278) From: Paul Hoffman In-Reply-To: Date: Thu, 19 Jul 2012 08:55:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3B20D03E-33CA-4B54-836B-4513B18DD4A9@vpnc.org> References: To: IPsecme WG X-Mailer: Apple Mail (2.1278) Subject: Re: [IPsec] New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 15:55:12 -0000 On Jul 19, 2012, at 12:23 AM, Will Liu (Shucheng) wrote: > We have submitted a new version of the draft entitled " Multiple Path = IP Security ". This draft is proposed to present an approach to enhance = data protection when transmitting IPsec datagrams across the insecure = networks. The method affords the stronger protection to the traffic by = splitting it among a set of sub-tunnels. =20 >=20 > The latest version is available at: > = http://www.ietf.org/internet-drafts/draft-zhang-ipsecme-multi-path-ipsec-0= 1.txt >=20 > Any comments will be appreciated. During the discussion of the -00 draft earlier this year, a number of WG = participants sent comments to the list. It appears that none of those = comments were addressed, either on the list or in this -01 draft. Could = any of the draft authors please reply to the earlier comments? --Paul Hoffman= From kivinen@iki.fi Thu Jul 19 09:34:27 2012 Return-Path: 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 180C821F86C9 for ; Thu, 19 Jul 2012 09:34:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+lBBGU0d7qa for ; Thu, 19 Jul 2012 09:34:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id D1D7721F8675 for ; Thu, 19 Jul 2012 09:34:20 -0700 (PDT) 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 q6JGZ644017648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 19:35:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6JGZ5Vo013856; Thu, 19 Jul 2012 19:35:05 +0300 (EEST) 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: <20488.14136.959427.329740@fireball.kivinen.iki.fi> Date: Thu, 19 Jul 2012 19:35:04 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <4b62e88e53cb04aea392ea3d66068766.squirrel@www.trepanning.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <6e6e9b0353742bf189595bbdbe18ef2c.squirrel@www.trepanning.net> <20487.13524.169733.687058@fireball.kivinen.iki.fi> <7aaaf28d697c766d68119374252eab7a.squirrel@www.trepanning.net> <20487.20809.148900.638021@fireball.kivinen.iki.fi> <4b62e88e53cb04aea392ea3d66068766.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 17 min Cc: ipsec@ietf.org, Johannes Merkle , "Biester, Jobst" Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 16:34:27 -0000 Dan Harkins writes: > > Brainpool groups do not have number in the IANA registry, which makes > > them private for IKEv1 use. There is nothing there claiming that you > > can only use new group mode to negotiate groups that are not know for > > anybody else. > > "Brainpool groups do not have a number in the IANA registry". What do you > think the topic of this thread is? Look at the subject above. > > You are arguing against doing something because it hasn't been done yet > and that is illogical. No, I am arguing against it as Brainpool groups CAN ALREADY BE USED in IKEv1 without any changes to the specifications, or to the implementations. IKEv1 does not require every single group to be coded in to every implementation. > You know what? IKEv2 doesn't have any brainpool groups defined in its > IANA registry. Are you against such a code point allocation? If not, then > can I please ask you to be consistent in your positions? IKEv2 cannot use groups which do not have number allocated. There is no way to use brainpool groups in IKEv2 now. Thats why I do think adding them to the IKEv2 IANA registry is something that should be done. IKEv1 and IKEv2 situation is completely different because of that, i.e existing IKEv1 implementation can already use brainpool groups, IKEv2 implementations cannot. > Furthermore, not all implementations support domain parameter sets > being passed in SA payloads (do any?) or New Group Mode so what you > are advocating for causes more of the problems you are trying to use to > justify your advocacy. Our IKEv1 implemention 15 years ago did support both passing them in SA payloads and inside new group mode. I do not know about others. -- kivinen@iki.fi From liushucheng@huawei.com Thu Jul 19 18:22:02 2012 Return-Path: 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 8032E11E80CD for ; Thu, 19 Jul 2012 18:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, 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 HQyDW1cV85W4 for ; Thu, 19 Jul 2012 18:22:02 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D497511E80CA for ; Thu, 19 Jul 2012 18:22:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHX36401; Thu, 19 Jul 2012 21:22:56 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 18:20:49 -0700 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 19 Jul 2012 18:20:55 -0700 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.75]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 20 Jul 2012 09:20:52 +0800 From: "Will Liu (Shucheng)" To: Stephen Kent , "ipsec@ietf.org" Thread-Topic: [IPsec] FW: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-01.txt Thread-Index: AQHNZcFw9ANXOKEhZU2UQU79nia2R5cxX/6A Date: Fri, 20 Jul 2012 01:20:50 +0000 Message-ID: References: <500824AC.70002@bbn.com> In-Reply-To: <500824AC.70002@bbn.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [IPsec] FW: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 01:22:02 -0000 Thanks. I will check your comments on the previous version. Regards, Will > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Stephen Kent > Sent: Thursday, July 19, 2012 11:16 PM > To: ipsec@ietf.org > Subject: Re: [IPsec] FW: New Version Notification for > draft-zhang-ipsecme-multi-path-ipsec-01.txt >=20 > I provided a number of comments in response to the -00 version back in > April. >=20 > According to the diff tool in data tacker, the -01 version is identical, > except that the author list and dates have changed. >=20 > So it's not clear that comments really are "appreciated.";-) >=20 > Steve >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From Johannes.Merkle@secunet.com Fri Jul 20 04:12:23 2012 Return-Path: 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 C084B21F859B for ; Fri, 20 Jul 2012 04:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 u3AWgWM2KyeC for ; Fri, 20 Jul 2012 04:12:23 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id C74BF21F854D for ; Fri, 20 Jul 2012 04:12:22 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 0C1EE1A0085; Fri, 20 Jul 2012 13:12:25 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id B23A61A007A; Fri, 20 Jul 2012 13:12:22 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jul 2012 13:13:11 +0200 Message-ID: <50093D47.90500@secunet.com> Date: Fri, 20 Jul 2012 13:13:11 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Yoav Nir References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <93213A99-17A9-44C6-97A4-F910AE789872@checkpoint.com> <5007E4C3.4080803@secunet.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2012 11:13:13.0679 (UTC) FILETIME=[A78585F0:01CD6668] Cc: "ipsec@ietf.org" , "Biester, Jobst" , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 11:12:23 -0000 Yoav, > As Tero said, the signature algorithms can be specified in the 3 reserved bytes, but support for such things should be indicated in the Notify payload. Yes, I agree. > How about standardizing just one more authentication method? > > Call it "public key signature" or some such, and make the signing algorithm depend on the public key in the CERT payload. > After sleeping on your idea, I realize that it may work very well for ECDSA. The main problem with elliptic curve signature schemes is that there are so many different domain parameters. Tero has pointed out that the authentication methods registry for IKEv2 is only 8-bit, limiting the number of assignable methods. On the other hand, the domain parameters are specified in the subject public key info in the certificate, either explicitly (listing all parameters) or by reference (registered OID). Thus, it is possible to define an authentication method ECDSA_generic where the domain parameters are read from the certificate. One code point for an unlimited number of domain parameters. For the hash function to be used, there are several options: 1. An RFC could specify the default for each domain parameter set, e.g. SHA-256 for Brainpool Curve p-256. 2. Alternatively or a means to override the default setting, a hash algo ID could be encoded in the 3 reserved bytes in the authentication payload 3. Since the authentication payload has variable length, it could also include a leading byte specifying the hash algorithm. Of course, this contradicts the current specification of the ECDSA authentication payload from RFC4754, but RFC4754 specifies the encoding only for the specific NIST curves ECDSA authentication methods defined therein. Johannes From Johannes.Merkle@secunet.com Fri Jul 20 09:19:36 2012 Return-Path: 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 515BE21F858E for ; Fri, 20 Jul 2012 09:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 R6ujxcuKux-K for ; Fri, 20 Jul 2012 09:19:34 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 134A321F85F2 for ; Fri, 20 Jul 2012 09:19:34 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 562561A007E; Fri, 20 Jul 2012 18:19:35 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 7C22C1A007A; Fri, 20 Jul 2012 18:19:32 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Jul 2012 18:20:26 +0200 Message-ID: <50098548.5040609@secunet.com> Date: Fri, 20 Jul 2012 18:20:24 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipsec@ietf.org, kivinen@iki.fi References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> In-Reply-To: <20487.1106.571589.307917@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2012 16:20:26.0306 (UTC) FILETIME=[92393220:01CD6693] Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2012 16:19:36 -0000 Tero, thank you for your valuable answers. Please find my responses below. >> [Question 0] Is the WG interested in shepherding an RFC specifying >> all that's necessary to use the Brainpool curves in ipsec? And what >> category would be preferred, standard track or informational. > > I think it might be good idea to get some usable elliptic curves too. > The groups 19-21 is mostly unusable now as we messed up with their > format in the original RFC4753 and they changes we made in RFC5903 are > not backward compatible with the original RFC4753 and the > interoperability problem just causes timeout on the initiator. This is a good argument. Another one is that it is always advisable to have more than one curve per bit length just in case that new cryptanalytic results point out weaknesses in one of them. Moreover, the fact that the selection of the seeds, from which the NIST curves have been generated, is not explained might also be considered as a missing link in their property of being verifiably pseudo-random. > >> [Question 1] Should we include IKEv1 in the specs as well? It seems >> that some people in the WG do not like the idea of updating this >> obsolete protocol. On the other hand, many applications still use >> IKEv1 and specifying the use of the Brainpool curves only for IKEv2 >> would exclude these. > > I would be strongly against for including support for protocol which > has been obsoleted 7 years ago. If people want to use this kind of > groups in IKEv1 they can use the new group mode and negotiate groups > on the fly. There is no need to add them to IKEv1. > I have followed your dispute with Dan and do not take a clear position here as I have not your experience with standardization of protocols. For me, IKEv1 does not have high priority, and I mainly aim at using the Brainpool curves with IKEv2. >> [Question 2] If IKEv1 is to be considered, the registry for IPSEC >> Authentication Methods (Value 3) needs to be updated, because the >> values for ECDSA are specific for each curve. What policy for >> updating this IANA registry can be assumed? IANA currently requires >> a standard track RFC, but there has recently been some discussion on >> relaxing this, in particular, >> http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html and >> http://www.ietf.org/mail-archive/web/ipsec/current/msg07654.html . >> For the corresponding IKEv2 registry (Auth Method), only Expert >> Review is required. > > Hmm... So you are talking adding them for both Diffie-Hellman and > ECDSA uses? > Yes, sorry for not stating this clearly. Why should an implementation use another parameter set for the signature as for the key exchange unless the other peer doesn't support the primary parameters? In particular, implementations in constraint environments would benefit from the option of using only a single set of domain parameters. > Adding them for authentication use (ECDSA use) will most likely get > more opposition. First of all, I am not at all happy how the ECDSA > groups are added to the IKEv2 authentication method. The > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit > registry in IKEv1). This does not matter if we have only few ECDSA > groups with one hash algorithm for each, but when we are adding more > groups it seems to bad idea for each of them having separate number. > Especially if someone later decides that they want to use all ECDSA > groups with SHA 3 too... Today, I responded to Yoav's idea of taking algorithms details from the certificate. At least the EC domain parameters could be taken from it, and for the hash function, a default could be defined per curve. So one new authentication method ECDSA_generic or ECDSA_cert_defined could be sued for any EC domain parameters. > > I think we should have made the ECDSA support for IKEv2 in such way > that we had added some subfields to the authentication field, i.e. > only allocated one value for ECDSA and put the curve number inside the > authentication payload and perhaps even separated the hash algorithm > from it. There is 3 bytes of reserved data in the authentication > payload immediately after the auth method. Perhaps we could use those. Adding hash algorithm flexibility is of course a more general topic concerning not only ECDSA but also RSA and DSA. This is out-of-scope of our endeavor and should be discussed separately. > > It is most likely too late now, but we still want to make sure we do > not allocate too many entries from that registry, i.e. is there need > to add all the groups in there, do we really need that many different > strengths? Which hash algorithm do we use with what group? > > Also note, that authentication methods are not negotiated in IKEv2, > i.e. there is no way to know whether the other end supports the > authentication algorithm you wanted to use. On the other hand as you > need to have credentials for the other end you are using, so most > if other end would be accepting your authentication credentials it > also supports the authentication method that needs to be used to use > then. > You touch the same point as Yoav, who pointed out that a generalized authentication method (e.g. ECDSA_generic) would imply that the same certificate (for a key pair using one of the NIST curves listed in RFC 4754) could be used ith two different authentication methods. Yoav has suggested to indicate support for the general method in the Notify payload, another option could be to introduce a new transform type AUTH, so that support for this AUTH method is indicated in the SA payload. Again, this is a protocol extension that exceeds our intended scope, and should be specified separately. An alternative to avoid the interoperability problems with existing implementations of RFC 4754 could be to require that ECDSA_generic MUST not be used for the curves listed in RFC 4754, or that implementations encountering authentication failures by the other peer MUST re-try using the "old" authentication methods from RFC 4754. > On the IKEv1 there is another problem. The authentication method is > negotiated (in main mode), but it MUST be same for both directions, so > both ends must support same types of credentials. Also as you pointed > out the authentication algorithgms registry for IKEv1 is still > Standard track RFC required and there has been multiple people in the > WG opposing to changing it. > After following your discussion with Dan I doubt that a WG consensus can be achieved on this issue. But as I said, IKEv1 is of minor importance for me. > So adding support for authentication methods do require more work for > both IKEv1 and IKEv2. > I think my proposal (based on Yoav's idea) of introducing a generalized ECDSA authentication method could do the trick, as long as the potential conflict with existing RFC 4754 implementations are not considered a no-go. >> [Question 3] If IKEv1 is to be considered, it seems reasonable to >> write only one RFC covering IKEv1 and IKEv2. Actually, we also plan >> to prepare analogous specifications for TLS, so an option would be >> to write a common RFC for IKE and TLS analogously to RFC 5114. >> However, according to the update policy of the IANA registry EC >> Named Curve for TLS, such an RFC would have to be shepherded by the >> tls WG. Does this prevent or considerably complicate the creation of >> a joint RFC for IKE and TLS? Would preparing separate RFCs for IKE >> and TLS be preferable? > > I would suggest writing separate RFCs for TLS. It might seem like good > idea to write only one RFC, but that just causes confusion to the > actual users of the RFC. They are either TLS or IPsec implementors, > and it is confusing if you are not using the same terms which are > already used in those protocols. > This argument seems very reasonable. > >> [Question 4] In RFC 5639, for each of the bit lengths 160, 192, 224, >> 256, 320, 384, 512 two curves are defined, one being the $,1r|(Bquadratic >> twist$,1r}(B of the other $,1rs(B their algebraic structure (and hence, security >> level) is equivalent, but one of them allows particular efficient >> arithmetic. In order to leave the choice of the curve for a given >> bit length to the implementation we propose to register IANA values >> (for Auth method and Diffie-Hellman Group) for both curves for each >> bit length. Of course, this doubles the number of number >> assignments. Any objections on this? > > For Diffie-Hellman groups with 16-bit registry, no. For the > Authentication Algorithms registry with only 8-bit registry, yes. On > the other hand if we do take those reserved fields in to use in the > IKEv2 authentication payload and put the parameters there then I see > no reason to limit the number of groups. This issue would be solved by the generic ECDSA method. > >> [Question 5] In Germany, not only ECDSA is in use with IKE and IPSec >> but also ECGDSA (Elliptic Curve German Digital Signature Algorithm) >> according to ISO 14888-3, which is a slight variant of ECDSA. The >> advantage of ECGDSA over ECDSA is that signature generation does not >> need any inversion modulo the group order, which removes the >> necessity of corresponding code. This advantage is particularly >> interesting when using devices with limited computation power and >> storage like smart cards or electronic control units in cars. In >> particular, car manufacturers have expressed their desire to deviate >> from EDSA For this reason, we would like to specify values for >> ECGDSA (with the individual bit lengths and curves) as >> Authentication Method as well. Would the WG support inclusion of >> this additional signature algorithm? > > I think it might be good idea for IKEv2 (and bad idea for IKEv1), but > at least there I think we should add it differently than what is done > for the current ECDSA code, i.e not make separate number for each > group (which would be 28 (i.e. >10% of the whole registry) if we add > all 7 strengths with 2 formats and each with both ECDSA and ECGDSA). > Again, a generalizes ECGDSA method would achieve exactly what you indicate. Only one additional assignment. >> [Question 6] In cryptographic applications using elliptic curves, >> point compression (see Section 4.2 in RFC 6090) is frequently used >> in particular in environments with limited bandwidth and storage >> capacity. However, in IKE this mechanism is currently not supported >> as, according to RFC 5903, the KE payload consists of the >> concatenation of two components, x and y, each of which having the >> same length as the underlying finite field. We propose to add >> support for point compression for the KE Payload to IKE by allowing >> also the use of a compressed form of x, e.g. of 64 bits, >> representing only the least significant bit. In contrast to the >> (obsolete) draft-ietf-ipsec-ike-ecc-groups-10, RFC 5903 does not >> specify a data format for the ECDH KE payload in which the >> uncompressed form is explicitly specified (e.g. in a leading byte), >> uncompressed and compressed form could only be implicitly >> distinguished by their bit length (as specified in the KE header). >> Does this raise any issue with implementations? What are your >> opinions and preferences? > > I have been under impression that the point compression is one of > those items which are patented and that is the reason why it is not This is not an issue. According to http://cr.yp.to/patents/us/6141420.html the patent is almost certainly invalid because its authors revealed the (known) existence of prior art to the patent office, and furthermore, the patent expires in 2014. > been used in the IKEv2. Also as I said earlier the authentication > methods are not negotiated, thus if one ends send KE payload in point > compressed format and other end does not implement point compression > because of licensing reasons they cannot talk to each other. > I am not talking about authentication but about key exchange. For authentication, no point compression can be applied, as an ECDSA signature dies not represent a point on the curve but only to integers (mod the group order). But I admit that there might be an issue when an implementation not supporting point compression receives a KE payload of unexpected length. This might lead to undesired behavior. Thus, it might be necessary to use separate group descriptions when using point compression. But I have not sufficient experience with implementations to assess that. Johannes From kivinen@iki.fi Sat Jul 21 08:56:11 2012 Return-Path: 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 C181021F8647 for ; Sat, 21 Jul 2012 08:56:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oq5dVBu1TO-E for ; Sat, 21 Jul 2012 08:56:10 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 529FF21F8645 for ; Sat, 21 Jul 2012 08:56:04 -0700 (PDT) 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 q6LFuxS0007568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Jul 2012 18:56:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6LFux1I018359; Sat, 21 Jul 2012 18:56:59 +0300 (EEST) 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: <20490.53579.25865.193739@fireball.kivinen.iki.fi> Date: Sat, 21 Jul 2012 18:56:59 +0300 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <50098548.5040609@secunet.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 18 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 15:56:11 -0000 Johannes Merkle writes: > > Adding them for authentication use (ECDSA use) will most likely get > > more opposition. First of all, I am not at all happy how the ECDSA > > groups are added to the IKEv2 authentication method. The > > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit > > registry in IKEv1). This does not matter if we have only few ECDSA > > groups with one hash algorithm for each, but when we are adding more > > groups it seems to bad idea for each of them having separate number. > > Especially if someone later decides that they want to use all ECDSA > > groups with SHA 3 too... > > Today, I responded to Yoav's idea of taking algorithms details from > the certificate. At least the EC domain parameters could be taken > from it, and for the hash function, a default could be defined per > curve. So one new authentication method ECDSA_generic or > ECDSA_cert_defined could be sued for any EC domain parameters. Hmm... so the EC domain parameters can be seen from the certificate? I wonder why did the RFC4753 then made separate allocations for each EC group? > > I think we should have made the ECDSA support for IKEv2 in such way > > that we had added some subfields to the authentication field, i.e. > > only allocated one value for ECDSA and put the curve number inside the > > authentication payload and perhaps even separated the hash algorithm > > from it. There is 3 bytes of reserved data in the authentication > > payload immediately after the auth method. Perhaps we could use those. > > Adding hash algorithm flexibility is of course a more general topic > concerning not only ECDSA but also RSA and DSA. This is out-of-scope > of our endeavor and should be discussed separately. We already have this same problem in the RSA, and we do assume that it is not a problem in real life. I.e. every implementation will use hash algorithm that is supported by other end. I.e. if some impementation is SHA-1 only then certificates are also SHA-1 only and everybody uses SHA-1, and if certificates uses SHA-2, then everybody using those certificates do support both SHA-1 and SHA-2, and it does not really matter which hash function is used... This is the reason why we do not explictly define what hash function needs to be used with RSA. > You touch the same point as Yoav, who pointed out that a generalized > authentication method (e.g. ECDSA_generic) would imply that the same > certificate (for a key pair using one of the NIST curves listed in > RFC 4754) could be used ith two different authentication methods. > Yoav has suggested to indicate support for the general method in the > Notify payload, another option could be to introduce a new transform > type AUTH, so that support for this AUTH method is indicated in the > SA payload. Again, this is a protocol extension that exceeds our > intended scope, and should be specified separately. > > An alternative to avoid the interoperability problems with existing > implementations of RFC 4754 could be to require that ECDSA_generic > MUST not be used for the curves listed in RFC 4754, or that > implementations encountering authentication failures by the other > peer MUST re-try using the "old" authentication methods from RFC > 4754. I think the way forward is to take this WG and as whether WG would be willing to recharter and add new items to its charter: 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be done as individual draft, and does not need to be WG item, but if we are doing the rest in WG then I think this should also be WG item too). 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) in the IKEv2. This may require new standard track RFC defining new generic ECDSA method, and might also need solutions how hash function is selected for each group. Then we can start thinking in the WG what would be the best way to solve those problems. I think the correct solution would be to make new ECDSA_generic method and specify where the domain parameters come (both with certificates and with raw public keys), and we might want to give some kind of implementation guidelines to the hash algorithm selection, or we might even define a way to specify it. > > I have been under impression that the point compression is one of > > those items which are patented and that is the reason why it is not > > This is not an issue. According to > http://cr.yp.to/patents/us/6141420.html the patent is almost > certainly invalid because its authors revealed the (known) existence > of prior art to the patent office, and furthermore, the patent > expires in 2014. We cannot really say whether some patent is invalid or not, but on the other hand saying it will expire 2014 is something that will help... > > > been used in the IKEv2. Also as I said earlier the authentication > > methods are not negotiated, thus if one ends send KE payload in point > > compressed format and other end does not implement point compression > > because of licensing reasons they cannot talk to each other. > > > > I am not talking about authentication but about key exchange. For > authentication, no point compression can be applied, as an ECDSA > signature dies not represent a point on the curve but only to > integers (mod the group order). Ah, good. > But I admit that there might be an issue when an implementation not > supporting point compression receives a KE payload of unexpected > length. This might lead to undesired behavior. Thus, it might be > necessary to use separate group descriptions when using point > compression. But I have not sufficient experience with > implementations to assess that. With Diffie-Hellman groups things are easier, as they are negotiated in the IKEv2, and if someone send KE payload which other end does not support (i.e. uses point compression) but also proposes same group without point compression, the receiver can send INVALID_KE_PAYLOAD and tell the other end to fall back to common group. So to support point compression we can allocate allocate separate groups for compressed and non-compressed uses. I am not sure whether that is best option, but that is something we can look at on item 1 above in the WG. -- kivinen@iki.fi From dharkins@lounge.org Sat Jul 21 09:27:42 2012 Return-Path: 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 32BC221F860D for ; Sat, 21 Jul 2012 09:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 R3ohzH5tGRi5 for ; Sat, 21 Jul 2012 09:27:41 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A989721F85F1 for ; Sat, 21 Jul 2012 09:27:32 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3F4AF10224008; Sat, 21 Jul 2012 09:28:31 -0700 (PDT) Received: from 63.133.196.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 21 Jul 2012 09:28:31 -0700 (PDT) Message-ID: <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> In-Reply-To: <20490.53579.25865.193739@fireball.kivinen.iki.fi> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> Date: Sat, 21 Jul 2012 09:28:31 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" 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 Cc: ipsec@ietf.org, Johannes Merkle Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 16:27:42 -0000 On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: > Johannes Merkle writes: >> > Adding them for authentication use (ECDSA use) will most likely get >> > more opposition. First of all, I am not at all happy how the ECDSA >> > groups are added to the IKEv2 authentication method. The >> > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit >> > registry in IKEv1). This does not matter if we have only few ECDSA >> > groups with one hash algorithm for each, but when we are adding more >> > groups it seems to bad idea for each of them having separate number. >> > Especially if someone later decides that they want to use all ECDSA >> > groups with SHA 3 too... >> >> Today, I responded to Yoav's idea of taking algorithms details from >> the certificate. At least the EC domain parameters could be taken >> from it, and for the hash function, a default could be defined per >> curve. So one new authentication method ECDSA_generic or >> ECDSA_cert_defined could be sued for any EC domain parameters. > > Hmm... so the EC domain parameters can be seen from the certificate? I > wonder why did the RFC4753 then made separate allocations for each EC > group? The particular curve can be determined from the subjectPublicKeyInfo. Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool curves. I'm not so sure it makes sense to define a new hash algorithm per curve though. I would suggest just using the negotiated hash function. That is going to be used for key derivation and will influence the level of security that the exchange affords. That is, if you define SHA-384 to use with brainpoolP384r1 but the two sides end up using SHA-1 for key derivation then I'm not sure what using SHA-384 for authentication is buying you. [snip] > > I think the way forward is to take this WG and as whether WG would be > willing to recharter and add new items to its charter: > > 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be > done as individual draft, and does not need to be WG item, but if > we are doing the rest in WG then I think this should also be WG > item too). > 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) > in the IKEv2. This may require new standard track RFC defining new > generic ECDSA method, and might also need solutions how hash > function is selected for each group. If we're gonna recharter, maybe we should just work on an IKEv3 because the problems in IKEv2 are becoming apparent. This "new authentication mode" suggestion, or the need for a "generic ECDSA" algorithm are just hacks that should not be necessary for a properly defined protocol. In addition, the issues with the incorrect definition of representation of the result of an ECDH (it's the x-coordinate, not the concatenation of the x- and y-coordinates) that's lead to interoperability issues, and the inability to handle point compression all lead one to the conclusion that this stuff should all be fixed once and for all and fixed cleanly. Dan. From ynir@checkpoint.com Sat Jul 21 10:49:46 2012 Return-Path: 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 4B85121F8505 for ; Sat, 21 Jul 2012 10:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.389 X-Spam-Level: X-Spam-Status: No, score=-10.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 pKRKvqbP4jIV for ; Sat, 21 Jul 2012 10:49:45 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA0C21F858F for ; Sat, 21 Jul 2012 10:49:44 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6LHof4L027501; Sat, 21 Jul 2012 20:50:42 +0300 X-CheckPoint: {500AE9F4-0-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 21 Jul 2012 20:50:41 +0300 From: Yoav Nir To: Dan Harkins Date: Sat, 21 Jul 2012 20:50:40 +0300 Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: Ac1naVfpX+OwdHCwShGt/saONaNPBA== Message-ID: <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> In-Reply-To: <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Johannes Merkle , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 17:49:46 -0000 On Jul 21, 2012, at 7:28 PM, Dan Harkins wrote: >=20 > On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: >> Johannes Merkle writes: >>>> Adding them for authentication use (ECDSA use) will most likely get >>>> more opposition. First of all, I am not at all happy how the ECDSA >>>> groups are added to the IKEv2 authentication method. The >>>> authentication methods registry is only 8-bit in IKEv2 (it is 16-bit >>>> registry in IKEv1). This does not matter if we have only few ECDSA >>>> groups with one hash algorithm for each, but when we are adding more >>>> groups it seems to bad idea for each of them having separate number. >>>> Especially if someone later decides that they want to use all ECDSA >>>> groups with SHA 3 too... >>>=20 >>> Today, I responded to Yoav's idea of taking algorithms details from >>> the certificate. At least the EC domain parameters could be taken >>> from it, and for the hash function, a default could be defined per >>> curve. So one new authentication method ECDSA_generic or >>> ECDSA_cert_defined could be sued for any EC domain parameters. >>=20 >> Hmm... so the EC domain parameters can be seen from the certificate? I >> wonder why did the RFC4753 then made separate allocations for each EC >> group? >=20 > The particular curve can be determined from the subjectPublicKeyInfo. > Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool > curves. >=20 > I'm not so sure it makes sense to define a new hash algorithm per curve > though. I would suggest just using the negotiated hash function. That is > going to be used for key derivation and will influence the level of secur= ity > that the exchange affords. That is, if you define SHA-384 to use with > brainpoolP384r1 but the two sides end up using SHA-1 for key derivation > then I'm not sure what using SHA-384 for authentication is buying you. Not much, but not all PRF functions are hashes. What hash will you use if y= our PRF is AES-XCBC? What if it's GHash? Sure we could extend both those t= o be hash functions (just use AES-XCBC with a fixed key) but we've never do= ne this before, and I don't have any idea if the cryptographers will approv= e. > [snip] >>=20 >> I think the way forward is to take this WG and as whether WG would be >> willing to recharter and add new items to its charter: >>=20 >> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be >> done as individual draft, and does not need to be WG item, but if >> we are doing the rest in WG then I think this should also be WG >> item too). >> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) >> in the IKEv2. This may require new standard track RFC defining new >> generic ECDSA method, and might also need solutions how hash >> function is selected for each group. >=20 > If we're gonna recharter, maybe we should just work on an IKEv3 because > the problems in IKEv2 are becoming apparent. This "new authentication mod= e" > suggestion, or the need for a "generic ECDSA" algorithm are just hacks th= at > should not be necessary for a properly defined protocol. In addition, the > issues with the incorrect definition of representation of the result of a= n > ECDH (it's the x-coordinate, not the concatenation of the x- and > y-coordinates) that's lead to interoperability issues, and the inability = to > handle point compression all lead one to the conclusion that this stuff > should all be fixed once and for all and fixed cleanly. In 6 years IKEv2 has gained very little traction. All major vendors offer i= t, but it's still not the default setting for any of them. It would be as b= ad as saying that IPv6 has problems, so we should begin work on IPv8. Yoav= From sfluhrer@cisco.com Sat Jul 21 11:30:16 2012 Return-Path: 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 711F521F852B for ; Sat, 21 Jul 2012 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 FwOsabEIIPuZ for ; Sat, 21 Jul 2012 11:30:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C45CE21F851C for ; Sat, 21 Jul 2012 11:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=730; q=dns/txt; s=iport; t=1342895475; x=1344105075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JrQdVKqA1MzjrThn9fsTVtT//oXRPBDVHGmZoQeJ3zc=; b=l+twIf5kGpEetVMm0JQtNsqkVi0H5zkdpVIG4YG4SVqB21nNls68G1yS 0U85eHF8hxnd3Ix2ny0SuvA7WrtpABYsDZyh4i4t5Fi4sjwMNZJIvX9QL zul3RhoPZLIaMZeWHX0OrE13rfXBPNR4EibyZ5AGMY+y7BPavHxb9lJN7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOT0ClCtJV2b/2dsb2JhbABFuVuBB4IgAQEBAwESASc/BQcEAgEIDgMEAQELFAkHMhQJCAIEAQ0FCBqHZQaebJ9Ai02Fc2ADo3CBZoJf X-IronPort-AV: E=Sophos;i="4.77,630,1336348800"; d="scan'208";a="104080499" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 21 Jul 2012 18:31:15 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q6LIVEXk004849 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 21 Jul 2012 18:31:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Sat, 21 Jul 2012 13:31:14 -0500 From: "Scott Fluhrer (sfluhrer)" To: Yoav Nir , Dan Harkins Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: AQHNZpOb9clt6S/TCkq27t8USi0SLpc0OZaAgAAIz4CAABb0AP//tpfw Date: Sat, 21 Jul 2012 18:31:14 +0000 Message-ID: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> In-Reply-To: <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.83] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19056.000 x-tm-as-result: No--20.877000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Johannes Merkle , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2012 18:30:16 -0000 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Saturday, July 21, 2012 1:51 PM To: Dan Harkins Cc: ipsec@ietf.org; Johannes Merkle; Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec > Not much, but not all PRF functions are hashes. What hash will you use if= your PRF is AES-XCBC? What if it's GHash? > Sure we could extend both those to be hash functions (just use AES-XCBC w= ith a fixed key) but we've never done this > before, and I don't have any idea if the cryptographers will approve. Cryptographers would certainly not approve; it's easy to generate preimages= for AES-XCBC or GHash with a public key. From dharkins@lounge.org Sat Jul 21 18:11:44 2012 Return-Path: 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 98BCF21F859A for ; Sat, 21 Jul 2012 18:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 cbjMu2e44AaD for ; Sat, 21 Jul 2012 18:11:44 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id F248821F8599 for ; Sat, 21 Jul 2012 18:11:43 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CBB6910224008; Sat, 21 Jul 2012 18:12:43 -0700 (PDT) Received: from 12.69.234.130 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 21 Jul 2012 18:12:44 -0700 (PDT) Message-ID: <92f255201e78f338cb9de9b6dec68204.squirrel@www.trepanning.net> In-Reply-To: <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> Date: Sat, 21 Jul 2012 18:12:44 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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 Cc: "ipsec@ietf.org" , Johannes Merkle , Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 01:11:44 -0000 On Sat, July 21, 2012 10:50 am, Yoav Nir wrote: > > On Jul 21, 2012, at 7:28 PM, Dan Harkins wrote: > >> On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: [snip] >>> I think the way forward is to take this WG and as whether WG would be >>> willing to recharter and add new items to its charter: >>> >>> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be >>> done as individual draft, and does not need to be WG item, but if >>> we are doing the rest in WG then I think this should also be WG >>> item too). >>> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) >>> in the IKEv2. This may require new standard track RFC defining new >>> generic ECDSA method, and might also need solutions how hash >>> function is selected for each group. >> >> If we're gonna recharter, maybe we should just work on an IKEv3 because >> the problems in IKEv2 are becoming apparent. This "new authentication >> mode" >> suggestion, or the need for a "generic ECDSA" algorithm are just hacks >> that >> should not be necessary for a properly defined protocol. In addition, >> the >> issues with the incorrect definition of representation of the result of >> an >> ECDH (it's the x-coordinate, not the concatenation of the x- and >> y-coordinates) that's lead to interoperability issues, and the inability >> to >> handle point compression all lead one to the conclusion that this stuff >> should all be fixed once and for all and fixed cleanly. > > In 6 years IKEv2 has gained very little traction. All major vendors offer > it, but it's still not the default setting for any of them. It would be as > bad as saying that IPv6 has problems, so we should begin work on IPv8. We've been through nearly 40 revisions of this protocol (18 for IKEv2, another 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it still needs hacks to add some new elliptic curves-- either N new authentication modes for N curves, or a new unified and general ECDSA in addition to the existing 3 for ECDSA (!!!)-- and even still there will be interoperability issues because some people represent an ECDH shared secret as x||y and others represent it as x. Notice how the Notify payload is becoming the overloaded payload of choice to "fix" everything? It's hacked for EAP-only, it's hacked for secure passwords, and it's the method of choice to hack in new curves. Yuck. It's not apparent to me that the reasons for lack of deployment of IKEv2 are in any way similar to those of IPv6 (and, frankly, I would tend to doubt there is any relationship). It may be "bad" to say that we have a problem, but it's worse to deny that the problem exists. The first step to actually addressing one's problems of dysfunction is admitting to them. Let me begin: "Hello! My name is Dan. We have a problem." Dan. From kivinen@iki.fi Sun Jul 22 05:31:02 2012 Return-Path: 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 99D4421F8564 for ; Sun, 22 Jul 2012 05:31:02 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 z0ICZhdpxfyu for ; Sun, 22 Jul 2012 05:30:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A60321F8582 for ; Sun, 22 Jul 2012 05:30:44 -0700 (PDT) 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 q6MCUR9U025202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2012 15:30:27 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6MCUQN3016145; Sun, 22 Jul 2012 15:30:26 +0300 (EEST) 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: <20491.62050.196289.183047@fireball.kivinen.iki.fi> Date: Sun, 22 Jul 2012 15:30:26 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 8 min Cc: ipsec@ietf.org, Johannes Merkle Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 12:31:02 -0000 Dan Harkins writes: > I'm not so sure it makes sense to define a new hash algorithm per curve > though. I would suggest just using the negotiated hash function. That is We do not negotiate hash function in IKEv2. We do negotiate Pseudo-random function (PRF) and Integrity Algorithm (MAC), but there is no HASH function negotiated. > going to be used for key derivation and will influence the level of security > that the exchange affords. That is, if you define SHA-384 to use with > brainpoolP384r1 but the two sides end up using SHA-1 for key derivation > then I'm not sure what using SHA-384 for authentication is buying you. IKEv2 do not use hash function for key deriviation it uses PRF for that. -- kivinen@iki.fi From kivinen@iki.fi Sun Jul 22 06:15:49 2012 Return-Path: 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 5366421F855D for ; Sun, 22 Jul 2012 06:15:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei4ueszRo3dq for ; Sun, 22 Jul 2012 06:15:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B9A21F8589 for ; Sun, 22 Jul 2012 06:15:47 -0700 (PDT) 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 q6MDFN8Q001737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Jul 2012 16:15:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6MDFLd4016426; Sun, 22 Jul 2012 16:15:21 +0300 (EEST) 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: <20491.64745.55358.539748@fireball.kivinen.iki.fi> Date: Sun, 22 Jul 2012 16:15:21 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <92f255201e78f338cb9de9b6dec68204.squirrel@www.trepanning.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> <92f255201e78f338cb9de9b6dec68204.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 24 min Cc: "ipsec@ietf.org" , Johannes Merkle , Yoav Nir Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 13:15:49 -0000 Dan Harkins writes: > We've been through nearly 40 revisions of this protocol (18 for IKEv2, > another > 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it > still > needs hacks to add some new elliptic curves-- either N new authentication > modes for N curves, or a new unified and general ECDSA in addition to the > existing 3 for ECDSA (!!!)-- You forgot the IKEv1 drafts too, as IKEv1 does the ECDSA at the same way than IKEv2 (they both come from the same RFC), so they should also be counted as revisions. And, no, I have no idea why the people who added ECDSA did add it that way. I always assumed that there is no way to know the domain parameters and hash from the cert / signature, and thats why they needed to be encoded to the auth algorithm field. Now it seems my assumption was incorrect. But with the patent issues with elliptic curves, nobody really used EC, thus nobody really cared... (at least for me the reason I did not care about EC was those patent issues, and also as there was no real customer demand for them, or to say that the customer demand usually went away when they heard there are patent issues). > and even still there will be interoperability issues because some > people represent an ECDH shared secret as x||y and others represent > it as x. Yes, this just points how little people cared. Some people did notice it, but just assumed that ok, they just wanted to things differently and changed their code to do what original RFC4753 defined. Fixing that kind of problem with errata, was really bad mistake. And I still think fixing that problem without allocating new numbers were again mistake, but I lost that fight. Also it took several years before this issue was even noticed, that tells how little EC groups are really used (either in IKEv1 or IKEv2, as the same mistake was in both of them). > Notice how the Notify payload is becoming the overloaded payload of choice > to "fix" everything? It's hacked for EAP-only, it's hacked for secure > passwords, and it's the method of choice to hack in new curves. Yuck. I do not think notify payload has "become the overloaded payload of choice", it was originally defined in IKEV2 for that purposes also: ---------------------------------------------------------------------- 3.10. Notify Payload ... in any other message to indicate sender capabilities or to modify the meaning of the request. ---------------------------------------------------------------------- The main reason why notify is used in the IKEv2, is that it is secure (compared to IKEv1, where it cannot be used as it is not authenticated in phase 1) and easy way to do capability indications. I myself think notify payload is much better than using vendor ID payloads which was normally done in IKEv1. -- kivinen@iki.fi From ynir@checkpoint.com Sun Jul 22 06:52:53 2012 Return-Path: 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 F35EF21F85A5 for ; Sun, 22 Jul 2012 06:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.403 X-Spam-Level: X-Spam-Status: No, score=-10.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 IExLkA8hveJh for ; Sun, 22 Jul 2012 06:52:51 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id F1DB121F8475 for ; Sun, 22 Jul 2012 06:52:50 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6MDrVSH013902; Sun, 22 Jul 2012 16:53:47 +0300 X-CheckPoint: {500C03D3-0-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 22 Jul 2012 16:53:33 +0300 From: Yoav Nir To: Tero Kivinen Date: Sun, 22 Jul 2012 16:53:35 +0300 Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: Ac1oEWHh3N4uMU0jQ1GwsVHXRcs3DA== Message-ID: <81E5B1E9-CB8C-4A61-B242-3A02D1C8E5EA@checkpoint.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> <92f255201e78f338cb9de9b6dec68204.squirrel@www.trepanning.net> <20491.64745.55358.539748@fireball.kivinen.iki.fi> In-Reply-To: <20491.64745.55358.539748@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Johannes Merkle , Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 13:52:53 -0000 On Jul 22, 2012, at 4:15 PM, Tero Kivinen wrote: > Dan Harkins writes: >> We've been through nearly 40 revisions of this protocol (18 for IKEv2, >> another >> 10 to "clarify" how to use it and then another 11 to do IKEv2v2) and it >> still >> needs hacks to add some new elliptic curves-- either N new authenticatio= n >> modes for N curves, or a new unified and general ECDSA in addition to th= e >> existing 3 for ECDSA (!!!)-- >=20 > You forgot the IKEv1 drafts too, as IKEv1 does the ECDSA at the same > way than IKEv2 (they both come from the same RFC), so they should also > be counted as revisions. >=20 > And, no, I have no idea why the people who added ECDSA did add it that > way.=20 I don't know either, but I can guess. With RSA the hash is much smaller tha= n the signature (128-512 bits vs 1024-4096 bits) so we use the PKCS#1 struc= ture that also describes the hash. So you don't need to specify the hash up= front - it's encoded in the signature itself. With ECDSA, the hashes are the same sizes as the signatures, so there's no = room within the signature to encode the hash algorithm. You need to know wh= at it is by some other means. So they chose to encode it using the AUTH met= hod. Not very economical in terms of protecting the scarce resource of auth= methods. My suggestion only improves this by making each curve go with a specific ha= sh (specified in the document, not in the protocol). And you can probably r= eplace the hashes with their SHA-3 (or GOST) equivalents by using the reser= ved fields in the AUTH payload. Regardless of what we do with the Brainpool= curves, we also need to be ready for vanity curves, and there's no telling= how many we're going to have. openssl/crypto/ec/ec_curve.c has several doz= ens of them, and I wouldn't want us to have to fight over allocation for ea= ch new curve. Yoav From dharkins@lounge.org Sun Jul 22 11:54:08 2012 Return-Path: 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 A6BEC21F85AF for ; Sun, 22 Jul 2012 11:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.149 X-Spam-Level: X-Spam-Status: No, score=-6.149 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 qyKVM8Dw6qPa for ; Sun, 22 Jul 2012 11:54:08 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBAA21F8568 for ; Sun, 22 Jul 2012 11:54:08 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D2D9A10224008; Sun, 22 Jul 2012 11:55:09 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 22 Jul 2012 11:55:10 -0700 (PDT) Message-ID: <3bb6591ee408288a9781c6574de15d5c.squirrel@www.trepanning.net> In-Reply-To: <81E5B1E9-CB8C-4A61-B242-3A02D1C8E5EA@checkpoint.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> <92f255201e78f338cb9de9b6dec68204.squirrel@www.trepanning.net> <20491.64745.55358.539748@fireball.kivinen.iki.fi> <81E5B1E9-CB8C-4A61-B242-3A02D1C8E5EA@checkpoint.com> Date: Sun, 22 Jul 2012 11:55:10 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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 Cc: "ipsec@ietf.org" , Johannes Merkle , Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 18:54:08 -0000 On Sun, July 22, 2012 6:53 am, Yoav Nir wrote: > > With ECDSA, the hashes are the same sizes as the signatures, so there's no > room within the signature to encode the hash algorithm. You need to know > what it is by some other means. So they chose to encode it using the AUTH > method. Not very economical in terms of protecting the scarce resource of > auth methods. Actually that's not true. The length of the digest of the hash algorithm is not the same as the length of the prime of the curve (what I think you mean by the "same size as the signatures" since the the signature is R|S). X9.62 says that the length of the digest of the hash is a kind of low-water mark of the desired security level. If the digest is larger than the length of the prime then you're supposed to take the left-most length-of-prime bits of the digest and use that to compute "s". And this points out to another unfortunate design decision of IKEv2. Instead of negotiating a fundamental cryptographic primitive like a hash function, it negotiates a derivative construct like a PRF. So instead of being able to use the negotiated hash function to compute an ECDSA signature we're forced to eat through the "scarce resource" of the authentication method registry. Very clumsy, very hackish, very unfortunate. Dan. From sfluhrer@cisco.com Sun Jul 22 12:51:49 2012 Return-Path: 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 B883521F8683 for ; Sun, 22 Jul 2012 12:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 3078XBuZQyKi for ; Sun, 22 Jul 2012 12:51:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9A62C21F8681 for ; Sun, 22 Jul 2012 12:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=1752; q=dns/txt; s=iport; t=1342986771; x=1344196371; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bO6I6gEo4l4B6IHEd3t3I5zGlA8bBtUz0W7MmHXeDDE=; b=Rok881wAjsoqlmoARrg7ACmQDbMDdR40qrqpuTG6WV970c4XQtcLBk21 yhBgctfI2dDpDlh2z1Fmh87PVkN15suZo+ax78mIosG2dHf7SosHBqP4r vUIZSr3PuuBy8HNtVMMhn4Sg2MXuDsPqS6ZR5jQjmmlC0tioFajxgyI2Z A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIZZDFCtJXHB/2dsb2JhbABFuVyBB4IgAQEBAwESASc/BQcEAgEIDgMEAQELFAkHMhQJCAIEAQ0FCBqHZQafPp5/i02Fc2ADo3CBZoJf X-IronPort-AV: E=Sophos;i="4.77,633,1336348800"; d="scan'208";a="104203164" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jul 2012 19:52:50 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q6MJqoJi008433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 22 Jul 2012 19:52:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0283.003; Sun, 22 Jul 2012 14:52:50 -0500 From: "Scott Fluhrer (sfluhrer)" To: Yoav Nir , Tero Kivinen Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: AQHNZpOb9clt6S/TCkq27t8USi0SLpc0OZaAgAAIz4CAABb0AIAAe4MAgADJ5oCAAAqugIAAAthw Date: Sun, 22 Jul 2012 19:52:49 +0000 Message-ID: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> <92f255201e78f338cb9de9b6dec68204.squirrel@www.trepanning.net> <20491.64745.55358.539748@fireball.kivinen.iki.fi> <81E5B1E9-CB8C-4A61-B242-3A02D1C8E5EA@checkpoint.com> In-Reply-To: <81E5B1E9-CB8C-4A61-B242-3A02D1C8E5EA@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.83] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19058.001 x-tm-as-result: No--27.012400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Johannes Merkle , Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jul 2012 19:51:50 -0000 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Y= oav Nir Sent: Sunday, July 22, 2012 9:54 AM To: Tero Kivinen Cc: ipsec@ietf.org; Johannes Merkle; Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec > I don't know either, but I can guess. With RSA the hash is much smaller t= han the signature (128-512 bits vs 1024-4096 > bits) so we use the PKCS#1 structure that also describes the hash. So you= don't need to specify the hash up front - > it's encoded in the signature itself. > > With ECDSA, the hashes are the same sizes as the signatures, so there's n= o room within the signature to encode the > hash algorithm. You need to know what it is by some other means. A comment from the pedants-R-us gallery: well, you've come to the correct c= onclusion (there's no way to determine from an ECDSA signature the hash use= d to generate the signature), however the reasoning you used to get there i= s incorrect. The issue isn't the size of an ECDSA signature (for example, a signature ba= sed on the P256 curve is 512 bits long, and uses only 256 bits from the has= h). Instead, the way RSA works allows recovery of the padded hash; we can = take advantage of that to signify the hash method in the padding bits. In = contrast, ECDSA does not allow the analogous operation; even if we padded t= he hash, we couldn't recover the padding anyways from the signature. We ca= n certainly test if a specific hash value is the one that goes with the sig= nature (that's what the signature verification operation is); however, it i= s infeasible to recover information about that value (for example, any bits= that might signify padding). From kivinen@iki.fi Mon Jul 23 02:21:18 2012 Return-Path: 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 3C36E21F86C2 for ; Mon, 23 Jul 2012 02:21:18 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 wTuI-6kGtMGt for ; Mon, 23 Jul 2012 02:21:17 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB7121F86AB for ; Mon, 23 Jul 2012 02:21:14 -0700 (PDT) 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 q6N9Jgxa023565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2012 12:19:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6N9Jd9d015290; Mon, 23 Jul 2012 12:19:39 +0300 (EEST) 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: <20493.5931.252811.462101@fireball.kivinen.iki.fi> Date: Mon, 23 Jul 2012 12:19:39 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <3bb6591ee408288a9781c6574de15d5c.squirrel@www.trepanning.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> <92f255201e78f338cb9de9b6dec68204.squirrel@www.trepanning.net> <20491.64745.55358.539748@fireball.kivinen.iki.fi> <81E5B1E9-CB8C-4A61-B242-3A02D1C8E5EA@checkpoint.com> <3bb6591ee408288a9781c6574de15d5c.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 18 min Cc: "ipsec@ietf.org" , Johannes Merkle , Yoav Nir Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 09:21:18 -0000 Dan Harkins writes: > And this points out to another unfortunate design decision of > IKEv2. Instead of negotiating a fundamental cryptographic primitive > like a hash function, it negotiates a derivative construct like a > PRF. IKEv2 does not need hash function anywehere, and because of that it does not define it. Also there are PRFs which are not derived from the hash functions (PRF_AES128_XCBC and PRF_AES128_CMAC). It is much better to negotiate the algorithm you are using (i.e. MAC and PRF) instead of some other function which is not used anywhere directly, and which may or may not be used to derive other functions (hash). > So instead of being able to use the negotiated hash function to > compute an ECDSA signature we're forced to eat through the "scarce > resource" of the authentication method registry. Very clumsy, very > hackish, very unfortunate. I disagree it being clumsy or hackish or unfortunate. It is just one way of designing the system. Some peole do want to make sure there is no way to mix algorithms of different strength. I myself think this should be something that is restricted by policy, not by protocol, but some people do disagree that and design systems differently. It is not necessarely bad or good, it is just different. Also there is no reason why the ECDSA RFC could not have added a new transform type for HASH function, but it instead decided to use fixed hash functions for the curves (just like we do for DSA in the IKEv1, which always used SHA-1 as hash function when calculating signature, regardless what was negotiated in the SA payloads for HASH). I think RFC4754 aimed for the suite-B compatibility and it aimed to support ECDSA levels suitable for AES-128, AES-192, and AES-256, thus selecting matching EC groups and hash functions is what they decided to do: 5. Security Considerations ... ECDSA-256, ECDSA-384, and ECDSA-521 are designed to offer security comparable with the AES-128, AES-192, and AES-256 respectively. -- kivinen@iki.fi From Johannes.Merkle@secunet.com Mon Jul 23 04:32:05 2012 Return-Path: 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 F3FB421F86FF for ; Mon, 23 Jul 2012 04:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 pMWAF+zuGqcV for ; Mon, 23 Jul 2012 04:32:04 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 03AAB21F86C5 for ; Mon, 23 Jul 2012 04:32:03 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 216461A007F; Mon, 23 Jul 2012 13:30:30 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id E84251A007E; Mon, 23 Jul 2012 13:30:25 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jul 2012 13:31:56 +0200 Message-ID: <500D362C.4020501@secunet.com> Date: Mon, 23 Jul 2012 13:31:56 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Dan Harkins References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> In-Reply-To: <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2012 11:31:56.0938 (UTC) FILETIME=[C4467EA0:01CD68C6] Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:32:05 -0000 >> >> Hmm... so the EC domain parameters can be seen from the certificate? I >> wonder why did the RFC4753 then made separate allocations for each EC >> group? > > The particular curve can be determined from the subjectPublicKeyInfo. > Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool > curves. Actually, this is not strictly correct: ANSI X9.62 defies three ways to specify the curve (domain parameters) in a certificate (extracted from RFC 5480): ECParameters ::= CHOICE { namedCurve OBJECT IDENTIFIER implicitCurve NULL specifiedCurve SpecifiedECDomain } implicitCurve means that "the parameters are explicitly defined elsewhere". So we can safely assume that the parameters are available to a pier receiving the certificate of the other one. By the way: While RFC 5480 prohibits the use of implicitCurve and specifiedCurve, there are certainly still many implementations of RFC 3279 out there which allowed all three methods. > > I'm not so sure it makes sense to define a new hash algorithm per curve > though. I would suggest just using the negotiated hash function. That is > going to be used for key derivation and will influence the level of security > that the exchange affords. That is, if you define SHA-384 to use with > brainpoolP384r1 but the two sides end up using SHA-1 for key derivation > then I'm not sure what using SHA-384 for authentication is buying you. Others have already pointed out that the PRF does not need to be a hash function. But even if it had to, the requirements are different. For a digital signature, you need a hash function to be collision resistant, while for PRF you need good mixing properties and, in some circumstances, one-wayness. The requirements for a PRF are much easier to achieve, e.g. even MD5 is still considered one-way and has good mixing properties, while collisions have been found. > > [snip] >> >> I think the way forward is to take this WG and as whether WG would be >> willing to recharter and add new items to its charter: >> >> 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be >> done as individual draft, and does not need to be WG item, but if >> we are doing the rest in WG then I think this should also be WG >> item too). I am not sure. If the rest is not specific for the Brainpool curves (e.g. defining a generic ECDSA auth method) it is not so clear that both efforts should be bundled. >> 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) >> in the IKEv2. This may require new standard track RFC defining new >> generic ECDSA method, and might also need solutions how hash >> function is selected for each group. According to the policy of the IANA registry for ath methods, standard track is not required but only IETF consensus, i.e. an informational WG document would suffice. > If we're gonna recharter, maybe we should just work on an IKEv3 because > the problems in IKEv2 are becoming apparent. This "new authentication mode" > suggestion, or the need for a "generic ECDSA" algorithm are just hacks that > should not be necessary for a properly defined protocol. In addition, the I do not agree. The generic definition of the ECDSA auth method is analogous to the auth methods defined for RSA and DSA keys, and thus, is rather the proper (canonical) way to define it than a hack. Of course, the fact than there are already 3 specific auth methods for ECDSA (which are not canonically defined) makes specification of a generic ECDSA method more cumbersome. > issues with the incorrect definition of representation of the result of an > ECDH (it's the x-coordinate, not the concatenation of the x- and > y-coordinates) that's lead to interoperability issues, and the inability to > handle point compression all lead one to the conclusion that this stuff > should all be fixed once and for all and fixed cleanly. > > Dan. > > Johannes From Johannes.Merkle@secunet.com Mon Jul 23 04:57:21 2012 Return-Path: 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 902D721F8683 for ; Mon, 23 Jul 2012 04:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 1ntMWg2PF3tk for ; Mon, 23 Jul 2012 04:57:20 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 83C8E21F8535 for ; Mon, 23 Jul 2012 04:57:20 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 69B241A0075; Mon, 23 Jul 2012 13:55:48 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id D4C9A1A006F; Mon, 23 Jul 2012 13:55:46 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jul 2012 13:57:18 +0200 Message-ID: <500D3C1D.6050904@secunet.com> Date: Mon, 23 Jul 2012 13:57:17 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Tero Kivinen References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> In-Reply-To: <20490.53579.25865.193739@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2012 11:57:18.0088 (UTC) FILETIME=[4EF39080:01CD68CA] Cc: ipsec@ietf.org Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 11:57:21 -0000 > Hmm... so the EC domain parameters can be seen from the certificate? I > wonder why did the RFC4753 then made separate allocations for each EC > group? As I wrote to Dan, there is actually also the option of not specifying the parameters in the cert, but this method (implicitCurve) is supposed to be used only if the parameters are known to the other pier by other means (e.g. by local configuration) > >>> I think we should have made the ECDSA support for IKEv2 in such way >>> that we had added some subfields to the authentication field, i.e. >>> only allocated one value for ECDSA and put the curve number inside the >>> authentication payload and perhaps even separated the hash algorithm >>> from it. There is 3 bytes of reserved data in the authentication >>> payload immediately after the auth method. Perhaps we could use those. >> >> Adding hash algorithm flexibility is of course a more general topic >> concerning not only ECDSA but also RSA and DSA. This is out-of-scope >> of our endeavor and should be discussed separately. > > We already have this same problem in the RSA, and we do assume that it > is not a problem in real life. I.e. every implementation will use hash > algorithm that is supported by other end. I.e. if some impementation > is SHA-1 only then certificates are also SHA-1 only and everybody uses > SHA-1, and if certificates uses SHA-2, then everybody using those > certificates do support both SHA-1 and SHA-2, and it does not really > matter which hash function is used... This is the reason why we do not Even if the pier supports both SHA-1 and all SHA-2 functions, it would require try-and-error to find out which one was used for the signature. Maybe in most cases the tier uses the same hash function as the CA, but this does not need to be the case. I know of large-scale PKIs, where the CAs use longer hash functions than the end entities. This can be motivated by the (indisputably) higher security requirements for CAs than for end users. >> You touch the same point as Yoav, who pointed out that a generalized >> authentication method (e.g. ECDSA_generic) would imply that the same >> certificate (for a key pair using one of the NIST curves listed in >> RFC 4754) could be used ith two different authentication methods. >> Yoav has suggested to indicate support for the general method in the >> Notify payload, another option could be to introduce a new transform >> type AUTH, so that support for this AUTH method is indicated in the >> SA payload. Again, this is a protocol extension that exceeds our >> intended scope, and should be specified separately. >> >> An alternative to avoid the interoperability problems with existing >> implementations of RFC 4754 could be to require that ECDSA_generic >> MUST not be used for the curves listed in RFC 4754, or that >> implementations encountering authentication failures by the other >> peer MUST re-try using the "old" authentication methods from RFC >> 4754. > > I think the way forward is to take this WG and as whether WG would be > willing to recharter and add new items to its charter: Accidentally, I included by response to this in my reply to Dan. For completeness, I will repeat it here. > > 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be > done as individual draft, and does not need to be WG item, but if > we are doing the rest in WG then I think this should also be WG > item too). I am not sure. If the rest is not specific for the Brainpool curves (e.g. defining a generic ECDSA auth method) it is not so clear that both efforts should be bundled. > 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) > in the IKEv2. This may require new standard track RFC defining new > generic ECDSA method, and might also need solutions how hash > function is selected for each group. > According to the policy of the IANA registry for ath methods, standard track is not required but only IETF consensus, i.e. an informational WG document would suffice. > Then we can start thinking in the WG what would be the best way to > solve those problems. I think the correct solution would be to make > new ECDSA_generic method and specify where the domain parameters come > (both with certificates and with raw public keys), and we might want >From a cryptographic point of view, the correctness (and hence, the integrity and authenticity) of the domain parameters is crucial, it is not a restriction to require that, if a raw (trusted) EC public key is used, the parameters must also be available by trusted means (e.g. local configuration). Johannes From turners@ieca.com Mon Jul 23 05:57:41 2012 Return-Path: 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 AB90B11E8085 for ; Mon, 23 Jul 2012 05:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.432 X-Spam-Level: X-Spam-Status: No, score=-102.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3SgT2+XWneUC for ; Mon, 23 Jul 2012 05:57:40 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [70.85.130.16]) by ietfa.amsl.com (Postfix) with ESMTP id B27AD11E807F for ; Mon, 23 Jul 2012 05:57:40 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id C1834BC8EA05F; Mon, 23 Jul 2012 07:57:40 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 919BABC8E9FAA for ; Mon, 23 Jul 2012 07:57:40 -0500 (CDT) Received: from [71.191.15.186] (port=35165 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1StICg-0002fY-9U; Mon, 23 Jul 2012 07:57:38 -0500 Message-ID: <500D4A41.5090601@ieca.com> Date: Mon, 23 Jul 2012 08:57:37 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Johannes Merkle References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <93213A99-17A9-44C6-97A4-F910AE789872@checkpoint.com> <5007E4C3.4080803@secunet.com> <50093D47.90500@secunet.com> In-Reply-To: <50093D47.90500@secunet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [71.191.15.186]:35165 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "ipsec@ietf.org" , "Biester, Jobst" , Yoav Nir , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 12:57:41 -0000 On 7/20/12 7:13 AM, Johannes Merkle wrote: > Yoav, > >> As Tero said, the signature algorithms can be specified in the 3 reserved bytes, but support for such things should be indicated in the Notify payload. > > Yes, I agree. > >> How about standardizing just one more authentication method? >> >> Call it "public key signature" or some such, and make the signing algorithm depend on the public key in the CERT payload. >> > > After sleeping on your idea, I realize that it may work very well for ECDSA. The main problem with elliptic curve > signature schemes is that there are so many different domain parameters. Tero has pointed out that the authentication > methods registry for IKEv2 is only 8-bit, limiting the number of assignable methods. On the other hand, the domain > parameters are specified in the subject public key info in the certificate, either explicitly (listing all parameters) > or by reference (registered OID). > > Thus, it is possible to define an authentication method ECDSA_generic where the domain parameters are read from the > certificate. One code point for an unlimited number of domain parameters. Just thought I'd point out here that in RFC 5480 the only option is namedCurve (i.e., OIDs). But, the brainpool curves all have OIDs assigned in RFC 5639. > For the hash function to be used, there are several options: > 1. An RFC could specify the default for each domain parameter set, e.g. SHA-256 for Brainpool Curve p-256. > 2. Alternatively or a means to override the default setting, a hash algo ID could be encoded in the 3 reserved bytes in > the authentication payload > 3. Since the authentication payload has variable length, it could also include a leading byte specifying the hash > algorithm. Of course, this contradicts the current specification of the ECDSA authentication payload from RFC4754, but > RFC4754 specifies the encoding only for the specific NIST curves ECDSA authentication methods defined therein. > > Johannes > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Mon Jul 23 10:39:28 2012 Return-Path: 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 1879111E80C8 for ; Mon, 23 Jul 2012 10:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 b5nk+90xyWQD for ; Mon, 23 Jul 2012 10:39:27 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 5529211E807F for ; Mon, 23 Jul 2012 10:39:27 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3711310224008; Mon, 23 Jul 2012 10:39:26 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 23 Jul 2012 10:39:26 -0700 (PDT) Message-ID: <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> In-Reply-To: <500D362C.4020501@secunet.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> Date: Mon, 23 Jul 2012 10:39:26 -0700 (PDT) From: "Dan Harkins" To: "Johannes Merkle" 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 Cc: ipsec@ietf.org, Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 17:39:28 -0000 On Mon, July 23, 2012 4:31 am, Johannes Merkle wrote: >> >> The particular curve can be determined from the subjectPublicKeyInfo. >> Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool >> curves. > > Actually, this is not strictly correct: > ANSI X9.62 defies three ways to specify the curve (domain parameters) in a > certificate (extracted from RFC 5480): > ECParameters ::= CHOICE { > namedCurve OBJECT IDENTIFIER > implicitCurve NULL > specifiedCurve SpecifiedECDomain > } > implicitCurve means that "the parameters are explicitly defined > elsewhere". > > So we can safely assume that the parameters are available to a pier > receiving the certificate of the other one. > > > By the way: While RFC 5480 prohibits the use of implicitCurve and > specifiedCurve, there are certainly still many > implementations of RFC 3279 out there which allowed all three methods. For a guy who's always reminding everyone about how there are many implementations of an older RFC I should keep that in mind. Thank you for pointing that out. But, as you note, RFC 5480 prohibits implicitCurve and specificCurve so all we have left is namedCurve which is, as I noted, how the particular curve can be determined from the subjectPublicKeyInfo. >> If we're gonna recharter, maybe we should just work on an IKEv3 >> because >> the problems in IKEv2 are becoming apparent. This "new authentication >> mode" >> suggestion, or the need for a "generic ECDSA" algorithm are just hacks >> that >> should not be necessary for a properly defined protocol. In addition, >> the > > I do not agree. The generic definition of the ECDSA auth method is > analogous to the auth methods defined for RSA and DSA > keys, and thus, is rather the proper (canonical) way to define it than a > hack. > Of course, the fact than there are already 3 specific auth methods for > ECDSA (which are not canonically defined) makes > specification of a generic ECDSA method more cumbersome. With RSA the hash algorithm is encoded into the padding so there is no real need to independently agree on a hash algorithm. For DSA, I disagree. The DSA algorithm definition is hash-specific so the hash- specific ECDSA auth methods are the canonical way. Let me point out, though, that canon law is not necessarily correct and this is an example. FIPS 186-3 (The Digital Signature Algorithm) specifies that security strength levels of DSA are a minimum of the security strength of the hash algorithm and the (L,N) pair from the domain parameter set. If one wished to achieve a security strength level with DSA that would be valid, according to NIST, "beyond 2030" one would need to use SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature" (authentication method value of 3) so that wouldn't work. Given that SP 800-57 requires that 80 bits of strength only be used through 2010 (and SHA-1 does not provide more than that) and it is now 2012 it appears that IKEv2 is not capable of producing a signature of sufficient strength for certain customers (they might not be your's but they do exist, and there's probably more of them than there are people clamoring for AES-XCBC MAC). So to actually address this in the hash-specific canonical way requires new auth methods for different permutations of DSS with SHA-224, SHA-256, SHA-384, and SHA-512 as well as different permutations of ECDSA with brainpool curves using the 5 different SHA varients. But this is getting, as you say, "cumbersome". Of course one can decide not to use the hash-specific canonical technique and come up with "generic DSA" and "generic ECDSA" to address this but then we have the unfortunate state of hash-specific (EC)DSA methods and "generic" methods and now it's getting ugly (and hack-ish). Instead of either negotiating a complete ciphersuite (the way TLS does) or individual components (the way IKEv1 did), IKEv2 does both and gets the worst of both worlds. Dan. From dharkins@lounge.org Mon Jul 23 11:01:45 2012 Return-Path: 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 97A9E11E80CE for ; Mon, 23 Jul 2012 11:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 hfcFTnL0Y1dQ for ; Mon, 23 Jul 2012 11:01:45 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFE811E8093 for ; Mon, 23 Jul 2012 11:01:45 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 407A110224008; Mon, 23 Jul 2012 11:01:44 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 23 Jul 2012 11:01:44 -0700 (PDT) Message-ID: In-Reply-To: <20493.5931.252811.462101@fireball.kivinen.iki.fi> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <01444706-1E43-4675-B919-BA0A1CADC076@checkpoint.com> <92f255201e78f338cb9de9b6dec68204.squirrel@www.trepanning.net> <20491.64745.55358.539748@fireball.kivinen.iki.fi> <81E5B1E9-CB8C-4A61-B242-3A02D1C8E5EA@checkpoint.com> <3bb6591ee408288a9781c6574de15d5c.squirrel@www.trepanning.net> <20493.5931.252811.462101@fireball.kivinen.iki.fi> Date: Mon, 23 Jul 2012 11:01:44 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" 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 Cc: "ipsec@ietf.org" , Johannes Merkle , Yoav Nir , Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 18:01:45 -0000 On Mon, July 23, 2012 2:19 am, Tero Kivinen wrote: > Dan Harkins writes: >> So instead of being able to use the negotiated hash function to >> compute an ECDSA signature we're forced to eat through the "scarce >> resource" of the authentication method registry. Very clumsy, very >> hackish, very unfortunate. > > I disagree it being clumsy or hackish or unfortunate. It is just one > way of designing the system. Some peole do want to make sure there is > no way to mix algorithms of different strength. I myself think this > should be something that is restricted by policy, not by protocol, but > some people do disagree that and design systems differently. It is not > necessarely bad or good, it is just different. So some people want to do it one way and other's want to do it a different way. What's hackish is to do both and that's what IKEv2 does. For (EC)DSA the hash algorithm to use is determined by the auth method (no way to mix algorithms) but the cipher and D-H group are not (something restricted by policy). Doing it one way or the other might not necessarily be good or bad but doing it both is. > Also there is no reason why the ECDSA RFC could not have added a new > transform type for HASH function, but it instead decided to use fixed > hash functions for the curves (just like we do for DSA in the IKEv1, > which always used SHA-1 as hash function when calculating signature, > regardless what was negotiated in the SA payloads for HASH). And in IKEv2 you got rid of the hash negotiation but retained the SHA-1 only nature of DSA regardless of the PRF being negotiated. Section 3.8 of RFC 5996 says: "DSS Digital Signature 3 Computed as specified in Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash." Dan. From Johannes.Merkle@secunet.com Mon Jul 23 12:16:04 2012 Return-Path: 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 B1D5721F8472 for ; Mon, 23 Jul 2012 12:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 FL-5+MjAg-UZ for ; Mon, 23 Jul 2012 12:16:04 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFCA21F844E for ; Mon, 23 Jul 2012 12:16:03 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 38AF71A0075; Mon, 23 Jul 2012 21:15:58 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id BD92F1A006C; Mon, 23 Jul 2012 21:15:52 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Jul 2012 21:15:55 +0200 Message-ID: <500DA2EB.209@secunet.com> Date: Mon, 23 Jul 2012 21:15:55 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Dan Harkins References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> In-Reply-To: <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2012 19:15:55.0450 (UTC) FILETIME=[955251A0:01CD6907] Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 19:16:04 -0000 >>> If we're gonna recharter, maybe we should just work on an IKEv3 >>> because >>> the problems in IKEv2 are becoming apparent. This "new authentication >>> mode" >>> suggestion, or the need for a "generic ECDSA" algorithm are just hacks >>> that >>> should not be necessary for a properly defined protocol. In addition, >>> the >> >> I do not agree. The generic definition of the ECDSA auth method is >> analogous to the auth methods defined for RSA and DSA >> keys, and thus, is rather the proper (canonical) way to define it than a >> hack. >> Of course, the fact than there are already 3 specific auth methods for >> ECDSA (which are not canonically defined) makes >> specification of a generic ECDSA method more cumbersome. > > With RSA the hash algorithm is encoded into the padding so there is > no real need to independently agree on a hash algorithm. For DSA, No, in RSA PKCS#1v1.5 padding (which is currently the only supported padding in IKEv2), the hash algorithm is *not* encoded in the padding. Only the length of the length of the hash value can be determined due to the reserved zero octet leading the hash value. For SHA-1 and the SHA-2 hash functions, the length also determines the function, so your assertion in in some way true for these functions. However, RFC 5996 does not restrict the hash function to these. As soon as one of the SHA-3 contributions is used, the function can not be determined from the padding, as SHA-3 contributions were required support 224, 256, 384, and 512-bit message digests, exactly the lengths generated by the SHA-2 functions. > I disagree. The DSA algorithm definition is hash-specific so the hash- > specific ECDSA auth methods are the canonical way. Let me point > out, though, that canon law is not necessarily correct and this is an > example. By generic ECDSA methods, I did not mean hash-independent but only curve-independent. At least for SHA-1/SHA-2, the mapping between size of the curve and hash function could be fixed in an RFC. The hash length shall not be smaller than the bit length of curve parameters (FIPS-186-3), and there is no need to choose an SHA-2 function longer than the minimum one meeting this requirement. As I said in an earlier message, adding hash algorithm flexibility is a more general topic concerning not only ECDSA. It probably requires much more than simply defining a new auth method and specifying a rule, which hash function to chose for which ECDSA bit length. > > FIPS 186-3 (The Digital Signature Algorithm) specifies that security > strength levels of DSA are a minimum of the security strength of the > hash algorithm and the (L,N) pair from the domain parameter set. If > one wished to achieve a security strength level with DSA that would > be valid, according to NIST, "beyond 2030" one would need to use > SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature" > (authentication method value of 3) so that wouldn't work. > > Given that SP 800-57 requires that 80 bits of strength only be used > through 2010 (and SHA-1 does not provide more than that) and it > is now 2012 it appears that IKEv2 is not capable of producing a > signature of sufficient strength for certain customers (they might not > be your's but they do exist, and there's probably more of them than > there are people clamoring for AES-XCBC MAC). > This is definitely an issue when using DSA with IKEv2, and I do not doubt that something should be done, but I don't think that this needs to be coupled with an effort to specify a curve-independent ECDSA auth method. > So to actually address this in the hash-specific canonical way > requires new auth methods for different permutations of DSS with > SHA-224, SHA-256, SHA-384, and SHA-512 as well as different > permutations of ECDSA with brainpool curves using the 5 different > SHA varients. But this is getting, as you say, "cumbersome". > As said above, I don't see the need to allow, for instance, the Brainpool p256 curve to be used with any hash function other than SHA-256. > Of course one can decide not to use the hash-specific canonical > technique and come up with "generic DSA" and "generic ECDSA" to > address this but then we have the unfortunate state of hash-specific > (EC)DSA methods and "generic" methods and now it's getting ugly > (and hack-ish). > Such a co-existence of different approaches would also be the case if a curve-independent (but hash-specific) ECDSA method was specified, and I agreee that this is a bit unfortunate. But this is not a major issue compared to alternative of specifying separate methods for each curve in an 8 bit registry. > Instead of either negotiating a complete ciphersuite (the way TLS > does) or individual components (the way IKEv1 did), IKEv2 does both > and gets the worst of both worlds. > Means to negotiate the hash function could be specified as discussed earlier in this thread, but of course this is a more significant change. And I am not sure if this is necessary, given the clear recommendations of FIPS 186-3. Johannes > Dan. > > > > From sfluhrer@cisco.com Mon Jul 23 13:15:14 2012 Return-Path: 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 4161811E808A for ; Mon, 23 Jul 2012 13:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 EVWjtPFTfN4N for ; Mon, 23 Jul 2012 13:15:11 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id BD75A11E807F for ; Mon, 23 Jul 2012 13:15:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sfluhrer@cisco.com; l=2665; q=dns/txt; s=iport; t=1343074511; x=1344284111; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Qa2Rwff/a/cI2UshUzVw6KIcXE+szguEIvGPZhvH2Ps=; b=jUSpI4XSi4eUerjGiW+XB06Lt6ePeAf2rmy6zX/RqBobl/aPs9d7zvh2 3oIiUCGWZrJ1TlBm/YPI0PG8hGSj9kEdTl3M5dKegMzoo71RffPRKjN4V wpxTnAK0DacVoSxvYIOYsEngNb7JAnbShC6lth6KB1GZTdGujrhCX9lsn s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOyvDVCtJV2Y/2dsb2JhbABFuV+BB4IgAQEBBBIBJz8MBAIBCBEEAQELFAkHMhQJCAIEAQ0FCBqHa5wnn3+LTYVzYAOjcIFmgl8 X-IronPort-AV: E=Sophos;i="4.77,640,1336348800"; d="scan'208";a="104550581" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 23 Jul 2012 20:15:11 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6NKFBVS006975 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Jul 2012 20:15:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Mon, 23 Jul 2012 15:15:11 -0500 From: "Scott Fluhrer (sfluhrer)" To: Johannes Merkle , Dan Harkins Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: AQHNZpOb9clt6S/TCkq27t8USi0SLpc0OZaAgAAIz4CAAtHMAIAAZq4AgAAa9YD//7WUwA== Date: Mon, 23 Jul 2012 20:15:10 +0000 Message-ID: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> In-Reply-To: <500DA2EB.209@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.83] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19060.001 x-tm-as-result: No--20.837200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 20:15:14 -0000 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of J= ohannes Merkle Sent: Monday, July 23, 2012 3:16 PM To: Dan Harkins Cc: ipsec@ietf.org; Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec >>=20 >> With RSA the hash algorithm is encoded into the padding so there is >> no real need to independently agree on a hash algorithm. > > No, in RSA PKCS#1v1.5 padding (which is currently the only supported > padding in IKEv2), the hash algorithm is *not* encoded in the padding. > Only the length of the length of the hash value can be determined due > to the reserved zero octet leading the hash value. For SHA-1 and the > SHA-2 hash functions, the length also determines the function, so your > assertion in in some way true for these functions. However, RFC 5996 > does not restrict the hash function to these. As soon as one of the > SHA-3 contributions is used, the function can not be determined from > the padding, as SHA-3 contributions were required support 224, 256, > 384, and 512-bit message digests, exactly the lengths generated by the > SHA-2 functions. Actually, the hash type is indeed encoded in the signature in PKCS#1v1.5, a= ka RSASSA-PKCS1-v1_5; refer to the PKCS #1 version 2.1 or to RFC3447, secti= on A.2.4 for both documents. To summarize, when using PKCS#1v1.5, the padded message is of the format: 00 02 FF FF FF FF ... FF 00 (where there are enough FF bytes to exactly fill the RSA block). The byte string I marked as is a string that depends on the hash algo= rithm used; for SHA-256, it is: 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 For SHA-1, it is: 30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 And there are other OIDs for a number of other hash functions. This OID (w= hen concatenated with the hash) is a DER string the means "The result of is ". And, yes, a signature verifier can use this OID = string to figure out which hash function to use (by running the RSA public = operation on the signature, looking through the resulting block, checking w= hich OID it lists, and then running the appropriate hash on the data). When SHA-3 comes out, they'll just allocate more OIDs (if they haven't alre= ady) to denote the various sizes of SHA-3; no confusion between SHA-256 and= SHA-3-256 will be necessary. Perhaps you have this confused with signatures in IKEv1; there, they do som= ething nonstandard and don't include the OID (possibly because they are not= actually using the hash function, but instead the HMAC version). From dharkins@lounge.org Mon Jul 23 15:22:36 2012 Return-Path: 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 3787E11E80DE for ; Mon, 23 Jul 2012 15:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 jUuVCB9BiA2b for ; Mon, 23 Jul 2012 15:22:35 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6D56E11E80BE for ; Mon, 23 Jul 2012 15:22:35 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E003310224008; Mon, 23 Jul 2012 15:22:34 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 23 Jul 2012 15:22:35 -0700 (PDT) Message-ID: <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> In-Reply-To: <500DA2EB.209@secunet.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> Date: Mon, 23 Jul 2012 15:22:35 -0700 (PDT) From: "Dan Harkins" To: "Johannes Merkle" 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 Cc: ipsec@ietf.org, Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 22:22:36 -0000 On Mon, July 23, 2012 12:15 pm, Johannes Merkle wrote: >>>> If we're gonna recharter, maybe we should just work on an IKEv3 >>>> because >>>> the problems in IKEv2 are becoming apparent. This "new authentication >>>> mode" >>>> suggestion, or the need for a "generic ECDSA" algorithm are just hacks >>>> that >>>> should not be necessary for a properly defined protocol. In addition, >>>> the >>> >>> I do not agree. The generic definition of the ECDSA auth method is >>> analogous to the auth methods defined for RSA and DSA >>> keys, and thus, is rather the proper (canonical) way to define it than >>> a >>> hack. >>> Of course, the fact than there are already 3 specific auth methods for >>> ECDSA (which are not canonically defined) makes >>> specification of a generic ECDSA method more cumbersome. >> >> With RSA the hash algorithm is encoded into the padding so there is >> no real need to independently agree on a hash algorithm. For DSA, > > No, in RSA PKCS#1v1.5 padding (which is currently the only supported > padding in IKEv2), the hash algorithm is *not* > encoded in the padding. Only the length of the length of the hash value > can be determined due to the reserved zero octet > leading the hash value. For SHA-1 and the SHA-2 hash functions, the length > also determines the function, so your > assertion in in some way true for these functions. However, RFC 5996 does > not restrict the hash function to these. As > soon as one of the SHA-3 contributions is used, the function can not be > determined from the padding, as SHA-3 > contributions were required support 224, 256, 384, and 512-bit message > digests, exactly the lengths generated by the > SHA-2 functions. I see that Scott Fluhrer has already responded to this; I agree with Scott. >> I disagree. The DSA algorithm definition is hash-specific so the hash- >> specific ECDSA auth methods are the canonical way. Let me point >> out, though, that canon law is not necessarily correct and this is an >> example. > > By generic ECDSA methods, I did not mean hash-independent but only > curve-independent. > > At least for SHA-1/SHA-2, the mapping between size of the curve and hash > function could be fixed in an RFC. The hash > length shall not be smaller than the bit length of curve parameters > (FIPS-186-3), and there is no need to choose an > SHA-2 function longer than the minimum one meeting this requirement. If the mapping between curve and hash function is fixed then I don't see what you mean by "not hash-independent but only curve-independent". Seems that there is nothing independent, it's all fixed. >> So to actually address this in the hash-specific canonical way >> requires new auth methods for different permutations of DSS with >> SHA-224, SHA-256, SHA-384, and SHA-512 as well as different >> permutations of ECDSA with brainpool curves using the 5 different >> SHA varients. But this is getting, as you say, "cumbersome". >> > As said above, I don't see the need to allow, for instance, the Brainpool > p256 curve to be used with any hash function > other than SHA-256. And there are 7 new brainpool curves so that's 7 new auth methods plus 4 new ones to deal with the non-EC version of DSA for a total of 11 new auth methods to go along with the existing 4. 15 different auth methods just for the digital signature standard! >> Of course one can decide not to use the hash-specific canonical >> technique and come up with "generic DSA" and "generic ECDSA" to >> address this but then we have the unfortunate state of hash-specific >> (EC)DSA methods and "generic" methods and now it's getting ugly >> (and hack-ish). >> > Such a co-existence of different approaches would also be the case if a > curve-independent (but hash-specific) ECDSA > method was specified, and I agreee that this is a bit unfortunate. But > this is not a major issue compared to alternative > of specifying separate methods for each curve in an 8 bit registry. Yes, it is unfortunate. What's also unfortunate is that the 11 auth methods mentioned above (plus the 3 existing ECDSA auth methods) will probably have to be duplicated for SHA-3 thereby eating into this "scarce resource" of an 8-bit registry even further. >> Instead of either negotiating a complete ciphersuite (the way TLS >> does) or individual components (the way IKEv1 did), IKEv2 does both >> and gets the worst of both worlds. >> > > Means to negotiate the hash function could be specified as discussed > earlier in this thread, but of course this is a > more significant change. And I am not sure if this is necessary, given the > clear recommendations of FIPS 186-3. I am not advocating the mixing-and-matching of curves and hash functions of different security levels (and therefore one could argue to fix them) but it should be noted that IKEv2 allows all sorts of mixing and matching of ciphers, hash algorithms, and D-H groups of different security levels to be negotiated-- AES-256 with the 768-bit DH group authenticated with ECDSA using NISTP384 with SHA-384 and key derivation using SHA-1. Why would someone do this? I have no idea. Can someone? Yes. Is there a reason to enforce a "no mix-and-match" policy on some primitives and a "laissez faire negotiation" policy on others? No, at least not a good one. The point is, that the IKEv2 design was quite myopic-- if there are to be different permutations of curve-hash as separate auth methods then it shouldn't have been made a "scarce resource" of an 8-bit registry. You're right that fixing all this stuff that you describe as "cumbersome" and "unfortunate" would be "a more significant change". I think it might be worth trying and given the poor adoption of IKEv2 now's the time to fix it with IKEv3 before it's too late. Dan. From turners@ieca.com Mon Jul 23 21:21:50 2012 Return-Path: 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 DDB5A11E8109 for ; Mon, 23 Jul 2012 21:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.342 X-Spam-Level: X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 5RsvfI3qI2RA for ; Mon, 23 Jul 2012 21:21:50 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.37.25]) by ietfa.amsl.com (Postfix) with ESMTP id AAF1511E8108 for ; Mon, 23 Jul 2012 21:21:50 -0700 (PDT) Received: by gateway03.websitewelcome.com (Postfix, from userid 5007) id 33254C67DAFA7; Mon, 23 Jul 2012 23:21:51 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway03.websitewelcome.com (Postfix) with ESMTP id 286DBC67DAF74 for ; Mon, 23 Jul 2012 23:21:51 -0500 (CDT) Received: from [71.191.15.186] (port=41121 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1StWd4-0002zw-17 for ipsec@ietf.org; Mon, 23 Jul 2012 23:21:50 -0500 Message-ID: <500E22DD.1080906@ieca.com> Date: Tue, 24 Jul 2012 00:21:49 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <078c01cd68ef$b35643e0$1a02cba0$@iab.org> In-Reply-To: <078c01cd68ef$b35643e0$1a02cba0$@iab.org> X-Forwarded-Message-Id: <078c01cd68ef$b35643e0$1a02cba0$@iab.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [71.191.15.186]:41121 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [IPsec] Fwd: IAB IPv6 privacy survey posted, response requested X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 04:21:51 -0000 In case you're not on the announce list. spt -------- Original Message -------- Subject: IAB IPv6 privacy survey posted, response requested Date: Mon, 23 Jul 2012 09:24:56 -0700 From: IAB Chair Reply-To: iab@iab.org Organization: Internet Architecture Board To: The IAB is working on Privacy Considerations for Internet Protocols . In order to better understand the implementation status of IPv6 privacy mechanisms in operating system stacks, those familiar with OS IPv6 implementations are asked tocomplete a short survey . The survey responses will be used in a detailed write-up on IPv6 privacy; privacy reviews of other IETF protocols are available here. Please send responses to iab-ipv6-privacy-survey@i1b.org by August 13, 2012. If you have questions, please send them to iab-ipv6-privacy-survey@i1b.org . From Johannes.Merkle@secunet.com Tue Jul 24 02:34:18 2012 Return-Path: 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 77F2621F85E0 for ; Tue, 24 Jul 2012 02:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 xzQiCh0bLZD0 for ; Tue, 24 Jul 2012 02:34:18 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 925F521F8619 for ; Tue, 24 Jul 2012 02:34:17 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id BB6C11A0078 for ; Tue, 24 Jul 2012 11:34:03 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 96E211A0075 for ; Tue, 24 Jul 2012 11:33:56 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jul 2012 11:34:07 +0200 Message-ID: <500E6C0E.4080806@secunet.com> Date: Tue, 24 Jul 2012 11:34:06 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2012 09:34:07.0717 (UTC) FILETIME=[791AB950:01CD697F] Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 09:34:18 -0000 >>> With RSA the hash algorithm is encoded into the padding so there is >>> no real need to independently agree on a hash algorithm. >> >> No, in RSA PKCS#1v1.5 padding (which is currently the only supported >> padding in IKEv2), the hash algorithm is *not* encoded in the padding. >> Only the length of the length of the hash value can be determined due >> to the reserved zero octet leading the hash value. For SHA-1 and the >> SHA-2 hash functions, the length also determines the function, so your >> assertion in in some way true for these functions. However, RFC 5996 >> does not restrict the hash function to these. As soon as one of the >> SHA-3 contributions is used, the function can not be determined from >> the padding, as SHA-3 contributions were required support 224, 256, >> 384, and 512-bit message digests, exactly the lengths generated by the >> SHA-2 functions. > > Actually, the hash type is indeed encoded in the signature in PKCS#1v1.5, aka RSASSA-PKCS1-v1_5; refer to the PKCS #1 version 2.1 or to RFC3447, section A.2.4 for both documents. > > To summarize, when using PKCS#1v1.5, the padded message is of the format: > 00 02 FF FF FF FF ... FF 00 > (where there are enough FF bytes to exactly fill the RSA block). > > The byte string I marked as is a string that depends on the hash algorithm used; for SHA-256, it is: > 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20 > Right, I was mistaken, I had looked into the padding scheme of the PKCS#1v1.5 encryption scheme not signature. Johannes From kivinen@iki.fi Tue Jul 24 03:17:26 2012 Return-Path: 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 E7E6321F8692 for ; Tue, 24 Jul 2012 03:17:26 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 x+HrlPwHD2bG for ; Tue, 24 Jul 2012 03:17:26 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6922721F8690 for ; Tue, 24 Jul 2012 03:17:25 -0700 (PDT) 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 q6OAG7hw027845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2012 13:16:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6OAG6Bg004413; Tue, 24 Jul 2012 13:16:06 +0300 (EEST) 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: <20494.30182.668465.949717@fireball.kivinen.iki.fi> Date: Tue, 24 Jul 2012 13:16:06 +0300 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <500D3C1D.6050904@secunet.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <500D3C1D.6050904@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 22 min X-Total-Time: 35 min Cc: ipsec@ietf.org Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 10:17:27 -0000 Johannes Merkle writes: > As I wrote to Dan, there is actually also the option of not > specifying the parameters in the cert, but this method > (implicitCurve) is supposed to be used only if the parameters are > known to the other pier by other means (e.g. by local configuration) So for IKEv2 use we can say that ECDSA MUST be used with certificates which give domain parameters in the certificate? That should solve the problem that we do not need separate auth methods for every different EC curve. > Even if the pier supports both SHA-1 and all SHA-2 functions, it > would require try-and-error to find out which one was used for the > signature. I now understand, when it was point out in some later emails, that in the ECDSA signatures there is no way to know the hash algorithm from the signature alone (compared to RSA, where is possible to extract the hash algorithm from signature). But there is still two different problems there. One is which hash algorithm to use, and another is how the other end knows which hash algorithm was used. There are multiple solutions to the problems. One solution to both of the problems would be to add new transform type for HASH algorithms and negotiate it. This would most likely be the cleanest way, but would require more changes than other solutions. Another option is to use method like or RSA to select which hash algorithm to use, and encode the hash algorithm to the auth payload reserved bytes. Yet another option is to specify the mandatory hash algorithm to be used for each specific curve, so hash function is known because of specific group is used. This is bit like what existing ECDSA groups are doing, i.e. each group defines hash function that must be used for it. This option does not require that every group will be given separate authentication method number. > > 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be > > done as individual draft, and does not need to be WG item, but if > > we are doing the rest in WG then I think this should also be WG > > item too). > I am not sure. If the rest is not specific for the Brainpool curves > (e.g. defining a generic ECDSA auth method) it is not so clear that > both efforts should be bundled. I do not think they need to be bundled. Thats why I proposed adding two separate charter items for them. I.e. this first step is something that can be done quickly and without any problems with just one informational RFC. I do not also expect there to be too much discussion whether this should be done or not, and how this should be done. > > 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) > > in the IKEv2. This may require new standard track RFC defining new > > generic ECDSA method, and might also need solutions how hash > > function is selected for each group. > > > According to the policy of the IANA registry for ath methods, > standard track is not required but only IETF consensus, > i.e. an informational WG document would suffice. Yes information draft would be enough, but if we are really making generic ECDSA method, then we most likely do want to also say what we are going to do for the old ECDSA methods. For example if we do want to say that those methods are NOT RECOMMENDED then we need to update the standard track document (RFC4754). Also at least I would prefer that this kind of generic work should be standard track document. > From a cryptographic point of view, the correctness (and hence, the > integrity and authenticity) of the domain parameters is crucial, it > is not a restriction to require that, if a raw (trusted) EC public > key is used, the parameters must also be available by trusted means > (e.g. local configuration). In my draft-kivinen-oob-pubkey-00.txt which adds raw EC public keys, we did plan to use SubjectPublicKeyInfo part of the PKIX certificate, thus that would have the domain parameters in there. The local configuration would then indicate whether that raw key is trusted or not. -- kivinen@iki.fi From kivinen@iki.fi Tue Jul 24 03:30:54 2012 Return-Path: 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 391EC21F8659 for ; Tue, 24 Jul 2012 03:30:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDNoUyF5c-ED for ; Tue, 24 Jul 2012 03:30:53 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F1421F867A for ; Tue, 24 Jul 2012 03:30:52 -0700 (PDT) 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 q6OATal9014595 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jul 2012 13:29:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6OATaUD007952; Tue, 24 Jul 2012 13:29:36 +0300 (EEST) 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: <20494.30991.820250.462623@fireball.kivinen.iki.fi> Date: Tue, 24 Jul 2012 13:29:35 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 13 min Cc: ipsec@ietf.org, Johannes Merkle Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 10:30:54 -0000 Dan Harkins writes: > FIPS 186-3 (The Digital Signature Algorithm) specifies that security > strength levels of DSA are a minimum of the security strength of the > hash algorithm and the (L,N) pair from the domain parameter set. If > one wished to achieve a security strength level with DSA that would > be valid, according to NIST, "beyond 2030" one would need to use > SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature" > (authentication method value of 3) so that wouldn't work. That SHA-1 text is leftover from the RFC4306 and from the IKEv1, i.e. when the only supported DSS was the one using SHA-1. The RFC5996 did update from the 1994 FIPS 186 to draft FIPS 186-3 but that comment about SHA-1 did not get removed. On the other hand I would expect most of the implementations ignore that comment, and go with the actual DSS documentation when using DSS signatures, and use the hashes defined in there. This is one of those cases where, when that text was added it seemed to help understanding the issue, as SHA-1 was the only allowed hash function for DSS, but with updated documents with later references, that comment came misleading but did not get removed.. > So to actually address this in the hash-specific canonical way > requires new auth methods for different permutations of DSS with > SHA-224, SHA-256, SHA-384, and SHA-512 as well as different > permutations of ECDSA with brainpool curves using the 5 different > SHA varients. But this is getting, as you say, "cumbersome". So you are saying that each DSS even with ECDSA do require to tell what hash function is used separately? I have assume that when I do get DSA public key in the certificate, and know the length of the DSA key, I can know which hash function is used when using that key? But if I am mistaken, then we might need to add extra DSS methods too (but lets not add them to IKEv1, as I do not want new modifications to IKEv1. IKEv1 does this same way than IKEv2 does, i.e. it assumes you know which hash function is used with DSS and ignores the negotiated hash function when using DSS). Note, that there is no MUSTs or anything like that in the RFC5996 saying you MUST use SHA-1, it is just statement that DSS as defined in year 1994 version used SHA-1. -- kivinen@iki.fi From Johannes.Merkle@secunet.com Tue Jul 24 04:17:13 2012 Return-Path: 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 BF57421F8670 for ; Tue, 24 Jul 2012 04:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 S9Ke2uwLKaPD for ; Tue, 24 Jul 2012 04:17:13 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 82D1321F864B for ; Tue, 24 Jul 2012 04:17:12 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 928C81A0075; Tue, 24 Jul 2012 13:16:59 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 27E021A006C; Tue, 24 Jul 2012 13:16:56 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jul 2012 13:17:07 +0200 Message-ID: <500E8433.7020002@secunet.com> Date: Tue, 24 Jul 2012 13:17:07 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Dan Harkins References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> In-Reply-To: <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2012 11:17:07.0975 (UTC) FILETIME=[DCD34170:01CD698D] Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 11:17:14 -0000 >> By generic ECDSA methods, I did not mean hash-independent but only >> curve-independent. >> >> At least for SHA-1/SHA-2, the mapping between size of the curve and hash >> function could be fixed in an RFC. The hash >> length shall not be smaller than the bit length of curve parameters >> (FIPS-186-3), and there is no need to choose an >> SHA-2 function longer than the minimum one meeting this requirement. > > If the mapping between curve and hash function is fixed then I don't > see what you mean by "not hash-independent but only curve-independent". > Seems that there is nothing independent, it's all fixed. I have the impression that we misunderstand each other. The solution that I propose is to define one new auth method ECDSA_generic which indicates that - the curve shall be taken from the certificate - the hash function shall be the minimum SHA-1/2 function matching or exceeding the security level of the curve. This method is flexible w.r.t the curve but not w.r.t the hash function, and that is what I called "not hash-independent but only curve-independent". Maybe the term "curve-flexible but not hash-flexible" is better. This approach is exactly the one followed for DSA (DSS Digital Signature), except that the latter one was limited to SHA-1. Thus, a curve-independent ECDSA method would be more consistent with the existing DSA method. This is the reason why I objected to your assertion of our approach being a "hack". But maybe you didn't refer to this approach at all? > >>> So to actually address this in the hash-specific canonical way >>> requires new auth methods for different permutations of DSS with >>> SHA-224, SHA-256, SHA-384, and SHA-512 as well as different >>> permutations of ECDSA with brainpool curves using the 5 different >>> SHA varients. But this is getting, as you say, "cumbersome". >>> >> As said above, I don't see the need to allow, for instance, the Brainpool >> p256 curve to be used with any hash function >> other than SHA-256. > > And there are 7 new brainpool curves so that's 7 new auth methods > plus 4 new ones to deal with the non-EC version of DSA for a total > of 11 new auth methods to go along with the existing 4. 15 different > auth methods just for the digital signature standard! > Not with the approach I proposed: there is only one method ECDSA_generic. Note, that for DSA (on EC), it would also be sufficient to specify a new auth method DSS_key_length_defined_hash accompanied with the requirement to choose the hash function as the smallest SHA-2 function meeting the minimum requirements of FIPS-186-3. >>> Of course one can decide not to use the hash-specific canonical >>> technique and come up with "generic DSA" and "generic ECDSA" to >>> address this but then we have the unfortunate state of hash-specific >>> (EC)DSA methods and "generic" methods and now it's getting ugly >>> (and hack-ish). >>> >> Such a co-existence of different approaches would also be the case if a >> curve-independent (but hash-specific) ECDSA >> method was specified, and I agreee that this is a bit unfortunate. But >> this is not a major issue compared to alternative >> of specifying separate methods for each curve in an 8 bit registry. > > Yes, it is unfortunate. What's also unfortunate is that the 11 auth > methods mentioned above (plus the 3 existing ECDSA auth methods) > will probably have to be duplicated for SHA-3 thereby eating into this > "scarce resource" of an 8-bit registry even further. We have the choice: Either spending many assignments out of the 256 available, or to specify a generic auth method deviating from the approach previously tken for ECDSA (but being in accordance with the approach taken for DSA). > >>> Instead of either negotiating a complete ciphersuite (the way TLS >>> does) or individual components (the way IKEv1 did), IKEv2 does both >>> and gets the worst of both worlds. >>> >> >> Means to negotiate the hash function could be specified as discussed >> earlier in this thread, but of course this is a >> more significant change. And I am not sure if this is necessary, given the >> clear recommendations of FIPS 186-3. > > I am not advocating the mixing-and-matching of curves and hash > functions of different security levels (and therefore one could argue > to fix them) but it should be noted that IKEv2 allows all sorts of mixing > and matching of ciphers, hash algorithms, and D-H groups of different > security levels to be negotiated-- AES-256 with the 768-bit DH group > authenticated with ECDSA using NISTP384 with SHA-384 and key > derivation using SHA-1. Why would someone do this? I have no idea. > Can someone? Yes. Is there a reason to enforce a "no mix-and-match" > policy on some primitives and a "laissez faire negotiation" policy on > others? No, at least not a good one. > I assume, the reason why the hash function is not negotiated is that at the time IKEv2 was specified there was mainly one hash function giving adequate security in practical use. > The point is, that the IKEv2 design was quite myopic-- if there are > to be different permutations of curve-hash as separate auth methods > then it shouldn't have been made a "scarce resource" of an 8-bit > registry. You're right that fixing all this stuff that you describe as > "cumbersome" and "unfortunate" would be "a more significant > change". I think it might be worth trying and given the poor adoption > of IKEv2 now's the time to fix it with IKEv3 before it's too late. > I doubt that you can get a WG consensus on doing this. I am more interested in a short term solution, and for this I am prepared to do without hash-flexibility. Johannes From yaronf.ietf@gmail.com Tue Jul 24 09:08:32 2012 Return-Path: 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 E2BB321F867E for ; Tue, 24 Jul 2012 09:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 8KHvYxNYDh9F for ; Tue, 24 Jul 2012 09:08:31 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA8F321F8669 for ; Tue, 24 Jul 2012 09:08:30 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so4958528wgb.13 for ; Tue, 24 Jul 2012 09:08:29 -0700 (PDT) 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:subject :content-type:content-transfer-encoding; bh=sZF0mm803n95Dz5nUc4brUO3rYXBK2kPtMOpvHg2vng=; b=pGr3noEVh47RAkGJGerY9/zXs2SRqwskGEeJ6LOSQJGHjVTH6AnaOcUG8LjDKZ1sU2 zg03hPtdKBBMsOLYwVIW5737AjJOxln9sZ5xN94CzxcAoxQE+hiuLiSF2hDH9auOkLp1 R2zKuYeC9tRmQAq9FukFF+4IjXUnfaLOCgBcbR+pJg0Ka+2MuSafsdW2arqrjZE0Oj7B fbAkRTuYgBUjefE/S/WFkE1X8I1CHhJYeQNTR1MqN3Pm91hyaeogOS46yq2kRVE3eTgE W37R6C+AegKuiHTnwohbBJThh9UIYfRAnwW89ML/kl3L184JLk1wFRJNOJUvf4iK3OX/ BKXQ== Received: by 10.180.78.35 with SMTP id y3mr8209796wiw.16.1343146109623; Tue, 24 Jul 2012 09:08:29 -0700 (PDT) Received: from [192.168.7.200] (93-173-131-118.bb.netvision.net.il. [93.173.131.118]) by mx.google.com with ESMTPS id 8sm285352eeg.16.2012.07.24.09.08.27 (version=SSLv3 cipher=OTHER); Tue, 24 Jul 2012 09:08:28 -0700 (PDT) Message-ID: <500EC87A.5020106@gmail.com> Date: Tue, 24 Jul 2012 19:08:26 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 16:08:32 -0000 Hi, recent discussion on the list has indicated that there is some interest in better supporting ECDSA certificates in IKEv2, and that the existing solutions are not very extensible. The discussion was very useful in outlining the existing issues and pointing to some possible ways forward. Paul and I would like to propose setting up a design team with the goal of proposing a long-term solution to this problem. Some of the attributes of a reasonable solution include: - Supports currently used and proposed ECDSA certificates. - Allows flexibility in defining EC domain parameters. - Allows flexibility in associating hash functions with EC groups. - Is not limited to 256 values - ECDH is out of scope. - Non-certificate authentication using raw public keys is out of scope, unless it is trivially supported by the proposal. The solution should be an extension to IKEv2, and should not break the protocol. Some of the ideas in http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be used as a starting point. Please respond to us privately or to the list, indicating if you would like to participate in the design team, or if you only support the effort and would be willing to review the ensuing I-D. Thanks, Yaron From dharkins@lounge.org Tue Jul 24 09:56:45 2012 Return-Path: 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 7D6EC21F861D for ; Tue, 24 Jul 2012 09:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 eCxy9a1RqGd9 for ; Tue, 24 Jul 2012 09:56:45 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E92D121F8619 for ; Tue, 24 Jul 2012 09:56:44 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6E35A10224008; Tue, 24 Jul 2012 09:56:44 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 24 Jul 2012 09:56:44 -0700 (PDT) Message-ID: In-Reply-To: <500E8433.7020002@secunet.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> Date: Tue, 24 Jul 2012 09:56:44 -0700 (PDT) From: "Dan Harkins" To: "Johannes Merkle" 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 Cc: ipsec@ietf.org, Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 16:56:45 -0000 On Tue, July 24, 2012 4:17 am, Johannes Merkle wrote: >> If the mapping between curve and hash function is fixed then I don't >> see what you mean by "not hash-independent but only curve-independent". >> Seems that there is nothing independent, it's all fixed. > > I have the impression that we misunderstand each other. The solution that > I propose is to define one new auth method > ECDSA_generic which indicates that > - the curve shall be taken from the certificate > - the hash function shall be the minimum SHA-1/2 function matching or > exceeding the security level of the curve. So the signer says "ECDSA_generic" and the curve is determined from the subjectPublicKeyInfo and one infers the correct SHA-1/2 algorithm from the curve. OK, so if the curve is the 320-bit brainpool curve then we always use SHA-384. Got it. >> And there are 7 new brainpool curves so that's 7 new auth methods >> plus 4 new ones to deal with the non-EC version of DSA for a total >> of 11 new auth methods to go along with the existing 4. 15 different >> auth methods just for the digital signature standard! >> > Not with the approach I proposed: there is only one method ECDSA_generic. > > Note, that for DSA (on EC), it would also be sufficient to specify a new > auth method DSS_key_length_defined_hash > accompanied with the requirement to choose the hash function as the > smallest SHA-2 function meeting the minimum > requirements of FIPS-186-3. Well FIPS 186-3 specifically refers to SP 800-57 for "information about the selection of the appropriate (L,N) pair in accordance with a desired security strength for a given time period for the generation of digital signatures." And SP 800-57 says that, for example, to produce a signature valid "beyond 2030" it requires a minimum of 128 bits of strength (table 4) and that when performing digital signatures of 128 bits of security the valid hash functions are SHA-256, SHA-384, and SHA-512. You want to restrict such signatures to SHA-256 so it's not really meeting the requirements of FIPS 186-3. >> Yes, it is unfortunate. What's also unfortunate is that the 11 auth >> methods mentioned above (plus the 3 existing ECDSA auth methods) >> will probably have to be duplicated for SHA-3 thereby eating into this >> "scarce resource" of an 8-bit registry even further. > > We have the choice: Either spending many assignments out of the 256 > available, or to specify a generic auth method > deviating from the approach previously tken for ECDSA (but being in > accordance with the approach taken for DSA). But the "generic ECDSA" does not solve the problem with SHA-3. As you said above, "the hash function shall be the minimum SHA-1/2 function matching or exceeding the security level of the curve." So how do you support SHA-3? I guess we could assign a bit (clear=SHA-1/2, set = SHA-3) but that's getting pretty hackish. Or we could have 2 "generic ECDSA", one for SHA-1/2 and another for SHA-3. Yuck. If only this protocol was designed better.... Dan. From dharkins@lounge.org Tue Jul 24 10:43:42 2012 Return-Path: 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 71D3D11E80A4 for ; Tue, 24 Jul 2012 10:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 xKw92Vp8oTKh for ; Tue, 24 Jul 2012 10:43:40 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id C17D411E80A3 for ; Tue, 24 Jul 2012 10:43:40 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 0517410224008; Tue, 24 Jul 2012 10:43:34 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 24 Jul 2012 10:43:35 -0700 (PDT) Message-ID: <3bbf0a5eb1d27ea493210aae7782ee85.squirrel@www.trepanning.net> In-Reply-To: <500EC87A.5020106@gmail.com> References: <500EC87A.5020106@gmail.com> Date: Tue, 24 Jul 2012 10:43:35 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" 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 Cc: IPsecme WG Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 17:43:42 -0000 Hello, I would like to participate. The problem I see is that the selection of the hash algorithm has to be decoupled from the indication of the authentication method. So I propose the following: 1. Determining the Domain Parameter Set The curve SHALL be identified by name in the subjectPublicKeyInfo of the certificate or raw public key. 2. Determining the hash algorithm Use some of the RESERVED bits of the AUTH payload to define a "hash algorithm." I propose using 16 bits and making it align for shorts so use bits 16-31 and leave 8-15 as RESERVED. Then we should specify that the value of "hash algorithm" SHALL be zero except for the following new Auth Method: 13: Elliptic Curve Digital Signature Algorithm and the value of "hash algorithm" will come out of a new registry created by IANA whose initial population will be: - 1 : SHA-1 - 2 : SHA-224 - 3 : SHA-256 - 4 : SHA-384 - 5 : SHA-512 This has a number of benefits: - it will work for raw public keys (as Tero is proposing) as well as certified ECDSA keys. - it will allow for growth too because when SHA-3 algorithms get defined they can just further populate the new registry and we can unambiguously identify the hash algorithm regardless of the expected digest size or the curve. - we can support more of the FIPS 186-3 options where a hash producing a larger digest than the curve's prime is being used. - it doesn't consume a scarce resource unnecessarily. - the same approach could be used to fix non-EC DSA which I believe is still broken (just define another "generic DSA" auth method and use the hash registry this proposal creates). There remains an open question about what to do with the existing ECDSA curves and I suggest nothing. There will technically be two ways to do a NIST P256 signature using SHA-256 (ditto for 384/384 and 521/512). No big deal. Dan. On Tue, July 24, 2012 9:08 am, Yaron Sheffer wrote: > Hi, > recent discussion on the list has indicated that there is some interest > in better supporting ECDSA certificates in IKEv2, and that the existing > solutions are not very extensible. The discussion was very useful in > outlining the existing issues and pointing to some possible ways forward. > > Paul and I would like to propose setting up a design team with the goal > of proposing a long-term solution to this problem. Some of the > attributes of a reasonable solution include: > > - Supports currently used and proposed ECDSA certificates. > - Allows flexibility in defining EC domain parameters. > - Allows flexibility in associating hash functions with EC groups. > - Is not limited to 256 values > - ECDH is out of scope. > - Non-certificate authentication using raw public keys is out of scope, > unless it is trivially supported by the proposal. > > The solution should be an extension to IKEv2, and should not break the > protocol. Some of the ideas in > http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be > used as a starting point. > > Please respond to us privately or to the list, indicating if you would > like to participate in the design team, or if you only support the > effort and would be willing to review the ensuing I-D. > > Thanks, > Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From ynir@checkpoint.com Tue Jul 24 11:04:45 2012 Return-Path: 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 0984421F8611 for ; Tue, 24 Jul 2012 11:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.365 X-Spam-Level: X-Spam-Status: No, score=-10.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bMRSy7IinIVM for ; Tue, 24 Jul 2012 11:04:44 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 09FD221F8610 for ; Tue, 24 Jul 2012 11:04:43 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6OI4eCj003377; Tue, 24 Jul 2012 21:04:40 +0300 X-CheckPoint: {500EE193-7-1B221DC2-4FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Tue, 24 Jul 2012 21:04:40 +0300 From: Yoav Nir To: Yaron Sheffer Date: Tue, 24 Jul 2012 21:04:38 +0300 Thread-Topic: [IPsec] ECDSA in IKEv2 Thread-Index: Ac1pxspfm0qlneO4TaCW2zEcZXO8kw== Message-ID: <026235F6-0037-4B3B-9760-99F371911DC0@checkpoint.com> References: <500EC87A.5020106@gmail.com> In-Reply-To: <500EC87A.5020106@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPsecme WG Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:04:45 -0000 Hi Yaron I would like to participate. A few comments on the proposed "charter": - Flexibility in associating hash functions should not a unlimited. There = is no reason to allow a 521-bit EC group with MD4 as the hash function, or = even with SHA2-256 as the hash function. I'm perfectly happy to limit that = curve to SHA2-512 and SHA3-512. - I don't think "ECDSA" as opposed to "ECGDSA" or "DSA" or "RSA" should be= an authentication method. It seems much more intuitive to me to expand tha= t to "certificate authentication" or "public key signatures". The user gets= a certificate by some method, installs it on their IKE endpoint, and then = proceeds to use it. The public key in the certificate is suitable for verif= ying one or more kinds of signature, so it does influence the content of th= e AUTH payloads, but whatever kind of certificate you use, the method IMO s= hould be the same. Since we're taking the public key from a SPKI structure = in a certificate anyway (or from Tero's OOB draft that uses the same SPKI s= tructure), the type of signature possible is already determined. Or if ther= e is more than one possibility (as in ECDSA and ECGDSA) this can be signale= d in the same way as the hash algorithm. Yoav On Jul 24, 2012, at 7:08 PM, Yaron Sheffer wrote: > Hi, > recent discussion on the list has indicated that there is some interest=20 > in better supporting ECDSA certificates in IKEv2, and that the existing=20 > solutions are not very extensible. The discussion was very useful in=20 > outlining the existing issues and pointing to some possible ways forward. >=20 > Paul and I would like to propose setting up a design team with the goal=20 > of proposing a long-term solution to this problem. Some of the=20 > attributes of a reasonable solution include: >=20 > - Supports currently used and proposed ECDSA certificates. > - Allows flexibility in defining EC domain parameters. > - Allows flexibility in associating hash functions with EC groups. > - Is not limited to 256 values > - ECDH is out of scope. > - Non-certificate authentication using raw public keys is out of scope,=20 > unless it is trivially supported by the proposal. >=20 > The solution should be an extension to IKEv2, and should not break the=20 > protocol. Some of the ideas in=20 > http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be=20 > used as a starting point. >=20 > Please respond to us privately or to the list, indicating if you would=20 > like to participate in the design team, or if you only support the=20 > effort and would be willing to review the ensuing I-D. >=20 > Thanks, > Yaron From yaronf.ietf@gmail.com Tue Jul 24 11:28:10 2012 Return-Path: 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 990AA11E8087 for ; Tue, 24 Jul 2012 11:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 0f1ZNT1GqUI9 for ; Tue, 24 Jul 2012 11:28:10 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B45CD11E8079 for ; Tue, 24 Jul 2012 11:28:09 -0700 (PDT) Received: by bkty7 with SMTP id y7so6252411bkt.31 for ; Tue, 24 Jul 2012 11:28:08 -0700 (PDT) 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=qxJC5LozqnIkFHp392v7MY9aPjmW63Lg+PN0qEnJRyE=; b=My5d9Vr3KWM8lbN1DQHvtwcJAcnG1Ln2TZ8+/y7vjfivv/Lg+SYnMozu7X18nSd98C xWgsP4nm9i6JbfLxrNLsjdDcTfPu7Kn70o0c3qqFhZYdAKUYwFBVGnnfCTtpImr+OY93 C5tis1v43bj929nkmTrwkB40tL8PeZ/HQowCaDHJObvQaxke4BOkIvAMiGyJ/U5odk8P zVHUc0vnqVNyoRC2m1jNWQX7YbamvHMFKghIpEXC7FSIzZQg9sffBeK062h9WSdffk4t wDc6uIbCvnKySzsceAwhVzwwTMKGhdq0/4Jsh0ryY94yYW3rYXe9IQSkhlyxKjnoIpiT U3iA== Received: by 10.205.117.141 with SMTP id fm13mr10941620bkc.125.1343154488563; Tue, 24 Jul 2012 11:28:08 -0700 (PDT) Received: from [10.0.0.4] ([109.64.166.231]) by mx.google.com with ESMTPS id n5sm11491821bkv.14.2012.07.24.11.28.07 (version=SSLv3 cipher=OTHER); Tue, 24 Jul 2012 11:28:08 -0700 (PDT) Message-ID: <500EE936.8070806@gmail.com> Date: Tue, 24 Jul 2012 21:28:06 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Yoav Nir References: <500EC87A.5020106@gmail.com> <026235F6-0037-4B3B-9760-99F371911DC0@checkpoint.com> In-Reply-To: <026235F6-0037-4B3B-9760-99F371911DC0@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:28:10 -0000 Hi Yoav, please see below. Thanks, Yaron On 07/24/2012 09:04 PM, Yoav Nir wrote: > Hi Yaron > > I would like to participate. > > A few comments on the proposed "charter": > > - Flexibility in associating hash functions should not a unlimited. There is no reason to allow a 521-bit EC group with MD4 as the hash function, or even with SHA2-256 as the hash function. I'm perfectly happy to limit that curve to SHA2-512 and SHA3-512. This is for the group to decide, of course. Personally I'm fine with a fully flexible or with a somewhat flexible solution. But not with a solution where we invent a mapping from curve to hash, and the next curve to come along disproves our theory. > > - I don't think "ECDSA" as opposed to "ECGDSA" or "DSA" or "RSA" should be an authentication method. It seems much more intuitive to me to expand that to "certificate authentication" or "public key signatures". The user gets a certificate by some method, installs it on their IKE endpoint, and then proceeds to use it. The public key in the certificate is suitable for verifying one or more kinds of signature, so it does influence the content of the AUTH payloads, but whatever kind of certificate you use, the method IMO should be the same. Since we're taking the public key from a SPKI structure in a certificate anyway (or from Tero's OOB draft that uses the same SPKI structure), the type of signature possible is already determined. Or if there is more than one possibility (as in ECDSA and ECGDSA) this can be signaled in the same way as the hash algorithm. I would agree if we were designing a new protocol. In this case, we are solving a problem and I'd like to focus on it. I am sure modular DSA or RSA have their own challenges, and I see no reason to tackle these challenges, seeing that the existing solutions work just fine. As to ECGDSA, I would prefer to leave it out for now. My feeling is that its constituency is too small to justify the effort. Plus, it can be tacked on later as an Informational RFC. > > Yoav > > On Jul 24, 2012, at 7:08 PM, Yaron Sheffer wrote: > >> Hi, >> recent discussion on the list has indicated that there is some interest >> in better supporting ECDSA certificates in IKEv2, and that the existing >> solutions are not very extensible. The discussion was very useful in >> outlining the existing issues and pointing to some possible ways forward. >> >> Paul and I would like to propose setting up a design team with the goal >> of proposing a long-term solution to this problem. Some of the >> attributes of a reasonable solution include: >> >> - Supports currently used and proposed ECDSA certificates. >> - Allows flexibility in defining EC domain parameters. >> - Allows flexibility in associating hash functions with EC groups. >> - Is not limited to 256 values >> - ECDH is out of scope. >> - Non-certificate authentication using raw public keys is out of scope, >> unless it is trivially supported by the proposal. >> >> The solution should be an extension to IKEv2, and should not break the >> protocol. Some of the ideas in >> http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be >> used as a starting point. >> >> Please respond to us privately or to the list, indicating if you would >> like to participate in the design team, or if you only support the >> effort and would be willing to review the ensuing I-D. >> >> Thanks, >> Yaron > From prvs=3552a385c1=dbrown@certicom.com Tue Jul 24 11:42:19 2012 Return-Path: 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 71EBD21F85D7 for ; Tue, 24 Jul 2012 11:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.174 X-Spam-Level: X-Spam-Status: No, score=-5.174 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Ov9LRmq3I-sQ for ; Tue, 24 Jul 2012 11:42:19 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id B8EAD21F85CE for ; Tue, 24 Jul 2012 11:42:18 -0700 (PDT) X-AuditID: 0a412830-b7f2e6d000004806-55-500eec872e35 Received: from XCT101CNC.rim.net (xct101cnc.rim.net [10.65.161.201]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id CA.51.18438.78CEE005; Tue, 24 Jul 2012 18:42:15 +0000 (GMT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 14:42:14 -0400 From: Dan Brown To: 'Johannes Merkle' , Dan Harkins Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: AQHNZpOZFYffEm0Lh0aC+e7B6HtNipc0KNKAgAAI0ICAAtHMAIAAZq4AgAAa9YCAADQngIAA2GeAgAAvs5A= Date: Tue, 24 Jul 2012 18:42:13 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF509D7AC@XMB111CNC.rim.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> In-Reply-To: <500E8433.7020002@secunet.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBKsWRmVeSWpSXmKPExsXC5bjwpG77G74Ag/6Z8hZL/31hsdi/5QWb xbIZsxgtjp5/zubA4rFkyU8mj8NfF7J4PNv9ksVjU+sS1gCWqAZGm6TEkrLgzPQ8fTubxLy8 /JLEklSFlNTiZFsln9T0xByFgKLMssTkSgWXzOLknMTM3NQiJYXMFFslEyWFgpzE5NTc1LwS W6XEgoLUvBQlOy4FDGADVJaZp5Cal5yfkpmXbqvkGeyva2FhaqlrqGSnm9DJk7Gp4T5zwVPO ipU37zI1MH5m72Lk5JAQMJFYtfggM4QtJnHh3nq2LkYuDiGBPiaJ+VffsUA4WxglVk3dyQJS xSagKnH/6DmgDnYOEYEIiZVWIFFmAReJ6/0PwGYKC1hJXDjeA1YtImAtcfzFDSg7SWLl9fNg u1iApsw9/Z0JxOYVcJM4df801N7rzBJz1l8Da+AU0Jb4fXYLmM0oICux++x1Johl4hK3nsxn gjhaQGLJnvNQD4hKvHz8jxXCVpR4chJiDrOAjsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZ SMbOQtIyC0nLLCQtCxhZVjEK5mYUG5gZJucl6xVl5urlpZZsYgSnEw2DHYzv31scYhTgYFTi 4c06yxcgxJpYVlyZe4hRgoNZSYT37nqgEG9KYmVValF+fFFpTmrxIUYLYLBMZJbiTs4Hprq8 knhjAwMUjpI472117gAhgXRg6slOTS1ILYJpZeLgBBnNJSVSDEwgqUWJpSUZ8aA0F18MTHRS DYyVa7vmST4QNfDq7pA6ZcUyZ5ZxV1WftjM39+1Pm2frpKbM66xsEM7jc/v3bKfQbV7GrlpX 9v5bvbV8q0z//2C4vyNESHDhrnzLV+1Nx/eH3BRoSto3MUlOPVvMcOeRvswzi/Xvz/x6JsSE 7zf7rfhJSXqVeRONbOWiNi80Pn6Z1fvbl68nbyqxFGckGmoxFxUnAgDOT3ltWwMAAA== Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:42:19 -0000 Hi all, Just a technical question, not very IPSec-specific: Do the Brainpool curves comply with all the requirements (and ideally the re= commendations too) that the ECDSA standards place on the elliptic curves? T= he intent of the ECDSA standards and IPSec is to have a secure, interoperabl= e signature algorithm, which ought to be the case for the Brainpool curves u= sed with ECDSA. So IPSec may choose to call various things "ECDSA", but IPS= ec may want to avoid saying something is ANSI X9.62-2005 unless if it is str= ictly compliant. The main ECDSA standards are ANSI X9.62-2005 and SEC1-v2.0 (which also speci= fies other ECC algorithms and syntax). FIPS 186-3 specifies ECDSA mostly by= reference to ANSI X9.62-2005. ISO also specifies "EC-DSA". IEEE 1363-200= 0 and IEEE 1363a-2004 specify ECDSA under a slightly different acronym. As editor of ANSI X9.62-2005 and SEC1-v2.0, I ought able to help check compl= iance. As I recall, both standards impose requirements on the elliptic curv= es in order to avoid weak curves, and perhaps also to encourage interoperabi= lity. Maybe Johannes could contact me off-list to start this process. Best regards, Daniel Brown Research In Motion Limited --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient 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 immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From dharkins@lounge.org Tue Jul 24 11:52:07 2012 Return-Path: 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 4E65011E80A2 for ; Tue, 24 Jul 2012 11:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 T-WP1n7zzoLY for ; Tue, 24 Jul 2012 11:52:06 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9E40011E80A4 for ; Tue, 24 Jul 2012 11:52:06 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 45CAC10224008; Tue, 24 Jul 2012 11:52:06 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 24 Jul 2012 11:52:06 -0700 (PDT) Message-ID: <51faf4d928985753217019512c7a4184.squirrel@www.trepanning.net> In-Reply-To: <026235F6-0037-4B3B-9760-99F371911DC0@checkpoint.com> References: <500EC87A.5020106@gmail.com> <026235F6-0037-4B3B-9760-99F371911DC0@checkpoint.com> Date: Tue, 24 Jul 2012 11:52:06 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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 Cc: IPsecme WG Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 18:52:07 -0000 On Tue, July 24, 2012 11:04 am, Yoav Nir wrote: > - Flexibility in associating hash functions should not a unlimited. There > is no reason to allow a 521-bit EC group with MD4 as the hash function, > or even with SHA2-256 as the hash function. I'm perfectly happy to limit > that curve to SHA2-512 and SHA3-512. There is no reason to "allow" the 768-bit FFC group to be used to generate a shared secret that is to be authenticated with an ECDSA signature with a 521-bit curve and have SHA-1 be used as the key derivation function either, but such a thing is permissible and it will be permissible in IKEv2 even if we were to prohibit the use of SHA-256 with a 521-bit curve. Any attempt to enforce coherent use of primitives-- e.g. define what primitives are valid for different security levels, or what certain combinations of primitives are permissible and what are forbidden-- should only be done as part of an IKEv3. Dan. From mcgrew@cisco.com Tue Jul 24 13:15:32 2012 Return-Path: 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 3C60521F852E for ; Tue, 24 Jul 2012 13:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 9dK-1EAH-pD1 for ; Tue, 24 Jul 2012 13:15:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1CF21F8526 for ; Tue, 24 Jul 2012 13:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcgrew@cisco.com; l=3066; q=dns/txt; s=iport; t=1343160931; x=1344370531; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=GO+MuJOG1VwJbw21vab1GYQ+RvViFPUl2uxpqdsvnG4=; b=MNlhTAlVI3rP8l9n1hNgdlDqft8OZAyrqSOUH/c5hNIKi5WSnZema+dg NHPsMX7sstSUEDJGmIDe6NajtkZPP/HBJ36CWlwxeZbNIQ7XwTC9spg93 J7rBrt1fwyRrpYjx2xACgwIgPqDnao7+QsoG+rSQ60fA6587ekXKlALYR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMsBD1CtJV2Y/2dsb2JhbABFugGBB4IiAQQBAQEPASctBx0BCDYxBgslAgQBEgkSB4dcAwwLmmOWaQ2JTopjfAaGWgOTdYFUiwqDHYFmgl+BVgk X-IronPort-AV: E=Sophos;i="4.77,648,1336348800"; d="scan'208";a="104917411" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 24 Jul 2012 20:15:30 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6OKFUkk032058 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 24 Jul 2012 20:15:30 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 15:15:30 -0500 From: "David McGrew (mcgrew)" To: Yaron Sheffer , IPsecme WG Thread-Topic: [IPsec] ECDSA in IKEv2 Thread-Index: AQHNabaZuHbr5iDiEkO6cZdML4TK65c473eA Date: Tue, 24 Jul 2012 20:15:29 +0000 Message-ID: In-Reply-To: <500EC87A.5020106@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.228] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19062.001 x-tm-as-result: No--34.273900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <419C5B90BED58D46B951D95E55235767@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 20:15:32 -0000 Hi Yaron, On 7/24/12 12:08 PM, "Yaron Sheffer" wrote: >Hi, >recent discussion on the list has indicated that there is some interest >in better supporting ECDSA certificates in IKEv2, and that the existing >solutions are not very extensible. The discussion was very useful in >outlining the existing issues and pointing to some possible ways forward. > >Paul and I would like to propose setting up a design team with the goal >of proposing a long-term solution to this problem. Some of the >attributes of a reasonable solution include: > >- Supports currently used and proposed ECDSA certificates. Has there been a formal proposal for new ECDSA certificates? Or do you mean the informal idea of using different elliptic curve parameters inside ECDSA? The latter suggestion is something that needs to be reviewed, and if it goes forward, would need to be well specified. (Thanks to Dan Brown for offering to help with this analysis.) "Supports other protocols than IKEv2" is another desirable property. If there is interest in ECDSA with other curves in IKEv2, then it is likely that there will be interest in other protocols such as TLS and SMIME. To avoid parallel and potentially divergent solutions for other protocols, it makes sense to consider extensions to ECDSA and its certificate format. >- Allows flexibility in defining EC domain parameters. >- Allows flexibility in associating hash functions with EC groups. I do not think that flexibility in hash/curve pairs is desirable (though it might be acceptable if there is well written guidance on which pairs to use). If the number of signature parameters is significantly larger than 256, as suggested below, then there are enough numbers to go around that we can assign every hash/curve pair that we care about its own number. >- Is not limited to 256 values >- ECDH is out of scope. >- Non-certificate authentication using raw public keys is out of scope, >unless it is trivially supported by the proposal. Another requirement: the solution should work with certificate chains, without requiring that all certificates in the chain have the exact same signature algorithm and parameters. > >The solution should be an extension to IKEv2, Why should this be a requirement? It is something of a layer violation to require the protocol to provide the information about how to process the signatures in the certificates that it carries. >and should not break the >protocol. Some of the ideas in >http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be >used as a starting point. > >Please respond to us privately or to the list, indicating if you would >like to participate in the design team, or if you only support the >effort and would be willing to review the ensuing I-D. I would like to participate. David > >Thanks, > Yaron > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec From yaronf.ietf@gmail.com Tue Jul 24 13:52:00 2012 Return-Path: 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 CE44D11E80B3 for ; Tue, 24 Jul 2012 13:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 qHiVVp-VQw1I for ; Tue, 24 Jul 2012 13:52:00 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD23611E80A4 for ; Tue, 24 Jul 2012 13:51:59 -0700 (PDT) Received: by bkty7 with SMTP id y7so6338765bkt.31 for ; Tue, 24 Jul 2012 13:51:58 -0700 (PDT) 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=hVZAI0IEAQq8MpIsoVR4vwOsL9ZJGWTUD1nrIRw9jsE=; b=gY31XGTRoRi50NqCttpwuJ7+qOABoFzRADSpDhFX7EzLasUP066NqnQSv/Qa4NeVbr ZbSR5ul3WuE3uvQib/161TgyM5modlnfiWtxSIUOH4wVGhu1gr1crdftcfqF6O5kxtjs gmQxanlViSAo24xqznmvsV19dzuWkPwgn6+HzhTtdLE4e2sZS4EQnlEz9E+EJX5s3e9z /RIUn+Am7O7PRWWGDOepb3ezmYdesAzPSzrRG6ftHede5DGnVt84jRpduZGQbp6Z8Vak VMcWOHf1mNabk6fE+kuXkHhbupIpRwAAmpZdgAXP+PWYBtiiyPhDVUAQw98+GsedzZdU VuNQ== Received: by 10.204.154.73 with SMTP id n9mr10890261bkw.113.1343163118738; Tue, 24 Jul 2012 13:51:58 -0700 (PDT) Received: from [10.0.0.9] ([109.64.166.231]) by mx.google.com with ESMTPS id 25sm11638467bkx.9.2012.07.24.13.51.57 (version=SSLv3 cipher=OTHER); Tue, 24 Jul 2012 13:51:58 -0700 (PDT) Message-ID: <500F0AE6.9070501@gmail.com> Date: Tue, 24 Jul 2012 23:51:50 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "David McGrew (mcgrew)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 20:52:00 -0000 Hi David, please see my responses below. Thanks, Yaron On 24.7.2012 23:15, David McGrew (mcgrew) wrote: > Hi Yaron, > > On 7/24/12 12:08 PM, "Yaron Sheffer" wrote: > >> Hi, >> recent discussion on the list has indicated that there is some interest >> in better supporting ECDSA certificates in IKEv2, and that the existing >> solutions are not very extensible. The discussion was very useful in >> outlining the existing issues and pointing to some possible ways forward. >> >> Paul and I would like to propose setting up a design team with the goal >> of proposing a long-term solution to this problem. Some of the >> attributes of a reasonable solution include: >> >> - Supports currently used and proposed ECDSA certificates. > Has there been a formal proposal for new ECDSA certificates? Or do you > mean the informal idea of using different elliptic curve parameters inside > ECDSA? The latter suggestion is something that needs to be reviewed, > and if it goes forward, would need to be well specified. (Thanks to Dan > Brown for offering to help with this analysis.) Sorry about the sloppy language. I meant the latter: the use of certificates based on different EC domain parameters. But I'm certainly not suggesting that we should define the certificate, or that we should extend the ECDSA algorithm. The scope is very strictly limited to IKEv2 use of ECDSA certs specified elsewhere. > > "Supports other protocols than IKEv2" is another desirable property. If > there is interest in ECDSA with other curves in IKEv2, then it is likely > that there will be interest in other protocols such as TLS and SMIME. To > avoid parallel and potentially divergent solutions for other protocols, it > makes sense to consider extensions to ECDSA and its certificate format. I strongly disagree on this point. The is a short-term effort to solve a problem related to IKEv2. I'm not advocating diverging from TLS on purpose. But I'm not out to solve a problem for all of the IETF protocols. > >> - Allows flexibility in defining EC domain parameters. >> - Allows flexibility in associating hash functions with EC groups. > I do not think that flexibility in hash/curve pairs is desirable (though > it might be acceptable if there is well written guidance on which pairs to > use). If the number of signature parameters is significantly larger than > 256, as suggested below, then there are enough numbers to go around that > we can assign every hash/curve pair that we care about its own number. I'll be happy to see such guidance coming from CFRG. I doubt that we have the relevant expertise in ipsecme to formulate or review this "pairing". If we have "enough numbers to go around" we can have all the useful pairs and there will also be some silly pairs, and it's not reasonable to try to outlaw the silly ones in advance. > >> - Is not limited to 256 values >> - ECDH is out of scope. >> - Non-certificate authentication using raw public keys is out of scope, >> unless it is trivially supported by the proposal. > Another requirement: the solution should work with certificate chains, > without requiring that all certificates in the chain have the exact same > signature algorithm and parameters. I'm not disagreeing but I think that in the context of IKEv2 (and other protocols), the only thing that touches the protocol is the end-entity certificate. So we don't care about the rest of the chain. > >> The solution should be an extension to IKEv2, > Why should this be a requirement? It is something of a layer violation > to require the protocol to provide the information about how to process > the signatures in the certificates that it carries. The existing protocol indicates how to generate the AUTH payload based on the public key that's provided by the certificate. So it's not about "processing the signatures in the certs", it's about "using the cert to sign other stuff". > > > >> and should not break the >> protocol. Some of the ideas in >> http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be >> used as a starting point. >> >> Please respond to us privately or to the list, indicating if you would >> like to participate in the design team, or if you only support the >> effort and would be willing to review the ensuing I-D. > I would like to participate. > > David >> Thanks, >> Yaron >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec From paul.hoffman@vpnc.org Tue Jul 24 13:53:43 2012 Return-Path: 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 F14B111E80BB for ; Tue, 24 Jul 2012 13:53:42 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 mgpBjz6LjaPA for ; Tue, 24 Jul 2012 13:53:42 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1C09C11E80A4 for ; Tue, 24 Jul 2012 13:53:38 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6OK2Fig011302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2012 13:02:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <810C31990B57ED40B2062BA10D43FBF509D7AC@XMB111CNC.rim.net> Date: Tue, 24 Jul 2012 13:53:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <810C31990B57ED40B2062BA10D43FBF509D7AC@XMB111CNC.rim.net> To: Dan Brown X-Mailer: Apple Mail (2.1278) Cc: IPsecme WG Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 20:53:43 -0000 On Jul 24, 2012, at 11:42 AM, Dan Brown wrote: > Do the Brainpool curves comply with all the requirements (and ideally = the recommendations too) that the ECDSA standards place on the elliptic = curves? I'm confused by the question. "The ECDSA standards" (ANSI X9.62-2005 and = SEC1-v2.0) list things that newer curves might not meet because, well, = they're newer than the standards. Why should that be a limitation on = what is used in IPsec? --Paul Hoffman= From paul.hoffman@vpnc.org Tue Jul 24 14:00:46 2012 Return-Path: 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 4E4FE11E8072 for ; Tue, 24 Jul 2012 14:00:46 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 tPJYAJrhHV9s for ; Tue, 24 Jul 2012 14:00:45 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4821F8593 for ; Tue, 24 Jul 2012 14:00:45 -0700 (PDT) Received: from sn87.proper.com (sn87.proper.com [75.101.18.87]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6OK9KwT012670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2012 13:09:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Tue, 24 Jul 2012 14:00:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: David McGrew (mcgrew) X-Mailer: Apple Mail (2.1278) Cc: IPsecme WG Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 21:00:46 -0000 On Jul 24, 2012, at 1:15 PM, David McGrew (mcgrew) wrote: > Hi Yaron, >=20 > On 7/24/12 12:08 PM, "Yaron Sheffer" wrote: >=20 >> Hi, >> recent discussion on the list has indicated that there is some = interest >> in better supporting ECDSA certificates in IKEv2, and that the = existing >> solutions are not very extensible. The discussion was very useful in >> outlining the existing issues and pointing to some possible ways = forward. >>=20 >> Paul and I would like to propose setting up a design team with the = goal >> of proposing a long-term solution to this problem. Some of the >> attributes of a reasonable solution include: >>=20 >> - Supports currently used and proposed ECDSA certificates. >=20 > Has there been a formal proposal for new ECDSA certificates? Or do = you > mean the informal idea of using different elliptic curve parameters = inside > ECDSA? The latter suggestion is something that needs to be = reviewed, > and if it goes forward, would need to be well specified. It is the latter, and that's exactly why having the output of a design = team would be useful. > "Supports other protocols than IKEv2" is another desirable property. =20= Not for this work, no. Maybe that would be appropriate for CFRG or SAAG, = but not the IPsecME WG. > If > there is interest in ECDSA with other curves in IKEv2, then it is = likely > that there will be interest in other protocols such as TLS and SMIME. = =20 There are already specifications from those WGs. > To > avoid parallel and potentially divergent solutions for other = protocols, it > makes sense to consider extensions to ECDSA and its certificate = format. Of course. >> - Allows flexibility in defining EC domain parameters. >> - Allows flexibility in associating hash functions with EC groups. >=20 > I do not think that flexibility in hash/curve pairs is desirable = (though > it might be acceptable if there is well written guidance on which = pairs to > use). =20 Others might disagree. For example, NIST seems to be of multiple minds = when they are choosing strengths. > If the number of signature parameters is significantly larger than > 256, as suggested below, then there are enough numbers to go around = that > we can assign every hash/curve pair that we care about its own number. One thing that the design team needs to consider is the amount of = flexibility. Note that the proposal says "allows flexibility", not = "forces maximal flexibility". >> - Is not limited to 256 values >> - ECDH is out of scope. >> - Non-certificate authentication using raw public keys is out of = scope, >> unless it is trivially supported by the proposal. >=20 > Another requirement: the solution should work with certificate chains, > without requiring that all certificates in the chain have the exact = same > signature algorithm and parameters. Good suggestion, yes. >> The solution should be an extension to IKEv2, >=20 > Why should this be a requirement? It is something of a layer = violation > to require the protocol to provide the information about how to = process > the signatures in the certificates that it carries. If you have other concrete proposals, that would be grand. There has = been enough disagreement in the thread this last week where it is likely = that there are multiple ways to do things. --Paul Hoffman From prvs=4552b2e56b=dbrown@certicom.com Tue Jul 24 14:21:29 2012 Return-Path: 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 51C4D11E8098 for ; Tue, 24 Jul 2012 14:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.18 X-Spam-Level: X-Spam-Status: No, score=-5.18 tagged_above=-999 required=5 tests=[AWL=0.023, 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 bOLo8PMX7dUG for ; Tue, 24 Jul 2012 14:21:28 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8F14011E808F for ; Tue, 24 Jul 2012 14:21:28 -0700 (PDT) X-AuditID: 0a41282f-b7f8a6d000006c2d-da-500f11d7f585 Received: from XCT101CNC.rim.net (xct101cnc.rim.net [10.65.161.201]) by mhs060cnc.rim.net (SBG) with SMTP id 79.D9.27693.7D11F005; Tue, 24 Jul 2012 16:21:27 -0500 (CDT) Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.02.0298.004; Tue, 24 Jul 2012 17:21:26 -0400 From: Dan Brown To: 'Paul Hoffman' Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: AQHNZpOZFYffEm0Lh0aC+e7B6HtNipc0KNKAgAAI0ICAAtHMAIAAZq4AgAAa9YCAADQngIAA2GeAgAAvs5CAAHFWgP//v/vw Date: Tue, 24 Jul 2012 21:21:26 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF509D870@XMB111CNC.rim.net> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <810C31990B57ED40B2062BA10D43FBF509D7AC@XMB111CNC.rim.net> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsXC5bjwpO51Qf4Ag+2vlS32b3nBZnFr/RdW ByaPJUt+Mnl8nn2VOYApqoHRJimxpCw4Mz1P384mMS8vvySxJFUhJbU42VbJJzU9MUchoCiz LDG5UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksBA9gAlWXmKaTm JeenZOal2yp5BvvrWliYWuoaKtnpJnTyZJy5qFhwhLPi/eR9TA2MZ9i7GDk5JARMJN5dncAG YYtJXLi3Hsjm4hASWMUo8b+7nx3C2cIo8ar3OFgVm4CqxP2j55hBbBEBLYntE7cwgdjMAvIS m7/sAqsRFrCSuHC8hwWixlri+IsbUHaexMLz68FsFqA5l3/eZAWxeQXcJO7OgFl2jEWidcE2 sAWcAjYSnRuegRUxCshK7D57HWqZuMStJ/OZIM4WkFiy5zwzhC0q8fLxP1YIW1HiyclrLBD1 OhILdn9ig7C1JZYtfM0MsVhQ4uTMJywTGMVmIRk7C0nLLCQts5C0LGBkWcUomJtRbGBmkJyX rFeUmauXl1qyiRGcKDT0dzC+fW9xiFGAg1GJh/cDK3+AEGtiWXFl7iFGCQ5mJRHeu+v5AoR4 UxIrq1KL8uOLSnNSiw8xWgCDZSKzFHdyPjCJ5ZXEGxsYoHCUxHkzvgH1CaQDk092ampBahFM KxMHJ8hoLimRYmAKSS1KLC3JiAcluvhiYKqTamAs08xb/fBC1rHLfy6eWLXqTNyUpL/xs7Sl PvzsbWuflmh38ezKq4+2GT5tXVRUNlFx65/TFamq7/Z6P1Q5oTQl79dXSU9NjY/PHIu6bwcm PtCXXvXm5gWZdr4iZ6vs/UkhdT/dKvvSFxy/FFVV9kYtPfdxwNb5ShoxL8WXbQ9k7Fh2TXy/ bFGQEktxRqKhFnNRcSIADEsUpEgDAAA= Cc: IPsecme WG Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 21:21:29 -0000 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] > Sent: Tuesday, July 24, 2012 4:53 PM > To: Dan Brown > Cc: IPsecme WG > Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec > > On Jul 24, 2012, at 11:42 AM, Dan Brown wrote: > > > Do the Brainpool curves comply with all the requirements (and ideally th= e > recommendations too) that the ECDSA standards place on the elliptic curves= ? > > I'm confused by the question. "The ECDSA standards" (ANSI X9.62-2005 and S= EC1- > v2.0) list things that newer curves might not meet because, well, they're > newer than the standards. Why should that be a limitation on what is used= in > IPsec? The next text after the question tried to clarify that I was not suggesting= any such limitation. Anyway, to answer your question: considerable thought was put into ECC param= eters in ECDSA standards, so their requirements should make for a good sanit= y check on any newer curves. (Are the Brainpool curves actually newer?) It= should be possible to devise newer curve that also adheres to the past ECDS= A standards, but if not, there should be a good reason. > > --Paul Hoffman --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient 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 immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From paul.hoffman@vpnc.org Tue Jul 24 15:24:06 2012 Return-Path: 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 0595611E809B for ; Tue, 24 Jul 2012 15:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 o1YnOPiX2i+5 for ; Tue, 24 Jul 2012 15:24:05 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6E94F11E809A for ; Tue, 24 Jul 2012 15:24:05 -0700 (PDT) Received: from [10.20.30.100] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q6OLWgcN028674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Jul 2012 14:32:43 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <810C31990B57ED40B2062BA10D43FBF509D870@XMB111CNC.rim.net> Date: Tue, 24 Jul 2012 15:23:55 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0E93E4F5-2F5D-4C63-BBD2-EC6A1A6030E4@vpnc.org> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <810C31990B57ED40B2062BA10D43FBF509D7AC@XMB111CNC.rim.net> <810C31990B57ED40B2062BA10D43FBF509D870@XMB111CNC.rim.net> To: Dan Brown X-Mailer: Apple Mail (2.1278) Cc: IPsecme WG Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 22:24:06 -0000 On Jul 24, 2012, at 2:21 PM, Dan Brown wrote: > The next text after the question tried to clarify that I was not = suggesting any such limitation. =20 Thank you: it was not clear. > Anyway, to answer your question: considerable thought was put into ECC = parameters in ECDSA standards, so their requirements should make for a = good sanity check on any newer curves. (Are the Brainpool curves = actually newer?) It should be possible to devise newer curve that also = adheres to the past ECDSA standards, but if not, there should be a good = reason.=20 Of course. Anything we do here should have good reason, and it should be = documented. --Paul Hoffman= From Johannes.Merkle@secunet.com Wed Jul 25 09:47:58 2012 Return-Path: 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 AD1CD21F86B9 for ; Wed, 25 Jul 2012 09:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] 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 5ha9GK9JlOpJ for ; Wed, 25 Jul 2012 09:47:58 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 16BDE21F86B5 for ; Wed, 25 Jul 2012 09:47:58 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 7E1A31A0066 for ; Wed, 25 Jul 2012 18:47:27 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 5913F1A006F for ; Wed, 25 Jul 2012 18:47:24 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Jul 2012 18:47:51 +0200 Message-ID: <50102338.6020409@secunet.com> Date: Wed, 25 Jul 2012 18:47:52 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <500EC87A.5020106@gmail.com> In-Reply-To: <500EC87A.5020106@gmail.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jul 2012 16:47:51.0693 (UTC) FILETIME=[3B0413D0:01CD6A85] Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 16:47:58 -0000 > Please respond to us privately or to the list, indicating if you would like to participate in the design team, or if you > only support the effort and would be willing to review the ensuing I-D. I would also like to participate. Though I am not an expert in IKEv2, I hope that my background on PKI standards and crypto can help. > - Allows flexibility in associating hash functions with EC groups. I is certainly not bad if the proposed solution could be trivially applied to (non-EC) DSA as well. I understand that this is not a requirement that fits in here but it is a nice-to-have. > - Is not limited to 256 values Does this requirement also apply to the hash functions if we are going to define separate code points for these? Johannes From yaronf.ietf@gmail.com Wed Jul 25 10:15:00 2012 Return-Path: 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 A709E21F85F6 for ; Wed, 25 Jul 2012 10:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 97bYC17xkA+Q for ; Wed, 25 Jul 2012 10:15:00 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B0FA21F85F2 for ; Wed, 25 Jul 2012 10:14:59 -0700 (PDT) Received: by bkty7 with SMTP id y7so668471bkt.31 for ; Wed, 25 Jul 2012 10:14:58 -0700 (PDT) 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=cTEpkRjFQyg+yVeym2a4gKq1jZ7E2XR/8cdHjc/Lxa4=; b=el1XXddl2QgN4gt6zJht0fhgOm0vFUFSYNDKmxP/1X0yB40ADhbphGYOjfakhdcb6w pEX7jGwYZmO7lqJsz+l5LbKZ0QvtTKEMGIAVLy/pwXFUZc/7H5eA5P9/mW7G9YaU++KP bCalckS3pXML9w4YJA20MH3sBAn9jgdFQSreiMlQ3yNg+dJfZNddOqn1N24ZG65JTLbb qIIR1RwH9zDUebk2twuog2CVKUpEj4K966dk0qG2Dk7vvhrKQtdCnMGTct0N0rPgUOk4 nb71lP0WeWBOilxg87bfhl/2cc8+pvnD98icuftknEddiLFx1SN/p85TFh104qrfxTw+ m94Q== Received: by 10.204.133.220 with SMTP id g28mr12230399bkt.117.1343236498620; Wed, 25 Jul 2012 10:14:58 -0700 (PDT) Received: from [10.0.0.4] (bzq-109-64-166-231.red.bezeqint.net. [109.64.166.231]) by mx.google.com with ESMTPS id c18sm13321780bkv.8.2012.07.25.10.14.57 (version=SSLv3 cipher=OTHER); Wed, 25 Jul 2012 10:14:58 -0700 (PDT) Message-ID: <50102990.5030305@gmail.com> Date: Wed, 25 Jul 2012 20:14:56 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Johannes Merkle References: <500EC87A.5020106@gmail.com> <50102338.6020409@secunet.com> In-Reply-To: <50102338.6020409@secunet.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: Re: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 17:15:00 -0000 Hi Johannes, re: your last point, I think not. IMHO 256 values would be sufficient for the hash functions, if defined separately (though I would prefer 16 bits, of course). Thanks, Yaron On 07/25/2012 07:47 PM, Johannes Merkle wrote: > >> Please respond to us privately or to the list, indicating if you would like to participate in the design team, or if you >> only support the effort and would be willing to review the ensuing I-D. > > I would also like to participate. Though I am not an expert in IKEv2, I hope that my background on PKI standards and > crypto can help. > >> - Allows flexibility in associating hash functions with EC groups. > I is certainly not bad if the proposed solution could be trivially applied to (non-EC) DSA as well. I understand that > this is not a requirement that fits in here but it is a nice-to-have. > >> - Is not limited to 256 values > Does this requirement also apply to the hash functions if we are going to define separate code points for these? > > Johannes > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From kivinen@iki.fi Thu Jul 26 06:21:59 2012 Return-Path: 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 7180A21F85D6 for ; Thu, 26 Jul 2012 06:21:59 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 h45BVLEjR3A3 for ; Thu, 26 Jul 2012 06:21:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7B921F85D1 for ; Thu, 26 Jul 2012 06:21:57 -0700 (PDT) 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 q6QDLsGG015153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 16:21:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6QDLqSB026622; Thu, 26 Jul 2012 16:21:52 +0300 (EEST) 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: <20497.17519.926893.965011@fireball.kivinen.iki.fi> Date: Thu, 26 Jul 2012 16:21:51 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 16 min Cc: ipsec@ietf.org, Johannes Merkle Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 13:21:59 -0000 Dan Harkins writes: > Well FIPS 186-3 specifically refers to SP 800-57 for "information about > the selection of the appropriate (L,N) pair in accordance with a desired > security strength for a given time period for the generation of digital > signatures." And SP 800-57 says that, for example, to produce a > signature valid "beyond 2030" it requires a minimum of 128 bits of > strength (table 4) and that when performing digital signatures of 128 > bits of security the valid hash functions are SHA-256, SHA-384, and > SHA-512. You want to restrict such signatures to SHA-256 so it's > not really meeting the requirements of FIPS 186-3. Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc to know the answer myself). When we have DSS signature in FIPS 186-3 format, I have understood that there is no indication about whether the signature is ECDSA or normal DSA, or what is the domain parameters for the ECDSA, and what is the hash function used when generating the signature. I.e. the signature just consist of some raw bits, and there is no other information around it and all that other information must be carried to the verifier over some other medium? Is this correct? If that is correct how does the PKIX solve this? I.e. when I have certificate signed by the some other certificate using DSA? If my reading of RFC5280 is correct there is this signatureAlgorithm ASN.1 blob in front of the signature itself and that gives all that information (including the domain parameters and hash functions etc). Is my understanding correct? If so then I think we should use similar method in the IKEv2 too, and fix both ECDSA and normal DSA at the same time, i.e. create one new authentication method where the actual signature format that contains both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3 from the RFC5280). This will fix the problem for all DSA methods (EC or normal) and allows using any hash function allowed by signers policy. It also allows responder to immediately know the domain parameters and hash function even when certificate of the public key was not delivered inband of the IKEv2. If we define one new authentication method then we can also deprecate old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-* curve - 9-11), and recommend that new implementations will use this new method. Or we can still say that for SHA-1 DSS and SHA-2 with those curves still use the old methods. This same method could also be used for RSA, but as this problem of not knowing hash-function / parameters do not exists in RSA there is no point of changing the current RSA method. This would also make it so that we could use any public key method the PKIX decideds to define in the future without any changes to the IKEv2 document. > If only this protocol was designed better.... True, we can only blame ourselves. This same problem was already there for IKEv1, but nobody noticed that we should fix this when we were defining IKEv2. -- kivinen@iki.fi From kivinen@iki.fi Thu Jul 26 06:33:36 2012 Return-Path: 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 1CB8D21F8767 for ; Thu, 26 Jul 2012 06:33:36 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 xmkELjtWhJiq for ; Thu, 26 Jul 2012 06:33:35 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 279F021F8738 for ; Thu, 26 Jul 2012 06:33:34 -0700 (PDT) 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 q6QDXWlH027873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Jul 2012 16:33:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6QDXWf6020125; Thu, 26 Jul 2012 16:33:32 +0300 (EEST) 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: <20497.18220.240288.108274@fireball.kivinen.iki.fi> Date: Thu, 26 Jul 2012 16:33:32 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <500EC87A.5020106@gmail.com> References: <500EC87A.5020106@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 10 min Cc: IPsecme WG Subject: [IPsec] ECDSA in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 13:33:36 -0000 Yaron Sheffer writes: > Paul and I would like to propose setting up a design team with the goal > of proposing a long-term solution to this problem. Some of the > attributes of a reasonable solution include: > > - Supports currently used and proposed ECDSA certificates. > - Allows flexibility in defining EC domain parameters. > - Allows flexibility in associating hash functions with EC groups. > - Is not limited to 256 values > - ECDH is out of scope. > - Non-certificate authentication using raw public keys is out of scope, > unless it is trivially supported by the proposal. I would also like to solve the problem with non-EC DSA. > The solution should be an extension to IKEv2, and should not break the > protocol. Some of the ideas in > http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be > used as a starting point. Actually I think adding the signatureAlgorithm from the PKIX 4.1.1.2 to be included in the Authentication data inside the new authentication method as proposed in my email today to the list would be even better, but this is something that should be discussed in the design team. > Please respond to us privately or to the list, indicating if you would > like to participate in the design team, or if you only support the > effort and would be willing to review the ensuing I-D. I would like to participate. -- kivinen@iki.fi From Johannes.Merkle@secunet.com Thu Jul 26 07:55:17 2012 Return-Path: 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 354C821F8598 for ; Thu, 26 Jul 2012 07:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] 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 E05b-OL+NfRH for ; Thu, 26 Jul 2012 07:55:16 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id EE08F21F8636 for ; Thu, 26 Jul 2012 07:55:15 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id AE8201A007E; Thu, 26 Jul 2012 16:54:33 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id DBD581A007D; Thu, 26 Jul 2012 16:54:27 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Jul 2012 16:55:07 +0200 Message-ID: <50115A4B.4020700@secunet.com> Date: Thu, 26 Jul 2012 16:55:07 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Tero Kivinen References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> In-Reply-To: <20497.17519.926893.965011@fireball.kivinen.iki.fi> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2012 14:55:07.0162 (UTC) FILETIME=[A5744FA0:01CD6B3E] Cc: ipsec@ietf.org, Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 14:55:17 -0000 > > Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc > to know the answer myself). > > When we have DSS signature in FIPS 186-3 format, I have understood > that there is no indication about whether the signature is ECDSA or > normal DSA, or what is the domain parameters for the ECDSA, and what > is the hash function used when generating the signature. > > I.e. the signature just consist of some raw bits, and there is no > other information around it and all that other information must be > carried to the verifier over some other medium? > > Is this correct? Yes, in both cases (DSA, ECDSA) the signature consists of two integers. RFC 3279 defines: Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } Ecdsa-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } And the bit length is typically comparable. > > If that is correct how does the PKIX solve this? I.e. when I have > certificate signed by the some other certificate using DSA? If my > reading of RFC5280 is correct there is this signatureAlgorithm ASN.1 > blob in front of the signature itself and that gives all that > information (including the domain parameters and hash functions etc). > > Is my understanding correct? > Almost. The signature scheme and hash are specified in the signatureAlgorithm identifier, e.g. id-dsa-with-sha256 and ecdsa-with-SHA256. The parameters (DSA parameters and ECC domain parameters) are stored in subjectPublicKey. But this is specified in the certificate. Note: for DSA is is admissible (according to RFC 3279) to omit the patrameters and then the parameters of the CA key apply, which are specified in the CA certificate. So it an be necessary to parse the CA certificate as well to obtain them. > If so then I think we should use similar method in the IKEv2 too, and > fix both ECDSA and normal DSA at the same time, i.e. create one new > authentication method where the actual signature format that contains > both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3 > from the RFC5280). > > This will fix the problem for all DSA methods (EC or normal) and > allows using any hash function allowed by signers policy. It also > allows responder to immediately know the domain parameters and hash > function even when certificate of the public key was not delivered > inband of the IKEv2. > That would work but would expand the auth payload by more than two or three bytes. For instance the OID ecdsa-with-SHA256 is 1.2.840.10045.4.3.2. While this is still limited, for the new RSA-PSS scheme (see my response regarding RSA below) > If we define one new authentication method then we can also deprecate > old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-* > curve - 9-11), and recommend that new implementations will use this > new method. Or we can still say that for SHA-1 DSS and SHA-2 with > those curves still use the old methods. > Deprecation is the cleaner method but I fear that existing implementation will not quickly adpat to the new rule, so still allowing the old methods is more safe. > This same method could also be used for RSA, but as this problem of > not knowing hash-function / parameters do not exists in RSA there is > no point of changing the current RSA method. > This may change. Since 2005, PKIX supports through RFC 4055 the signature scheme RSASA-PSS which provides provable security (in a certain mathematical model) and is generally considered the better padding method as compared to the old padding PKCS#1v1.5. However, in RSASA-PSS, the encoding of the PKIX signature algorithm identifier may be quite large as it has several parameters: RSASSA-PSS-params ::= SEQUENCE { hashAlgorithm [0] HashAlgorithm DEFAULT sha1, maskGenAlgorithm [1] MaskGenAlgorithm DEFAULT mgf1SHA1, saltLength [2] INTEGER DEFAULT 20, trailerField [3] TrailerField DEFAULT trailerFieldBC } -- Johannes From ynir@checkpoint.com Thu Jul 26 11:06:43 2012 Return-Path: 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 49D3921F8623 for ; Thu, 26 Jul 2012 11:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=-3.967, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_24=0.6, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_HI=-8] 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 YaEiLlGl32AF for ; Thu, 26 Jul 2012 11:06:42 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF2421F8625 for ; Thu, 26 Jul 2012 11:06:37 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6QI6WEf014764; Thu, 26 Jul 2012 21:06:32 +0300 X-CheckPoint: {501184EA-0-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Jul 2012 21:06:31 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 26 Jul 2012 21:06:30 +0300 From: Yoav Nir To: Tero Kivinen Date: Thu, 26 Jul 2012 21:06:28 +0300 Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: Ac1rWWEchyHlbsqdRimWz5gnANVM+g== Message-ID: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> In-Reply-To: <20497.17519.926893.965011@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1101b616949586d6194664d28a7a3c2dd542b881f4 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , Johannes Merkle , Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 18:06:43 -0000 On Jul 26, 2012, at 4:21 PM, Tero Kivinen wrote: > If that is correct how does the PKIX solve this? I.e. when I have > certificate signed by the some other certificate using DSA? If my > reading of RFC5280 is correct there is this signatureAlgorithm ASN.1 > blob in front of the signature itself and that gives all that > information (including the domain parameters and hash functions etc). >=20 > Is my understanding correct? Yes. If you print out a certificate signed with ECDSA with OpenSSL, it look= s like this: MBA:tmp ynir$ openssl x509 -in the_ca_cert.crt -text Certificate: Data: Version: 3 (0x2) Serial Number: 1 (0x1) Signature Algorithm: ecdsa-with-SHA1 Issuer:=20 Validity Not Before: Jul 26 17:56:00 2012 GMT Not After : Jul 26 17:56:00 2022 GMT Subject:=20 Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub:=20 04:b9:36:b6:65:ee:65:27:70:f0:f9:16:67:78:53: b8:be:14:29:c5:36:09:a7:3b:0a:f0:0d:59:4d:31: 6d:9a:f3:be:fd:bf:e3:6e:0e:39:69:96:c9:d8:ae: 74:79:3d:f8:af:b5:5a:65:44:fe:76:c1:8c:52:18: f3:6e:49:43:23 ASN1 OID: prime256v1 X509v3 extensions: X509v3 Basic Constraints: critical CA:TRUE X509v3 Subject Key Identifier:=20 9B:D6:1D:1A:9B:B8:CE:2D:46:FD:B1:A5:6E:7D:35:E6:05:04:F0:36 X509v3 Key Usage:=20 Certificate Sign, CRL Sign Netscape Cert Type:=20 SSL CA, S/MIME CA, Object Signing CA Netscape Comment:=20 xca certificate Signature Algorithm: ecdsa-with-SHA1 30:45:02:20:61:68:e4:5e:9c:47:2d:d6:49:f6:6b:24:cb:43: cd:20:2e:c4:5d:bb:1a:45:d9:95:09:6b:89:93:5b:00:d2:cb: 02:21:00:b9:c4:d3:d4:4a:98:e0:d6:20:45:b2:95:8b:4a:06: d5:6b:3d:90:f6:a7:81:be:1f:d0:c5:f1:a8:b5:6a:d0:b9 See the "Signature Algorithm" field before the signature itself? If we dum= p the ASN.1 the signature is a sequence of an OID and a bitstring: MBA:tmp ynir$ openssl asn1parse -in the_ca_cert.crt -i -dump 0:d=3D0 hl=3D4 l=3D 351 cons: SEQUENCE =20 =85 270:d=3D1 hl=3D2 l=3D 9 cons: SEQUENCE =20 272:d=3D2 hl=3D2 l=3D 7 prim: OBJECT :ecdsa-with-SHA1 281:d=3D1 hl=3D2 l=3D 72 prim: BIT STRING =20 0000 - 00 30 45 02 20 61 68 e4-5e 9c 47 2d d6 49 f6 6b .0E. ah.^.G-= .I.k 0010 - 24 cb 43 cd 20 2e c4 5d-bb 1a 45 d9 95 09 6b 89 $.C. ..]..E.= ..k. 0020 - 93 5b 00 d2 cb 02 21 00-b9 c4 d3 d4 4a 98 e0 d6 .[....!.....= J... 0030 - 20 45 b2 95 8b 4a 06 d5-6b 3d 90 f6 a7 81 be 1f E...J..k=3D= ...... 0040 - d0 c5 f1 a8 b5 6a d0 b9- .....j.. In IKE we only have the bitstring, so we must infer the OID from something = else.= From yaronf.ietf@gmail.com Thu Jul 26 14:00:00 2012 Return-Path: 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 8935921F84B6 for ; Thu, 26 Jul 2012 14:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 35NANuT+GIUi for ; Thu, 26 Jul 2012 13:59:59 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2534A21F84A5 for ; Thu, 26 Jul 2012 13:59:58 -0700 (PDT) Received: by bkty7 with SMTP id y7so1433228bkt.31 for ; Thu, 26 Jul 2012 13:59:58 -0700 (PDT) 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=kb5qrNG3UxtmO5i5cc4f4RyElaSxKwt3CPQCISW75V4=; b=bvIORqtK+HIvknrql0mN1OM11ji2YyBM8BAA93E+6SEXNq440K9wAdoEdsuyIvmRJU 3UwnS+sZqPxqLuNB1xYiRHKpJfWi0WKJAzDvOhhayIgTnGWWo68UxoWUR81t7sZrcv1C vMa6XbgEy+PSOn3VEmL4jx/qyMOX1m2/quvUxG07IABk+4BwR3sIgu6Lo53d7bKilfpQ DWnx3Mg+c9URFwe/F0YUSTgtfI8ixGl7ycwW2DjEE/XVmVQ+xicVZ2Hr+SC5IUIXT4N4 nC/o0isMkzuQNXtVRJQkXQ34dr/kvfu9ot/GJJFlh8ohRrpRDSaJ2o5Qguy06DupUtXz CwBg== Received: by 10.205.139.6 with SMTP id iu6mr85236bkc.20.1343336398148; Thu, 26 Jul 2012 13:59:58 -0700 (PDT) Received: from [10.0.0.4] ([109.67.179.185]) by mx.google.com with ESMTPS id fu8sm123589bkc.5.2012.07.26.13.59.56 (version=SSLv3 cipher=OTHER); Thu, 26 Jul 2012 13:59:57 -0700 (PDT) Message-ID: <5011AFCB.1080900@gmail.com> Date: Thu, 26 Jul 2012 23:59:55 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Tero Kivinen References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> In-Reply-To: <20497.17519.926893.965011@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Johannes Merkle , Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:00:00 -0000 Hi Tero, the fact that we need to study the protocol details and go into the ASN.1 bits to ascertain that we have a problem, strongly suggests to me that non-EC DSA is not terribly important. So if we can have a *simple* solution that also deals with this problem, fine. Otherwise, let's just focus on ECDSA. Thanks, Yaron On 07/26/2012 04:21 PM, Tero Kivinen wrote: > Dan Harkins writes: >> Well FIPS 186-3 specifically refers to SP 800-57 for "information about >> the selection of the appropriate (L,N) pair in accordance with a desired >> security strength for a given time period for the generation of digital >> signatures." And SP 800-57 says that, for example, to produce a >> signature valid "beyond 2030" it requires a minimum of 128 bits of >> strength (table 4) and that when performing digital signatures of 128 >> bits of security the valid hash functions are SHA-256, SHA-384, and >> SHA-512. You want to restrict such signatures to SHA-256 so it's >> not really meeting the requirements of FIPS 186-3. > > Few questions (I do not know enough about FIPS 186-3 or SP 800-57 etc > to know the answer myself). > > When we have DSS signature in FIPS 186-3 format, I have understood > that there is no indication about whether the signature is ECDSA or > normal DSA, or what is the domain parameters for the ECDSA, and what > is the hash function used when generating the signature. > > I.e. the signature just consist of some raw bits, and there is no > other information around it and all that other information must be > carried to the verifier over some other medium? > > Is this correct? > > If that is correct how does the PKIX solve this? I.e. when I have > certificate signed by the some other certificate using DSA? If my > reading of RFC5280 is correct there is this signatureAlgorithm ASN.1 > blob in front of the signature itself and that gives all that > information (including the domain parameters and hash functions etc). > > Is my understanding correct? > > If so then I think we should use similar method in the IKEv2 too, and > fix both ECDSA and normal DSA at the same time, i.e. create one new > authentication method where the actual signature format that contains > both the signatureAlgorithm and signatureValue (4.1.1.2 and 4.1.1.3 > from the RFC5280). > > This will fix the problem for all DSA methods (EC or normal) and > allows using any hash function allowed by signers policy. It also > allows responder to immediately know the domain parameters and hash > function even when certificate of the public key was not delivered > inband of the IKEv2. > > If we define one new authentication method then we can also deprecate > old DSA methods (DSS Digital Signature - 3, ECDSA with * on the P-* > curve - 9-11), and recommend that new implementations will use this > new method. Or we can still say that for SHA-1 DSS and SHA-2 with > those curves still use the old methods. > > This same method could also be used for RSA, but as this problem of > not knowing hash-function / parameters do not exists in RSA there is > no point of changing the current RSA method. > > This would also make it so that we could use any public key method the > PKIX decideds to define in the future without any changes to the IKEv2 > document. > >> If only this protocol was designed better.... > > True, we can only blame ourselves. This same problem was already there > for IKEv1, but nobody noticed that we should fix this when we were > defining IKEv2. > From dharkins@lounge.org Thu Jul 26 14:21:11 2012 Return-Path: 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 6623711E809C for ; Thu, 26 Jul 2012 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 1MlUdYl1j+V6 for ; Thu, 26 Jul 2012 14:21:10 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDA5411E8080 for ; Thu, 26 Jul 2012 14:21:10 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7D3C210224008; Thu, 26 Jul 2012 14:21:10 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 26 Jul 2012 14:21:10 -0700 (PDT) Message-ID: In-Reply-To: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> Date: Thu, 26 Jul 2012 14:21:10 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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 Cc: "ipsec@ietf.org" , Johannes Merkle , Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:21:11 -0000 On Thu, July 26, 2012 11:06 am, Yoav Nir wrote: > In IKE we only have the bitstring, so we must infer the OID from something > else. Which is why I suggested we take some of the second bunch of RESERVED bits in the AUTH payload. Not to indicate an OID (not enough bits) but to just enumerate the valid hash algorithms that can be used with ECDSA. That way we know the curve from the subjectPublicKeyInfo (in either the signer's certificate or raw public key) and the hash algorithm used (from the 2nd bunch of RESERVED bits). There is nothing to infer. When more hash algorithms (like SHA3) get defined we just populate the registry that gets represented in the 2nd bunch of RESERVED bits. Dan. From dharkins@lounge.org Thu Jul 26 14:22:50 2012 Return-Path: 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 9FA6011E80AA for ; Thu, 26 Jul 2012 14:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 OJudYsX37XQy for ; Thu, 26 Jul 2012 14:22:50 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 46A8911E80A4 for ; Thu, 26 Jul 2012 14:22:50 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E7FFB10224008; Thu, 26 Jul 2012 14:22:49 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 26 Jul 2012 14:22:50 -0700 (PDT) Message-ID: In-Reply-To: <5011AFCB.1080900@gmail.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> <5011AFCB.1080900@gmail.com> Date: Thu, 26 Jul 2012 14:22:50 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" 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 Cc: ipsec@ietf.org, Johannes Merkle , Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 21:22:50 -0000 On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: > Hi Tero, > > the fact that we need to study the protocol details and go into the > ASN.1 bits to ascertain that we have a problem, strongly suggests to me > that non-EC DSA is not terribly important. So if we can have a *simple* > solution that also deals with this problem, fine. Otherwise, let's just > focus on ECDSA. How does one currently indicate the hash algorithm used for non-EC DSA in IKEv2 today? Dan. From kivinen@iki.fi Thu Jul 26 20:08:30 2012 Return-Path: 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 D7DA121F8535 for ; Thu, 26 Jul 2012 20:08:30 -0700 (PDT) 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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 moqpfVQ1on+5 for ; Thu, 26 Jul 2012 20:08:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6854821F8530 for ; Thu, 26 Jul 2012 20:08:28 -0700 (PDT) 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 q6R37l2Y010853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jul 2012 06:07:47 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6R37FwQ017955; Fri, 27 Jul 2012 06:07:15 +0300 (EEST) 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: <20498.1507.493980.852558@fireball.kivinen.iki.fi> Date: Fri, 27 Jul 2012 06:07:15 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> <5011AFCB.1080900@gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: ipsec@ietf.org, Johannes Merkle Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 03:08:31 -0000 Dan Harkins writes: > On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: > > the fact that we need to study the protocol details and go into the > > ASN.1 bits to ascertain that we have a problem, strongly suggests to me > > that non-EC DSA is not terribly important. So if we can have a *simple* > > solution that also deals with this problem, fine. Otherwise, let's just > > focus on ECDSA. > > How does one currently indicate the hash algorithm used for non-EC DSA > in IKEv2 today? Same way than IKEv1 does it, meaning it is assumed to be SHA-1. Also I would be more happy to reuse the stuff from PKIX than adding new registy for hashes. This would simplify the auth payload processing too as the domain parameters and hash both could be seen from the same place (i.e. from the auth payload) and then we do not need to add stuff to this registry when new hash functions are added, we can just assume someone will allocate oids for them. -- kivinen@iki.fi From dharkins@lounge.org Thu Jul 26 23:30:51 2012 Return-Path: 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 BFDC111E80D6 for ; Thu, 26 Jul 2012 23:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 nsXp8MAX83mI for ; Thu, 26 Jul 2012 23:30:51 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC3711E80D3 for ; Thu, 26 Jul 2012 23:30:51 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 766DB10224008; Thu, 26 Jul 2012 23:30:50 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 26 Jul 2012 23:30:51 -0700 (PDT) Message-ID: In-Reply-To: <20498.1507.493980.852558@fireball.kivinen.iki.fi> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> <5011AFCB.1080900@gmail.com> <20498.1507.493980.852558@fireball.kivinen.iki.fi> Date: Thu, 26 Jul 2012 23:30:51 -0700 (PDT) From: "Dan Harkins" To: "Tero Kivinen" 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 Cc: ipsec@ietf.org, Johannes Merkle , Dan Harkins Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 06:30:51 -0000 On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: > Dan Harkins writes: >> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >> > the fact that we need to study the protocol details and go into the >> > ASN.1 bits to ascertain that we have a problem, strongly suggests to >> me >> > that non-EC DSA is not terribly important. So if we can have a >> *simple* >> > solution that also deals with this problem, fine. Otherwise, let's >> just >> > focus on ECDSA. >> >> How does one currently indicate the hash algorithm used for non-EC DSA >> in IKEv2 today? > > Same way than IKEv1 does it, meaning it is assumed to be SHA-1. OK, so you're admitting that there's a problem with non-EC DSA in IKEv2. Good, I agree. I would say the inability for IKEv2 to construct a signature that is valid today according to FIPS 186-3 is a problem and we should address it. > Also I would be more happy to reuse the stuff from PKIX than adding > new registy for hashes. This would simplify the auth payload > processing too as the domain parameters and hash both could be seen > from the same place (i.e. from the auth payload) and then we do not > need to add stuff to this registry when new hash functions are added, > we can just assume someone will allocate oids for them. The domain parameter comes from the CERT payload not the AUTH payload. In any event there's 1 bunch of 8 RESERVED bits and then on the next aligned ulong there's another 24, that's 32 available but disjoint bits. How do you propose encoding an OID into the AUTH payload? Dan. From ynir@checkpoint.com Fri Jul 27 00:13:46 2012 Return-Path: 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 6DADA21F8518 for ; Fri, 27 Jul 2012 00:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 fwSGbvKL0ajf for ; Fri, 27 Jul 2012 00:13:45 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8DA21F851B for ; Fri, 27 Jul 2012 00:13:44 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id q6R7Dgdd004029; Fri, 27 Jul 2012 10:13:42 +0300 X-CheckPoint: {50123D60-6-1B221DC2-4FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 27 Jul 2012 10:13:40 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 27 Jul 2012 10:13:38 +0300 From: Yoav Nir To: Dan Harkins Date: Fri, 27 Jul 2012 10:13:37 +0300 Thread-Topic: [IPsec] Using ECC Brainpool curves with ipsec Thread-Index: Ac1rx1e+QorSKvlKSv2gDsC9Qqj32g== Message-ID: <1BE8F074-3F6E-49EC-B912-3BDA4052F629@checkpoint.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> <5011AFCB.1080900@gmail.com> <20498.1507.493980.852558@fireball.kivinen.iki.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 11c25c4fbf8a53dbfc96eae8e41218137effd5ee51 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "ipsec@ietf.org" , Johannes Merkle , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 07:13:46 -0000 On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote: >=20 > On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: >> Dan Harkins writes: >>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >>>> the fact that we need to study the protocol details and go into the >>>> ASN.1 bits to ascertain that we have a problem, strongly suggests to >>> me >>>> that non-EC DSA is not terribly important. So if we can have a >>> *simple* >>>> solution that also deals with this problem, fine. Otherwise, let's >>> just >>>> focus on ECDSA. >>>=20 >>> How does one currently indicate the hash algorithm used for non-EC DSA >>> in IKEv2 today? >>=20 >> Same way than IKEv1 does it, meaning it is assumed to be SHA-1. >=20 > OK, so you're admitting that there's a problem with non-EC DSA in > IKEv2. Good, I agree. I would say the inability for IKEv2 to construct > a signature that is valid today according to FIPS 186-3 is a problem > and we should address it. Is that "we" as in the IPsecME group, or "we" the design team? Either way, = non-EC DSA is hardly used. There are effectively zero certificates on https= servers using it. People preferred RSA even in the days when RSA had to be= licensed and DSA was free. Why do we need to fix it now? >> Also I would be more happy to reuse the stuff from PKIX than adding >> new registy for hashes. This would simplify the auth payload >> processing too as the domain parameters and hash both could be seen >> from the same place (i.e. from the auth payload) and then we do not >> need to add stuff to this registry when new hash functions are added, >> we can just assume someone will allocate oids for them. >=20 > The domain parameter comes from the CERT payload not the AUTH > payload. In any event there's 1 bunch of 8 RESERVED bits and then on the > next aligned ulong there's another 24, that's 32 available but disjoint > bits. How do you propose encoding an OID into the AUTH payload? One way is to just place the ASN.1 structure similar to a certificate signa= ture: a sequence containing an OID and a bitstring. That structure can be p= laced there as the "Authentication Data" field. The only issue I have with = that is that there is no negotiation about support for the algorithm, so th= e OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not eve= n support SHA2-224, but that problem exists also with encoding the SHA2-224= in the currently reserved fields.=20 The advantage is that no specification would need to be updated when a new = hash function is defined. As long as it has an OID, the spec supports it wi= th no change. Yoav= From yaronf.ietf@gmail.com Fri Jul 27 01:19:58 2012 Return-Path: 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 5C9EB21F8496 for ; Fri, 27 Jul 2012 01:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Git-Ec5OIBgR for ; Fri, 27 Jul 2012 01:19:57 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E27221F8478 for ; Fri, 27 Jul 2012 01:19:56 -0700 (PDT) Received: by bkty7 with SMTP id y7so1651989bkt.31 for ; Fri, 27 Jul 2012 01:19:55 -0700 (PDT) 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=U3i/nw+Xg8sKP8rXbGibeVsh4sNax2JcKbO9iRxQ/DQ=; b=UiR5zfgsJSNnNe4Tw3IaV2BdV/uTc9LhaXa/CLVEo7FCwwlSaizeWy6ojoyHtUEkN4 w8ujjzlcC++Fo9HOPJU2h36wmwb4Ve9ZodXp7QkSenKX8qe8fE2WySemGnEf6JJ2AqqE 1dhqjkKnGcw/sp7eEjyhmhKWjD1c4muMMNGFbD4dRvAcCK9qOS9IeCPpiUvBKGtc+/Rb Y7k8snrPw6LU4akqx1zLusOpPvXkotLLZ8gV6TewX0FQTWRBDqy7m9Ko4H987epVt+/1 f+A+65JZg+sGu3+FDeuqOsMRfMqLze9xiy/nLe+goLEiKyJOf1G5CWvD2DW2GR34QY/d cXhw== Received: by 10.204.154.151 with SMTP id o23mr582431bkw.77.1343377195447; Fri, 27 Jul 2012 01:19:55 -0700 (PDT) Received: from [10.0.0.4] ([109.67.179.185]) by mx.google.com with ESMTPS id n17sm476814bks.6.2012.07.27.01.19.53 (version=SSLv3 cipher=OTHER); Fri, 27 Jul 2012 01:19:54 -0700 (PDT) Message-ID: <50124F28.2020702@gmail.com> Date: Fri, 27 Jul 2012 11:19:52 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 MIME-Version: 1.0 To: Yoav Nir References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> <5011AFCB.1080900@gmail.com> <20498.1507.493980.852558@fireball.kivinen.iki.fi> <1BE8F074-3F6E-49EC-B912-3BDA4052F629@checkpoint.com> In-Reply-To: <1BE8F074-3F6E-49EC-B912-3BDA4052F629@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , Johannes Merkle , Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 08:19:58 -0000 Hi Yoav, I would take a new IANA registry over embedded ASN.1 snippets any time. Just my personal opinion, of course. Thanks, Yaron On 07/27/2012 10:13 AM, Yoav Nir wrote: > > On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote: > >> >> On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: >>> Dan Harkins writes: >>>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >>>>> the fact that we need to study the protocol details and go into the >>>>> ASN.1 bits to ascertain that we have a problem, strongly suggests to >>>> me >>>>> that non-EC DSA is not terribly important. So if we can have a >>>> *simple* >>>>> solution that also deals with this problem, fine. Otherwise, let's >>>> just >>>>> focus on ECDSA. >>>> >>>> How does one currently indicate the hash algorithm used for non-EC DSA >>>> in IKEv2 today? >>> >>> Same way than IKEv1 does it, meaning it is assumed to be SHA-1. >> >> OK, so you're admitting that there's a problem with non-EC DSA in >> IKEv2. Good, I agree. I would say the inability for IKEv2 to construct >> a signature that is valid today according to FIPS 186-3 is a problem >> and we should address it. > > Is that "we" as in the IPsecME group, or "we" the design team? Either way, non-EC DSA is hardly used. There are effectively zero certificates on https servers using it. People preferred RSA even in the days when RSA had to be licensed and DSA was free. Why do we need to fix it now? > >>> Also I would be more happy to reuse the stuff from PKIX than adding >>> new registy for hashes. This would simplify the auth payload >>> processing too as the domain parameters and hash both could be seen >>> from the same place (i.e. from the auth payload) and then we do not >>> need to add stuff to this registry when new hash functions are added, >>> we can just assume someone will allocate oids for them. >> >> The domain parameter comes from the CERT payload not the AUTH >> payload. In any event there's 1 bunch of 8 RESERVED bits and then on the >> next aligned ulong there's another 24, that's 32 available but disjoint >> bits. How do you propose encoding an OID into the AUTH payload? > > One way is to just place the ASN.1 structure similar to a certificate signature: a sequence containing an OID and a bitstring. That structure can be placed there as the "Authentication Data" field. The only issue I have with that is that there is no negotiation about support for the algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not even support SHA2-224, but that problem exists also with encoding the SHA2-224 in the currently reserved fields. > > The advantage is that no specification would need to be updated when a new hash function is defined. As long as it has an OID, the spec supports it with no change. > > Yoav > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From dharkins@lounge.org Fri Jul 27 08:51:33 2012 Return-Path: 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 9E7DB21F8797 for ; Fri, 27 Jul 2012 08:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 SzbJW2+uuo1M for ; Fri, 27 Jul 2012 08:51:33 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 14B1D21F8688 for ; Fri, 27 Jul 2012 08:51:33 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AA66310224008; Fri, 27 Jul 2012 08:51:32 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 27 Jul 2012 08:51:32 -0700 (PDT) Message-ID: In-Reply-To: <1BE8F074-3F6E-49EC-B912-3BDA4052F629@checkpoint.com> References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> <5011AFCB.1080900@gmail.com> <20498.1507.493980.852558@fireball.kivinen.iki.fi> <1BE8F074-3F6E-49EC-B912-3BDA4052F629@checkpoint.com> Date: Fri, 27 Jul 2012 08:51:32 -0700 (PDT) From: "Dan Harkins" To: "Yoav Nir" 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 Cc: "ipsec@ietf.org" , Johannes Merkle , Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jul 2012 15:51:33 -0000 On Fri, July 27, 2012 12:13 am, Yoav Nir wrote: > > On Jul 27, 2012, at 9:30 AM, Dan Harkins wrote: > >> >> On Thu, July 26, 2012 8:07 pm, Tero Kivinen wrote: >>> Dan Harkins writes: >>>> On Thu, July 26, 2012 1:59 pm, Yaron Sheffer wrote: >>>>> the fact that we need to study the protocol details and go into the >>>>> ASN.1 bits to ascertain that we have a problem, strongly suggests to >>>> me >>>>> that non-EC DSA is not terribly important. So if we can have a >>>> *simple* >>>>> solution that also deals with this problem, fine. Otherwise, let's >>>> just >>>>> focus on ECDSA. >>>> >>>> How does one currently indicate the hash algorithm used for non-EC >>>> DSA >>>> in IKEv2 today? >>> >>> Same way than IKEv1 does it, meaning it is assumed to be SHA-1. >> >> OK, so you're admitting that there's a problem with non-EC DSA in >> IKEv2. Good, I agree. I would say the inability for IKEv2 to construct >> a signature that is valid today according to FIPS 186-3 is a problem >> and we should address it. > > Is that "we" as in the IPsecME group, or "we" the design team? Either way, > non-EC DSA is hardly used. There are effectively zero certificates on > https servers using it. People preferred RSA even in the days when RSA had > to be licensed and DSA was free. Why do we need to fix it now? I meant "we" as the WG. I think this design team is working at the pleasure of the WG anyway. I'm not sure why a survey of https servers can accurately gauge the use of DSA in IKEv2. One could also look at it in the light that the SHA-1-only nature of DSA in IKEv2 only became a problem recently (as FIPS 186-3 and SP 800-57 say such signatures were valid only through 2010). The reason we need to fix it now is that IKEv2 cannot produce a valid DSA signature today and unless IKEv3 is just around the corner I'd say we should fix it in IKEv2 (and given the sound of crickets I hear every time I bring up IKEv3 I'm less inclined to think it's just around the corner). >>> Also I would be more happy to reuse the stuff from PKIX than adding >>> new registy for hashes. This would simplify the auth payload >>> processing too as the domain parameters and hash both could be seen >>> from the same place (i.e. from the auth payload) and then we do not >>> need to add stuff to this registry when new hash functions are added, >>> we can just assume someone will allocate oids for them. >> >> The domain parameter comes from the CERT payload not the AUTH >> payload. In any event there's 1 bunch of 8 RESERVED bits and then on the >> next aligned ulong there's another 24, that's 32 available but disjoint >> bits. How do you propose encoding an OID into the AUTH payload? > > One way is to just place the ASN.1 structure similar to a certificate > signature: a sequence containing an OID and a bitstring. That structure > can be placed there as the "Authentication Data" field. The only issue I > have with that is that there is no negotiation about support for the > algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the > receiver does not even support SHA2-224, but that problem exists also with > encoding the SHA2-224 in the currently reserved fields. > > The advantage is that no specification would need to be updated when a new > hash function is defined. As long as it has an OID, the spec supports it > with no change. Yes that would work. Since there would be a new AUTH method we could overload the Authentication Data field. It seems sort of a "6 of one; half dozen of the other" kind of thing but I guess "we" can decide that. Dan. From kivinen@iki.fi Sat Jul 28 14:17:37 2012 Return-Path: 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 A1B2721F86A0 for ; Sat, 28 Jul 2012 14:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 QjTYaXgUnvwd for ; Sat, 28 Jul 2012 14:17:37 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1CE21F8685 for ; Sat, 28 Jul 2012 14:17:36 -0700 (PDT) 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 q6SLHXwk006600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jul 2012 00:17:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id q6SLHUkV014555; Sun, 29 Jul 2012 00:17:30 +0300 (EEST) 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: <20500.22250.653151.122391@fireball.kivinen.iki.fi> Date: Sun, 29 Jul 2012 00:17:30 +0300 From: Tero Kivinen To: "Dan Harkins" In-Reply-To: References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> <5011AFCB.1080900@gmail.com> <20498.1507.493980.852558@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 45 min X-Total-Time: 60 min Cc: ipsec@ietf.org, Johannes Merkle Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2012 21:17:37 -0000 Dan Harkins writes: > >> How does one currently indicate the hash algorithm used for non-EC DSA > >> in IKEv2 today? > > > > Same way than IKEv1 does it, meaning it is assumed to be SHA-1. > > OK, so you're admitting that there's a problem with non-EC DSA in > IKEv2. Good, I agree. I would say the inability for IKEv2 to construct > a signature that is valid today according to FIPS 186-3 is a problem > and we should address it. Yes, and no. I agree there is spefication problem as the RFC5996 says SHA-1, when it should not say anything about has algorithm and left that to the FIPS 186-3. I would expect most implementations which support longer non-EC DSA keys than what SHA-1 is enough for, most likely already do use SHA-2 for those regardless what RFC5996 says (i.e. they uses fips specification as more authorative when selecting the hash algorithm than the example in the RFC5996). I do agree we should solve this now. > The domain parameter comes from the CERT payload not the AUTH > payload. In any event there's 1 bunch of 8 RESERVED bits and then on the > next aligned ulong there's another 24, that's 32 available but disjoint > bits. How do you propose encoding an OID into the AUTH payload? ---------------------------------------------------------------------- Using following payload format: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Method | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Authentication Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and adding new auth method Generic DSA and say that the authentication data field of the auth payload will have following format: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Signature Algorithm ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Signature Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where * Signature Algorithm is AlgorithmIdentifier ASN.1 blob from the RFC5280 section 4.1.1.2 * Signature Data will be the actual signature value as specified in the FIPS-186-3 section 4.6, i.e. (r,s). Note, that the Signature Algorithm is ASN.1 SEQUENCE containing the OID and optional parameters, and its length can be seen from the SEQUENCE ASN.1 part. There is no padding between the Signature Algorithm and Signature Data field, the Signature Data field is directly concatenated to the Signature Algorithm field. ---------------------------------------------------------------------- In normal case that will add around 13-16 bytes to the Auth payload, and it will solve the problem for both non-EC DSA and ECDSA. The ASN.1 object of Signature Algorithm will usually be something like: 0x30 0x0b - SEQUENCE 0x06 0x07 - OBJECT IDENTIFIER 0x2a 0x86 0x48 0xce 0x38 0x04 0x03 - 1.2.840.10040.4.3 dsa-with-sha1 0x05 0x00 - NULL or 0x30 0x0c - SEQUENCE 0x06 0x08 - OBJECT IDENTIFIER 0x2a 0x86 0x48 0xce 0x3d 0x04 0x03 0x02 - 1.2. 840. 10045. 4. 3 2 ecdsa-with-SHA256(2) 0x05 0x00 - NULL (Not sure if the ecdsa-with-SHA256(2) is correct oid for this, just grabbing some random oid from google, also the asn1 encoding might be wrong as was just manually doing it while writing the email). Another option would be to use bit more asn.1, i.e. say that authentication data is: authenticationData ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } which would add 2 for initial sequence + 2 bytes for bit string header for before the signature value, but I think the first version is better, as the implementation can simply compare the initial bytes against internal table if it does not want do asn.1 parsing here. -- kivinen@iki.fi From mglt.ietf@gmail.com Sun Jul 29 21:59:56 2012 Return-Path: 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 4C65B11E8098; Sun, 29 Jul 2012 21:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[AWL=5.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 ptel42S0Lg5N; Sun, 29 Jul 2012 21:59:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 19CE711E808D; Sun, 29 Jul 2012 21:59:55 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so9609513obb.31 for ; Sun, 29 Jul 2012 21:59:54 -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 :content-type; bh=zE2BOgMcSpohu0AoLjHeV/XRKjY3/49Dv5K3z1cJR48=; b=hXCXCgwPe/jpwPn+pACfBv8Kyn0AAk5gX+gKZqg4XrAL5cOaY72l3SIDVqXtsh4snN e3DkE87h/RQlOOrjoPaK8fb7ZZCcsJ73sZYxJQhHbX8RYdWcyZk2DlWnIN63mjXDqde1 xTinItLbZzVU6U6GQxNKKYYrVRScCQHoAe1fWckkIQHvnlnHGVRBrb4ap8ia2/op5KAR locmyhwnRAuDbeBhqL15yrS+sE0zuERCFsM1ujz2/mdaKARtU5hA5HrrpIqt7ImuC+Qo PvYnJPY0/olHAEg2zr0mhk1te1RXuy5a5mx0F0wPwKETmu3uzTI6Cd/lvXUgWCem6H2V dnVw== MIME-Version: 1.0 Received: by 10.182.225.100 with SMTP id rj4mr15428142obc.64.1343624394569; Sun, 29 Jul 2012 21:59:54 -0700 (PDT) Received: by 10.182.196.38 with HTTP; Sun, 29 Jul 2012 21:59:54 -0700 (PDT) In-Reply-To: <20120730045037.978.65071.idtracker@ietfa.amsl.com> References: <20120730045037.978.65071.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 06:59:54 +0200 Message-ID: From: Daniel Migault To: mif@ietf.org, ipsec@ietf.org, multipathtcp@ietf.org Content-Type: multipart/alternative; boundary=14dae93993bbbff99004c604eed1 Subject: [IPsec] Fwd: New Version Notification for draft-mglt-mif-security-requirements-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 04:59:56 -0000 --14dae93993bbbff99004c604eed1 Content-Type: text/plain; charset=ISO-8859-1 Please find the new version of IPsec security requirements with Multiple Interfaces. Comments and suggestions are welcome BR Daniel ---------- Forwarded message ---------- From: Date: Mon, Jul 30, 2012 at 6:50 AM Subject: New Version Notification for draft-mglt-mif-security-requirements-02.txt To: mglt.ietf@gmail.com Cc: carlw@mcsr-labs.org A new version of I-D, draft-mglt-mif-security-requirements-02.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Filename: draft-mglt-mif-security-requirements Revision: 02 Title: IPsec Multiple Interfaces Requirements Creation date: 2012-07-30 WG ID: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-mglt-mif-security-requirements-02.txt Status: http://datatracker.ietf.org/doc/draft-mglt-mif-security-requirements Htmlized: http://tools.ietf.org/html/draft-mglt-mif-security-requirements-02 Diff: http://tools.ietf.org/rfcdiff?url2=draft-mglt-mif-security-requirements-02 Abstract: Multiple Interface Nodes (MIF Nodes) may use their Multiple Interfaces to perform Mobility, Multihoming. Then, these MIF Nodes may also manage traffic between these Multiple Interfaces. Because IPsec has not been designed for Multiple Interfaces, MIF Nodes have difficulties to benefit from MIF features with IPsec protected communications. This document provides use cases where IPsec protected communications would take advantage of MIF features. From these uses cases, we identify the different IPsec features MIF Nodes would require. Then, we expose the limitations of the IPsec related protocols IKEv2 and MOBIKE regarding to these MIF features before listing the MIF IPsec Security Requirements that should be address by a extension of IKEv2 or MOBIKE. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --14dae93993bbbff99004c604eed1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please find the new version of IPsec security requirements with Multiple In= terfaces.

Comments and suggestions are welcome

BR

Dani= el

---------- Forwarded message ---------= -
From: <internet-drafts@ietf.org>
= Date: Mon, Jul 30, 2012 at 6:50 AM
Subject: New Version Notification for= draft-mglt-mif-security-requirements-02.txt
To: mglt.ietf@gmail.com
Cc: <= a href=3D"mailto:carlw@mcsr-labs.org">carlw@mcsr-labs.org


A new version of I-D, draft-mglt-mif-security-requirements-02.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-mglt-mif-security-requirements
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 IPsec Multiple Interfaces Requirements
Creation date: =A0 2012-07-30
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.= ietf.org/internet-drafts/draft-mglt-mif-security-requirements-02.txt Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.= org/doc/draft-mglt-mif-security-requirements
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/d= raft-mglt-mif-security-requirements-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://tools.= ietf.org/rfcdiff?url2=3Ddraft-mglt-mif-security-requirements-02

Abstract:
=A0 =A0Multiple Interface Nodes (MIF Nodes) may use their Multiple
=A0 =A0Interfaces to perform Mobility, Multihoming. =A0Then, these MIF Node= s
=A0 =A0may also manage traffic between these Multiple Interfaces. =A0Becaus= e
=A0 =A0IPsec has not been designed for Multiple Interfaces, MIF Nodes have<= br> =A0 =A0difficulties to benefit from MIF features with IPsec protected
=A0 =A0communications.

=A0 =A0This document provides use cases where IPsec protected communication= s
=A0 =A0would take advantage of MIF features. =A0From these uses cases, we =A0 =A0identify the different IPsec features MIF Nodes would require. =A0Th= en,
=A0 =A0we expose the limitations of the IPsec related protocols IKEv2 and =A0 =A0MOBIKE regarding to these MIF features before listing the MIF IPsec<= br> =A0 =A0Security Requirements that should be address by a extension of IKEv2=
=A0 =A0or MOBIKE.




The IETF Secretariat



--
Daniel Migault
Orange Labs -- Sec= urity
+33 6 70 72 69 58
--14dae93993bbbff99004c604eed1-- From Johannes.Merkle@secunet.com Mon Jul 30 02:28:33 2012 Return-Path: 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 8CB1D21F8720 for ; Mon, 30 Jul 2012 02:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] 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 w0gl0Penlkvx for ; Mon, 30 Jul 2012 02:28:33 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id AD34521F869F for ; Mon, 30 Jul 2012 02:28:32 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 0AD711A007F; Mon, 30 Jul 2012 11:26:59 +0200 (CEST) X-Virus-Scanned: by secunet Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 7EAA01A0066; Mon, 30 Jul 2012 11:26:53 +0200 (CEST) Received: from [10.208.1.73] ([10.208.1.73]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Jul 2012 11:28:22 +0200 Message-ID: <501653B6.9030009@secunet.com> Date: Mon, 30 Jul 2012 11:28:22 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Yoav Nir References: <4FF316DF.6050109@secunet.com> <20487.1106.571589.307917@fireball.kivinen.iki.fi> <50098548.5040609@secunet.com> <20490.53579.25865.193739@fireball.kivinen.iki.fi> <799b5b85c37f8b81eabca2cddcb5a6ce.squirrel@www.trepanning.net> <500D362C.4020501@secunet.com> <95ec732dcc9d9164e36f3019ffd714cb.squirrel@www.trepanning.net> <500DA2EB.209@secunet.com> <13a9196e15008e918263dc619194895e.squirrel@www.trepanning.net> <500E8433.7020002@secunet.com> <20497.17519.926893.965011@fireball.kivinen.iki.fi> <5011AFCB.1080900@gmail.com> <20498.1507.493980.852558@fireball.kivinen.iki.fi> <1BE8F074-3F6E-49EC-B912-3BDA4052F629@checkpoint.com> In-Reply-To: <1BE8F074-3F6E-49EC-B912-3BDA4052F629@checkpoint.com> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2012 09:28:22.0861 (UTC) FILETIME=[AA085FD0:01CD6E35] Cc: "ipsec@ietf.org" , Dan Harkins , Tero Kivinen Subject: Re: [IPsec] Using ECC Brainpool curves with ipsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 09:28:33 -0000 > >>> Also I would be more happy to reuse the stuff from PKIX than adding >>> new registy for hashes. This would simplify the auth payload >>> processing too as the domain parameters and hash both could be seen >>> from the same place (i.e. from the auth payload) and then we do not >>> need to add stuff to this registry when new hash functions are added, >>> we can just assume someone will allocate oids for them. >> >> The domain parameter comes from the CERT payload not the AUTH >> payload. In any event there's 1 bunch of 8 RESERVED bits and then on the >> next aligned ulong there's another 24, that's 32 available but disjoint >> bits. How do you propose encoding an OID into the AUTH payload? > > One way is to just place the ASN.1 structure similar to a certificate signature: a sequence containing an OID and a bitstring. That structure can be placed there as the "Authentication Data" field. The only issue I have with that is that there is no negotiation about support for the algorithm, so the OID may turn out to be ECDSA-with-SHA2-224 when the receiver does not even support SHA2-224, but that problem exists also with encoding the SHA2-224 in the currently reserved fields. > > The advantage is that no specification would need to be updated when a new hash function is defined. As long as it has an OID, the spec supports it with no change. > This is a good solution, which can be used not only for ECDSA but for any signature method. So the question is if the new auth method should be defined for ECDSA only (generic_ECDSA) or for a broader scope (generic_ECC_signature, generic_signature). Johannes From paul@cypherpunks.ca Tue Jul 31 08:31:21 2012 Return-Path: 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 D4AD521F86BA; Tue, 31 Jul 2012 08:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.236 X-Spam-Level: X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, SUBJ_ALL_CAPS=2.077] 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 y1N2FLjPKYRg; Tue, 31 Jul 2012 08:31:21 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 53E4D21F86C2; Tue, 31 Jul 2012 08:31:20 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 324B582574; Tue, 31 Jul 2012 11:31:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 22CD18043D; Tue, 31 Jul 2012 11:31:00 -0400 (EDT) Date: Tue, 31 Jul 2012 11:31:00 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: dane WG list , "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [IPsec] IPSEC & DANE (RFC4025) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 15:31:22 -0000 The IPSECKEY issue came up a few times today in the dane meeting without being explained. This is the issue (see https://tools.ietf.org/html/rfc4025 ) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | precedence | gateway type | algorithm | gateway | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + ~ gateway ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | / / public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| You can specify a gateway. So one could have: www.google.com. IN IPSECKEY 10 1 2 1.2.3.4 This would instruct ipsec clients supporting IPSECKEY to initiate IKE with RSA and said public key to 1.2.3.4 for all traffic to www.google.com. This allows one to specify a dedicated IPsec machine. I can put in: paul.example.com. IN IPSECKEY 10 1 2 1.2.3.4 Of course, I don't control 1.2.3.4 (google does), which has IKE using keyblob and not otherkeyblob. So it will fail to establish a working IPsec tunnel. But my kernel SPD/SAD can only have one src:dst policy. In the case of failure to do IKE, this would be a block to prevent plaintext leaks. So if i can trick a client into connecting to paul.example.com, I can ensure that user will not be able to talk to www.google.com. Clearly, a lot of this will depend on local policy/implementation that is not specified in any RFC. And depending on soft vs hard fail this would be a DoS or a downgrade attack. The core problem is that anyone can make a claim about someone elses' IP address with respect to the public key. We have no way of knowing who is telling the truth here. We could if we placed the key in the reverse, but that's exactly what freeswan/openswan tried to do, and in reality no one really controls their reverse to add records to it. The difference with TLS is that the client has a concept of the terminal name it connected to, and has its own src-dst transport, whereas for IPsec we only have one src-dst for the entire host. Paul From mcr+ietf@sandelman.ca Tue Jul 31 11:03:16 2012 Return-Path: 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 336CD21F8899; Tue, 31 Jul 2012 11:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.772 X-Spam-Level: X-Spam-Status: No, score=-1.772 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 GncFQb2Jma8I; Tue, 31 Jul 2012 11:03:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id AB8D821F8552; Tue, 31 Jul 2012 11:03:15 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EE732016A; Tue, 31 Jul 2012 14:15:35 -0400 (EDT) From: Michael Richardson To: Paul Wouters In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: "ipsec@ietf.org WG" , dane WG list Subject: Re: [IPsec] [dane] IPSEC & DANE (RFC4025) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 18:03:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Paul" =3D=3D Paul Wouters writes: Paul> But my kernel SPD/SAD can only have one src:dst policy. In the ca= se of Paul> failure to do IKE, this would be a block to prevent plaintext lea= ks. Paul> So if i can trick a client into connecting to paul.example.com, I= can Paul> ensure that user will not be able to talk to www.google.com. This "attack" and the usage you gave for IPSECKEY is not consistent with RF= C4322. By the time that IPSECKEY RR was approved, RFC4322 was already approved (don't be confused by the order of the document numbers...). RFC4322 spec= ifies TXT RR. An RFC4322-bis that specified IPSECKEY, and IKEv2 was envisioned, but never compelted. Paul> Clearly, a lot of this will depend on local policy/implementation= that Paul> is not specified in any RFC. And depending on soft vs hard fail t= his Paul> would be a DoS or a downgrade attack. RFC4322 specifies it. Section 3.2 discussed "OE-permissive" (fail-to-clear) and "OE-paranoid" (fail-to-drop) versions. Openswan by default put the 0.0.0.0/0 into OE-permissive policy bucket, so if IKE failed, then the "%hold" should get replaced with a %pass. Paul> The core problem is that anyone can make a claim about someone el= ses' Paul> IP address with respect to the public key. We have no way of know= ing "claim", yes, but not enforce. OE failed initially because of lack of control over reverse, and later, due to there being no reverse for systems on the NATwork. Paul> The difference with TLS is that the client has a concept of the Paul> terminal name it connected to, and has its own src-dst transport, Paul> whereas for IPsec we only have one src-dst for the entire host. Agreed. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBgd34qHRg3pndX9AQLPjgQAuw6q7c1NmCoWemgU1AVpk2iX0WP4DGip TexO3Fk+U+Wn5/dCJ6UeVdPStYsxDTzMqOJOD0I9O8XdYjeh7eqasp12N46MYNPM zm/RABtSdfoJHsgd1jv0JZnue/d7nvZU3CGA15ACPBq1l7zEmHvlz7raG3RG9TtC LcMQNDqJFo8= =XnzV -----END PGP SIGNATURE----- --=-=-=-- From paul@cypherpunks.ca Tue Jul 31 13:59:17 2012 Return-Path: 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 51F3E21F88C0; Tue, 31 Jul 2012 13:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] 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 4NAOB6rsFXRm; Tue, 31 Jul 2012 13:59:16 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id CE12021F869E; Tue, 31 Jul 2012 13:59:16 -0700 (PDT) Received: by bofh.nohats.ca (Postfix, from userid 500) id 4A4C18256F; Tue, 31 Jul 2012 16:58:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 420288050D; Tue, 31 Jul 2012 16:58:56 -0400 (EDT) Date: Tue, 31 Jul 2012 16:58:56 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Michael Richardson In-Reply-To: <4896.1343757791@obiwan.sandelman.ca> Message-ID: References: <4896.1343757791@obiwan.sandelman.ca> User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "ipsec@ietf.org WG" , dane WG list Subject: Re: [IPsec] [dane] IPSEC & DANE (RFC4025) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 20:59:17 -0000 On Tue, 31 Jul 2012, Michael Richardson wrote: > Paul> But my kernel SPD/SAD can only have one src:dst policy. In the case of > Paul> failure to do IKE, this would be a block to prevent plaintext leaks. > > Paul> So if i can trick a client into connecting to paul.example.com, I can > Paul> ensure that user will not be able to talk to www.google.com. > > This "attack" and the usage you gave for IPSECKEY is not consistent with RFC4322. Isn't it stating the same with different syntactic sugar? 4.3.2.1.in-addr.arpa. IN TXT X-IPsec-Server(P)=A.B.C.D public-key So if I control the reverse 4.3.2.1 and trick you into a lookup for OE, and put google's A.B.C.D with "boguspublic-key" in there, wouldn't I have the exact same issue? And as per 4322, I could have my records DNSSEC signed. It doesn't help google. > RFC4322 specifies it. > Section 3.2 discussed "OE-permissive" (fail-to-clear) and "OE-paranoid" > (fail-to-drop) versions. Openswan by default put the 0.0.0.0/0 into > OE-permissive policy bucket, so if IKE failed, then the "%hold" should > get replaced with a %pass. So what happens in my case? Either google is blocked, or google is downgraded to plaintext. Or the application could distinguish between my suggested boguspublic-key versus the real google public-key. But again, the only authoritave way for who controls A.B.C.D can be found that reverse tree, which we deem unusable at large. > Paul> The core problem is that anyone can make a claim about someone elses' > Paul> IP address with respect to the public key. We have no way of knowing > > "claim", yes, but not enforce. > OE failed initially because of lack of control over reverse, and later, > due to there being no reverse for systems on the NATwork. Yes, and what I'm saying is that current methods for tying DANE to IPSEC fail, because there is no binding to the legitimacy of the proclaimed gateway. The simple case where a server is doing OE for itself is not an issue. That works, but I don't think that would move out of the hobby space. Paul From mcr+ietf@sandelman.ca Tue Jul 31 16:00:58 2012 Return-Path: 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 980CA21F8920; Tue, 31 Jul 2012 16:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599] 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 1YBLhvHxBDtb; Tue, 31 Jul 2012 16:00:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8EA21F8713; Tue, 31 Jul 2012 16:00:55 -0700 (PDT) Received: from obiwan.sandelman.ca (unknown [IPv6:2607:f0b0:f:2:3a60:77ff:fe38:e647]) by tuna.sandelman.ca (Postfix) with ESMTP id 839932016A; Tue, 31 Jul 2012 19:13:13 -0400 (EDT) From: Michael Richardson To: Paul Wouters In-Reply-To: References: <4896.1343757791@obiwan.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.5; XEmacs 21.4 (patch 22) 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 Cc: "ipsec@ietf.org WG" , dane WG list Subject: Re: [IPsec] [dane] IPSEC & DANE (RFC4025) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:00:58 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Paul" =3D=3D Paul Wouters writes: Paul> So what happens in my case? Either google is blocked, or google is Paul> downgraded to plaintext. Or the application could distinguish bet= ween Paul> my suggested boguspublic-key versus the real google Google is plaintext, you never had the right to speak for it. Paul> Yes, and what I'm saying is that current methods for tying DANE t= o IPSEC Paul> fail, because there is no binding to the legitimacy of the procla= imed Paul> gateway. I assume by "current methods", you mean RFC4322?=20 Or is there another proposal that I've missed?=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUBhjoYqHRg3pndX9AQKvpwP/Z83aLbvtS2TOjRBRGo34PTk6DW0494GR /y8VfBEVYJHIithu170bUIj+djxhjZLkt0WCXXbrelbZcO9A4rhCdclTm0sLPea4 1qftmVz3RKrvdzJ2Q0m1jlK24aTnJlfKVq+q9fan5eu3h7U2Cy6oHrITPVMf3WZs +lHrWk250lI= =lVqh -----END PGP SIGNATURE----- --=-=-=--