From nobody Thu Aug 6 09:54:26 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B16F1B31A5 for ; Thu, 6 Aug 2015 09:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV6zU6-n4-Xt for ; Thu, 6 Aug 2015 09:54:22 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9008A1B30FB for ; Thu, 6 Aug 2015 09:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1438880062; x=2302793662; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dfoxaa/63cgq7yjjSsGyRy5RiXr4j3kh39Jze8Rav7o=; b=gIKA8K01eArWgT4zzR+RCcFZhpa5igBVIXFMDBvlhfNLjy3uSqkZSn2xTVFh7Ocz 3vybkd3TxIGrKH5wBQ++jiIZLnk19bR2fbSBsXCYxFSf+FpJLTCa1PhQ86So461o 9URE22PtIFqwWkNOo458pFb1k5cUPCLMhWJI2cZdjMVu12au9M/lYsfQcnKcwQyi +VSe8DqWiLRJr8HwNBUAEpUSiLZzM2PNpEoG2nPq5nSpifAM+dDzgpe8xFDCdw5o IbuOscjm2XVZi5lHMJGrwBc/GAywiYs+Q55U8zGWhjkYpsPwD5qf+Z/Q3F1uwTty 6Ivi1SDRlZeuxu3AFaLMPw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 6A.A3.23348.E3193C55; Thu, 6 Aug 2015 09:54:22 -0700 (PDT) X-AuditID: 11973e13-f79306d000005b34-8e-55c3913e73a0 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id C1.BF.14452.EC283C55; Thu, 6 Aug 2015 08:52:46 -0700 (PDT) Received: from [17.226.23.72] (unknown [17.226.23.72]) by aniseed.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NSO00EYQ6YLZN40@aniseed.apple.com> for ipsec@ietf.org; Thu, 06 Aug 2015 09:54:21 -0700 (PDT) Content-type: multipart/alternative; boundary="Apple-Mail=_A838BD24-6B70-4074-9614-425B9AD0D08C" MIME-version: 1.0 (Mac OS X Mail 9.0 \(3069\)) From: Tommy Pauly In-reply-to: <21948.240.780663.729327@fireball.acr.fi> Date: Thu, 06 Aug 2015 09:54:20 -0700 Message-id: References: <21945.22164.460957.958095@fireball.acr.fi> <365878F7-8629-4B6F-ABB8-62C43EAD4E97@apple.com> <21948.240.780663.729327@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3069) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOLMWRmVeSWpSXmKPExsUi2FAYpWs38XCowcweNov9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr48axFUwF60sqtl6czN7A+Dyxi5GTQ0LARGLBhrlMELaYxIV7 69m6GLk4hAT2Mkos6zvEClPU8PkpVKKfSaJ/5wewhJBAH5PEik+VXYwcHMwCSRLPztaBhHkF 9CRaJ/eDlQgL2EqsWPcVbAGbgIrE8W8bmEFsTgEziaunXzGC2CwCqhI75hxlhxhjKPH2vi3E GBuJjRsvM0Os3cok8X7tQjaQhIiAosTuJ1uhjpaV2LZ1FdSdHWwSH2ekTGAUmoVw0SwkF4HY zALaEssWvmaGsDUl9ncvZ8EU15Do/DaRdQEj2ypGodzEzBzdzDxTvcSCgpxUveT83E2MoJCf bie8g/H0KqtDjAIcjEo8vBbrD4UKsSaWFVfmHmKU5mBREucV2QYUEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwFhes+ZDwwL5mB7B+TZicoZnXE4eEzDhlPk/OdhK+/b2+LRd/VsilCznSD8x lzHaEiX8+UNME8fxwJs+c6Un+P5Jlpr3M42vcP4Ztc8vF1ftO9zqcH2OzfmlkksTpvmt3Mz3 UmhzYRrrnqxcoV/hDIv/Kmx/9/mQxPbMcx8cZ1wpcxMt4dmxt1aJpTgj0VCLuag4EQCOKGYt WgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FAsrnuu6XCowdU7lhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxo1jK5gK1pdUbL04mb2B8XliFyMnh4SAiUTD56dsELaYxIV7 64FsLg4hgX4mif6dH1hBEkICfUwSKz5VdjFycDALJEk8O1sHEuYV0JNondwPViIsYCuxYt1X JhCbTUBF4vi3DcwgNqeAmcTV068YQWwWAVWJHXOOskOMMZR4e98WYoyNxMaNl5kh1m5lkni/ diHYPSICihK7n2xlgrhNVmLb1lWsExj5ZyFcMQvJFSA2s4C2xLKFr5khbE2J/d3LWTDFNSQ6 v01kXcDItopRoCg1J7HSTC+xoCAnVS85P3cTIzhIC6N2MDYstzrEKMDBqMTDe2HeoVAh1sSy 4srcQ4wSHMxKIrwP9Q+HCvGmJFZWpRblxxeV5qQWH2KU5mBREudVWgZULZCeWJKanZpakFoE k2Xi4JRqYFSLbP208nbS7a6Sd8b/2f6+n6xcvrxuhrTZy10nLlW0uN8KeLrBTz/I1lr4WdP6 XdkszaKWn16vvcmSwP0k+O48owbNK03xxXtWPNma9SqxM9B50aPXdg1T7s93fqC0P2lG67WK 3zzRzydyqVR9/f3UeXKpwZ9F5bsjOo1N/QTOr36X/nnVMWUlluKMREMt5qLiRAA7bmw1TgIA AA== Archived-At: Cc: ipsec@ietf.org, Paul Wouters Subject: Re: [IPsec] Split DNS in IKEv2 Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2015 16:54:25 -0000 --Apple-Mail=_A838BD24-6B70-4074-9614-425B9AD0D08C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 31, 2015, at 4:12 PM, Tero Kivinen wrote: >=20 > Tommy Pauly writes: >> On the topic of DNS caching, I think the draft could give >> recommendations that the cache for a domain assigned to the IKEv2 >> connection should be flushed, but would not need to go into >> implementation details. =46rom the perspective of our clients (Mac = and >> iOS), all VPN types other than IKEv2 already support split DNS >> configurations. We use a single daemon, mDNSResponder, to manage the >> cache for all applications. Whenever a split DNS configuration is >> added or removed, the cache for that domain will be flushed. >=20 > That might be enough. On the other hand applications quite often do > have their own caches too (I do not think web page does dns lookup > from local daemon for every single image on the page, as most likely > they will be from same server, and browser might also reuse old > keepalive tcp connection to the server). >=20 > I.e. if browser does dns lookup for www.example.com using global dns, > gets faked reply for IP-address of www.evil.com back, and then starts > loading the page by making connection to the www.evil.com. Now user > notices that oh, I forgot to enable VPN before loading that page, > enables VPN, VPN will flush cache, and then user will reload the page, > but unfortunately as browser still has http connection to www.evil.com > based on faked dns lookup, it will reload everything using that > connection, as there is no way for VPN to tell it to flush its > internal state. This is definitely a possibility if the browser manages its own DNS = cache and does not monitor network changes to know when to flush the = cache. However, since this problem is solved by most mainstream browsers = on the major OSes, I think we can just include a note about this in the = draft. >=20 >>>> Also if you have multiple VPN connections up and running and all of >>>> them claim that they are the only ones who want to serve ".". >>>=20 >>> I would say that if you want all DNS traffic (eg "." domain) that = would >>> only be allowed if you also get all the traffic (0.0.0.0/0). Because = in >>> that case the VPN has already taken over your security and you have >>> configured a trust relationship for everything already. >>=20 >> Yes, we also generally only let the VPN claim to resolve all DNS >> traffic if it also claims to route all IP traffic=E2=80=94this is the = =E2=80=9Cfull >> tunnel=E2=80=9D mode, and the device clearly trusts the server. >=20 > Oh, the evil vpn can ask only for ".com", ".org", ".net" etc domains, > it does not need to ask for "." to gain almost same effect... >=20 > I.e. there is all kind details we need to think here.=20 Certainly, the VPN could do this. If the client wants to be more = paranoid/restrictive, one interesting option would be to send the = requested split domains in the configuration payload, and only apply the = domains that the server replies with that are within the requested = domains. This would restrict what the server could send, in the same way = that the initiator can request restricted traffic selectors. For example, one valid exchange could be: Initiator: SPLIT-DOMAINS: (example.com , 0.0.0.0) -> Responder: <- SPLIT-DOMAINS: (mail.example.com = , 198.51.100.2; other.example.com = , 198.51.100.6) If the responder tried to claim .com, the initiator could ignore or only = send example.com . >=20 >>> So that leaves the issue of VPN service Foo claiming bar.com instead = of >>> foo.com DNS. I think for manually configured VPNs (eg classic VPN) = this >>> is not a protocol problem but a management problem. For autoamtic = VPNs >>> (eg opportunistic) I think the client MUST ignore this new option = along >>> with a bunch of other CP payload options - that is it is not a new >>> problem. >>=20 >> I agree that the issue of trusting the VPN server to assign a valid >> private domain for resolution is a management problem, not a >> protocol problem. If we trust the server to assign private routes, >> we can generally trust it to assign private domains. >=20 > That is not true with opprtunistic cases. It is easy to limit the VPN > to only do route adding for only the IP-number that was used to > connect the VPN, but ther eis no way to verify the DNS name list > returned by the server. >=20 > When connecting to the trusted domain there is no problem, as the > configuration can be trusted.=20 >=20 >> The server could just as easily assign =E2=80=9Cmalicious=E2=80=9D = routes to capture >> other services=E2=80=99 traffic as it could assign incorrect domains. = It is >> up to the client to make sure that the source is trusted. I agree >> that this is clearer for a traditional VPN, and any opportunistic >> clients must be more cautious. >=20 > Yep, or even disable the whole DNS prefix thing. On the other hand how > do plan to handle the reverse dns? Match the dns query of > x.y.z.in-addr.arpa and forward it only to tunnel which has vpn traffic > route to z.y.x network? Yes, opportunistic clients may probably want to disable the DNS domains = altogether. That should be a recommendation. The reverse DNS case is interesting. We could do it like you suggested, = although I do not have a strong opinion on this. Thanks, Tommy > --=20 > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_A838BD24-6B70-4074-9614-425B9AD0D08C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 31, 2015, at 4:12 PM, Tero Kivinen <kivinen@iki.fi> = wrote:

Tommy Pauly writes:
On the topic of DNS caching, I think the draft could give
recommendations that the cache for a domain assigned to the = IKEv2
connection should be flushed, but would not need to = go into
implementation details. =46rom the perspective of = our clients (Mac and
iOS), all VPN types other than IKEv2 = already support split DNS
configurations. We use a single = daemon, mDNSResponder, to manage the
cache for all = applications. Whenever a split DNS configuration is
added = or removed, the cache for that domain will be flushed.

That might be enough. On the = other hand applications quite often do
have their own = caches too (I do not think web page does dns lookup
from = local daemon for every single image on the page, as most likely
they will be from same server, and browser might also reuse = old
keepalive tcp connection to the server).

I.e. if browser does dns lookup for www.example.com using = global dns,
gets faked reply for IP-address of www.evil.com back, and then = starts
loading the page by making connection to the www.evil.com. Now user
notices that oh, I forgot to enable VPN before loading that = page,
enables VPN, VPN will flush cache, and then user = will reload the page,
but unfortunately as browser still = has http connection to www.evil.com
based on faked dns lookup, it = will reload everything using that
connection, as there is = no way for VPN to tell it to flush its
internal state.

This = is definitely a possibility if the browser manages its own DNS cache and = does not monitor network changes to know when to flush the cache. = However, since this problem is solved by most mainstream browsers on the = major OSes, I think we can just include a note about this in the = draft.


Also if you have multiple VPN connections up and running and = all of
them claim that they are the only ones who want to = serve ".".

I would say that if = you want all DNS traffic (eg "." domain) that would
only = be allowed if you also get all the traffic (0.0.0.0/0). Because in
that case the VPN has already taken over your security and = you have
configured a trust relationship for everything = already.

Yes, we also = generally only let the VPN claim to resolve all DNS
traffic = if it also claims to route all IP traffic=E2=80=94this is the =E2=80=9Cful= l
tunnel=E2=80=9D mode, and the device clearly trusts the = server.

Oh, the evil vpn can = ask only for ".com", ".org", ".net" etc domains,
it does = not need to ask for "." to gain almost same effect...

I.e. there is all kind details we need to think here.

Certainly, the VPN could do this. If the client = wants to be more paranoid/restrictive, one interesting option would be = to send the requested split domains in the configuration payload, and = only apply the domains that the server replies with that are within the = requested domains. This would restrict what the server could send, in = the same way that the initiator can request restricted traffic = selectors.

For example, one valid = exchange could be:

Initiator:
SPLIT-DOMAINS: (example.com, 0.0.0.0) = ->

= Responder:
= <- = SPLIT-DOMAINS: (mail.example.com, 198.51.100.2; other.example.com, 198.51.100.6)

If the responder tried to claim .com, the = initiator could ignore or only send example.com.


So that = leaves the issue of VPN service Foo claiming bar.com instead of
foo.com DNS. I think for manually configured VPNs (eg = classic VPN) this
is not a protocol problem but a = management problem. For autoamtic VPNs
(eg opportunistic) = I think the client MUST ignore this new option along
with = a bunch of other CP payload options - that is it is not a new
problem.

I agree = that the issue of trusting the VPN server to assign a valid
private domain for resolution is a management problem, not = a
protocol problem. If we trust the server to assign = private routes,
we can generally trust it to assign = private domains.

That is not = true with opprtunistic cases. It is easy to limit the VPN
to= only do route adding for only the IP-number that was used to
connect the VPN, but ther eis no way to verify the DNS name = list
returned by the server.

When connecting to the trusted domain there is no problem, as = the
configuration can be trusted.

The server could just as = easily assign =E2=80=9Cmalicious=E2=80=9D routes to capture
other services=E2=80=99 traffic as it could assign incorrect = domains. It is
up to the client to make sure that the = source is trusted. I agree
that this is clearer for a = traditional VPN, and any opportunistic
clients must be = more cautious.

Yep, or even = disable the whole DNS prefix thing. On the other hand how
do= plan to handle the reverse dns? Match the dns query of
x.y.z.in-addr.arpa and forward it only to tunnel which has = vpn traffic
route to z.y.x network?

Yes, = opportunistic clients may probably want to disable the DNS domains = altogether. That should be a recommendation.

The reverse DNS case is interesting. We could do = it like you suggested, although I do not have a strong opinion on = this.

Thanks,
Tommy
--
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_A838BD24-6B70-4074-9614-425B9AD0D08C-- From nobody Mon Aug 10 13:09:11 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1931B2A8A for ; Mon, 10 Aug 2015 13:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qihTT5N0MEaS for ; Mon, 10 Aug 2015 13:09:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E986E1B2A6D for ; Mon, 10 Aug 2015 13:09:01 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:53195 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1ZOtNU-000NhR-9G; Mon, 10 Aug 2015 16:09:00 -0400 To: Yoav Nir , ipsec References: <55AE095E.6090300@bbn.com> <699D4CBB-8302-43E8-AD0D-A47A80A5066B@gmail.com> From: Stephen Kent Message-ID: <55C904DB.2050901@bbn.com> Date: Mon, 10 Aug 2015 16:08:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <699D4CBB-8302-43E8-AD0D-A47A80A5066B@gmail.com> Content-Type: multipart/alternative; boundary="------------090705070208030406040603" Archived-At: Subject: Re: [IPsec] P-256 speed X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 20:09:06 -0000 This is a multi-part message in MIME format. --------------090705070208030406040603 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Yoav, > Is this code available anywhere? If not, it makes it hard to reproduce > their results. There is a paper on the code design, and I anticipate the code will become available, as the work was sponsored by NIST. > It’s too bad they don’t submit this to bench.cr.yp.to so we could have > an apples-to-apples comparison with other implementations. I suspect they will do so. Steve --------------090705070208030406040603 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Yoav,

Is this code available anywhere? If not, it makes it hard to reproduce their results.
There is a paper on the code design, and I anticipate the code will become available,
as the work was sponsored by NIST.
It’s too bad they don’t submit this to bench.cr.yp.to so we could have an apples-to-apples comparison with other implementations.
I suspect they will do so.

Steve
--------------090705070208030406040603-- From nobody Tue Aug 11 07:45:08 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FB71A8A97 for ; Tue, 11 Aug 2015 07:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxH5DvlAkh3O for ; Tue, 11 Aug 2015 07:45:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74F351A901F for ; Tue, 11 Aug 2015 07:45:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWD05773; Tue, 11 Aug 2015 14:45:02 +0000 (GMT) Received: from SZXEML434-HUB.china.huawei.com (10.82.67.225) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 11 Aug 2015 15:45:01 +0100 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.251]) by szxeml434-hub.china.huawei.com ([10.82.67.225]) with mapi id 14.03.0235.001; Tue, 11 Aug 2015 22:44:39 +0800 From: Dharmanandana Reddy Pothula To: "svan@elvis.ru" , "pwouters@redhat.com" Thread-Topic: [IPSec] The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-07 Thread-Index: AQHQ1EGAjZ3Y+npme0qm+hAhnlEYhg== Date: Tue, 11 Aug 2015 14:44:38 +0000 Message-ID: <3F00A55B1B111141BAE547DB25D09FE27DCD6FC1@szxeml523-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.212.129] Content-Type: multipart/alternative; boundary="_000_3F00A55B1B111141BAE547DB25D09FE27DCD6FC1szxeml523mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "ipsec@ietf.org" Subject: [IPsec] [IPSec] The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 14:45:07 -0000 --_000_3F00A55B1B111141BAE547DB25D09FE27DCD6FC1szxeml523mbschi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As per statement under section 2.4 in RFC 7296, To prevent DoS attack on the initiator, "the initiator MAY be willing to ac= cept multiple responses to its first message, treat each response as potentially legitimate, respond to each one, and the= n discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of its req= uests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are cryptogr= aphically valid." if we apply above scenario when initiator expects authentication null from = responder, there is possibility that initiator will receive more than one c= ryptographically valid response, as per above statement, the first one should be considered and subsequent r= esponses should be ignored, but if first one is attacker and subsequent one= is genuine peer, the connection establishes with the attacker. We feel this is security risk. can you please provide more insight on this? Regards, Dharmanandana Reddy.P Perumal. V --_000_3F00A55B1B111141BAE547DB25D09FE27DCD6FC1szxeml523mbschi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

As per statement under section 2.4 in RFC 7296,

 

To prevent DoS attack on the initiator, "the initiator MAY be = willing to accept multiple responses to its first message,
treat each response as potentially legitimate, respond to each one, an= d then discard all the invalid half-open connections when it
receives a valid cryptographically protected response to any one of it= s requests.  Once a cryptographically valid response is received,
all subsequent responses should be ignored whether or not they are cry= ptographically valid."

 

if we apply above scenario when initiator expects authentication null fr= om responder, there is possibility that initiator will receive more th= an one cryptographically valid response,

as per above statement, the first one should be considered and subs= equent responses should be ignored, but if first one is attacker = and subsequent one is genuine peer, the connection establishes wi= th the attacker.

 

We feel this is security risk. can you please provide more insight = on this?

 

Regards,

Dharmanandana Reddy.P 

Perumal. V

 

 

 

--_000_3F00A55B1B111141BAE547DB25D09FE27DCD6FC1szxeml523mbschi_-- From nobody Tue Aug 11 08:31:03 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 750A01A0063 for ; Tue, 11 Aug 2015 08:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.67 X-Spam-Level: X-Spam-Status: No, score=0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqREXBU6eInJ for ; Tue, 11 Aug 2015 08:31:00 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A880E1A0115 for ; Tue, 11 Aug 2015 08:30:59 -0700 (PDT) Received: by lagz9 with SMTP id z9so73115160lag.3 for ; Tue, 11 Aug 2015 08:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type; bh=i5FotddBrCx8/Fzj8wm2pInoyCLigQZfqMJ83muYdlA=; b=TX4O9yuqGULrwE4/bFxRALXdyqi1DhA011N/p/llTMllyV2t6u/cFngwAGlt0kqLXN tufgyPVcA96Q1jQEKaJW1CZJLWGtgt+LARJZ9n9nfHd4CMVZZtVJRYerlDoBVTM9pCym 2r+/iZlLKrtPOG58G1by7ds/yB0fNUIvlKbqh2eNP6wWTHmyuOWvJgBa6llfF0N+U35B Ewwn1q+OlJlvatqLQRyK9z4Kl3lEEHrh5lJxW9t0L908D+5kYDTMKPge0fqteFufn2Ta LgDxr7JsBn5h/OuRC9D5RYlycQpH5P21sHF6XPELSb4wVKH4FSkK460JxmBH1j60MndC Sh9Q== X-Received: by 10.152.23.4 with SMTP id i4mr27092243laf.51.1439307058155; Tue, 11 Aug 2015 08:30:58 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id kx11sm534080lac.41.2015.08.11.08.30.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 11 Aug 2015 08:30:56 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Dharmanandana Reddy Pothula" , References: <3F00A55B1B111141BAE547DB25D09FE27DCD6FC1@szxeml523-mbs.china.huawei.com> Date: Tue, 11 Aug 2015 18:30:58 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_1DCE_01D0D463.DDF0A1D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] [IPSec] The NULL Authentication Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-07 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 15:31:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_1DCE_01D0D463.DDF0A1D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dharmanandana, I don't think that the attack, described in the section 2.4 of RFC 7296 is related to NULL authentication. This attack implies that attackers send IKE_SA_INIT response containing garbage in the KE Payload and that they never compute SKEYSEED and the other keys, so that they cannot construct proper (cryptographically valid) IKE_AUTH = response.=20 However, if attackers do go further in the protocol and calculate the = keys and respond with valid IKE_AUTH response with NULL authentication, and if the NULL authentication is acceptible to the Initiator, then the=20 Initiator does connect to the wrong host. However, it is an intrinsic property of NULL authentication - you cannot authenticate the peer. The Security Considerations Section of the draft (In particular, Section = 3.1) warns that the host must not made any assumptions that it connects to the peer it was intendind to connect to. Regards, Valery Smyslov. ----- Original Message -----=20 From: Dharmanandana Reddy Pothula=20 To: svan@elvis.ru ; pwouters@redhat.com=20 Cc: ipsec@ietf.org=20 Sent: Tuesday, August 11, 2015 5:44 PM Subject: [IPSec] The NULL Authentication Method in IKEv2 Protocol - = draft-ietf-ipsecme-ikev2-null-auth-07 Hi, As per statement under section 2.4 in RFC 7296,=20 To prevent DoS attack on the initiator, "the initiator MAY be willing = to accept multiple responses to its first message, treat each response as potentially legitimate, respond to each one, = and then discard all the invalid half-open connections when it receives a valid cryptographically protected response to any one of = its requests. Once a cryptographically valid response is received, all subsequent responses should be ignored whether or not they are = cryptographically valid." if we apply above scenario when initiator expects authentication null = from responder, there is possibility that initiator will receive more = than one cryptographically valid response, as per above statement, the first one should be considered and = subsequent responses should be ignored, but if first one is attacker and = subsequent one is genuine peer, the connection establishes with the = attacker. We feel this is security risk. can you please provide more insight on = this? Regards, Dharmanandana Reddy.P=20 Perumal. V ------=_NextPart_000_1DCE_01D0D463.DDF0A1D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Dharmanandana,
 
I don't think that the attack, described in the = section 2.4 of=20 RFC 7296
is related to NULL authentication. This attack = implies that=20 attackers
send IKE_SA_INIT response containing garbage in the = KE=20 Payload
and that they never compute SKEYSEED and the other = keys, so=20 that
they cannot construct proper (cryptographically = valid)=20 IKE_AUTH response.
 
However, if attackers do go further in the protocol = and=20 calculate the keys
and respond with valid IKE_AUTH response with = NULL=20 authentication,
and if the NULL authentication is acceptible to the = Initiator,=20 then the
Initiator does connect to the wrong host. However, = it is an=20 intrinsic
property of NULL authentication - you cannot = authenticate the=20 peer.
 
The Security Considerations Section of the draft (In = particular, Section 3.1)
warns that the host must not made any assumptions = that it=20 connects
to the peer it was intendind to connect = to.
 
Regards,
Valery Smyslov.
 
----- Original Message -----
From:=20 Dharmanandana Reddy=20 Pothula
Sent: Tuesday, August 11, 2015 = 5:44=20 PM
Subject: [IPSec] The NULL = Authentication=20 Method in IKEv2 Protocol - draft-ietf-ipsecme-ikev2-null-auth-07

Hi,

 

As per statement under section 2.4 in RFC 7296,

 

To prevent DoS attack on the initiator, "the initiator MAY be = willing=20 to accept multiple responses to its first message,
treat each = response as=20 potentially legitimate, respond to each one, and then discard all = the=20 invalid half-open connections when it
receives a valid = cryptographically=20 protected response to any one of its requests.  Once a=20 cryptographically valid response is received,
all subsequent = responses=20 should be ignored whether or not they are cryptographically = valid."

 

if we apply above scenario when initiator expects authentication = null=20 from responder, there is possibility that initiator will receive = more=20 than one cryptographically valid response,

as per above statement, the first one should be considered=20 and subsequent responses should be ignored, but if first one = is attacker and subsequent one is genuine peer, the = connection=20 establishes with the attacker.

 

We feel this is security risk. can you please provide more = insight on=20 this?

 

Regards,

Dharmanandana Reddy.P 

Perumal. V

 

 

 

------=_NextPart_000_1DCE_01D0D463.DDF0A1D0-- From nobody Tue Aug 11 17:03:36 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BC11A0173 for ; Tue, 11 Aug 2015 17:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_Wg5OkIuBs9 for ; Tue, 11 Aug 2015 17:02:50 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC1621A0141 for ; Tue, 11 Aug 2015 17:02:50 -0700 (PDT) Received: from [10.32.60.79] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t7C02nV9015034 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 11 Aug 2015 17:02:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.79] From: "Paul Hoffman" To: ipsec@ietf.org Date: Tue, 11 Aug 2015 17:02:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: X-Mailman-Approved-At: Tue, 11 Aug 2015 17:03:35 -0700 Subject: [IPsec] Work on the IPsec-related YANG documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Aug 2015 00:02:51 -0000 Greetings. At the meeting in Prague, there was discussion of the IPsec-related YANG documents (draft-tran-ipecme-yang-ipsec, draft-wang-ipsecme-ipsec-yang, and draft-wang-ipsecme-ike-yang). Given the low level of understanding of YANG, it would be great if the authors of the three documents could either combine the documents or, failing that, agree on some wording for the WG about what each doc does and why they should exist in parallel. After that, the WG will be in a better position to think about whether we want to adopt them as WG items. --Paul Hoffman From nobody Fri Aug 14 04:47:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BDB1ACDCD for ; Fri, 14 Aug 2015 04:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.124 X-Spam-Level: X-Spam-Status: No, score=0.124 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BbZAF_TtXWj for ; Fri, 14 Aug 2015 04:47:56 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1591ACDB4 for ; Fri, 14 Aug 2015 04:47:56 -0700 (PDT) Received: by wicne3 with SMTP id ne3so15738399wic.0 for ; Fri, 14 Aug 2015 04:47: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:subject :content-type:content-transfer-encoding; bh=F92JWQhDPxq6RwJHgcbG2R5IPC+0V6xDZkxFdcSW8LY=; b=oA9FGpri3WVgrDSuahLZf/rhrdCoO8bJvunlknRBndz6iVyNo31BKZ24l/noPvr8oQ xEMYyIDZpBnronCHL4WgwxhzB4rQ+lAu8xEcbOzz3c8X4jqFHSZjKerj0b84onyhzY4S Sk9EwuWr2IxH4AwuwtvpgSNRQhExyrIGiM6FvUjdWQCGMYJhOodWOXca3UJizEdLU+Dp 5hGEDQgfwpRhdLaFVPIRwWA1jVhgV0DhlteFzraXiG5D6m6oX+SCRFs+tWaMujEu/Fbh BpCUTVGn96vQqDNeQPhMN0b2WL0bIz0/tLL9gNxc2SneQV4r8B5Ui9n4fTOn1O4UyXpn Cmxg== X-Received: by 10.180.73.244 with SMTP id o20mr6081305wiv.31.1439552875014; Fri, 14 Aug 2015 04:47:55 -0700 (PDT) Received: from [10.0.0.7] (bzq-79-176-197-89.red.bezeqint.net. [79.176.197.89]) by smtp.googlemail.com with ESMTPSA id mc18sm2687482wic.23.2015.08.14.04.47.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Aug 2015 04:47:54 -0700 (PDT) Message-ID: <55CDD568.4020003@gmail.com> Date: Fri, 14 Aug 2015 14:47:52 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: IPsecME WG Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [IPsec] DDoS draft next steps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 11:47:57 -0000 Dear authors and WG members,

We clearly do not have enough energy/consensus behind the draft to move it forward in its current form. My personal opinion is that the draft is an important piece of work and I don't want to see it go to waste.

We would like to see if the working group would be interested in a more focused draft. Some options:
  • Make the draft more attractive by solving the problem of mobile clients (did I hear "memory-intensive puzzles"? someone even mentioned Captcha), then try again to get consensus around it.
  • Publish only the protocol part of the document, basically Sec. 3 and 8, as an Experimental RFC.

There are probably other options.


Ideas?


Thanks,

    Yaron


From nobody Fri Aug 14 05:42:27 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12BB1A0121 for ; Fri, 14 Aug 2015 05:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63BLv0z-fG4V for ; Fri, 14 Aug 2015 05:42:25 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C3E1A011F for ; Fri, 14 Aug 2015 05:42:24 -0700 (PDT) Received: by lalv9 with SMTP id v9so43146424lal.0 for ; Fri, 14 Aug 2015 05:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=LJ6ukngrWYcbbu/zXHXlRUQMteBtdEquEaFHFIhRDJM=; b=VWxB+8YPUlvyHirZIBJ9e7x0lXe0awRDAKZKE7bHRsGFxPBu69/dEVqZY0CiWFNUkp Q51nylRVMaqvuKq3+dzXfYZVEQHMcG8XKycn0Flq9LOcUKfQiAvqvg2lNXi1hU7p3PEp XsQHRrTcfEpeSww/bZxeolzNEMOU9lpPO7skVczZsveJ4G/HpD5iVw8QdW+1m9YvrRJl jGCzGFTUnM9V63PO0crecJTipZACKensH7tiHchFYY7y2e9VIx+C074e3VFwRe088q3F ZnOZq719bT/mWE5ZuBjSbrdk86OC4oToUshkWpJJZAMA8ACACbCNWgxbvkDi79+4GadB mhuQ== X-Received: by 10.112.55.33 with SMTP id o1mr42998250lbp.96.1439556143196; Fri, 14 Aug 2015 05:42:23 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id xc10sm1429407lbb.34.2015.08.14.05.42.22 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Aug 2015 05:42:22 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" , "IPsecME WG" References: <55CDD568.4020003@gmail.com> Date: Fri, 14 Aug 2015 15:42:24 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 12:42:27 -0000 Hi Yaron, that was my idea to use CAPTCHA as a puzzle. My thoughts were the following. We came to the problem that weak clients cannot solve strong puzzles, so using puzzles for DDoS protection makes legitimate weak clients uncapable to establish IKE SA. Then I thought that probably we can use some other resource, that is available for weak clients to solve puzzles. Many weak clients are smartphones, so they have an owner, a human who is usually initiating the communication. So, why not ask human to solve puzzle? Then CAPTCHA was the first that came to my mind. The idea is that initiator indicates what kind of puzzle it wants to solve - computational puzzle or CAPTCHA. In the latter case the responder returns some kind of CAPTCHA, cryptographically linked with cookie, so that it could later verify in a stateless manner that initiator didn't cheat. The initiator would present CAPTCHA to user and then return back the solution along with cookie. This approach has some potential drawbacks. 1. CAPTCHA is usually rather big, so we could run into fragmentation problem in IKE_SA_INIT. 2. Th difficulty of CAPTCHA is somewhat unclear, the progress in OCR technology could make this kind of puzzles too weak and attackers would indicate their preference to get this kind of puzzles. 3. This solution is sutable for smartphones, however there are many weak clients that are not smartphones (besides IoT world that could be some SOHO devices, like sensors, home appliance, SOHO routers etc.). The idea is a bit crazy, so it is interesting to know what folks think about it. Regards, Valery. > Dear authors and WG members, > > We clearly do not have enough energy/consensus behind the draft to move it forward in its current > form. > My personal opinion is that the draft is an important piece of work and I don't want to see it go > to waste. > > We would like to see if the working group would be interested in a more focused draft. Some > options: > > - Make the draft more attractive by solving the problem of mobile clients (did I hear > "memory-intensive puzzles"? > someone even mentioned Captcha), then try again to get consensus around it. > - Publish only the protocol part of the document, basically Sec. 3 and 8, as an Experimental RFC. > There are probably other options. > > > Ideas? > > > Thanks, > Yaron From nobody Fri Aug 14 05:53:00 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 503A11A0AF8 for ; Fri, 14 Aug 2015 05:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.47 X-Spam-Level: * X-Spam-Status: No, score=1.47 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dPQ9Of6NzlI for ; Fri, 14 Aug 2015 05:52:58 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C065F1A0A6A for ; Fri, 14 Aug 2015 05:52:57 -0700 (PDT) Received: by lalv9 with SMTP id v9so43307367lal.0 for ; Fri, 14 Aug 2015 05:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=3hK+RLb0rpJ/sbJnIiiDJ0/Hh7/oIpE0lDLzEV52D/U=; b=ZMsnR0h/aIbTbazUuEaH4FGMuVvKePHvUx0UOQf/P82QoDqu1NrqWi4WqqFZdOJ/4M vNyqIWAMJlhkW5DQBWv2ko4uD0z8JWFxipdNlcTxnTQYLtEfLhHOCTP+osBRRg7E0SUj ZAl2nI+abdo97d6RTKEjfKAEy2xl7gn2jK8Cmo32bhN3bg6OApDotxXSAU+73QZHJ5v4 yIll8mfGjWKnWpD/edC/tRhlXheo0BW61rGVFgp7hKkSD/772820aCb+rQI6xozwR1rR fvB6suvvlWg52N7C0+H7ULzB7WhfuvQXgn563U1cWpSB6QriMfMvtgfIjRSOF9s4V2Ps KV4w== X-Received: by 10.112.24.163 with SMTP id v3mr39562754lbf.101.1439556776223; Fri, 14 Aug 2015 05:52:56 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id kc4sm1435270lbc.39.2015.08.14.05.52.55 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Aug 2015 05:52:55 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" , "IPsecME WG" References: <55CDD568.4020003@gmail.com> Date: Fri, 14 Aug 2015 15:52:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Erik Nygren Subject: Re: [IPsec] DDoS draft next steps - memory intensive puzzle X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 12:52:59 -0000 Hi again, the idea of "memory-intensive puzzle" is present in Erik Nygren's draft "TLS Client Puzzles Extension" (http://www.ietf.org/id/draft-nygren-tls-client-puzzles-00.txt). The idea is to create puzzle in such a way, that the time to solve it depends rather on available RAM, than on CPU power. It is assumed that the difference in RAM size between modern smartphones and desktops is not as great, as the difference in CPU power. Probably Erik could explain his idea in more details. Regards, Valery. > Dear authors and WG members, > > We clearly do not have enough energy/consensus behind the draft to move it forward in its current > form. > My personal opinion is that the draft is an important piece of work and I don't want to see it go > to waste. > > We would like to see if the working group would be interested in a more focused draft. Some > options: > > - Make the draft more attractive by solving the problem of mobile clients (did I hear > "memory-intensive puzzles"? > someone even mentioned Captcha), then try again to get consensus around it. > - Publish only the protocol part of the document, basically Sec. 3 and 8, as an Experimental RFC. > There are probably other options. > > > Ideas? > > > Thanks, > Yaron From nobody Fri Aug 14 06:45:31 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBA81A1B5E for ; Fri, 14 Aug 2015 06:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ba1dsQjTKV2z for ; Fri, 14 Aug 2015 06:45:28 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD271A1B43 for ; Fri, 14 Aug 2015 06:45:28 -0700 (PDT) Received: by wibhh20 with SMTP id hh20so21388086wib.0 for ; Fri, 14 Aug 2015 06:45:27 -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 :cc:content-type; bh=LfDlvimkXRM3/ZPiVWbPCTvuCyH9C6duYGDGGZ7ESWQ=; b=ytSbQmbm7o67rZkKg7VzMRnT4PwwjqIjbuhTGltsm6Z3aOWCiDGoSsuW7AOCP2p32Y 7bz1se/pPPdYop6flOomnJszDzXgLr7W42NG5N4odvDPbvz48hS4ijlzt9aJJm6cGHDe eI5rhhdVcUagJctmirg1Ep4/1D6Nbb6jQU1X+8p9sgjokZXNCZncZ1Z1RqEa7cZHfh+V nH0zYq4bAuEYZjT39VGfMPdLp4qPOJyv3aMzeLPYl008AahWtPP/C81KEF1K1n0agC6j 0pp4hqXI3ufoA46r58kxRDlKUsYqDeoWwpjhyVdaHwJH60jobmLjMmRRaBk0/ZLsutSW hhOQ== MIME-Version: 1.0 X-Received: by 10.194.205.37 with SMTP id ld5mr24916wjc.14.1439559926982; Fri, 14 Aug 2015 06:45:26 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Fri, 14 Aug 2015 06:45:26 -0700 (PDT) In-Reply-To: References: <55CDD568.4020003@gmail.com> Date: Fri, 14 Aug 2015 09:45:26 -0400 Message-ID: From: Kathleen Moriarty To: Valery Smyslov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 13:45:30 -0000 On Fri, Aug 14, 2015 at 8:42 AM, Valery Smyslov wrote: > Hi Yaron, > > that was my idea to use CAPTCHA as a puzzle. My thoughts were the following. > We came to the problem that weak clients cannot solve strong puzzles, > so using puzzles for DDoS protection makes legitimate weak clients > uncapable to establish IKE SA. Then I thought that probably we can use > some other resource, that is available for weak clients to solve puzzles. > Many weak clients are smartphones, so they have an owner, a human > who is usually initiating the communication. So, why not ask human to solve > puzzle? Then CAPTCHA was the first that came to my mind. > > The idea is that initiator indicates what kind of puzzle it wants to solve - > computational puzzle or CAPTCHA. In the latter case the responder returns > some kind of CAPTCHA, cryptographically linked with cookie, so that > it could later verify in a stateless manner that initiator didn't cheat. > The initiator would present CAPTCHA to user and then return back > the solution along with cookie. > > This approach has some potential drawbacks. > 1. CAPTCHA is usually rather big, so we could run into fragmentation problem > in IKE_SA_INIT. > 2. Th difficulty of CAPTCHA is somewhat unclear, the progress > in OCR technology could make this kind of puzzles too weak > and attackers would indicate their preference to get this kind of > puzzles. > 3. This solution is sutable for smartphones, however there are > many weak clients that are not smartphones (besides IoT world > that could be some SOHO devices, like sensors, home appliance, > SOHO routers etc.). > > The idea is a bit crazy, so it is interesting to know what folks think about > it. With no hat on, I hate captchas. I sometimes don't see it well enough depending on the images selected and have not used applications as a result. It is a clever way to tackle the problem, so it would be up to the deployer to make sure their captcha images didn't prevent expected and authorized users from connecting. Thanks, Kathleen > > Regards, > Valery. > > > >> Dear authors and WG members, >> >> We clearly do not have enough energy/consensus behind the draft to move it >> forward in its current form. >> My personal opinion is that the draft is an important piece of work and I >> don't want to see it go to waste. >> >> We would like to see if the working group would be interested in a more >> focused draft. Some options: >> >> - Make the draft more attractive by solving the problem of mobile clients >> (did I hear "memory-intensive puzzles"? >> someone even mentioned Captcha), then try again to get consensus around >> it. >> - Publish only the protocol part of the document, basically Sec. 3 and 8, >> as an Experimental RFC. >> There are probably other options. >> >> >> Ideas? >> >> >> Thanks, >> Yaron > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- Best regards, Kathleen From nobody Fri Aug 14 07:29:09 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4D71A893A for ; Fri, 14 Aug 2015 07:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-UqxcROMzT2 for ; Fri, 14 Aug 2015 07:29:06 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A9351A8930 for ; Fri, 14 Aug 2015 07:29:06 -0700 (PDT) Received: by lagz9 with SMTP id z9so44904942lag.3 for ; Fri, 14 Aug 2015 07:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=9J//1D+YXvklZjLxNOfI8/SfSozOYRV31gn6ZvnTXkI=; b=EnVjMgnsxZ3cpO4++VKfZnXH1cyfT73qCr5asrXjXu1SJMXZcWoAB255+R8IUPf9QC vKEJuq4RAR05GeR/o9PRDYN4FCdNy7CNHb8A3Pc1ePcnwKYhhHfEM/P4JsGm1GVBwiBK mxbBq5PCELwC+AnOwg6HTE4128uXasoFnY7ufZ3CL6sbY9IDdO8wNTW1Glm2K6qSMdI2 HYmKv4tZqI1hvk27RiV98tVDpDOUangauzbnp2to6jexrAAgP8chSlJgm3heNg/3IvyQ 7j1KXqlYA2kvp7v/IOI4i2BL6+qVDmoVyjUC7fK6oF+f1TTRhvrT+dw//7hH2H5/M6bi ezLA== X-Received: by 10.152.37.161 with SMTP id z1mr44402488laj.27.1439562544371; Fri, 14 Aug 2015 07:29:04 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g1sm1508754lam.30.2015.08.14.07.29.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Aug 2015 07:29:03 -0700 (PDT) Message-ID: <79614077359A4222A46B773C450158F4@buildpc> From: "Valery Smyslov" To: "Kathleen Moriarty" References: <55CDD568.4020003@gmail.com> Date: Fri, 14 Aug 2015 17:29:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 14:29:07 -0000 > With no hat on, I hate captchas. I sometimes don't see it well enough > depending on the images selected and have not used applications as a > result. It is a clever way to tackle the problem, so it would be up > to the deployer to make sure their captcha images didn't prevent > expected and authorized users from connecting. To be frank I hate them also as a user in real life. But any kind of puzzle solution (be it captca or cryptographic puzzle) would annoy users (additional delays, battery power consumption etc.). Valery. > Thanks, > Kathleen From nobody Fri Aug 14 08:12:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704291A9252 for ; Fri, 14 Aug 2015 08:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWZhxpwS7ixl for ; Fri, 14 Aug 2015 08:12:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756381A923A for ; Fri, 14 Aug 2015 08:12:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3F562200A1; Fri, 14 Aug 2015 11:30:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B019D63B10; Fri, 14 Aug 2015 11:12:47 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 907F563AE8; Fri, 14 Aug 2015 11:12:47 -0400 (EDT) From: Michael Richardson To: "Valery Smyslov" In-Reply-To: References: <55CDD568.4020003@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 15:12:55 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > We came to the problem that weak clients cannot solve strong puzzles, > so using puzzles for DDoS protection makes legitimate weak clients > uncapable to establish IKE SA. Then I thought that probably we can use > some other resource, that is available for weak clients to solve puzzles. Sure, there could also be some interface to OAUTH2. > This approach has some potential drawbacks. > 1. CAPTCHA is usually rather big, so we could run into fragmentation > problem in IKE_SA_INIT. I would think that reference by value is the wrong approach, it should be a URL. > 2. Th difficulty of CAPTCHA is somewhat unclear, the progress > in OCR technology could make this kind of puzzles too weak > and attackers would indicate their preference to get this kind of > puzzles. > 3. This solution is sutable for smartphones, however there are > many weak clients that are not smartphones (besides IoT world > that could be some SOHO devices, like sensors, home appliance, > SOHO routers etc.). It seems to me there can not be a one-size-fits all approach. Focus on a smaller scope of problem. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVc4FbICLcPvd0N1lAQJRoAgAi5usgYlbKrSaFKjZYx/pmLDmdwZ5x3et 5cPg6fzf+q2tVnKQKHa8fYE+ftnEfAtsJOtq0tQ51nFfylEGEXWYfM9JEs7FMKGT XNlizyj70ZdblYe2RiCCaYLtmBZDWEZpNtaeobw/5p5xBi2BPhOCmW8EaYFGpCwj PaO7WSmETp5yZPRI90od+dlPnipQZK280Ckck4FSHxTAYUydF7f62ogyq6QfHkcF UslbeQgpYtPYpGpHjjWLjbszplchFIhS3SP12wcu2zmQQPpdiWzZ7uCKt+JIJihd /ES98q5c+G/y/8bBlM+P1xoM6fwlp4B6yNDT0xI8rpwi2mDMrI32BQ== =wj6x -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 14 09:01:39 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E91C1A86E3 for ; Fri, 14 Aug 2015 09:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rZvHWwz_kmb for ; Fri, 14 Aug 2015 09:01:35 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C3C1A86E2 for ; Fri, 14 Aug 2015 09:01:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3mt8dp1ws6z20h; Fri, 14 Aug 2015 18:01:34 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=UqoxJOw5 X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id YVUWGa4-UfQw; Fri, 14 Aug 2015 18:01:32 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 14 Aug 2015 18:01:32 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 617848009F; Fri, 14 Aug 2015 12:01:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1439568091; bh=gFwj65H4R0kwJh/MRd9H2Lmek5dPTPu/CYBZWq0fm8g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UqoxJOw5PYeJ1z58VxdXt5nNNZWPOkMBr8JmFBYClq1EjPH3uuhAm8BXUjExXyTrI 2YlEfrgULPwsjDGQTXzMr1C0jgyBVr4fHHuGcJWTWGxFIMV/mSsoz0weErIeQfcbhH GjxGlHul8tIcVIh5cXGjm0OkwAxhyDMr2KTNCF64= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7EG1UQm022727; Fri, 14 Aug 2015 12:01:31 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 14 Aug 2015 12:01:30 -0400 (EDT) From: Paul Wouters To: Valery Smyslov In-Reply-To: <79614077359A4222A46B773C450158F4@buildpc> Message-ID: References: <55CDD568.4020003@gmail.com> <79614077359A4222A46B773C450158F4@buildpc> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG , Kathleen Moriarty Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 16:01:37 -0000 On Fri, 14 Aug 2015, Valery Smyslov wrote: >> With no hat on, I hate captchas. I sometimes don't see it well enough >> depending on the images selected and have not used applications as a >> result. It is a clever way to tackle the problem, so it would be up >> to the deployer to make sure their captcha images didn't prevent >> expected and authorized users from connecting. > > To be frank I hate them also as a user in real life. > But any kind of puzzle solution (be it captca or > cryptographic puzzle) would annoy users (additional delays, battery power > consumption etc.). captcha's also assume there is a user to talk to, which might not always (or even mostly) be the case. Paul From nobody Fri Aug 14 09:08:55 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8EC1A86FE for ; Fri, 14 Aug 2015 09:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcmTb-BSZz6p for ; Fri, 14 Aug 2015 09:08:53 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EE7B1A86E2 for ; Fri, 14 Aug 2015 09:08:53 -0700 (PDT) Received: by lbcbn3 with SMTP id bn3so47983227lbc.2 for ; Fri, 14 Aug 2015 09:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=JVvoE5SznZiZ7A4QcB1f5cCwvaqu6C9F94T0KP6M/v0=; b=OPzTndirZWhmuuzIG/E/vfscd7m02W0dpV5gFOXkGtWwBpMDGBr6RgAHuterlDfUaS 4kTeBJHMUFAzzH295FSp/CqIVB1vRZ7ohr+0JqZT+LyEqky5M1U7CQptkZzJD1C5taD/ L6NOvAlHco/kdYARefBUQnkmP9yZkIudFRO8GNCi+6brysiIPs+iJew35HGjM08qbLC5 TAt7IqeUJiGqnXCETDwTvCYMzByc5CXNpOYOERgwbHs5+uNNupu3Sy8bXlJP6WbXgktV 0UswN5N7TwRkQ+U7UkNLHoKFDpW/o8SHNbWcqRdf0ITmx0swNuzjjfcCuwFaPrJi6lt6 aBtA== X-Received: by 10.152.179.170 with SMTP id dh10mr27267996lac.22.1439568531725; Fri, 14 Aug 2015 09:08:51 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id z1sm1573901lbj.11.2015.08.14.09.08.50 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Aug 2015 09:08:51 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <55CDD568.4020003@gmail.com> <79614077359A4222A46B773C450158F4@buildpc> Date: Fri, 14 Aug 2015 19:08:52 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG , Kathleen Moriarty Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 16:08:54 -0000 >>> With no hat on, I hate captchas. I sometimes don't see it well enough >>> depending on the images selected and have not used applications as a >>> result. It is a clever way to tackle the problem, so it would be up >>> to the deployer to make sure their captcha images didn't prevent >>> expected and authorized users from connecting. >> >> To be frank I hate them also as a user in real life. >> But any kind of puzzle solution (be it captca or >> cryptographic puzzle) would annoy users (additional delays, battery power >> consumption etc.). > > captcha's also assume there is a user to talk to, which might not always > (or even mostly) be the case. Yes, I wrote in my original e-mail that this is not appropriate for "unattended" devices. For those cryptographic puzzles are left. This is appropriate mostly for smartphones. From nobody Fri Aug 14 09:36:20 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E291A883D for ; Fri, 14 Aug 2015 09:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H18gEkHQIWRy for ; Fri, 14 Aug 2015 09:36:17 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1A41A8835 for ; Fri, 14 Aug 2015 09:36:17 -0700 (PDT) Received: by wicja10 with SMTP id ja10so23339283wic.1 for ; Fri, 14 Aug 2015 09:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pil4AjwT3IEVnukdHTDhy+4t6CGODRlR7vEoBfOGWOg=; b=mIDt5spWUash6aAoU3V0b7O1BW3pb+UX7sJLHerlFwMxZCg56EeqElFX3kfKhYp3Vo jEHKSmmG+4tezyYBdX3OABAQDsHI9g8hlsyKNpM3GwhfgMJgpUULQilu736C2xAzu3Ss voB3niFPcaoyIhnQADBwRezGKxjvxN1LHKm6wggRgqJDiT3WrffY6CzCmKAD1JW2iavy SIDjnFMH5yAKxXxAIgXihHSLR24zopak6NYIcMM66wgTUmq97hVsl6uGC8orjsEZpq4T HoF90XZzD2xhJpzn7SXakoy6ngTqJCqhogkthrl8g42MvwUxMORzCEIjY6MEVWxSBEW0 yb7w== X-Received: by 10.180.82.98 with SMTP id h2mr7781770wiy.37.1439570176189; Fri, 14 Aug 2015 09:36:16 -0700 (PDT) Received: from [192.168.1.50] (antoniah.static.otenet.gr. [79.129.103.151]) by smtp.gmail.com with ESMTPSA id jr5sm8988042wjc.14.2015.08.14.09.36.13 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Aug 2015 09:36:15 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Fri, 14 Aug 2015 19:36:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <69454422-47B3-441A-A9CD-EBEB7004354A@gmail.com> References: <55CDD568.4020003@gmail.com> <79614077359A4222A46B773C450158F4@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.2102) Archived-At: Cc: IPsecME WG , Kathleen Moriarty , Paul Wouters Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 16:36:19 -0000 > On Aug 14, 2015, at 7:08 PM, Valery Smyslov wrote: >=20 >>>> With no hat on, I hate captchas. I sometimes don't see it well = enough >>>> depending on the images selected and have not used applications as = a >>>> result. It is a clever way to tackle the problem, so it would be = up >>>> to the deployer to make sure their captcha images didn't prevent >>>> expected and authorized users from connecting. >>>=20 >>> To be frank I hate them also as a user in real life. >>> But any kind of puzzle solution (be it captca or >>> cryptographic puzzle) would annoy users (additional delays, battery = power consumption etc.). >> captcha's also assume there is a user to talk to, which might not = always >> (or even mostly) be the case. >=20 > Yes, I wrote in my original e-mail that this is not appropriate > for "unattended" devices. For those cryptographic puzzles are left. > This is appropriate mostly for smartphones. And IoT devices are left out in the cole by both approaches. They = can=E2=80=99t do millions of SHA-2 fast enough, and they don=E2=80=99t = have a user or a user interface capable of displaying the captcha. I=E2=80=99m trying to imagine this as a conversation between the user = and their phone: User: Connect Phone: VPN gateway is overloaded. Wait 48 seconds while I solve the = puzzle or type in the numbers from this picture User: I guess I didn=E2=80=99t really want to read my work email this = badly Yoav From nobody Mon Aug 17 10:33:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1CE1AC413 for ; Mon, 17 Aug 2015 10:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.623 X-Spam-Level: ** X-Spam-Status: No, score=2.623 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUWshKY4CSM7 for ; Mon, 17 Aug 2015 10:33:21 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100F61ACD94 for ; Mon, 17 Aug 2015 10:33:21 -0700 (PDT) Received: by igfj19 with SMTP id j19so60978882igf.1 for ; Mon, 17 Aug 2015 10:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=XfwXvvj0td7DBLhhZdBtJRUGLl9244YqQeccUqDnqT8=; b=rZ1MP69Rl+Oz74XRQypocw7uUCKbCpkvP/2is3y2/bHisDyiom9e/+U3jvn8Pd7Kp+ si8WsbvTDfgTREH0kwxi5+9w+VbDCCjvrsI2XQAxzDi7jBrME0gexynTfMf4QD3Q/j1l bb2GdsbXpLvMckQjU+f8eMtoUVprsJzCtTNWWSXftbQ0jHKImCa65gJyzapuLwLCN4Ku fc12yOdrk5ID1pSNa/LyxCI1zJP+rYPrnRn4zkvpmF1g+o+hi96Vgg4ULp26l23XeVDt D6MVHcIaAgWCFFIQd9v8kf8PTb1lLXHxD/fVIHRnK0PTArPGRONZt07T+u0/WXAU4W00 AXQg== MIME-Version: 1.0 X-Received: by 10.50.88.41 with SMTP id bd9mr18579223igb.4.1439832800480; Mon, 17 Aug 2015 10:33:20 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.79.21.196 with HTTP; Mon, 17 Aug 2015 10:33:20 -0700 (PDT) In-Reply-To: <881AE47D-154A-4922-8429-0829493E26B0@gmail.com> References: <881AE47D-154A-4922-8429-0829493E26B0@gmail.com> Date: Mon, 17 Aug 2015 13:33:20 -0400 X-Google-Sender-Auth: L7uhok1WMFNe7aB8YSEznQArfks Message-ID: From: Daniel Migault To: Les Leposo Content-Type: multipart/alternative; boundary=089e013cb9849bd76c051d853284 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa (Yaron Sheffer) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:33:28 -0000 --089e013cb9849bd76c051d853284 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Thank you for taking time to review the document and raising the issues. We noticed they have remained unanswered yet, -- although your points have probably helped us clarifying the document. This email's intention is to address the issue you raised. Feel free to let us know whether you agree on the response or if you woudl like additional information. BR, Daniel %%% ISSUE 1 : when is the =E2=80=98CLONE_IKE_SA=E2=80=99 notification exactly s= ent - perhaps some examples (e.g. uplink route comes up)? RESPONSE 1: The draft explicitly mentions two use cases, the mobility use case and the load sharing use case. Both use cases have been detailled and Appendix A provides diagrams and figures to detail step by step the mobility use case. %%% ISSUE 2: please consider good integration with =E2=80=98Session Resumption= =E2=80=99. particularly as a =E2=80=98low-cal=E2=80=99 extension to section 4.3.3, som= eone alluded to this earlier. RESPONSE 2: The Clone IKE SA mechanism is outside Session Resumption, so Session Resumption is not an issue for this draft. %%% ISSUE 3: please consider consistency with the =E2=80=98ADDITIONAL_IP*_ADDRE= SS list, someone alluded to this earlier. RESPONSE 3: The Clone IKE SA mechanism use MOBIKE, but does not extend it and so remains outside MOBIKE. Interactions with ADDITIONAL_IP*_ADDRESS is not an issue for this draft. %%% ISSUE 4: perhaps, a (configurable) maximum lifetime for the series of cloned IKE_SAs? RESPONSE 4: The IKE_SA life time negociation is not part of the IKEv2: RFC7296 section 2.8 mentions "A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiated. In IKEv2, each end of the SA is responsible for enforcing its own lifetime policy on the SA and rekeying the SA when necessary. If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. If an SA has been inactive for a long time and if an endpoint would not initiate the SA in the absence of traffic, the endpoint MAY choose to close the SA instead of rekeying it when its lifetime expires. It can also do so if there has been no traffic since the last time the SA was rekeyed." %%% ISSUE 5: What should be done for extraneous =E2=80=98CLONE_IKE_SA=E2=80=99 = notifications? RESPONSE 5: This has been adressed in section 5.2 of the current draft. "The CLONE_IKE_SA notification MUST appear only in request message of the CREATE_CHILD_SA exchange concerning the IKE SA rekey. If the CLONE_IKE_SA notification appears in any other message, it MUST be ignored." On Wed, Dec 3, 2014 at 7:09 AM, Les Leposo wrote: > Hi All, > > there probably are gateways that currently perform =E2=80=98faux-cloning = IKE-SAs=E2=80=99 > (e.g. through data replication tricks) - if so, they would only have an > opportunity to do so upon receiving favourable UPDATE_SA_ADDRESSES > notifications. I=E2=80=99m not sure if clients do this sort of thing. > > So, I support this draft because it could help standardise how =E2=80=98l= ow-cal=E2=80=99 > clients & distributed servers hand-over tunnels. It can also be used to > improve handovers, but, it potentially introduces some security risks. > > This draft is like __builtin_prefetch - it can be great if used > effectively, otherwise it could get a little worse. > > A few issues: > 1) when is the =E2=80=98CLONE_IKE_SA=E2=80=99 notification exactly sent -= perhaps some > examples (e.g. uplink route comes up)? > 2) please consider good integration with =E2=80=98Session Resumption=E2= =80=99. > particularly as a =E2=80=98low-cal=E2=80=99 extension to section 4.3.3, s= omeone alluded to > this earlier. > 3) please consider consistency with the =E2=80=98ADDITIONAL_IP*_ADDRESS l= ist, > someone alluded to this earlier. > 4) perhaps, a (configurable) maximum lifetime for the series of cloned > IKE_SAs? > 5) What should be done for extraneous =E2=80=98CLONE_IKE_SA=E2=80=99 noti= fications? > > > > On Dec 3, 2014, at 2:20 AM, ipsec-request@ietf.org wrote: > > > > Send IPsec mailing list submissions to > > ipsec@ietf.org > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://www.ietf.org/mailman/listinfo/ipsec > > or, via email, send a message with subject or body 'help' to > > ipsec-request@ietf.org > > > > You can reach the person managing the list at > > ipsec-owner@ietf.org > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of IPsec digest..." > > > > > > Today's Topics: > > > > 1. Re: Survey for WG interest in adopting > > draft-nagayama-ipsecme-ipsec-with-qkd (Yaron Sheffer) > > 2. Re: Survey for WG interest in adopting > > draft-mglt-ipsecme-clone-ike-sa (Yaron Sheffer) > > 3. Re: Survey for WG interest in adopting > > draft-nagayama-ipsecme-ipsec-with-qkd (Rodney Van Meter) > > 4. Re: Some speculations about puzzles (Graham Bartlett (grbartle)) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 02 Dec 2014 23:19:39 +0200 > > From: Yaron Sheffer > > To: Paul Hoffman , IPsecME WG > > Subject: Re: [IPsec] Survey for WG interest in adopting > > draft-nagayama-ipsecme-ipsec-with-qkd > > Message-ID: <547E2CEB.3020200@gmail.com> > > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed > > > > Here's a quick reminder to speak up if you're interested in this > > document and are willing to contribute as co-author or reviewer. > > > > Thanks, > > Yaron > > > > On 11/25/2014 10:06 PM, Paul Hoffman wrote: > >> > >> > >> Greetings again. There is a small emerging industry of crypto solution= s > that transmit keys using Quantum Key Distribution (QKD), and then use tho= se > keys for classical high-speed encryption. Several such solutions are usin= g > IKE, and there is a perceived need to standardize this usage. If so, that > standardization should be done in this Working Group. > >> > >> If you agree with the need to standardize this usage, and believe that > draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting pla= ce > for that standardization, and are willing to review and contribute text t= o > the document if it is adopted by the WG, please say so on the list. This = WG > has a history of adopting documents but then not having enough reviewers > for us to feel confident that we are making a good standard, so we need t= o > see a reasonable number of actively interested people before we adopt the > document. If it is not adopted, the authors can ask for it to be publishe= d > as an RFC through individual submission or by the Independent Submissions > Editor. > >> > >> Please reply by December 8, 2015. > >> > >> --Paul Hoffman and Yaron Sheffer > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 02 Dec 2014 23:20:33 +0200 > > From: Yaron Sheffer > > To: Paul Hoffman , IPsecME WG > > Subject: Re: [IPsec] Survey for WG interest in adopting > > draft-mglt-ipsecme-clone-ike-sa > > Message-ID: <547E2D21.2070600@gmail.com> > > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed > > > > And similarly for this draft: please speak up if you're interested in > > this document and are willing to contribute as co-author or reviewer. > > > > Thanks, > > Yaron > > > > On 11/25/2014 10:06 PM, Paul Hoffman wrote: > >> > >> > >> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA > setup in cases where VPN gateways have multiple interfaces and want to > establish different SAs on the different interfaces without having to > repeat the IKE authentication. Instead, they could clone a single IKE SA > multiple times, and then move it to different interfaces using MOBIKE. > >> > >> If you agree with the need to standardize this usage, and believe that > draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place for > that standardization, and are willing to review and contribute text to th= e > document if it is adopted by the WG, please say so on the list. This WG h= as > a history of adopting documents but then not having enough reviewers for = us > to feel confident that we are making a good standard, so we need to see a > reasonable number of actively interested people before we adopt the > document. If it is not adopted, the authors can ask for it to be publishe= d > as an RFC through individual submission or by the Independent Submissions > Editor. > >> > >> Please reply by December 8, 2015. > >> > >> --Paul Hoffman and Yaron Sheffer > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > >> > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 2 Dec 2014 17:49:58 -0500 > > From: Rodney Van Meter > > To: Yaron Sheffer > > Cc: Rodney Van Meter , IPsecME WG > > , Paul Hoffman > > Subject: Re: [IPsec] Survey for WG interest in adopting > > draft-nagayama-ipsecme-ipsec-with-qkd > > Message-ID: > > Content-Type: text/plain; charset=3Dutf-8 > > > > Hi, > > > > Sorry to be a little slow to reply. I was offline over Thanksgiving, > just saw the messages yesterday afternoon. > > > > Of course I favor adoption, and am willing to work with anyone who can > contribute to the development of an appropriate protocol. Momentum seems > to be toward a version supporting a variety of out-of-band mechanisms, an= d > I?m willing to work in that direction. > > > > Shota is looking in to the numerous issues I detailed in the long > message right after IETF. > > > > ?Rod > > > >> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer > wrote: > >> > >> Here's a quick reminder to speak up if you're interested in this > document and are willing to contribute as co-author or reviewer. > >> > >> Thanks, > >> Yaron > >> > >> On 11/25/2014 10:06 PM, Paul Hoffman wrote: > >>> > >>> > >>> Greetings again. There is a small emerging industry of crypto > solutions that transmit keys using Quantum Key Distribution (QKD), and th= en > use those keys for classical high-speed encryption. Several such solution= s > are using IKE, and there is a perceived need to standardize this usage. I= f > so, that standardization should be done in this Working Group. > >>> > >>> If you agree with the need to standardize this usage, and believe tha= t > draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting pla= ce > for that standardization, and are willing to review and contribute text t= o > the document if it is adopted by the WG, please say so on the list. This = WG > has a history of adopting documents but then not having enough reviewers > for us to feel confident that we are making a good standard, so we need t= o > see a reasonable number of actively interested people before we adopt the > document. If it is not adopted, the authors can ask for it to be publishe= d > as an RFC through individual submission or by the Independent Submissions > Editor. > >>> > >>> Please reply by December 8, 2015. > >>> > >>> --Paul Hoffman and Yaron Sheffer > >>> _______________________________________________ > >>> IPsec mailing list > >>> IPsec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/ipsec > >>> > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Tue, 2 Dec 2014 23:20:33 +0000 > > From: "Graham Bartlett (grbartle)" > > To: Valery Smyslov , Yoav Nir , > > ipsec > > Subject: Re: [IPsec] Some speculations about puzzles > > Message-ID: > > Content-Type: text/plain; charset=3D"us-ascii" > > > > Hi Valery > > > > Would the Timestamp be generated every time cycle? If this wasn't a > static > > figure (per timecycle - maybe when the secret is changed?, but rather a > > rolling unix time), then how would the Responder be able to validate th= is > > Cookie (without trying every previous timestamp or having the timestamp > > included in the Initiators reply?). Would it not be better to save X > > number of Secrets and just try them instead (assuming that the Secret i= s > > changing fairly regularly)? The Secret could also be used to tell > (approx) > > how old the Cookie is. > > > > > > I like the two options of the header in the clear. > > > > > > Many thanks > > > > On 01/12/2014 15:34, "Valery Smyslov" wrote: > > > >> Hi, this is a long message. > >> > >> First of all I think that the puzzles mechanism is a great tool > >> to make DoS attacks harder for attackers and we should > >> try to incorporate it into IKE. Moreover, I think that > >> the puzzles could be used not only in IKE_SA_INIT, but also > >> to defend against DoS attacks in IKE_AUTH exchange (see below). > >> However, the puzzles mechanism is a controversal thing, > >> since it requires an additional work from legitimate clients. > >> It could be particularly troublesome for small battery-powered wireles= s > >> devices (smartphones, IoT devices etc) - not only would it delay > >> connection > >> setup, but it also would decrease battery lifetime. > >> > >> So think that the puzzles mechanism if incorporated into IKE should > follow > >> some general principles: > >> 1. Puzzles should be optional. It should be possible for client to jus= t > >> return > >> cookie even if puzzle is given by SGW). > >> 2. The ultimate decision whether to solve puzzle or ignore it should b= e > >> made > >> by client. > >> 3. Those, who ignore puzzles (for any reason - either they are legacy > >> clients > >> or they decide to save battery) should still have a chance to setup > >> connection > >> (on "best effort" basis). > >> > >> In other words, let's consider puzzles mechanizm not as discriminating > >> tool > >> ("those who cannot solve puzzles won't be allowed in"), but as > >> a "first-class ticket" for those, who are ready to pay for it. > >> And the price for the first-class service should be high enough to mak= e > it > >> unattractive for attackers. > >> > >> > >> Concrete proposals. > >> > >> 1. Algorithm agility for puzzles. It is relatively easy to achieve. Wh= en > >> IKE_SA_INIT request comes from the client, the server could quicly par= se > >> it, > >> find SA payload and figure out the list of transforms the client > proposes. > >> Then it could select mutually supported PRF and indicate it to the > client > >> in response containing puzzle. The puzzle in this case would look like= : > >> "please, give me a string of octets such, that if this PRF is applied > >> to that string of octets using supplied cookie as the key, then the > >> result would contain this number of trailing zero bits" (another optio= n > - > >> apply PRF to cookie + string of octets using zero key). > >> > >> Parsing IKE_SA_INIT message is a relatively easy task. > >> The side advantage of this approach is that the server > >> could quickly check the structure of the message and > >> the list of proposed transforms and wouldn't spend more resources > >> in case the initial message is malformed or no proposals are acceptabl= e > >> to the responder. > >> > >> 2. Cookie generation. Currently RFC7296 suggestd the following > >> formula to compute cookie: > >> > >> Cookie =3D | Hash(Ni | IPi | SPIi | ) > >> > >> With puzzles more information should be present in the cookie > >> to prevent some attacks from initiator. First, when > >> responder asks initiator to solve the puzzle, it sets puzzle > >> difficulty to some level and indicates it in the response message. > >> When the solved puzzle is returned back to the responder, > >> it must know in a stateless manner what level of difficulty > >> it has requested. Otherwise the initiator could cheat. So responder > >> must encode this information into cookie, as the cookie is an entity > that > >> initiator cannot forge. Then, it is desirable to also include > >> timestamp into cookie to prevent initiator from re-using solved puzzle= s > >> and from collecting a lot of puzzles, solving them and then presenting > >> them > >> all at once. Including timestamp allows the responder > >> to determine how old this cookie is and, therefore, > >> how much time it was taken from the initiator to solve the puzzle. > >> If the results are suspicious (an easy puzzle took too long to be > solved), > >> then the request should be rejected, even in the case it contains > >> a valid solution for the puzzle. And in case of accepting > >> algorithm agility method described above the selected PRF > >> must also be encoded in cookie. > >> > >> So, the cookie generation would look like: > >> > >> Cookie =3D | | | > >> > >> | > >> Hash(Ni | IPi | SPIi | | | = | > >> ) > >> > >> Note, that should be allowed to be zero here - > >> in case it is just a cookie request with no puzzle request. > >> > >> To summarize here is a possible sequence of messages in IKE_SA_INIT: > >> > >> request --> HDR, SA, KE, Ni, > >> [N(NAT_DETECTION_SOURCE_IP)+, > >> N(NAT_DETECTION_DESTINATION_IP),] > >> [V+][N+] > >> > >> response with puzzle <-- HDR, N(COOKIE), N(PUZZLE, PRF=3D, > >> DIFFICULTY=3D) > >> [V+][N+] > >> > >> Legacy client or client that don't want to spend recources on puzzle > >> would ignore N(PUZZLE) and act as if only N(COOKIE) was received. > >> > >> request --> HDR, [N(COOKIE),] > >> SA, KE, Ni, > >> [N(NAT_DETECTION_SOURCE_IP)+, > >> N(NAT_DETECTION_DESTINATION_IP),] > >> [V+][N+] > >> > >> At this point the responder will: > >> - check that the cookie is valid > >> - retrieve timestamp and difficulty level from the cookie and ensures = it > >> is > >> fresh for that level > >> - if the level is zero, then it means that no puzzle was requested > >> - if the level is non-zero then it means that the initiator either > >> doesn't support puzzles or is unwilling to solve them; in either > >> case the request is processed on "best effort" basis - > >> it could be served or dropped depending on current resource availabili= ty > >> or on some probability (e.g.serve every Nth request in case of attack) > >> > >> Client, that is solved the puzzle: > >> > >> request --> HDR, [N(COOKIE),], N(PUZZLE_SOLUTION) > >> SA, KE, Ni, > >> [N(NAT_DETECTION_SOURCE_IP)+, > >> N(NAT_DETECTION_DESTINATION_IP),] > >> [V+][N+] > >> > >> > >> At this point the responder will: > >> - check that the cookie is valid > >> - retrieve timestamp and difficulty level from the cookie and ensures = it > >> is > >> fresh for that level > >> - if the level is zero, then it means that no puzzle was requested, > >> but initiator still supplied some solution; in this case > >> N(PUZZLE_SOLUTION) > >> is ignored and the message is processed as described above > >> - if the level is non-zero then responder will retrieve PRF from the > >> cookie > >> and verify the correctness of supplied puzzle solution > >> - if everything is OK then this request is served with higher priority > >> > >> > >> 3. Using puzzles in IKE_AUTH exchange. The draft > >> ipsecme-ddos-protection-00 > >> describes DoS attack on IKE_AUTH exchange: > >> > >> Sending an Authentication request is surprisingly cheap. It > >> requires > >> a proper IKE header with the correct IKE SPIs, and it requires a > >> single encrypted payload. The content of the payload might as we= ll > >> be junk. The responder has to perform the relatively expensive k= ey > >> derivation, only to find that the Authentication request does not > >> decrypt. > >> > >> I think that the puzzles could be used to make this attack substantial= ly > >> more expensive for the attacker. The idea is to require the initiator > >> to supply an additional string of octets in IKE_AUTH request such, tha= t > >> applying PRF with the Nr as the key to this string of octets > >> concatenated with the content of the IKE_AUTH message will > >> result in some number of zero trailing bits. In this case if the > attacker > >> fills in the content of SK payload with garbage, it will be detected > >> by the responder without performing DH computation. The level of > >> difficulty > >> in this case must be set so, that the time needed to solve the puzzle = is > >> by the order of magnitude more, than to compute DH, so that > >> this attack becomes unattractive for potential attacker. > >> > >> There are some options where to place puzzle solution > >> in IKE_AUTH message. > >> > >> 1. It could be explicitely present as Notification payload > >> before Encrypted payload: > >> > >> HDR, N(PUZZLE_SOLUTION), SK {IDi, [CERT,] [CERTREQ,] > >> [IDr,] AUTH, SAi2, TSi, TSr} > >> > >> 2. It could be placed right after Encrypted payload without > >> any header. In this case the length indicated in IKE Header > >> would be greater, than the length indicated in Encrypted payload > >> header, and the solved puzzle would be placed in this gap. > >> > >> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} > >> >> puzzle> > >> > >> In case of IKE fragmentation every fragment should contain > >> its own solution for the puzzle. Note also, that puzzles in IKE_AUTH > >> are mandatory for initiator if they are requested by responder - > >> the request won't be processed untill the initiator provides > >> puzzle solution (this is unlike puzzles in IKE_SA_INIT, where > >> they should be optional). > >> > >> > >> Regards, > >> Valery Smyslov. > >> > >> _______________________________________________ > >> IPsec mailing list > >> IPsec@ietf.org > >> https://www.ietf.org/mailman/listinfo/ipsec > > -------------- next part -------------- > > A non-text attachment was scrubbed... > > Name: smime.p7s > > Type: application/pkcs7-signature > > Size: 3708 bytes > > Desc: not available > > URL: < > http://www.ietf.org/mail-archive/web/ipsec/attachments/20141202/b7299f72/= attachment.p7s > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > ------------------------------ > > > > End of IPsec Digest, Vol 128, Issue 2 > > ************************************* > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --089e013cb9849bd76c051d853284 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you for taking time= to review the document and raising the issues. We noticed they have remain= ed unanswered yet, -- although your points have probably helped us clarifyi= ng the document. This email's intention is to address the issue you rai= sed. Feel free to let us know whether you agree on the response or if you w= oudl like additional information.

BR,
Daniel=C2=A0 =

%%%
ISSUE 1 : when is the =E2=80=98CLONE_IKE_SA=E2=80= =99 notification exactly sent - perhaps some examples (e.g. uplink route co= mes up)?

RESPONSE 1: The draft explicitly mentions two use cases, th= e mobility use case and the load sharing use case. Both use cases have been= detailled and Appendix A provides diagrams and figures to detail step by s= tep the mobility use case.

%%%
ISSUE 2: please consider good inte= gration with =E2=80=98Session Resumption=E2=80=99. particularly as a =E2=80= =98low-cal=E2=80=99 extension to section 4.3.3, someone alluded to this ear= lier.

RESPONSE 2: The Clone IKE SA mechanism is outside Session Resu= mption, so Session Resumption is not an issue for this draft.

%%%ISSUE 3: please consider consistency with the =E2=80=98ADDITIONAL_IP*_ADDR= ESS list, someone alluded to this earlier.

RESPONSE 3: The Clone IKE= SA mechanism use MOBIKE, but does not extend it and so remains outside MOB= IKE. Interactions with ADDITIONAL_IP*_ADDRESS is not an issue for this draf= t.

%%%
ISSUE 4: perhaps, a (configurable) maximum lifetime for th= e series of cloned IKE_SAs?
RESPONSE 4: The IKE_SA life time negociation= is not part of the IKEv2: RFC7296 section 2.8 mentions

"A diff= erence between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes were negotiate= d.=C2=A0 In IKEv2, each end of the SA is responsible for enforcing its own = lifetime policy on the SA and rekeying the SA when necessary.=C2=A0 If the = two ends have different lifetime policies, the end with the shorter lifetim= e will end up always being the one to request the rekeying.=C2=A0 If an SA = has been inactive for a long time and if an endpoint would not initiate the= SA in the absence of traffic, the endpoint MAY choose to close the SA inst= ead of rekeying it when its lifetime expires.=C2=A0 It can also do so if th= ere has been no traffic since the last time the SA was rekeyed."
%%%
ISSUE 5: What should be done for extraneous =E2=80=98CLONE_IKE_SA= =E2=80=99 notifications?
RESPONSE 5: This has been adressed in section 5= .2 of the current draft.

"The CLONE_IKE_SA notification MUST ap= pear only in request message of the CREATE_CHILD_SA exchange concerning the= IKE SA rekey. If the CLONE_IKE_SA notification appears in any other messag= e, it MUST be ignored."
=C2=A0

On Wed, Dec 3, 2014 at 7:09 AM, = Les Leposo <leposo@gmail.com> wrote:
Hi All,

there probably are gateways that currently perform =E2=80=98faux-cloning IK= E-SAs=E2=80=99 (e.g. through data replication tricks) - if so, they would o= nly have an opportunity to do so upon receiving favourable UPDATE_SA_ADDRES= SES notifications. I=E2=80=99m not sure if clients do this sort of thing.
So, I support this draft because it could help standardise how =E2=80=98low= -cal=E2=80=99 clients & distributed servers hand-over tunnels. It can a= lso be used to improve handovers, but, it potentially introduces some secur= ity risks.

This draft is like __builtin_prefetch - it can be great if used effectively= , otherwise it could get a little worse.

A few issues:
1) when is the =E2=80=98CLONE_IKE_SA=E2=80=99 notification exactly sent - p= erhaps some examples (e.g. uplink route comes up)?
2) please consider good integration with =E2=80=98Session Resumption=E2=80= =99. particularly as a =E2=80=98low-cal=E2=80=99 extension to section 4.3.3= , someone alluded to this earlier.
3) please consider consistency with the =E2=80=98ADDITIONAL_IP*_ADDRESS lis= t, someone alluded to this earlier.
4) perhaps, a (configurable) maximum lifetime for the series of cloned IKE_= SAs?
5) What should be done for extraneous =E2=80=98CLONE_IKE_SA=E2=80=99 notifi= cations?


> On Dec 3, 2014, at 2:20 AM, = ipsec-request@ietf.org wrote:
>
> Send IPsec mailing list submissions to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ipsec@ietf= .org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>=C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailm= an/listinfo/ipsec
> or, via email, send a message with subject or body 'help' to >=C2=A0 =C2=A0 =C2=A0 =C2=A0ip= sec-request@ietf.org
>
> You can reach the person managing the list at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ipse= c-owner@ietf.org
>
> When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPsec digest..."
>
>
> Today's Topics:
>
>=C2=A0 =C2=A01. Re: Survey for WG interest in adopting
>=C2=A0 =C2=A0 =C2=A0 draft-nagayama-ipsecme-ipsec-with-qkd (Yaron Sheff= er)
>=C2=A0 =C2=A02. Re: Survey for WG interest in adopting
>=C2=A0 =C2=A0 =C2=A0 draft-mglt-ipsecme-clone-ike-sa (Yaron Sheffer) >=C2=A0 =C2=A03. Re: Survey for WG interest in adopting
>=C2=A0 =C2=A0 =C2=A0 draft-nagayama-ipsecme-ipsec-with-qkd (Rodney Van = Meter)
>=C2=A0 =C2=A04. Re: Some speculations about puzzles (Graham Bartlett (g= rbartle))
>
>
> ----------------------------------------------------------------------=
>
> Message: 1
> Date: Tue, 02 Dec 2014 23:19:39 +0200
> From: Yaron Sheffer <yaron= f.ietf@gmail.com>
> To: Paul Hoffman <paul.hof= fman@vpnc.org>, IPsecME WG <ips= ec@ietf.org>
> Subject: Re: [IPsec] Survey for WG interest in adopting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-nagayama-ipsecme-ipsec-with-qkd
> Message-ID: <547E2CEB= .3020200@gmail.com>
> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed
>
> Here's a quick reminder to speak up if you're interested in th= is
> document and are willing to contribute as co-author or reviewer.
>
> Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron
>
> On 11/25/2014 10:06 PM, Paul Hoffman wrote:
>> <chair hats on>
>>
>> Greetings again. There is a small emerging industry of crypto solu= tions that transmit keys using Quantum Key Distribution (QKD), and then use= those keys for classical high-speed encryption. Several such solutions are= using IKE, and there is a perceived need to standardize this usage. If so,= that standardization should be done in this Working Group.
>>
>> If you agree with the need to standardize this usage, and believe = that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting = place for that standardization, and are willing to review and contribute te= xt to the document if it is adopted by the WG, please say so on the list. T= his WG has a history of adopting documents but then not having enough revie= wers for us to feel confident that we are making a good standard, so we nee= d to see a reasonable number of actively interested people before we adopt = the document. If it is not adopted, the authors can ask for it to be publis= hed as an RFC through individual submission or by the Independent Submissio= ns Editor.
>>
>> Please reply by December 8, 2015.
>>
>> --Paul Hoffman and Yaron Sheffer
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec<= br> >>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 02 Dec 2014 23:20:33 +0200
> From: Yaron Sheffer <yaron= f.ietf@gmail.com>
> To: Paul Hoffman <paul.hof= fman@vpnc.org>, IPsecME WG <ips= ec@ietf.org>
> Subject: Re: [IPsec] Survey for WG interest in adopting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-ipsecme-clone-ike-sa
> Message-ID: <547E2D21= .2070600@gmail.com>
> Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed
>
> And similarly for this draft: please speak up if you're interested= in
> this document and are willing to contribute as co-author or reviewer.<= br> >
> Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Yaron
>
> On 11/25/2014 10:06 PM, Paul Hoffman wrote:
>> <chair hats on>
>>
>> Greetings again. The "Clone IKE SA" proposal tries to op= timize IKE SA setup in cases where VPN gateways have multiple interfaces an= d want to establish different SAs on the different interfaces without havin= g to repeat the IKE authentication. Instead, they could clone a single IKE = SA multiple times, and then move it to different interfaces using MOBIKE. >>
>> If you agree with the need to standardize this usage, and believe = that draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place = for that standardization, and are willing to review and contribute text to = the document if it is adopted by the WG, please say so on the list. This WG= has a history of adopting documents but then not having enough reviewers f= or us to feel confident that we are making a good standard, so we need to s= ee a reasonable number of actively interested people before we adopt the do= cument. If it is not adopted, the authors can ask for it to be published as= an RFC through individual submission or by the Independent Submissions Edi= tor.
>>
>> Please reply by December 8, 2015.
>>
>> --Paul Hoffman and Yaron Sheffer
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec<= br> >>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 2 Dec 2014 17:49:58 -0500
> From: Rodney Van Meter <rdv@s= fc.wide.ad.jp>
> To: Yaron Sheffer <yaronf.= ietf@gmail.com>
> Cc: Rodney Van Meter <rdv@sfc= .wide.ad.jp>, IPsecME WG
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<ipsec@= ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>
> Subject: Re: [IPsec] Survey for WG interest in adopting
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft-nagayama-ipsecme-ipsec-with-qkd
> Message-ID: <F33B0D44-9229-4A9E-AB81-E506C8D9E15C@sfc.wide.ad.jp>= ;
> Content-Type: text/plain; charset=3Dutf-8
>
> Hi,
>
> Sorry to be a little slow to reply.=C2=A0 I was offline over Thanksgiv= ing, just saw the messages yesterday afternoon.
>
> Of course I favor adoption, and am willing to work with anyone who can= contribute to the development of an appropriate protocol.=C2=A0 Momentum s= eems to be toward a version supporting a variety of out-of-band mechanisms,= and I?m willing to work in that direction.
>
> Shota is looking in to the numerous issues I detailed in the long mess= age right after IETF.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0?Rod
>
>> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
>>
>> Here's a quick reminder to speak up if you're interested i= n this document and are willing to contribute as co-author or reviewer.
>>
>> Thanks,
>>=C2=A0 =C2=A0 =C2=A0 Yaron
>>
>> On 11/25/2014 10:06 PM, Paul Hoffman wrote:
>>> <chair hats on>
>>>
>>> Greetings again. There is a small emerging industry of crypto = solutions that transmit keys using Quantum Key Distribution (QKD), and then= use those keys for classical high-speed encryption. Several such solutions= are using IKE, and there is a perceived need to standardize this usage. If= so, that standardization should be done in this Working Group.
>>>
>>> If you agree with the need to standardize this usage, and beli= eve that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good start= ing place for that standardization, and are willing to review and contribut= e text to the document if it is adopted by the WG, please say so on the lis= t. This WG has a history of adopting documents but then not having enough r= eviewers for us to feel confident that we are making a good standard, so we= need to see a reasonable number of actively interested people before we ad= opt the document. If it is not adopted, the authors can ask for it to be pu= blished as an RFC through individual submission or by the Independent Submi= ssions Editor.
>>>
>>> Please reply by December 8, 2015.
>>>
>>> --Paul Hoffman and Yaron Sheffer
>>> _______________________________________________
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec<= /a>
>>>
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec<= br> >
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 2 Dec 2014 23:20:33 +0000
> From: "Graham Bartlett (grbartle)" <grbartle@cisco.com>
> To: Valery Smyslov <svanru@gmai= l.com>, Yoav Nir <ynir.iet= f@gmail.com>,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0ipsec <= ipsec@ietf.org>
> Subject: Re: [IPsec] Some speculations about puzzles
> Message-ID: <D0A3F897.34ED3%grbartle@cisco.com>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> Hi Valery
>
> Would the Timestamp be generated every time cycle? If this wasn't = a static
> figure (per timecycle - maybe when the secret is changed?, but rather = a
> rolling unix time), then how would the Responder be able to validate t= his
> Cookie (without trying every previous timestamp or having the timestam= p
> included in the Initiators reply?). Would it not be better to save X > number of Secrets and just try them instead (assuming that the Secret = is
> changing fairly regularly)? The Secret could also be used to tell (app= rox)
> how old the Cookie is.
>
>
> I like the two options of the header in the clear.
>
>
> Many thanks
>
> On 01/12/2014 15:34, "Valery Smyslov" <svanru@gmail.com> wrote:
>
>> Hi, this is a long message.
>>
>> First of all I think that the puzzles mechanism is a great tool >> to make DoS attacks harder for attackers and we should
>> try to incorporate it into IKE. Moreover, I think that
>> the puzzles could be used not only in IKE_SA_INIT, but also
>> to defend against DoS attacks in IKE_AUTH exchange (see below). >> However, the puzzles mechanism is a controversal thing,
>> since it requires an additional work from legitimate clients.
>> It could be particularly troublesome for small battery-powered wir= eless
>> devices (smartphones, IoT devices etc) - not only would it delay >> connection
>> setup, but it also would decrease battery lifetime.
>>
>> So think that the puzzles mechanism if incorporated into IKE shoul= d follow
>> some general principles:
>> 1. Puzzles should be optional. It should be possible for client to= just
>> return
>>=C2=A0 =C2=A0cookie even if puzzle is given by SGW).
>> 2. The ultimate decision whether to solve puzzle or ignore it shou= ld be
>> made
>> by client.
>> 3. Those, who ignore puzzles (for any reason - either they are leg= acy
>> clients
>>=C2=A0 =C2=A0or they decide to save battery) should still have a ch= ance to setup
>> connection
>>=C2=A0 =C2=A0(on "best effort" basis).
>>
>> In other words, let's consider puzzles mechanizm not as discri= minating
>> tool
>> ("those who cannot solve puzzles won't be allowed in"= ;), but as
>> a "first-class ticket" for those, who are ready to pay f= or it.
>> And the price for the first-class service should be high enough to= make it
>> unattractive for attackers.
>>
>>
>> Concrete proposals.
>>
>> 1. Algorithm agility for puzzles. It is relatively easy to achieve= . When
>> IKE_SA_INIT request comes from the client, the server could quicly= parse
>> it,
>> find SA payload and figure out the list of transforms the client p= roposes.
>> Then it could select mutually supported PRF and indicate it to the= client
>> in response containing puzzle. The puzzle in this case would look = like:
>> "please, give me a string of octets such, that if this PRF is= applied
>> to that string of octets using supplied cookie as the key, then th= e
>> result would contain this number of trailing zero bits" (anot= her option -
>> apply PRF to cookie + string of octets using zero key).
>>
>> Parsing IKE_SA_INIT message is a relatively easy task.
>> The side advantage of this approach is that the server
>> could quickly check the structure of the message and
>> the list of proposed transforms and wouldn't spend more resour= ces
>> in case the initial message is malformed or no proposals are accep= table
>> to the responder.
>>
>> 2. Cookie generation. Currently RFC7296 suggestd the following
>> formula to compute cookie:
>>
>>=C2=A0 =C2=A0Cookie =3D <VersionIDofSecret> | Hash(Ni | IPi |= SPIi | <secret>)
>>
>> With puzzles more information should be present in the cookie
>> to prevent some attacks from initiator. First, when
>> responder asks initiator to solve the puzzle, it sets puzzle
>> difficulty to some level and indicates it in the response message.=
>> When the solved puzzle is returned back to the responder,
>> it must know in a stateless manner what level of difficulty
>> it has requested. Otherwise the initiator could cheat. So responde= r
>> must encode this information into cookie, as the cookie is an enti= ty that
>> initiator cannot forge. Then, it is desirable to also include
>> timestamp into cookie to prevent initiator from re-using solved pu= zzles
>> and from collecting a lot of puzzles, solving them and then presen= ting
>> them
>> all at once. Including timestamp allows the responder
>> to determine how old this cookie is and, therefore,
>> how much time it was taken from the initiator to solve the puzzle.=
>> If the results are suspicious (an easy puzzle took too long to be = solved),
>> then the request should be rejected, even in the case it contains<= br> >> a valid solution for the puzzle. And in case of accepting
>> algorithm agility method described above the selected PRF
>> must also be encoded in cookie.
>>
>> So, the cookie generation would look like:
>>
>>=C2=A0 =C2=A0Cookie =3D <VersionIDofSecret> | <Timestamp&g= t; | <PuzzleDifficulty> |
>> <PRF>
>> |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Hash(Ni | IPi | SPIi | <Timestamp>= | <PuzzleDifficulty> | <PRF> |
>> <secret>)
>>
>> Note, that <PuzzleDifficulty> should be allowed to be zero h= ere -
>> in case it is just a cookie request with no puzzle request.
>>
>> To summarize here is a possible sequence of messages in IKE_SA_INI= T:
>>
>>=C2=A0 request=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-->= ; HDR, SA, KE, Ni,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [N(NAT_DETECTION_SOURCE_IP)+,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N(NAT_DETECTION_DESTINATION_IP),]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [V+][N+]
>>
>>=C2=A0 response with puzzle=C2=A0 =C2=A0 <-- HDR, N(COOKIE), N(P= UZZLE, PRF=3D<X>,
>> DIFFICULTY=3D<N>)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [V+][N+]
>>
>> Legacy client or client that don't want to spend recources on = puzzle
>> would ignore N(PUZZLE) and act as if only N(COOKIE) was received.<= br> >>
>>=C2=A0 request=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-->= ; HDR, [N(COOKIE),]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 SA, KE, Ni,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [N(NAT_DETECTION_SOURCE_IP)+,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N(NAT_DETECTION_DESTINATION_IP),]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [V+][N+]
>>
>> At this point the responder will:
>> - check that the cookie is valid
>> - retrieve timestamp and difficulty level from the cookie and ensu= res it
>> is
>> fresh for that level
>> - if the level is zero, then it means that no puzzle was requested=
>> - if the level is non-zero then it means that the initiator either=
>> doesn't support puzzles or is unwilling to solve them; in eith= er
>> case the request is processed on "best effort" basis - >> it could be served or dropped depending on current resource availa= bility
>> or on some probability (e.g.serve every Nth request in case of att= ack)
>>
>> Client, that is solved the puzzle:
>>
>>=C2=A0 request=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-->= ; HDR, [N(COOKIE),], N(PUZZLE_SOLUTION)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 SA, KE, Ni,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [N(NAT_DETECTION_SOURCE_IP)+,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N(NAT_DETECTION_DESTINATION_IP),]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 [V+][N+]
>>
>>
>> At this point the responder will:
>> - check that the cookie is valid
>> - retrieve timestamp and difficulty level from the cookie and ensu= res it
>> is
>> fresh for that level
>> - if the level is zero, then it means that no puzzle was requested= ,
>> but initiator still supplied some solution; in this case
>> N(PUZZLE_SOLUTION)
>> is ignored and the message is processed as described above
>> - if the level is non-zero then responder will retrieve PRF from t= he
>> cookie
>> and verify the correctness of supplied puzzle solution
>> - if everything is OK then this request is served with higher prio= rity
>>
>>
>> 3. Using puzzles in IKE_AUTH exchange. The draft
>> ipsecme-ddos-protection-00
>> describes DoS attack on IKE_AUTH exchange:
>>
>>=C2=A0 =C2=A0 =C2=A0 Sending an Authentication request is surprisin= gly cheap.=C2=A0 It
>> requires
>>=C2=A0 =C2=A0 =C2=A0 a proper IKE header with the correct IKE SPIs,= and it requires a
>>=C2=A0 =C2=A0 =C2=A0 single encrypted payload.=C2=A0 The content of= the payload might as well
>>=C2=A0 =C2=A0 =C2=A0 be junk.=C2=A0 The responder has to perform th= e relatively expensive key
>>=C2=A0 =C2=A0 =C2=A0 derivation, only to find that the Authenticati= on request does not
>> decrypt.
>>
>> I think that the puzzles could be used to make this attack substan= tially
>> more expensive for the attacker. The idea is to require the initia= tor
>> to supply an additional string of octets in IKE_AUTH request such,= that
>> applying PRF with the Nr as the key to this string of octets
>> concatenated with the content of the IKE_AUTH message will
>> result in some number of zero trailing bits. In this case if the a= ttacker
>> fills in the content of SK payload with garbage, it will be detect= ed
>> by the responder without performing DH computation. The level of >> difficulty
>> in this case must be set so, that the time needed to solve the puz= zle is
>> by the order of magnitude more, than to compute DH, so that
>> this attack becomes unattractive for potential attacker.
>>
>> There are some options where to place puzzle solution
>> in IKE_AUTH message.
>>
>> 1. It could be explicitely present as Notification payload
>>=C2=A0 =C2=A0 =C2=A0before Encrypted payload:
>>
>>=C2=A0 =C2=A0 =C2=A0 HDR, N(PUZZLE_SOLUTION), SK {IDi, [CERT,] [CER= TREQ,]
>>=C2=A0 =C2=A0 =C2=A0 [IDr,] AUTH, SAi2, TSi, TSr}
>>
>> 2. It could be placed right after Encrypted payload without
>>=C2=A0 =C2=A0 =C2=A0any header. In this case the length indicated i= n IKE Header
>>=C2=A0 =C2=A0 =C2=A0would be greater, than the length indicated in = Encrypted payload
>>=C2=A0 =C2=A0 =C2=A0header, and the solved puzzle would be placed i= n this gap.
>>
>>=C2=A0 =C2=A0 =C2=A0 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, = SAi2, TSi, TSr}
>> <solved
>> puzzle>
>>
>> In case of IKE fragmentation every fragment should contain
>> its own solution for the puzzle. Note also, that puzzles in IKE_AU= TH
>> are mandatory for initiator if they are requested by responder - >> the request won't be processed untill the initiator provides >> puzzle solution (this is unlike puzzles in IKE_SA_INIT, where
>> they should be optional).
>>
>>
>> Regards,
>> Valery Smyslov.
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec<= br> > -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 3708 bytes
> Desc: not available
> URL: <http://www.ietf.org/mail-archive/web/ipsec/attachments/20141202/b7299f72/a= ttachment.p7s>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
> ------------------------------
>
> End of IPsec Digest, Vol 128, Issue 2
> *************************************

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--089e013cb9849bd76c051d853284-- From nobody Mon Aug 17 10:47:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09001ACDBC for ; Mon, 17 Aug 2015 10:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1wYu6t4yUmC for ; Mon, 17 Aug 2015 10:47:09 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5DC1ACDF2 for ; Mon, 17 Aug 2015 10:47:01 -0700 (PDT) Received: by igui7 with SMTP id i7so61054477igu.0 for ; Mon, 17 Aug 2015 10:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=RXk67ttzJyI1pqWWahuv3sQUVaW+GuzCKasaQp3EEio=; b=0Qm9V/tqYs/2e2+toSxfdG/XyTB5rVklsFW9cIL5axez4zVtkZodoWeJsF68H2jzad pHJSK8sRoMUuIsSI+Vy5+9qxAZqXuUPVd/BfLQlPDdC2AofPCHU6brPTf9XcDvBaAr25 dfQgTf9wxyvhaOi4Gg7T6FlKgOAkaAxqms2ARdLmJp0bJDcW7GTOEC9rp/0tllOjGIw8 EaqojAK/ab+JYiYj78j3HbmLTUNI8mj12zttAk6srros/EO2CPHWkdNEmve1nFWIO6RY p6KPqzCoVZLrgCp26fExwmuFd0rjT42vn1+yHQ6Plny663OsMGF52TFNs8hps0yhXaC3 m3/A== MIME-Version: 1.0 X-Received: by 10.50.13.10 with SMTP id d10mr19507615igc.20.1439833620734; Mon, 17 Aug 2015 10:47:00 -0700 (PDT) Sender: mglt.ietf@gmail.com Received: by 10.79.21.196 with HTTP; Mon, 17 Aug 2015 10:47:00 -0700 (PDT) In-Reply-To: <21624.32179.838590.460413@fireball.kivinen.iki.fi> References: <21624.32179.838590.460413@fireball.kivinen.iki.fi> Date: Mon, 17 Aug 2015 13:47:00 -0400 X-Google-Sender-Auth: nr6dTbQbMQbvLknjjIyoyLnyjEE Message-ID: From: Daniel Migault To: Tero Kivinen Content-Type: multipart/alternative; boundary=089e011848747fe92e051d856310 Archived-At: Cc: IPsecME WG , Valery Smyslov , Paul Wouters Subject: Re: [IPsec] Survey for WG interest in adoptingdraft-mglt-ipsecme-clone-ike-sa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 17:47:11 -0000 --089e011848747fe92e051d856310 Content-Type: text/plain; charset=UTF-8 Hi, Thank you Tero for providing these explanation, We would like to update the current draft with additional text on SA duplication and its associated issues raised by Paul. We believe it would also help to position/understand Clone IKE SA. The text is expected to be added in the introduction. Feel free to let us know whether you beleive the text is clear enough, or if you have any additional comments before we publish a new version. Introduction [...] Another scenario is a load-balancing solution. Load-sharing clusters often are built so, that they are transparent for VPN End Users. In case of IPsec it means that IKE and IPsec SA states are duplicated on every cluster node where load balancer can redirect packets. The drawback of such approach is that anti-replay related data (in particular Sequence Number) must be transactionally syncronized betweed participating nodes per every outgoing AH or ESP packet, which makes building high-speed systems problematic. Another approach for building load-balancing systems is to make VPN End Users aware of them, which allows to have two or more Security Gateways sharing the same ID, but each having its own IP address. In this case the VPN End User first establishes an IKE SA with one of these gateways. Then, at some point of time the gateway takes a decision to move client to a different cluster node. This can be done with Redirect Mechanism for IKEv2 [RFC5685]. The drawback of such approach is that it requires new IKE SA to be established from scratch, including full authentication. In some cases this could be avoided by using IKEv2 Session Resumption [RFC5723] with a new gateway. However this requires VPN End User to know beforehand which new gateway to connect to. So it is desirable to be able to clone existing IKE SA, to move it to a different Security Gateway, and then to indicate VPN End User to use this new SA. This would allow participating Security Gateways to share the load between them. BR, Daniel and Valery On Fri, Nov 28, 2014 at 8:50 AM, Tero Kivinen wrote: > Paul Wouters writes: > > On Thu, 27 Nov 2014, Valery Smyslov wrote: > > > > > I think that the mechanism it describes is useful and could be used > > > as a building block for several solutions. For example, > > > it can be used in load-sharing scenario when there are > > > some gateways with different IP addresses, that share > > > the same credentials. If client established IKE SA with > > > any of them then the SA could be cloned and transfered > > > to other nodes of this cluster without reauthentication, > > > and the traffic from client then could be balanced > > > among those gateways. > > > > That would run into replay protection problems, just like if you copy > > all kernel IPsec state between machines. And I believe load sharing > > when properly done should be invisible to client side and not need > > special support. > > Actually I tihnk the idea is to get rid of the replay protection > issues. In normal case if you just copy all IKE and IPsec state > between the servers, then you need to make sure you also copy all > replay data. If you clone the IKE SA, move the cloned IKE SA to new > IP-address (and new load sharing server in the cluster), and then > create the IPsec Child SAs there, then each of the replay data is only > located in the server you are talking to, and there is no need to move > replay data between the cluster members. > > If the load sharing is done so it is invisible to the client, then you > always end up problems with the replay protection data. If it is done > this way where the client is aware of the different cluster members > then there is no problem with the replay protection data. > > > I am interested in the problem, but have bad feelings about throwing > > around IKE states from two peers to another peer, which this > > mechanism seems to leave open. > > No, this draft addresses just that problem, i.e. it WILL NOT throw > away IKE states from peer to another. It will simply clone the current > IKEv2 SA, so after the operation there are two completely independent > IKEv2 SAs. Each of those IKEv2 SAs have their own replay windows, and > counters, and both have their own independent set of Child SAs. > > The draft mentions tha twe already have MOBIKE which can be used to > move the IKEv2 SA and all associated Child SAs from one IP to another, > i.e. it can be used to transfer SA from one IP address to another, and > if the second IP address is not actually in the same physical box, but > happens to be IP address of the another member in the shared cluster, > that is something that client cannot know. The cluster just then need > to make sure that it transfers the another independed IKE SA to that > other peer when doing mobike operation to change the IP address. > > > For instance, I would much rather see some informational exchange > > method or create child sa method using the existing IKE SA for > > conveying this information and somehow creatie the additional new > > Child SA. > > I do not understand what you are meaning here. > > > Throwing around private keys or computed shared secrets to multiple > > peers worry me. > > Private keys do not need to be transmitted, only the SKEYSEED and > material generated from there needs to be transmitted (i.e. the > computed shared state). Doing load-sharing without the client > knowledge, do require exactly same material to be transmitted, but in > addition to that all the replay protection related material needs to > be transmitted also. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --089e011848747fe92e051d856310 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Thank you Tero for provid= ing these explanation, We would like to update the current draft with addit= ional text on SA duplication and its associated issues raised by Paul. We b= elieve it would also help to position/understand Clone IKE SA. The text is = expected to be added in the introduction. Feel free to let us know whether = you beleive the text is clear enough, or if you have any additional comment= s before we publish a new version.


Introduction

[...]
=C2=A0=C2=A0 Another scenario is a load-balancing solution.=C2=A0 Load= -sharing clusters
=C2=A0=C2=A0 often are built so, that they are transpa= rent for VPN End Users.=C2=A0 In
=C2=A0=C2=A0 case of IPsec it means tha= t IKE and IPsec SA states are duplicated on
=C2=A0=C2=A0 every cluster n= ode where load balancer can redirect packets.=C2=A0 The
=C2=A0=C2=A0 dra= wback of such approach is that anti-replay related data (in
=C2=A0=C2=A0= particular Sequence Number) must be transactionally syncronized
=C2=A0= =C2=A0 betweed participating nodes per every outgoing AH or ESP packet,
= =C2=A0=C2=A0 which makes building high-speed systems problematic.=C2=A0 Ano= ther
=C2=A0=C2=A0 approach for building load-balancing systems is to mak= e VPN End Users
=C2=A0=C2=A0 aware of them, which allows to have two or = more Security Gateways
=C2=A0=C2=A0 sharing the same ID, but each having= its own IP address.=C2=A0 In this
=C2=A0=C2=A0 case the VPN End User fi= rst establishes an IKE SA with one of these
=C2=A0=C2=A0 gateways.=C2=A0= Then, at some point of time the gateway takes a decision
=C2=A0=C2=A0 t= o move client to a different cluster node.=C2=A0 This can be done with
= =C2=A0=C2=A0 Redirect Mechanism for IKEv2 [RFC5685].=C2=A0 The drawback of = such
=C2=A0=C2=A0 approach is that it requires new IKE SA to be establis= hed from
=C2=A0=C2=A0 scratch, including full authentication.=C2=A0 In s= ome cases this could be
=C2=A0=C2=A0 avoided by using IKEv2 Session Resu= mption [RFC5723] with a new
=C2=A0=C2=A0 gateway.=C2=A0 However this req= uires VPN End User to know beforehand which
=C2=A0=C2=A0 new gateway to = connect to.=C2=A0 So it is desirable to be able to clone
=C2=A0=C2=A0 ex= isting IKE SA, to move it to a different Security Gateway, and then
=C2= =A0=C2=A0 to indicate VPN End User to use this new SA.=C2=A0 This would all= ow
=C2=A0=C2=A0 participating Security Gateways to share the load betwee= n them.



BR,
Daniel and Valery


= =C2=A0

O= n Fri, Nov 28, 2014 at 8:50 AM, Tero Kivinen <kivinen@iki.fi> = wrote:
Paul Wouters writ= es:
> On Thu, 27 Nov 2014, Valery Smyslov wrote:
>
> > I think that the mechanism it describes is useful and could be us= ed
> > as a building block for several solutions. For example,
> > it can be used in load-sharing scenario when there are
> > some gateways with different IP addresses, that share
> > the same credentials. If client established IKE SA with
> > any of them then the SA could be cloned and transfered
> > to other nodes of this cluster without reauthentication,
> > and the traffic from client then could be balanced
> > among those gateways.
>
> That would run into replay protection problems, just like if you copy<= br> > all kernel IPsec state between machines. And I believe load sharing > when properly done should be invisible to client side and not need
> special support.

Actually I tihnk the idea is to get rid of the replay protection
issues. In normal case if you just copy all IKE and IPsec state
between the servers, then you need to make sure you also copy all
replay data. If you clone the IKE SA, move the cloned IKE SA to new
IP-address (and new load sharing server in the cluster), and then
create the IPsec Child SAs there, then each of the replay data is only
located in the server you are talking to, and there is no need to move
replay data between the cluster members.

If the load sharing is done so it is invisible to the client, then you
always end up problems with the replay protection data. If it is done
this way where the client is aware of the different cluster members
then there is no problem with the replay protection data.

> I am interested in the problem, but have bad feelings about throwing > around IKE states from two peers to another peer, which this
> mechanism seems to leave open.

No, this draft addresses just that problem, i.e. it WILL NOT throw away IKE states from peer to another. It will simply clone the current
IKEv2 SA, so after the operation there are two completely independent
IKEv2 SAs. Each of those IKEv2 SAs have their own replay windows, and
counters, and both have their own independent set of Child SAs.

The draft mentions tha twe already have MOBIKE which can be used to
move the IKEv2 SA and all associated Child SAs from one IP to another,
i.e. it can be used to transfer SA from one IP address to another, and
if the second IP address is not actually in the same physical box, but
happens to be IP address of the another member in the shared cluster,
that is something that client cannot know. The cluster just then need
to make sure that it transfers the another independed IKE SA to that
other peer when doing mobike operation to change the IP address.

> For instance, I would much rather see some informational exchange
> method or create child sa method using the existing IKE SA for
> conveying this information and somehow creatie the additional new
> Child SA.

I do not understand what you are meaning here.

> Throwing around private keys or computed shared secrets to multiple > peers worry me.

Private keys do not need to be transmitted, only the SKEYSEED and material generated from there needs to be transmitted (i.e. the
computed shared state). Doing load-sharing without the client
knowledge, do require exactly same material to be transmitted, but in
addition to that all the replay protection related material needs to
be transmitted also.
--
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--089e011848747fe92e051d856310-- From nobody Tue Aug 18 17:04:09 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1CF1A00BE for ; Tue, 18 Aug 2015 17:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rVrWYWEc7zL for ; Tue, 18 Aug 2015 17:04:07 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 61A3C1A00ED for ; Tue, 18 Aug 2015 17:04:07 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 10B40A888132 for ; Tue, 18 Aug 2015 17:04:07 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 18 Aug 2015 17:04:07 -0700 (PDT) Message-ID: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> Date: Tue, 18 Aug 2015 17:04:07 -0700 (PDT) From: "Dan Harkins" To: "IPsecME WG" 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 Archived-At: Subject: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 00:04:09 -0000 https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml "CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant implementations of the IKE standard (IKEv1) together with large, high-entropy, pre-shared keys and the AES-256 encryption algorithm. RFC 2409 is the only version of the IKE standard that leverages symmetric pre-shared keys in a manner that may achieve quantum resistant confidentiality." :-) Dan. From nobody Wed Aug 19 10:16:43 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60E61A1B8B for ; Wed, 19 Aug 2015 10:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIQvc0Lg9iB0 for ; Wed, 19 Aug 2015 10:16:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75221A1BEC for ; Wed, 19 Aug 2015 10:16:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 19B2B20098; Wed, 19 Aug 2015 13:34:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7396B63B10; Wed, 19 Aug 2015 13:16:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0DEEB63AEC; Wed, 19 Aug 2015 13:16:37 -0400 (EDT) From: Michael Richardson To: "Dan Harkins" In-Reply-To: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 17:16:41 -0000 --=-=-= Content-Type: text/plain Dan Harkins wrote: > https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml > "CSfC deployments involving an IKE/IPsec layer may use RFC > 2409-conformant implementations of the IKE standard (IKEv1) > together with large, high-entropy, pre-shared keys and the > AES-256 encryption algorithm. RFC 2409 is the only version > of the IKE standard that leverages symmetric pre-shared keys > in a manner that may achieve quantum resistant confidentiality." So, all of IKEv2 is out, according to them? Or they just didn't consider it yet? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdS59ICLcPvd0N1lAQKpmwf+Op4ITf+hkIIt9i30TOxOLeoLEo6PZDHq 2oMWS3A7kMtFlYhcdqnbsK01AMXtZz8N4bTxY50Q2eY6g0JHyEvY0Ofkxs1umNyk JWLTc8DuVMR45qcW+kJEH0iWbXMRNiFTq4dFz9k/3rZTjn6i+H0h3xQj1LTnsPgw /xcU1FnfvObvQKeCgv8rhXs8hQlFAWQzyBRwJT1yAwUcDL/wUnA9Jbrj7KxFawa4 4rAs4lCez4YC0TUsZxEYOwiy6QHfBxS7YE4B9K/TfALqvtEQ7RY26uvjCNAz8Jve ++ZDbdujvy2RU2cSM9UcpWVK1UUgrM0TQx5fPtVI9wQoJPxi5nFaXA== =Od6I -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 19 10:33:20 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFBD1A7032 for ; Wed, 19 Aug 2015 10:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPtoMds8XA2O for ; Wed, 19 Aug 2015 10:33:16 -0700 (PDT) Received: from mx5r.gridway.net (mx5.gridway.net [74.216.186.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 141021A7021 for ; Wed, 19 Aug 2015 10:32:42 -0700 (PDT) Received: from delivery.mygridway.net (delivery.mygridway.net [72.1.205.180]) by mx5r.gridway.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t7JHVwgE031531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2015 13:32:41 -0400 Received: from MPBEEXCHANGE.gwhosting.local ([172.17.12.4]) by mpbeexchange.gwhosting.local ([172.17.12.4]) with mapi id 14.03.0224.002; Wed, 19 Aug 2015 13:32:11 -0400 From: Mike Borza To: Michael Richardson , Dan Harkins Thread-Topic: [IPsec] PSK mode Thread-Index: AQHQ2hLatfV2Ohm57kWvDTcucxr8454T1ISA//++eEA= Date: Wed, 19 Aug 2015 17:32:09 +0000 Message-ID: <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> In-Reply-To: <31446.1440004597@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.114.47.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=72.1.205.180; country=CA; region=Ontario; city=Ottawa; latitude=45.3467; longitude=-75.7700; http://maps.google.com/maps?q=45.3467,-75.7700&z=6 X-CanItPRO-Stream: base:outbound (inherits from base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 207.107.149.162 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 17:33:18 -0000 They don't mention IKEv2. I don't know IKEv2 well enough to know whether t= here are any symmetric PSK authentication schemes, but if not, perhaps ther= e should be. The point they're making is that the ECC-based authentication= methods become insecure when quantum computers of sufficient power become = available, and in light of recent progress in the field the indications are= that they will become available in a reasonably short timeframe. (And they= should know that timeframe better than just about anybody else.) I view t= his as an indication that they believe there may be viable QCs of that capa= bility in the five to ten years timeframe. Mike -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Wednesday, August 19, 2015 13:17 To: Dan Harkins Cc: IPsecME WG Subject: Re: [IPsec] PSK mode Dan Harkins wrote: > https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml > "CSfC deployments involving an IKE/IPsec layer may use RFC > 2409-conformant implementations of the IKE standard (IKEv1) > together with large, high-entropy, pre-shared keys and the > AES-256 encryption algorithm. RFC 2409 is the only version > of the IKE standard that leverages symmetric pre-shared keys > in a manner that may achieve quantum resistant confidentiality." So, all of IKEv2 is out, according to them? Or they just didn't consider it yet? -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Wed Aug 19 10:49:36 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12221A1EF6 for ; Wed, 19 Aug 2015 10:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKyXxBU7EM-5 for ; Wed, 19 Aug 2015 10:49:32 -0700 (PDT) Received: from ausxipps301.us.dell.com (ausxipps301.us.dell.com [143.166.148.223]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A091A1F70 for ; Wed, 19 Aug 2015 10:49:22 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=GUfm3qhgFlNMHmPz+LWWE9WV61PJwshUYsYnAtFq2pkVh+rVZpmwkdDr dY2M6YAJu5nmFcqMtCumGkb+tkkL/gK2B4GnOit71jw5vyvMBrerlbYv/ nqeaDTpmNZPhktUjZTWymdYxsRWaHYe0o7asP0F1BJ7bvWWN3xJbjc9hz w=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1440006563; x=1471542563; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=DN6IZ7qMxFAcgeNF+cLU74M/YN1Qmu9ybbrmXHgrMZ4=; b=aGhMR5mdFFn+/UJUnjZQX+m26BezSxSWseTc2EkgI7F6uixhDGCHZN4e fTK7n2fWDFT+Luw8clgllDS5aaH0VTnmpoy3DM0YO0/pXqH8FcD/883RH XR9KrWOgmMhwZCvl1OHzQKB9eZxETSC1Ordo8ntBGGimh5jJNEvL895wM E=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.15,711,1432616400"; d="scan'208";a="692526639" From: To: Thread-Topic: [IPsec] PSK mode Thread-Index: AQHQ2hKtJyQ3yJtgp0y3WFyLL5jGGZ4T5UiAgAAEV4CAAATNAA== Date: Wed, 19 Aug 2015 17:49:20 +0000 Message-ID: References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> In-Reply-To: <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.178.128.192] Content-Type: text/plain; charset="utf-8" Content-ID: <69DCEE705972E14485406B426E60C93B@dell.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org, mcr+ietf@sandelman.ca, dharkins@lounge.org Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 17:49:33 -0000 DQo+IE9uIEF1ZyAxOSwgMjAxNSwgYXQgMTozMiBQTSwgTWlrZSBCb3J6YSA8bWJvcnphQGVsbGlw dGljdGVjaC5jb20+IHdyb3RlOg0KPiANCj4gVGhleSBkb24ndCBtZW50aW9uIElLRXYyLiAgSSBk b24ndCBrbm93IElLRXYyIHdlbGwgZW5vdWdoIHRvIGtub3cgd2hldGhlciB0aGVyZSBhcmUgYW55 IHN5bW1ldHJpYyBQU0sgYXV0aGVudGljYXRpb24gc2NoZW1lcywgYnV0IGlmIG5vdCwgcGVyaGFw cyB0aGVyZSBzaG91bGQgYmUuICBUaGUgcG9pbnQgdGhleSdyZSBtYWtpbmcgaXMgdGhhdCB0aGUg RUNDLWJhc2VkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgYmVjb21lIGluc2VjdXJlIHdoZW4gcXVh bnR1bSBjb21wdXRlcnMgb2Ygc3VmZmljaWVudCBwb3dlciBiZWNvbWUgYXZhaWxhYmxlLCBhbmQg aW4gbGlnaHQgb2YgcmVjZW50IHByb2dyZXNzIGluIHRoZSBmaWVsZCB0aGUgaW5kaWNhdGlvbnMg YXJlIHRoYXQgdGhleSB3aWxsIGJlY29tZSBhdmFpbGFibGUgaW4gYSByZWFzb25hYmx5IHNob3J0 IHRpbWVmcmFtZS4gKEFuZCB0aGV5IHNob3VsZCBrbm93IHRoYXQgdGltZWZyYW1lIGJldHRlciB0 aGFuIGp1c3QgYWJvdXQgYW55Ym9keSBlbHNlLikgIEkgdmlldyB0aGlzIGFzIGFuIGluZGljYXRp b24gdGhhdCB0aGV5IGJlbGlldmUgdGhlcmUgbWF5IGJlIHZpYWJsZSBRQ3Mgb2YgdGhhdCBjYXBh YmlsaXR5IGluIHRoZSBmaXZlIHRvIHRlbiB5ZWFycyB0aW1lZnJhbWUuDQoNCkNvdWxkIHlvdSBw b2ludCB0byByZWZlcmVuY2VzIHRoYXQgZGlzY3VzcyByZWFsIHF1YW50dW0gY29tcHV0ZXJzPyAg SSBzcGVudCBhIHdoaWxlIHJlYWRpbmcgb24gdGhpcyBzdWJqZWN0IHdpdGhpbiB0aGUgcGFzdCB5 ZWFyLCBhbmQgYXMgZmFyIGFzIEkgY291bGQgdGVsbCwgcXVhbnR1bSBjb21wdXRlcnMgYXJlIGEg dmVyeSBpbnRlcmVzdGluZyB0aGVvcnkgYnV0IG5vbmUgeWV0IGV4aXN0IGluIHByYWN0aWNlLg0K DQpJIGxvb2tlZCBmb3IgYSBkZXNjcmlwdGlvbiBvZiB0aGlzZSDigJxTdWl0ZSBCIGFsZ29yaXRo bXPigJ0gYnV0IGl0IHdhc27igJl0IG9idmlvdXMuDQoNCkRvZXNu4oCZdCBQU0sgaW52b2x2ZSBE aWZmaWUtSGVsbG1hbiBrZXkgYWdyZWVtZW50PyAgSSB0aG91Z2h0IHRoYXQgU2hvcuKAmXMgYWxn b3JpdGhtIChvciBhIGdlbmVyYWxpemF0aW9uIG9mIGl0KSBhZGRyZXNzZXMgdGhlIGRpc2NyZXRl IGxvZyBwcm9ibGVtLg0KDQoJcGF1bA0K From nobody Wed Aug 19 12:19:33 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5281A017A for ; Wed, 19 Aug 2015 12:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pUv4FhPeaAaV for ; Wed, 19 Aug 2015 12:19:30 -0700 (PDT) Received: from mx5r.gridway.net (mx5.gridway.net [74.216.186.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EADD21A0024 for ; Wed, 19 Aug 2015 12:19:28 -0700 (PDT) Received: from delivery.mygridway.net (delivery.mygridway.net [72.1.205.180]) by mx5r.gridway.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id t7JJJOQJ027633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 19 Aug 2015 15:19:24 -0400 Received: from MPBEEXCHANGE.gwhosting.local ([172.17.12.4]) by mpbeexchange.gwhosting.local ([172.17.12.4]) with mapi id 14.03.0224.002; Wed, 19 Aug 2015 15:19:24 -0400 From: Mike Borza To: "Paul_Koning@Dell.com" Thread-Topic: [IPsec] PSK mode Thread-Index: AQHQ2hLatfV2Ohm57kWvDTcucxr8454T1ISA//++eECAAEqsAP//wC9g Date: Wed, 19 Aug 2015 19:19:24 +0000 Message-ID: <29C194186F21E3449DEE427644BBCA087BEC9BA4@mpbeexchange.gwhosting.local> References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.114.47.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CanIt-Geo: ip=72.1.205.180; country=CA; region=Ontario; city=Ottawa; latitude=45.3467; longitude=-75.7700; http://maps.google.com/maps?q=45.3467,-75.7700&z=6 X-CanItPRO-Stream: base:outbound (inherits from base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 207.107.149.162 Archived-At: Cc: "ipsec@ietf.org" , "mcr+ietf@sandelman.ca" , "dharkins@lounge.org" Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 19:19:32 -0000 Tm8sIEkgY2FuJ3QgcG9pbnQgdG8gcmVhbCBxdWFudHVtIGNvbXB1dGVycyBsYXJnZXIgdGhhbiBh IGhhbmRmdWwgb2YgcXViaXRzLiAgV2hlbiBJIHNhdyB0aGVzZSAoaHR0cDovL3d3dy5uYXR1cmUu Y29tL25jb21tcy8yMDE1LzE1MDQyOS9uY29tbXM3OTc5L2Z1bGwvbmNvbW1zNzk3OS5odG1sIGFu ZCBodHRwOi8vd3d3Lm5hdHVyZS5jb20vbmF0dXJlL2pvdXJuYWwvdjUxOS9uNzU0MS9mdWxsL25h dHVyZTE0MjcwLmh0bWwpIGVhcmxpZXIgdGhpcyB5ZWFyLCBpdCB3YXMgdGhlIGZpcnN0IGluZGlj YXRpb24gdG8gbWUgdGhhdCB0aGUgZW1lcmdlbmNlIG9mIHJlYWwgcXVhbnR1bSBjb21wdXRlcnMg b2Ygc2lnbmlmaWNhbnQgY2FwYWJpbGl0eSBtYXkgYmUgY2xvc2VyIHRoYW4gSSBwcmV2aW91c2x5 IGV4cGVjdGVkLiAgSSB3YXMgbm90IGV4cGVjdGluZyB0aGUgZmlkZWxpdHkgcHJvYmxlbSB0byBi ZSByZXNvbHZlZCBmb3Igc29tZSB0aW1lIHRvIGNvbWUgeWV0LCBidXQgdGhpcyBpcyBhICh0aGU/ KSBmdW5kYW1lbnRhbCBpbXBlZGltZW50IHRvIHJlYWwgUUNzLiAgSWYgaXQncyByZXNvbHZlZCAo YW5kIEkgZG9uJ3Qga25vdyBmb3IgY2VydGFpbiB0aGF0IGl0IHdpbGwgYmUgYnkgdGhlc2UgbWV0 aG9kcykgdGhlbiBwcm9ncmVzcyBtYXkgYmUgcmVsYXRpdmVseSBxdWljay4gIFdpdGggdGhhdCBp biBtaW5kLCBJIGluZmVycmVkIGZyb20gdGhlIHN1aXRlIEIgdXBkYXRlIHRoYXQgTlNBIGp1ZGdl cyBwcm9ncmVzcyBpbiB0aGUgYXJlYSBvZiBwcm9kdWNpbmcgdmlhYmxlIHF1YW50dW0gY29tcHV0 ZXJzIG9mIHN1ZmZpY2llbnQgY2FwYWJpbGl0eSB0byBiZSBvbiB0aGUgaG9yaXpvbiB0b28uICBH b2luZyBiYWNrIHRvLCBhbmQgZXhwYW5kaW5nIG9uLCB0aGUgdGV4dCBvZiB0aGUgYW5ub3VuY2Vt ZW50IHRoYXQgRGFuIHF1b3RlZCBpbiBraWNraW5nIHRoaXMgYWxsIG9mZjoNCg0KIkZvciBleGFt cGxlLCBDU2ZDIGRlcGxveW1lbnRzIGludm9sdmluZyBhbiBJS0UvSVBzZWMgbGF5ZXIgbWF5IHVz ZSBSRkMgMjQwOS1jb25mb3JtYW50IGltcGxlbWVudGF0aW9ucyBvZiB0aGUgSUtFIHN0YW5kYXJk IChJS0V2MSkgdG9nZXRoZXIgd2l0aCBsYXJnZSwgaGlnaC1lbnRyb3B5LCBwcmUtc2hhcmVkIGtl eXMgYW5kIHRoZSBBRVMtMjU2IGVuY3J5cHRpb24gYWxnb3JpdGhtLiAgUkZDIDI0MDkgaXMgdGhl IG9ubHkgdmVyc2lvbiBvZiB0aGUgSUtFIHN0YW5kYXJkIHRoYXQgbGV2ZXJhZ2VzIHN5bW1ldHJp YyBwcmUtc2hhcmVkIGtleXMgaW4gYSBtYW5uZXIgdGhhdCBtYXkgYWNoaWV2ZSBxdWFudHVtIHJl c2lzdGFudCBjb25maWRlbnRpYWxpdHkuIEFkZGl0aW9uYWxseSwgTUFDc2VjIGtleSBhZ3JlZW1l bnQgYXMgc3BlY2lmaWVkIGluIElFRUUgODAyLjFYLTIwMTAsIGFuZCB0aGUgUkZDIDQyNzkgVExT IHNwZWNpZmljYXRpb24gcHJvdmlkZSBmdXJ0aGVyIG9wdGlvbnMgZm9yIGltcGxlbWVudGluZyBx dWFudHVtIHJlc2lzdGFudCBzZWN1cml0eSBtZWFzdXJlcyB0b2RheS4gVGhlc2Ugb3B0aW9ucyBh bHNvIGludm9sdmUga2V5IGFncmVlbWVudCBzY2hlbWVzIHRoYXQgbGV2ZXJhZ2UgbGFyZ2Ugc3lt bWV0cmljIHByZS1zaGFyZWQga2V5cy4NCg0KV2l0aCByZXNwZWN0IHRvIElBRCBjdXN0b21lcnMg dXNpbmcgbGFyZ2UsIHVuY2xhc3NpZmllZCBQS0kgc3lzdGVtcywgcmVtYWluaW5nIGF0IDExMiBi aXRzIG9mIHNlY3VyaXR5IChpLmUuIDIwNDgtYml0IFJTQSkgbWF5IGJlIHByZWZlcmFibGUgKG9y IHNvbWV0aW1lcyBuZWNlc3NhcnkgZHVlIHRvIGJ1ZGdldCBjb25zdHJhaW50cykgZm9yIHRoZSBu ZWFyLXRlcm0gaW4gYW50aWNpcGF0aW9uIG9mIGRlcGxveWluZyBxdWFudHVtIHJlc2lzdGFudCBh c3ltbWV0cmljIGFsZ29yaXRobXMgdXBvbiB0aGVpciBmaXJzdCBhdmFpbGFiaWxpdHkuIg0KDQpB IGtleSBwYXJ0IG9mIFNob3IncyBhbGdvcml0aG0gdGhhdCBiZW5lZml0cyBmcm9tIGEgUUMgaXMg ZXNzZW50aWFsbHkgcGFyYWxsZWxpemVkIGJydXRlIGZvcmNlIGF0dGFjayBvbiB0aGUgaW52ZXJz aW9uIG9mIHRoZSAiaGFyZCIgcHJvYmxlbSBvbiB3aGljaCB0aGUgY3J5cHRvc3lzdGVtIGlzIGJh c2VkLCB3aGV0aGVyIHRoYXQncyBjb21wdXRpbmcgYSBkaXNjcmV0ZSBmYWN0b3JpemF0aW9uLCBk aXNjcmV0ZSBsb2dhcml0aG0gb3IgYW4gZWxsaXB0aWMgY3VydmUgZGlzY3JldGUgbG9nYXJpdGht LiAgSW4gdGhhdCBjYXNlIHRoZSB0aW1lIHRvIGNvbXB1dGUgYSBzb2x1dGlvbiBpcyBwcm9wb3J0 aW9uYWwgdG8gTyhOLzIpIGZvciBOLWJpdHMga2V5cywgYW5kIGludmVyc2VseSBwcm9wb3J0aW9u YWwgdG8gdGhlIG51bWJlciBvZiBxdWJpdHMgdGhhdCBjYW4gYmUgYnJvdWdodCB0byBiZWFyIG9u IHRoZSBwcm9ibGVtLiAgQXMgInNtYWxsIiBRQ3Mgd2lsbCBhbG1vc3QgY2VydGFpbmx5IGJlIGF2 YWlsYWJsZSBiZWZvcmUgbGFyZ2VyIG9uZXMsIHN5c3RlbXMgYmFzZWQgb24gc21hbGxlciBrZXlz IHdpbGwgZmFsbCB0byB0aG9zZSBhdHRhY2tzIGVhcmxpZXIgdGhhbiBsYXJnZXIgb25lcywgYW5k IHRoZSBkaWZmZXJlbmNlIHdpbGwgYmUgc2l6ZWFibGUuICBTbyBsYXJnZSBSU0Ega2V5cywgb3Ig REgga2V5cywgd2lsbCByZXF1aXJlIG11Y2ggbGFyZ2VyIHF1YW50dW0gY29tcHV0ZXJzIHRvIGJy ZWFrIHRoYW4gZm9yIEVDQyBrZXlzIG9mIDI1NiBvciAzODQgYml0cy4gIElmIHRoZSBlcnJvciBj b3JyZWN0aW9uIGNhcGFiaWxpdGllcyBkb24ndCBjb250aW51ZSB0byBzY2FsZSB1cCBlYXNpbHks IHRoZW4gbGFyZ2VyIGtleXMgb2Ygb3RoZXIgY3J5cHRvIHN5c3RlbXMgbWF5IHJlbWFpbiBzZWN1 cmUgc2lnbmlmaWNhbnRseSBsb25nZXIuDQoNCkxpa2UgeW91LCBJIGxvb2tlZCBmb3Igc29tZSBk aXJlY3Qgc3RhdGVtZW50IHRoYXQgdGhlIGNhcGFiaWxpdHkgd291bGQgYmUgYXZhaWxhYmxlIGlu IGEgcmVhc29uYWJsZSB0aW1lZnJhbWUsIGJ1dCBJIHdhc24ndCBzdXJwcmlzZWQgbm90IHRvIHNl ZSBpdC4NCg0KTWlrZQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQYXVs X0tvbmluZ0BEZWxsLmNvbSBbbWFpbHRvOlBhdWxfS29uaW5nQERlbGwuY29tXSANClNlbnQ6IFdl ZG5lc2RheSwgQXVndXN0IDE5LCAyMDE1IDEzOjQ5DQpUbzogTWlrZSBCb3J6YSA8bWJvcnphQGVs bGlwdGljdGVjaC5jb20+DQpDYzogbWNyK2lldGZAc2FuZGVsbWFuLmNhOyBkaGFya2luc0Bsb3Vu Z2Uub3JnOyBpcHNlY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJUHNlY10gUFNLIG1vZGUNCg0K DQo+IE9uIEF1ZyAxOSwgMjAxNSwgYXQgMTozMiBQTSwgTWlrZSBCb3J6YSA8bWJvcnphQGVsbGlw dGljdGVjaC5jb20+IHdyb3RlOg0KPiANCj4gVGhleSBkb24ndCBtZW50aW9uIElLRXYyLiAgSSBk b24ndCBrbm93IElLRXYyIHdlbGwgZW5vdWdoIHRvIGtub3cgd2hldGhlciB0aGVyZSBhcmUgYW55 IHN5bW1ldHJpYyBQU0sgYXV0aGVudGljYXRpb24gc2NoZW1lcywgYnV0IGlmIG5vdCwgcGVyaGFw cyB0aGVyZSBzaG91bGQgYmUuICBUaGUgcG9pbnQgdGhleSdyZSBtYWtpbmcgaXMgdGhhdCB0aGUg RUNDLWJhc2VkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZHMgYmVjb21lIGluc2VjdXJlIHdoZW4gcXVh bnR1bSBjb21wdXRlcnMgb2Ygc3VmZmljaWVudCBwb3dlciBiZWNvbWUgYXZhaWxhYmxlLCBhbmQg aW4gbGlnaHQgb2YgcmVjZW50IHByb2dyZXNzIGluIHRoZSBmaWVsZCB0aGUgaW5kaWNhdGlvbnMg YXJlIHRoYXQgdGhleSB3aWxsIGJlY29tZSBhdmFpbGFibGUgaW4gYSByZWFzb25hYmx5IHNob3J0 IHRpbWVmcmFtZS4gKEFuZCB0aGV5IHNob3VsZCBrbm93IHRoYXQgdGltZWZyYW1lIGJldHRlciB0 aGFuIGp1c3QgYWJvdXQgYW55Ym9keSBlbHNlLikgIEkgdmlldyB0aGlzIGFzIGFuIGluZGljYXRp b24gdGhhdCB0aGV5IGJlbGlldmUgdGhlcmUgbWF5IGJlIHZpYWJsZSBRQ3Mgb2YgdGhhdCBjYXBh YmlsaXR5IGluIHRoZSBmaXZlIHRvIHRlbiB5ZWFycyB0aW1lZnJhbWUuDQoNCkNvdWxkIHlvdSBw b2ludCB0byByZWZlcmVuY2VzIHRoYXQgZGlzY3VzcyByZWFsIHF1YW50dW0gY29tcHV0ZXJzPyAg SSBzcGVudCBhIHdoaWxlIHJlYWRpbmcgb24gdGhpcyBzdWJqZWN0IHdpdGhpbiB0aGUgcGFzdCB5 ZWFyLCBhbmQgYXMgZmFyIGFzIEkgY291bGQgdGVsbCwgcXVhbnR1bSBjb21wdXRlcnMgYXJlIGEg dmVyeSBpbnRlcmVzdGluZyB0aGVvcnkgYnV0IG5vbmUgeWV0IGV4aXN0IGluIHByYWN0aWNlLg0K DQpJIGxvb2tlZCBmb3IgYSBkZXNjcmlwdGlvbiBvZiB0aGlzZSDigJxTdWl0ZSBCIGFsZ29yaXRo bXPigJ0gYnV0IGl0IHdhc27igJl0IG9idmlvdXMuDQoNCkRvZXNu4oCZdCBQU0sgaW52b2x2ZSBE aWZmaWUtSGVsbG1hbiBrZXkgYWdyZWVtZW50PyAgSSB0aG91Z2h0IHRoYXQgU2hvcuKAmXMgYWxn b3JpdGhtIChvciBhIGdlbmVyYWxpemF0aW9uIG9mIGl0KSBhZGRyZXNzZXMgdGhlIGRpc2NyZXRl IGxvZyBwcm9ibGVtLg0KDQoJcGF1bA0K From nobody Wed Aug 19 13:54:20 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E861A8826 for ; Wed, 19 Aug 2015 13:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlRuu2wwcoVH for ; Wed, 19 Aug 2015 13:54:16 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5F3B1A8A1A for ; Wed, 19 Aug 2015 13:54:16 -0700 (PDT) X-AuditID: c618062d-f79ef6d000007f54-2d-55d48f9a74ac Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 18.C0.32596.A9F84D55; Wed, 19 Aug 2015 16:15:54 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Wed, 19 Aug 2015 16:54:14 -0400 From: Ing-Wher Chen To: "ipsec@ietf.org" Thread-Topic: Re: [IPsec] Work on the IPsec-related YANG documents Thread-Index: AdDavOF6IDahib5jQ1OCB9TH2qQKjw== Date: Wed, 19 Aug 2015 20:54:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyuXRPiO6s/iuhBnfvq1vs3/KCzYHRY8mS n0wBjFFcNimpOZllqUX6dglcGfc6rrIWrGev2HFRvIHxH2sXIyeHhICJxM1Pe9ggbDGJC/fW A9lcHEICRxklTkzYwg7hLGeUOHn3PlgHm4CBxIaPW5hAbBEBVYlTy6aDxYUFbCU6T39ihYg7 SbzefooFwtaTOHj/AzuIzQJU33ljIZDNwcEr4Csxr08BJMwItPj7qTVgI5kFxCVuPZnPBHGQ gMSSPeeZIWxRiZePYY5WlNjXP50dol5HYsHuT2wQtrbEsoWvwep5BQQlTs58wjKBUXgWkrGz kLTMQtIyC0nLAkaWVYwcpcWpZbnpRgabGIFhfEyCTXcH456XlocYBTgYlXh4FxRdDhViTSwr rsw9xCjNwaIkzusYlRcqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVGiLo1P47GGj//Mx+qN 7ot2G506Kbb5ptC6U4y7PufGLX3nZFjz1N/qlP5fmctLNYotNp8RCRILrnrzwCWlT70mbY// i5sBATt2mFbN3dwj57Gt8LD41WD95cFTGK6bSqZ9cv3F7PKxzLMibKFg9DnH9W1vl3+//lc5 q4+jctLB06uOFzsr1SuxFGckGmoxFxUnAgCiaXH5RAIAAA== Archived-At: Subject: Re: [IPsec] Work on the IPsec-related YANG documents X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 20:54:18 -0000 Hi Paul, The authors are in the process of merging the three YANG documents you mentioned. Thanks, Helen -----Original Message----- > From: "Paul Hoffman" > To: ipsec@ietf.org > Date: Tue, 11 Aug 2015 17:02:49 -0700 > Subject: [IPsec] Work on the IPsec-related YANG documents > > Greetings. At the meeting in Prague, there was discussion of the=20 > IPsec-related YANG documents (draft-tran-ipecme-yang-ipsec,=20 > draft-wang-ipsecme-ipsec-yang, and draft-wang-ipsecme-ike-yang). Given=20 > the low level of understanding of YANG, it would be great if the authors= =20 > of the three documents could either combine the documents or, failing=20 > that, agree on some wording for the WG about what each doc does and why=20 > they should exist in parallel. After that, the WG will be in a better=20 > position to think about whether we want to adopt them as WG items. >=20 > --Paul Hoffman From nobody Wed Aug 19 19:04:37 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB65B1A8BC3 for ; Wed, 19 Aug 2015 19:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEwuZVrbiHGD for ; Wed, 19 Aug 2015 19:04:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491891A8A86 for ; Wed, 19 Aug 2015 19:04:33 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 145D220098; Wed, 19 Aug 2015 22:22:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3837563B10; Wed, 19 Aug 2015 22:04:32 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 211F863AEC; Wed, 19 Aug 2015 22:04:32 -0400 (EDT) From: Michael Richardson To: Mike Borza In-Reply-To: <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: IPsecME WG , Dan Harkins Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 02:04:35 -0000 --=-=-= Content-Type: text/plain Mike Borza wrote: > They don't mention IKEv2. I don't know IKEv2 well enough to know > whether there are any symmetric PSK authentication schemes, but if not, > perhaps there should be. The point they're making is that the There are PSK methods. But, all the methods also use traditional DH, and IKEv2 defines ECDH methods (AFAIK, haven't implemented yet). I wonder if QC factoring of ECC easier than finding SHA1/SHA2/etc. collisions, or if there is less effort being spent on the secure hashes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdU1r4CLcPvd0N1lAQI+IAf8CipXVDXrRzidW07DF543JW2SHwpMA8IY my8GDcSa5+9K96+GrKzIrK4KqrY1k9p3lYvHN6m9STeU51QWvoIwVIHha0L6629Y 0H776VTn2FnOgyShWTdhlFIp5+3UBEJabpq6ScZK5TA3Lkv9OQf/VQJ0BtnrMWQZ hEH9pk4sDf88vnjQs0yNAqtZ4zEb1TWjAC+KR5+aMPwzSJRsisKl1679uba/9hbf SzypaaFC0bDxa3c+KhMO2EP6nc891MIEtfGw0N4I3nfiAsaMkRey+1JscYU/CgzS ttakVOq9NFyuxBy/cK6cvO7MxULKTZrQZ5EmsXu7OMtoEHuil8GJ2g== =EcDv -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 20 00:23:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A2B1A0282 for ; Thu, 20 Aug 2015 00:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.009 X-Spam-Level: * X-Spam-Status: No, score=1.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WWoUsxCsbgCd for ; Thu, 20 Aug 2015 00:23:55 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A551A0273 for ; Thu, 20 Aug 2015 00:23:54 -0700 (PDT) Received: by lbbtg9 with SMTP id tg9so18200562lbb.1 for ; Thu, 20 Aug 2015 00:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=SLtvZaV9hahIyWD+WMUmhrD38WPyz4bdfXcZGCgOSaw=; b=Gc/lPctZXvBrWqryS5qgDwzuMbjenUWQulpQgYT0fEGlbLY59zCwJ9A+iag31g3qpc bT5Sm75c0T6Jvu8FjJ2T04e+XR0w7mxLuVUo9SYQKfqgwzr96J29FUUGzFIpwz9CBneM 0gxWwdq+xQMvOl/yS8mFbHz3RPiBvLoTG/Llpe28NfXVz+5cx+s9x0iUFu6IXERApZDK 7vrgdm1Lz2ENJTWionRIoyLAQo0moObQmVotVZ4iQI+Vqd1N2AaS0Pj1P9QAlXpDh8z8 pxtwyqZJvQlozvzUEU/4VgkQIhUwEQ030rHob+SxhI8HnXl9GrWEOg/hj9CzgUUViTfX HicQ== X-Received: by 10.112.73.33 with SMTP id i1mr1627179lbv.31.1440055433116; Thu, 20 Aug 2015 00:23:53 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o6sm931522lah.20.2015.08.20.00.23.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 20 Aug 2015 00:23:52 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Mike Borza" , "Michael Richardson" , "Dan Harkins" References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> Date: Thu, 20 Aug 2015 10:23:58 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 07:23:56 -0000 Hi, IKEv2 has symmetrick PSK authentication method. However, it is different from IKEv1. The difference is that in IKEv1 the session keys computation involves both preshared key and DH shared secret SKEYID = prf(pre-shared-key, Ni_b | Nr_b) SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0) SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1) SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) while in IKEv2 it involves only DH shared secret, so preshared key is used for authentication only and is not used for session keys calculations SKEYSEED = prf(Ni | Nr, g^ir) {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) This change was intentional, it was made by Hugo Krawczyk during work on IKEv2 due to complaints from the community that if IKEv1 PSK auth mode was used in IKEv2 then it would be impossible for responder to select proper preshared secret based on initiator's identity (like in IKEv1 Main Mode). As far as I remember, when making this change Hugo mentioned, that it would weaken security of the protocol. Does NSA mean this difference when claiming that IKEv1 PSK mode is the only QC-safe protocol? Should we add similar mode to IKEv2? Regards, Valery Smyslov. > They don't mention IKEv2. I don't know IKEv2 well enough to know whether there are > any symmetric PSK authentication schemes, but if not, perhaps there should be. > The point they're making is that the ECC-based authentication methods become insecure > when quantum computers of sufficient power become available, and in light of recent progress > in the field the indications are that they will become available in a reasonably short timeframe. > (And they should know that timeframe better than just about anybody else.) > I view this as an indication that they believe there may be viable QCs of that capability > in the five to ten years timeframe. > > Mike > > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Michael Richardson > Sent: Wednesday, August 19, 2015 13:17 > To: Dan Harkins > Cc: IPsecME WG > Subject: Re: [IPsec] PSK mode > > > Dan Harkins wrote: > > https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml > > > "CSfC deployments involving an IKE/IPsec layer may use RFC > > 2409-conformant implementations of the IKE standard (IKEv1) > > together with large, high-entropy, pre-shared keys and the > > AES-256 encryption algorithm. RFC 2409 is the only version > > of the IKE standard that leverages symmetric pre-shared keys > > in a manner that may achieve quantum resistant confidentiality." > > So, all of IKEv2 is out, according to them? > Or they just didn't consider it yet? > > -- > Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Aug 20 06:56:22 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0A51A033B for ; Thu, 20 Aug 2015 06:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-trTFQENlvD for ; Thu, 20 Aug 2015 06:56:16 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEAA1A0451 for ; Thu, 20 Aug 2015 06:56:16 -0700 (PDT) Received: from [10.32.60.117] (cpe-24-167-103-233.rgv.res.rr.com [24.167.103.233]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t7KDuDLm073781 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2015 06:56:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host cpe-24-167-103-233.rgv.res.rr.com [24.167.103.233] claimed to be [10.32.60.117] From: "Paul Hoffman" To: "Valery Smyslov" Date: Thu, 20 Aug 2015 08:56:15 -0500 Message-ID: <35BBCD27-5877-455C-96D8-CB68218A581C@vpnc.org> In-Reply-To: References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 13:56:17 -0000 We should ask the NSA authors or their proxies before we do anything. Heck, maybe some NSA folks might even want to contribute to such an extension to IKEv2. We are in absolutely no rush, given how long it will be before serious researchers think there are practical quantum computers. --Paul Hoffman From nobody Thu Aug 20 07:26:42 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701081ACEA4 for ; Thu, 20 Aug 2015 07:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.711 X-Spam-Level: X-Spam-Status: No, score=-12.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvg599mcRNaE for ; Thu, 20 Aug 2015 07:26:39 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93C591ACEA0 for ; Thu, 20 Aug 2015 07:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4371; q=dns/txt; s=iport; t=1440080800; x=1441290400; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=znExPTaYqgVtqT5Prei5WG6+KEmav5+e3PgTtjjdmEs=; b=P0SGD5Ihh5L8W3UOoVJzG0Lx1qnqdS929brr0Uf4dH0xIBw4bkReMJmj Wjbgu4jwRD9FIWefsYXZQNPueMogN32dwJiugLw7Q6MMwFGJp5kJ07e0n +elvi1yRkzSTKp5R9NPet6zhb9BaH/K8splBsj42fD+7J3jkfuqgarIj8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BgBQBF49VV/5hdJa1UCYMbVGkGv0cKgkODOAKBMzsRAQEBAQEBAYEKhCMBAQEDAQEBATc0CwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCAyIEggNz3MBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItThC4NHjEHBoMSgRQFkheDEgGnKSaDfXEBgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,714,1432598400"; d="scan'208";a="25615437" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 20 Aug 2015 14:26:39 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t7KEQc35002304 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Aug 2015 14:26:38 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 20 Aug 2015 09:26:37 -0500 Received: from xhc-aln-x09.cisco.com (173.36.12.83) by xch-aln-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 20 Aug 2015 09:26:37 -0500 Received: from xmb-rcd-x04.cisco.com ([169.254.8.103]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0248.002; Thu, 20 Aug 2015 09:26:37 -0500 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , Mike Borza , Michael Richardson , Dan Harkins Thread-Topic: [IPsec] PSK mode Thread-Index: AQHQ2hKXA1CPvDJvk0GUtTWDDU+/W54T5UiAgAAEV4CAAJSr3YAAcaLA Date: Thu, 20 Aug 2015 14:26:37 +0000 Message-ID: References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.66] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 14:26:41 -0000 > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov > Sent: Thursday, August 20, 2015 3:24 AM > To: Mike Borza; Michael Richardson; Dan Harkins > Cc: IPsecME WG > Subject: Re: [IPsec] PSK mode >=20 > Hi, >=20 > IKEv2 has symmetrick PSK authentication method. However, it is different > from IKEv1. > The difference is that in IKEv1 the session keys computation involves bot= h > preshared key and DH shared secret >=20 > SKEYID =3D prf(pre-shared-key, Ni_b | Nr_b) SKEYID_d =3D prf(SKEYID, g^xy= | > CKY-I | CKY-R | 0) SKEYID_a =3D prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY= -R | > 1) SKEYID_e =3D prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2) >=20 > while in IKEv2 it involves only DH shared secret, so preshared key is use= d for > authentication only and is not used for session keys calculations >=20 > SKEYSEED =3D prf(Ni | Nr, g^ir) > {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =3D prf+ (SKEYSEED= , Ni | > Nr | SPIi | SPIr) >=20 > This change was intentional, it was made by Hugo Krawczyk during work on > IKEv2 due to complaints from the community that if IKEv1 PSK auth mode > was used in IKEv2 then it would be impossible for responder to select pro= per > preshared secret based on initiator's identity (like in IKEv1 Main Mode).= As > far as I remember, when making this change Hugo mentioned, that it would > weaken security of the protocol. >=20 > Does NSA mean this difference when claiming that IKEv1 PSK mode is the > only QC-safe protocol? I believe so. > Should we add similar mode to IKEv2? I believe that there is an easier alternative; the problem is that IKEv2 is= relying on the security of the (EC)DH exchange, and that is breakable with= a Quantum Computer. A cleaner approach would be to replace the DH exchang= e with something that does the same functionality, but in a Quantum Resista= nt manner. NTRU (using an ephemeral key) can do precisely this (and perfor= ms quickly enough, and with small enough KE payloads not to cause fragmenta= tion); we could negotiate NTRU as "yet another 'DH group'". That way, we d= on't need to have this as a separate option to be negotiated.=20 >=20 > Regards, > Valery Smyslov. >=20 >=20 >=20 > > They don't mention IKEv2. I don't know IKEv2 well enough to know > > whether there are any symmetric PSK authentication schemes, but if not, > perhaps there should be. > > The point they're making is that the ECC-based authentication methods > > become insecure when quantum computers of sufficient power become > > available, and in light of recent progress in the field the indications= are that > they will become available in a reasonably short timeframe. > > (And they should know that timeframe better than just about anybody > > else.) I view this as an indication that they believe there may be > > viable QCs of that capability in the five to ten years timeframe. > > > > Mike > > > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Michael > > Richardson > > Sent: Wednesday, August 19, 2015 13:17 > > To: Dan Harkins > > Cc: IPsecME WG > > Subject: Re: [IPsec] PSK mode > > > > > > Dan Harkins wrote: > > > https://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml > > > > > "CSfC deployments involving an IKE/IPsec layer may use RFC > > > 2409-conformant implementations of the IKE standard (IKEv1) > > > together with large, high-entropy, pre-shared keys and the > > > AES-256 encryption algorithm. RFC 2409 is the only version > > > of the IKE standard that leverages symmetric pre-shared keys > > > in a manner that may achieve quantum resistant confidentiality." > > > > So, all of IKEv2 is out, according to them? > > Or they just didn't consider it yet? > > > > -- > > Michael Richardson , Sandelman Software > Works > > -=3D IPv6 IoT consulting =3D- > > > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Aug 20 08:19:56 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A89F1ACEB4 for ; Thu, 20 Aug 2015 08:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWIRwDvLSfns for ; Thu, 20 Aug 2015 08:19:51 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [IPv6:2001:620:130:a080::46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B22A1A8A4D for ; Thu, 20 Aug 2015 08:19:51 -0700 (PDT) Received: from [IPv6:2001:1620:f00:f1::2] (cl-242.zrh-02.ch.sixxs.net [IPv6:2001:1620:f00:f1::2]) by mail.strongswan.org (Postfix) with ESMTPSA id 9EBA640350; Thu, 20 Aug 2015 17:19:54 +0200 (CEST) Message-ID: <55D5F012.4030206@strongswan.org> Date: Thu, 20 Aug 2015 17:19:46 +0200 From: Andreas Steffen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: "Scott Fluhrer (sfluhrer)" , Valery Smyslov , Mike Borza , Michael Richardson , Dan Harkins References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 15:19:54 -0000 Hi Scott, an NTRU Encryption-based IKEv2 key exchange is actually what the strongSwan open source VPN software has been offering with the ntru plugin for more than a year: https://wiki.strongswan.org/projects/strongswan/wiki/NTRU For the four security strengths of 112, 128, 192 and 256 bits strongSwan is using the private-use DH groups 1030..1033 in conjunction with the strongSwan Vendor ID. If you combine the NTRU key exchange with lattice-based BLISS signatures in the AUTH payload https://wiki.strongswan.org/projects/strongswan/wiki/BLISS than you arrive at a 100% Quantum Resistant IKEv2 protocol without the use of any PSKs. So the future has already arrived ;-) Best regards Andreas On 08/20/2015 04:26 PM, Scott Fluhrer (sfluhrer) wrote: > > > I believe that there is an easier alternative; the problem is that > IKEv2 is relying on the security of the (EC)DH exchange, and that is > breakable with a Quantum Computer. A cleaner approach would be to > replace the DH exchange with something that does the same > functionality, but in a Quantum Resistant manner. NTRU (using an > ephemeral key) can do precisely this (and performs quickly enough, > and with small enough KE payloads not to cause fragmentation); we > could negotiate NTRU as "yet another 'DH group'". That way, we don't > need to have this as a separate option to be negotiated. ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== From nobody Thu Aug 20 08:33:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647401ACF24 for ; Thu, 20 Aug 2015 08:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Avuy7iGIGFn for ; Thu, 20 Aug 2015 08:33:27 -0700 (PDT) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA83F1ACEE9 for ; Thu, 20 Aug 2015 08:33:18 -0700 (PDT) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=M96QYReWEwpyPSPtE3K+yQA0tDS6Hylmww5sgFE4b6FW7w7u/Ai8X1at 5bt7qmnMIwQ+3GKvve68HTG3217Iu3t4yp1z2iatQclSdUeFro7WbZHyi lJCodwLO/FaEPggwTxXlL0HmIfUot1I4aTGd04WUqLTG+dDGObwdio+rr k=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1440084798; x=1471620798; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CPMORCqaJ9KzBFImv5PPTeDVwSsh9BceAOa0A3M3CaQ=; b=bedYj/21f2lDgxIeA5POG1ZZDSCx5m2wFTZPBL0mrLZ6Wne16SHmj/yd ScXnfCAqfB9IKs3v89n3CC8BLb/J17ai+1kKFtMv8eVrt4hlkyrbGJpsB 1Ab3bn8U7fUYkTA11FZ0duvrbjqgkbEsbeUu2sxiMnnjlLTUglHhHQV2s k=; X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="5.15,714,1432616400"; d="scan'208";a="695304654" From: To: Thread-Topic: [IPsec] PSK mode Thread-Index: AQHQ2hKtJyQ3yJtgp0y3WFyLL5jGGZ4T5UiAgAAEV4CAAJSe1YAAyeCAgAASnoA= Date: Thu, 20 Aug 2015 15:33:14 +0000 Message-ID: References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.178.128.194] Content-Type: text/plain; charset="us-ascii" Content-ID: <077F2CA5BB2F4849A8F8BA2872ACAF41@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: ipsec@ietf.org, mcr+ietf@sandelman.ca, svanru@gmail.com, mborza@elliptictech.com, dharkins@lounge.org Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 15:33:28 -0000 > On Aug 20, 2015, at 10:26 AM, Scott Fluhrer (sfluhrer) wrote: >=20 >> ... >> Does NSA mean this difference when claiming that IKEv1 PSK mode is the >> only QC-safe protocol? >=20 > I believe so. >=20 >> Should we add similar mode to IKEv2? >=20 > I believe that there is an easier alternative; the problem is that IKEv2 = is relying on the security of the (EC)DH exchange, and that is breakable wi= th a Quantum Computer. A cleaner approach would be to replace the DH excha= nge with something that does the same functionality, but in a Quantum Resis= tant manner. NTRU (using an ephemeral key) can do precisely this (and perf= orms quickly enough, and with small enough KE payloads not to cause fragmen= tation); we could negotiate NTRU as "yet another 'DH group'". That way, we= don't need to have this as a separate option to be negotiated.=20 Has the NTRU based exchange had enough validation by skilled cryptographers= to be considered worth using in production? Also, has it been shown not to be vulnerable to a generalization of Shor's = algorithm, the way D-H is? It would be rather silly to introduce a new mec= hanism, only to have someone come along and tell us that Shor's algorithm b= reaks it, too. paul From nobody Thu Aug 20 10:51:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0CC1A1BAA for ; Thu, 20 Aug 2015 10:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyeMLPFXNW_t for ; Thu, 20 Aug 2015 10:50:47 -0700 (PDT) Received: from mx4r.gridway.net (mx4.gridway.net [74.216.186.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949451A1A9E for ; Thu, 20 Aug 2015 10:50:46 -0700 (PDT) Received: from delivery.mygridway.net (delivery.mygridway.net [72.1.205.180]) by mx4r.gridway.net (8.14.4/8.14.4/Debian-4) with ESMTP id t7KHoiBD022269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 20 Aug 2015 13:50:45 -0400 Received: from MPBEEXCHANGE.gwhosting.local ([172.17.12.4]) by mpbeexchange.gwhosting.local ([172.17.12.4]) with mapi id 14.03.0224.002; Thu, 20 Aug 2015 13:50:39 -0400 From: Mike Borza To: Michael Richardson Thread-Topic: [IPsec] PSK mode Thread-Index: AQHQ2hLatfV2Ohm57kWvDTcucxr8454T1ISA//++eECAANUIAIAAv53w Date: Thu, 20 Aug 2015 17:50:38 +0000 Message-ID: <29C194186F21E3449DEE427644BBCA087BEC9E26@mpbeexchange.gwhosting.local> References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> <19945.1440036272@sandelman.ca> In-Reply-To: <19945.1440036272@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.114.47.98] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=72.1.205.180; country=CA; region=Ontario; city=Ottawa; latitude=45.3467; longitude=-75.7700; http://maps.google.com/maps?q=45.3467,-75.7700&z=6 X-CanItPRO-Stream: base:outbound (inherits from base:default) X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 207.107.149.160 Archived-At: Cc: IPsecME WG , Dan Harkins Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 17:50:51 -0000 If I understand your point correctly, QC doesn't improve the rate at which = hash collisions may be found, at least not by any currently known (to me) a= lgorithm. In the case of the asymmetric algorithms, Shor's algorithm and c= lose variants make an attack on the keyspace more practical. (When suffici= ently capable QCs are practical). There are published results that support = those statements. For similar reasons, symmetric cryptography loses streng= th to N/2 bits for N bits keys. So e.g. AES-256 will have 128 bits of secu= rity in a post-QC world. Mike -----Original Message----- From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of Michael Richa= rdson Sent: Wednesday, August 19, 2015 22:05 To: Mike Borza Cc: Dan Harkins ; IPsecME WG Subject: Re: [IPsec] PSK mode Mike Borza wrote: > They don't mention IKEv2. I don't know IKEv2 well enough to know > whether there are any symmetric PSK authentication schemes, but if no= t, > perhaps there should be. The point they're making is that the There are PSK methods. But, all the methods also use traditional DH, and IKEv2 defines ECDH method= s (AFAIK, haven't implemented yet). I wonder if QC factoring of ECC easier than finding SHA1/SHA2/etc. collisio= ns, or if there is less effort being spent on the secure hashes. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Thu Aug 20 15:35:31 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93C81B2C6C; Thu, 20 Aug 2015 15:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM8-tv5JKuaf; Thu, 20 Aug 2015 15:35:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id E92701B2CAD; Thu, 20 Aug 2015 15:35:17 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C9695180474; Thu, 20 Aug 2015 15:34:49 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150820223449.C9695180474@rfc-editor.org> Date: Thu, 20 Aug 2015 15:34:49 -0700 (PDT) Archived-At: Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 7634 on ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 22:35:28 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7634 Title: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec Author: Y. Nir Status: Standards Track Stream: IETF Date: August 2015 Mailbox: ynir.ietf@gmail.com Pages: 13 Characters: 27513 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-chacha20-poly1305-12.txt URL: https://www.rfc-editor.org/info/rfc7634 DOI: http://dx.doi.org/10.17487/RFC7634 This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Aug 20 16:04:27 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EF71A01C6 for ; Thu, 20 Aug 2015 16:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsqsj61cbOvz for ; Thu, 20 Aug 2015 16:04:24 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E9F1A01A5 for ; Thu, 20 Aug 2015 16:04:24 -0700 (PDT) Received: by wicja10 with SMTP id ja10so2255029wic.1 for ; Thu, 20 Aug 2015 16:04:23 -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=fXNvnD8GDxHuI6YF1w4d/skipqjRtsOyWoR/bmuVq98=; b=PBuVcbr/OyXuxpYSFqrNq4qThtbfM5kTsOB5a4KS9NWj6zwaEwFaoR0nuhMFIcxCjT ceAOMyoP2R0A9aBkE6r9+D/hqNNGJlns0vSE+XKtvo0ZbprP2vy8FFMaOto9AgMtGyWS OCpaBNlIsrYecaIM4ynKxk7TYKdYZncUMmRLPv5LKZpV/5wEFTAcDrqKWpS2RQr3LxqF f5b6/+wgZqJzrzzw5AI1OCxVPyYvCEjNJ4Ar9VwVJXrG0IcGKnB49m3kMiJ7gQujr3VN pXANX0GCCb9dfhHAhfEmUC4n2l2u8g/fSKvRNV24BtTTXnDNhToTIdJjCbK5JbBPVSMJ P3iA== MIME-Version: 1.0 X-Received: by 10.180.82.230 with SMTP id l6mr973452wiy.61.1440111863011; Thu, 20 Aug 2015 16:04:23 -0700 (PDT) Received: by 10.28.157.84 with HTTP; Thu, 20 Aug 2015 16:04:22 -0700 (PDT) In-Reply-To: <20150820223449.C9695180474@rfc-editor.org> References: <20150820223449.C9695180474@rfc-editor.org> Date: Thu, 20 Aug 2015 19:04:22 -0400 Message-ID: From: Kathleen Moriarty To: Yoav Nir , "ipsec@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [IPsec] Fwd: RFC 7634 on ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 23:04:26 -0000 Nice job, Yoav and to those that helped with reviews, comments, shepherding, etc.! Kathleen ---------- Forwarded message ---------- From: Date: Thu, Aug 20, 2015 at 6:34 PM Subject: [IPsec] RFC 7634 on ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7634 Title: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec Author: Y. Nir Status: Standards Track Stream: IETF Date: August 2015 Mailbox: ynir.ietf@gmail.com Pages: 13 Characters: 27513 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-chacha20-poly1305-12.txt URL: https://www.rfc-editor.org/info/rfc7634 DOI: http://dx.doi.org/10.17487/RFC7634 This document describes the use of the ChaCha20 stream cipher along with the Poly1305 authenticator, combined into an AEAD algorithm for the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec -- Best regards, Kathleen From nobody Thu Aug 20 20:49:05 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B101A1BEE; Thu, 20 Aug 2015 20:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsfD22oVV7Sy; Thu, 20 Aug 2015 20:49:02 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C242F1A1BEC; Thu, 20 Aug 2015 20:49:01 -0700 (PDT) Received: by laba3 with SMTP id a3so34146600lab.1; Thu, 20 Aug 2015 20:49:00 -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 :cc:content-type; bh=prhNr0Ku3KaM76Mjxq3ps29JuxWo7+icsENZayJR+X8=; b=rG8/xslc6Rk8sYOYRnF0yoRJ65D/XHjiS+166CE7adfFtv8zpQ8scASFcrnvkCUgbm /NO7itt+KALr6e8IUAnUefKxjNgzvsLQmO3U4Vt7gKBcwPejx/gyIygEsSIplMUg0JMT /mrAHrhRpKmJ0i2kRI1dlvf9LklPUqODQ2Osh7+G+aZ/zyLmqywEG51weqLwviCGWKVh oaXiJdFWvoEv2Tlk2zQCfv1CB3sv+xygQogojMV4MBmG1rZWjkgQd4drCVxhE22IUnG6 WFR6VC8oW1nGnzCRJcT8022GdSEnu0WM9EXkkQVVpv7VjZ3uMpIE/bxKPgbl84Vx/zcK zONg== MIME-Version: 1.0 X-Received: by 10.112.163.72 with SMTP id yg8mr5925751lbb.82.1440128940123; Thu, 20 Aug 2015 20:49:00 -0700 (PDT) Received: by 10.25.23.212 with HTTP; Thu, 20 Aug 2015 20:49:00 -0700 (PDT) In-Reply-To: <20150820223449.C9695180474@rfc-editor.org> References: <20150820223449.C9695180474@rfc-editor.org> Date: Fri, 21 Aug 2015 09:19:00 +0530 Message-ID: From: KARAN VERMA To: rfc-editor@rfc-editor.org Content-Type: multipart/alternative; boundary=089e0118366ce82c03051dca255b Archived-At: Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-dist@rfc-editor.org, ietf-announce@ietf.org Subject: Re: [IPsec] RFC 7634 on ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 03:49:04 -0000 --089e0118366ce82c03051dca255b Content-Type: text/plain; charset=UTF-8 Nice RFC, I will help to reviews this rfc Karan On Fri, Aug 21, 2015 at 4:04 AM, wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 7634 > > Title: ChaCha20, Poly1305, and Their Use > in the Internet Key Exchange Protocol > (IKE) and IPsec > Author: Y. Nir > Status: Standards Track > Stream: IETF > Date: August 2015 > Mailbox: ynir.ietf@gmail.com > Pages: 13 > Characters: 27513 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipsecme-chacha20-poly1305-12.txt > > URL: https://www.rfc-editor.org/info/rfc7634 > > DOI: http://dx.doi.org/10.17487/RFC7634 > > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec. > > This document is a product of the IP Security Maintenance and Extensions > Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/rfc.html > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- *Kind Regards, * *Karan Verma * *Research Scholar * *UTP, Malaysia* *Phone: +60-166245082 <%2B60-166245082>* --089e0118366ce82c03051dca255b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nice RFC, I will help to reviews this rfc=C2=A0



Karan

On Fri, Aug 21, 2015 at 4:04 AM, <rfc-editor@rfc-editor.org> wrote:
A new Request for Comments is now available in online RFC li= braries.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7634

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 ChaCha20, Poly1305, = and Their Use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in th= e Internet Key Exchange Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (IKE)= and IPsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0Y. Nir
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0August 2015
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 ynir.ietf@gmail.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 13
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 27513
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates/Obsoletes/SeeAlso:=C2=A0 =C2=A0None

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-ipsecme-chacha= 20-poly1305-12.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc7634

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /dx.doi.org/10.17487/RFC7634

This document describes the use of the ChaCha20 stream cipher along
with the Poly1305 authenticator, combined into an AEAD algorithm for
the Internet Key Exchange Protocol version 2 (IKEv2) and for IPsec.

This document is a product of the IP Security Maintenance and Extensions Wo= rking Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestion= s
for improvements.=C2=A0 Please refer to the current edition of the Official=
Internet Protocol Standards (https://www.rfc-editor.org/standard= s) for the
standardization state and status of this protocol.=C2=A0 Distribution of th= is
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=C2=A0 https://www.ietf.org/mailman/listinfo/iet= f-announce
=C2=A0 https://mailman.rfc-editor.org/mailma= n/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search=
For downloading RFCs, see https://www.rfc-editor.org/rfc.html=

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



--
Kind R= egards,=C2=A0

Karan Verma=C2=A0
Research Scholar=C2=A0
UTP, Mal= aysia
= Phone:=C2=A0+60-166245082
--089e0118366ce82c03051dca255b-- From nobody Sun Aug 23 17:13:53 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9151B2E36 for ; Sun, 23 Aug 2015 17:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xW1xH3z3EZcf for ; Sun, 23 Aug 2015 17:13:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643941B2E35 for ; Sun, 23 Aug 2015 17:13:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B0E062009E; Sun, 23 Aug 2015 20:32:25 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9AE3F63B10; Sun, 23 Aug 2015 20:13:49 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8680D63AEC; Sun, 23 Aug 2015 20:13:49 -0400 (EDT) From: Michael Richardson To: Andreas Steffen In-Reply-To: <55D5F012.4030206@strongswan.org> References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> <55D5F012.4030206@strongswan.org> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Cc: IPsecME WG , Valery Smyslov , Mike Borza , Dan Harkins , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 00:13:51 -0000 --=-=-= Content-Type: text/plain Andreas Steffen wrote: > an NTRU Encryption-based IKEv2 key exchange is actually what the > strongSwan open source VPN software has been offering with the > ntru plugin for more than a year: > https://wiki.strongswan.org/projects/strongswan/wiki/NTRU > For the four security strengths of 112, 128, 192 and 256 bits > strongSwan is using the private-use DH groups 1030..1033 in > conjunction with the strongSwan Vendor ID. Cool... an ID explanining things would be a really good thing to have. > If you combine the NTRU key exchange with lattice-based BLISS > signatures in the AUTH payload > https://wiki.strongswan.org/projects/strongswan/wiki/BLISS > than you arrive at a 100% Quantum Resistant IKEv2 protocol > without the use of any PSKs. I don't know if the WG wants to add this to it's charter, but it sure would be nice to have a spec... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdphvYCLcPvd0N1lAQIGgAf/dwzw4g/Whk8TOsUTFlI+MNDs4K+v5NT4 Nl5wKuIaGo+QJ3ROj5J3jb/PkauDbhxhoi52GblW5XnwFRXkkamQqfMfAptKw6Io Qw6U4UnbFcTLoBrIhfmu4FJNoxSLAtPudys5o1HwWGS84cLBEpz0AymHlSbTx2aH c57/cTODPlu0Z5mCxGaDM7vAzUBygqvVMUiZDEm+x8w0njyPzYVQ4rXWXyfmeikM IGvgwRDBvH/fgClHUoxEWchx3IRt/Hym24+oDe0jjmZSH02/ysowDouECcQxap0F 3Tf7M6299dx8KGvwBo//pdMEK3uTmidaFSRLHpXsHq5I/UqMsXZtkQ== =DS43 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 24 05:25:07 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742F1B32E0 for ; Mon, 24 Aug 2015 05:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8it681JSvDW for ; Mon, 24 Aug 2015 05:25:04 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BFF1B32FA for ; Mon, 24 Aug 2015 05:25:03 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-74-55daa36197ea Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1A.04.26730.163AAD55; Mon, 24 Aug 2015 06:53:54 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Mon, 24 Aug 2015 08:25:02 -0400 From: Daniel Migault To: "ipsec@ietf.org" Thread-Topic: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-05.txt Thread-Index: AQHQ3mZD0CHzfUrca0uOyuEVjOUVR54bENeg Date: Mon, 24 Aug 2015 12:25:01 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C11214EB2E@eusaamb107.ericsson.se> References: <20150824121310.20833.50393.idtracker@ietfa.amsl.com> In-Reply-To: <20150824121310.20833.50393.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyuXSPt27S4luhBs1N/Bb7t7xgs7jxYSab A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXx+mILS8EauYq56xazNjCekO1i5OSQEDCR eLntByuELSZx4d56ti5GLg4hgaOMEj+7VrFDOMsZJY6vmsYCUsUmYCTRdqifHcQWEVCVOLVs Olg3M5D9ZdcZZhBbWCBIYsOPO4wQNcESf/duY4WwjSQ+3P7MBmKzANWvfXsCqJ6Dg1fAV6L/ RwpIWEjAUeLuvs9gqzgFnCQe3L4MNoYR6Ljvp9YwQawSl7j1ZD4TxNECEkv2nGeGsEUlXj7+ B/WMksTH3/PZQcYzC2hKrN+lD9GqKDGl+yHY9bwCghInZz5hmcAoNgvJ1FkIHbOQdMxC0rGA kWUVI0dpcWpZbrqR4SZGYIQck2Bz3MG44JPlIUYBDkYlHt4HF2+GCrEmlhVX5h5ilOZgURLn lfbLCxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaJby4olIudGPJ6HfJ52702FcZJOTX1K/ pz9SzFz0ys+7hx2PqCbGdPz4XPAx84Jfz7eVTHGG8Rv23f8syX/ysVCxsceDit/Cmks7D3pp 1a2z+v4nIjD1nFLa1jMy90VKzzjFn99l+UGxTd7a4ae18ZVihfLi3aLTshYJXF9Ryl6xhyut 3nKNEktxRqKhFnNRcSIASVW2UHECAAA= Archived-At: Cc: Valery Smyslov Subject: [IPsec] FW: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 12:25:06 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC1tZ2x0LWlwc2Vj bWUtY2xvbmUtaWtlLXNhLTA1LiBJbiB0aGlzIHZlcnNpb24sIHdlIGFkZGVkIHRleHQgIHRvIHJl ZmxlY3QgdGhlIGRpc2N1c3Npb24gb2YgdGhlIGxvYWQgYmFsYW5jaW5nIElQc2VjIFZQTnMgWzFd Lg0KDQpGZWVsIGZyZWUgdG8gY29tbWVudCB0aGUgY3VycmVudCBkb2N1bWVudC4NCkJSLA0KDQpE YW5pZWwgIA0KDQpbMV0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9pcHNl Yy95MG9rbHJKX0hZbWJYMDdsRHJiRjBmcWRFc3MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEF1Z3VzdCAyNCwgMjAxNSA4OjEzIEFNDQpUbzog VmFsZXJ5IFNteXNsb3Y7IFZhbGVyeSBTbXlzbG92OyBEYW5pZWwgTWlnYXVsdDsgRGFuaWVsIE1p Z2F1bHQNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWdsdC1p cHNlY21lLWNsb25lLWlrZS1zYS0wNS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbWdsdC1pcHNlY21lLWNsb25lLWlrZS1zYS0wNS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgRGFuaWVsIE1pZ2F1bHQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWdsdC1pcHNlY21lLWNsb25lLWlrZS1zYQ0KUmV2aXNp b246CTA1DQpUaXRsZToJCUNsb25pbmcgSUtFIFNBIGluIHRoZSBJbnRlcm5ldCBLZXkgRXhjaGFu Z2UgUHJvdG9jb2wgVmVyc2lvbiAyIChJS0V2MikNCkRvY3VtZW50IGRhdGU6CTIwMTUtMDgtMjQN Ckdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTE0DQpVUkw6ICAgICAgICAg ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1nbHQtaXBzZWNt ZS1jbG9uZS1pa2Utc2EtMDUudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbWdsdC1pcHNlY21lLWNsb25lLWlrZS1zYS8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWdsdC1pcHNlY21lLWNs b25lLWlrZS1zYS0wNQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1tZ2x0LWlwc2VjbWUtY2xvbmUtaWtlLXNhLTA1DQoNCkFic3RyYWN0Og0K ICAgVGhpcyBkb2N1bWVudCBjb25zaWRlcnMgYSBWUE4gRW5kIFVzZXIgZXN0YWJsaXNoaW5nIGFu IElQc2VjIFNBIHdpdGgNCiAgIGEgU2VjdXJpdHkgR2F0ZXdheSB1c2luZyB0aGUgSW50ZXJuZXQg S2V5IEV4Y2hhbmdlIFByb3RvY29sIFZlcnNpb24gMg0KICAgKElLRXYyKSwgd2hlcmUgYXQgbGVh c3Qgb25lIG9mIHRoZSBwZWVycyBoYXMgbXVsdGlwbGUgaW50ZXJmYWNlcyBvcg0KICAgd2hlcmUg U2VjdXJpdHkgR2F0ZXdheSBpcyBhIGNsdXN0ZXIgd2l0aCBlYWNoIG5vZGUgaGF2aW5nIGl0cyBv d24gSVANCiAgIGFkZHJlc3MuDQoNCiAgIFdpdGggdGhlIGN1cnJlbnQgSUtFdjIgcHJvdG9jb2ws IHRoZSBvdXRlciBJUCBhZGRyZXNzZXMgb2YgdGhlIElQc2VjDQogICBTQSBhcmUgZGV0ZXJtaW5l ZCBieSB0aG9zZSB1c2VkIGJ5IElLRSBTQS4gIEFzIGEgcmVzdWx0IHVzaW5nDQogICBtdWx0aXBs ZSBpbnRlcmZhY2VzIHJlcXVpcmVzIHRvIHNldCB1cCBhbiBJS0UgU0Egb24gZWFjaCBpbnRlcmZh Y2UsDQogICBvciBvbiBlYWNoIHBhdGggaWYgYm90aCB0aGUgVlBOIENsaWVudCBhbmQgdGhlIFNl Y3VyaXR5IEdhdGV3YXkgaGF2ZQ0KICAgbXVsdGlwbGUgaW50ZXJmYWNlcy4gIFNldHRpbmcgZWFj aCBJS0UgU0EgaW52b2x2ZXMgYXV0aGVudGljYXRpb25zDQogICB3aGljaCBtaWdodCByZXF1aXJl IG11bHRpcGxlIHJvdW5kIHRyaXBzIGFzIHdlbGwgYXMgYWN0aXZpdHkgZnJvbSB0aGUNCiAgIFZQ TiBFbmQgVXNlciBhbmQgdGh1cyB3b3VsZCBkZWxheSB0aGUgVlBOIGVzdGFibGlzaG1lbnQuICBJ biBhZGRpdGlvbg0KICAgbXVsdGlwbGUgYXV0aGVudGljYXRpb25zIHVubmVjZXNzYXJpbHkgaW5j cmVhc2UgdGhlIGxvYWQgb24gdGhlIFZQTg0KICAgY2xpZW50IGFuZCB0aGUgYXV0aGVudGljYXRp b24gaW5mcmFzdHJ1Y3R1cmUuDQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJlc2VudHMgdGhlIHNvbHV0 aW9uIHRoYXQgYWxsb3dzIHRvIGNsb25lIElLRXYyIFNBLA0KICAgd2hlcmUgYW4gYWRkaXRpb25h bCBTQSBpcyBkZXJpdmVkIGZyb20gYW4gZXhpc3Rpbmcgb25lLiAgVGhlIG5ld2x5DQogICBjcmVh dGVkIElLRSBTQSBpcyBzZXQgd2l0aG91dCB0aGUgSUtFdjIgYXV0aGVudGljYXRpb24gZXhjaGFu Z2UuDQogICBUaGlzIElLRSBTQSBjYW4gbGF0ZXIgYmUgYXNzaWduZWQgdG8gYW5vdGhlciBpbnRl cmZhY2Ugb3IgbW92ZWQgdG8NCiAgIGFub3RoZXIgY2x1c3RlciBtb2RlIHVzaW5nIE1PQklLRSBw cm90b2NvbC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Mon Aug 24 07:38:02 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0C31A034C for ; Mon, 24 Aug 2015 07:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.278 X-Spam-Level: **** X-Spam-Status: No, score=4.278 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, MANGLED_GIRL=2.3, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IISIK5tJqJUI for ; Mon, 24 Aug 2015 07:37:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 072851A01FC for ; Mon, 24 Aug 2015 07:37:57 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t7OEJkoo021876 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Aug 2015 17:19:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t7OEJiCO022477; Mon, 24 Aug 2015 17:19:44 +0300 (EEST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NxzIEWtU4I" Content-Transfer-Encoding: 7bit Message-ID: <21979.10240.760855.22791@fireball.acr.fi> Date: Mon, 24 Aug 2015 17:19:44 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 23 min Archived-At: Cc: IPsecME WG , Michael Richardson , Mike Borza , Dan Harkins Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 14:38:01 -0000 --NxzIEWtU4I Content-Type: text/plain; charset=us-ascii Content-Description: message body and .signature Content-Transfer-Encoding: 7bit Valery Smyslov writes: > SKEYSEED = prf(Ni | Nr, g^ir) > {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+ > (SKEYSEED, Ni | Nr | SPIi | SPIr) > > This change was intentional, it was made by Hugo Krawczyk during > work on IKEv2 due to complaints from the community that if IKEv1 PSK > auth mode was used in IKEv2 then it would be impossible for > responder to select proper preshared secret based on initiator's > identity (like in IKEv1 Main Mode). As far as I remember, when > making this change Hugo mentioned, that it would weaken security of > the protocol. Yes, the problem was that PSK was needed to decrypt the IKE packet to be able to see the ID, so ID was useless for selecting PSK. Because of this people used aggressive mode in IKEv1, so PSK could be selected based on the ID. Also if the PSK was wrong then the decryption simply failed and that made it hard to know what went wrong. For the responder he just needed to know which PSK to use based on the source IP address, and that worked fine with fixed vpn links, but not with mobile users. In IKEv2 we decided to use the PSK only for the authentication, and not tie it up to the key generation. Most of the PSKs used in real world are not cryptografilly strong enough to provide that much more security for the SKEYSEED calculation. When we were talking about the draft-nagayama-ipsecme-ipsec-with-qkd draft (now expired) we discussed that we should just add the QKDdata SKEYSEED calculation. (Hmm... it seems that my comments (attached) about the draft-nagayama-ipsecme-ipsec-with-qkd draft never made to the list). In that email I proposed changing the SKEYSEED calculation so ti would include QKDdata: SKEYSEED = prf(Ni | Nr, g^ir | QKDdata) On the other hand this would still bring exactly same problems we had with IKEv1 related to what happens if QKDdata do not match. We would not have the ID issue, as the QKDdata is selected based on the different payload, i.e. QKD KeyID would select what QKDdata is used, and that is sent in the IKE_SA_INIT which is not encrypted. I also proposed to change the QKD draft to be more generic, i.e. generic out of band one time shared key usage protocol, i.e. not specifically tied to the QKD. I.e. we discussed about distributing strong shared data using DVDs or similars, and just sending offsets for the shared data to be used. Other option is to only augment the KEYMAT, i.e. the actual IPsec traffic key materials used. I.e. change KEYMAT = prf+(SK_d, Ni | Nr) to KEYMAT = prf+(SK_d, Ni | Nr | QKDdata) I.e in that case attacker who can break DH would be able to see the IKEv2 SA traffic, i.e. the IDs, key exchanges etc, but still would not be able to decrypt the actual ESP traffic without getting the QKDdata too. The only secret thing in the IKE SA traffic is the IDs, but if we use the QKDdata to generate encryption keys, then that QKD KeyID is a form of ID, that most likely can already be used to derive the actual user id (depends how that QKD KeyID is generated). The IKE SA traffic needs to be protected for real time changes, but there is not that big value for protecting them for long term decryption. On the other hand ESP traffic is the one that really benefits from long term decryption protection. > Does NSA mean this difference when claiming that IKEv1 PSK mode is the only > QC-safe protocol? Should we add similar mode to IKEv2? I think we should continue pushing the draft-nagayama-ipsecme-ipsec-with-qkd forward, and specify it as generic method where out of band shared keys can be brought in to the SKEYSEED or KEYMAT. -- kivinen@iki.fi --NxzIEWtU4I Content-Type: application/octet-stream; name="ipsec-ietf-org-kivinen-21624.29487.515060.335151@fireball.kivinen.iki.fi" Content-Disposition: attachment; filename="ipsec-ietf-org-kivinen-21624.29487.515060.335151@fireball.kivinen.iki.fi" Content-Transfer-Encoding: base64 RnJvbSBraXZpbmVuIEZyaSBOb3YgMjggMTU6MDU6NTEgKzAyMDAgMjAxNApNSU1FLVZlcnNpb246 IDEuMApDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWkKQ29udGVudC1U cmFuc2Zlci1FbmNvZGluZzogN2JpdApNZXNzYWdlLUlEOiA8MjE2MjQuMjk0ODcuNTE1MDYwLjMz NTE1MUBmaXJlYmFsbC5raXZpbmVuLmlraS5maT4KRGF0ZTogRnJpLCAyOCBOb3YgMjAxNCAxNTow NTo1MSArMDIwMApGcm9tOiBUZXJvIEtpdmluZW4gPGtpdmluZW5AaWtpLmZpPgpUbzogaXBzZWNA aWV0Zi5vcmcKQ0M6IGRyYWZ0LW5hZ2F5YW1hLWlwc2VjbWUtaXBzZWMtd2l0aC1xa2RAdG9vbHMu aWV0Zi5vcmcKU3ViamVjdDogTXkgY29tbWVudHMgdG8gZHJhZnQtbmFnYXlhbWEtaXBzZWNtZS1p cHNlYy13aXRoLXFrZC0wMS50eHQKWC1NYWlsZXI6IFZNIDguMi4wYiB1bmRlciAyNC4zLjEgKHg4 Nl82NC0tbmV0YnNkKQpYLUVkaXQtVGltZTogMTM4IG1pbgpYLVRvdGFsLVRpbWU6IDExMCBtaW4K CkZpcnN0IHNvbWUgbW9yZSBnZW5lcmljIGNvbW1lbnRzLgoKRmlyc3Qgb2YgYWxsLCBpZiBJIHVu ZGVyc3Rvb2QgY29ycmVjdGx5IHRoZSBtYWluIGlkZWEgaXMgdG8gbWFrZSBzdXJlCnRoYXQgZXZl biBpZiB0aGUgRGlmZmllLUhlbGxtYW4gaXMgbGF0ZXIgYnJva2VuIGJ5IGF0dGFja2VyLCB0aGUK YXR0YWNrZXIgY2Fubm90IGRlY3J5cHQgb2xkIHN0cmVhbXMsIGFzIHRoZSBRS0QgcHJvdmlkZXMg ZGF0YSB3aGljaCBpcwpub3QgYXZhaWxhYmxlIGZvciB0aGUgYXR0YWNrZXIuIEFzIHN1Y2ggSSBk byBub3Qgc2VlIGFueSByZWFzb24gdG8KbW9yZXZlIG9yIHJlcGxhY2UgRGlmZmllLUhlbGxtYW4s IGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0bwphdWdtZW50IGl0IHdpdGggbWF0ZXJp YWwgZnJvbSBRS0QuIFRoaXMgd291bGQgYWxzbyBwcm92aWRlIGxpbWl0ZWQKcHJvdGVjdGlvbiBh Z2FpbnMgdGhlIGlzc3VlcyB3aXRoIFFLRCwgaS5lLiBpZiBhdHRhY2tlciBzb21laG93IGxhdGVy CmdldHMgYWNjZXNzIHRvIHRoZSBRS0QgbWF0ZXJpYWwsIHRoZXkgd291bGQgc3RpbGwgbmVlZCB0 byBjcmFjayB0aGUKRGlmZmllLUhlbGxtYW4gdG8gYmUgYWJsZSB0byByZWFkIHRoZSB0cmFmZmlj LgoKQWxzbyBjaGFuZ2luZyB0aGUgYWN0dWFsIHByb3RvY29sIHNvIHRoYXQgaXQgd291bGQgcmV1 c2UgbW9zdCBvZiB0aGUKY3J5cHRvZ3JhcGhpYyBwcm90ZWN0aW9uIHByb3ZpZGVkIGJ5IHRoZSBJ S0V2Miwgd291bGQgYWxsb3cgcmV1c2luZwp0aGUgZXhpc3Rpbmcgc2VjdXJpdHkgYW5hbHlzaXMg ZG9uZSBmb3IgdGhlIElLRXYyLgoKQmVjYXVzZSBvZiB0aGF0IEkgd291bGQgcHJvcG9zZSB0aGUg UUtEZGF0YSB3b3VsZCBub3QgcmVwbGFjZSB0aGUKU0tFWVNFRUQgKHRoaXMgaXMgd2hhdCBJIHVu ZGVyc3Rvb2QgdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGRvZXMsCmV2ZW4gaWYgdGhpcyBp cyBub3QgYWN0dWFsbHkgbWVudGlvbmVkIGluIHRoZSBkcmFmdCksIGJ1dCBpbnN0ZWFkCm1vZGlm eSB0aGUgU0tFWVNFRUQgZ2VuZXJhdGlvbiBhIGJpdC4KCkN1cnJlbnQgU0tFWVNFRUQgZ2VuZXJh dGlvbiBpczoKCiAgIFNLRVlTRUVEID0gcHJmKE5pIHwgTnIsIGdeaXIpCgpvciBmb3IgcmVrZXk6 CgogICBTS0VZU0VFRCA9IHByZihTS19kIChvbGQpLCBnXmlyIChuZXcpIHwgTmkgfCBOcikKCklm IHdlIG1vZGlmeSB0aG9zZSBzbyB0aGF0IGluc3RlYWQgb2YgZ15pciwgd2Ugd291bGQgdXNlIGde aXIKY29uY2F0ZW5hdGVkIHdpdGggUUtEZGF0YSwgaS5lLjoKCiAgIFNLRVlTRUVEID0gcHJmKE5p IHwgTnIsIGdeaXIgfCBRS0RkYXRhKQoKb3IgZm9yIHJla2V5OgoKICAgU0tFWVNFRUQgPSBwcmYo U0tfZCAob2xkKSwgZ15pciAobmV3KSB8IE5pIHwgTnIgfCBRS0RkYXRhKQoKd2hlcmUgdGhlIFFL RGRhdGEgaXMgdGhlIHF1YW50dW0ga2V5IGRhdGEgbG9jYXRlZCB1c2luZyB0aGUgUUtEIEtleUlE CnBheWxvYWQsIGkuZS4gaXQgd291bGQgYmUgc2FtZSBpbiBib3RoIGVuZC4gVGhpcyB3b3VsZCBt ZWFuIHRoYXQgdGhlCmV4aXN0aW5nIHNlY3VyaXR5IGFuYWx5c2lzIGZvciB0aGUgSUtFdjIgd291 bGQgc3RpbGwgYmUgdGhlcmUsIGFuZApyZWdhcmRsZXNzIHdoZXRoZXIgdGhlIFFLRGRhdGEgaXMg Z29vZCBvciBub3QsIHRoaXMgZXh0ZW5zaW9uIHdpbGwgbm90CndlYWtlbiB0aGUgcHJvdGVjdGlv biBwcm92aWRlZCBieSB0aGUgSUtFdjIuIAoKLS0KClRoZSBhbm90aGVyIGNvbW1lbnQgSSBoYXZl IHRoYXQgdGhlIGZhbGxiYWNrIG1vZGUgc2hvdWxkIGJlIHJlbW92ZWQKY29tcGxldGVseS4gQXMg dGhlIHJhbmRvbW5lc3MgZ2VuZXJhdGVkIGJ5IHRoZSBRS0QgaXMgc2hhcmVkIGJ5IGJvdGgKZW5k cywgdGhlbiBib3RoIGVuZHMgd2lsbCBrbm93IHdoZXRoZXIgdGhlIG1hdGVyaWFsIGlzIHRoZXJl IG9yIG5vdCwKc28gdGhlcmUgaXMgbm8gcG9pbnQgb2YgbmVnb3RpYXRlIHdoYXQgdG8gZG8gYXQg dGhhdCBwb2ludC4gVGhpcyB3b3VsZApiZSBqdXN0IGxvY2FsIHBvbGljeSBtYXR0ZXIuIEkuZS4g dGhlIGxvY2FsIHBvbGljeSBjb3VsZCBiZSB0aGF0IGlmClFLRCBtYXRlcmlhbCBpcyBub3QgYXZh aWxhYmxlIHdoZW4gaXQgaXMgbmVlZGVkIHdlIHNpbXBseSBmYWlsLCBhbmQKd2lsbCBub3QgYWxs b3cgdHJhZmZpYyB0byBnbyBhdCBhbGwgKGkuZS4gZmFsbGJhY2sgbWV0aG9kIFdBSVRfUUtEKSwK b3IgaXQgY291bGQgYmUgdGhhdCB3ZSBqdXN0IGZhbGwgYmFjayB0byBEaWZmaWUtSGVsbG1hbiBl dGMuIEkuZS4gYWxsCm9mIHRoaXMgaXMganVzdCBsb2NhbCBtYXR0ZXIgb2YgdGhlIHBlZXIuIElu IElLRXYyIHdlIGhhdmUgbW9zdGx5IGRvbmUKdGhpcyBpbiBvdGhlciBzaXR1YXRpb25zIHRvbywg Zm9yIGV4YW1wbGUgdGhlIGxpZmV0aW1lcyBhcmUgY29tcGxldGVseQpsb2NhbCBtYXR0ZXIgZm9y IHRoZSBwZWVycy4gVGhpcyB0aGluZyBzaG91bGQgYWxzbyBiZSBsY29hbCBtYXR0ZXIuIAoKLS0K ClRoZSBQQUstREggaXMgY29tcGxldGVseSB1bm5lZWRlZCBoZXJlLiBUaGUgUEFLLURIIGlzIG1l YW4gZm9yIGh1bWFuCm1lbW9yaXphYmxlIHBhc3N3b3JkLCBpLmUuIGZvciB3ZWFrIHBhc3N3b3Jk LiBUaGUgUUtEZGF0YSBnZW5lcmF0ZWQKZnJvbSB0aGVyZSBzaG91bGQgbm90IGJlIHNvIHdlYWsg dGhhdCBpdCBuZWVkcyB0aGlzLiBJIG1lYW4sIGlmIGl0IGlzCnNvIHdlYWsgeW91IG5lZWQgUEFL LURILCB0aGVuIHlvdSBzaG91bGQgbm90IGJlIHVzaW5nIGl0IGF0IGFsbC4gU28KcmVtb3ZlIGl0 IGNvbXBsZXRlbHkuCgotLQoKVGhlIG5lZ290aWF0aW9uIG9mIHRoaXMgc2hvdWxkIGJlIGRvbmUg c28gdGhhdCB0aGlzIGFuZCBub3JtYWwKRGlmZmllLUhlbGxtYW4gY2FuIGJlIGludGVybWl4ZWQs IGkuZS4gaWYgb3RoZXIgZW5kIGRvZXMgbm90IHN1cHBvcnQKUUtELCBvciBkb2VzIG5vdCB3YW50 IHRvIGRvIGl0IGZvciBzb21lIHJlYXNvbiwgdGhlbiB0aGV5IHNob3VsZCBiZQphYmxlIHRvIGZh bGwgYmFjayB0byBub3JtYWwgRGlmZmllLUhlbGxtYW4gaWYgaXQgaXMgYWxsb3dlZCBieSBwb2xp Y3kuCkFjdHVhbGx5IHRoaXMgbWlnaHQgbm90IGhhcHBlbiB0aGF0IG9mdGVuLCBhcyBib3RoIHBl ZXJzIHdpbGwga25vdwp3aGV0aGVyIHRoZXkgaGF2ZSBRS0QgbWF0ZXJpYWwgZm9yIHRoZSBvdGhl ciBlbmQsIGFzIGJvdGggcGVlcnMgd2lsbApoYXZlIHNhbWUgc2hhcmVkIFFLRGRhdGEgZW50cmll cywgc28gcGVlciB3b3VsZCBub3QgZXZlbiB0cnkgdG8KcHJvcG9zZSBRS0QgdW5sZXNzIGl0IGhh cyBzaGFyZWQgUUtEZGF0YSBlbnRyeSB3aXRoIHRoZSBvdGhlciBlbmQuIEJ1dAphbnl3YXlzIGl0 IG1pZ2h0IGJlIGJldHRlciB0byBtYWtlIHRoaXMgc28gdGhhdCB0aGV5IGJvdGggY2FuIGJlIHVz ZWQKYXMgc3BlY2lmaWVkIGluIHRoZSBwb2xpY3kuIAoKLS0KCk1vcmUgZXhhY3QgY29tbWVudHM6 Cgo+IEFic3RyYWN0Cj4gCj4gICAgUXVhbnR1bSBLZXkgRGlzdHJpYnV0aW9uIChRS0QpIGlzIGEg bWVjaGFuaXNtIGZvciBjcmVhdGluZyBzaGFyZWQsCj4gICAgc2VjcmV0LCByYW5kb20gYml0cy4g IFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVuc2lvbnMgdG8gdGhlIElLRXYyCj4gICAgcHJv dG9jb2wgdG8gdXNlIHJhbmRvbSBiaXRzIGNyZWF0ZWQgdmlhIFFLRCBhcyBrZXlzIGZvciBJUHNl Yy4gIFRoZQo+ICAgIERpZmZpZS1IZWxsbWFuIGtleSBhZ3JlZW1lbnQgbWVjaGFuaXNtIGlzIHJl cGxhY2VkIHdpdGggUUtELiAgVGhlIHVzZQoKSSB3b3VsZCByZXBsYWNlIHRoZSAvcmVwbGFjZWQg d2l0aC9hdWdtZW50ZWQgd2l0aC8KCj4gMy4gIERhdGEgRm9ybWF0cyBhbmQgSW5mb3JtYXRpb24g RXhjaGFuZ2UgU2VxdWVuY2VzCj4gCj4gICAgSUtFIG11c3QgZXhjaGFuZ2UgdHdvIHBhcmFtZXRl cnMgdG8gdXNlIFFLRDogYW4gaWRlbnRpZmllciBpbmRpY2F0aW5nCj4gICAgd2hpY2ggUUtELWdl bmVyYXRlZCBrZXkgaXMgdG8gYmUgdXNlZCAoS2V5SUQpIGFuZCB0aGUgY2hvaWNlIG9mCj4gICAg ZmFsbGJhY2sgbWV0aG9kcy4gIE9uZSBLZXkgSUQgcmVwcmVzZW50cyBvbmUgdW5pdCBvZiBzaGFy ZWQgcmFuZG9tCj4gICAgYml0cywgbGFyZ2UgZW5vdWdoIGZvciB1c2UgYXMgYnVsayBkYXRhIGVu Y3J5cHRpb24ga2V5LiAgRmFsbGJhY2sKPiAgICBtZXRob2RzIGFyZSB1c2VkIHdoZW4gdGhlIFFL RCBzeXN0ZW0ga2V5IGdlbmVyYXRpb24gdW5kZXJydW5zLgo+ICAgIEFkZGl0aW9uYWxseSwgdGhl IHN5c3RlbSBzaG91bGQgYmUgYWJsZSB0byBjaG9vc2UgdGhlIGtleSBleGNoYW5nZQo+ICAgIGFs Z29yaXRobSBmcm9tIGFuIGFwcHJvdmVkIGxpc3QgaW5jbHVkaW5nIGUuZy4gIFFLRCwgRGlmZmll LUhlbGxtYW4KPiAgICBrZXkgZXhjaGFuZ2UgYW5kIHBhc3N3b3JkLWF1dGhlbnRpY2F0ZWQga2V5 IFtSRkM1NjgzXS4KClNvIEkgdGhpbmsgb25seSB0aGluZyBuZWVkZWQgZm9yIFFLRCBpcyB0aGUg S2V5SUQsIGkuZS4gdGhlIGZhbGxiYWNrCnRleHQgc2h1bGQgYmUgcmVtb3ZlZCBmcm9tIGhlcmUu IFNhbWUgZm9yIHRoZSBwYXNzd29yZC1hdXRoZW50aWNhdGVkCmtleSBzdHVmZi4gCgo+IDMuMS4g IERhdGEgRm9ybWF0cwo+IAo+ICAgIFRoZXJlIGFyZSB0aHJlZSBhZGRlZCBkYXRhIGZvcm1hdHM6 IFFLRCBLZXlJRCBQYXlsb2FkLCBRS0QgRmFsbGJhY2sKPiAgICBQYXlsb2FkIGFuZCBUcmFuc2Zv cm0gRmllbGQgZm9yIFFLRCBpbiB0aGUgU0EgUGF5bG9hZC4KCkkgZG8gbm90IGFjdHVhbGx5IHRo aW5rIHdlIG5lZWQgYW55IG9mIHRoZXNlLiBXZSBoYXZlIGFscmVhZHkgdXNlZApOb3RpZnkgcGF5 bG9hZHMgZm9yIHRoaXMga2luZCBvZiBvbmUgZGlyZWN0aW9uYWwgbmVnb3RpYXRpb25zLCB3aGVy ZQp3ZSBkbyBub3QgcmVxdWlyZSBib3RoIGVuZHMgdG8gYWdyZWUsIGJ1dCB3aGVyZSBpZiBlaXRo ZXIgZW5kIGRlY2lkZXMKdG8gcmVmdXNlIHRoZSBwcm9wb3NhbCwgd2Ugc2ltcGx5IGxlYXZlIGl0 IG91dC4gRm9yIGV4YW1wbGUKVVNFX1RSQU5TUE9SVF9NT0RFIG5vdGlmaWNhdGlvbiBpcyBzZW50 IGJ5IGluaXRpYXRvciB0byBpbmRpY2F0ZSBpdAp3YW50cyB0byBkbyB0cmFuc3BvcnQgbW9kZSwg YW5kIGlmIHJlc3BvbmRlciBzZW5kcyBpdCBiYWNrLCBpdCB3aWxsCm1lYW4gdHJhbnNwb3J0IG1v ZGUgd2lsbCBiZSB1c2VkLCBvdGhlcndpc2Ugd2UgZmFsbCBiYWNrIHRvIHR1bm5lbAptb2RlICh3 aGljaCBpcyBtYW5kYXRvcnkpLiBTaW1pbGFyIHRoaW5nIGhhcHBlbnMgd2l0aCBJUENPTVBfU1VQ UE9SVEVECmV0Yy4gCgo+IDMuMS4xLiAgUUtEIEtleUlEIFBheWxvYWQKPiAKPiAgICBGaWd1cmUg MiBkZWZpbmVzIHRoZSBwYXlsb2FkIGZvciB0aGUgUUtEIEtleUlELgo+IAo+ICAgIFFLRCBLZXlJ RCBQYXlsb2FkCj4gCj4gICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMKPiAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCj4gICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKPiAgICAh IE5leHQgUGF5bG9hZCAgIUMhICBSRVNFUlZFRCAgICEgICAgICAgICBQYXlsb2FkIExlbmd0aCAg ICAgICAgIQo+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCj4gICAgISAgICB2ZXJzaW9uICAgICFGISAgIGZsYWdzICAg ICAhICAgICAgICAgIFFLRCBEZXZpY2UgSUQgICAgICAgICEKPiAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwo+ICAgICEg ICAgICAgICBLZXkgSUQgTGVuZ3RoICAgICAgICAgISAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAhCj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICEKPiAgICAhICAgICAgICAgICAgICAgICAgICBLZXkgSUQgKHZh cmlhYmxlIGxlbmd0aCkgICAgICAgICAgICAgICAgICAgIQo+ICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCj4gCj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDIKCkkgdGhpbmsgaXQgd291bGQg YmUgYmV0dGVyIHRvIGp1c3QgdXNlIFFLRF9LRVlJRCBzdGF0dXMgbm90aWZpY2F0aW9uLAppLmUs IGp1c3Qgc2F5IHRoZSBLZXkgSUQgaXMgbmVnb3RpYXRlZCB1c2luZyBOb3RpZmljYXRpb24gcGF5 bG9hZApoYXZpbmcgdGhlIFFLRF9LRVlJRCBhcyBub3RpZmljYXRpb24gbWVzc2FnZSB0eXBlLCBh bmQgdGhlIGluaXRpYXRvcgpzZW5kcyB0aGUgUUtEIEtleUlEIGluc2lkZSB0aGUgTm90aWZpY2F0 aW9uIGRhdGEsIGFuZCB0aGUgcmVzcG9uZGVyCndpbGwgc2ltcGx5IHNlbmQgZW1weSBRS0QgS2V5 SUQgbm90aWZpY2F0aW9uIGlmIGl0IGFncmVlcyBvbiB1c2luZwpRS0QuIElmIEtleSBJRCBpcyBz ZW50IGluc2lkZSB0aGUgSUtFX1NBX0lOSVQgYW5kIG90aGVyIGVuZCBhZ3JlZXMgb24KdXNpbmcg aXQsIHRoZW4gUUtEZGF0YSByZXRyaWV2ZWQgdXNpbmcgdGhlIFFLRCBLZXlJRCBpcyBhZGRlZCB0 byB0aGUKU0tFWVNFRUQgY2FsY3VsYXRpb24gKGFzIEkgZXhwbGFpbmVkIGVhcmxpZXIpLiBJZiBu b3QsIHRoZW4gdGhlCmNvbm5lY3Rpb24gZmFsbCBiYWNrcyB0byBub3JtYWwgSUtFdjIgRGlmZmll LUhlbGxtYW4uIFRoaXMgUUtEX0tFWUlECm5vdGlmaWNhdGlvbiBjYW4gYmUgaW4gYW55IHBheWxv YWQgd2hpY2ggY2FuIGhhdmUgS0UgcGF5bG9hZHMsIGkuZS4KSUtFX1NBX0lOSVQsIENSRUFURV9D SElMRF9TQSB3aGVuIHJla2V5aW5nIElQc2VjIG9yIElLRSBTQSBldGMuCgo+ICAgIFRoZSBOZXh0 IFBheWxvYWQgZmllbGQgb2YgdGhlIHByZXZpb3VzIGhlYWRlciBNVVNUIGJlIHNldCB0byB0aGUg UUtECj4gICAgS2V5SUQgUGF5bG9hZCBudW1iZXIgKHNlZSBTZWN0aW9uIDcpLiAgVGhlIGZpcnN0 IDMyIGJpdHMgb2YgdGhlCj4gICAgcGF5bG9hZCBhcmUgdGhlIEdlbmVyaWMgUGF5bG9hZCBIZWFk ZXIuICBUbyBhdm9pZCBhIG1hbi1pbi10aGUtbWlkZGxlCj4gICAgYXR0YWNrIGRvd25ncmFkaW5n IHRoZSBuZWdvdGlhdGVkIHNlY3VyaXR5IGxldmVsLCB0aGUgQ3JpdGljYWwgYml0Cj4gICAgbXVz dCBiZSBzZXQgdG8gMS4gIFRoZSByZXNwb25kZXIgTVVTVCByZXBseSB3aXRoIGFuIGVycm9yIG1l c3NhZ2UKPiAgICB3aGVuIGl0IGl0IGlzIGluY2FwYWJsZSBvZiB1c2luZyBRS0QgKHNlZSBTZWN0 aW9uIDQpLgoKQ3JpdGljYWwgYml0IGRvZXMgbm90IHByb3ZpZGUgYW55IHByb3RlY3Rpb24gYWdh aW5zdAptYW4taW4tdGhlLW1pZGRsZS4gSXQganVzdCBtYWtlcyBpbnRlcm9wZXJhYmlsaXR5IGFu ZCBmYWxsYmFjayB0bwp2ZXJzaW9uIHdoaWNoIGRvIG5vdCBzdXBwb3J0IFFLRCBpbXBvc3NpYmxl LiBBbGwgcGF5bG9hZHMgc2VudCBhbmQKcmVjZWl2ZWQgZHVyaW5nIHRoZSBJS0V2MiBleGNoYW5n ZXMgYXJlIGFscmVhZHkgcHJvdGVjdGVkIGFnYWluc3QKbWFuLWluLXRoZS1taWRkbGUsIHByb3Zp ZGVkIHN0cm9uZyBhdXRoZW50aWNhdGlvbiBvZiB0aGUgb3RoZXIgZW5kIGlzCmRvbmUuIEluIG5v cm1hbCBjYXNlIHRoaXMgaXMgZG9uZSBpbiB1c2luZyB0aGUgcHJlLXNoYXJlZCBrZXlzIG9yCnNp Z25hdHVyZXMsIGluIFFLRCBjYXNlIHRoZXJlIHdpbGwgYWxzbyBiZSBhZGRpdGlvbmFsIGF1dGhl bnRpY2F0aW9uCmFzIHRoZSBwZWVyIHdobyBkb2VzIG5vdCBrbm93IHRoZSBRS0RkYXRhIGNhbm5v dCBwYXJ0aWNpcGF0ZSB0aGUKbmVnb3RpYXRpb24sIHRodXMgZXZlbiBpZiB0aGUgcHJlLXNoYXJl ZCBrZXkgaXMgbGVha2VkIHRvIGF0dGFja2VyLAp0aGUgYXR0YWNrIHN0aWxsIGNhbm5vdCBkbyBt YW4taW4tdGhlLW1pZGRsZSBvZiB0aGUgUUtEIHByb3RlY3RlZApjb25uZWN0aW9uIGFzIGl0IGNh bm5vdCBjYWxjdWxhdGUgdGhlIFNLRVlTRUVEIHVzZWQgZHVyaW5nIHRoZQpJS0VfQVVUSCBwcm9j ZXNzaW5nLgoKU28gY3JpdGljYWwgYml0IHNob3VsZCBub3QgYmUgc2V0LiBUaGUgb25seSB0aGlu ZyBpdCB3aWxsIGNhdXNlIGlzCnRoYXQgeW91IGNhbm5vdCBjb21tdW5pY2F0ZSBhdCBhbGwgd2l0 aCBzb21lb25lIHdobyBkb2VzIG5vdCBkbyBRS0QuCkkuZS4gbGV0cyBzYXkgeW91IGhhdmUgdHdv IHNpdGVzLCBBIGFuZCBCLiBZb3Ugc2V0IHVwIHRoZSBRS0QgZmliZXIKbGluayBiZXR3ZWVuIHRo ZSBzaXRlcywgYW5kIHRoZW4gc3RhcnQgc2V0dGluZyB1cCB0aGUgUUtEIElQc2VjCmNvbm5lY3Rp b24gYmV0d2VlbiB0aGUgcGVlcnMuIFlvdSBnbyB0byBzaXRlIEEsIHVwZ3JhZGUgdGhlIHNvZnR3 YXJlCnRoZXJlLCB0byBzdXBwb3J0IFFLRCBhbmQgY29uZmlndXJlIGl0IHRvIHRyeSB0byB1c2Ug UUtELCBidXQgYWxsb3cKZmFsbGJhY2sgdG8gRGlmZmllLUhlbGxtYW4gaWYgUUtEIGlzIG5vdCBw b3NzaWJsZS4gQXMgdGhlIHNpdGUgQiBpcwpub3QgeWV0IHVwZGF0ZWQsIHRoZSBjb25uZWN0aW9u IHdpbGwgZmFsbCBiYWNrIHRvIERpZmZpZS1IZWxsbWFuIGFuZApldmVyeXRoaW5nIHN0aWxsIHdv cmtzLiBJZiB5b3UgdXNlIGNyaXRpY2FsIGJpdCwgdGhlIG90aGVyIGVuZCBhbHdheXMKcmV0dXJu cyBVTlNVUFBPUlRFRF9DUklUSUNBTF9QQVlMT0FEIGVycm9yLCBhbmQgdGhleSBjYW5ub3QgZmFs bCBiYWNrCnRvIERpZmZpZS1IZWxsbWFuLiAoTm90ZSwgdGhhdCBzaXRlIEEgd2lsbCB0aGluayBz aXRlIEIgaGFzIHRoZSBRS0QKbWF0ZXJpYWwsIGFzIHRoZSBmaWJlciBsaW5rIGlzIHRoZXJlLCBh bmQgdGhlIFFLRCBjYW4gYmUgcnVuIG92ZXIgdGhhdApmaWJlciBsaW5rLCBldmVuIGlmIHRoZSBs aW5rIGJldHdlZW4gdGhlIFFLRCBkZXZpY2UgYW5kIHRoZSBTR1cgaXMKc3RpbGwgbWlzc2luZyBm cm9tIHRoZSBvdGhlciBlbmQpLiAKCklmIG5vIGNyaXRpY2FsIGJpdCBpcyBzZXQsIHRoZW4geW91 IGNhbiBnbyB0byBzaXRlIEIsIHVwZ3JhZGUgdGhlCnNvZnR3YXJlIHRoZXJlIGFuZCB0aGVuIGVu YWJsZSBRS0QgdGhlcmUsIGFuZCByZXN0YXJ0IGNvbm5lY3Rpb24sIGFuZApub3cgYm90aCBlbmRz IHdpbGwgc3RhcnQgdXNpbmcgUUtELgoKPiAgICBvICBWZXJzaW9uIChvbmUgb2N0ZXQpIHNwZWNp ZmllcyB0aGUgZm9ybWF0IGFuZCBzZW1hbnRpY3Mgb2YgdGhpcwo+ICAgICAgIG1lc3NhZ2UuICBU aGUgY3VycmVudCB2ZXJzaW9uIGlzIDEuCgpJZiB1c2luZyBub3RpZmljYXRpb24gcGF5bG9hZHMs IHlvdSBkbyBub3QgbmVlZCB2ZXJzaW9uIG51bWJlciwgYXMgd2UKY2FuIHNpbXBseSBhbGxvY2F0 ZSBuZXcgc3RhdHVzIG5vdGlmaWNhdGlvbiBudW1iZXIgaWYgd2UgbmVlZCB0byBtYWtlClFLRF9L RVlJRDIgdmVyc2lvbi4uLiAKCj4gICAgbyAgVGhlICJGIiBmaWVsZCBjb250YWlucyB0aGUgUnVu bmluZyBNb2RlIGNvbmZpZ3VyYXRpb24uICBJUHNlYyB3aXRoCj4gICAgICAgUUtEIGhhcyB0d28g bW9kZXMsIG5vcm1hbCBhbmQgZmFsbGJhY2suICBUYWJsZSAxIHNob3dzIHRoZSBtb2Rlcwo+ICAg ICAgIGFuZCBtb2RlIHZhbHVlcy4gIFRoaXMgZmllbGQgTVVTVCBiZSAwIGZvciBpbml0aWF0aW5n IElQc2VjLgoKQXMgSSBtZW50aW9uZWQgZWFybGllciwgbm8gcG9pbnQgb2YgaGF2aW5nIGZhbGxi YWNrIG1vZGUsIGl0IGlzIGxvY2FsCnBvbGljeSBtYXR0ZXIuIAoKPiAgICBvICBGbGFncyBob2xk cyBmbGFnIGJpdHM7IHRoaXMgZmllbGQgTVVTVCBiZSB6ZXJvLgo+Cj4gICAgbyAgUUtEIERldmlj ZSBJRCBjb250YWlucyBhbiBJRCBudW1iZXIgZm9yIHRoZSBRS0QgZGV2aWNlLiAgRWFjaAo+ICAg ICAgIElQc2VjIEdhdGV3YXkgbWF5IGJlIGVxdWlwcGVkIHdpdGggbW9yZSB0aGFuIG9uZSBRS0Qg ZGV2aWNlLiAgVGhpcwo+ICAgICAgIGZpZWxkIGNhcnJpZXMgYW4gSUQgbnVtYmVyIHRvIGRldGVy bWluZSB3aGljaCBRS0QgZGV2aWNlIHNob3VsZCBiZQo+ICAgICAgIHVzZWQuICBUaGUgRGV2aWNl IElEIHBsdXMgdGhlIEtleSBJRCBNVVNUIHVuaXF1ZWx5IGlkZW50aWZ5IHRoZQo+ICAgICAgIGtl eS4KPiAKPiAgICBvICBLZXkgSUQgTGVuZ3RoIGRlZmluZXMgdGhlIGxlbmd0aCBvZiBLZXkgSUQg ZmllbGQuCj4gCj4gICAgbyAgS2V5IElEICh2YXJpYWJsZSBsZW5ndGgpIGlzIHVzZWQgdG8gY29t bXVuaWNhdGUgd2hpY2gga2V5IHRvIHVzZQo+ICAgICAgIGZvciB0aGUgZW5jcnlwdGlvbi4KCkkg dGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGp1c3QgZGVmaW5lIHRoZSBLZXlJRCB0byBiZSBi aW5hcnkgYmxvYgpjb250YWluaW5nIHRoZSBpZGVudGl0eSBvZiB0aGUga2V5IGluIHRoZSBmb3Jt YXQgdGhhdCBkZXBlbmRzIG9uIHRoZQphY3R1YWwgUUtEIGRldmljZXMgdXNlZC4gSS5lLiBpZiBk ZXZpY2UgSURzIGFyZSBuZWVkZWQsIHRoZW4gdGhvc2UKc2hvdWxkIGJlIGluY2x1ZGVkIGluIHRo ZSBLZXlJRCBldGMuCgpOb3RlLCBhcyBpdCBpcyBhc3N1bWVkIHRoYXQgYm90aCBlbmRzIHNoYXJl IHRoZSBzYW1lIHNlY3JldCBtYXRlcmlhbAphY2Nlc3NhYmxlIHVzaW5nIHRoZSBLZXlJRCwgaXQg d291bGQgYmUgcG9zc2libGUgdG8gdXNlIHRoaXMgbWV0aG9kCmFsc28gZm9yIG90aGVyIHVzZXMg dGhhbiBRS0QuIEZvciBleGFtcGxlIHRoZSBRS0RkYXRhIGNvdWxkIGJlCnJldHJpZXZlZCBmcm9t IHRoZSBEVkQgbWFpbGVkIG92ZXIgZGlwbG9tYXRpYyBtYWlsIHRvIHRoZSBkZXN0aW5hdGlvbiwK YW5kIHRoZSBLZXkgSUQgY291bGQganVzdCBiZSB1c2VkIGFzIHJlZmVyZW5jZSB0byB0aGUgb25l IHRpbWUgcGFkIG9uCnRoZSBEVkQsIGkuZS4gdGhlIGtleSBJRCBjb3VsZCBjb25zaXN0IG9mIDY0 LWJpdCBEVkQgaWQgbnVtYmVyLCBhbmQKMzItYml0IGJsb2NrIG51bWJlciBvbiB0aGUgZHZkLiBG cm9tIHRoZSBibG9jayBudW1iZXIgdGhlIHN5c3RlbSB3b3VsZApyZWFkIG9uZSA2NC1ieXRlIChm b3IgZXhhbXBsZSkgYmxvY2sgYW5kIHVzZSB0aGF0IGFzIFFLRGRhdGEuCgpTbyB0aGlzIHNhbWUg bWV0aG9kIGNhbiBiZSB1ZXNkIHdpdGggYWxsIGtpbmQgb2YgT09CIChvdXQgb2YgYmFuZCkKa2V5 aW5nIG1hdGVyaWFsIGRpc3RyaWJ1dGlvbiBtZXRob2RzLCBpLmUuIGl0IG1pZ2h0IGJlIHdvcnRo IG9mIGVmZm9ydAp0byBjaGFuZ2Ugc3RyaW5nIFFLRCB3aXRoIE9PQktELi4uCgo+IDMuMS4yLiAg UUtEIEZhbGxiYWNrIFBheWxvYWQKClJlbW92ZSBhbGwgdGhpcy4uCgo+IDMuMS4zLiAgVHJhbnNm b3JtIEZpZWxkIGZvciBRS0QgaW4gU0EgUGF5bG9hZAo+IAo+ICAgIEZpZ3VyZSA0IGRlZmluZXMg dGhlIFRyYW5zZm9ybSBGaWVsZCBmb3IgUUtEIGluY2x1ZGVkIGluIHRoZSBTQQo+ICAgIFBheWxv YWQuCgpJZiB0aGUgUUtEIGlzIG5lZ290aWF0ZWQgdXNpbmcgbm90aWZ5LCB0aGVyZSBpcyBubyBu ZWVkIGZvciB0cmFuc2Zvcm0KaWQgYXQgYWxsLiAKCj4gICAgbyAgVHJhbnNmb3JtIElEIGZpZWxk IGNvbnRhaW5zIHRoZSBtZXRob2QgZm9yIHVzaW5nIFFLRC4gIFRhYmxlIDMKPiAgICAgICBzaG93 cyB0aGUgbW9kZXMgYW5kIHRoZSB2YWx1ZXMuICBEaXJlY3QgdXNlIG1lYW5zIHVzaW5nIFFLRC0K PiAgICAgICBnZW5lcmF0ZWQga2V5IGFzIGVuY3J5cHQga2V5LiAgSW4gcGFzc3dvcmQtYXV0aGVu dGljYXRlZCBrZXkgbW9kZSwKPiAgICAgICB0aGUgUUtELWdlbmVyYXRlZCBrZXkgaXMgdXNlZCBm b3IgRC1ILiAgU2VlIFtSRkM1NjgzXSBmb3IgZGV0YWlscy4KCklmIFFLRCBpcyB1c2VkIGp1c3Qg Zm9yIGF1dGhlbnRpY2F0aW9uLCBpLmUuIG5vdCBhdCBhbGwgaW4gdGhlClNLRVlTRUVEIGNhbGN1 bGF0aW9uLCB0aGVuIGl0IHdvdWxkIGJlIGJldHRlciB0byBqdXN0IHVzZSBwcmUtc2hhcmVkCmtl eSwgYXMgUUtELWdlbmVyYXRlZCBrZXkgc2hvdWxkIGJlIHJhbmRvbSwgYW5kIHN0cm9uZywgdGh1 cyBzdWl0YWJsZQpmb3IgcHJlLXNoYXJlZCBrZXkgYXV0aGVudGljYXRpb24uIFRoZSBwYXNzd29y ZCBhdXRoZW50aWNhdGVkIGtleQptb2RlcyBhcmUgcmVhbGx5IG9ubHkgbmVlZGVkIHdoZW4gdXNl ZCB3aXRoIHdlYWsgcGFzc3dvcmRzLiBBY3R1YWxseQp0aGlzIGRvZXMgbm90IGRlZmluZSBhdCBh bGwgaG93IHRoZSBRS0Qgd291bGQgYmUgdXNlZCBpbiB0aGF0IGNhc2UsCndvdWxkIHRoZSBRS0Rk YXRhIGp1c3QgcmVwbGFjZSB0aGUgcGFzc3dvcmQgb3Igd2hhdD8gQWxzbyB0byB1c2UgYW55Cm9m IHRob3NlIHBhc3N3b3JkIGF1dGhlbnRpY2F0ZWQgbWV0aG9kcyBpbiBJS0V2MiwgeW91IHdvdWxk IHJlYWxseQpuZWVkIHRvIHVzZSB0aGUgUkZDNjQ2NyBzZWN1cmUgcGFzc3dvcmQgZnJhbWV3b3Jr IGFuZCBwaWNrIG9uZSBvZiB0aGUKc2VjdXJlIHBhc3N3b3JkIG1ldGhvZHMgZnJvbSB0aGUgb25l cyBzdGFuZGFyZGl6ZWQgZm9yIGl0IChpLmUuIFBBQ0UKKFJGQzY2MzEpIEF1Z1BBS0UgKFJGQzY2 MjgpLCBTZWN1cmUgUFNLIEF1dGhlbnRpY2F0aW9uIChSRkM2NjE3KSksCm5vdCBkZWZpbmUgb25l IG1vcmUgbWV0aG9kIGZvciBpdC4KCkJ1dCBhcyB1c2luZyB0aGUgUUtEIGluIHRoZSBTS0VZU0VF RCBnZW5lcmF0aW9uIGFzIEkgZGVzY3JpYmVkCmVhcmxpZXIsIHdpbGwgYXV0b21hdGljYWxseSB1 c2UgaXQgZm9yIGF1dGhlbnRpY2F0aW9uIGFsc28sIHRoZXJlCndvdWxkIG5vdCBiZSBuZWVkIGZv ciB1c2luZyBRS0Qgb25seSBpbiBhdXRoZW50aWNhdGlvbi4gCgo+IDMuMi4xLiAgSW5pdGlhbGl6 aW5nIElLRV9TQQo+IAo+ICAgIFRoZSBJS0VfU0FfSU5JVCB3aXRoIFFLRAo+IAo+IAo+ICAgICBJ bml0aWF0b3IgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXNwb25kZXIK PiAgICAtLS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLS0t LS0tLS0tLQo+ICAgICAgICAgIEhEUiwgU0FpMSwgS0VpLCBOaSBLZXlJRCAgIC0tPgoKSSB0aGlu ayB0aGUgYmV0dGVyIHdheSB0byBkbyB0aGlzIHdvdWxkIGJlIHRvIGRvOgoKICAgSW5pdGlhdG9y ICAgICAgICAgICAgICAgICAgICAgICAgIFJlc3BvbmRlcgogICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgIEhEUiwg U0FpMSwgS0VpLCBOaSwgTihRS0RfS0VZSUQpICAtLT4KCiAgICAgICAgICAgICAgICAgICAgICA8 LS0gIEhEUiwgU0FyMSwgS0VyLCBOciwgTihRS0RfS0VZSUQpLCBbQ0VSVFJFUV0KCkFuZCB0aGVu IHRoZSBTS0VZU0VFRCB3b3VsZCBiZSBnZW5lcmF0ZWQgYXMKCiAgIFNLRVlTRUVEID0gcHJmKE5p IHwgTnIsIGdeaXIgfCBRS0RkYXRhKQoKYW5kIHRoZSByZXN0IG9mIElLRXYyIGV4Y2hhbmdlIHdv dWxkIHByb2Nlc3MgYXMgbm9ybWFsbHkuIAoKPiAzLjIuMi4gIFJla2V5aW5nIElLRV9TQQoKUmVr ZXlpbmcgc2hvdWxkIGdvIGluIHNpbWlsYXJseSBhcyBJS0VfU0FfSU5JVCwgaS5lLiBqdXN0IGFk ZGluZwpOb3RpZnkgYW5kIGFkZGluZyBRS0RkYXRhIHRvIHRoZSBTS0VZU0VFRC4gCgo+IDYuICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKVGhlIHNlY3VyaXR5IG9mIHRoZSBRS0QgaXMgZGVwZW5k ZW50IG9uIHRoZSBhY3R1YWwgcmFuZG9tIG51bWJlcgpnZW5lcmF0b3IgZ2VuZXJhdGluZyB0aGUg Yml0cyB0cmFuc21pdHRlZCBvdmVyIHRoZSBRS0QgbGluay4gVGhpcwpzaG91bGQgYmUgbWVudGlv bmVkIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLiBPZiBjb3Vyc2UKdGhl IGxvc3N5IG5hdHVyZSBvZiB0aGUgUUtEIGxpbmsgd2lsbCBhZGQgc29tZSByYW5kb21uZXNzIHRv IHRoZQpwcm9jZXNzLCBidXQgdGhpcyBtaWdodCBkaXNhcHBwZWFyIHdoZW4gbGluayBtZXRob2Rz IGdldCBiZXR0ZXIuIElmCnVzaW5nIHRoZSBTS0VZU0VFRCBtZXRob2QgdGhlIHF1YWxpdHkgb2Yg dGhlIHJhbmRvbSBudW1iZXIgZ2VuZXJhdG9yCmRvZXMgbm90IG1hdHRlciB0aGF0IG11Y2gsIG9u bHkgdGhlIGFtb3VudCBvZiBlbnRyeXB5IGluIHRoZSBRS0RkYXRhCm1hdHRlcnMuIEkuZS4gZXZl biBpZiBoYWxmIG9mIHRoZSA1MTItYml0IFFLRGRhdGEgaXMgemVyb3MsIGFuZAphbm90aGVyIGhh bGYgaXMgYWN0dWFsbHkgcmFuZG9tLCB0aGVuIHRoaXMgd2lsbCBzdGlsbCBoYXZlIDI1Ni1iaXRz IG9mCmVudHJ5cHkgYW5kIGl0IHdpbGwgYmUgc2VjdXJlIGFnYWluc3QgYXR0YWNrcy4gT24gdGhl IG90aGVyIGhhbmQgaWYKdGhlIFFLRCBkYXRhIHdvdWxkIGJlIHVzZWQgZGlyZWN0bHkgYXMga2V5 aW5nIG1hdGVyaWFsIGZvciB0aGUKc3ltbWV0cmljIGtleXMgd2l0aG91dCB1c2luZyBQUkYrIHRv IG1peCB0aGUgZW50cnlweSwgdGhpcyBjb3VsZCBjYXVzZQpjYXRhc3Ryb3BoaWMgZmFpbHVyZXMg dG8gdGhlIHN5c3RlbS4KCkFzIGFjdHVhbCBJUHNlYyBrZXkgbWF0ZXJpYWwgaXMgZ2VuZXJhdGVk IGZyb20gdGhlIEtFWU1BVCwgd2hpY2ggaXMKZ2VuZXJhdGVkIGZyb20gdGhlIFNLX2QgdXNpbmcg cHJmKywgd2hpY2ggaXMgZ2VuZXJhdGVkIGZyb20gdGhlClNLRVlTRUVEIHVzaW5nIHByZissIGV0 YywgdGhlIG92ZXJhbGwgc2VjdXJpdHkgb2YgdGhlIHN5c3RlbSBzdGlsbApkZXBlbmRzIGhlYXZp bHkgb24gdGhlIHByZisuCgpUaGlzIHNob3VsZCBhbHNvIG1ha2Ugc3VyZSB0aGF0IGJvdGggZW5k cyB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IGVhY2gKS2V5IElEIGlzIG9ubHkgb25jZSBmb3Igc3Vj Y2Vzc2Z1bGx5LCBpLmUuIG9uY2UgdGhlIFFLRGRhdGEgYXNzb2NpYXRlZAp3aXRoIEtleSBJRCBp cyB1c2VkIHN1Y2Nlc3NmdWxseSB3aXRoIHRoZSBJS0V2MiwgdGhlbiByZXVzZSBvZiB0aGF0CnNo b3VsZCBub3QgYmUgYWxsb3dlZC4gT24gdGhlIG90aGVyIGhhbmQgd2UgZG8gd2FudCB0byBtYWtl IHN1cmUgdGhhdAphdHRhY2sgY2Fubm90IGNvbnN1bWUgYWxsIFFLRGRhdGEgYnkgZG9pbmcgaHVn ZSBhbW91bnQgb2YKdW5zdWNjZXNzZnVsbCB0cmllcyBmb3IgSUtFdjIgYXV0aGVudGljYXRpb25z LCB0aHVzIGlmIHRoZSBwZWVyIHdvdWxkCnJlbW92ZSBLZXkgSUQgZnJvbSB1c2UgaW1tZWRpYXRl bHkgd2hlbiBpdCBpcyB1c2VkIHJlZ2FyZGxlc3Mgd2hldGhlcgp0aGUgbmVnb3RpYXRpb24gc3Vj ZWVkIG9yIG5vdCwgdGhpcyB3b3VsZCBjYXVzZSBlYXN5IHdheSB0byBjb25zdW1lCmFsbCBrZXkg aWRzIGluIHRoZSBzeXN0ZW0uIAotLSAKa2l2aW5lbkBpa2kuZmkK --NxzIEWtU4I-- From nobody Mon Aug 24 08:36:35 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120141A87D0 for ; Mon, 24 Aug 2015 08:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUEFVPPvrfCB for ; Mon, 24 Aug 2015 08:36:32 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A2E1A87AB for ; Mon, 24 Aug 2015 08:36:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3n0HcF6kYWz1bv; Mon, 24 Aug 2015 17:36:29 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=Ep1x3PJu X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id NcSSu9XSBvXe; Mon, 24 Aug 2015 17:36:28 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 24 Aug 2015 17:36:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 366918009F; Mon, 24 Aug 2015 11:36:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440430587; bh=m/ZvO0EqTrX67R8BsTBLuhS3dU5iX9HJRZ3HXQ925x0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Ep1x3PJuHikkCKCgYY4LKiQAxb/nU/o5vDagBF7rDBsRa7FGLl7lrW0Etj38hUuMq iKIGeVPLKG4HLxwQqy0YpjHN0R+KzOlPgpmAoAhVXgzhBNcvRPJzX+iWFr/iWxCfbB fcD3phmruVgo2haZaf1Xvq7DECCjxAv4BJF5eXwA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7OFaQ3Q014778; Mon, 24 Aug 2015 11:36:26 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 24 Aug 2015 11:36:26 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21979.10240.760855.22791@fireball.acr.fi> Message-ID: References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> <21979.10240.760855.22791@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 15:36:34 -0000 On Mon, 24 Aug 2015, Tero Kivinen wrote: > I think we should continue pushing the > draft-nagayama-ipsecme-ipsec-with-qkd forward, and specify it as > generic method where out of band shared keys can be brought in to the > SKEYSEED or KEYMAT. +1 Paul From nobody Mon Aug 24 08:45:31 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD411A888B for ; Mon, 24 Aug 2015 08:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RR4MYz8cC7nN for ; Mon, 24 Aug 2015 08:45:29 -0700 (PDT) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E393F1A886B for ; Mon, 24 Aug 2015 08:45:28 -0700 (PDT) Received: by pdob1 with SMTP id b1so54812591pdo.2 for ; Mon, 24 Aug 2015 08:45:28 -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=uCSVQJt6QYpfCpp8OeORzMUVUpDXGeWn6jnaR4LWfBA=; b=liUwmm8RkUZRDo7cuzi81mjnp6hd45tahfN0Xw4xCXDeQ7a02NV7eJrEDZ66BG2KZ1 4V70k9mcSZv716J1VtIFx0Sp+YtE94LXN7+MlGceP9tk8ms8XkomnkNuLywt2Ao0yN7D uuhkcTaxg6Kbc5oCLIp2wQQkSmpi4pWqB35g86He2nsBTYjkupIChT6OUCs7pY7Odlae H8dg2Nh8Fwq+9xze4RcgH/J5IL4xl2ntUc9kvUVR0CJTAAYaJRaU3H0rq1DvWahqrZQl Cq9lzGiQnasjhtADZxhuWVlg1D8xWGlcDmpio/mHmhLC5biSQre7HoRdLIwX2BE145if Y2Ew== X-Received: by 10.70.135.41 with SMTP id pp9mr1129701pdb.158.1440431128394; Mon, 24 Aug 2015 08:45:28 -0700 (PDT) Received: from [172.18.132.38] (cowboy.intuit.com. [65.204.229.11]) by smtp.googlemail.com with ESMTPSA id w2sm16420540pdo.89.2015.08.24.08.45.26 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Aug 2015 08:45:27 -0700 (PDT) Message-ID: <55DB3C14.5050900@gmail.com> Date: Mon, 24 Aug 2015 18:45:24 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Paul Wouters , Tero Kivinen References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> <21979.10240.760855.22791@fireball.acr.fi> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 15:45:30 -0000 Even in a world where quantum computers are a risk that we need to consider in our crypto, QKD will still remain a niche. So to go back to the original question, NTRU+BLISS are a possible solution if we care about this problem. QKD is not. Thanks, Yaron On 08/24/2015 06:36 PM, Paul Wouters wrote: > On Mon, 24 Aug 2015, Tero Kivinen wrote: > >> I think we should continue pushing the >> draft-nagayama-ipsecme-ipsec-with-qkd forward, and specify it as >> generic method where out of band shared keys can be brought in to the >> SKEYSEED or KEYMAT. > > +1 > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Aug 24 12:02:48 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540821A0469 for ; Mon, 24 Aug 2015 12:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx-irOHLdSWJ for ; Mon, 24 Aug 2015 12:02:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCB8D1A014B for ; Mon, 24 Aug 2015 12:02:38 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 852372002A for ; Mon, 24 Aug 2015 15:21:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B824563B10; Mon, 24 Aug 2015 15:02:37 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9DC1463AD9 for ; Mon, 24 Aug 2015 15:02:37 -0400 (EDT) From: Michael Richardson To: IPsecME WG In-Reply-To: <55D5F012.4030206@strongswan.org> References: <330f40a932fdab731e738fc48c7c43af.squirrel@www.trepanning.net> <31446.1440004597@sandelman.ca> <29C194186F21E3449DEE427644BBCA087BEC9B13@mpbeexchange.gwhosting.local> <55D5F012.4030206@strongswan.org> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 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 Sender: mcr@sandelman.ca Archived-At: Subject: Re: [IPsec] PSK mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 19:02:46 -0000 --=-=-= Content-Type: text/plain Andreas Steffen wrote: > an NTRU Encryption-based IKEv2 key exchange is actually what the > strongSwan open source VPN software has been offering with the > ntru plugin for more than a year: > https://wiki.strongswan.org/projects/strongswan/wiki/NTRU I read a bit about NTRU on wikipedia, of which I knew nothing before. There are patents involved, I don't know which ones and I don't know when they expire, but it seems like it isn't that new an idea. Apparently they wrote some kind of exemption for open source. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVdtqTYCLcPvd0N1lAQIlIQf+J9byHqL048PpChuIwqEJGeqX+uMz5UV7 KwECLl5loJwxO0/qKdgDo8c2XE47h/o9d1b5j26aJIS3zJmFdJkHUFMRrW1NO07D 5sueICYO/QSIHztqOCg/BWYvQShgwOB49CJubzpcsTsXRn0jvMYOlXvhhax4GFcC eJt+HsbKifx7fCzVwNua2Aa5jqUcvoZ38uzMJfpRBooZkOgNBGIH4Q/T3dULGU4y L5r08fST+Now/yfay+kaRQtYJuTyDY9QAx0kXkaciIItGLqqbVFhdtaRMjwb8HLv UMADbrBFAEK4aOjkZk7axoTybrv+eLnXVvM8AqWVRTdxiwQSdIhFQA== =8ktw -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 24 15:58:44 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD401A89FB for ; Mon, 24 Aug 2015 15:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exz_yoEVUeun for ; Mon, 24 Aug 2015 15:58:42 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2CD1ACCFD for ; Mon, 24 Aug 2015 15:58:42 -0700 (PDT) Received: from [10.32.60.58] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t7OMwf3V015670 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 24 Aug 2015 15:58:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.58] From: "Paul Hoffman" To: "IPsecME WG" Date: Mon, 24 Aug 2015 15:58:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 22:58:43 -0000 Greetings. There was some general interest in having a standard way to modern elliptic curves for ephemeral key exchange. Please respond in this thread whether or no you think this document is a good start on that work, and whether or not you think the WG should have this as a work item. --Paul Hoffman From nobody Mon Aug 24 16:49:30 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8C0C1A87CD for ; Mon, 24 Aug 2015 16:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD8jA6ctdShq for ; Mon, 24 Aug 2015 16:49:27 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2A81A87AC for ; Mon, 24 Aug 2015 16:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1440460166; x=2304373766; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=O0iSsKD60Dmquf3MtIkXXhVe35wRwNlzucHZhMUXDXc=; b=kOOFmKvn3vv4EurLO0rUs5dnzTaOLSmsDKjLpwqAG/d8xgz8tZHIcvCCCTWsdqcE cTufHQj98uHvVFhq2ajm7oonYkQicF+3E5MBiE+aYh8JUTxEdzAwDIr4jNl1f4Ra eid4okS+/8l9Lo/ODg5xQA86JfAzsdCeJU7UAu6G2gaAH+3nbnvVO/HyoLr2/65h UpKl1Eiyl5WbJPPf4bQ6EaKxa2GZAX3Crtx3W8wLsDTQu8kjNW6q/e1axKtF5eK5 EJaFJC4i1Pg645xEhXHj6VAwW0kyaTGbJ42xdNMatqUq4mIoLk0NW3t2TF6aRget 0kngWGX4rCMGptqObUSpXg==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id D9.16.23348.68DABD55; Mon, 24 Aug 2015 16:49:26 -0700 (PDT) X-AuditID: 11973e13-f79306d000005b34-48-55dbad86c8a0 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id A6.16.32123.68DABD55; Mon, 24 Aug 2015 16:49:26 -0700 (PDT) Received: from da0602a-dhcp122.apple.com (da0602a-dhcp122.apple.com [17.226.23.122]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NTM007TQ26DTW40@cilantro.apple.com> for ipsec@ietf.org; Mon, 24 Aug 2015 16:49:26 -0700 (PDT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.0 \(3074\)) From: Tommy Pauly In-reply-to: Date: Mon, 24 Aug 2015 16:49:41 -0700 Content-transfer-encoding: quoted-printable Message-id: <067D6ECD-2BF1-4F36-AF57-3A30248D2945@apple.com> References: To: Paul Hoffman X-Mailer: Apple Mail (2.3074) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYrNu29naowb/zOhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsPWlSwFs9kr1lx5wNTA2MnWxcjBISFgInHvcmAXIyeQKSZx 4d56oDAXh5DAXkaJ9Td2sEMkTCRePOtnhUhMZJJ4OLsFytnAJHFiYjsbSBWzgJbE+p3HmUBs XgE9ieZ/e5lBbGGBCImZ91ezgthsAioSx79tAItzCthI/H5/DMxmEVCV+PhiMTPEHHmJ3v8b GSFsbYkn7y6wQsy0kbh5chvYLiEBa4mPF+6DxUUENCQuPIS5VFbi5/Gj7CDHSQhMYJPo7PjP NoFReBaS+2YhuW8Wkh0LGJlXMQrlJmbm6GbmmeolFhTkpOol5+duYgQF8nQ74R2Mp1dZHWIU 4GBU4uGdMf92qBBrYllxZe4hRmkOFiVx3jwDoJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG yAkif0U9wzZNit7VXmtx29qv7Zzbik0+7p8zj/CuYbu9iytAM2fWxqxl3lIXmyaemSWozSnj fWTvyzezr3b1+tnfmTD/n+aEAyc3HOX8af7gza3nPD8to9LWzjnrEHYg/1/Ndr09chweeezX i59dOMJYe/fr0x0qf8omBfot2CRa/i34zweF7UosxRmJhlrMRcWJAE7GkNVFAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUi2FAspNu29naoQc8bGYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEro2HrSpaC2ewVa648YGpg7GTrYuTkkBAwkXjxrJ8VwhaTuHBv PVCci0NIYCKTxMPZLawQzgYmiRMT28E6mAW0JNbvPM4EYvMK6Ek0/9vLDGILC0RIzLy/GmwS m4CKxPFvG8DinAI2Er/fHwOzWQRUJT6+WMwMMUdeovf/RkYIW1viybsLrBAzbSRuntwGtktI wFri44X7YHERAQ2JCw93sENcKivx8/hR9gmMArOQnDQLyUmzkIxdwMi8ilGgKDUnsdJYL7Gg ICdVLzk/dxMjOPQKg3cw/llmdYhRgINRiYf3w8LboUKsiWXFlbmHGCU4mJVEeNNXAIV4UxIr q1KL8uOLSnNSiw8xJgM9M5FZSjQ5HxgXeSXxhiYmBibGxmbGxuYm5qQJK4nz8i4HWiGQnliS mp2aWpBaBLOFiYNTqoGx9IzppMDD6nfVW8QCFi/X+u/JJFxc8NkmeN/XPZ9LrG9rygb3dhc+ rsjPbfpf/YrnGXdT58GqgPsqCht5VWqOTjp5RjBo9imfA38apstuzOzo55M/YFS12mPdw2eT t0jHzr9RE/I72Ellwam2fZnvozYUyYk+b1tRcPAyV8EZ/m8XrX/96G9RYinOSDTUYi4qTgQA 9Os8ioECAAA= Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 23:49:29 -0000 I think this would be a good feature for the WG to work on, and that = this document provides a good start. Thanks, Tommy Pauly > On Aug 24, 2015, at 3:58 PM, Paul Hoffman = wrote: >=20 > Greetings. There was some general interest in having a standard way to = modern elliptic curves for ephemeral key exchange. Please respond in = this thread whether or no you think this document is a good start on = that work, and whether or not you think the WG should have this as a = work item. >=20 > --Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_ipsec&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3Dp3wIGO08_H-OJhu= nJTPABw&m=3DgT9uQhEuaKWOcKHV039CypYOlz19mz_f_1CQ4QpDt0U&s=3DRAO9in8Syrok4P= urz0fgaBR1-MEHWdpPeB7N4l8lzrI&e=3D=20 From nobody Mon Aug 24 21:09:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE3E1A8879 for ; Mon, 24 Aug 2015 21:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V12R-O8-UEZa for ; Mon, 24 Aug 2015 21:09:42 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C911A874B for ; Mon, 24 Aug 2015 21:09:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3n0cKJ1r2gzBd; Tue, 25 Aug 2015 06:09:40 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=MtyekIAa X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id d9WoJ81HnZhA; Tue, 25 Aug 2015 06:09:39 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 25 Aug 2015 06:09:38 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 220FA8009D; Tue, 25 Aug 2015 00:09:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440475778; bh=1svoSVKcu9swj0JLiul3t11mFwNEC/lhJSYExOapGrc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MtyekIAaNR0OCQTsxSn5kSMPxRmadQ4M84y693oTfps8Cy6aw60XLo/WVuDF3jEYh PVKwNcqPBf0Rdb+/WnnMAz0wNn7qFdf7g3A+baFhlJegyFl6eEvQr8QpDV0IL7gEyb 6g/1WSUszA4h5rlIaahkZu4qJF3LTQKud+3Q+2eE= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7P49blw001779; Tue, 25 Aug 2015 00:09:37 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 25 Aug 2015 00:09:37 -0400 (EDT) From: Paul Wouters To: Paul Hoffman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 04:09:44 -0000 On Mon, 24 Aug 2015, Paul Hoffman wrote: > Subject: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work > item Note that I tried looking at the document and pasted it into google and oddly got: https://tools.ietf.org/html/draft-nir-ipsecme-curve25519-00 which does NOT list that there is a -01 as well. But there is: https://tools.ietf.org/html/draft-nir-ipsecme-curve25519-01 > Greetings. There was some general interest in having a standard way to modern > elliptic curves for ephemeral key exchange. Please respond in this thread > whether or no you think this document is a good start on that work, and > whether or not you think the WG should have this as a work item. Yes I think the WG should take on this work, and this document is a good start. Paul From nobody Tue Aug 25 05:04:35 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1002C1AD0D1 for ; Tue, 25 Aug 2015 05:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjrZY5zcR23U for ; Tue, 25 Aug 2015 05:04:33 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8881A8F35 for ; Tue, 25 Aug 2015 05:04:32 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t7PBkUgs012810 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Aug 2015 14:46:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t7PBkUGT029253; Tue, 25 Aug 2015 14:46:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21980.21910.16806.245646@fireball.acr.fi> Date: Tue, 25 Aug 2015 14:46:30 +0300 From: Tero Kivinen To: "Paul Hoffman" In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 0 min X-Total-Time: 0 min Archived-At: Cc: IPsecME WG Subject: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 12:04:34 -0000 Paul Hoffman writes: > Greetings. There was some general interest in having a standard way to > modern elliptic curves for ephemeral key exchange. Please respond in > this thread whether or no you think this document is a good start on > that work, and whether or not you think the WG should have this as a > work item. I think this is good start, and we should work on this in the WG. -- kivinen@iki.fi From nobody Tue Aug 25 05:37:22 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F021A8AA6 for ; Tue, 25 Aug 2015 05:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuwSspz0in7p for ; Tue, 25 Aug 2015 05:37:19 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAADE1ACEA9 for ; Tue, 25 Aug 2015 05:37:18 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t7PCJFrw008845 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 25 Aug 2015 15:19:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t7PCJFU4000723; Tue, 25 Aug 2015 15:19:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21980.23875.397896.822512@fireball.acr.fi> Date: Tue, 25 Aug 2015 15:19:15 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 32 min Archived-At: Subject: [IPsec] My review of draft-nir-ipsecme-curve25519 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 12:37:20 -0000 Firstly the name of the draft is bit misleading, as this defines both curve25519 and Curve448 keys not only curve25519. This document is bit confusing as some of the values are defined as "strings of 32 octets", some are defined as 255/448-bit numbers having certain properties (high bit set, n lowest bits unset), but then later it mixes these. For example the public key is defined of "string of 32 octets", but then section 3.1 says that it is "32 octets encoded as an array of bytes in little-endian order...". As we are talking about the string of 32 octets, talking about it being litt-endian is confusing. I would assume that section 8 of [CFRG-Curves] would define how to convert the internal number to 32-octet string, so leaving out the "little-endian order" from this draft would be clearer. In the section 3.2 recipient tests there is discussion about checking that the public key 32-octet string will have last byte in such way that high-order bit of it is not set. If this is property of the func(d, G) for curve25519, and curve448, how can we ever get public values having that bit set? So why it is only SHOULD to reject that public key? I mean if we receive such public key, that clearly means that other end is either attacker, or working incorrectly, and we MUST always reject it. Or if there is no security issues accepting such public keys, then why not just say that no checks needs to be done. If we reject such public key, what behavior should happen in IKE level? Error message, drop silently? Same as RFC6989? In the security considerations section the 2nd last paragraph only mentions that Curve25519 explictly, but does not mention curve448. Is there difference between them, or should the text say "This is widely seen as a security advantage for these curves, since...". Typos: In section A.1.1 s/mutliplying/multiplying/ The test vectors should most likely also include Curve448 test vectors, and perhaps even full IKEv2 KE payloads... -- kivinen@iki.fi From riyazinbec@gmail.com Mon Aug 24 23:45:31 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F131E1B2A84 for ; Mon, 24 Aug 2015 23:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY7EK5UnONiV for ; Mon, 24 Aug 2015 23:45:26 -0700 (PDT) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056ED1B2A7E for ; Mon, 24 Aug 2015 23:45:26 -0700 (PDT) Received: by laba3 with SMTP id a3so91965317lab.1 for ; Mon, 24 Aug 2015 23:44:39 -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=IJ2wEN1J55ED5hr1fp1JAnpYiuMJDsrUzu3S2y6xIMA=; b=SyqSWEjkLRrOJRaFZxfKQEE+q4zAniOGUPEwFta9MzWItWTGYBZnJcoiP1wB4GXPWS AtwZmxEVU1tNEGu1AkP5NKI3RP+dVrRS4R+QMLNgHmlB0ZpcdnUlZCORpHnY3Yl7zion 8PWp4mmXkoB6u0S2mBYXhC1OPdPE1n/VaJvW60yWD5CwSTLDjm1C82MkXqPshO2uhomU dviVJ6m2rcwwHgBNNA+KTZvyhmh3zTedYaphPYq4Vh6ST21NmvQ7iBhUSEzdvEkfj/Ed 1bZcmfJmH1VOfgNdYjDFW8xcUjYt7CEFL1fiIDBkW6GOnjNxqbvgMKYFtCLh7fm7Kn6V /f2w== MIME-Version: 1.0 X-Received: by 10.152.43.129 with SMTP id w1mr24269400lal.44.1440485079183; Mon, 24 Aug 2015 23:44:39 -0700 (PDT) Received: by 10.112.224.4 with HTTP; Mon, 24 Aug 2015 23:44:39 -0700 (PDT) Date: Tue, 25 Aug 2015 12:14:39 +0530 Message-ID: From: riyaz talikoti To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=001a11c1b70c72f96f051e1d1188 Archived-At: X-Mailman-Approved-At: Tue, 25 Aug 2015 08:00:53 -0700 Subject: [IPsec] IKEv2 PFS, IKE Rekey KE Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 06:51:07 -0000 --001a11c1b70c72f96f051e1d1188 Content-Type: text/plain; charset=UTF-8 Hi All, I have a basic doubt with IKEv2, IKE SA rekey with PFS configured. Sorry for the broadcast mail. I have configured as below IKE proposal DH Group 14 IPSEC Proposal PFS DH Group 2 During INIT EXCHANGE DH Group 14 will be used to calculate KE payload value. and For IPSEC SA's (CHILD SA established as part of CREATE_CHILD_SA EXCHANGE) will use DH 2. and also IPSEC SA REKEY will also use DH2. Now During IKE SA REKEY (CREATE_CHILD_SA EXCHANGE) What DH Group MUST be used? DH14 or DH 2? Thanks Riyaz --001a11c1b70c72f96f051e1d1188 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi = All,
I have a basic doubt with IKEv2, IKE SA rekey with PFS config= ured.
Sorry for the broadcast mail.

I= have configured as below
IKE proposal
DH Group 14
IPSEC Proposal
PFS DH Group 2

During INIT EXCH= ANGE DH Group 14 will be used to calculate KE payload value.

<= div>and For IPSEC SA's (CHILD SA established as part of CREATE_CHILD_SA= EXCHANGE) will use DH 2. and also IPSEC SA REKEY will also use DH2.

Now During IKE SA REKEY (CREATE_CHILD_SA EXCHANGE)
What DH Group MUST be used? DH14 or DH 2?

Thanks
R= iyaz
--001a11c1b70c72f96f051e1d1188-- From nobody Tue Aug 25 08:20:02 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23311B2EE6 for ; Tue, 25 Aug 2015 08:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhIwBKyDbiQq for ; Tue, 25 Aug 2015 08:19:57 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482B11B2F89 for ; Tue, 25 Aug 2015 08:19:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3n0vBg6NDKz272; Tue, 25 Aug 2015 17:19:55 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=NmFLatxK X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ZJJcKsrrt4iJ; Tue, 25 Aug 2015 17:19:55 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 25 Aug 2015 17:19:54 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 16DE18009D; Tue, 25 Aug 2015 11:19:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1440515994; bh=ICP3eLGIhEZ7A/gzMwM/hm88Wp+TcEWe192ZmPlXQZE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=NmFLatxKT4L2boykfLL473/jBlpaZhzI2+k8r10e1luQoULPnVSg1nSJRuYUBEwzC Q1H/bnKVpsqwTiMNzLimt249xuqQ8ThtFeaIwI7R3xNvuZGoKDzlADpD1DQaakkKbH /OeGkh+kmlg1DIDvAhq6G4ckHwpYmMHjN3j8vCHQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t7PFJrUN011287; Tue, 25 Aug 2015 11:19:53 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 25 Aug 2015 11:19:53 -0400 (EDT) From: Paul Wouters To: riyaz talikoti In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] IKEv2 PFS, IKE Rekey KE Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2015 15:20:00 -0000 On Tue, 25 Aug 2015, riyaz talikoti wrote: > I have a basic doubt with IKEv2, IKE SA rekey with PFS configured. > I have configured as below > IKE proposal > DH Group 14 > > IPSEC Proposal > PFS DH Group 2 > During INIT EXCHANGE DH Group 14 will be used to calculate KE payload value. > > and For IPSEC SA's (CHILD SA established as part of CREATE_CHILD_SA EXCHANGE) will use DH 2. and also IPSEC SA REKEY will > also use DH2. > > Now During IKE SA REKEY (CREATE_CHILD_SA EXCHANGE) > What DH Group MUST be used? DH14 or DH 2? It has been brought up before, you can probably find something in the archives. Basically, having a different group for IKE and IPSEC makes no sense in IKEv2. The initial exchange results in both an IKE SA and an IPsec SA. So your configuration doesn not really make sense anymore. Which group should be used for the initial exchange? I think most implementations use the IKE group for the initial exchange (which results in an IPsec SA too!) and the IPsec group for the rekey using the create_child exchange. And also for IKEv1 it did not make much sense either. If the DH of the IPsec SA is broken, you've lost and they can see your traffic. If the DH of the IKE SA is broken, they can create a new IPsec SA of which they will know the KEYMAT, so you still lose and they can see the traffic. So if you break any DH, you win. So whatever is the weakest DH will be attacked. If you think group 2 can be broken, use group 14. If you think group 2 cannot be broken, why use group 14? Paul From nobody Tue Aug 25 22:52:38 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0D01A7021 for ; Tue, 25 Aug 2015 22:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhmSQzI9_sZQ for ; Tue, 25 Aug 2015 22:52:36 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30531A7001 for ; Tue, 25 Aug 2015 22:52:35 -0700 (PDT) Received: by wijn1 with SMTP id n1so12598865wij.0 for ; Tue, 25 Aug 2015 22:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L7YDXs/TeZzoe57hrnPRxmNHURA5aMzLKlCBlA8UXe4=; b=Xst//ys8No8rxcn3pgBWE0UfX+g/3SluVWYIu71pluhUUOpxifXFyo9hFX2qXj4arO 2gL4pmaC2KHAyPdar2p3dPz9xOFfGvPBhLQzaWzi93jO9fuXSRyWBRc9vM/+oSTExg1a nd4Z2x3h1Ym0WaWb62fd+qHP1SFDivRXzEW7zSi2/10MmQn1nLb8XRC2ZCEbg01V4vOR E3l4gagc4OIYkxJVuQPnFA4aaGYJzcaPHPbAUfb0LwYi5kKda3icaqiX9HBrXAWgj8QN eLHh4J7YDI++zzqUAv1/WCT1GSOndjnYSj6nzorfo33T/XKJYnKox9syBTQ5T2wdnMgI Df2A== X-Received: by 10.180.189.17 with SMTP id ge17mr9670748wic.90.1440568354423; Tue, 25 Aug 2015 22:52:34 -0700 (PDT) Received: from [10.4.25.34] ([80.179.9.115]) by smtp.gmail.com with ESMTPSA id fq15sm2088994wjc.12.2015.08.25.22.52.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 22:52:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <21980.23875.397896.822512@fireball.acr.fi> Date: Wed, 26 Aug 2015 08:52:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21980.23875.397896.822512@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My review of draft-nir-ipsecme-curve25519 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 05:52:37 -0000 > On Aug 25, 2015, at 3:19 PM, Tero Kivinen wrote: >=20 > Firstly the name of the draft is bit misleading, as this defines both > curve25519 and Curve448 keys not only curve25519. Agree. Version -00 had only Curve25519 and the name remained. For the WG = draft we can pick a different file name.=20 The title is "New Safe Curves for IKEv2 Key Agreement=E2=80=9D, which I = think is slightly better than the CFRG draft ("Elliptic Curves for = Security=E2=80=9D), but perhaps too generic. Maybe we should follow the = example of the TLS draft (=E2=80=9CCurve25519 and Curve448 for Transport = Layer Security (TLS)=E2=80=9D) and title it =E2=80=9CCurve25519 and = Curve448 for IKEv2 Key Agreement=E2=80=9D. > This document is bit confusing as some of the values are defined as > "strings of 32 octets", some are defined as 255/448-bit numbers having > certain properties (high bit set, n lowest bits unset), but then later > it mixes these. >=20 > For example the public key is defined of "string of 32 octets", but > then section 3.1 says that it is "32 octets encoded as an array of > bytes in little-endian order...". As we are talking about the string > of 32 octets, talking about it being litt-endian is confusing. >=20 > I would assume that section 8 of [CFRG-Curves] would define how to > convert the internal number to 32-octet string, so leaving out the > "little-endian order" from this draft would be clearer. I tried to follow the example of the TLS draft where the public keys are = strings of octets while the private (or =E2=80=9Csecret=E2=80=9D) keys = are numbers. I see that I missed that in section 3.1. How about: OLD: o The Key Exchange Data is 32 octets encoded as an array of bytes in little-endian order as described in section 8 of [CFRG-Curves] NEW: o The Key Exchange Data is a 32-octet public key as described in=20 section 8 of [CFRG-Curves] ...or even... NEW2: o The Key Exchange Data is a 32-octet public key. > In the section 3.2 recipient tests there is discussion about checking > that the public key 32-octet string will have last byte in such way > that high-order bit of it is not set. >=20 > If this is property of the func(d, G) for curve25519, and curve448, > how can we ever get public values having that bit set? So why it is > only SHOULD to reject that public key? I mean if we receive such > public key, that clearly means that other end is either attacker, or > working incorrectly, and we MUST always reject it. >=20 > Or if there is no security issues accepting such public keys, then why > not just say that no checks needs to be done. If we reject such public > key, what behavior should happen in IKE level? Error message, drop > silently? Same as RFC6989? Tough one. The draft says something about implementation fingerprinting, = but if some implementations drop this at the IKE level and some don=E2=80=99= t that=E2=80=99s is a new avenue for fingerprinting. I don=E2=80=99t = know which one is right. In any case, *if* you make the check *and* it = fails *then* it=E2=80=99s appropriate to send an INVALID_SYNTAX = (although I don=E2=80=99t understand why RFC 6989 recommends that over = INVALID_KE_PAYLOAD) notification. > In the security considerations section the 2nd last paragraph only > mentions that Curve25519 explictly, but does not mention curve448. Is > there difference between them, or should the text say "This is widely > seen as a security advantage for these curves, since=E2=80=A6". Nope. Just missed that when extending the document to cover Curve448. > Typos: In section A.1.1 s/mutliplying/multiplying/ >=20 > The test vectors should most likely also include Curve448 test > vectors, and perhaps even full IKEv2 KE payloads=E2=80=A6 Yes. These were copied from the earlier TLS draft. They need some work. Yoav From nobody Tue Aug 25 23:33:57 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97181ACE67 for ; Tue, 25 Aug 2015 23:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpVdVvv8TuWa for ; Tue, 25 Aug 2015 23:33:55 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 742AD1A8A06 for ; Tue, 25 Aug 2015 23:33:55 -0700 (PDT) Received: by widdq5 with SMTP id dq5so5134705wid.0 for ; Tue, 25 Aug 2015 23:33:54 -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=STPwweETELgvjR36i2gRUqJxmqW/oSjx1czd7eRcMtA=; b=ZfPsvhG+ZmdlIiUqvVFWt2ElonW98ufG/qXfVtn+o233TwyRveG+uhqImXsIf9kdG4 DnjU+SMX9V/mcGCsFbnvUcz8GBgNacvhtxQ5/vuYHnaP+HAunS/V9sT6sgS1LU7JpS0T H479CO2kxJTAfJ4/5X2NcfHNLz5fTV0Dzft+AOhkKdkaCQ3Zzs4q0VLpxJq0a1ziGFvy vpVCasqH4Izaak5BoxKfvARkZ11FrPtq0u+NDJvu4Y38W8fi6T1qUOMjrx0BZSsmfGPG IF14VUEiv7AwGhRl5ueNaROxX8cGSBWbo1rkMGSL4bzs6ZPycMl8K7H8vQjUJFHRVWUo W3gA== X-Received: by 10.180.80.138 with SMTP id r10mr1623027wix.18.1440570834139; Tue, 25 Aug 2015 23:33:54 -0700 (PDT) Received: from [192.168.1.104] (84.94.199.17.cable.012.net.il. [84.94.199.17]) by smtp.googlemail.com with ESMTPSA id en5sm5946904wib.18.2015.08.25.23.33.52 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2015 23:33:53 -0700 (PDT) Message-ID: <55DD5DCF.7050805@gmail.com> Date: Wed, 26 Aug 2015 09:33:51 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Yoav Nir , Tero Kivinen References: <21980.23875.397896.822512@fireball.acr.fi> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My review of draft-nir-ipsecme-curve25519 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 06:33:56 -0000 >> In the section 3.2 recipient tests there is discussion about checking >> that the public key 32-octet string will have last byte in such way >> that high-order bit of it is not set. >> >> If this is property of the func(d, G) for curve25519, and curve448, >> how can we ever get public values having that bit set? So why it is >> only SHOULD to reject that public key? I mean if we receive such >> public key, that clearly means that other end is either attacker, or >> working incorrectly, and we MUST always reject it. >> >> Or if there is no security issues accepting such public keys, then why >> not just say that no checks needs to be done. If we reject such public >> key, what behavior should happen in IKE level? Error message, drop >> silently? Same as RFC6989? > > Tough one. The draft says something about implementation fingerprinting, but if some implementations drop this at the IKE level and some don’t that’s is a new avenue for fingerprinting. I don’t know which one is right. In any case, *if* you make the check *and* it fails *then* it’s appropriate to send an INVALID_SYNTAX (although I don’t understand why RFC 6989 recommends that over INVALID_KE_PAYLOAD) notification. > RFC 6989 recommends INVALID_SYNTAX because per RFC 7296, INVALID_KE_PAYLOAD is used for cases where the initiator is expected to retry the exchange. Incorrect DH values are at best a bug and at worst an attack, and should not result in an automatic retry. Thanks, Yaron From nobody Tue Aug 25 23:38:42 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A001A1A21B5 for ; Tue, 25 Aug 2015 23:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.47 X-Spam-Level: * X-Spam-Status: No, score=1.47 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Bw8EG02Z9Kt for ; Tue, 25 Aug 2015 23:38:39 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE701A21A5 for ; Tue, 25 Aug 2015 23:38:39 -0700 (PDT) Received: by lbbpu9 with SMTP id pu9so113931295lbb.3 for ; Tue, 25 Aug 2015 23:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=cMcUv9B7D0e0bCYvZOPiUCRHlRioQpkHjaQJ+x0JQh4=; b=Sg90H6pxhpN7o5rpO+cgl7kpar4dSEBdWdSStsUfb/HtXu60zzEW/igc4E2eb+JVE5 DXCxhvr5sltAiWUjG/G/pnMRfiMAJQIgGoMwpbPZDjMZu9Rhi3f3xn25HapGnjh5fHjC LJEGrehMbnOtjLS0UoYnd989K4uyaijjVXGnYsbdI2y3HdmMSxzWEguKu5pcWSiSDovH y3Lw7Qt/Lrq73r6WHvA7PVGTpPk8C8RfKaJs4IXMmTOn70ep2Y7OKFTueoJlEyK8YwIX Gr5P/V6kKwEuPcA3kV8QRXb3Hc3Ts9QxJQ1RlioyZrkNgc1vSvKdT5LlRNZktVuGWesl yDBA== X-Received: by 10.112.139.133 with SMTP id qy5mr28874427lbb.60.1440571117564; Tue, 25 Aug 2015 23:38:37 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id kx11sm6494090lac.41.2015.08.25.23.38.36 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 25 Aug 2015 23:38:36 -0700 (PDT) Message-ID: <74A0C04C0800493BB38303786AEC7137@buildpc> From: "Valery Smyslov" To: "Paul Hoffman" , "IPsecME WG" References: Date: Wed, 26 Aug 2015 09:38:33 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Subject: Re: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WGwork item X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 06:38:40 -0000 Hi, I support adopting this document. Regards, Valery Smyslov. > Greetings. There was some general interest in having a standard way to > modern elliptic curves for ephemeral key exchange. Please respond in > this thread whether or no you think this document is a good start on > that work, and whether or not you think the WG should have this as a > work item. > > --Paul Hoffman > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Aug 25 23:38:50 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DB51A8932 for ; Tue, 25 Aug 2015 23:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ll1HmrvatuJE for ; Tue, 25 Aug 2015 23:38:48 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08361A21B5 for ; Tue, 25 Aug 2015 23:38:47 -0700 (PDT) Received: by wicja10 with SMTP id ja10so34364632wic.1 for ; Tue, 25 Aug 2015 23:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tEgqSMsV0tuZgzMYHimieEoFb3Y94d3RGFxgK/vWPHA=; b=re08knlcVr+KuqAXVPc/0/TekmCuIfvN3CU/0BUtkivHo3sia8URvK1dMIKB2mpKbF 6BMDd11G5T6R9PBC6CI8ieHd4AQAcF2CMpnt+jroyMYQIvjftVE94JF2ULBaylvo8NnL WvDy/vLNkxo57qlAa1aHhGqCEZdHZLON4xyeVdQ+adCsXnzVRQuJCbmLCG7zW7xwnOtb hynM/VKvuUnmKVQHQLJBNYYDfMO7oPd6Sg2J/fTNirO91EsS1o+X0dUxPNz3iq9IWyCq Tw7dtnTdCZADVZsFil1GsdYB7wWAGfahjl8Dxqv+jv2YRcLZIS5L4rF5+oAmM9Njc8rH 16vQ== X-Received: by 10.180.211.168 with SMTP id nd8mr10405052wic.23.1440571126523; Tue, 25 Aug 2015 23:38:46 -0700 (PDT) Received: from [172.24.248.148] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id ik8sm2247805wjb.8.2015.08.25.23.38.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Aug 2015 23:38:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <55DD5DCF.7050805@gmail.com> Date: Wed, 26 Aug 2015 09:38:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21980.23875.397896.822512@fireball.acr.fi> <55DD5DCF.7050805@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] My review of draft-nir-ipsecme-curve25519 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 06:38:49 -0000 > On Aug 26, 2015, at 9:33 AM, Yaron Sheffer = wrote: >=20 >>> In the section 3.2 recipient tests there is discussion about = checking >>> that the public key 32-octet string will have last byte in such way >>> that high-order bit of it is not set. >>>=20 >>> If this is property of the func(d, G) for curve25519, and curve448, >>> how can we ever get public values having that bit set? So why it is >>> only SHOULD to reject that public key? I mean if we receive such >>> public key, that clearly means that other end is either attacker, or >>> working incorrectly, and we MUST always reject it. >>>=20 >>> Or if there is no security issues accepting such public keys, then = why >>> not just say that no checks needs to be done. If we reject such = public >>> key, what behavior should happen in IKE level? Error message, drop >>> silently? Same as RFC6989? >>=20 >> Tough one. The draft says something about implementation = fingerprinting, but if some implementations drop this at the IKE level = and some don=E2=80=99t that=E2=80=99s is a new avenue for = fingerprinting. I don=E2=80=99t know which one is right. In any case, = *if* you make the check *and* it fails *then* it=E2=80=99s appropriate = to send an INVALID_SYNTAX (although I don=E2=80=99t understand why RFC = 6989 recommends that over INVALID_KE_PAYLOAD) notification. >>=20 >=20 > RFC 6989 recommends INVALID_SYNTAX because per RFC 7296, = INVALID_KE_PAYLOAD is used for cases where the initiator is expected to = retry the exchange. Incorrect DH values are at best a bug and at worst = an attack, and should not result in an automatic retry. Ah. Makes sense. Section 2.5 has the string =E2=80=9Cinvalid KE = payload=E2=80=9D several times, so it looked strange. Yoav From nobody Wed Aug 26 07:24:35 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC431B2E02 for ; Wed, 26 Aug 2015 07:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJUa8CCBJCjb for ; Wed, 26 Aug 2015 07:24:33 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DE961B2F51 for ; Wed, 26 Aug 2015 07:21:42 -0700 (PDT) Received: from [192.168.114.1] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t7QELf1Q063815 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Aug 2015 07:21:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [192.168.114.1] From: "Paul Hoffman" To: "IPsecME WG" Date: Wed, 26 Aug 2015 07:21:40 -0700 Message-ID: <766C5C5E-73AA-48DD-A6F5-68A1EC29A739@vpnc.org> References: <20150826135917.947.37928.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [IPsec] Fwd: Last Call: (More Raw Public Keys for IKEv2) to Internet Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Aug 2015 14:24:34 -0000 Of interest to this WG. This is an individual submission, not a WG item, so comments should be sent as described in the announcement. Forwarded message: > From: The IESG > To: IETF-Announce > Subject: Last Call: (More > Raw Public Keys for IKEv2) to Internet Standard > Date: Wed, 26 Aug 2015 06:59:17 -0700 > > > The IESG has received a request from an individual submitter to > consider > the following document: > - 'More Raw Public Keys for IKEv2' > as Internet Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-09-23. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > The Internet Key Exchange Version 2 (IKEv2) protocol currently only > supports raw RSA keys. In constrained environments it is useful to > make use of other types of public keys, such as those based on > Elliptic Curve Cryptography. This documents adds support for other > types of raw public keys to IKEv2. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-oob-pubkey/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Wed Aug 26 19:55:10 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 886751A8861; Wed, 26 Aug 2015 19:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GlQQl7efm1C; Wed, 26 Aug 2015 19:55:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 268511A87B2; Wed, 26 Aug 2015 19:55:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1530D18046D; Wed, 26 Aug 2015 19:54:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150827025452.1530D18046D@rfc-editor.org> Date: Wed, 26 Aug 2015 19:54:52 -0700 (PDT) Archived-At: Cc: ipsec@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org Subject: [IPsec] RFC 7619 on The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2015 02:55:08 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7619 Title: The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2) Author: V. Smyslov, P. Wouters Status: Standards Track Stream: IETF Date: August 2015 Mailbox: svan@elvis.ru, pwouters@redhat.com Pages: 12 Characters: 24593 Updates: RFC 4301 I-D Tag: draft-ietf-ipsecme-ikev2-null-auth-07.txt URL: https://www.rfc-editor.org/info/rfc7619 DOI: http://dx.doi.org/10.17487/RFC7619 This document specifies the NULL Authentication method and the ID_NULL Identification Payload ID Type for Internet Key Exchange Protocol version 2 (IKEv2). This allows two IKE peers to establish single-side authenticated or mutual unauthenticated IKE sessions for those use cases where a peer is unwilling or unable to authenticate or identify itself. This ensures IKEv2 can be used for Opportunistic Security (also known as Opportunistic Encryption) to defend against Pervasive Monitoring attacks without the need to sacrifice anonymity. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Fri Aug 28 04:36:42 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090C81B307F for ; Fri, 28 Aug 2015 04:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkZD0EZMY9EO for ; Fri, 28 Aug 2015 04:36:39 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A533C1B2FF2 for ; Fri, 28 Aug 2015 04:36:38 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t7SBIYNR008740 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Aug 2015 14:18:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t7SBIYX7012480; Fri, 28 Aug 2015 14:18:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <21984.17290.12598.128450@fireball.acr.fi> Date: Fri, 28 Aug 2015 14:18:34 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: <21980.23875.397896.822512@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] My review of draft-nir-ipsecme-curve25519 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 11:36:41 -0000 Yoav Nir writes: > The title is "New Safe Curves for IKEv2 Key Agreement=E2=80=9D, which= I > think is slightly better than the CFRG draft ("Elliptic Curves for > Security=E2=80=9D), but perhaps too generic. Maybe we should follow t= he > example of the TLS draft (=E2=80=9CCurve25519 and Curve448 for Transp= ort > Layer Security (TLS)=E2=80=9D) and title it =E2=80=9CCurve25519 and C= urve448 for > IKEv2 Key Agreement=E2=80=9D. That title looks good. > I tried to follow the example of the TLS draft where the public keys > are strings of octets while the private (or =E2=80=9Csecret=E2=80=9D)= keys are > numbers. I see that I missed that in section 3.1. How about:=20 >=20 > OLD: > o The Key Exchange Data is 32 octets encoded as an array of bytes= in > little-endian order as described in section 8 of [CFRG-Curves] > NEW: > o The Key Exchange Data is a 32-octet public key as described in=20= > section 8 of [CFRG-Curves] I think this is better, i.e. keep the reference. > > In the section 3.2 recipient tests there is discussion about checki= ng > > that the public key 32-octet string will have last byte in such way= > > that high-order bit of it is not set. > >=20 > > If this is property of the func(d, G) for curve25519, and curve448,= > > how can we ever get public values having that bit set=3F So why it = is > > only SHOULD to reject that public key=3F I mean if we receive such > > public key, that clearly means that other end is either attacker, o= r > > working incorrectly, and we MUST always reject it. > >=20 > > Or if there is no security issues accepting such public keys, then = why > > not just say that no checks needs to be done. If we reject such pub= lic > > key, what behavior should happen in IKE level=3F Error message, dro= p > > silently=3F Same as RFC6989=3F >=20 > Tough one. The draft says something about implementation > fingerprinting, but if some implementations drop this at the IKE > level and some don=E2=80=99t that=E2=80=99s is a new avenue for finge= rprinting. Yep. > I don=E2=80=99t know which one is right. In any case, *if* you make t= he > check *and* it fails *then* it=E2=80=99s appropriate to send an > INVALID=5FSYNTAX (although I don=E2=80=99t understand why RFC 6989 re= commends > that over INVALID=5FKE=5FPAYLOAD) notification. If we would use INVALID=5FKE=5FPAYLOAD then we would need to send list of acceptable groups in it, and it would be stupid to say that when other end is using group X, that INVALID=5FKE=5FPAYLOAD(use group X)... INVALID=5FSYNTAX tells that other end something that was invalid from the protocol point of view, i.e. in this case it sent payload which had bit set, where standard says it MUST not be set. I think we either should say MUST, or MUST NOT (I do not really care which one), but not SHOULD... --=20 kivinen@iki.fi From nobody Fri Aug 28 05:00:21 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655ED1A9218 for ; Fri, 28 Aug 2015 05:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2udDCJgzBzkN for ; Fri, 28 Aug 2015 05:00:19 -0700 (PDT) Received: from mail.strongswan.org (sitav-80046.hsr.ch [IPv6:2001:620:130:a080::46]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E12CD1B2F73 for ; Fri, 28 Aug 2015 04:58:47 -0700 (PDT) Received: from [IPv6:2001:1620:f7b:1:c030:b95f:87d9:24b6] (unknown [IPv6:2001:1620:f7b:1:c030:b95f:87d9:24b6]) by mail.strongswan.org (Postfix) with ESMTPSA id 4F09240126; Fri, 28 Aug 2015 13:58:46 +0200 (CEST) Message-ID: <55E04CF5.20108@strongswan.org> Date: Fri, 28 Aug 2015 13:58:45 +0200 From: Andreas Steffen User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Paul Hoffman , IPsecME WG References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060805060605070406020303" Archived-At: Subject: Re: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:00:20 -0000 This is a cryptographically signed message in MIME format. --------------ms060805060605070406020303 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Paul, I'm in favour of adopting this document. Best regards Andreas Steffen On 25.08.2015 00:58, Paul Hoffman wrote: > Greetings. There was some general interest in having a standard way to > modern elliptic curves for ephemeral key exchange. Please respond in > this thread whether or no you think this document is a good start on > that work, and whether or not you think the WG should have this as a > work item. > > --Paul Hoffman =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Open Source VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D[ITA-HSR]=3D=3D --------------ms060805060605070406020303 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMhDCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGSDCCBTCgAwIBAgIDC0oMMA0GCSqGSIb3DQEB CwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwOTIyMTc0MjM0 WhcNMTUwOTIzMTYyNzUyWjBYMScwJQYDVQQDDB5hbmRyZWFzLnN0ZWZmZW5Ac3Ryb25nc3dh bi5vcmcxLTArBgkqhkiG9w0BCQEWHmFuZHJlYXMuc3RlZmZlbkBzdHJvbmdzd2FuLm9yZzCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALTWE8Ab5LeaiLpYD1vLjg3OM11mc8CC t2h2gdZGpCg5Yv9awYOy1zd8VlXPoOnVtnk2yiXrT9wnz5iZthKfiaqh0fgd18G43svQYuto nFJX+G0BldOkTWDobhbYc9aGzl927+XDcIf/zMaZOiZXsU4ErCOnhumq4zUNtJX1kFh/haow CSj4HPI5MDzRLCGPcngE/XKLmSRLaXnBo+BO1AEmSzysCgihNnwxFxpqfm39X1WlharG0wJy JGXqgXAuXZ7jh2pDH8A9Ww8G4gxv58iiY5VW5wsfiPmbWwQsbIDIXXq6gFKRKi9zWeqchV5r JW/g/JFw0AFCqgAkmJwtowkCAwEAAaOCAuQwggLgMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUF3XH/qcfHMgVFp7S 4EH1ZE157+8wHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwKQYDVR0RBCIwIIEe YW5kcmVhcy5zdGVmZmVuQHN0cm9uZ3N3YW4ub3JnMIIBTAYDVR0gBIIBQzCCAT8wggE7Bgsr BgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRv IHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBD QSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNv bXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0w K6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUF BwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xh c3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3Rh cnRzc2wuY29tLzANBgkqhkiG9w0BAQsFAAOCAQEAC5bWzDjemB04RK3lLPYsMhvYGUg58HL6 SUlMl6yZm8VSG5Y3VDgJPLSrpLdGpXJwwP+d7kJ1zxETcd7/ouoXLTcSkTeglnZemEV8M6wd DNPuGCc3klL7g2hWH22F0/OZkgY/HMMLtpPQcGyAzh83qr2ISJPBY9Pw6tqVOKGIKB/EhQey rZkMtYuAO6TlKYIwO0FZxqB+Ot1Cp8ocwwzXe504eD+MHAdR8Ikz1hh4KyEqn/p7DBeYhrhY 7ZsCEkRf8eb8ckiJ2XzY/sDmmgby/toBx3m2XISu38Qfu2BdCFdMbBjr9ZcnYMjit+XdNmvT uCNgX3k/cGlTa7scuAkc8DGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0ECAwtKDDAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA4MjgxMTU4NDVaMCMGCSqGSIb3DQEJBDEWBBTbUEMw PlaW7EVXSWw1d+oZcsSYHTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDC0oMMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLSgwwDQYJKoZIhvcNAQEBBQAEggEALLP2 XXeCeoW6mr4r0DP8j7NNcQoD/Q1yHKT2uiTbB0AnFCI52vlv1i4mB3s7kdcxTVaoUsr/hw/c m471YJwWe3lFMv9DuHLZ9AoQSlOwTDqoGsJAfSIlPtuJuKQPCVj34DdID4ACxbcq99wOIu/t E5vKNKH8mrNC5aEcbnJ71dK8sbnHqcW7t5BS4WWJI2jW6eFO8uslMO/VqEhmHheKRJDObqwx tF8iTs52asE2thzNAM6nv11qKuP3mlkvcgU2ykTEHS26ZTsC68V0ElBfacqwBeo1Mg7GoCg/ Gkg1LdZC6tjNM4kPzIahTD9wm3okPa0pVWtp+JbN2kbyRDC3WwAAAAAAAA== --------------ms060805060605070406020303--