From nobody Mon Mar 3 01:41:09 2014 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 9C73B1A0C25; Mon, 3 Mar 2014 01:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Di4suZsCZmbw; Mon, 3 Mar 2014 01:41:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F15F1A03FC; Mon, 3 Mar 2014 01:41:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303094105.4810.38295.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 01:41:05 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/BddJaNYe5--TZyQ18OX1c5A8RKw Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:41:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Wajdi Feghali Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-02.txt Pages : 11 Date : 2014-03-03 Abstract: This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 3 02:50:18 2014 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 097EA1A0CEC for ; Mon, 3 Mar 2014 02:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, 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 RnOLNNFL6VUV for ; Mon, 3 Mar 2014 02:50:14 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id D3BC71A0E2E for ; Mon, 3 Mar 2014 02:50:12 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id c11so4451268lbj.40 for ; Mon, 03 Mar 2014 02:50:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:subject:date:mime-version:content-type :content-transfer-encoding; bh=2el2kFl6aEz0AZL+6fb/LepfkTR/v4r6bThB0eWEmHg=; b=ClkehkujUhwbOdOgLrLb9R4WEITIsRxpXdx0vqnT7pzSAi7mOzBftPKv7UYSJ/27QO ea5reguowHjGDjAOJ4joYuSja8MPUW2jh3jwN+4NfjGF5WTARabXLGurYfWBt0gPal2h f1oqsBXq8LiluspjsKWJT1RKMY7+6CHf4i9zR4qDCsZjhFmiMwDtZ51R4ADl5mKyXlZq XSu4ViXXvEY9ggh/M4Xjj1Nc/7ARphx+j3RI1Ii1oc1TRYJRqoW1cOILME84+ZbL2gf0 TT9LgcputRuDLwYQ9T6ESFleKUI6SVUEyWc3Ke6VeAmThrde017QTWQ9BgcEOkyVHCRa by8A== X-Received: by 10.152.87.228 with SMTP id bb4mr22853112lab.15.1393843809404; Mon, 03 Mar 2014 02:50:09 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id y2sm29352850lal.10.2014.03.03.02.50.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 02:50:07 -0800 (PST) Message-ID: From: "Valery Smyslov" To: Date: Mon, 3 Mar 2014 14:50:20 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/KcFcK7k8HFco_-JQ52v8bzl6qzo Subject: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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, 03 Mar 2014 10:50:16 -0000 Hi all, I've posted new version of the NULL Auth Method draft. It addresses comments received from Yaron Sheffer and Paul Wouters. Regards, Valery Smyslov. ----- Original Message ----- From: To: "Valery Smyslov" ; "Valery Smyslov" Sent: Monday, March 03, 2014 2:41 PM Subject: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.txt > > A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-01.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-smyslov-ipsecme-ikev2-null-auth > Revision: 01 > Title: The NULL Authentication Method in IKEv2 Protocol > Document date: 2014-03-03 > Group: Individual Submission > Pages: 9 > URL: > http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-null-auth-01.txt > Status: > https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-null-auth/ > Htmlized: > http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-smyslov-ipsecme-ikev2-null-auth-01 > > Abstract: > This document defines the NULL Authentication Method for the IKEv2 > Protocol. This method provides a way to omit peer authentication in > IKEv2 and to explicitely indicate it in the protocol run. This > method may be used to preserve anonymity or in situations, where no > trust relationship exists between the parties. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > From nobody Mon Mar 3 03:45:49 2014 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 4F37B1A000D for ; Mon, 3 Mar 2014 03:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 XI81Pj-n-She for ; Mon, 3 Mar 2014 03:45:45 -0800 (PST) Received: from mail-ie0-x243.google.com (mail-ie0-x243.google.com [IPv6:2607:f8b0:4001:c03::243]) by ietfa.amsl.com (Postfix) with ESMTP id C6F161A0007 for ; Mon, 3 Mar 2014 03:45:44 -0800 (PST) Received: by mail-ie0-f195.google.com with SMTP id lx4so890904iec.2 for ; Mon, 03 Mar 2014 03:45:42 -0800 (PST) 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=ZiACgZnll+6o1W/t3Vig7BwsBorVVSaQtbsoCMmu7cg=; b=tECoEtKOW7iNFpyH/9BvZltijS7DHZbrHFu1+1k2TaZwQQPKpJ2Xec7vNKhG36NVx4 sc/3nqVml0b5M+YIRLH1n27CJIc4pnUgXxKItYn64fxe+uLlQGmDrI/BQiAOAwW/Wy7H g3sRx/mdjY9BZN5nZmg1w2SSfic2yzShiADHyHMok4usYM3SGKQnHb+0sTWq+R0tJD+S VksB9evO1Ii6qZS8/YpHoUVSEFntgVuqE50FsKo+4BpmrBtBvfJ16S8saHg3baHBj1ZK 0xl7tpGYR5+jZhjrjmYsMfjm+c7vQy/jj+be4La4umB0gGTAAUkZRP2lWhMs87SN0ZX+ krqA== MIME-Version: 1.0 X-Received: by 10.42.254.3 with SMTP id nc3mr974026icb.67.1393847141767; Mon, 03 Mar 2014 03:45:41 -0800 (PST) Received: by 10.50.40.131 with HTTP; Mon, 3 Mar 2014 03:45:41 -0800 (PST) In-Reply-To: References: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> Date: Mon, 3 Mar 2014 12:45:41 +0100 Message-ID: From: Daniel Palomares To: Valery Smyslov Content-Type: multipart/alternative; boundary=bcaec51593e3c19ec904f3b253e5 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/eo_9yblQ7j2InaJnjsiHhcbhSQY Cc: IPsecme WG Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition 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, 03 Mar 2014 11:45:48 -0000 --bcaec51593e3c19ec904f3b253e5 Content-Type: text/plain; charset=ISO-8859-1 Thank you for your comments Valery. *From:* Daniel Palomares > *To:* Valery Smyslov > *Cc:* IPsecme WG > *Sent:* Thursday, February 27, 2014 10:16 PM > *Subject:* Re: [IPsec] Draft: IKEv2/IPsec Context Definition > > Hello Valery, > > Thanks for commenting on the draft . > > >> Then, I've been always thinking that the content of the IKE/IPsec SA is >> an implementation issue. The draft tries to mandate this content, >> but it lacks plenty of absolutely needed information (this is especially >> true >> for IKE SA), like MID counters, window bitmaps, lifetimes, credential >> information, >> VIDs, features, statistics and so on. >> > > Yeah, in the lists of the IKE_SA/IPsec_SA parameters, some information was > missing, but they actually appear in the structure example on the Appendix. > These parameters, together with those pointed out by Yogendra in previous > comments, are explicitly added in their corresponding sections. > > Sorry, I still couldn't find in IKEV2CONTEXT structure neither next_mid, > nor next_expected_mid, nor window_bitmap etc. All this parameters > are mandatory for IKEv2 to work properly. > You are right, and thank you for pointing that out. The window bitmap was missing. I added in the following version of the draft. Even though I implemented a testbed, I forgot to add it on the draft. On the other hand, I have a question concerning the netxt_mid or next_expected_mid. Are you talking about the message's ID? If yes, they are added already as part of the IKEv2 parameters as well in version 01. I will publish it in a few hours. > > > On the other hand, the draft tries to mandate one way of presenting some > data, > >> ignoring the fact that it is not the only (and probably not the best) >> way. For example, >> instead of transferring nonces and DH secret to the other node one may >> transfer computed SK_* keys. This approach may have some advantages both >> from security and performance perspectives. >> > > We actually think sending keys is one quick way to build an > IKE_SA/IPsec_SA. As I said before, all the keys SK_* were included in the > Appendix but are missing within the lists in sections 4 and 5. They are > added in the following version of the draft -01. > > We also included three different level of parameters in order to classify > their relevance: *Mandatory, Optional or Vendor Specific*. > Note that the draft does not intend to define the format for transferring > the parameters/contexts. The draft actually identifies each parameter that > MUST be included to maintain the IKE_SA/IPsec_SA alive. To classify the > relevance of the parameter, it can be defined as Mandatory (M), Optional > (O) or Vendor Specific (V). > > I have one question concerning about comment concerning the keys (SK_*), : > A node can send all the keys (SK_*) to avoid their recalculation in the > other node, ignoring the Nonces and DH secret. However, ignoring Nonces > might lead to the impossibility of REKYING crypto material. Please correct > me if I'm wrong. So my question is: > Are you proposing to add all SK_* together with the Nonce and DH > information? Or, do you think that sending all keys might be enough > (ignoring Ni, Nr and DH-related information)? > > Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED, > SK_*, keymat for Child SA and AUTH payload content.Anyway, once the > exchange > is complete, the nonces, appeared in this exchange, may be discarded. > > Actually, you have 3 choices to exchange IKEv2 keying information between > nodes in cluster: > 1. Send your private DH key, peer's KE content and nonces. In this case > other nodes will recalculate all keys from the very beginning. > 2. Send SKEYSEED and nonces. > 3. Send computed SK_* keys. Note. that you even may omit sending SK_p*, as > these > keys are used only during authentication (unless you implement Session > Resumption, > but it also depends on how you store the tickets - by value or by > reference). > > I appreciate your comments concerning the keys SK_* . We actually defined three additional flags for each parameter depending on their relevance/usage: mandatory, optional or vendor specific. However, if you don't mind, I will also add your comments to the draft as part of the key management. In fact, when sending all SK_* (using a mandatory flag), then Nonces, KE, and DH key become optional. But I will clarify this in version -01 of the draft too. > All approaches are equally possible. There seems to be some > security and performance benefists for approach 3, but somebody > may argue. Implementation may use any of this approaches > and I don't think it's good to mandate the only approach, > > By now, we only wish to agree in the parameters that should be transmitted concerning the IKEv2 and IPsec contexts. Following steps would be to define a format for transferring such data. One could think in JSON format?. I agree that one should not mandate how applications will implement such solutions, but in order to reach interoperability between different constructors, then we need to define this. Kind Regards, Daniel PALOMARES, Regards, > Valery. > > > > > > Kind Regards, > Daniel Palomares > > > >> > Regards, >> Valery Smyslov. >> >> >> ----- Original Message ----- >> *From:* Daniel Palomares >> *To:* ipsec@ietf.org >> *Sent:* Thursday, February 13, 2014 6:09 PM >> *Subject:* [IPsec] Draft: IKEv2/IPsec Context Definition >> >> Hi, >> >> Please find a draft we have Posted. They concern the definition of IKEv2 >> and IPsec contexts. >> Comments are welcome, >> >> BR, >> >> Daniel Palomares >> >> >> >> >> >> Name: draft-plmrs-ipsecme-ipsec-ikev2-context-definition. >> >> Revision: 00 >> Title: IKEv2/IPsec Context Definition >> Document date: 2014-02-12 >> Group: Individual Submission >> Pages: 8 >> URL: >> http://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-definition/ >> Htmlized: >> http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 >> >> >> Abstract >> >> IPsec/IKEv2 clusters are constituted of multiple nodes accessed via a >> single address by the end user. The traffic is then split between >> the nodes via specific IP load balancing policies. Once a session is >> assigned to a given node, IPsec makes it difficult to assign the >> session to another node. This makes management operations and >> transparent high availability for end users difficult to perform >> within the cluster. >> >> This document describes the contexts for IKEv2 and IPsec that MUST be >> transferred between two nodes so a session can be restored. This >> makes possible to transfer an IPsec session transparently to the end >> user. >> >> >> >> *Daniel* *PALOMARES* >> >> *Orange Labs, Issy-les-Moulineaux* >> >> +33 6 34 23 07 88 >> >> ------------------------------ >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --bcaec51593e3c19ec904f3b253e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you for your comments Valery.

Sent: Thursday, February 27, 2014 1= 0:16=20 PM
Subject: Re: [IPsec] Draft: IKEv2/I= Psec=20 Context Definition

Hello Valery,

Thanks for commenting on the draft= =20 .
=A0
Then, I've been always thinking that the con= tent of the=20 IKE/IPsec SA is
an implementation issue. The draft tries to mand= ate this=20 content,
but it lacks plenty of absolutely needed informa= tion=20 (this is especially true
for IKE SA), like MID counters, window bitmaps,= =20 lifetimes, credential information,
VIDs, features, statist= ics and so=20 on.

Yeah, in the lists of the IKE_SA/IPsec_SA parameters, some informati= on=20 was missing, but they actually appear in the structure example on the=20 Appendix. These parameters, together with those pointed out by Yogendra i= n=20 previous comments, are explicitly added in their corresponding sections.= =20
Sorry, I still couldn't fi= nd in=20 IKEV2CONTEXT structure neither next_mid,
nor next_expected_mid, nor=20 window_bitmap etc. All this parameters
are mandatory for IKEv2 to wor= k=20 properly.

You are right, and thank you for pointing that = out. The window bitmap was missing. I added in the following version of the= draft. Even though I implemented a testbed, I forgot to add it on the draf= t.
On the other hand, I have a question concerning the netxt_mid or= next_expected_mid. Are you talking about the message's ID? If yes, the= y are added already as part of the IKEv2 parameters as well in version 01. = I will publish it in a few hours.
=A0
=A0
On the other hand, the draft tries to=20 mandate one way of presenting some data,
ignoring the fact that = it is not the=20 only (and probably not the best) way. For example,
instead of=A0transferring nonces and DH secret t= o the=20 other node one may
transfer computed SK_* keys. This=20 approach=A0may have=A0some advantages both
from security and perfo= rmance=20 perspectives.

We actually think sending keys is one quick way to build an=20 IKE_SA/IPsec_SA.=A0 As I said before, all the keys SK_* were included in= =20 the Appendix but are missing within the lists in sections 4 and 5. They a= re=20 added in the following version of the draft -01.

We also included = three=20 different level of parameters in order to classify their relevance:=20 Mandatory, Optional or Vendor Specific.
Note that the draft does not intend to define the format for transfe= rring=20 the parameters/contexts. The draft actually identifies each parameter tha= t=20 MUST be included to maintain the IKE_SA/IPsec_SA alive. To classify the= =20 relevance of the parameter, it can be defined as Mandatory (M), Optional = (O)=20 or Vendor Specific (V).

I have one question concerning about comment concerning the keys (SK= _*),=20 :
A node can send all the keys (SK_*) to avoid their recalculation in = the=20 other node, ignoring the Nonces and DH secret. However,=A0 ignoring Nonce= s=20 might lead to the impossibility of REKYING crypto material. Please correc= t me=20 if I'm wrong. So my question is:
Are you proposing to add all SK_= *=20 together with the Nonce and DH information? Or, do you think that sending= all=20 keys might be enough (ignoring Ni, Nr and DH-related=20 information)?
Sending SK_* is enough. Nonces are used only i= n=20 calculations of SKEYSEED,
SK_*, keymat for Child SA and AUTH payload=20 content.Anyway, once the exchange
is complete, the nonces, appeared in this exchange,= =20 may be discarded.
=A0
Actually, you have 3 choices to exchange IKEv2 keyin= g=20 information between nodes in cluster:
1. Send your private DH key, peer's KE content a= nd=20 nonces. In this case
=A0=A0=A0 other nodes will recalculate all=20 keys from the very beginning.
2. Send SKEYSEED and nonces.
3. Send computed SK_* keys. Note. that you even may= =20 omit sending SK_p*, as these
=A0=A0=A0 keys are used only during=20 authentication (unless you implement=A0Session=20 Resumption,
=A0=A0=A0 but it also depends on how you=20 store the tickets - by value or by reference).
=A0

I appreciate your comments concerning the keys SK_* . We actually define= d three additional=A0 flags for each parameter depending on their relevance= /usage: mandatory, optional or vendor specific. However, if you don't m= ind, I will also add your comments to the draft as part of the key manageme= nt. In fact, when sending all SK_* (using a mandatory flag), then Nonces, K= E, and DH key become optional. But I will clarify this in version -01 of th= e draft too.
=A0
All approaches are equally possible. There seems to = be=20 some
security and performance benefists for approach 3, b= ut=20 somebody
may argue. Implementation may use any of this=20 approaches
and I don't think it's good to mandate the o= nly=20 approach,
=A0
=A0
By now, we o= nly wish to agree in the parameters that should be transmitted concerning t= he IKEv2 and IPsec contexts. Following steps would be to define a format=A0= for transferring such data. One could think in JSON format?. I agree that = one should not mandate how applications will implement such solutions, but = in order to reach interoperability between different constructors, then we = need to define this.
=A0

Kind Regards,
Daniel PALOMARES,

=

Regards,
Valery.



=A0
Kind Regards,
Daniel Palomares<= br>


=A0
Regards,
Valery Smyslov.
=A0
----- Original Message -----
Sent: Thursday, February 13, 20= 14=20 6:09 PM
Subject: [IPsec] Draft: IKEv2/I= Psec=20 Context Definition

Hi,

Please find a draft we have Posted. They concern the=20 definition of IKEv2 and IPsec contexts.
Comments are=20 welcome,

BR,

Daniel Palomares

=A0

=A0

Name: =A0 =A0 =A0=A0=20 draft-plmrs-ipsecme-ipsec-ikev2-context-definition.

Revision:=20 00
Title: =A0 =A0 =A0 IKEv2/IPsec Context=20 Definition
Document date: =A0 =A02014-02-12
Group: =A0=20 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0=20 =A0=A0 8
URL:ht= tp://www.ietf.org/id/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00.= txt
Status:= https://datatracker.ietf.org/doc/draft-plmrs-ipsecme-ipsec-ikev2-context-de= finition/
Htmlized: h= ttp://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definitio= n-00


Abstract

=A0 =A0IPsec/IKEv2 clusters are=20 constituted of multiple nodes accessed via a
=A0 =A0single=20 address by the end user. =A0The traffic is then split between
=A0= =20 =A0the nodes via specific IP load balancing policies. =A0Once a=20 session is
=A0 =A0assigned to a given node, IPsec makes it=20 difficult to assign the
=A0 =A0session to another node.=20 =A0This makes management operations and
=A0 =A0transparent=20 high availability for end users difficult to perform
=A0=20 =A0within the cluster.

=A0 =A0This document describes the=20 contexts for IKEv2 and IPsec that MUST be
=A0 =A0transferred=20 between two nodes so a session can be restored. =A0This
=A0=20 =A0makes possible to transfer an IPsec session transparently to the= =20 end
=A0 =A0user.

=A0

Daniel= PALOMARES

Orange= Labs,=20 Issy-les-Moulineaux

+33 6 34 = 23 07=20 88

_______________________________________________
IPsec maili= ng=20 list
IPsec@iet= f.org
https://www.ietf.org/mailman/listinfo/ipsec



--bcaec51593e3c19ec904f3b253e5-- From nobody Mon Mar 3 04:02:52 2014 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 4CB9D1A0060 for ; Mon, 3 Mar 2014 04:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 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, 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 nw9poeOgxn1E for ; Mon, 3 Mar 2014 04:02:49 -0800 (PST) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 39AD11A0051 for ; Mon, 3 Mar 2014 04:02:49 -0800 (PST) Received: by mail-la0-f52.google.com with SMTP id ec20so3739189lab.39 for ; Mon, 03 Mar 2014 04:02:45 -0800 (PST) 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=csm0H9Gpsbj4oVR0bqKz0WO2ovwXUR6R3SNhoQ4gvKo=; b=wazSeW6dm5A68gwg3oUykE8b3fUVqdyFyU4/CoJ9iSpH39HLCJWR7+F63LwIio722t gxQdE+ASQgPHVJTDg/wTGElJmHwiIAfsMRX8Bb0+D2oT7Do3WwHmbLQmP4awy/fWLvxR 6+bOZv97ZUA7nX/k1BTRNBhC+AcK5rhgouDb0S1PUFDq+fUfrslfHguaXcCkD48MkVUS UpsHmnySyR/SN+oZhm7q8wkBfXt9p9RtepYIuV+uvWCxSGcQLiF6RNu0/26xnQQXe6x7 6PYUiviKcHyE0IQDEUzJTTUBxCQfj5P9B0j2J1yiUbgq7Kn8hUvsaKRVPhOO4AtJcP5w tOmA== X-Received: by 10.152.242.165 with SMTP id wr5mr2012438lac.47.1393848165617; Mon, 03 Mar 2014 04:02:45 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id q6sm29678406lal.3.2014.03.03.04.02.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 04:02:44 -0800 (PST) Message-ID: <9618756DDA9C407AB0DC06AC207FD394@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "ipsec" References: <530CE583.6030801@gmail.com> Date: Mon, 3 Mar 2014 16:02:57 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/wmlo7kKBKUkIUYgkMIEwxiy6CZU Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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, 03 Mar 2014 12:02:51 -0000 Hi, I have mostly no problem with the document. However I have one small concern. The draft lists the following trasforms based on AES cipher: AES-GCM AES-CCM AES-CTR AES-128-CBC AES-GMAC AES-XCBC-MAC-96 All these transforms, except for AES-XCBC-MAC-96, allows to be used with different key lengths - 128, 192 and 256 bits. It looks strange to me that, unlike the others, AES-128-CBC has key length explicitely specified in the draft. Why it differs in this respect from the others? What about AES-192-CBC and AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) I think the draft should either: - remove explicit key length from AES-128-CBC and make it just AES-CBC - add explicit key length to all other AES-based transforms (except for AES-XCBC-MAC-96) - leave things as is, but explain why AES-CBC differs in this respect from the others Regards, Valery Smyslov. ----- Original Message ----- From: "Yaron Sheffer" To: "ipsec" Sent: Tuesday, February 25, 2014 10:48 PM Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts > Hi, this is to start a 2-week working group last call on the revised > Algorithm Implementation Requirements document, ending March 11. The draft > is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We > should have last called the draft a while ago, and I apologize for the > delay. > > The changes from the existing requirements are listed in Sec. 2.5 of the > draft, but most of this (rather short) document is new and describes the > rationale for the choice of algorithms and requirement levels. > > Please read this draft and send any comments to the WG mailing list, even > if the comments are "I see no problems". Comments such as "I do not > understand this part" or "this part could be explained better in this way" > are particularly useful at this point. > > Thanks, > Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Mar 3 07:04:14 2014 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 4AE5C1A0102 for ; Mon, 3 Mar 2014 07:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 ZuIhhrrXAbOn for ; Mon, 3 Mar 2014 07:04:11 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B017E1A004A for ; Mon, 3 Mar 2014 07:04:10 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s23F44up020636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Mar 2014 17:04:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s23F443D006722; Mon, 3 Mar 2014 17:04:04 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21268.39396.785431.297271@fireball.kivinen.iki.fi> Date: Mon, 3 Mar 2014 17:04:04 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 126 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/fo7TL9oMmTTAHuZgacF98Sr09AY Cc: ipsec@ietf.org Subject: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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, 03 Mar 2014 15:04:13 -0000 Valery Smyslov writes: > I've posted new version of the NULL Auth Method draft. > It addresses comments received from Yaron Sheffer and Paul Wouters. Ah, I just managed to read the -00 version... Oh well, reading diffs next... Anyways I think the document is in quite good shape, I think the section 2.2 needs to be more specific about how to send the empty ID payload. I think the idea of sending ID_IPV4_ADDR with 0 bytes of data is very bad idea. The current text says you can omit data, and that the type can be anything. The problem is that in most cases the implementation has code that will parse the ID payload using standard rules and now if the ID payload has type of ID_IPV4_ADDR and 0 bytes of data, the parsing will fail. It would be better to say that if you are sending empty ID payload, you msut use ID_KEY_ID type which already allows any data, including empty. Actually I now noticed you changed the "SHOULD be ignored" to "MUST be ignored", and I think that is again bad idea. I think logging and auditing the ID for problem solving purposes is good idea even if it does not have any meaning for the authentication. I.e. at least then I can contact helpdesk and say that my NULL authentication connection to server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it from your logs... -- kivinen@iki.fi From nobody Mon Mar 3 07:04:50 2014 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 4AF931A0145 for ; Mon, 3 Mar 2014 07:04:48 -0800 (PST) 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 PHkN0DddtLWA for ; Mon, 3 Mar 2014 07:04:47 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id AD8671A0133 for ; Mon, 3 Mar 2014 07:04:46 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id x48so3264333wes.21 for ; Mon, 03 Mar 2014 07:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version; bh=EZjtrcBnQ1467YWqIueUSkHXQjRJhLc6pNbQd/pU3x0=; b=zf45zLluEj32TlrXY070Z9r/LBHmSuZiCT/0SUgZr62GPY8yNimqfvo6lJ7jfKZk3c VQnIMPwgtmHyS6pjU+B0zV89pKZm+OUn2Cr6V2MRzuzxj2lASfaqOjY6eaQiJ7Ls6Cc7 uPKfPf8+XYkVgyQmeO/BtfdzOwvQ1dIRtPHBWiNJrw9oo3DOEiZM0o2z9wpGLiCjGxAL xOk8u90PHK+YE3Sye2ly31aVlCPTbZHZURCAPzSRHxYNMlM4u2sYfU9ZP7uKDjAHFGSS V5cr67I4T088uc7G/DvKqaaOpIXl0xaW1WyR7fxD+xVZquKoZXsbP4p/anE8degNhzYJ oj0A== X-Received: by 10.194.84.144 with SMTP id z16mr18730387wjy.23.1393859083364; Mon, 03 Mar 2014 07:04:43 -0800 (PST) Received: from dhcp-b378.meeting.ietf.org (dhcp-b378.meeting.ietf.org. [31.133.179.120]) by mx.google.com with ESMTPSA id f7sm36526312wjb.7.2014.03.03.07.04.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 07:04:42 -0800 (PST) From: RJ Atkinson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 3 Mar 2014 10:04:40 -0500 Message-Id: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com> To: IPsec ME WG List Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/akfMloaTqRFnjPr3WenJn_WXVyc Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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, 03 Mar 2014 15:04:48 -0000 > Perhaps some text along the line of: > > ESP-NULL offers the same protection as AH, ... This sentence above is not true. ESP-NULL and AH provide different security properties to the IP-layer. AH protects all IP options, whereas ESP cannot protect any IP options that appear prior to the ESP header -- the location in the packet where those IP options are seen *and acted upon* by routers/firewalls/etc. Similarly, AH protects many IP header fields from in-transit modification, whereas ESP encapsulation provides no protection for the 1st (outer) IP header (i.e., that appears before the ESP header). As a prior discussion has noted, AH can and is used to provide cryptographic protection to some security-critical IP options (e.g. sensitivity labels). ESP-NULL is not capable of protecting those options. The reason AH is MAY is that not all deployments care about protecting the (outer) IP header and (visible to the forwarding plane) IP options. Some deployments definitely do care. Other deployments do not. Yours, Ran From nobody Mon Mar 3 07:54:08 2014 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 C8AD31A021B for ; Mon, 3 Mar 2014 07:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 dxWJtHq70p_B for ; Mon, 3 Mar 2014 07:54:05 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6971A0217 for ; Mon, 3 Mar 2014 07:54:04 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s23FrwN7020857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 3 Mar 2014 17:53:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s23Frwj8018301; Mon, 3 Mar 2014 17:53:58 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21268.42389.983348.801438@fireball.kivinen.iki.fi> Date: Mon, 3 Mar 2014 17:53:57 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <9618756DDA9C407AB0DC06AC207FD394@buildpc> References: <530CE583.6030801@gmail.com> <9618756DDA9C407AB0DC06AC207FD394@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 13 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/4hmEWXrNMdrHM5jFF8ZRAYLhfDU Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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, 03 Mar 2014 15:54:06 -0000 Valery Smyslov writes: > The draft lists the following trasforms based on AES cipher: > > AES-GCM > AES-CCM > AES-CTR > AES-128-CBC > AES-GMAC > AES-XCBC-MAC-96 > > All these transforms, except for AES-XCBC-MAC-96, > allows to be used with different key lengths - 128, 192 and 256 bits. > It looks strange to me that, unlike the others, AES-128-CBC > has key length explicitely specified in the draft. Why it differs in > this respect from the others? What about AES-192-CBC and > AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) Hmm... actually we should most like use the same names we use in the IANA registry. For example we have 3 different types of AES-GCM: 18 AES-GCM with a 8 octet ICV [RFC4106] [RFC5282] 19 AES-GCM with a 12 octet ICV [RFC4106] [RFC5282] 20 AES-GCM with a 16 octet ICV [RFC4106] [RFC5282] Which one of those is the one that is moved to SHOULD+? Should we just pick one of them, and say that it is the one we prefer, or should all implementations implement all of them? AES-CCM has similar thing, but as they are moving to MAY it does not really matter. And yes, I agree the AES-128-CBC should be changed to AES-CBC. In the RFC4305 and RFC4835 we had text like "AES-CBC with 128-bit keys", but as we now have more AES modes, we should probably just add text saying that for 128-bit keys for AES is MUST. Also for AES-GMAC we need to decide which of the ones we are saying is SHOULD+: 9 AUTH_AES_128_GMAC [RFC4543] 10 AUTH_AES_192_GMAC [RFC4543] 11 AUTH_AES_256_GMAC [RFC4543] > I think the draft should either: > - remove explicit key length from AES-128-CBC and make it just > AES-CBC > - add explicit key length to all other AES-based transforms (except for > AES-XCBC-MAC-96) AES-XCBC-MAC-96 is always defined to be have 128-bit key. The key length cannot be negotiated when using the authentication algorithm, it can only be negotiated for the encryption keys. Thats why the AUTH_AES_*_GMAC authentication algorithms are defined as 3 different algorithms. > - leave things as is, but explain why AES-CBC differs in this respect from > the others I think that is bad idea. I think the best is to say that in general with AES encryption (GCM, CBC, CCM etc) we assume the key length is 128-bits. (i.e. the MUST for AES-CBC is for 128-bit keys, and the SHOULD+ for AES-GCM is also for 128-bit keys with x octect ICV). -- kivinen@iki.fi From nobody Mon Mar 3 08:20:16 2014 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 89AAA1A01E4 for ; Mon, 3 Mar 2014 08:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 Cu5wZXZYRvnC for ; Mon, 3 Mar 2014 08:19:58 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 05F6D1A00B6 for ; Mon, 3 Mar 2014 08:19:57 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s23GJrvB022117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 3 Mar 2014 18:19:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s23GJraO021144; Mon, 3 Mar 2014 18:19:53 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21268.43945.628205.309410@fireball.kivinen.iki.fi> Date: Mon, 3 Mar 2014 18:19:53 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/opjBvDF9NJbfNMluXtAiRVNHfFI Subject: [IPsec] Comments to draft-amjads-ipsecme-ikev2-data-channel-00 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, 03 Mar 2014 16:20:13 -0000 First of all, I am really dubious whether this is needed. When I started reading this, I first assumed, ok, it is used to transfer some data between two nodes from userland to userland without any need for kernel IPsec stack, or some configuration / policy data that is needed before the ESP SA can be brought up. I was really suprised that this actually transmits IPv4 and IPv6 packets inside the IKE. I.e. it just replaces the ESP with IKEv2. I see any real benefit from that. What is the use case for this? I think it would be much easier to just create one IPsec ESP SA and run your IP packets over that? I think it is bad idea to create tunneling IP packets over IKEv2 over UDP over IP solution. Some other nits: In the section 8.1 it says: o Protocol ID (1 octet): MUST be 1, as this message is related to an IKEv2 SA. This is wrong. The RFC5996 says that Protocol ID MUST be 0, as there is no SPI: o Protocol ID (1 octet) - If this notification concerns an existing SA whose SPI is given in the SPI field, this field indicates the type of that SA. For notifications concerning Child SAs, this field MUST contain either (2) to indicate AH or (3) to indicate ESP. Of the notifications defined in this document, the SPI is included only with INVALID_SELECTORS and REKEY_SA. If the SPI field is empty, this field MUST be sent as zero and MUST be ignored on receipt. -- kivinen@iki.fi From nobody Mon Mar 3 08:25:35 2014 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 6FC621A0158 for ; Mon, 3 Mar 2014 08:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 n7azDJ3Pp6B0 for ; Mon, 3 Mar 2014 08:25:30 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC831A0238 for ; Mon, 3 Mar 2014 08:25:29 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s23GPPfN003459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 3 Mar 2014 18:25:25 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s23GPP9N002005; Mon, 3 Mar 2014 18:25:25 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21268.44277.606320.237806@fireball.kivinen.iki.fi> Date: Mon, 3 Mar 2014 18:25:25 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ux979O3hsJ3_7xfOHRkiuvRy9og Subject: [IPsec] Comments to the draft-ietf-ipsecme-ikev2-fragmentation-05 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, 03 Mar 2014 16:25:32 -0000 I have read this document, and I think it is getting ready. I have some nits for it, but they are just typos and similar. Nits: ---------------------------------------------------------------------- In appendix A: The attacker could infrequently emit forged but looking valid fragments ^^^^^^^^^^^^^ s/looking valid/valid looking/ -- ... that allows receiver to determine forgeg fragments and ^^^^^^ not to fetch them into the reassempling queue. ^^^^^ s/forgeg/forged/ s/fetch/store/ -- kivinen@iki.fi From nobody Mon Mar 3 09:11:56 2014 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 6ECEE1A02CA for ; Mon, 3 Mar 2014 09:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 FjUxHBDmNCIs for ; Mon, 3 Mar 2014 09:11:50 -0800 (PST) Received: from mail-ie0-x241.google.com (mail-ie0-x241.google.com [IPv6:2607:f8b0:4001:c03::241]) by ietfa.amsl.com (Postfix) with ESMTP id C06AE1A0258 for ; Mon, 3 Mar 2014 09:11:50 -0800 (PST) Received: by mail-ie0-f193.google.com with SMTP id rl12so2588633iec.0 for ; Mon, 03 Mar 2014 09:11:47 -0800 (PST) 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=ce/7bBP8ea0RyLiazT9f6aMPPM3ODraSW8neG0nSv3o=; b=HgqmY2RYB2PAmvPyRy0xQ3B50E+pCeSzDyvbcgDmg7y5ptosjQjHOVOiIXR4TO5bZc /mdf3ElvRFTk3s7Wp6NAV7pNA9XnoovAgdgLlAyRSvxaoV6oUggIVOHN/q2SKg7Vs8tt rydnggIpvz9QGhEy34AVBcAppWC8YccoVGZSl6AZ101RQIa+eiZ8E2I1p873XSSaldCM WNYj6HM21WNSJZI8p3DU+5nMiBiNIkOZ/hSLSPleeEoO9FXQ3zGtidUk/abBi/vgMVib 2M9ncbj7EAhScudMa3NOvmZl95LxqoLjZf7ocPlF+z3tHDxQYBywcfFZ95/Gg3Zx6rHT L8/Q== MIME-Version: 1.0 X-Received: by 10.50.143.12 with SMTP id sa12mr23464557igb.45.1393866707856; Mon, 03 Mar 2014 09:11:47 -0800 (PST) Received: by 10.50.40.131 with HTTP; Mon, 3 Mar 2014 09:11:47 -0800 (PST) Date: Mon, 3 Mar 2014 18:11:47 +0100 Message-ID: From: Daniel Palomares To: IPsecme WG Content-Type: multipart/alternative; boundary=001a1134cd02fc727404f3b6e1db Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/XKPKwj0peu11asIjlT98fi_0gXc Subject: [IPsec] New draft: MOBIKEv2 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, 03 Mar 2014 17:11:53 -0000 --001a1134cd02fc727404f3b6e1db Content-Type: text/plain; charset=ISO-8859-1 Hi all, Please find a draft we have just posted. It concerns a new version of MOBIKE, called MOBIKEv2, which extends MOBIKE [RFC4555] for IPsec Security Associations using also transport mode. Comments are welcome, A new version of I-D, draft-mglt-ipsecme-mobikev2-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-mobikev2 Revision: 00 Title: MOBIKEv2: MOBIKE extension for Transport mode Document date: 2014-03-03 Group: Individual Submission Pages: 14 URL: http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-mobikev2-00.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-mobikev2/ Htmlized: http://tools.ietf.org/html/draft-mglt-ipsecme-mobikev2-00 Abstract: MOBIKE [RFC4555] is the IKEv2 Mobility and Multihoming Protocol and as been defined only for IPsec Security Association using the tunnel mode. This document describes MOBIKEv2 that extends MOBIKE [RFC4555] for IPsec Security Associations using also transport mode. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Regards, Daniel Palomares Orange Labs & LIP6 +33-634230788 --001a1134cd02fc727404f3b6e1db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Please find a draft we have just posted. It concerns a new version of MOBIK= E, called MOBIKEv2, which extends MOBIKE [RFC45= 55]=A0 for IPsec Security Associations using also transport mode.

Comments are welcome,


A new version of I-D, draft-mglt-ipsecme-mobikev2-00.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name: =A0 =A0 =A0 =A0 =A0 draft-mglt-ipsecme-mobikev2
Revision: =A0 =A0 =A0 00
Title: =A0 =A0 =A0 =A0 =A0MOBIKEv2: MOBIKE extension for Transport mode
Document date: =A02014-03-03
Group: =A0 =A0 =A0 =A0 =A0Individual Submission
Pages: =A0 =A0 =A0 =A0 =A014
URL: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/i= nternet-drafts/draft-mglt-ipsecme-mobikev2-00.txt
Status: =A0 =A0 =A0 =A0 https://datatracker.ietf.org/doc/d= raft-mglt-ipsecme-mobikev2/
Htmlized: =A0 =A0 =A0 http://tools.ietf.org/html/draft-mglt-ip= secme-mobikev2-00


Abstract:
=A0 =A0MOBIKE [RFC4555] is the IKEv2 Mobility and Multihoming Protocol and<= br> =A0 =A0as been defined only for IPsec Security Association using the tunnel=
=A0 =A0mode. =A0This document describes MOBIKEv2 that extends MOBIKE [RFC45= 55]
=A0 =A0for IPsec Security Associations using also transport mode.


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.


Regards,

Daniel Palomares
Orange = Labs & LIP6
+33-634230788



--001a1134cd02fc727404f3b6e1db-- From nobody Mon Mar 3 12:49:27 2014 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 91B141A03DE for ; Mon, 3 Mar 2014 12:49:25 -0800 (PST) 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 v-OodO1eSt3F for ; Mon, 3 Mar 2014 12:49:24 -0800 (PST) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3B01A0388 for ; Mon, 3 Mar 2014 12:49:23 -0800 (PST) Received: by mail-wg0-f43.google.com with SMTP id x13so2725340wgg.26 for ; Mon, 03 Mar 2014 12:49:20 -0800 (PST) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=6X5NovMXwOcasc8my7o5UAVOPA2suO99jPqA5Anx8Ew=; b=kaV79J0lRVCTTT9YzDb/jLVK6krO4k6UL4Wcq5jpmq0114hO6MUDzaW/x73pkSGaaV 75x4T/ISyU4M/3api3tZQrqhp3xtEu3Nxh7cwjViIQ0hMN9GTDBf8BO2RbwSZzIxH5HO 4o9bQre5iSr2eKH0WRKdpOyJR0YyP3sFDXYTJRyJycfurNBWPi8Tjvb+X+h+inAFjU5+ +KXQPU3wv25Dko/bf41tiVRprrcoQ/14WZNzYLhYYlV3PKU1t6CtLXNxyE/7wOOXYDpn QaoVRq4ufqivBKaf0ps0QTvmLDW7Ljf2sLO45Q0L63P9l3I/m2JOkJSAGZcsT8SqeTJt SVFw== X-Received: by 10.194.2.194 with SMTP id 2mr9627087wjw.73.1393879760584; Mon, 03 Mar 2014 12:49:20 -0800 (PST) Received: from [10.0.0.6] ([109.65.63.189]) by mx.google.com with ESMTPSA id z1sm41060784wjq.19.2014.03.03.12.49.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 12:49:19 -0800 (PST) Message-ID: <5314EACE.5060502@gmail.com> Date: Mon, 03 Mar 2014 22:49:18 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tero Kivinen , ipsec@ietf.org References: <21268.44277.606320.237806@fireball.kivinen.iki.fi> In-Reply-To: <21268.44277.606320.237806@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DlaHzvQcbwWF-4bVHZbu2CQhuqU Subject: Re: [IPsec] Comments to the draft-ietf-ipsecme-ikev2-fragmentation-05 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, 03 Mar 2014 20:49:25 -0000 ...And s/reassempling/reassembling (also in the preceding paragraph). Yaron On 03/03/2014 06:25 PM, Tero Kivinen wrote: > I have read this document, and I think it is getting ready. I have > some nits for it, but they are just typos and similar. > > Nits: > ---------------------------------------------------------------------- > > In appendix A: > > The attacker could infrequently emit forged but looking valid fragments > ^^^^^^^^^^^^^ > s/looking valid/valid looking/ > > -- > > ... that allows receiver to determine forgeg fragments and > ^^^^^^ > not to fetch them into the reassempling queue. > ^^^^^ > > s/forgeg/forged/ > s/fetch/store/ > From nobody Mon Mar 3 14:34:58 2014 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 0385E1A0249 for ; Mon, 3 Mar 2014 14:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547] 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 wZ--A1Gll8Ve for ; Mon, 3 Mar 2014 14:34:53 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id BB73A1A0233 for ; Mon, 3 Mar 2014 14:34:51 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8D4FB800AF; Mon, 3 Mar 2014 17:34:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393886087; bh=9BF4FCymJvKhIDJBvHQNscZEFRvk5fZ+sxCsIFu/DTE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QouLCCmps6I9VmYPE2zlGhaymS+KQBaocr5Qjm3kOoKmJrED5ojdt+QzGxIWOTAG4 qzM/vxqhuhqI8aNnXxFiZ5jhK5OlPhNszonX/ZWnC/siJGOAFqvdQWFJnLBO1rjsBK kTr1GZPqq3nogviseRBmEaBxGXF+srIGPpuTY36A= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s23MYk7H005328; Mon, 3 Mar 2014 17:34:46 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 3 Mar 2014 17:34:46 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21268.42389.983348.801438@fireball.kivinen.iki.fi> Message-ID: References: <530CE583.6030801@gmail.com> <9618756DDA9C407AB0DC06AC207FD394@buildpc> <21268.42389.983348.801438@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/_wCwZDmqN-EPnBJ0Izk6eYosvx8 Cc: ipsec , Valery Smyslov Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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, 03 Mar 2014 22:34:56 -0000 On Mon, 3 Mar 2014, Tero Kivinen wrote: > Hmm... actually we should most like use the same names we use in the > IANA registry. For example we have 3 different types of AES-GCM: > > 18 AES-GCM with a 8 octet ICV [RFC4106] [RFC5282] > 19 AES-GCM with a 12 octet ICV [RFC4106] [RFC5282] > 20 AES-GCM with a 16 octet ICV [RFC4106] [RFC5282] > > Which one of those is the one that is moved to SHOULD+? Should we just > pick one of them, and say that it is the one we prefer, or should all > implementations implement all of them? AES-CCM has similar thing, but > as they are moving to MAY it does not really matter. Actually yes. I talked to one of the authors of RFC 4106, John Viega, a while ago and he said: "Some people seemed to think embedded devices would want to use truncated tags. in this day in age, I would recommend AGAINST tag truncation" So I would be happy to only move ID 20 to SHOULD+ and actually demote 18 and 19. Paul From nobody Mon Mar 3 14:54:03 2014 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 F1AE01A02B8 for ; Mon, 3 Mar 2014 14:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 IUuyCeuQZsEC for ; Mon, 3 Mar 2014 14:54:01 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 317AA1A01E8 for ; Mon, 3 Mar 2014 14:54:01 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DBC86800AF; Mon, 3 Mar 2014 17:53:57 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s23MrvV9007085; Mon, 3 Mar 2014 17:53:57 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 3 Mar 2014 17:53:57 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: RJ Atkinson In-Reply-To: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com> Message-ID: References: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-SWyxIfqtWK_NrE5RdTmPqjyzYY Cc: IPsec ME WG List Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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, 03 Mar 2014 22:54:03 -0000 On Mon, 3 Mar 2014, RJ Atkinson wrote: >> ESP-NULL offers the same protection as AH, ... > > This sentence above is not true. ESP-NULL and AH provide > different security properties to the IP-layer. > > AH protects all IP options, whereas ESP cannot protect any > IP options that appear prior to the ESP header -- the location > in the packet where those IP options are seen *and acted upon* > by routers/firewalls/etc. What meaning has "protecting" those bits? Endpoint A and B protect something by cryptography, but any router in the middle can't trust those signatures anyway. So I don't see how AH is different from ESPinUDP where you set those options in the UDP header. These are not "protected" but the router can't verify the crypto anyway. > Similarly, AH protects many IP header fields from in-transit > modification, whereas ESP encapsulation provides no protection > for the 1st (outer) IP header (i.e., that appears before the ESP header). So I don't buy that. The IP header is not protecting the packet from a router, which cannot confirm the crypto of that protection. What this is really about is exposing things like QoS bits, but those devices acting on those are not verifying any "protection". They are blindly using the exposed options. So ESPinUDP works equally well here. > As a prior discussion has noted, AH can and is used to provide > cryptographic protection to some security-critical IP options > (e.g. sensitivity labels). ESP-NULL is not capable of protecting > those options. I'm not sure what you are referring to here. Not labeled IPsec I take it? And again, how does this "protection" work? How do the routers verify this "protection" when only the endpoints know the crypto keys used to protect the header and payload? > The reason AH is MAY is that not all deployments care about > protecting the (outer) IP header and (visible to the forwarding > plane) IP options. Can you explain how this protection works? If an AH packet flies by, and I change the QoS option from off to on to give my packet preference in the network, how will the next router notice this and ignore this QoS option? > Some deployments definitely do care. Other deployments do not. By understanding was always that people didn't like options getting "lost" or "hidde" within the ESP payload, and not getting set on the outer packet. In fact, with KLIPS we had an option that could copy some of the header bits into the outer IP header. Paul From nobody Mon Mar 3 14:57:39 2014 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 60D931A01C4 for ; Mon, 3 Mar 2014 14:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 331Vp_VMadaT for ; Mon, 3 Mar 2014 14:57:37 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id DE6751A01D6 for ; Mon, 3 Mar 2014 14:57:36 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D2A2F800AF; Mon, 3 Mar 2014 17:57:33 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s23MvX98007502; Mon, 3 Mar 2014 17:57:33 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 3 Mar 2014 17:57:33 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21268.39396.785431.297271@fireball.kivinen.iki.fi> Message-ID: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/jrP0JYNj7EDP9JV7O9oJYnhXEEw Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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, 03 Mar 2014 22:57:38 -0000 On Mon, 3 Mar 2014, Tero Kivinen wrote: > It would be better to say that if you are sending empty ID payload, > you msut use ID_KEY_ID type which already allows any data, including > empty. That could work, if we really don't want to allow this document to change the ID payload from mandatory to optional (which I would prefer) > Actually I now noticed you changed the "SHOULD be ignored" to "MUST be > ignored", and I think that is again bad idea. I think logging and > auditing the ID for problem solving purposes is good idea even if it > does not have any meaning for the authentication. I.e. at least then I > can contact helpdesk and say that my NULL authentication connection to > server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID > payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it > from your logs... I disagree strongly. The point here is that the client is anonymous. We should not add things that can be traced to a user. Someone will badly abuse this "feature" like you are suggesting for "diagnostics" and inadvertly compromise the client's anonimity. Paul From nobody Mon Mar 3 15:04:48 2014 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 49B431A027E for ; Mon, 3 Mar 2014 15:04:47 -0800 (PST) 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 NPcfGz9-eAmV for ; Mon, 3 Mar 2014 15:04:45 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id F07CA1A0269 for ; Mon, 3 Mar 2014 15:04:44 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id p61so2826127wes.25 for ; Mon, 03 Mar 2014 15:04:41 -0800 (PST) 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=conpgL0rqIY3LnZzmDxVEqcIOpNThy0xc7ZF5hrAqmo=; b=D/KheFXw2ygR+XIt8LB81gtHj2/rEEPTr5X6/j8WmrG/X2QWO+G4v/qX/2LN0xiv2z YADBHDSQx6/rcNZhkT4/K3Pb8+FPqg90N/GBikijH+gnlgKQRDoMvz/J9bSCmlZmMMQt FYp65bQaZ+Me97hTsWhco1PAoYET5qIKD5KhUdJB8D1OTKWNCsYrP7y7b2dXhgwam2N0 i4a90nPL7/RX1DaUyjzAvxbwWSV7UnQHlZNtWSaqW12D1LANgfkY0RculdJjo//PCbft /rDP/nFXBgpehtfBanUMSZX5zBMRmDdcd3c8Rg/GFBiMMYRTnUoN3Npcp9H2R70iWHJo n88A== X-Received: by 10.194.91.232 with SMTP id ch8mr22279011wjb.13.1393887881403; Mon, 03 Mar 2014 15:04:41 -0800 (PST) Received: from [10.0.0.6] ([109.65.63.189]) by mx.google.com with ESMTPSA id xt1sm42540470wjb.17.2014.03.03.15.04.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 15:04:41 -0800 (PST) Message-ID: <53150A87.6030305@gmail.com> Date: Tue, 04 Mar 2014 01:04:39 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul Wouters , Tero Kivinen References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/FYPnbRNCjQtjqtHAeHpk_B94iyc Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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, 03 Mar 2014 23:04:47 -0000 Hi Paul, Quoting from the abstract: "This method may be used to preserve anonymity or in situations, where no trust relationship exists between the parties." You seem to assume that all clients want to be anonymous. IMHO "unauthenticated" does not necessarily imply "anonymous". When I talk to someone on the plane and they tell me their name, they are not authenticated and they may well be lying. But in general, they are not anonymous either. Thanks, Yaron On 03/04/2014 12:57 AM, Paul Wouters wrote: > On Mon, 3 Mar 2014, Tero Kivinen wrote: > >> It would be better to say that if you are sending empty ID payload, >> you msut use ID_KEY_ID type which already allows any data, including >> empty. > > That could work, if we really don't want to allow this document to > change the ID payload from mandatory to optional (which I would prefer) > >> Actually I now noticed you changed the "SHOULD be ignored" to "MUST be >> ignored", and I think that is again bad idea. I think logging and >> auditing the ID for problem solving purposes is good idea even if it >> does not have any meaning for the authentication. I.e. at least then I >> can contact helpdesk and say that my NULL authentication connection to >> server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID >> payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it >> from your logs... > > I disagree strongly. The point here is that the client is anonymous. We > should not add things that can be traced to a user. Someone will badly > abuse this "feature" like you are suggesting for "diagnostics" and > inadvertly compromise the client's anonimity. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Mar 3 21:24:34 2014 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 662E81A0361 for ; Mon, 3 Mar 2014 21:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, 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 Lrvk3ehC6bZL for ; Mon, 3 Mar 2014 21:24:31 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C2E5F1A0366 for ; Mon, 3 Mar 2014 21:24:30 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so5322292lbj.3 for ; Mon, 03 Mar 2014 21:24:26 -0800 (PST) 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=KFlyiqDy6mTk57/fBhgegAsJA2ptcSbupba5JFGTZ0E=; b=GYa4zNqEGJtiuv51mb/qk1eMB5BZTrX3J5DpUTQ+PiP5/+VWCAO2dtFcvNPi2yFCWZ CB/zPrSHS3y04gdIz88zjCRqTqH7x6CQZM7ndrwVsF7POgESub9vnhI8sJDIePkKSu6P hQi1Uq9msKl10K8POWAaLilE2iCMuyh463Kir2RAJqmfFSeYPIcb80F/3qiulJlq+3F0 7Urp8ZLuzKfCRLddgKvprulVnugFem8Gf+bLzZM+eO5otAialj9Zw87MqcbnaeX2zH4D sl9HZK7YDKrkkEeqbSEWgOr370jskhDzcFIk5EsB6Y1rsxyClSwyg4uIunsVKcUGEYHF /9Gw== X-Received: by 10.112.14.1 with SMTP id l1mr260008lbc.39.1393910666848; Mon, 03 Mar 2014 21:24:26 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id qf1sm15239970lbc.8.2014.03.03.21.24.25 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 21:24:26 -0800 (PST) Message-ID: <6310663B551C405E84E5CFC469781E65@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , References: <21268.44277.606320.237806@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 09:24:39 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/xiS-EUNGRd_DCBXuXAFwPQiweoo Subject: Re: [IPsec] Comments to the draft-ietf-ipsecme-ikev2-fragmentation-05 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, 04 Mar 2014 05:24:32 -0000 Hi Tero, thanks for catching these typos and gramma errors. Valery. ----- Original Message ----- From: "Tero Kivinen" To: Sent: Monday, March 03, 2014 8:25 PM Subject: [IPsec] Comments to the draft-ietf-ipsecme-ikev2-fragmentation-05 >I have read this document, and I think it is getting ready. I have > some nits for it, but they are just typos and similar. > > Nits: > ---------------------------------------------------------------------- > > In appendix A: > > The attacker could infrequently emit forged but looking valid fragments > ^^^^^^^^^^^^^ > s/looking valid/valid looking/ > > -- > > ... that allows receiver to determine forgeg fragments and > ^^^^^^ > not to fetch them into the reassempling queue. > ^^^^^ > > s/forgeg/forged/ > s/fetch/store/ > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Mar 3 21:25:44 2014 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 CEA1B1A0361 for ; Mon, 3 Mar 2014 21:25:42 -0800 (PST) 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 EJVkmxPrOju4 for ; Mon, 3 Mar 2014 21:25:41 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id B71A91A035F for ; Mon, 3 Mar 2014 21:25:40 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id mc6so5200799lab.22 for ; Mon, 03 Mar 2014 21:25:37 -0800 (PST) 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=yiB/NMh/FhTfT1ZHLLzY4EzuhOy+78C61R1qxv78gOA=; b=zVqJ7zuddrgnGi45NSY0nqWinxp7qoMrbWZcxH9On8zP8Jzgfe6qTQQEakCdT+pres 1GZuUkEJ8SLzHkAik/wik35/xA+Y5bynYoLCDCpnfl2nbzEJla32qYzmJq72/cxmPjQW mGqkJYd5L6j9chhkBC9xLcf2scidBQN8Z8GixuD/8hcPGEjTi1/1DwjnPbUnYHTcvQVI Jf+57rAOshElLUfWsC9+9F+SNROepRW3BIRiC94zb+8zi3gRQV8k90N69lqhFvrQEgw/ mgGfp9av4BT7CQ3q15n+O9DRtlO0mg4oN06kNpUcSBnZ8HCHtjMiav+/RtjJEcXpYV97 Kkig== X-Received: by 10.152.28.41 with SMTP id y9mr678129lag.11.1393910737097; Mon, 03 Mar 2014 21:25:37 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id pz10sm18355711lbb.10.2014.03.03.21.25.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 21:25:36 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yaron Sheffer" , "Tero Kivinen" , References: <21268.44277.606320.237806@fireball.kivinen.iki.fi> <5314EACE.5060502@gmail.com> Date: Tue, 4 Mar 2014 09:25:50 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/RS4g58srilslA5JylqV9_PBjRJQ Subject: Re: [IPsec] Comments to thedraft-ietf-ipsecme-ikev2-fragmentation-05 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, 04 Mar 2014 05:25:43 -0000 Thanks Yaron! Valery. ----- Original Message ----- From: "Yaron Sheffer" To: "Tero Kivinen" ; Sent: Tuesday, March 04, 2014 12:49 AM Subject: Re: [IPsec] Comments to thedraft-ietf-ipsecme-ikev2-fragmentation-05 > ...And s/reassempling/reassembling (also in the preceding paragraph). > > Yaron > > On 03/03/2014 06:25 PM, Tero Kivinen wrote: >> I have read this document, and I think it is getting ready. I have >> some nits for it, but they are just typos and similar. >> >> Nits: >> ---------------------------------------------------------------------- >> >> In appendix A: >> >> The attacker could infrequently emit forged but looking valid >> fragments >> ^^^^^^^^^^^^^ >> s/looking valid/valid looking/ >> >> -- >> >> ... that allows receiver to determine forgeg fragments and >> ^^^^^^ >> not to fetch them into the reassempling queue. >> ^^^^^ >> >> s/forgeg/forged/ >> s/fetch/store/ >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Mar 3 22:10:28 2014 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 E606E1A010F for ; Mon, 3 Mar 2014 22:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, 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 zrweuO2o2gDe for ; Mon, 3 Mar 2014 22:10:24 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C41EB1A039D for ; Mon, 3 Mar 2014 22:10:23 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id w7so5260998lbi.2 for ; Mon, 03 Mar 2014 22:10:20 -0800 (PST) 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=0S+vIgQ/Bq6Qp4RJ57IO6Gl55VKgsK0+W85/923jkKs=; b=M08nJn/4AyzN4rt8YeG+OVxphmw3jzRC59eSlMBeMigo08KXWYFHAlnuX9TgNXCzZv c2Gw85ae13HRwahiObFFADjyyjs8binTlRLJQJ5/73JT/u5XT8jI8qglGEtWs7+ASnOH 6qLPsmzoL5fSDeb4jp5Sm7Ico99Gt3v09+rvheO8tDiQERXEVDLlSqrHHwOO2NBh2rkC omKGrD0UZYATDyZZ7XKqQepJAwqzqq/VmqqkSKWwkY/kfBiu8Q2K3AJ5MZ8EKQ3/akkl 0sgysqpCXhPcKIs0U4ZnxzWvjh7stDFsaobz0zQema3d/4l/u3rjC5aQyWn9YI363SUR h3CA== X-Received: by 10.112.64.37 with SMTP id l5mr172785lbs.49.1393913419984; Mon, 03 Mar 2014 22:10:19 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id ir3sm33623293lac.9.2014.03.03.22.10.18 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 22:10:18 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" References: <530CE583.6030801@gmail.com><9618756DDA9C407AB0DC06AC207FD394@buildpc> <21268.42389.983348.801438@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 10:10:32 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/fKKPRNa-TuVogmhjdKtzP2b9Zu0 Cc: ipsec Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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, 04 Mar 2014 06:10:26 -0000 HI Tero, > Hmm... actually we should most like use the same names we use in the > IANA registry. Agree, this would make things more clear. > I think the best is to say that in general with AES encryption (GCM, > CBC, CCM etc) we assume the key length is 128-bits. (i.e. the And don't forget about GMAC. > MUST for AES-CBC is for 128-bit keys, and the SHOULD+ for AES-GCM is > also for 128-bit keys with x octect ICV). I also think this is the best way. I listed the other two just for completeness. Valery. From nobody Mon Mar 3 22:36:51 2014 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 873161A027E for ; Mon, 3 Mar 2014 22:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, 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 PasWeZ3Jwip1 for ; Mon, 3 Mar 2014 22:36:47 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D8EF31A01AE for ; Mon, 3 Mar 2014 22:36:46 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id w7so5248524lbi.6 for ; Mon, 03 Mar 2014 22:36:43 -0800 (PST) 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=xMtnck7NXfp/cD9GaIg8zCEBy+prTTPQ8faRgzNR2kY=; b=s3bxq6K+3pvSmK3m+MM6aShExOHuMFYUOcQZLYvSw/Gut9sJtXoHjkpDJu+rcr3mdh tvOxUpMWeEYSl51MQeWPaq8Q1vaMpXhXmGMU0S5UgaKoS2JA7NmeaeYKcSpehENtxklY loUTK/XdHBakvl+GtL7b3sm04dToJFmshltQDfR+2Kuc+7AI10eWLDDVgp6YWWm1MS2k 6qyG38mOKCoZC6scMSygw/aLFTwIlzZfcMQNP9NLVmRnND3vSXyyWUxUsp2JQA+jVeAb UwnoC1gfPZ5xX2/J2QIFa+jMQg2AXdu7Lzu/CWcTasEiLgcZyWNKd7cts09wBf1DnKV+ S3Sg== X-Received: by 10.152.3.72 with SMTP id a8mr8464544laa.33.1393914991665; Mon, 03 Mar 2014 22:36:31 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id y2sm33737041lal.10.2014.03.03.22.36.30 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 03 Mar 2014 22:36:30 -0800 (PST) Message-ID: <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 10:36:44 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/u2IqW08a4hKJFN4K-VeMliHjy5c Cc: ipsec@ietf.org Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 06:36:48 -0000 Hi Tero, > Anyways I think the document is in quite good shape, I think the > section 2.2 needs to be more specific about how to send the empty ID > payload. I think the idea of sending ID_IPV4_ADDR with 0 bytes of > data is very bad idea. The current text says you can omit data, and > that the type can be anything. The problem is that in most cases the > implementation has code that will parse the ID payload using standard > rules and now if the ID payload has type of ID_IPV4_ADDR and 0 bytes > of data, the parsing will fail. I agree this may chocke some implementations. The idea was that if implementation notice that Auth Method is NULL, it must not parse ID Payload at all. But I understand that depending on the order in which payloads are processed by particular implementation, this may be inconvinient for implementers. > It would be better to say that if you are sending empty ID payload, > you msut use ID_KEY_ID type which already allows any data, including > empty. Actually, even with ID_KEY_ID it is a bit of hack. I'd rather define the entity "Empty ID Payload" as ID Payload with ID Type of zero and zero-length content (so that even ID Type be undefined) and require implementations to use it if they want to keep anonimity. > Actually I now noticed you changed the "SHOULD be ignored" to "MUST be > ignored", and I think that is again bad idea. I think logging and > auditing the ID for problem solving purposes is good idea even if it > does not have any meaning for the authentication. I.e. at least then I > can contact helpdesk and say that my NULL authentication connection to > server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID > payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it > from your logs... Actually, I tried to address Paul Wouters' concern that without strong "MUST" here implementations may use ID even if it is not authenticated. But, from my understanding of the wording, "MUST be ignored by IKE" doesn't mean that implementation is not allowed to log the ID, that is always useful ror auditing and troubleshooting. I probably should make this more clear. Regards, Valery. > -- > kivinen@iki.fi From nobody Tue Mar 4 01:26:49 2014 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 8AA451A0449 for ; Tue, 4 Mar 2014 01:26:44 -0800 (PST) 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 iIfLIYZnrAjb for ; Tue, 4 Mar 2014 01:26:41 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 835671A042E for ; Tue, 4 Mar 2014 01:26:41 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id b13so4587273wgh.31 for ; Tue, 04 Mar 2014 01:26:38 -0800 (PST) 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 :content-transfer-encoding:message-id:references:to; bh=vogmnVM+oPN7EjF4yUbpdAssHvrySm+4dxnWA2nyhX0=; b=pkxh6gy1KabzITT8hl9OtCa0KnH4bigdKlK6vZtkhFMh/ayHCeJKFNuPnnG/6G0JGR Z+U7I3B5BPA6zZ855bMtq9v2qzR12OOgB6Mb6AW+E7TS85fxuFTuYH3MRqShyidZ9jNC osa2TEc2rF9oxz3Ma2nod0qPdlLKSqaPLSHcsWZXyTko+6bslJrSpASoWcl9sknX2iOP wAsRYdnItXplN+Ia3BzaUFf2e4pQICQp9HcoyqYoIFj2cTHLFXlOoXpTf4M189d/Nl3h +BAoCkS06VujPb3Nw3FxE5D3HNCQGS5OsinX7O+TeKIP9C1gbWfsK9NDXzh99n4LDhHq jLQA== X-Received: by 10.194.243.68 with SMTP id ww4mr2258002wjc.58.1393925197948; Tue, 04 Mar 2014 01:26:37 -0800 (PST) Received: from dhcp-hotel-wifi-158-bf.meeting.ietf.org ([130.129.158.191]) by mx.google.com with ESMTPSA id r3sm49005433wjw.0.2014.03.04.01.26.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 01:26:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: RJ Atkinson In-Reply-To: Date: Tue, 4 Mar 2014 04:26:33 -0500 Content-Transfer-Encoding: 7bit Message-Id: References: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/oYLMAIF4lfVaXpg_h0my-vbOeDI Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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, 04 Mar 2014 09:26:44 -0000 On 03 Mar 2014, at 17:53 , Paul Wouters wrote: > On Mon, 3 Mar 2014, RJ Atkinson wrote: > >>> ESP-NULL offers the same protection as AH, ... >> >> This sentence above is not true. ESP-NULL and AH provide >> different security properties to the IP-layer. >> >> AH protects all IP options, whereas ESP cannot protect any >> IP options that appear prior to the ESP header -- the location >> in the packet where those IP options are seen *and acted upon* >> by routers/firewalls/etc. > > What meaning has "protecting" those bits? Endpoint A and B protect > something by cryptography, but any router in the middle can't trust > those signatures anyway. So I don't see how AH is different from > ESPinUDP where you set those options in the UDP header. These are > not "protected" but the router can't verify the crypto anyway. At least some deployed routers in the middle in some deployments ARE able to validate and therefore trust the AH values (and trust that the IP options present were placed there by the sender). This was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1). Some other kinds of middleboxes (e.g. some firewalls) also can do this. Some AH implementations that support asymmetric keying go back at least 15 years, although those were not standardised back in 1995 -- primarily due to IPR considerations on intermediate authentication (which IPR I believe either has expired or expires very soon). >> Similarly, AH protects many IP header fields from in-transit >> modification, whereas ESP encapsulation provides no protection >> for the 1st (outer) IP header (i.e., that appears before the ESP header). > > So I don't buy that. The IP header is not protecting the packet from > a router, which cannot confirm the crypto of that protection. Some deployed IPv4 routers can confirm the AH authentication information in some deployments. This has been true for years. Note that RFC-1826, Section 1.1, contains explicit discussion of the applicability of AH with asymmetric algorithms to enable intermediate authentication. > What this > is really about is exposing things like QoS bits, No. IETF standards say that the IP ToS/DiffServ bits are allowed to be modified in-transit. For example see Section 7.2 of RFC-2474 & also page 10 of RFC-2402. > but those devices > acting on those are not verifying any "protection". They are blindly > using the exposed options. So ESPinUDP works equally well here. No. >> As a prior discussion has noted, AH can and is used to provide >> cryptographic protection to some security-critical IP options >> (e.g. sensitivity labels). ESP-NULL is not capable of protecting >> those options. > > I'm not sure what you are referring to here. Not labeled IPsec I > take it? And again, how does this "protection" work? How do the > routers verify this "protection" when only the endpoints know > the crypto keys used to protect the header and payload? As an example, one can have (and real deployments exist) where an IPv4 sensitivity label (e.g. FIPS-188) in an IPv4 packet is protected by AH, using asymmetric cryptography, where both end systems and also intermediate label-policing IP routers can validate the digital signatures carried by AH to validate that the sensitivity label has not been tampered with since it was placed in the packet by the sender. Not all deployments where FIPS-188 is in use also use/deploy AH for protection, but some FIPS-188 deployments definitely do. - ESP-in-UDP can NOT do this. - ESP-NULL can NOT do this in any other way either. > Can you explain how this protection works? If an AH packet flies by, > and I change the QoS option from off to on to give my packet preference > in the network, how will the next router notice this and ignore > this QoS option? As noted above, the IP ToS/DiffServ byte explicitly is excluded from AH protection, originally because some deployed routers were known to change the field in-transit (RFC-2402) and later (after RFC-2474) because IETF standards explicitly say that modifying that field in-transit is allowed. >> Some deployments definitely do care. Other deployments do not. > > By understanding was always that people didn't like options getting > "lost" or "hidde" within the ESP payload, and not getting set on > the outer packet. While some people might have that view, that never has been a universal view. Broadly speaking, the primary case against using any IP option is that *historically* the presence of an IP option in an IP packet caused that packet to be forwarded on the "slow path" of many commercial IP routers. That is not necessarily the case today, although it reportedly still is the case for some products. A commercial router vendor that I worked a decade ago for shipped silicon that could fast-path, at wire-speed, for then high-speed interfaces (i.e., 10 Gbps) packets containing options -- simply because the silicon included logic to parse around the option to locate the start of the upper-layer header and apply any needed transport-protocol/port-number ACLs. As I noted during this past Sunday's IEPG meeting, I know of at least one other vendor with an independent implementation in silicon (ASIC or FPGA) that can parse packets at wire speed (e.g. can find the TCP header and TCP port numbers and apply an ACL using an ASIC in a packet with IPv6 header + IPv6-Dest-Opts-Header + TCP). So the performance argument against IP options might be diminishing. Despite that, some IP options have been in use in some deployments since the late 1980s (at least since BLACKER was deployed -- for example see RFC 1038). The bottom line for AH is this: - AH is optional to implement, so it is a business decision whether a particular product implements it or not. Many many products do implement AH, both now and in the past. - Implementations of AH with asymmetric cryptography also exist and are deployed both now and in the past. - Real deployments exist that use AH to protect IP options in transit, including intermediate authentication of the AH contents by some deployed IP routers. - Real applications exist where AH is the only solution available (i.e. no form of ESP can provide the needed protection and no other IETF protocol can provide the needed protection). - It is always possible to parse past an AH header to find an upper-layer header. Despite work on heuristics, there is no 100% reliable way to parse past the SPI field of an ESP header. So I believe that AH meets all the IETF criteria (e.g., use case, implementation, & deployment) for being retained as is. No one is forced to use AH or implement AH if one doesn't care to do so. However, for some deployments, there is no technical alternative to using AH at present. Yours, Ran From nobody Tue Mar 4 01:55:07 2014 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 3E5571A0496 for ; Tue, 4 Mar 2014 01:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547] 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 RzOVSgX0gFwN for ; Tue, 4 Mar 2014 01:55:01 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id B01CE1A049F for ; Tue, 4 Mar 2014 01:55:01 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DA8E4800AF; Tue, 4 Mar 2014 04:54:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1393926896; bh=IU6RNJox2incXwkB/+B6h14QMi+pPhVO6RAad+aFJAU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ocb8lrUT1QqwYxagPc+TrI86q4m/zUtdyuoZW/GEbt5Y2aIIzJUd7xyrXn2pWEOcW otsLNpFQkayyUppbeQBafElNZTAuJsUQM2yL1CXNkv21lTzbtsUF6wAsY+3AYWrWhd +Sn5O2KbOiTgWGItcTJpVZhOQmJ72WrTco5qY8xA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s249suu5002536; Tue, 4 Mar 2014 04:54:56 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 4 Mar 2014 04:54:56 -0500 (EST) From: Paul Wouters To: Valery Smyslov In-Reply-To: <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> Message-ID: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/xlZJoegZcxy5aID1wVBIVaqQodM Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 09:55:05 -0000 On Tue, 4 Mar 2014, Valery Smyslov wrote: > I agree this may chocke some implementations. The idea was that > if implementation notice that Auth Method is NULL, it must > not parse ID Payload at all. But I understand that depending > on the order in which payloads are processed by particular > implementation, this may be inconvinient for implementers. I have actually thought about a mode where we scramble the order or payloads just to see which implementations would die :P No implementation should depend on the order of payloads for anything. > and require implementations to use it if they want to keep anonimity. I feel someone wants to give an implementation the freedom to make an unwise decision :P I really want to insist that anonymous means anonymous - no methods for sending along an ID. >> Actually I now noticed you changed the "SHOULD be ignored" to "MUST be >> ignored", and I think that is again bad idea. I think logging and >> auditing the ID for problem solving purposes is good idea even if it >> does not have any meaning for the authentication. I.e. at least then I >> can contact helpdesk and say that my NULL authentication connection to >> server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID >> payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it >> from your logs... > > Actually, I tried to address Paul Wouters' concern that without > strong "MUST" here implementations may use ID even if it is > not authenticated. But, from my understanding of the wording, > "MUST be ignored by IKE" doesn't mean that implementation > is not allowed to log the ID, that is always useful ror auditing > and troubleshooting. I probably should make this more clear. And I feel that I need to reject anonymous connections that have an ID to protect the anonymity of the user. Paul From nobody Tue Mar 4 01:59:34 2014 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 ADB921A04A4 for ; Tue, 4 Mar 2014 01:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 lgPuVnkETrPU for ; Tue, 4 Mar 2014 01:59:29 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 92D2F1A049D for ; Tue, 4 Mar 2014 01:59:29 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 31A65800AF; Tue, 4 Mar 2014 04:59:26 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s249xPGt002698; Tue, 4 Mar 2014 04:59:25 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 4 Mar 2014 04:59:25 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: RJ Atkinson In-Reply-To: Message-ID: References: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Qs9e0c7FFH-dI90RhtUb9smIMzk Cc: IPsec ME WG List Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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, 04 Mar 2014 09:59:31 -0000 On Tue, 4 Mar 2014, RJ Atkinson wrote: >> What meaning has "protecting" those bits? Endpoint A and B protect >> something by cryptography, but any router in the middle can't trust >> those signatures anyway. So I don't see how AH is different from >> ESPinUDP where you set those options in the UDP header. These are >> not "protected" but the router can't verify the crypto anyway. > > At least some deployed routers in the middle in some deployments > ARE able to validate and therefore trust the AH values (and trust > that the IP options present were placed there by the sender). This > was ALWAYS something that was designed-in to AH (RFC-1826, Section 1.1). > Some other kinds of middleboxes (e.g. some firewalls) also can do this. I was not aware of such deployments. Thanks for the information. Paul From nobody Tue Mar 4 02:06:27 2014 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 A431A1A0545 for ; Tue, 4 Mar 2014 02:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JYLOhtPL1F2d for ; Tue, 4 Mar 2014 02:06:21 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id B71EE1A0535 for ; Tue, 4 Mar 2014 02:06:20 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 89DBD800AF; Tue, 4 Mar 2014 05:06:17 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s24A6H6A003109; Tue, 4 Mar 2014 05:06:17 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 4 Mar 2014 05:06:17 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yaron Sheffer In-Reply-To: <53150A87.6030305@gmail.com> Message-ID: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <53150A87.6030305@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/vlg_yLjpVMXaTm0GcukLypnLqdM Cc: "ipsec@ietf.org WG" , Valery Smyslov , Tero Kivinen Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 10:06:25 -0000 On Tue, 4 Mar 2014, Yaron Sheffer wrote: > Quoting from the abstract: "This method may be used to preserve anonymity or > in situations, where no trust relationship exists between the parties." You > seem to assume that all clients want to be anonymous. IMHO "unauthenticated" > does not necessarily imply "anonymous". When I talk to someone on the plane > and they tell me their name, they are not authenticated and they may well be > lying. But in general, they are not anonymous either. I'm really afraid of accidental leakage by implementors or administrators. In this era, I think we should really make an effort to protect against that. I really think it is a fundemantal problem if we allow an IPsec entity to lie about its identity. Right now, an identity is always proven by an authentication, and I think if there is no authentication, there should be no identity. If you want debugging, you can send some kind of implementation specific custom payload - don't piggyback on auth-none. Paul From nobody Tue Mar 4 02:06:44 2014 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 3FC0A1A0545 for ; Tue, 4 Mar 2014 02:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 dA1vZSPeZ1A5 for ; Tue, 4 Mar 2014 02:06:30 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id B3FC81A056D for ; Tue, 4 Mar 2014 02:06:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s24A6HWC000116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Mar 2014 12:06:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s24A6Hga029737; Tue, 4 Mar 2014 12:06:17 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21269.42393.747107.339481@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 12:06:17 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/BjOmtSvrLCD4sdR5FAkHd_8XSrQ Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 10:06:38 -0000 Paul Wouters writes: > > Actually I now noticed you changed the "SHOULD be ignored" to "MUST be > > ignored", and I think that is again bad idea. I think logging and > > auditing the ID for problem solving purposes is good idea even if it > > does not have any meaning for the authentication. I.e. at least then I > > can contact helpdesk and say that my NULL authentication connection to > > server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID > > payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it > > from your logs... > > I disagree strongly. The point here is that the client is anonymous. We > should not add things that can be traced to a user. Someone will badly > abuse this "feature" like you are suggesting for "diagnostics" and > inadvertly compromise the client's anonimity. I guess you have never done any helpdesk support trying to help people who complain that something that does not work? Having something there that would help support to find your items in the logs is always useful. The client does not have to put anything there if they do not like it, and the default setting should be that there is nothing, but allowing such things will make things easier for those poor souls doing helpdesk. I myself need to sometimes help people complaining about email problems in the iki.fi (email forwarder), and it is really hard to try to find specific email from the logs, especially as there is problems with timezones, and delays and so on, so exact time when the email was sent does not really help. Sometimes they are able to find message-id of the problematic email or the queue id in our end, and then it is so easy to find the entries in the logs and pinpoint the problem. I think the most important point of this feature is that the client is UNAUTHENTICATED, not that it is ANONYMOUS. If you want to have anonymity then you need to use TOR or similar, this is not enough. Your IP address etc will give your identity out in most cases anyways. Even if your IP address is not same than normally, your browser using the same IP address at same time will give out browser fingerprint that will most likely uniquely identify you when used with combination that you are also using null authentication in IPsec and connecting to the host X. We should understand what this feature offers, and what it can be used for. Anonymity is not offered by this feature. -- kivinen@iki.fi From nobody Tue Mar 4 02:41:00 2014 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 CEDA51A049D for ; Tue, 4 Mar 2014 02:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 JBxrPXXheOcD for ; Tue, 4 Mar 2014 02:40:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id E6B911A0450 for ; Tue, 4 Mar 2014 02:40:56 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s24AenBF020377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Mar 2014 12:40:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s24Aen2P000039; Tue, 4 Mar 2014 12:40:49 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21269.44464.979543.950214@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 12:40:48 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 11 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Sk5lE82_BqewJmYEiLn7tmMCU90 Cc: ipsec@ietf.org, Valery Smyslov Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 10:40:59 -0000 Paul Wouters writes: > On Tue, 4 Mar 2014, Valery Smyslov wrote: > > > I agree this may chocke some implementations. The idea was that > > if implementation notice that Auth Method is NULL, it must > > not parse ID Payload at all. But I understand that depending > > on the order in which payloads are processed by particular > > implementation, this may be inconvinient for implementers. > > I have actually thought about a mode where we scramble the order or > payloads just to see which implementations would die :P That only works for RFC5996 version, RFC4306 version are allowed to reject packets which have payloads in "wrong" order: >From RFC4306: ---------------------------------------------------------------------- 2.5. Version Numbers and Forward Compatibility ... Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations MUST send the payloads defined in this specification in the order shown in the figures in section 2 and implementations SHOULD reject as invalid a message with those payloads in any other order. ---------------------------------------------------------------------- RFC5996: ---------------------------------------------------------------------- 2.5. Version Numbers and Forward Compatibility ... Although new payload types may be added in the future and may appear interleaved with the fields defined in this specification, implementations SHOULD send the payloads defined in this specification in the order shown in the figures in Sections 1 and 2; implementations MUST NOT reject as invalid a message with those payloads in any other order. ---------------------------------------------------------------------- > No implementation should depend on the order of payloads for anything. True, but for example my implementation do parse all payloads first, and then start processing them by first checking certain payload, then checking the payloads in suitable order (i.e check that all require payloads are there, then check whether payloads have suitable values etc). This is done just this way so it does not matter in which order the payloads in the incoming packets are. I will find the ID payload regardless where it is, when I need it. And for example my ID parsing code already checks that there must be 4 bytes of data, if the ID type is ID_TYPE_IPV4_ADDR, and will return error immediately there if that is not true. This is way before I even start checking what is the authentication type etc. Of course I could move that checking to later, i.e when actually using the ID payload, but that would have its own issues. > > and require implementations to use it if they want to keep anonimity. > > I feel someone wants to give an implementation the freedom to make an > unwise decision :P I really want to insist that anonymous means > anonymous - no methods for sending along an ID. This is not anonymous method, this is unauthenticated method. We cannot really provide anonymity with this method. > And I feel that I need to reject anonymous connections that have an ID > to protect the anonymity of the user. But should you reject unauthenticated connections just because they have ID which you are not authenticating anyways. Note, that we are talking about unauthenticated connections, not really anonymous connections. -- kivinen@iki.fi From nobody Tue Mar 4 03:02:25 2014 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 827531A029F for ; Tue, 4 Mar 2014 03:02:23 -0800 (PST) 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 4k3E59t69VBA for ; Tue, 4 Mar 2014 03:02:22 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2A1A0450 for ; Tue, 4 Mar 2014 03:02:21 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id w7so5484869lbi.34 for ; Tue, 04 Mar 2014 03:02:18 -0800 (PST) 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=84POlnXjCYyOHPB5kT5nNlBu4spzVQGlw0JupU9aL6w=; b=ywHtII5k656D85K5bgA1ImkDVkWykWue7oAav6ucybkUYVIvb3wI1dGMX8Bij40eBt vKbdcI62Ese1ma9kzHJnreDchFnQMqr7r1+QMwWYH8xJEVKic2tgFBpV6ZWJS38vg1oQ Gh2k9DTibcqxrDKZs/BbNBrtS5GTAP8mwbWVTCKN46iCst3xmzEe7gyLtYFWVNC5MHM6 pAnaZE7AkOUg6JLFo4DZrcZVoAKopUINuVMP4r0LFT09oiIfQj8pXgzpPeY2HIL+QcfI wtRHaugv6TzJaWWTgEboonRVvb/Msp5adj1Di9TtxYOqv5elJG+r8TjUZHFlF08+pV9I iDlQ== X-Received: by 10.112.200.201 with SMTP id ju9mr19279lbc.76.1393930937965; Tue, 04 Mar 2014 03:02:17 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id q6sm34690960lal.3.2014.03.04.03.02.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Mar 2014 03:02:17 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> Date: Tue, 4 Mar 2014 15:02:34 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/QmZDadP_YmsI2Pu_h8MOeQu4KE4 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 11:02:23 -0000 Hi Paul, >> I agree this may chocke some implementations. The idea was that >> if implementation notice that Auth Method is NULL, it must >> not parse ID Payload at all. But I understand that depending >> on the order in which payloads are processed by particular >> implementation, this may be inconvinient for implementers. > > I have actually thought about a mode where we scramble the order or > payloads just to see which implementations would die :P > > No implementation should depend on the order of payloads for anything. The order payloads are processed is not necessary the order payloads appear in the message. Nobody (at least not me) tells that payloads must be processed in the order they appear in the message, but you still process payloads in some order. For example, you first try fo collect all VID payloads too understand what non-standard things you may expect from the message, before you start processing other payloads, don't you? So, I just meant, that if ID Payload is processed before AUTH Payload (a very natural behaviour, isn't it?), that implementation may not be prepared to get "scrambled" ID and it may choke it. But actually, it doesn't matter, because if implementation supports NULL Auth, it must be prepared to get any ID, and if it doesn't, then exchange will fail anyway. >> and require implementations to use it if they want to keep anonimity. > > I feel someone wants to give an implementation the freedom to make an > unwise decision :P I really want to insist that anonymous means > anonymous - no methods for sending along an ID. I just want to allow user to keep his anonimity to the extent he wishes himself. From my understanding the peer, who uses NULL Auth, must have freedom to decide whether to put something in ID (for any reason), or leave it empty. And note, that the draft encourages users (by SHOULD) to do the latter. Regards, Valery. From nobody Tue Mar 4 03:08:51 2014 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 BE2FF1A06E3 for ; Tue, 4 Mar 2014 03:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Js2yuZz29OJo for ; Tue, 4 Mar 2014 03:08:48 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8431A06CD for ; Tue, 4 Mar 2014 03:08:48 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6AD90800AF; Tue, 4 Mar 2014 06:08:44 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s24B8h1b005345; Tue, 4 Mar 2014 06:08:44 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 4 Mar 2014 06:08:43 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Tero Kivinen In-Reply-To: <21269.44464.979543.950214@fireball.kivinen.iki.fi> Message-ID: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <21269.44464.979543.950214@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/wK8ibqYuy_hduM8fBYjmLQcq9IU Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 11:08:51 -0000 On Tue, 4 Mar 2014, Tero Kivinen wrote: >> I have actually thought about a mode where we scramble the order or >> payloads just to see which implementations would die :P > > That only works for RFC5996 version, RFC4306 version are allowed to > reject packets which have payloads in "wrong" order: I did not realise IKEv1 did not allow that. How quaint.... > And for example my ID parsing code already checks that there must be 4 > bytes of data, if the ID type is ID_TYPE_IPV4_ADDR, and will return > error immediately there if that is not true. This is way before I even > start checking what is the authentication type etc. That's exactly how we do it. Parse each payload and store it, throw an immediate error if any of these are wrong. Then lookup the SPIs, find the right state and check if all required payloads are there and all other payloads are valid optional payloads, and only then proceed with processing. > This is not anonymous method, this is unauthenticated method. We > cannot really provide anonymity with this method. Okay, I guess we disagree. >> And I feel that I need to reject anonymous connections that have an ID >> to protect the anonymity of the user. > > But should you reject unauthenticated connections just because they > have ID which you are not authenticating anyways. Yes I think so. You are changing the meaning of ID from implicitely "verified ID" to potentially "unverified ID". I think that is wrong. Paul From nobody Tue Mar 4 03:23:37 2014 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 A75CF1A0721 for ; Tue, 4 Mar 2014 03:23:35 -0800 (PST) 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 7nwWHoQJC7mc for ; Tue, 4 Mar 2014 03:23:34 -0800 (PST) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BADC21A0713 for ; Tue, 4 Mar 2014 03:23:33 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id hr17so5536316lab.33 for ; Tue, 04 Mar 2014 03:23:29 -0800 (PST) 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=o20g0Va+86lB24mhECM6LpHMXE1+PIrfp12IhIBOcBc=; b=yWqYQrRJMjQO84XH6fMxyv1wezme2nd4vCAwrSsvWviV+N5vGRjsK0YJUKAaX0xYGd SOpLuUS3K3BWdT4gGm6RZSYxMyTC7uSEWOW8jIU7Dw6REyvm8zQyI1wuNaoyJbXme7Iz Z/xOX3RfQSJ26cK31UfgNGxBS7aSKSecUOJTt0zqIsrFnfYILFTMfIXXCCMga1R2PA6P 5U3xcyh1UpMeGAaHcjTbW/i4fWfPZNWOvqbc5vA7Qg9YCOLyfBoCOUiQy4Mt8MVDgSM6 0QydQRXVa63d/9dCRCdlyMA/F6ISXoTEAVtlqCOOEoG5K29JZp8f9584fIaD+HdIfZV1 eeLQ== X-Received: by 10.152.9.1 with SMTP id v1mr14596298laa.31.1393932209633; Tue, 04 Mar 2014 03:23:29 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id mo3sm19355981lbb.17.2014.03.04.03.23.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Mar 2014 03:23:28 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" , "Tero Kivinen" References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <21269.44464.979543.950214@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 15:23:46 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/lroKP2gXaJVAtvyfnXTQgCnLEL4 Cc: ipsec@ietf.org Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 11:23:36 -0000 >> But should you reject unauthenticated connections just because they >> have ID which you are not authenticating anyways. > > Yes I think so. You are changing the meaning of ID from implicitely > "verified ID" to potentially "unverified ID". I think that is wrong. But what prevent you from throwing away ID content in this case, as you know that it is unauthenticated (you may even not to log it), and allow user to connect? User has already exposed the content of ID, the damage (if any) has already occured, so what you will you protect by rejecting the connection? Regards, Valery. > Paul From nobody Tue Mar 4 03:28:01 2014 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 4D67C1A0727 for ; Tue, 4 Mar 2014 03:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 oC1ttpTA481k for ; Tue, 4 Mar 2014 03:27:57 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2541A06B9 for ; Tue, 4 Mar 2014 03:27:56 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s24BRkP2013406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Mar 2014 13:27:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s24BRkSk019928; Tue, 4 Mar 2014 13:27:46 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21269.47282.170859.595467@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 13:27:46 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <21269.44464.979543.950214@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 13 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ezg4RUyMZZ-k_iEyYIoKQ_QN5E8 Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 11:28:00 -0000 Paul Wouters writes: > On Tue, 4 Mar 2014, Tero Kivinen wrote: > > >> I have actually thought about a mode where we scramble the order or > >> payloads just to see which implementations would die :P > > > > That only works for RFC5996 version, RFC4306 version are allowed to > > reject packets which have payloads in "wrong" order: > > I did not realise IKEv1 did not allow that. How quaint.... IKEv1 did allow sending payloads in any order, if I remember right. RFC4306 is original IKEv2, not IKEv1... > > But should you reject unauthenticated connections just because they > > have ID which you are not authenticating anyways. > > Yes I think so. You are changing the meaning of ID from implicitely > "verified ID" to potentially "unverified ID". I think that is wrong. The draft name is null-auth, and for me that means there is no authentication. The abstract says it "may be used to preserve anonymity" (one use case, it does not say it do provide anonymity), and another use case is "in situations, where there no trustrelationship exists between the parties.". This second use case does not have anything to do with anonymity just unauthenticated connections. And the whole idea is to "omit peer authentication". Hmm... funny typo in section 1: o User wants to get anonymous access to some resource. In this situation he/she should be able to authenticate server, but to leave out his/her own authentication to prevent anonymity. In this case one-way authentication is desirable. user will leave out authentication to PREVENT anonymity... I assume preserve is the one word that was meant... The second use case does not require any anonymity: o Two peers without any trust relationship want to get some level of security in their communications. Without trust relationship they cannot prevent active Man-in-the-Middle attacks, but it is still possible to prevent passive eavesdropping with opportunistic encryption. In this case they have to perform unauthenticated key exchange. Actually even the first use case, having non-authenticated identity would still be useful in some cases. For example if I will protect my home server with null-authenticated IPsec, people most likely will still want to verify my servers authentication, and they might want to provide meaningful unauthenticated ID, even when it is not needed. The meaningful ID might be something that is not meaningful in global context, but it might be meaningful for me, i.e. just nickname or similar. If they want to do something where I would require them to do authentication then I would most likely still use my (self signed) certificate based authentication for server (with certificate pinning and TLSA records in DNSSEC signed zone), and they would use similar locally meaningful ID and raw public key to authenticate themselves to my server. I.e. I will see the upgrade path from null-auth -> raw public keys very logical in small private use setups. -- kivinen@iki.fi From nobody Tue Mar 4 03:35:39 2014 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 011CE1A0710; Tue, 4 Mar 2014 03:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, T_REMOTE_IMAGE=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 az7NFLs3l1Ok; Tue, 4 Mar 2014 03:35:29 -0800 (PST) Received: from acheron.ifi.lmu.de (acheron.ifi.lmu.de [IPv6:2001:4ca0:4000:1:129:187:214:135]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1E71A0703; Tue, 4 Mar 2014 03:35:29 -0800 (PST) Received: from TobiIdeaPad (unknown [IPv6:2001:67c:370:160:1808:37a0:831f:d853]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: guggemos) by acheron.ifi.lmu.de (Postfix) with ESMTPSA id 6E82F94A0CC; Tue, 4 Mar 2014 12:35:25 +0100 (CET) From: "Tobias Guggemos" To: , Date: Tue, 4 Mar 2014 11:35:36 -0000 Message-ID: <012001cf379d$ddc4f760$994ee620$@stud.ifi.lmu.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0121_01CF379D.DDC71A40" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac83nVrWJjL0rRg9Tq6qFucLAUi7PQ== Content-Language: de X-Antivirus: avast! (VPS 140302-1, 02.03.2014), Outbound message X-Antivirus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/m0sef72ZW5s33vB_22FSYcPLRIg Subject: [IPsec] New Draft Version: Diet-ESP 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, 04 Mar 2014 11:35:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0121_01CF379D.DDC71A40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, Please find a draft we have just posted. It is updated with some of the comments from the mailinglist and moved from dice to ipsecme WG. Comments are welcome, A new version of I-D, draft-mglt-ipsecme-diet-esp-00.txt has been successfully submitted by Tobias Guggemos and posted to the IETF repository. Name: draft-mglt-ipsecme-diet-esp Revision: 00 Title: Diet-ESP: a flexible and compressed format for IPsec/ESP Document date: 2014-03-03 Group: Individual Submission Pages: 26 URL: http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-diet-esp-00.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/ Htmlized: http://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-00 Abstract: IPsec/ESP has been designed to secure IP packets exchanged between two nodes. IPsec implements security at the IP layer which makes security transparent to the applications, as opposed to TLS or DTLS that requires application to implement TLS/DTLS. As a result, IPsec enable to define the security rules in a similar way one establishes firewall rules. One of the IPsec's drawbacks is that implementing security on a per packet basis adds overhead to each IP packet. Considering IoT devices, the data transmitted over an IP packet is expected to be rather small, and the cost of sending extra bytes is so high that IPsec/ESP can hardly be used for IoT as it is currently defined in RFC 4303. This document defines Diet-ESP, a protocol that compress and reduce the ESP overhead of IPsec/ESP so that it can fit security and energy efficient IoT requirements. Diet-ESP use already existing mechanism like IKEv2 to negotiate the compression format. Furthermore a lot of information, already existing for an IPsec Security Association, are reused to offer light negotiation in addition to maximum compression. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ------=_NextPart_000_0121_01CF379D.DDC71A40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

Please find a draft we have just posted. It is upd= ated with some of the comments from the mailinglist and moved from dice to = ipsecme WG.

Comments are welcome,

 

 

A new version of I-D, draft-mglt-ipsecme-diet-esp-00.txt

has been successfull= y submitted by Tobias Guggemos and posted to the IETF repository.

 

Name:      &n= bsp;          draft-mglt-ipsec= me-diet-esp

Revisi= on:            = 00

Title:&= nbsp;           &nbs= p;       Diet-ESP: a flexible and compressed = format for IPsec/ESP

Document date:        &nb= sp;      2014-03-03

Group:     &nbs= p;           Individual S= ubmission

P= ages:           &nbs= p;      26

URL:       &nbs= p;    http://www.ietf.org/= internet-drafts/draft-mglt-ipsecme-diet-esp-00.txt

Statu= s:         https://datatracker.ietf.org/doc/draft-mglt-ipsecme-diet-esp/

Htmlized:       http://tools.ietf.org/html/draft-mglt-ipsecme-diet-esp-00

 

<= o:p> 

Abstr= act:

 =   IPsec/ESP has been designed to secure IP packets exchanged between

  = two nodes.  IPsec implements security at the IP layer which makes

   s= ecurity transparent to the applications, as opposed to TLS or DTLS

   that r= equires application to implement TLS/DTLS.  As a result, IPsec

   enabl= e to define the security rules in a similar way one establishes<= /span>

   firewall = rules.

 

 &n= bsp; One of the IPsec's drawbacks is that implementing security on a per

   = packet basis adds overhead to each IP packet.  Considering IoT

   devic= es, the data transmitted over an IP packet is expected to be

   rather small= , and the cost of sending extra bytes is so high that

=

   IPsec/ESP can hardl= y be used for IoT as it is currently defined in

   RFC 4303.

 

   This document def= ines Diet-ESP, a protocol that compress and reduce

   the ESP overhead of IP= sec/ESP so that it can fit security and energy

   efficient IoT requirements= =2E  Diet-ESP use already existing mechanism

   like IKEv2 to negotiate= the compression format.  Furthermore a lot of

   information, already = existing for an IPsec Security Association, are

   reused to offer light neg= otiation in addition to maximum compression.

 

       &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;           

 =

 

Please note that it may t= ake a couple of minutes from the time of submission until the htmlized vers= ion and diff are available at tools.ietf.org.

 

The IETF Secretariat

 

 



Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.


------=_NextPart_000_0121_01CF379D.DDC71A40-- From nobody Tue Mar 4 03:46:48 2014 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 23B041A0041 for ; Tue, 4 Mar 2014 03:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.161 X-Spam-Level: X-Spam-Status: No, score=-0.161 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, 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 w3blTn8AV4Ve for ; Tue, 4 Mar 2014 03:46:46 -0800 (PST) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id E11EA1A0033 for ; Tue, 4 Mar 2014 03:46:45 -0800 (PST) Received: by mail-la0-f53.google.com with SMTP id b8so5585216lan.12 for ; Tue, 04 Mar 2014 03:46:42 -0800 (PST) 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=PJCf8yCFnYaz9HODXPGZ2hjr1I24DFutGsJkSanUOaY=; b=M81AIzNYsmLgACWfOxJcib+DRT6iUeba1Bvc34lPS4HmTHmC7B3iqpqubyHQhjSV1F zE6G7UOCv2Qzl4VOCc+Y8V4NrxFwZTEdFwdOlKsFoR/yphgbMxmr/MG+cNNvq/AmntbT PeIdDlyfAO1xXQGWQq2hSKRWiZk3BSis09RKvOALNQkFCiBlIYfgWe/IPOKdFbkMtA6N QfEiThKLJji4nuCY1sZHKwZIIZgdwTRoXFrYNRpV/U/f06C/zLVOMuPRIwQZiwv7GqA/ DIFrpn4GbDsKige0LHS+BzUe30XsncYvINgxmOJ6WQRi+XcnEXFbqhKs9E9kY6aKOOmr tTQg== X-Received: by 10.112.131.66 with SMTP id ok2mr25483968lbb.15.1393933602139; Tue, 04 Mar 2014 03:46:42 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id h7sm19397550lbj.1.2014.03.04.03.46.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Mar 2014 03:46:41 -0800 (PST) Message-ID: <4E18E9585BAC49EABF54E1DC547A4273@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "Paul Wouters" References: <21268.39396.785431.297271@fireball.kivinen.iki.fi><01FD5F789A0A406F9CCFC3033EA6721B@buildpc><21269.44464.979543.950214@fireball.kivinen.iki.fi> <21269.47282.170859.595467@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 15:46:59 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/5xmkySsBRthwB6PzwZvXkGztthY Cc: ipsec@ietf.org Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 11:46:47 -0000 Hi Tero, > IKEv1 did allow sending payloads in any order, if I remember right. Right, but with some restrictions (e.g. HASH Payload in QM must go before other Payloads). > Hmm... funny typo in section 1: > > o User wants to get anonymous access to some resource. In this > situation he/she should be able to authenticate server, but to > leave out his/her own authentication to prevent anonymity. In > this case one-way authentication is desirable. > > user will leave out authentication to PREVENT anonymity... I assume > preserve is the one word that was meant... Yes, of course. Thanks for catching. And in -01 draft I've added one more use case: o User wants to get some simple action from remote device. Consider garage door opener: it must authenticate user to open the door, but it is not necessary for the user to authenticate the door opener. In this case one-way authentication is sufficient. In this example there is no harm if garage door opener fills in its ID Payload - it need not be anonymous. Regards, Valery. From nobody Tue Mar 4 05:04:14 2014 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 595FD1A0143 for ; Tue, 4 Mar 2014 05:04:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 t1B_8VaY6V_G for ; Tue, 4 Mar 2014 05:04:10 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 862181A00A3 for ; Tue, 4 Mar 2014 05:04:10 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6E002800AF; Tue, 4 Mar 2014 08:04:06 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s24D45hD009702; Tue, 4 Mar 2014 08:04:06 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 4 Mar 2014 08:04:05 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Valery Smyslov In-Reply-To: <4E18E9585BAC49EABF54E1DC547A4273@buildpc> Message-ID: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi><01FD5F789A0A406F9CCFC3033EA6721B@buildpc><21269.44464.979543.950214@fireball.kivinen.iki.fi> <21269.47282.170859.595467@fireball.kivinen.iki.fi> <4E18E9585BAC49EABF54E1DC547A4273@buildpc> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/6nq5RoyyXqMBBXqLXe9PFKg0sGE Cc: "ipsec@ietf.org WG" , Tero Kivinen Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 13:04:12 -0000 On Tue, 4 Mar 2014, Valery Smyslov wrote: > And in -01 draft I've added one more use case: > > o User wants to get some simple action from remote device. Consider > garage door opener: it must authenticate user to open the door, > but it is not necessary for the user to authenticate the door > opener. In this case one-way authentication is sufficient. > > In this example there is no harm if garage door opener > fills in its ID Payload - it need not be anonymous. There is harm. An observer could figure out if it is me that's opening the door, or my wife or my kids. If the server (door) does not need it, don't send it. Paul From nobody Tue Mar 4 05:05:10 2014 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 661D91A0150 for ; Tue, 4 Mar 2014 05:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 v92z_JjsD4xS for ; Tue, 4 Mar 2014 05:05:03 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6251A00A3 for ; Tue, 4 Mar 2014 05:05:02 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 30564800AF; Tue, 4 Mar 2014 08:04:59 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s24D4xwO009742; Tue, 4 Mar 2014 08:04:59 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 4 Mar 2014 08:04:59 -0500 (EST) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Valery Smyslov In-Reply-To: Message-ID: References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <21269.44464.979543.950214@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Ikt_oY3GMEKjy3XAwPrdJ3ekxCM Cc: "ipsec@ietf.org WG" , Tero Kivinen Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 13:05:07 -0000 On Tue, 4 Mar 2014, Valery Smyslov wrote: >>> But should you reject unauthenticated connections just because they >>> have ID which you are not authenticating anyways. >> >> Yes I think so. You are changing the meaning of ID from implicitely >> "verified ID" to potentially "unverified ID". I think that is wrong. > > But what prevent you from throwing away ID content in this case, > as you know that it is unauthenticated (you may even not to log it), and > allow user to connect? User has already exposed the > content of ID, the damage (if any) has already occured, > so what you will you protect by rejecting the connection? Making the problem visible to it will not happen in the future. Paul From nobody Tue Mar 4 05:36:53 2014 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 1694D1A019D for ; Tue, 4 Mar 2014 05:36:51 -0800 (PST) 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 DsVg_xbsIQEU for ; Tue, 4 Mar 2014 05:36:49 -0800 (PST) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 38AC91A0193 for ; Tue, 4 Mar 2014 05:36:49 -0800 (PST) Received: by mail-lb0-f169.google.com with SMTP id l4so4826223lbv.0 for ; Tue, 04 Mar 2014 05:36:45 -0800 (PST) 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=2ixYns6jGvNyPxg0Cub1qq1OaRPMhTeDR0bfTz70Mmg=; b=G6cl7I5LR6fqhZVgi8mkWr4HwMkN0HkODmvrkW2QdSos79GXs2gEcxyc2t4VPpK0kZ yu4a6/V6GF4888kjNYhiObgpDrE1nphlqvTTWN32CJqnBGx9xGNNaeRum6uc645dExAu mCdJ1JDKStF2xaVZIZkiV83R4M4BSdcCeP3w1elEXV02KcvBvINdULAKDp0/W/AqVgSe jJkPFouolk39v3TIXsHRjMlICId8Gs/0kV3jec4rmB1v1YHCIbh95PTUfKihbN5ixpfJ OML3lEBmZYjWhzgIcrVt+1B1eQBtVA7rhjJatFjQZp+dMLvfCbeuK90ce0MEI5LahOIR LCwA== X-Received: by 10.152.120.201 with SMTP id le9mr105752lab.68.1393940205373; Tue, 04 Mar 2014 05:36:45 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id x4sm19726176lbn.2.2014.03.04.05.36.43 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Mar 2014 05:36:44 -0800 (PST) Message-ID: <838185E1D9C34EB9B03F46B3F4710117@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <21268.39396.785431.297271@fireball.kivinen.iki.fi><01FD5F789A0A406F9CCFC3033EA6721B@buildpc><21269.44464.979543.950214@fireball.kivinen.iki.fi> <21269.47282.170859.595467@fireball.kivinen.iki.fi> <4E18E9585BAC49EABF54E1DC547A4273@buildpc> Date: Tue, 4 Mar 2014 17:37:02 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/zITvc7Z25rh2l1ZI2LL2ThTI5To Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 13:36:51 -0000 >> o User wants to get some simple action from remote device. Consider >> garage door opener: it must authenticate user to open the door, >> but it is not necessary for the user to authenticate the door >> opener. In this case one-way authentication is sufficient. >> >> In this example there is no harm if garage door opener >> fills in its ID Payload - it need not be anonymous. > > There is harm. An observer could figure out if it is me that's opening > the door, or my wife or my kids. > > If the server (door) does not need it, don't send it. Sorry, you missed the point. In this example user must sent his identity and must authenticate to the door opener (otherwise it will open the door to any stranger). But door opener (responder) need not authenticate itself to the user and may use NULL Auth. It is a reverse situation to the first example in the draft, when initiator uses NULL Auth. What is the harm if door opener sends its unauthenticated identity to you? And what will you do in this case? Reject connection? But remember, that it was you who initiated this connection, and moreover, you are already authenticated and the action you requested (opening the door) has probably already occured, so rejecting connection in this case looks like stupid action. From nobody Tue Mar 4 05:46:36 2014 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 32CEC1A01BF for ; Tue, 4 Mar 2014 05:46:34 -0800 (PST) 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 ElQ9sNGQHhLe for ; Tue, 4 Mar 2014 05:46:32 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 574CB1A0170 for ; Tue, 4 Mar 2014 05:46:32 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id 10so5529865lbg.7 for ; Tue, 04 Mar 2014 05:46:28 -0800 (PST) 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=EDc7BE8D65gmx4nDCKriPADn37WnoPQz+XHoqvECCnY=; b=lmDe+MTrYbUyaZ6/lxQqXCD4ohuEfwnPMVMdZq4DW4bpc+F+QUtFrYH/ZeFZvU7rr3 K9pQjSHYoj+Rz8hoUSuimN/uuJxb7oRtP+u24VVv4t2QGr5aXTtwPWOL94/HMziSljzf kGZEbtfGnCDlPncBNS++8bzNO+qDWvP3NhE/e57wPYOacpw/DQ3LTltLUGzR2ljius6p +1J1HVOfVBkmbDmKfogwHhhY/rjtvnQp/r5hEodqZ9kFBwk0ZnBIATD21Yf5CBoMavzM IlOtMZy+uAiupzCoxmIp0B4McZTl0KqAvzHlkgW93Xeke8TXReVsMzt68A326N9jGfqX 3ejQ== X-Received: by 10.152.234.130 with SMTP id ue2mr17537000lac.0.1393940788439; Tue, 04 Mar 2014 05:46:28 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id zf7sm35360562lab.7.2014.03.04.05.46.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Mar 2014 05:46:27 -0800 (PST) Message-ID: <476582BCCB394DD0A6DB58434ED55486@buildpc> From: "Valery Smyslov" To: "Paul Wouters" References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <21269.44464.979543.950214@fireball.kivinen.iki.fi> Date: Tue, 4 Mar 2014 17:46:45 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/BLki6-hM_MSj6l_6moHANhD3NVw Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 13:46:34 -0000 >> But what prevent you from throwing away ID content in this case, >> as you know that it is unauthenticated (you may even not to log it), and >> allow user to connect? User has already exposed the >> content of ID, the damage (if any) has already occured, >> so what you will you protect by rejecting the connection? > > Making the problem visible to it will not happen in the future. If you consider it as a problem, than there ara other means to make it visible, e.g. audit that something is probably wrong. But you said: >> And I feel that I need to reject anonymous connections that have an ID >> to protect the anonymity of the user. And I just wonder how you are going to protect user's anonimity if user himself has already exposed his identity. From nobody Tue Mar 4 13:15:28 2014 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 19CE01A02F8 for ; Tue, 4 Mar 2014 13:15:24 -0800 (PST) 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 QyEiRTcCe_rv for ; Tue, 4 Mar 2014 13:15:21 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2021A02D6 for ; Tue, 4 Mar 2014 13:15:21 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id t61so126832wes.16 for ; Tue, 04 Mar 2014 13:15:17 -0800 (PST) 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=97J+OrqOzxiPadxroIs9B2RPzG6Z0zt4kshgiEknruM=; b=SAy+eu0U6cvmFJ925+oAy58LKttNVyLpAKIUGHznW9SC1xrnqc5ntr3eajStb9ZW+i i5f51TtU4QkfaCo9en64rdqQr+dXkntVodkOgY4SczYttcw0e3KN099H6GmiinMWqAjK LdUn1M0Cb1xkKeGB0V3vubHEzfYVgQBc0YeB95ykfWPi59vIUVHmcbhho5QtO6bor+Nx EkIn/GGtaBAGwtB4u/tkvkfgP+KT3l3NEPQSWtyvyYI6L2c6G9pK4Wo+VMUBQMO+/bvW JOmmENyD3NpZL/t2gnelFhIHmCCcHZxTJAXioku7Kyt6viWKDUyPITSwtkLKBudtIYS+ s5Tw== X-Received: by 10.195.12.102 with SMTP id ep6mr2717224wjd.76.1393967717655; Tue, 04 Mar 2014 13:15:17 -0800 (PST) Received: from [10.0.0.6] ([109.65.63.189]) by mx.google.com with ESMTPSA id ci4sm621282wjc.21.2014.03.04.13.15.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 13:15:17 -0800 (PST) Message-ID: <53164262.6010700@gmail.com> Date: Tue, 04 Mar 2014 23:15:14 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Tero Kivinen , Paul Wouters References: <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <21269.44464.979543.950214@fireball.kivinen.iki.fi> <21269.47282.170859.595467@fireball.kivinen.iki.fi> In-Reply-To: <21269.47282.170859.595467@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/L12x5_Pqb8jTIsCDVgcbbA9EmtU Cc: "ipsec@ietf.org WG" , Valery Smyslov Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.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: Tue, 04 Mar 2014 21:15:24 -0000 > > The second use case does not require any anonymity: > > o Two peers without any trust relationship want to get some level of > security in their communications. Without trust relationship they > cannot prevent active Man-in-the-Middle attacks, but it is still > possible to prevent passive eavesdropping with opportunistic > encryption. In this case they have to perform unauthenticated key > exchange. > > Actually even the first use case, having non-authenticated identity > would still be useful in some cases. For example if I will protect my > home server with null-authenticated IPsec, people most likely will > still want to verify my servers authentication, and they might want to > provide meaningful unauthenticated ID, even when it is not needed. The > meaningful ID might be something that is not meaningful in global > context, but it might be meaningful for me, i.e. just nickname or > similar. > > If they want to do something where I would require them to do > authentication then I would most likely still use my (self signed) > certificate based authentication for server (with certificate pinning > and TLSA records in DNSSEC signed zone), and they would use similar > locally meaningful ID and raw public key to authenticate themselves to > my server. > > I.e. I will see the upgrade path from null-auth -> raw public keys > very logical in small private use setups. > And once we start using raw public keys (or self signed certs), we can use out-of-band means to upgrade the identity from "claimed but unauthenticated" to "authenticated". This is what we're proposing in AutoVPN. Thanks, Yaron From nobody Wed Mar 5 15:01:33 2014 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 8DEB71A0242 for ; Wed, 5 Mar 2014 15:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 JAPPQRh3Oe9i for ; Wed, 5 Mar 2014 15:01:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2561A023C for ; Wed, 5 Mar 2014 15:01:28 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s25N1Lv4012687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Mar 2014 01:01:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s25N1LDf024188; Thu, 6 Mar 2014 01:01:21 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21271.44225.752369.306111@fireball.kivinen.iki.fi> Date: Thu, 6 Mar 2014 01:01:21 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 43 min X-Total-Time: 47 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/l3XndaqRko5ka9ck-NiQlLQhqz8 Subject: [IPsec] Comments to draft-mglt-ipsecme-clone-ike-sa-00.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: Wed, 05 Mar 2014 23:01:31 -0000 In the section 4. Protocol Overview, the draft says: The current IKE_SA becomes the old IKE_SA and the newly negotiated IKE_SA becomes the new IKE_SA. What the draft does not specify what happens to the Child SAs present on the old IKE SA. Are they moved to the new IKE SA or are they staying at the old. I would expect them to stay, as we just create clone of the IKE SA, but as in normal IKE SA rekey they move, this needs to be specified. Also in the sentence: If the Initiator does not want or does not care that two parallel IKE SA exists, the CLONE_IKE_SA Notify Payload SHOULD be omitted. Remove the useless SHOULD. If initiator does not want to create IKE SA clone, of course it does not include the notify specifying that it wants clone. I.e change text to: If the Initiator does not want or does not care that two parallel IKE SA exists, it will not include CLONE_IKE_SA Notify Payload in the IKE SA rekey exchange. In the next sentence there is text: The CLONE_IKE_SA Notify Payload is always part of a CREATE_CHILD_SA IKEv2 exchange. I think it would be good to specify here too that it is always part of a CREATE_CHILD_SA IKEv2 exchange rekeying IKE SA. In the same section there is text saying: The responder supports the CLONE_IKE_SA Notify Payload as it provided a CLONE_IKE_SA_SUPPORTED Notify Payload. If the CREATE_CHILD_SA request concerns a IKE_SA rekey. The responder MUST proceed to the IKE_SA rekey, create the new IKE_SA, and keep the old IKE_SA and respond with a CLONE_IKE_SA Notify Payload as represented below: I would expect there are situations where the responder does not want to allow IKE SA to be cloned, for example when it is running out of IKE SAs (i.e. too many clones). This text says the responder MUST do that... also the first two sentences should be connected to the later ones, i.e: The responder has already indicated its support to the CLONE_IKE_SA Notify Payload as it provided a CLONE_IKE_SA_SUPPORTED Notify Payload earlier. When the CREATE_CHILD_SA request with the CLONE_IKE_SA notify is received by the responder, it can either return error (for example NO_ADDITIONAL_SAS) or proceed with the IKE_SA cloning, create the new IKE_SA, and keeping the old IKE_SA and respond with a CREATE_CHILD_SA exchange reply with CLONE_IKE_SA Notify Payload as represented below: Other option would for the responder to just ignore the CLONE_IKE_SA notify and return normal IKE SA rekey packet without doing the cloning, but doing normal IKE SA rekey instead. I think it is better to return NO_ADDITIONAL_SAS in error cases, than to do IKE SA rekey (which initiator didn't want). In section 5, the text about the critical bit could be clarified (there are lots of misunderstanding about it already), i.e. change: - Critical Bit (1 bit): Indicates how the responder handles the Notify Payload. In this document the Critical Bit is not set. to: - Critical Bit (1 bit): Indicates how the responder handles the Notify Payload. As notify payload is mandatory to support in IKEv2, the Critical Bit is not set. In section 7. IANA Considerations, change the: The new fields and number are the following: to This document allocates two new values from the "IKEv2 Notify Message Types - Status Types" registry: The security considerations section requires some fixes and more text: The protocol defined in this document does not modifies IKEv2. It signalizes what has been implementation dependent on how to manage an old IKE_SA after a rekey. s/modifies/modify/ Also I do not think the RFC5996 said that it is implementation dependent on how to manage an old IKE_SA after rekey. It says in section 2.8 that old IKE SA is deleted (RFC5996): After the new equivalent IKE SA is created, the initiator deletes the old IKE SA, and the Delete payload to delete itself MUST be the last request sent over the old IKE SA. It does not give any indication how much you should wait after the creating new IKE SA, but the text saying "initiator deletes the old IKE SA" is quite clear... So I would fix the second sentence to be something better. The security considerations section should also list other attacks, i.e. this method could allow creating more IKE SAs or Child SAs between peers than what would be possible with single IKE SA (for example there might be Child SA limit per IKE SA, and this can be used to bypass that limit or similar). It also might affect auditing and accounting, as now for example only the first IKE SA might cause the account start event to be called, but it might be possible that each IKE SA destroy even will stop accounting. Also accounting might be interested how many clones the IKE SA has, or it might only be interested of the very first and very last IKE SA for the same ID. In appendix B.1 the text: The exchange is completely described in [RFC4555]. First the negotiates the IKE_SA. In the figure below peers also proceed to NAT detection because of the use of MOBIKE. Is missing some words in the second sentence (First the negotiates). In section B.3 fix: Alternatively, the VPN End User MAY uses a different IP address for each interface s/MAY uses/MAY use/ The exchange B.5 is not accoding to the draft, as it has N(CLONE_IKE_SA) inside the IKE_AUTH exchange, and the draft says it can only be in the CREATE_CHILD_SA exchange doing IKE SA rekey. So that kind of optimized negotiation is not possible with current draft. Also I think adding that kind of complexity in the IKE_AUTH is bad idea, so I would simply remove the B.5 example. -- kivinen@iki.fi From nobody Wed Mar 5 15:07:59 2014 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 8477E1A0305 for ; Wed, 5 Mar 2014 15:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 hHcen0mQjV_e for ; Wed, 5 Mar 2014 15:07:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 117241A005C for ; Wed, 5 Mar 2014 15:07:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s25N7k3F011723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 Mar 2014 01:07:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s25N7kr9028067; Thu, 6 Mar 2014 01:07:46 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21271.44610.414071.370642@fireball.kivinen.iki.fi> Date: Thu, 6 Mar 2014 01:07:46 +0200 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/pHiO_QMl_sPRLqj_MaibG-fZn9Y Subject: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01 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, 05 Mar 2014 23:07:53 -0000 In section 2 it says: Note that IKEv2 and IPsec session do not need to be on the same node as IKEv2 and IPsec context are different. This is not so easy. The RFC5996 says: ---------------------------------------------------------------------- 2.4. State Synchronization and Connection Timeouts ... An implementation needs to stop sending over any SA if some failure prevents it from receiving on all of the associated SAs. If a system creates Child SAs that can fail independently from one another without the associated IKE SA being able to send a delete message, then the system MUST negotiate such Child SAs using separate IKE SAs. ---------------------------------------------------------------------- I.e. if any of the IPsec SAs fail, then all of IPsec SAs created using same IKE SA, and the IKE SA must also fail. If IPsec SAs and IKE SA are on separate nodes, that do set up new kind of requirements for those nodes. I.e. if one node having IPsec SAs fails, the node having IKE SA needs to detect this, and send delete notification for each IPsec SA that were in that node. Also if the node having the IKE SA will fail, then all the IPsec SAs associated with that IKE SA, must stop sending, i.e. they needs to be destroyed. -- kivinen@iki.fi From nobody Wed Mar 5 23:42:39 2014 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 99E441A010D for ; Wed, 5 Mar 2014 23:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, 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 bmGHSq38JrWK for ; Wed, 5 Mar 2014 23:42:32 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8B61A0101 for ; Wed, 5 Mar 2014 23:42:32 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id s7so1445064lbd.23 for ; Wed, 05 Mar 2014 23:42:28 -0800 (PST) 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=V8VoOM1I9vaeSGnmf8z0pTOBjiXTvdxtHV4hCLbfD+M=; b=jznLeZEdlk3JTVOKmu4lzZokDggLOQ57EHyLoyASRacT/UZJwkEcqaFki1vXQngwUU fln96zpqpTPvDyeXuKcYJV8+wGyyBQZXe2PXYcoHg1ktpFVswn/pXX8c6R9J1/wN5PLY Jpr0VbsSxeixJm2haY+kBv72lbsO9cZt2Uqw2nYsa4XXMbJVcEvWzjnJSd9dZLnojF47 4q+Uc0doRa6vUcgVBT8pN1jHZzdfg0WbP39MykFym03QuyNfg7WZxBs0JZnkF2IvcNK0 z9IeKq+J6i9VTssEQ3sT3tFN0W0L5Rt3+j7lTmCCz0sqZOMo+5yPgVIHVfmQraZC68eu pX5Q== X-Received: by 10.152.206.42 with SMTP id ll10mr7107504lac.16.1394091747922; Wed, 05 Mar 2014 23:42:27 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id x5sm5339027lbk.5.2014.03.05.23.42.26 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Mar 2014 23:42:26 -0800 (PST) Message-ID: <0ACC9B8EA3184B9FAA2F40EA5173864F@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , References: <21271.44225.752369.306111@fireball.kivinen.iki.fi> Date: Thu, 6 Mar 2014 11:42:18 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/RjNZusLNfNcCURXJh15LxamvWUo Cc: Daniel Migault Subject: Re: [IPsec] Comments to draft-mglt-ipsecme-clone-ike-sa-00.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: Thu, 06 Mar 2014 07:42:34 -0000 Hi Tero, Thanks for reading and commenting the draft. As I'm now a co-author of the draft, I'll try to answer. > In the section 4. Protocol Overview, the draft says: > > The current IKE_SA becomes the old IKE_SA and the newly negotiated > IKE_SA becomes the new IKE_SA. > > What the draft does not specify what happens to the Child SAs present > on the old IKE SA. Are they moved to the new IKE SA or are they > staying at the old. I would expect them to stay, as we just create > clone of the IKE SA, but as in normal IKE SA rekey they move, this > needs to be specified. This is important and it is clarified in the next version (not yet published). You are right, Child SAs stay with old IKE SA. > Also in the sentence: > > If the Initiator does not want or > does not care that two parallel IKE SA exists, the CLONE_IKE_SA > Notify Payload SHOULD be omitted. > > Remove the useless SHOULD. If initiator does not want to create IKE SA > clone, of course it does not include the notify specifying that it > wants clone. I.e change text to: > > If the Initiator does not want or > does not care that two parallel IKE SA exists, it will not include > CLONE_IKE_SA Notify Payload in the IKE SA rekey exchange. Agree. > In the next sentence there is text: > > The CLONE_IKE_SA Notify Payload is > always part of a CREATE_CHILD_SA IKEv2 exchange. > > I think it would be good to specify here too that it is always part of > a CREATE_CHILD_SA IKEv2 exchange rekeying IKE SA. It is clarified in the next version. > In the same section there is text saying: > > The responder supports the CLONE_IKE_SA Notify Payload as it provided > a CLONE_IKE_SA_SUPPORTED Notify Payload. If the CREATE_CHILD_SA > request concerns a IKE_SA rekey. The responder MUST proceed to the > IKE_SA rekey, create the new IKE_SA, and keep the old IKE_SA and > respond with a CLONE_IKE_SA Notify Payload as represented below: > > I would expect there are situations where the responder does not want > to allow IKE SA to be cloned, for example when it is running out of > IKE SAs (i.e. too many clones). This text says the responder MUST do > that... also the first two sentences should be connected to the later > ones, i.e: > > The responder has already indicated its support to the CLONE_IKE_SA > Notify Payload as it provided a CLONE_IKE_SA_SUPPORTED Notify > Payload earlier. When the CREATE_CHILD_SA request with the > CLONE_IKE_SA notify is received by the responder, it can either > return error (for example NO_ADDITIONAL_SAS) or proceed with the > IKE_SA cloning, create the new IKE_SA, and keeping the old IKE_SA > and respond with a CREATE_CHILD_SA exchange reply with CLONE_IKE_SA > Notify Payload as represented below: > > Other option would for the responder to just ignore the CLONE_IKE_SA > notify and return normal IKE SA rekey packet without doing the > cloning, but doing normal IKE SA rekey instead. I think it is better > to return NO_ADDITIONAL_SAS in error cases, than to do IKE SA rekey > (which initiator didn't want). Actually, this part is redesigned in the next version along the lines you suggest. > In section 5, the text about the critical bit could be clarified > (there are lots of misunderstanding about it already), i.e. change: > > - Critical Bit (1 bit): Indicates how the responder handles the > Notify Payload. In this document the Critical Bit is not set. > > to: > > - Critical Bit (1 bit): Indicates how the responder handles the > Notify Payload. As notify payload is mandatory to support in > IKEv2, the Critical Bit is not set. OK. > In section 7. IANA Considerations, change the: > > The new fields and number are the following: > > to > > This document allocates two new values from the "IKEv2 Notify > Message Types - Status Types" registry: > > The security considerations section requires some fixes and more text: > > The protocol defined in this document does not modifies IKEv2. It > signalizes what has been implementation dependent on how to manage an > old IKE_SA after a rekey. > > s/modifies/modify/ Thanks. > Also I do not think the RFC5996 said that it is implementation > dependent on how to manage an old IKE_SA after rekey. It says in > section 2.8 that old IKE SA is deleted (RFC5996): > > After the new equivalent IKE SA is created, the initiator > deletes the old IKE SA, and the Delete payload to delete itself MUST > be the last request sent over the old IKE SA. > > It does not give any indication how much you should wait after the > creating new IKE SA, but the text saying "initiator deletes the old > IKE SA" is quite clear... > > So I would fix the second sentence to be something better. The > security considerations section should also list other attacks, i.e. > this method could allow creating more IKE SAs or Child SAs between > peers than what would be possible with single IKE SA (for example > there might be Child SA limit per IKE SA, and this can be used to > bypass that limit or similar). It also might affect auditing and > accounting, as now for example only the first IKE SA might cause the > account start event to be called, but it might be possible that each > IKE SA destroy even will stop accounting. Also accounting might be > interested how many clones the IKE SA has, or it might only be > interested of the very first and very last IKE SA for the same ID. Agree, this section needs more words. > In appendix B.1 the text: > > The exchange is completely described in [RFC4555]. First the > negotiates the IKE_SA. In the figure below peers also proceed to NAT > detection because of the use of MOBIKE. > > Is missing some words in the second sentence (First the negotiates). Thanks. > In section B.3 fix: > > Alternatively, the VPN End User MAY uses a different IP > address for each interface > > s/MAY uses/MAY use/ Thanks again. > The exchange B.5 is not accoding to the draft, as it has > N(CLONE_IKE_SA) inside the IKE_AUTH exchange, and the draft says it > can only be in the CREATE_CHILD_SA exchange doing IKE SA rekey. So > that kind of optimized negotiation is not possible with current draft. > > Also I think adding that kind of complexity in the IKE_AUTH is bad > idea, so I would simply remove the B.5 example. Agree and this "reduced" exchanges are already completely removed from the draft. Thanks, Valery. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Mar 6 02:35:29 2014 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 8554C1A0249 for ; Thu, 6 Mar 2014 02:35:27 -0800 (PST) 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 6CfgpcHPoCm1 for ; Thu, 6 Mar 2014 02:35:26 -0800 (PST) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 844811A01AF for ; Thu, 6 Mar 2014 02:35:24 -0800 (PST) Received: by mail-bk0-f46.google.com with SMTP id v15so635307bkz.33 for ; Thu, 06 Mar 2014 02:35:20 -0800 (PST) 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=fr30XUacAncPMu2BMSAZdU2V0Bp1GMm6/I2DRIv5/Tk=; b=rA2RRzV9w9XJcR7udFS+MDjqijQWcMhMJwsaA5f2csKsIlXeoZTxF/vaiEo89y4rKC y//V24j5G8xV9GjE/Q/oiDzPWBZjDzyoCgna8WeEHjXbgLqmxgvxhR2AFmN4WJMtuaqG cIGMQUzLYRf2kEFA9Nk8qtnFjztVZlg1DDICBefF91MY5TAsXtW98f0KTOviergN31KX 5YH3MkzWmRvz6zVuxz8Bnl/AGzlKYSuLgiR79iNorAbFIRKi4KwnzHwP5lqz9SjhMHZl s47N+HlCMN7N5CY3smKee11//eTUo1LNX09djkihL58A/+/L7TltFKn8PJ1rNoMw9ONO cqHg== X-Received: by 10.205.41.9 with SMTP id ts9mr180728bkb.61.1394102120115; Thu, 06 Mar 2014 02:35:20 -0800 (PST) Received: from [10.2.0.25] (93-173-72-197.bb.netvision.net.il. [93.173.72.197]) by mx.google.com with ESMTPSA id ci7sm6765715bkc.0.2014.03.06.02.35.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 02:35:19 -0800 (PST) Message-ID: <53184F65.6000201@gmail.com> Date: Thu, 06 Mar 2014 12:35:17 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Valery Smyslov , Daniel Palomares References: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/PPAsKRPt81ermwR78JpVCxt43Ko Cc: IPsecme WG Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition 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 Mar 2014 10:35:27 -0000 > Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED, > SK_*, keymat for Child SA and AUTH payload content.Anyway, once the exchange > is complete, the nonces, appeared in this exchange, may be discarded. > Actually, you have 3 choices to exchange IKEv2 keying information > between nodes in cluster: > 1. Send your private DH key, peer's KE content and nonces. In this case > other nodes will recalculate all keys from the very beginning. > 2. Send SKEYSEED and nonces. > 3. Send computed SK_* keys. Note. that you even may omit sending SK_p*, > as these > keys are used only during authentication (unless you implement > Session Resumption, > but it also depends on how you store the tickets - by value or by > reference). > All approaches are equally possible. There seems to be some > security and performance benefists for approach 3, but somebody > may argue. Implementation may use any of this approaches > and I don't think it's good to mandate the only approach, > Regards, > Valery. > Actually, I would suggest that we disallow (or "deprecate") option #1. IKEv2 explicitly allows for DH secrets to be shared between SAs (this is not a good idea, but people do it for performance reasons), and we even have an RFC to deal with the security issues resulting from this behavior. So a node would be sharing more than it bargained for. Thanks, Yaron From nobody Thu Mar 6 09:11:14 2014 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 D419D1A0083 for ; Thu, 6 Mar 2014 09:11:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 UUgcsaXaAe6w for ; Thu, 6 Mar 2014 09:11:07 -0800 (PST) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id EFC201A0048 for ; Thu, 6 Mar 2014 09:11:06 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id lx4so3043593iec.38 for ; Thu, 06 Mar 2014 09:11:03 -0800 (PST) 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=wjU3HHh5vBhnI0x2vC4m/XmLJpfKL6lQqZM4i6R+ksM=; b=Tin/DMkA2qC6H6ekeK/W+MX+EtKG5ArP+g8mLQq5v08z221oIXmCjjDWb67I5XrpSW 7yzYbhCAf9wtrrploV/FnwrfGZZQ1bMZcEVquNzXRdZHPqIZuc6kPQ9YMk6xJrIgkBuG 6FERE5+OhIce4TkIwqGtV6URTvChxxh3xIN7ZvtE8rm6HSr2b/jU0SEaqvhrzFx98Nna P/7Hy7SM61sxCAyIvcoAskwDPsf2Kv4Wogkf5fd7MGQXMT9gV1PWub+/AaRNIBrtlNvC 3PfC7lV7MbReNj6aK4ds/IM1h+DDnYSU/8ucZL78OgNWnKzzcVvkIuihCCJn726zdQn3 6erQ== MIME-Version: 1.0 X-Received: by 10.50.143.12 with SMTP id sa12mr17216957igb.45.1394125863001; Thu, 06 Mar 2014 09:11:03 -0800 (PST) Received: by 10.50.40.131 with HTTP; Thu, 6 Mar 2014 09:11:02 -0800 (PST) In-Reply-To: <53184F65.6000201@gmail.com> References: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> <53184F65.6000201@gmail.com> Date: Thu, 6 Mar 2014 18:11:02 +0100 Message-ID: From: Daniel Palomares To: Yaron Sheffer Content-Type: multipart/alternative; boundary=001a1134cd02d622d804f3f33884 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/W5a9E3pf56YEiaBFn_5DKocArfs Cc: IPsecme WG , Valery Smyslov Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition 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 Mar 2014 17:11:10 -0000 --001a1134cd02d622d804f3f33884 Content-Type: text/plain; charset=ISO-8859-1 Hi Yaron, Thanks for the comments. Yeah, I have seen one application that implements High Availability by sending DH secret + KE + Nonces. Concerning the RFC that deals with the security issues resulting from this behavior, are you talking about Yoav's RFC - IPsec Cluster Statement?. If not, could you please tell me which RFC are you mentioning? So, as this is a known issue (Case #1), there is no problem to disallow it. Other point from previous discussions: I just wanted to add that in the Case #3, Valery and I had some offline discussions about it, and we found out that actually the SK_p*_old are not used to compute Session Resumption's AUTH payload. Instead, SK_d_old is used to compute it. This means that we actually can avoid SK_p* to be included in the IKE_SA Context Parameters (with a Mandatory flag). If anyone thinks SK_p* might be needed for some other exchange, please point that out through the mailing-list. Thank you, Kind Regards, Daniel Palomares 2014-03-06 11:35 GMT+01:00 Yaron Sheffer : > Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED, >> SK_*, keymat for Child SA and AUTH payload content.Anyway, once the >> exchange >> is complete, the nonces, appeared in this exchange, may be discarded. >> Actually, you have 3 choices to exchange IKEv2 keying information >> between nodes in cluster: >> 1. Send your private DH key, peer's KE content and nonces. In this case >> other nodes will recalculate all keys from the very beginning. >> 2. Send SKEYSEED and nonces. >> 3. Send computed SK_* keys. Note. that you even may omit sending SK_p*, >> as these >> keys are used only during authentication (unless you implement >> Session Resumption, >> but it also depends on how you store the tickets - by value or by >> reference). >> All approaches are equally possible. There seems to be some >> security and performance benefists for approach 3, but somebody >> may argue. Implementation may use any of this approaches >> and I don't think it's good to mandate the only approach, >> Regards, >> Valery. >> >> > Actually, I would suggest that we disallow (or "deprecate") option #1. > IKEv2 explicitly allows for DH secrets to be shared between SAs (this is > not a good idea, but people do it for performance reasons), and we even > have an RFC to deal with the security issues resulting from this behavior. > So a node would be sharing more than it bargained for. > > Thanks, > Yaron > --001a1134cd02d622d804f3f33884 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Yaron,

Thanks for the comments.=

Yeah, I have seen one application that implements High A= vailability by sending DH secret + KE + Nonces.
Concerning the RFC that= deals with the security issues resulting from this behavior, are you talki= ng about=A0 Yoav's RFC - IPsec Cluster Statement?. If not, could you pl= ease tell me which RFC are you mentioning?

=A0So, as this is a known issue (Case #1), there is no probl= em to disallow it.

Other point from previous discussions:=
I just wanted to add that in the Case #3, Valery and I had s= ome offline discussions about it, and we found out that actually the SK_p*_= old are not used to compute Session Resumption's AUTH payload. Instead,= SK_d_old is used to compute it. This means that we actually can avoid SK_p= *=A0 to be included in the IKE_SA Context Parameters (with a Mandatory flag= ). If anyone thinks SK_p* might be needed for some other exchange, please p= oint that out through the mailing-list.=A0

Thank you,

Kind Rega= rds,
Daniel Palomares



2014-03-06 11:35 GMT+01:00 Yaron= Sheffer <yaronf.ietf@gmail.com>:
Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED, SK_*, keymat for Child SA and AUTH payload content.Anyway, once the exchang= e
is complete, the nonces, appeared in this exchange, may be discarded.
Actually, you have 3 choices to exchange IKEv2 keying information
between nodes in cluster:
1. Send your private DH key, peer's KE content and nonces. In this case=
=A0 =A0 =A0other nodes will recalculate all keys from the very beginning. 2. Send SKEYSEED and nonces.
3. Send computed SK_* keys. Note. that you even may omit sending SK_p*,
as these
=A0 =A0 =A0keys are used only during authentication (unless you implement Session Resumption,
=A0 =A0 =A0but it also depends on how you store the tickets - by value or b= y
reference).
All approaches are equally possible. There seems to be some
security and performance benefists for approach 3, but somebody
may argue. Implementation may use any of this approaches
and I don't think it's good to mandate the only approach,
Regards,
Valery.


Actually, I would suggest that we disallow (or "deprecate") optio= n #1. IKEv2 explicitly allows for DH secrets to be shared between SAs (this= is not a good idea, but people do it for performance reasons), and we even= have an RFC to deal with the security issues resulting from this behavior.= So a node would be sharing more than it bargained for.

Thanks,
=A0 =A0 =A0 =A0 Yaron

--001a1134cd02d622d804f3f33884-- From nobody Thu Mar 6 10:13:14 2014 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 70F941A0110 for ; Thu, 6 Mar 2014 10:13:13 -0800 (PST) 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 w7DZNW-OuF51 for ; Thu, 6 Mar 2014 10:13:10 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 6F24B1A0088 for ; Thu, 6 Mar 2014 10:13:10 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id z12so3646312wgg.29 for ; Thu, 06 Mar 2014 10:13:06 -0800 (PST) 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=rp+g/AGPuUnK6B5iCjsuJkSj+1KbwXP/bKbvKUufc+Q=; b=eLl0gaMJT3/UjruRXneCOwWRegb193EMTypjWiE1Pzd67hYv9wQOUorFqNiuBWAuwa rC36XA8V3cdC6burSe8UjrsivcAFOXNL5BHzfSm72DUXuD9g98s3R/3jrj28/NkbEmy9 qIeor6wsRyi7hXL97ldpVoYqjHTfPixw79HzzVy3FeV673ca08yeRYdeNWR/qA/jkT4w T71TtLFbCQxYLXePhbPO6Pqg2jYsdBDG4xIwMnIQ6IXnfzQy7z4wHOB7v7CB8ggllZTn a8k+UJAcaJYp7FdrfBivznkOfwGolq/eArEpNDHb9PFA5qslTgoKSJrJwImYgOVrr23P yzLg== MIME-Version: 1.0 X-Received: by 10.194.24.35 with SMTP id r3mr12345621wjf.68.1394129585978; Thu, 06 Mar 2014 10:13:05 -0800 (PST) Received: by 10.194.171.225 with HTTP; Thu, 6 Mar 2014 10:13:05 -0800 (PST) In-Reply-To: References: <7A4D82FA3EF546E499D0A0CD18C58153@buildpc> <53184F65.6000201@gmail.com> Date: Thu, 6 Mar 2014 19:13:05 +0100 Message-ID: From: Daniel Migault To: Daniel Palomares Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QCYQmBAvBaKICx4DlfSgHHRJ8wg Cc: IPsecme WG , Valery Smyslov Subject: Re: [IPsec] Draft: IKEv2/IPsec Context Definition 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 Mar 2014 18:13:13 -0000 Hi Yaron, Thanks for that useful input. I think you mention rfc6989 and [http://cacr.uwaterloo.ca/techreports/2008/cacr2008-24.pdf]. We will have a close look at them. Actually it is not a bad thing to reduce the number of ways to express keying information. BR, Daniel On Thu, Mar 6, 2014 at 6:11 PM, Daniel Palomares wrote: > Hi Yaron, > > Thanks for the comments. > > Yeah, I have seen one application that implements High Availability by > sending DH secret + KE + Nonces. > Concerning the RFC that deals with the security issues resulting from this > behavior, are you talking about Yoav's RFC - IPsec Cluster Statement?. If > not, could you please tell me which RFC are you mentioning? > > So, as this is a known issue (Case #1), there is no problem to disallow it. > > Other point from previous discussions: > I just wanted to add that in the Case #3, Valery and I had some offline > discussions about it, and we found out that actually the SK_p*_old are not > used to compute Session Resumption's AUTH payload. Instead, SK_d_old is used > to compute it. This means that we actually can avoid SK_p* to be included > in the IKE_SA Context Parameters (with a Mandatory flag). If anyone thinks > SK_p* might be needed for some other exchange, please point that out through > the mailing-list. > > Thank you, > > Kind Regards, > Daniel Palomares > > > > 2014-03-06 11:35 GMT+01:00 Yaron Sheffer : > >>> Sending SK_* is enough. Nonces are used only in calculations of SKEYSEED, >>> SK_*, keymat for Child SA and AUTH payload content.Anyway, once the >>> exchange >>> is complete, the nonces, appeared in this exchange, may be discarded. >>> Actually, you have 3 choices to exchange IKEv2 keying information >>> between nodes in cluster: >>> 1. Send your private DH key, peer's KE content and nonces. In this case >>> other nodes will recalculate all keys from the very beginning. >>> 2. Send SKEYSEED and nonces. >>> 3. Send computed SK_* keys. Note. that you even may omit sending SK_p*, >>> as these >>> keys are used only during authentication (unless you implement >>> Session Resumption, >>> but it also depends on how you store the tickets - by value or by >>> reference). >>> All approaches are equally possible. There seems to be some >>> security and performance benefists for approach 3, but somebody >>> may argue. Implementation may use any of this approaches >>> and I don't think it's good to mandate the only approach, >>> Regards, >>> Valery. >>> >> >> Actually, I would suggest that we disallow (or "deprecate") option #1. >> IKEv2 explicitly allows for DH secrets to be shared between SAs (this is not >> a good idea, but people do it for performance reasons), and we even have an >> RFC to deal with the security issues resulting from this behavior. So a node >> would be sharing more than it bargained for. >> >> Thanks, >> Yaron > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Thu Mar 6 10:24:11 2014 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 C2C241A01FB for ; Thu, 6 Mar 2014 10:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 twht7ZvFohn5 for ; Thu, 6 Mar 2014 10:23:59 -0800 (PST) Received: from mail-ie0-x241.google.com (mail-ie0-x241.google.com [IPv6:2607:f8b0:4001:c03::241]) by ietfa.amsl.com (Postfix) with ESMTP id 5724D1A01BE for ; Thu, 6 Mar 2014 10:23:57 -0800 (PST) Received: by mail-ie0-f193.google.com with SMTP id rl12so2171383iec.4 for ; Thu, 06 Mar 2014 10:23:53 -0800 (PST) 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=Gk9zhrbTdNwV5AO4zBBmYY+ZuBAVS43zXplyzw9fZLA=; b=P366dhbVRpDIxrX74BURc2VM0pIxWaw3n+m9AeD5hOeOt0ND/NdJV3YB9T9aPY7BXe wyQ9J/+vXccW7AWXt4UcXAFlgWYfVUAPluZmcw35SlDnuFv1TSXEioXMNmmvCHfvSc0I nefA8lKh4lA2AC5BREi7vdkWbtxU+3WaLLp1ie8BCFUC57M8CKwpV0WepqjQ1Jox8SJN oo83UVVAzr9xPsAw/fLFKKcgG5A3Syjj/2PODasNq8RGgfwySndbS2Bze3wi0vdWSBnt sIystCSO4LrAueerEW6zV+wNcElT8Me2M5pMP9KMXw749o1wDOyg7dlCIqVAyOqm52+I f8Ig== MIME-Version: 1.0 X-Received: by 10.43.46.3 with SMTP id um3mr10993451icb.1.1394130233342; Thu, 06 Mar 2014 10:23:53 -0800 (PST) Received: by 10.50.40.131 with HTTP; Thu, 6 Mar 2014 10:23:53 -0800 (PST) In-Reply-To: <21271.44610.414071.370642@fireball.kivinen.iki.fi> References: <21271.44610.414071.370642@fireball.kivinen.iki.fi> Date: Thu, 6 Mar 2014 19:23:53 +0100 Message-ID: From: Daniel Palomares To: Tero Kivinen Content-Type: multipart/alternative; boundary=bcaec52995a154401304f3f43dd1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/um1CJPomHH5dmzRjUYVDuph9T8E Cc: IPsecme WG Subject: Re: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01 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 Mar 2014 18:24:06 -0000 --bcaec52995a154401304f3f43dd1 Content-Type: text/plain; charset=ISO-8859-1 Hi Tero, Thank you for the comment. In fact, I agree that is not so easy. Actually [ARORA] addressed these kind of scenarios on his draft already. For example, one of the usage scenarios described is: the IKEv2 signaling and the IPsec tunnel mode traffic on different addresses for load balancing purposes. So, would you think it is a good idea to add this information to the draft (I mean the new requirements when IKE_SAs and IPsec_SAs are on separated nodes)? ... Or instead, would you think it would be good to ignore how applications are managing their IPsec_SAs and IKE_SAs and just delete the sentence " Note that IKEv2 and IPsec session do not need to be on the same node as IKEv2 and IPsec context are different". We could also just mention that we wish to make clear that there are parameters related to the IKE_SA and others for the IPsec_SA. KR Daniel Palomares 2014-03-06 0:07 GMT+01:00 Tero Kivinen : > In section 2 it says: > > Note that IKEv2 and IPsec session do not need to be on the same node > as IKEv2 and IPsec context are different. > > This is not so easy. The RFC5996 says: > > ---------------------------------------------------------------------- > 2.4. State Synchronization and Connection Timeouts > ... > An implementation needs to stop sending over any SA if > some failure prevents it from receiving on all of the associated SAs. > If a system creates Child SAs that can fail independently from one > another without the associated IKE SA being able to send a delete > message, then the system MUST negotiate such Child SAs using separate > IKE SAs. > ---------------------------------------------------------------------- > > I.e. if any of the IPsec SAs fail, then all of IPsec SAs created using > same IKE SA, and the IKE SA must also fail. If IPsec SAs and IKE SA > are on separate nodes, that do set up new kind of requirements for > those nodes. I.e. if one node having IPsec SAs fails, the node having > IKE SA needs to detect this, and send delete notification for each > IPsec SA that were in that node. Also if the node having the IKE SA > will fail, then all the IPsec SAs associated with that IKE SA, must > stop sending, i.e. they needs to be destroyed. > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --bcaec52995a154401304f3f43dd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tero,
Thank you for the comment. In fact, I agree that is not so easy. Actually [ARORA] addressed these kin= d of scenarios on his draft already. For example, one of the usage scenario= s described is: the IKEv2 signaling and the IPsec tunnel mode traffic on di= fferent addresses for load balancing purposes.

So, would you think it is a good idea to add this information to = the draft (I mean the new requirements when IKE_SAs and IPsec_SAs are on se= parated nodes)? ... Or instead, would you think it would be good to ignore = how applications are managing their IPsec_SAs and IKE_SAs and=A0 just delet= e the sentence " Note that IKEv2 and IPsec session do not need to be o= n the same node as IKEv2 and IPsec context are different".

We could also just mention that we wish to make clear that there = are parameters related to the IKE_SA and others for the IPsec_SA.

<= /div>KR
Daniel Palomares



2014-03-06 0:07 GMT+01:00 Tero Kivinen <kivinen@iki.fi>:
In section 2 it says:

=A0 =A0Note that IKEv2 and IPsec session do not need to be on the same node=
=A0 =A0as IKEv2 and IPsec context are different.

This is not so easy. The RFC5996 says:

----------------------------------------------------------------------
2.4. =A0State Synchronization and Connection Timeouts
...
=A0 =A0 =A0 =A0 An implementation needs to stop sending over any SA if
=A0 =A0some failure prevents it from receiving on all of the associated SAs= .
=A0 =A0If a system creates Child SAs that can fail independently from one =A0 =A0another without the associated IKE SA being able to send a delete =A0 =A0message, then the system MUST negotiate such Child SAs using separat= e
=A0 =A0IKE SAs.
----------------------------------------------------------------------

I.e. if any of the IPsec SAs fail, then all of IPsec SAs created using
same IKE SA, and the IKE SA must also fail. If IPsec SAs and IKE SA
are on separate nodes, that do set up new kind of requirements for
those nodes. I.e. if one node having IPsec SAs fails, the node having
IKE SA needs to detect this, and send delete notification for each
IPsec SA that were in that node. Also if the node having the IKE SA
will fail, then all the IPsec SAs associated with that IKE SA, must
stop sending, i.e. they needs to be destroyed.
--
kivinen@iki.fi

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--bcaec52995a154401304f3f43dd1-- From nobody Thu Mar 6 10:51:55 2014 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 CA9931A0084 for ; Thu, 6 Mar 2014 10:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 Fj_T7mMTTvTY for ; Thu, 6 Mar 2014 10:51:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5161A0135 for ; Thu, 6 Mar 2014 10:51:51 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s26Ipi4b025122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Mar 2014 20:51:44 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s26IphoK005724; Thu, 6 Mar 2014 20:51:43 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21272.50111.445075.959734@fireball.kivinen.iki.fi> Date: Thu, 6 Mar 2014 20:51:43 +0200 From: Tero Kivinen To: Daniel Palomares In-Reply-To: References: <21271.44610.414071.370642@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/kqf-iLtudOYM0HpImFdHv3b3I98 Cc: IPsecme WG Subject: Re: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01 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 Mar 2014 18:51:54 -0000 Daniel Palomares writes: > So, would you think it is a good idea to add this information to the = draft (I > mean the new requirements when IKE=5FSAs and IPsec=5FSAs are on separ= ated nodes)=3F > ... Or instead, would you think it would be good to ignore how applic= ations > are managing their IPsec=5FSAs and IKE=5FSAs and=A0 just delete the s= entence " Note > that IKEv2 and IPsec session do not need to be on the same node as IK= Ev2 and > IPsec context are different". We definately need to add text explaining the situation, as it is important that implementors understand the RFC5996 requirement.=20 > We could also just mention that we wish to make clear that there are > parameters related to the IKE=5FSA and others for the IPsec=5FSA. --=20 kivinen@iki.fi From nobody Sat Mar 8 02:43:03 2014 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 D98A61A027A for ; Sat, 8 Mar 2014 02:43:02 -0800 (PST) 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 h5oUiT5bGaLJ for ; Sat, 8 Mar 2014 02:43:01 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD3A1A026B for ; Sat, 8 Mar 2014 02:43:01 -0800 (PST) Received: from [10.207.200.59] ([31.55.55.105]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s28AgrCo053227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Mar 2014 03:42:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.55.105] claimed to be [10.207.200.59] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2A5945B6-2000-4B9A-8CFC-B27AB2BCC5CC@vpnc.org> Date: Sat, 8 Mar 2014 10:42:53 +0000 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/yunmzDxht_2vbyFiZT5_QpsVNUI Subject: [IPsec] Minutes from IETF 89 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: Sat, 08 Mar 2014 10:43:03 -0000 ...are posted at = . Many = thanks to Peter Yee for thoroughness. If you have any comments on the topics presented, please start a = separate thread. --Paul Hoffman= From nobody Sat Mar 8 02:48:06 2014 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 C230E1A0258 for ; Sat, 8 Mar 2014 02:48:05 -0800 (PST) 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 63qpykRL3_1h for ; Sat, 8 Mar 2014 02:48:04 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B53791A027B for ; Sat, 8 Mar 2014 02:48:04 -0800 (PST) Received: from [10.207.200.59] ([31.55.55.105]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s28AlvfI053371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Mar 2014 03:47:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.55.105] claimed to be [10.207.200.59] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <21271.44610.414071.370642@fireball.kivinen.iki.fi> Date: Sat, 8 Mar 2014 10:47:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21271.44610.414071.370642@fireball.kivinen.iki.fi> To: ipsec X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/gNYg5uaqUrufbqwtkFO7RqAqynA Subject: Re: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01 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: Sat, 08 Mar 2014 10:48:06 -0000 On Mar 5, 2014, at 11:07 PM, Tero Kivinen wrote: > In section 2 it says: >=20 > Note that IKEv2 and IPsec session do not need to be on the same node > as IKEv2 and IPsec context are different. >=20 > This is not so easy. The RFC5996 says: >=20 > ---------------------------------------------------------------------- > 2.4. State Synchronization and Connection Timeouts > ... > An implementation needs to stop sending over any SA if > some failure prevents it from receiving on all of the associated = SAs. > If a system creates Child SAs that can fail independently from one > another without the associated IKE SA being able to send a delete > message, then the system MUST negotiate such Child SAs using = separate > IKE SAs. > ---------------------------------------------------------------------- >=20 > I.e. if any of the IPsec SAs fail, then all of IPsec SAs created using > same IKE SA, and the IKE SA must also fail. If IPsec SAs and IKE SA > are on separate nodes, that do set up new kind of requirements for > those nodes. I.e. if one node having IPsec SAs fails, the node having > IKE SA needs to detect this, and send delete notification for each > IPsec SA that were in that node. Also if the node having the IKE SA > will fail, then all the IPsec SAs associated with that IKE SA, must > stop sending, i.e. they needs to be destroyed. =20 Tero's comment nails the concern I had when reading the document. IKEv2 = ties Child SAs to their parent SA, and using the context of one without = the other seems dangerous. --Paul Hoffman= From nobody Sat Mar 8 03:56:15 2014 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 CFECB1A01E1 for ; Sat, 8 Mar 2014 03:56:13 -0800 (PST) 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 ySZX6e6jY9pV for ; Sat, 8 Mar 2014 03:56:12 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DC6551A011E for ; Sat, 8 Mar 2014 03:56:12 -0800 (PST) Received: from [10.207.200.59] ([31.55.55.105]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s28Bu4Vn055805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Mar 2014 04:56:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.55.105] claimed to be [10.207.200.59] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman X-Priority: 3 In-Reply-To: <9618756DDA9C407AB0DC06AC207FD394@buildpc> Date: Sat, 8 Mar 2014 11:56:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1CD15B55-CB5D-4107-99BB-E2BF2F7A8760@vpnc.org> References: <530CE583.6030801@gmail.com> <9618756DDA9C407AB0DC06AC207FD394@buildpc> To: ipsec X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/0pFX0_2i7ijQ3it4SimM0EdfLTE Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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: Sat, 08 Mar 2014 11:56:14 -0000 On Mar 3, 2014, at 12:02 PM, Valery Smyslov wrote: > The draft lists the following trasforms based on AES cipher: >=20 > AES-GCM > AES-CCM > AES-CTR > AES-128-CBC > AES-GMAC > AES-XCBC-MAC-96 >=20 > All these transforms, except for AES-XCBC-MAC-96, > allows to be used with different key lengths - 128, 192 and 256 bits. > It looks strange to me that, unlike the others, AES-128-CBC > has key length explicitely specified in the draft. Why it differs in > this respect from the others? What about AES-192-CBC and > AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) >=20 > I think the draft should either: > - remove explicit key length from AES-128-CBC and make it just AES-CBC > - add explicit key length to all other AES-based transforms (except = for AES-XCBC-MAC-96) > - leave things as is, but explain why AES-CBC differs in this respect = from the others The next draft changes AES-128-CBC to AES-CBC, and says: In the following sections, all AES modes are for 128-bit AES. 192-bit = AES MAY be supported for those modes, but the requirements here are for = 128-bit AES. --Paul Hoffman= From nobody Sat Mar 8 03:57:38 2014 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 423E11A0265 for ; Sat, 8 Mar 2014 03:57:37 -0800 (PST) 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 czRN7nwot_TP for ; Sat, 8 Mar 2014 03:57:36 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4A91A0258 for ; Sat, 8 Mar 2014 03:57:36 -0800 (PST) Received: from [10.207.200.59] ([31.55.55.105]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s28BvTXl055926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Mar 2014 04:57:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host [31.55.55.105] claimed to be [10.207.200.59] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com> Date: Sat, 8 Mar 2014 11:57:28 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <66A2E597-43D4-4403-9FF8-D8D13F35E958@gmail.com> To: IPsec ME WG List X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/NeDV2fISF6_x6ei-JpDJ9NnqFOM Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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: Sat, 08 Mar 2014 11:57:37 -0000 On Mar 3, 2014, at 3:04 PM, RJ Atkinson wrote: >> Perhaps some text along the line of: >>=20 >> ESP-NULL offers the same protection as AH, ... >=20 > This sentence above is not true. ESP-NULL and AH provide=20 > different security properties to the IP-layer. The next draft has more careful wording about AH and ESP; we'll ask the = WG to check it before passing the draft to Kathleen for IETF Last call. --Paul Hoffman= From nobody Sat Mar 8 05:09:04 2014 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 3E9F51A0233 for ; Sat, 8 Mar 2014 05:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 Wjuh8yncaALd for ; Sat, 8 Mar 2014 05:09:00 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 62EFA1A0120 for ; Sat, 8 Mar 2014 05:09:00 -0800 (PST) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s28D8sLJ005116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Mar 2014 08:08:55 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s28D8sLJ005116 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394284135; bh=Xk1FxLrlZ78XAeZ6cE7gMkEr+9U=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Paf7npSS8kz5juY7ediut8Z/7Jo1uwRt6TDiqm6v0GcIYGbV2omm3tWvesWpJAHF4 w59S3BrwDHo7tcg1o9UxP6hVcivLN5d0tqbECNvA7d8tCtYhcAnXxDns+twpWERBCe YVgIf8TzoPGKqegdKQzknHByUUQwoo+SZLl4pEuo= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s28D8sLJ005116 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Sat, 8 Mar 2014 08:08:39 -0500 Received: from mxhub24.corp.emc.com (mxhub24.corp.emc.com [128.222.70.136]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s28D8dAV024670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Mar 2014 08:08:39 -0500 Received: from mx15a.corp.emc.com ([169.254.1.223]) by mxhub24.corp.emc.com ([128.222.70.136]) with mapi; Sat, 8 Mar 2014 08:08:38 -0500 From: "Black, David" To: Paul Hoffman , ipsec Date: Sat, 8 Mar 2014 08:08:37 -0500 Thread-Topic: AES key lengths: draft-ietf-ipsecme-esp-ah-reqts Thread-Index: Ac86z4SnMEREQoCDQC27eSw4Gtdo9A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/FMqZHddjIj8_oj4AkiDiEv128eI Subject: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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: Sat, 08 Mar 2014 13:09:03 -0000 > The next draft changes AES-128-CBC to AES-CBC, and says: >=20 > In the following sections, all AES modes are for 128-bit AES. 192-bit AES > MAY be supported for those modes, but the requirements here are for 128-b= it > AES. What about 256-bit AES keys? They should also be a "MAY". Thanks, --David > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Saturday, March 08, 2014 6:56 AM > To: ipsec > Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-r= eqts >=20 > On Mar 3, 2014, at 12:02 PM, Valery Smyslov wrote: >=20 > > The draft lists the following trasforms based on AES cipher: > > > > AES-GCM > > AES-CCM > > AES-CTR > > AES-128-CBC > > AES-GMAC > > AES-XCBC-MAC-96 > > > > All these transforms, except for AES-XCBC-MAC-96, > > allows to be used with different key lengths - 128, 192 and 256 bits. > > It looks strange to me that, unlike the others, AES-128-CBC > > has key length explicitely specified in the draft. Why it differs in > > this respect from the others? What about AES-192-CBC and > > AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) > > > > I think the draft should either: > > - remove explicit key length from AES-128-CBC and make it just AES-CBC > > - add explicit key length to all other AES-based transforms (except for= AES- > XCBC-MAC-96) > > - leave things as is, but explain why AES-CBC differs in this respect f= rom > the others >=20 > The next draft changes AES-128-CBC to AES-CBC, and says: >=20 > In the following sections, all AES modes are for 128-bit AES. 192-bit AES > MAY be supported for those modes, but the requirements here are for 128-b= it > AES. >=20 > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Mar 8 05:38:01 2014 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 D12691A0236 for ; Sat, 8 Mar 2014 05:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 jLmf8skRhK_m for ; Sat, 8 Mar 2014 05:37:54 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id AAE071A0233 for ; Sat, 8 Mar 2014 05:37:54 -0800 (PST) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s28DbnEH010876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 8 Mar 2014 08:37:49 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s28DbnEH010876 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394285869; bh=9UZgHV08jc+Nl+Elt2UGO1QNpUw=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=v5/X2yeAsFdp8lhytXxDBBcWE/IKric9JZSdQMY2hdb5JIULHsr+XRyOe9OYybQR1 BM3cigo5FG07nbv69GKr26AHz/xL2cKcsb6j2TVkYuSIe29Ez308AtsjNVBAGwdAaX JocgJjoKryQJMfS27hb1k9C6Dy77hQZxVnav86ms= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com s28DbnEH010876 Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Sat, 8 Mar 2014 08:37:35 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s28DbZeA024900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 8 Mar 2014 08:37:35 -0500 Received: from mx15a.corp.emc.com ([169.254.1.223]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Sat, 8 Mar 2014 08:37:34 -0500 From: "Black, David" To: ipsec Date: Sat, 8 Mar 2014 08:37:32 -0500 Thread-Topic: WGLC comments: draft-ietf-ipsecme-esp-ah-reqts Thread-Index: Ac86047BjkDfaOGDRaOWLC9jA1GuYg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE71206CF439363@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Rx7YNc8N1ZcLRhODbWbrEcFPbXk Subject: [IPsec] WGLC comments: draft-ietf-ipsecme-esp-ah-reqts 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: Sat, 08 Mar 2014 13:37:57 -0000 The draft looks very good. Aside from my previous comment on 256-bit AES keys, I want to +1 three things I've seen in this discussion: - DES should be "MUST NOT" - "SHOULD NOT-" is a better keyword than "SHOULD NOT+" - NULL authentication for use with AES GCM should be at least "SHOULD+" because AES GCM is "SHOULD+". If the intent is to cover the latter (NULL authentication) in Section 3, then I suggest adding text to section 2.3 to point this out. I have no strong opinion on ICV size for GCM and GMAC, but I am interested in the outcome as an author of the Block Storage IPsec profile update (draft-ietf-storm-ipsec-ips-update-04). That draft does not currently express requirements on ICV length. That draft's in Authors 48 hours at the moment as part of the entire iSCSI draft cluster, and it could be held to apply the ICV length outcome determined here if that were deemed importa= nt. =09 Thanks, --David > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer > Sent: Tuesday, February 25, 2014 1:49 PM > To: ipsec > Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts >=20 > Hi, this is to start a 2-week working group last call on the revised > Algorithm Implementation Requirements document, ending March 11. The > draft is at: > http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We should > have last called the draft a while ago, and I apologize for the delay. >=20 > The changes from the existing requirements are listed in Sec. 2.5 of the > draft, but most of this (rather short) document is new and describes the > rationale for the choice of algorithms and requirement levels. >=20 > Please read this draft and send any comments to the WG mailing list, > even if the comments are "I see no problems". Comments such as "I do not > understand this part" or "this part could be explained better in this > way" are particularly useful at this point. >=20 > Thanks, > Yaron >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Mar 8 05:42:17 2014 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 E85181A0233 for ; Sat, 8 Mar 2014 05:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, 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 jWCuiTfyTM4g for ; Sat, 8 Mar 2014 05:42:14 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6EF1A00FC for ; Sat, 8 Mar 2014 05:42:14 -0800 (PST) Received: by mail-lb0-f175.google.com with SMTP id w7so3559435lbi.34 for ; Sat, 08 Mar 2014 05:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-type:content-transfer-encoding:importance; bh=6L0Yv8yrrsRFRiD3mnK7cjUGTESqlRMZdKg1kpK0xZ0=; b=YNpayeM4qseAH+25wW2QJ3rcchTzK0ZBqUj6CcffOVodT++lNDkwk3ozG4FFgggvJG 9C/mlqgoEAgaXrkcFMGikeLiVX4mwIrCkAAEKbdoqVK5ze0E7MGxDUPQWmu2uC67G6JT T8F8G8jd5OLOJVwP8KS3tEwrXyATABYyuaZ+oKxxv2tcmu3J22R9MO5K9RCZiJQqtuGK 9YPKMJC6UYCdY93CumVelR2gXmBMpHZ+nex7xVpvyqvommA549y6OA5ROczvRe9vBhaH nSmNzQrp+OH/mOv4BUJbEfk/9k0qxT9iwo4C5ENc3QDgYiVuhyq1kn1N5GRma1uDSapn ARxQ== X-Received: by 10.112.201.164 with SMTP id kb4mr14937818lbc.32.1394286129199; Sat, 08 Mar 2014 05:42:09 -0800 (PST) Received: from chichi (ppp85-141-227-1.pppoe.mtu-net.ru. [85.141.227.1]) by mx.google.com with ESMTPSA id sx1sm19644104lac.1.2014.03.08.05.42.07 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 08 Mar 2014 05:42:08 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Hoffman" , "ipsec" References: <530CE583.6030801@gmail.com> <9618756DDA9C407AB0DC06AC207FD394@buildpc> <1CD15B55-CB5D-4107-99BB-E2BF2F7A8760@vpnc.org> In-Reply-To: <1CD15B55-CB5D-4107-99BB-E2BF2F7A8760@vpnc.org> Date: Sat, 8 Mar 2014 17:42:02 +0400 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 Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3522.110 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3522.110 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-mKFNX4cu-ZMomZJGhSnUZmDGc8 Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts 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: Sat, 08 Mar 2014 13:42:16 -0000 Hi Paul, > > The draft lists the following trasforms based on AES cipher: > > > > AES-GCM > > AES-CCM > > AES-CTR > > AES-128-CBC > > AES-GMAC > > AES-XCBC-MAC-96 > > > > All these transforms, except for AES-XCBC-MAC-96, > > allows to be used with different key lengths - 128, 192 and 256 bits. > > It looks strange to me that, unlike the others, AES-128-CBC > > has key length explicitely specified in the draft. Why it differs in > > this respect from the others? What about AES-192-CBC and > > AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-) > > > > I think the draft should either: > > - remove explicit key length from AES-128-CBC and make it just AES-CBC > > - add explicit key length to all other AES-based transforms (except for > > AES-XCBC-MAC-96) > > - leave things as is, but explain why AES-CBC differs in this respect > > from the others > > The next draft changes AES-128-CBC to AES-CBC, and says: > > In the following sections, all AES modes are for 128-bit AES. 192-bit AES > MAY be supported for those modes, but the requirements here are for > 128-bit AES. And please, add the same words for 256-bit AES as for 192-bits AES. Regards, Valery. > --Paul Hoffman From nobody Sat Mar 8 06:11:15 2014 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 84B031A0159 for ; Sat, 8 Mar 2014 06:11:14 -0800 (PST) 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 KkBdd30Vj24o for ; Sat, 8 Mar 2014 06:11:06 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B37101A00FC for ; Sat, 8 Mar 2014 06:11:06 -0800 (PST) Received: from [10.207.200.36] (host86-189-2-69.range86-189.btcentralplus.com [86.189.2.69]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s28EAtG0075694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Mar 2014 07:10:57 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host host86-189-2-69.range86-189.btcentralplus.com [86.189.2.69] claimed to be [10.207.200.36] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> Date: Sat, 8 Mar 2014 14:10:53 +0000 Content-Transfer-Encoding: 7bit Message-Id: <0BE98EEF-C639-48F8-90ED-5CB8A9206336@vpnc.org> References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/InwZaYo9EnJ1fY3luuc6zsb1_-Y Cc: ipsec Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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: Sat, 08 Mar 2014 14:11:14 -0000 On Mar 8, 2014, at 1:08 PM, Black, David wrote: > What about 256-bit AES keys? They should also be a "MAY". Good catch. --Paul Hoffman From nobody Sat Mar 8 06:14:16 2014 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 856701A013F for ; Sat, 8 Mar 2014 06:14:14 -0800 (PST) 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 DNdsc7ek4jlj for ; Sat, 8 Mar 2014 06:14:13 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 176921A00FC for ; Sat, 8 Mar 2014 06:14:13 -0800 (PST) Received: from [10.207.200.36] (host86-189-2-69.range86-189.btcentralplus.com [86.189.2.69]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s28EE5TG076171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 8 Mar 2014 07:14:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host host86-189-2-69.range86-189.btcentralplus.com [86.189.2.69] claimed to be [10.207.200.36] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71206CF439363@MX15A.corp.emc.com> Date: Sat, 8 Mar 2014 14:14:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0783904C-64C4-4561-B7B5-D4F57D6B5656@vpnc.org> References: <8D3D17ACE214DC429325B2B98F3AE71206CF439363@MX15A.corp.emc.com> To: ipsec X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/g6iDVUtwYVRPosJoifl6LFVDLUA Subject: [IPsec] SHOULD NOT in draft-ietf-ipsecme-esp-ah-reqts 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: Sat, 08 Mar 2014 14:14:14 -0000 On Mar 8, 2014, at 1:37 PM, Black, David wrote: > - "SHOULD NOT-" is a better keyword than "SHOULD NOT+" How do others feel about this? It feels like a bit of a bikeshed, but we = may as well be as helpful as possible. --Paul Hoffman= From nobody Sat Mar 8 06:21:21 2014 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 19ACC1A0218 for ; Sat, 8 Mar 2014 06:21:19 -0800 (PST) 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 a7hfJJNSiULX for ; Sat, 8 Mar 2014 06:21:18 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6E21A0159 for ; Sat, 8 Mar 2014 06:21:18 -0800 (PST) Received: from [10.207.200.36] (host86-189-2-69.range86-189.btcentralplus.com [86.189.2.69]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s28EL63i077215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Mar 2014 07:21:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host host86-189-2-69.range86-189.btcentralplus.com [86.189.2.69] claimed to be [10.207.200.36] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Paul Hoffman In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71206CF439363@MX15A.corp.emc.com> Date: Sat, 8 Mar 2014 14:21:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <55D8171A-FF38-45A1-B299-4EB5189743A7@vpnc.org> References: <8D3D17ACE214DC429325B2B98F3AE71206CF439363@MX15A.corp.emc.com> To: "Black, David" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/bnj2xMvDWOKSgnfLBNSyhr1utXA Cc: ipsec Subject: [IPsec] ICV sizes 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: Sat, 08 Mar 2014 14:21:19 -0000 On Mar 8, 2014, at 1:37 PM, Black, David wrote: > I have no strong opinion on ICV size for GCM and GMAC, but I am = interested > in the outcome as an author of the Block Storage IPsec profile update > (draft-ietf-storm-ipsec-ips-update-04). That draft does not currently > express requirements on ICV length. That draft's in Authors 48 hours = at > the moment as part of the entire iSCSI draft cluster, and it could be = held > to apply the ICV length outcome determined here if that were deemed = important. Making technical changes to a document in AUTH48 is a really bad idea. = If you were not specific enough when writing the draft, you should = probably just leave it alone. --Paul Hoffman From nobody Sat Mar 8 06:24:06 2014 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 26EBE1A0159 for ; Sat, 8 Mar 2014 06:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 0kMTif_qbPPq for ; Sat, 8 Mar 2014 06:24:03 -0800 (PST) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF231A00FC for ; Sat, 8 Mar 2014 06:24:03 -0800 (PST) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s28ENvhe030857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Mar 2014 09:23:58 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s28ENvhe030857 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394288638; bh=r+b86CViDIpym5FXWUq30AsfkZA=; h=From:To:CC:Date:Subject:Message-ID:In-Reply-To:Content-Type: Content-Transfer-Encoding:MIME-Version; b=vXHANhcoQyd+gBzrRdR8M5l6iwKPwD44+AEvyLENWbRpp3LJ/lDE6gtvyy5zhbmJA RyzGdJDAc75IC2ZFiMUKE8+UH6f/58W2Rc9CbcZL8yoJpU0iSgL9W+EEyFP6LHOqAv 5YHeNjzcLijQbNzPX4FwQwprtP9lKDJGjuwg4sbw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s28ENvhe030857 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd01.lss.emc.com (RSA Interceptor); Sat, 8 Mar 2014 09:23:36 -0500 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s28ENawf006858 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Mar 2014 09:23:36 -0500 Received: from mx15a.corp.emc.com ([169.254.1.223]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Sat, 8 Mar 2014 09:23:36 -0500 From: "Black, David" To: "'paul.hoffman@vpnc.org'" Date: Sat, 8 Mar 2014 09:23:35 -0500 Thread-Topic: ICV sizes Thread-Index: Ac862au5OKvJkV+xSWSesjh4SnCZ3gAAFHkx Message-ID: <8D3D17ACE214DC429325B2B98F3AE71206CF4F78B7@MX15A.corp.emc.com> In-Reply-To: <55D8171A-FF38-45A1-B299-4EB5189743A7@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: DLM_1, public Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/mYCOJfPafQmxRN0C0q2qnE_93Gg Cc: "'ipsec@ietf.org'" Subject: Re: [IPsec] ICV sizes 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: Sat, 08 Mar 2014 14:24:05 -0000 Ok, no problem here ... Thanks, --David +++Sent from Blackberry ----- Original Message ----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Saturday, March 08, 2014 09:21 AM=0A= To: Black, David Cc: ipsec Subject: ICV sizes On Mar 8, 2014, at 1:37 PM, Black, David wrote: > I have no strong opinion on ICV size for GCM and GMAC, but I am intereste= d > in the outcome as an author of the Block Storage IPsec profile update > (draft-ietf-storm-ipsec-ips-update-04). That draft does not currently > express requirements on ICV length. That draft's in Authors 48 hours at > the moment as part of the entire iSCSI draft cluster, and it could be hel= d > to apply the ICV length outcome determined here if that were deemed impor= tant. Making technical changes to a document in AUTH48 is a really bad idea. If y= ou were not specific enough when writing the draft, you should probably jus= t leave it alone. --Paul Hoffman From nobody Sat Mar 8 12:00:54 2014 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 13E661A0172 for ; Sat, 8 Mar 2014 12:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 LBChroVO2km4 for ; Sat, 8 Mar 2014 12:00:51 -0800 (PST) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by ietfa.amsl.com (Postfix) with ESMTP id 098761A02F2 for ; Sat, 8 Mar 2014 12:00:47 -0800 (PST) X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="4.97,615,1389765600"; d="scan'208";a="441925623" From: To: Thread-Topic: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts Thread-Index: Ac86z4SnMEREQoCDQC27eSw4Gtdo9AAa9ryA Date: Sat, 8 Mar 2014 20:00:42 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.216.26] Content-Type: text/plain; charset="Windows-1252" Content-ID: <02A889D1BA5B044E888F585A97FF7E66@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/fNrmOrtS19wyVR0nJZdq-9S66GU Cc: ipsec@ietf.org, paul.hoffman@vpnc.org Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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: Sat, 08 Mar 2014 20:00:53 -0000 On Mar 8, 2014, at 8:08 AM, Black, David wrote: >> The next draft changes AES-128-CBC to AES-CBC, and says: >>=20 >> In the following sections, all AES modes are for 128-bit AES. 192-bit AE= S >> MAY be supported for those modes, but the requirements here are for 128-= bit >> AES. >=20 > What about 256-bit AES keys? They should also be a "MAY". Why not =93SHOULD=94 for 192 and 256 bit keys? paul From nobody Sun Mar 9 01:43:47 2014 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 54A0B1A0328 for ; Sun, 9 Mar 2014 01:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 Ly1pmiLs9Phb for ; Sun, 9 Mar 2014 01:43:43 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCB81A021A for ; Sun, 9 Mar 2014 01:43:43 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id w62so7233680wes.0 for ; Sun, 09 Mar 2014 01:43:38 -0800 (PST) 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=ytMtQL3FqFnHNXHFK5E8kfbzQ3Ns0rGy3ri90+L2jkQ=; b=Rli7AYq0bWcvZaTli5Q6o2mgFdwl4lXJAsPUNPc5AUWl9OAa5uFEbbtYC9szYu3M9m NMbTqn9xRfQwvbqqd52ts1MwQ1pTKKxXjLw/btPWf8+D7Jy5HBXlOOqqNOhc7rLU+Wp6 fQPExc9yOQRDUxoI5JIsiuF615IdzOr92GyiR2sZiFDXDaCPOGsZEhDClAsR2i5hwNRY CG4Cewwc2D0rTqJF7kdxp+Fq+XlGXY+ZcrIU2JFK774R/dukp4iRhEaev431LDNr2Y8v XwEcm82/PUdLn88dwIKpOHdkfbQHkc8cco/Ou6G+34b/CafEkqaQqib1V/9/hjDlTaNL D8sA== MIME-Version: 1.0 X-Received: by 10.194.6.8 with SMTP id w8mr27236337wjw.16.1394358218216; Sun, 09 Mar 2014 01:43:38 -0800 (PST) Received: by 10.194.89.1 with HTTP; Sun, 9 Mar 2014 01:43:38 -0800 (PST) In-Reply-To: References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> Date: Sun, 9 Mar 2014 11:43:38 +0200 Message-ID: From: Yoav Nir To: ipsec Content-Type: multipart/alternative; boundary=047d7b5d6498495aab04f4295290 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QcO_QYGZygLbTA8j5T5zAo9hIUs Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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: Sun, 09 Mar 2014 09:43:46 -0000 --047d7b5d6498495aab04f4295290 Content-Type: text/plain; charset=ISO-8859-1 With vendor hat on: years ago we measured the performance and found that the performance of AES-256-CBC and AES-192-CBC were virtually identical. We removed AES-192-CBC from our UI because we didn't see a point to it - less security for no performance gain. I don't have any more recent measurements, but unless there is a good reason to prefer AES-192-CBC over AES-256-CBC, I'd rather it not be a SHOULD. On Sat, Mar 8, 2014 at 10:00 PM, wrote: > > On Mar 8, 2014, at 8:08 AM, Black, David wrote: > > >> The next draft changes AES-128-CBC to AES-CBC, and says: > >> > >> In the following sections, all AES modes are for 128-bit AES. 192-bit > AES > >> MAY be supported for those modes, but the requirements here are for > 128-bit > >> AES. > > > > What about 256-bit AES keys? They should also be a "MAY". > > Why not "SHOULD" for 192 and 256 bit keys? > > paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --047d7b5d6498495aab04f4295290 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
With vendor hat on: years ago we measured the perform= ance and found that the performance of AES-256-CBC and AES-192-CBC were vir= tually identical. We removed AES-192-CBC from our UI because we didn't = see a point to it - less security for no performance gain.

I don't have any more recent measurements, but unless there i= s a good reason to prefer AES-192-CBC over AES-256-CBC, I'd rather it n= ot be a SHOULD.


On Sat, Mar 8, 2014 at 10:00 PM, <Paul_Koning@dell.com> = wrote:

On Mar 8, 2014, at 8:08 AM, Black, David <david.black@emc.com> wrote:

>> The next draft changes AES-128-CBC to AES-CBC, and says:
>>
>> In the following sections, all AES modes are for 128-bit AES. 192-= bit AES
>> MAY be supported for those modes, but the requirements here are fo= r 128-bit
>> AES.
>
> What about 256-bit AES keys?  They should also be a "MAY&quo= t;.

Why not “SHOULD” for 192 and 256 bit keys?

        paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec

--047d7b5d6498495aab04f4295290-- From nobody Sun Mar 9 01:56:00 2014 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 677811A0240 for ; Sun, 9 Mar 2014 01:55:58 -0800 (PST) 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 uM0LLd_jpAkt for ; Sun, 9 Mar 2014 01:55:57 -0800 (PST) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BD01C1A021A for ; Sun, 9 Mar 2014 01:55:56 -0800 (PST) Received: by mail-ea0-f175.google.com with SMTP id d10so3112190eaj.20 for ; Sun, 09 Mar 2014 01:55:51 -0800 (PST) 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=YCO+7y+19N1QTiGLH+NvnGmQvm18qdjgt1VwTy4N+Co=; b=S/zmftoK7X1u0BLxb/mgcGRM13wjj52BrSGCAb6BGV5w10qt6xO5XWc2JvCVkRzmAH 2mFcVKQ3SGdCta4b6OR9mZwS67RDToLvpPlmKdHqczAhENy0Q4rpIxU8DwKxlAJcCQKH z0ojvZKtTTu9z1vtzYOFEeOUNGk1YSV7FnfBhcxY0M8OxKJnFKEaSxhD6RNAwAoxK+8n CBxm1YEnC4XHS4HyX9Uj0tCIwescPxOa0qAuRBKitenWKXxG42kNwonr/3Cj8TPUPlRv ZEtUdrQa0Lrz32EXy0lz77mdgK/0hVQDjiYxooOmDvrS9ANuw/g5BMSS0A0OFh19PyEr Xazg== X-Received: by 10.14.88.7 with SMTP id z7mr1770108eee.90.1394358951448; Sun, 09 Mar 2014 01:55:51 -0800 (PST) Received: from [10.2.0.25] (93-173-72-197.bb.netvision.net.il. [93.173.72.197]) by mx.google.com with ESMTPSA id m8sm30332398eef.14.2014.03.09.01.55.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Mar 2014 01:55:51 -0800 (PST) Message-ID: <531C3AA5.9070100@gmail.com> Date: Sun, 09 Mar 2014 11:55:49 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: IPsecME Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/--mee_Im-ewPnVtOwmuW-BZ7Ezs Subject: [IPsec] ChaCha and Salsa20 - IPsecME minutes 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: Sun, 09 Mar 2014 09:55:58 -0000 Hi Paul, In an attempt to rewrite history, please correct my comment in the minutes re: eStream submission of ChaCha. In fact, ChaCha is a modified version of Salsa20, and it was Salsa20 that was an eStream submission. See https://en.wikipedia.org/wiki/Salsa20 Thanks, Yaron From nobody Sun Mar 9 08:03:15 2014 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 0CACF1A035F for ; Sun, 9 Mar 2014 08:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 ng2mp8JujObb for ; Sun, 9 Mar 2014 08:03:13 -0700 (PDT) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A6E081A0265 for ; Sun, 9 Mar 2014 08:03:12 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id l18so6895688wgh.28 for ; Sun, 09 Mar 2014 08:03:07 -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=8wB4bzmTYClOn9Zv+Vqf1OK7hNx1zgAqSjEAET2K0N0=; b=QiMZgxE7BQvR1uWp4cc01btg0272Ne1ysYbpkTBfx509cu5eENYM9kOGRbJgKgviUs MkmzFY/cH08rBWTLuJZB0OVE7sykS2i+ADtjEpTEhh+E+oKk/ThTzaAT3pFkFt3oMe+9 Gp6NfiQugyrpLlr6WwbhEVyuGfb2Tums4ibW3z8HWBthNAWGoktd2rRo53rImWNEEbir woEfKcX2NTs9isszaCLbIfjHHg3syhPY3Vy4xri+dP/o95qpnp10b20W/doCYg7MqdVP hkWlc/yBwzf+0VTJnByGLKI35WgvrsdjKwSyaHb/J1odXTHcJAZA12OrjNV5adgfGgvo pWCA== MIME-Version: 1.0 X-Received: by 10.180.210.171 with SMTP id mv11mr4811365wic.44.1394377387252; Sun, 09 Mar 2014 08:03:07 -0700 (PDT) Received: by 10.194.89.1 with HTTP; Sun, 9 Mar 2014 08:03:07 -0700 (PDT) Date: Sun, 9 Mar 2014 17:03:07 +0200 Message-ID: From: Yoav Nir To: ipsec Content-Type: multipart/alternative; boundary=001a11c25d36d99f9104f42dc857 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/u9Ktj4Pagl-I0x9aD2GtCwW_sgM Subject: [IPsec] ChaCha20 & Poly1305, AEAD and other modes 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: Sun, 09 Mar 2014 15:03:14 -0000 --001a11c25d36d99f9104f42dc857 Content-Type: text/plain; charset=ISO-8859-1 Hi draft-nir-ipsecme-chacha20-poly1305 currently specifies three transforms: 1. chacha20 as a stand-alone cipher 2. Poly1305 as a stand-alone MAC 3. ChaCha20-Poly1305 as an AEAD. Some people in the room said that we should only do the AEAD and skip the stand-alone algorithms. This would prevent SAs with combinations such as ChaCha20 + HMAC-SHA1 or AES-128-CBC + Poly1305. I'm not saying whether we need or don't need these combinations. I don't see much use for them personally. My question to the list now is whether everyone agrees that it's fine to drop them and leave only the combined mode algorithm in the draft. Thanks Yoav --001a11c25d36d99f9104f42dc857 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi


draft-nir-ipsecme-chacha20-p= oly1305 currently specifies three transforms:
  1. chacha20 as a stan= d-alone cipher
  2. Poly1305 as a stand-alone MAC
  3. ChaCha20-Poly1= 305 as an AEAD.

Some people in the room said that we should only do the AEAD and sk= ip the stand-alone algorithms. This would prevent SAs with combinations suc= h as ChaCha20 + HMAC-SHA1 or AES-128-CBC + Poly1305.

I'm not= saying whether we need or don't need these combinations. I don't s= ee much use for them personally. My question to the list now is whether eve= ryone agrees that it's fine to drop them and leave only the combined mo= de algorithm in the draft.

Thanks

Yoav


--001a11c25d36d99f9104f42dc857-- From nobody Sun Mar 9 19:30:05 2014 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 B0B611A03A9 for ; Sun, 9 Mar 2014 19:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547, 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 M-LTVRNpsAq7 for ; Sun, 9 Mar 2014 19:29:59 -0700 (PDT) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 983DC1A03A4 for ; Sun, 9 Mar 2014 19:29:59 -0700 (PDT) Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2A2Tpgl002131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Mar 2014 22:29:52 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s2A2Tpgl002131 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1394418592; bh=gADsUr8psF1qUkB7TTEY7gUuHyY=; h=From:To:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=BK5CzjGcANYsodZUYJPPP4abpxyl4Xv6IuTa0CnZVXPEtN2VXa2JdAdhV00z+eQ1N NsijmzQzBYgUrvEfAjYkIRKmlN4evXi2EDsYup35FVp+b0sZspTWQmA5GkGi9CFiQ9 8YEgyhZJ8kBOjqX4Y9cA0AuJqwPewIXc5VmP/Es8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s2A2Tpgl002131 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd05.lss.emc.com (RSA Interceptor); Sun, 9 Mar 2014 19:29:42 -0700 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s2A2TfE0010145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Mar 2014 22:29:41 -0400 Received: from mx15a.corp.emc.com ([169.254.1.223]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Sun, 9 Mar 2014 22:29:40 -0400 From: "Black, David" To: Yoav Nir , ipsec Date: Sun, 9 Mar 2014 22:29:42 -0400 Thread-Topic: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts Thread-Index: Ac87fBKVk7xwAw2gR3qHp4OH6u0vGAAi7ozA Message-ID: <8D3D17ACE214DC429325B2B98F3AE71206CF4393CC@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE71206CF4393CCMX15Acorpemcc_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-RSA-Classifications: public Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ciC2AT49fbCoGXkuxuX6rKGsilI Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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 Mar 2014 02:30:04 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE71206CF4393CCMX15Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The storage world seems to have done likewise - use 256-bit keys when 128-b= its aren't enough; tape encryption is one source of examples. Also see Section 7.3 of RFC 5282 (Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol) which also recommends 256-bit keys in preference to 192-bit keys. FWIW, Section 7.2 of the same RFC (which applies to both CCM and GCM) recom= mends 16-octet ICVs and recommends against 12-octet ICVs. Thanks, --David From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Sunday, March 09, 2014 5:44 AM To: ipsec Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts With vendor hat on: years ago we measured the performance and found that th= e performance of AES-256-CBC and AES-192-CBC were virtually identical. We r= emoved AES-192-CBC from our UI because we didn't see a point to it - less s= ecurity for no performance gain. I don't have any more recent measurements, but unless there is a good reaso= n to prefer AES-192-CBC over AES-256-CBC, I'd rather it not be a SHOULD. On Sat, Mar 8, 2014 at 10:00 PM, > wrote: On Mar 8, 2014, at 8:08 AM, Black, David > wrote: >> The next draft changes AES-128-CBC to AES-CBC, and says: >> >> In the following sections, all AES modes are for 128-bit AES. 192-bit AE= S >> MAY be supported for those modes, but the requirements here are for 128-= bit >> AES. > > What about 256-bit AES keys? They should also be a "MAY". Why not "SHOULD" for 192 and 256 bit keys? paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_8D3D17ACE214DC429325B2B98F3AE71206CF4393CCMX15Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The storage world se= ems to have done likewise - use 256-bit keys when 128-bits

aren’t enough; tape encryption is one source of= examples.

 

Also see Section 7.3 of RFC 5282 (Using Authenticated En= cryption Algorithms

with the Encryp= ted Payload of the Internet Key Exchange version 2 (IKEv2)

Protocol) which also recommends 256-bit keys in prefe= rence to 192-bit keys.

 

FWIW, Section 7.2 of the same RFC (which app= lies to both CCM and GCM) recommends

= 16-octet ICVs and recommends against 12-octet ICVs.

Thanks,--David

 

From: IPsec [mailto:ipse= c-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Sunday, Ma= rch 09, 2014 5:44 AM
To: ipsec
Subject: Re: [IPsec] AES= key lengths: draft-ietf-ipsecme-esp-ah-reqts

 

With vendor hat on: years ago we measured = the performance and found that the performance of AES-256-CBC and AES-192-C= BC were virtually identical. We removed AES-192-CBC from our UI because we = didn't see a point to it - less security for no performance gain.

I don't have any more recent measurements, = but unless there is a good reason to prefer AES-192-CBC over AES-256-CBC, I= 'd rather it not be a SHOULD.

 

On= Sat, Mar 8, 2014 at 10:00 PM, <Paul_Koning@dell.com> wrote:


On Mar 8, 2014, at 8:= 08 AM, Black, David <david.black@= emc.com> wrote:

>> The next draft changes AES-128-CBC t= o AES-CBC, and says:
>>
>> In the following sections, all= AES modes are for 128-bit AES. 192-bit AES
>> MAY be supported fo= r those modes, but the requirements here are for 128-bit
>> AES.>
> What about 256-bit AES keys?  They should also be a &qu= ot;MAY".

Why not “SHOUL= D” for 192 and 256 bit keys?

        paul<= o:p>


__________________________= _____________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec<= o:p>

 

<= /div>
= --_000_8D3D17ACE214DC429325B2B98F3AE71206CF4393CCMX15Acorpemcc_-- From nobody Sun Mar 9 23:00:50 2014 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 9C9E51A03D6 for ; Sun, 9 Mar 2014 23:00:49 -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 I2C7aUDABr0D for ; Sun, 9 Mar 2014 23:00:47 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCB31A03D1 for ; Sun, 9 Mar 2014 23:00:47 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id n15so3480532ead.30 for ; Sun, 09 Mar 2014 23:00:42 -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:references :in-reply-to:content-type:content-transfer-encoding; bh=Npbgeh/VRLYx7gtBwv0CnGCTGbZOzLo1iYTXJN/RQ1M=; b=Bw0Ez+7/U8WcEpn+u1KQ5YJfzLVABZomH+4EQfu3tX0t8q3+G2rjUtkdbvHKhA03yG qpqoZiD9g+xVQj6CAc53bAjMwXTc9Ww+XXzeQZr+xQF0NHAiagcaektbn90XQtTHt2eN UVgE7dxDBDRzG8TX2xvyHA4w8GNcPgnALYsjciw6O2JEcPC3/jh9r+HW0rX+j63Tp32D pZBQVuN8WjzrzY8DWUTekFu1tr+G8pwxNKbeQZOwbYqVVptBKaK3LuNda4kMY9YOsyYf BuQj3e8POPvyhAmsiA0HdvDLimYeIEcRPeKKn6LVRCYCguMaaAD3z6CaT8kEjwW8Pp7L pDwg== X-Received: by 10.15.26.67 with SMTP id m43mr14607eeu.109.1394431242004; Sun, 09 Mar 2014 23:00:42 -0700 (PDT) Received: from [10.0.0.6] (bzq-109-65-63-189.red.bezeqint.net. [109.65.63.189]) by mx.google.com with ESMTPSA id o43sm40944223eef.12.2014.03.09.23.00.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Mar 2014 23:00:41 -0700 (PDT) Message-ID: <531D5508.4000707@gmail.com> Date: Mon, 10 Mar 2014 08:00:40 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yoav Nir , ipsec References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/oaCx4Imd0LUVv-pqjywG4IVRGXk Subject: Re: [IPsec] ChaCha20 & Poly1305, AEAD and other modes 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 Mar 2014 06:00:49 -0000 Hi Yoav, Can you explain why we need Poly1305 at all? We have SHA-2 and will probably adopt Keccak (SHA-3), so it's not like we don't have a backup. Let me suggest that we adopt *only* ChaCha20, which can be combined with any integrity protection algorithm in the normal ESP way. Is there any extra value (maybe code sharing?) in predefining an AEAD? Thanks, Yaron On 03/09/2014 05:03 PM, Yoav Nir wrote: > Hi > > > draft-nir-ipsecme-chacha20-poly1305 currently specifies three transforms: > > 1. chacha20 as a stand-alone cipher > 2. Poly1305 as a stand-alone MAC > 3. ChaCha20-Poly1305 as an AEAD. > > Some people in the room said that we should only do the AEAD and skip > the stand-alone algorithms. This would prevent SAs with combinations > such as ChaCha20 + HMAC-SHA1 or AES-128-CBC + Poly1305. > > I'm not saying whether we need or don't need these combinations. I don't > see much use for them personally. My question to the list now is whether > everyone agrees that it's fine to drop them and leave only the combined > mode algorithm in the draft. > > Thanks > > Yoav > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Mar 10 01:15:27 2014 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 9CCDA1A03F0 for ; Mon, 10 Mar 2014 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 3R58I6KmbpbE for ; Mon, 10 Mar 2014 01:15:23 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 86C4F1A0320 for ; Mon, 10 Mar 2014 01:15:23 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id l18so3760091wgh.31 for ; Mon, 10 Mar 2014 01:15:17 -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=ieICkM8cSdAzYToIJufNmloe3X0i5g5zqcptbWDT4iU=; b=t3lgCfu4cePVkxeiCc/kR8spoXLVs+kTth/pzxu7GsDfI/0sqTDQVUGiTCq5PMvg33 JbqBuFpJ1qZCmE4d6Ws2BiTBeKCVqPAaGoMRSVuqmS2LDSuzvZY6gEfMdPFJJmcx7dQQ IPwKStwxa8UMC8NXWXGK/JYw7t4Hu6bgY3df3Qe/6u7fA4vANGJOnXGJ8Ip5anImqNHC WeM9nXjq9GbnejrlEQGryWx+dQrre8gRgydQjaTI+Xok9GG+4KaVsMdh3zTJg3aygO67 FtvsF+YcKMF/tO6eDDj55HlvnLsRWclFmYHbP0YDMJoDT6LwGwy0M1bkVfT2ASs8bbib nz9w== MIME-Version: 1.0 X-Received: by 10.194.236.9 with SMTP id uq9mr29866475wjc.31.1394439317691; Mon, 10 Mar 2014 01:15:17 -0700 (PDT) Received: by 10.194.89.1 with HTTP; Mon, 10 Mar 2014 01:15:17 -0700 (PDT) In-Reply-To: <531D5508.4000707@gmail.com> References: <531D5508.4000707@gmail.com> Date: Mon, 10 Mar 2014 10:15:17 +0200 Message-ID: From: Yoav Nir To: Yaron Sheffer Content-Type: multipart/alternative; boundary=089e01493de031204704f43c344a Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/e5riurbe2rpZcoshaMYM8mhXI_M Cc: ipsec Subject: Re: [IPsec] ChaCha20 & Poly1305, AEAD and other modes 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 Mar 2014 08:15:25 -0000 --089e01493de031204704f43c344a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer wrote: > Hi Yoav, > > Can you explain why we need Poly1305 at all? We have SHA-2 and will > probably adopt Keccak (SHA-3), so it's not like we don't have a backup. > Sure. Poly1305 is fast.Faster than SHA-1, SHA-2, and Keccak. I haven't compared it to GMAC on Intel, but that is fast only becuase it has special Intel instructions like PCLMULQD. Both ChaCha and Poly1305 can be fast in a plain C implementation, so they're fast on any platform. Poly1305 needs another algorithm to generate the per-message keys. That could be AES as in DJB's original paper, or it can be ChaCha as in this draft (with or without the AEAD). > Let me suggest that we adopt *only* ChaCha20, which can be combined with > any integrity protection algorithm in the normal ESP way. Is there any > extra value (maybe code sharing?) in predefining an AEAD? > The AEAD version is already in at least one crypto library (NSS as used in Chrome) and there's a patch that AGL donated to OpenSSL (not in there yet). So in addition to AEADs being fashionable, this combination makes sense for performance, especially on non-Intel platforms. Yoav --089e01493de031204704f43c344a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer &l= t;yaronf.ietf@gm= ail.com> wrote:
Hi Yoav,

Can you explain why we need Poly1305 at all? We have SHA-2 and will probabl= y adopt Keccak (SHA-3), so it's not like we don't have a backup.

Sure.=A0 Poly1305 is fast.Faster than SHA= -1, SHA-2, and Keccak. I haven't compared it to GMAC on Intel, but that= is fast only becuase it has special Intel instructions like PCLMULQD. Both= ChaCha and Poly1305 can be fast in a plain C implementation, so they'r= e fast on any platform.=A0 Poly1305 needs another algorithm to generate the= per-message keys. That could be AES as in DJB's original paper, or it = can be ChaCha as in this draft (with or without the AEAD).
=A0
Let me suggest that we adopt *only* ChaCha20, which can be combined with an= y integrity protection algorithm in the normal ESP way. Is there any extra = value (maybe code sharing?) in predefining an AEAD?

The AEAD version is already in at least one crypto library (= NSS as used in Chrome) and there's a patch that AGL donated to OpenSSL = (not in there yet). So in addition to AEADs being fashionable, this combina= tion makes sense for performance, especially on non-Intel platforms.

Yoav
=A0
--089e01493de031204704f43c344a-- From nobody Mon Mar 10 01:43:15 2014 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 EEBAF1A0404 for ; Mon, 10 Mar 2014 01:43:13 -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 IMBQp4RD0Hy1 for ; Mon, 10 Mar 2014 01:43:11 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 621321A03FD for ; Mon, 10 Mar 2014 01:43:11 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id t61so8260185wes.17 for ; Mon, 10 Mar 2014 01:43:05 -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=AhzRL6l4H82Z7L7tiBu+xtOgKO+uYmBVNabZWkMg8dc=; b=mW71zfYoUnqyN9uAAZRZZ9u8UDoyyMLLpbIbM2q8AMfLNdbGX5YP2WS8XVvfyxAY+T IssjewhdllDtmJLXY7pBIeQGBY7bwIaoOq911ZxHVpbDD9YqQKkYBKEmuXmGBbxrjKPw VAKg5TJeC135auMihDTdUCGW2NhotHy7kBpFTBMesYCLqnhaPhrn+UuHroe+vVwG6pmu ZWgzEOD1Wt4kESKWXIdZs+wrRUoCI/3bVBMi0ui34ttNev5Il+ibglVZ7MUev0IVceq6 3ggC/YIPtKAVLZIl5pOrazhXG1G3FGGfxUqmIs+TQjqSu2VOJITfRiDVGylU6LAhFznC hJcQ== MIME-Version: 1.0 X-Received: by 10.180.89.225 with SMTP id br1mr7049898wib.38.1394440985636; Mon, 10 Mar 2014 01:43:05 -0700 (PDT) Received: by 10.194.171.225 with HTTP; Mon, 10 Mar 2014 01:43:05 -0700 (PDT) In-Reply-To: References: <531D5508.4000707@gmail.com> Date: Mon, 10 Mar 2014 09:43:05 +0100 Message-ID: From: Daniel Migault To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/VGgctE8IPc_J3U9XhLbzkji-65w Cc: ipsec Subject: Re: [IPsec] ChaCha20 & Poly1305, AEAD and other modes 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 Mar 2014 08:43:14 -0000 Hi, My understanding is that Poly1305 and chacha20 are provided as "alternatives" to SHA* or AES*. Specific devices with AES accelerations may be willing, for performance optimization, to use Poly1305 instead of SHA with AES. For this reason it might be better to have: - chacha20 as a stand-alone cipher - Poly1305 as a stand-alone MAC On the other hand, providing the AEAD chacha20-poly1305 may be helpful for end users or admins. Especially if security consideration recommends AEAD. Would it bring too much complexity to also define AEAD chacha20-poly1305? BR Daniel On Mon, Mar 10, 2014 at 9:15 AM, Yoav Nir wrote: > > > > On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer > wrote: >> >> Hi Yoav, >> >> Can you explain why we need Poly1305 at all? We have SHA-2 and will >> probably adopt Keccak (SHA-3), so it's not like we don't have a backup. > > > Sure. Poly1305 is fast.Faster than SHA-1, SHA-2, and Keccak. I haven't > compared it to GMAC on Intel, but that is fast only becuase it has special > Intel instructions like PCLMULQD. Both ChaCha and Poly1305 can be fast in a > plain C implementation, so they're fast on any platform. Poly1305 needs > another algorithm to generate the per-message keys. That could be AES as in > DJB's original paper, or it can be ChaCha as in this draft (with or without > the AEAD). > >> >> Let me suggest that we adopt *only* ChaCha20, which can be combined with >> any integrity protection algorithm in the normal ESP way. Is there any extra >> value (maybe code sharing?) in predefining an AEAD? > > > The AEAD version is already in at least one crypto library (NSS as used in > Chrome) and there's a patch that AGL donated to OpenSSL (not in there yet). > So in addition to AEADs being fashionable, this combination makes sense for > performance, especially on non-Intel platforms. > > Yoav > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Mon Mar 10 01:51:12 2014 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 9237F1A03FB for ; Mon, 10 Mar 2014 01:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 x2UVeTJTr8nA for ; Mon, 10 Mar 2014 01:51:08 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DEC2F1A03FA for ; Mon, 10 Mar 2014 01:51:07 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so5767569wgh.3 for ; Mon, 10 Mar 2014 01:51:02 -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=qHrSbEQsAHog1P1JxZ8tg3QJz+w8QbYWpHOV7IkC0Lk=; b=Ki/sssF+8P1uWkCKRutzNt9Xmh+Cp4XhNe8LFuNtOZ4DWhjN2qrJUSRRkAWzEqX7lT eKOf5rukoUH0WyaTYKPjLrQOamYXZ+YDti5OOr6fV4FCvIUBZCf8XDbmgwRUuWyagfCX 8ygsnzsnqAPKRI/eTOT32d6h65navQ43tMCF8W9yyboRal3lW1uf4z5OqSSgoBplYW8B fVwMq/Fnakwu03ledQrlB0tG9Vyb9f5fKx+/pzkdm6hh+DUffChSGbOLO+TdjbJn8eZo oNXtdLnit2ENR/M6wAePB9RCwF4uQWQVuXF87GS38jHBPu0kjZy6Zd7KCon6I0W9ARj4 Y3OQ== MIME-Version: 1.0 X-Received: by 10.194.91.232 with SMTP id ch8mr29999278wjb.13.1394441462038; Mon, 10 Mar 2014 01:51:02 -0700 (PDT) Received: by 10.194.89.1 with HTTP; Mon, 10 Mar 2014 01:51:01 -0700 (PDT) In-Reply-To: References: <531D5508.4000707@gmail.com> Date: Mon, 10 Mar 2014 10:51:01 +0200 Message-ID: From: Yoav Nir To: Daniel Migault Content-Type: multipart/alternative; boundary=047d7bd916b401442e04f43cb4b0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ds_n3c0uldSDWm-nC-wXqUGoxIw Cc: ipsec Subject: Re: [IPsec] ChaCha20 & Poly1305, AEAD and other modes 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 Mar 2014 08:51:10 -0000 --047d7bd916b401442e04f43cb4b0 Content-Type: text/plain; charset=ISO-8859-1 The draft currently has all three: standalone ChaCha, standalone Poly1305, and AEAD. Standalone Poly1305 has the issue that it requires a one-time key or a nonce to generate it, but ESP only allows an IV for the cipher, not for the MAC. The draft deals with it by using the replay counter as a nonce, but then changes APIs. That is one reason why some people are opposed to standalone Poly1305. Yoav On Mon, Mar 10, 2014 at 10:43 AM, Daniel Migault wrote: > Hi, > > My understanding is that Poly1305 and chacha20 are provided as > "alternatives" to SHA* or AES*. Specific devices with AES > accelerations may be willing, for performance optimization, to use > Poly1305 instead of SHA with AES. For this reason it might be better > to have: > - chacha20 as a stand-alone cipher > - Poly1305 as a stand-alone MAC > > On the other hand, providing the AEAD chacha20-poly1305 may be helpful > for end users or admins. Especially if security consideration > recommends AEAD. Would it bring too much complexity to also define > AEAD chacha20-poly1305? > > BR > Daniel > > > > On Mon, Mar 10, 2014 at 9:15 AM, Yoav Nir wrote: > > > > > > > > On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer > > wrote: > >> > >> Hi Yoav, > >> > >> Can you explain why we need Poly1305 at all? We have SHA-2 and will > >> probably adopt Keccak (SHA-3), so it's not like we don't have a backup. > > > > > > Sure. Poly1305 is fast.Faster than SHA-1, SHA-2, and Keccak. I haven't > > compared it to GMAC on Intel, but that is fast only becuase it has > special > > Intel instructions like PCLMULQD. Both ChaCha and Poly1305 can be fast > in a > > plain C implementation, so they're fast on any platform. Poly1305 needs > > another algorithm to generate the per-message keys. That could be AES as > in > > DJB's original paper, or it can be ChaCha as in this draft (with or > without > > the AEAD). > > > >> > >> Let me suggest that we adopt *only* ChaCha20, which can be combined with > >> any integrity protection algorithm in the normal ESP way. Is there any > extra > >> value (maybe code sharing?) in predefining an AEAD? > > > > > > The AEAD version is already in at least one crypto library (NSS as used > in > > Chrome) and there's a patch that AGL donated to OpenSSL (not in there > yet). > > So in addition to AEADs being fashionable, this combination makes sense > for > > performance, especially on non-Intel platforms. > > > > Yoav > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > --047d7bd916b401442e04f43cb4b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The draft currently has all three: standalone Ch= aCha, standalone Poly1305, and AEAD.

Standalone Poly1305 has t= he issue that it requires a one-time key or a nonce to generate it, but ESP= only allows an IV for the cipher, not for the MAC. The draft deals with it= by using the replay counter as a nonce, but then changes APIs. That is one= reason why some people are opposed to standalone Poly1305.

Yoav


On Mon, Mar 10, 2014 at 10:43 AM, Daniel Migault <mg= lt.ietf@gmail.com> wrote:
Hi,

My understanding is that Poly1305 and chacha20 are provided as
"alternatives" to SHA* or AES*. Specific devices with AES
accelerations may be willing, for performance optimization, to use
Poly1305 instead of SHA with AES. For this reason it might be better
to have:
=A0 =A0 - chacha20 as a stand-alone cipher
=A0 =A0 - Poly1305 as a stand-alone MAC

On the other hand, providing the AEAD chacha20-poly1305 may be helpfu= l
for end users or admins. Especially if security consideration
recommends AEAD. Would it bring too much complexity to also define
AEAD chacha20-poly1305?

BR
Daniel



On Mon, Mar 10, 2014 at 9:15 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>
>
>
> On Mon, Mar 10, 2014 at 8:00 AM, Yaron Sheffer <yaronf.ietf@gmail.com>
> wrote:
>>
>> Hi Yoav,
>>
>> Can you explain why we need Poly1305 at all? We have SHA-2 and wil= l
>> probably adopt Keccak (SHA-3), so it's not like we don't h= ave a backup.
>
>
> Sure. =A0Poly1305 is fast.Faster than SHA-1, SHA-2, and Keccak. I have= n't
> compared it to GMAC on Intel, but that is fast only becuase it has spe= cial
> Intel instructions like PCLMULQD. Both ChaCha and Poly1305 can be fast= in a
> plain C implementation, so they're fast on any platform. =A0Poly13= 05 needs
> another algorithm to generate the per-message keys. That could be AES = as in
> DJB's original paper, or it can be ChaCha as in this draft (with o= r without
> the AEAD).
>
>>
>> Let me suggest that we adopt *only* ChaCha20, which can be combine= d with
>> any integrity protection algorithm in the normal ESP way. Is there= any extra
>> value (maybe code sharing?) in predefining an AEAD?
>
>
> The AEAD version is already in at least one crypto library (NSS as use= d in
> Chrome) and there's a patch that AGL donated to OpenSSL (not in th= ere yet).
> So in addition to AEADs being fashionable, this combination makes sens= e for
> performance, especially on non-Intel platforms.
>
> Yoav
>
>
> __________________= _____________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



--
Daniel Migault
Orange Labs -- Security
+33 6 = 70 72 69 58

--047d7bd916b401442e04f43cb4b0-- From nobody Mon Mar 10 07:33:14 2014 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 217281A048F for ; Mon, 10 Mar 2014 07:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6] 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 WZatJqSmbFhX for ; Mon, 10 Mar 2014 07:33:12 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 014901A048C for ; Mon, 10 Mar 2014 07:33:11 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6BD79800AF; Mon, 10 Mar 2014 10:33:05 -0400 (EDT) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2AEX4uI027271; Mon, 10 Mar 2014 10:33:04 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 10 Mar 2014 10:33:04 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Yoav Nir In-Reply-To: Message-ID: References: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/FO9x6jgQ2t5JaxRrUpzfePb55KM Cc: ipsec Subject: Re: [IPsec] ChaCha20 & Poly1305, AEAD and other modes 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 Mar 2014 14:33:13 -0000 On Sun, 9 Mar 2014, Yoav Nir wrote: > Some people in the room said that we should only do the AEAD and skip the stand-alone algorithms. This would prevent SAs with combinations such > as ChaCha20 + HMAC-SHA1 or AES-128-CBC + Poly1305. > > I'm not saying whether we need or don't need these combinations. I don't see much use for them personally. My question to the list now is > whether everyone agrees that it's fine to drop them and leave only the combined mode algorithm in the draft. Yes. We have too many algorithms in IKE already. If we believe that combined mode algorithms are better than classic ENCR+INTEG algorithms, and I think we do, than we should not be adding more old style ENCR+INTEG algorithms. Paul From nobody Mon Mar 10 08:36:21 2014 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 CAB311A0371 for ; Mon, 10 Mar 2014 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 9LemZ8ZA3YIJ for ; Mon, 10 Mar 2014 08:36:15 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 90DAA1A0438 for ; Mon, 10 Mar 2014 08:36:15 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s2AFa7KC004913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Mar 2014 17:36:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s2AFa6J9003056; Mon, 10 Mar 2014 17:36:06 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21277.56294.130740.433216@fireball.kivinen.iki.fi> Date: Mon, 10 Mar 2014 17:36:06 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 10 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/8_W-4TlElTIflx1UssEu8nU8liY Cc: ipsec Subject: [IPsec] ChaCha20 & Poly1305, AEAD and other modes 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 Mar 2014 15:36:19 -0000 Yoav Nir writes: > Hi > > draft-nir-ipsecme-chacha20-poly1305 currently specifies three transforms: > > 1. chacha20 as a stand-alone cipher > 2. Poly1305 as a stand-alone MAC > 3. ChaCha20-Poly1305 as an AEAD. > > Some people in the room said that we should only do the AEAD and skip the > stand-alone algorithms. This would prevent SAs with combinations such as > ChaCha20 + HMAC-SHA1 or AES-128-CBC + Poly1305. I would suggest only keeping the AEED. For example AES-128-CBC + Poly1305 does not make any sense, especially if the Poly1305 is still defined to use ChaCha20 to generate keying material for the Poly1305, i.e. AES-128-CBC + Poly1305 will need to implement ChaCha20 too... We also already have multiple quite ok MACs and I assume we will have more when SHA3 stuff goes through, so there is no need for standalone Poly1305. There might be some uses for standalone ChaCha20, but I think it would be more important to keep things simple, and just define one thing and that would be AEAD mode. > I'm not saying whether we need or don't need these combinations. I > don't see much use for them personally. My question to the list now > is whether everyone agrees that it's fine to drop them and leave > only the combined mode algorithm in the draft. BTW, One the questions I had there that as the Poly1305 requires separate key for each invocation and the draft uses ChaCha20 to generate key, but if I have understood correct the way it generates the key only gives out random unpredictable keys, but it does not generate unique keys. If I understood correctly the original Poly1305 document used AES in a way which did generate unique keys for each poly1305 invocation. The draft-nir-cfrg-chacha20-poly1305 says the "The pair (r,s) should be unique, and MUST be unpredictable...". Should we add some text there explaining why the way in draft-nir-ipsecme-chacha20-poly1305 is ok, i.e. that even when we truncate the 512 bit output and only take 256 bits of it, the propability of using same key twice is negligible. -- kivinen@iki.fi From nobody Mon Mar 10 09:05:49 2014 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 272491A04C5 for ; Mon, 10 Mar 2014 09:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 Z4mUnQ5gGSHq for ; Mon, 10 Mar 2014 09:05:31 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 994821A04E8 for ; Mon, 10 Mar 2014 09:05:28 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:41210 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WN2he-0000xY-Mp for ipsec@ietf.org; Mon, 10 Mar 2014 12:05:22 -0400 Message-ID: <531DE2C2.7050109@bbn.com> Date: Mon, 10 Mar 2014 12:05:22 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/q65zE_wXMXv5BbnNbFo17lzM1MU Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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 Mar 2014 16:05:41 -0000 Paul > On Mar 8, 2014, at 8:08 AM, Black, David wrote: > >>> The next draft changes AES-128-CBC to AES-CBC, and says: >>> >>> In the following sections, all AES modes are for 128-bit AES. 192-bit AES >>> MAY be supported for those modes, but the requirements here are for 128-bit >>> AES. >> What about 256-bit AES keys? They should also be a "MAY". > Why not SHOULD for 192 and 256 bit keys? > > paul It's good to remember the reason that 256-bits keys for AES were specified, i.e., as a hedge against someone building a quantum computer. So, unless the data being encrypted is expected to have a lifetime far enough into the future as to merit protection against that concern, the extra time needed to perform AES-256 vs. AES-128 does not seem justified. Steve From nobody Mon Mar 10 09:13:20 2014 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 A1F401A04AE for ; Mon, 10 Mar 2014 09:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.448 X-Spam-Level: X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, 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 EdFyVItQoORb for ; Mon, 10 Mar 2014 09:13:18 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id E418A1A0449 for ; Mon, 10 Mar 2014 09:13:17 -0700 (PDT) X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="4.97,625,1389765600"; d="scan'208";a="563214245" From: To: Thread-Topic: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts Thread-Index: Ac86z4SnMEREQoCDQC27eSw4Gtdo9AAa9ryAAFpE3wAAAECFgA== Date: Mon, 10 Mar 2014 16:12:36 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> <531DE2C2.7050109@bbn.com> In-Reply-To: <531DE2C2.7050109@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.216.26] Content-Type: text/plain; charset="Windows-1252" Content-ID: <87BF259094F5A3428D0F75608D7327CB@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/wHvEnHRtJ3HnwYy8heistMFtu4Q Cc: ipsec@ietf.org Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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 Mar 2014 16:13:19 -0000 On Mar 10, 2014, at 12:05 PM, Stephen Kent wrote: > Paul >> On Mar 8, 2014, at 8:08 AM, Black, David wrote: >>=20 >>>> The next draft changes AES-128-CBC to AES-CBC, and says: >>>>=20 >>>> In the following sections, all AES modes are for 128-bit AES. 192-bit = AES >>>> MAY be supported for those modes, but the requirements here are for 12= 8-bit >>>> AES. >>> What about 256-bit AES keys? They should also be a "MAY". >> Why not =93SHOULD=94 for 192 and 256 bit keys? >>=20 >> paul > It's good to remember the reason that 256-bits keys for AES were specifie= d, > i.e., as a hedge against someone building a quantum computer. So, unless = the > data being encrypted is expected to have a lifetime far enough into the f= uture > as to merit protection against that concern, the extra time needed to per= form > AES-256 vs. AES-128 does not seem justified. >=20 > Steve That=92s a good argument for a user choosing to use AES-128 rather than AES= -256. But it doesn=92t really address why =93SHOULD implement=94 isn=92t j= ustified =97 the implementation cost is trivial and if it isn=92t used it h= as no performance impact. paul From nobody Mon Mar 10 09:45:42 2014 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 A1C881A0515 for ; Mon, 10 Mar 2014 09:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 CRfThDrlhgBP for ; Mon, 10 Mar 2014 09:45:34 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id D3ACA1A04E7 for ; Mon, 10 Mar 2014 09:45:34 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EB0B5800AF; Mon, 10 Mar 2014 12:45:28 -0400 (EDT) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s2AGjS0Q001672; Mon, 10 Mar 2014 12:45:28 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 10 Mar 2014 12:45:28 -0400 (EDT) From: Paul Wouters X-X-Sender: paul@bofh.nohats.ca To: Paul_Koning@Dell.com In-Reply-To: Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> <531DE2C2.7050109@bbn.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/2cJzFb9qhPZuomwJIZktfeqplMI Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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 Mar 2014 16:45:39 -0000 On Mon, 10 Mar 2014, Paul_Koning@Dell.com wrote: > That’s a good argument for a user choosing to use AES-128 rather than AES-256. But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it isn’t used it has no performance impact. It's not the implementation cost that matters. It is the GUI confusion. For example one vendor uses "aes" as aes128, and another vendor uses "aes" for aes256 (or aes_ctr or aes_cbc or aes_gcm). Each option we expose needlessly to the enduser is one more potential interop issue. Paul From nobody Mon Mar 10 09:58:21 2014 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 CA4F21A0552 for ; Mon, 10 Mar 2014 09:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 y3Oox53WvXAJ for ; Mon, 10 Mar 2014 09:58:16 -0700 (PDT) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by ietfa.amsl.com (Postfix) with ESMTP id 0522C1A0505 for ; Mon, 10 Mar 2014 09:58:15 -0700 (PDT) X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="4.97,625,1389765600"; d="scan'208";a="443715045" From: To: Thread-Topic: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts Thread-Index: AQHPPIAkMEREQoCDQC27eSw4Gtdo9Jra3qEA Date: Mon, 10 Mar 2014 16:58:07 +0000 Message-ID: References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> <531DE2C2.7050109@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.152.216.26] Content-Type: text/plain; charset="Windows-1252" Content-ID: <559218A20A512F4DB0238C1A95AC6BC7@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/WdWV-329L7lNjxOYyMRpWE2ekPo Cc: ipsec@ietf.org Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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 Mar 2014 16:58:19 -0000 On Mar 10, 2014, at 12:45 PM, Paul Wouters wrote: > On Mon, 10 Mar 2014, Paul_Koning@Dell.com wrote: >=20 >> That=92s a good argument for a user choosing to use AES-128 rather than = AES-256. But it doesn=92t really address why =93SHOULD implement=94 isn=92= t justified =97 the implementation cost is trivial and if it isn=92t used i= t has no performance impact. >=20 > It's not the implementation cost that matters. It is the GUI confusion. > For example one vendor uses "aes" as aes128, and another vendor uses > "aes" for aes256 (or aes_ctr or aes_cbc or aes_gcm). Each option we > expose needlessly to the enduser is one more potential interop issue. True. But if you assume sufficiently foolish GUI designs, just about anyth= ing can be hard to use. And I don=92t think that good crypto design should= be put at the mercy of people who can=92t design a decent UI. We know tha= t it=92s possible to get this right. paul From nobody Mon Mar 10 10:29:59 2014 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 09C1D1A06CD for ; Mon, 10 Mar 2014 10:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 hLpOU-4JjSKW for ; Mon, 10 Mar 2014 10:29:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id A56561A06CB for ; Mon, 10 Mar 2014 10:29:55 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:43668 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1WN41U-000LGX-10; Mon, 10 Mar 2014 13:29:56 -0400 Message-ID: <531DF68C.5060408@bbn.com> Date: Mon, 10 Mar 2014 13:29:48 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Paul_Koning@Dell.com References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> <531DE2C2.7050109@bbn.com> In-Reply-To: Content-Type: text/plain; charset=Windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/xhdsKwMNt5Tjz_oXgJPcvdEnjTg Cc: ipsec@ietf.org Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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 Mar 2014 17:29:57 -0000 Paul, > ... >> It's good to remember the reason that 256-bits keys for AES were specified, >> i.e., as a hedge against someone building a quantum computer. So, unless the >> data being encrypted is expected to have a lifetime far enough into the future >> as to merit protection against that concern, the extra time needed to perform >> AES-256 vs. AES-128 does not seem justified. >> >> Steve > Thats a good argument for a user choosing to use AES-128 rather than AES-256. But it doesnt really address why SHOULD implement isnt justified the implementation cost is trivial and if it isnt used it has no performance impact. > > paul I have been told by some commercial security consultants that their customers believe that bigger is more secure, and thus they should mandate use of longer key lengths if they are available. If that report is accurate, then making AES-256 a SHOULD (vs. a MAY) creates a situation where the performance penalty will be incurred, for no good reason. But, I'm not going to fall on my sword for this. Steve From nobody Mon Mar 10 23:06:17 2014 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 D80C31A0641 for ; Mon, 10 Mar 2014 23:06:15 -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 qWpJ3-e2Ca8t for ; Mon, 10 Mar 2014 23:06:13 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7178E1A0649 for ; Mon, 10 Mar 2014 23:06:13 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id lf12so2385043vcb.11 for ; Mon, 10 Mar 2014 23:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=pnhz9TeoA+KBXEgyLWGYh+w3G02wShWQPTpFOaCjIj0=; b=QtUy69opCJN7qQ5gOQ6dK4pX7z6pIuw2rx1QvL3ng7+oC/XNWhjXVjRF8lzMXVC/+2 LbdbnrAjP3Pa1s4t3HALAuhvMVgcKRr0hOOUX4mDuxUON57X6lWkpCxUZh41jXxTRWnK 4OaEpSglHMbmIKlzwvqoXzZgKS6XrSbfLvVAJS8OnWr6gJ3YSocgKYMxHg4kVth3Atc6 /YgBswDSBGh/T9/Waz20EhSaJqAI/E+ye/Rbz1/8OoNMsFJr5PlRuxu5kz7tC4rTsdfc 9koukOFQnZxsG43ap/iQ+UvkTXYh9RMnfjonQyb6KZ8aoDDUaPxBfRFfaO41ytUwHPh6 9V1g== X-Received: by 10.52.35.196 with SMTP id k4mr214551vdj.38.1394517967684; Mon, 10 Mar 2014 23:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.119.134 with HTTP; Mon, 10 Mar 2014 23:05:45 -0700 (PDT) In-Reply-To: References: <8D3D17ACE214DC429325B2B98F3AE71206CF439362@MX15A.corp.emc.com> <531DE2C2.7050109@bbn.com> From: Gandhar Gokhale Date: Tue, 11 Mar 2014 11:35:45 +0530 Message-ID: To: Paul_Koning@dell.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3fUL2NLx-8z4bjkWcVYImBMRiPc Cc: ipsec@ietf.org, paul@cypherpunks.ca Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts 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 Mar 2014 06:06:16 -0000 And testing cost for one more crypto algorithm when the algorithmic permutations are already too high! Gandhar Gokhale Networking Components Group LSI On Mon, Mar 10, 2014 at 10:28 PM, wrote: > > On Mar 10, 2014, at 12:45 PM, Paul Wouters wrote: > >> On Mon, 10 Mar 2014, Paul_Koning@Dell.com wrote: >> >>> That's a good argument for a user choosing to use AES-128 rather than A= ES-256. But it doesn't really address why "SHOULD implement" isn't justifi= ed -- the implementation cost is trivial and if it isn't used it has no per= formance impact. >> >> It's not the implementation cost that matters. It is the GUI confusion. >> For example one vendor uses "aes" as aes128, and another vendor uses >> "aes" for aes256 (or aes_ctr or aes_cbc or aes_gcm). Each option we >> expose needlessly to the enduser is one more potential interop issue. > > True. But if you assume sufficiently foolish GUI designs, just about any= thing can be hard to use. And I don't think that good crypto design should= be put at the mercy of people who can't design a decent UI. We know that = it's possible to get this right. > > paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Mar 11 08:03:50 2014 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 B15851A0479 for ; Tue, 11 Mar 2014 08:03:48 -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 zZTZ0xb9Nyb8 for ; Tue, 11 Mar 2014 08:03:46 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 877BB1A0755 for ; Tue, 11 Mar 2014 08:03:46 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so7897824wgh.27 for ; Tue, 11 Mar 2014 08:03:40 -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=IyZt3W4zkYe2gX+sHC/DcqOQ5MBNVKJmj3KePV+/iOQ=; b=K5qHt16jIsIDjOeUnKP+58OHlzjhnWKfxdLb3DZOtuTetk6YBveFKd/hVkr2NgrwKy wNGxnVg1QiJ72eY+azgmWcBpPhsqC57qdlOuVC0EE2PVu4/Srbb3eipwbrKUkLtlYC4C XiIJnAHGKvMvU8a5c9BF/vkmu4g/sPcjzTeoRSPvI1HD/RjV3q0f8gOgQLIpyexNo3vy jdG6/Ud7Z9KO35vnYniob37SpTTaixJaeZprAJcL9H9hUXulkosBEP0xEY49eoQ1mAMV UD+ZCTSbTWE8oC54UEgtij19dbOi9wnFthwJOFruuGxRe4pLLDMsCn9fcSz53KYfIr7q 9CZA== MIME-Version: 1.0 X-Received: by 10.180.13.33 with SMTP id e1mr3562338wic.38.1394550220400; Tue, 11 Mar 2014 08:03:40 -0700 (PDT) Received: by 10.194.171.225 with HTTP; Tue, 11 Mar 2014 08:03:40 -0700 (PDT) In-Reply-To: References: <21271.44610.414071.370642@fireball.kivinen.iki.fi> Date: Tue, 11 Mar 2014 16:03:40 +0100 Message-ID: From: Daniel Migault To: Paul Hoffman , Tero Kivinen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Ya77-BsC-TTRrgJWkFCf3SdIMAI Cc: ipsec Subject: Re: [IPsec] Some comments to draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01 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 Mar 2014 15:03:48 -0000 Hi Paul and Tero, Thanks for the comments we will clarify these points for the next version, and explicitly describe the dependance between these context. Thanks Daniel On Sat, Mar 8, 2014 at 11:47 AM, Paul Hoffman wrote: > On Mar 5, 2014, at 11:07 PM, Tero Kivinen wrote: > >> In section 2 it says: >> >> Note that IKEv2 and IPsec session do not need to be on the same node >> as IKEv2 and IPsec context are different. >> >> This is not so easy. The RFC5996 says: >> >> ---------------------------------------------------------------------- >> 2.4. State Synchronization and Connection Timeouts >> ... >> An implementation needs to stop sending over any SA if >> some failure prevents it from receiving on all of the associated SAs. >> If a system creates Child SAs that can fail independently from one >> another without the associated IKE SA being able to send a delete >> message, then the system MUST negotiate such Child SAs using separate >> IKE SAs. >> ---------------------------------------------------------------------- >> >> I.e. if any of the IPsec SAs fail, then all of IPsec SAs created using >> same IKE SA, and the IKE SA must also fail. If IPsec SAs and IKE SA >> are on separate nodes, that do set up new kind of requirements for >> those nodes. I.e. if one node having IPsec SAs fails, the node having >> IKE SA needs to detect this, and send delete notification for each >> IPsec SA that were in that node. Also if the node having the IKE SA >> will fail, then all the IPsec SAs associated with that IKE SA, must >> stop sending, i.e. they needs to be destroyed. > > Tero's comment nails the concern I had when reading the document. IKEv2 ties Child SAs to their parent SA, and using the context of one without the other seems dangerous. > > --Paul Hoffman > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Wed Mar 12 19:27:40 2014 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 5ECF31A0878 for ; Wed, 12 Mar 2014 19:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, 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 8lBjF4Z5z5hR for ; Wed, 12 Mar 2014 19:27:36 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 402601A0877 for ; Wed, 12 Mar 2014 19:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3942; q=dns/txt; s=iport; t=1394677650; x=1395887250; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qZiqVxpqiO6pPvZ53Id9jtDT+3sm8kpY6KzO2gNuos0=; b=K82Kcj4fYGSWWSWhZlt43WMQQTZ/9pUMPHILTSv6ixPuiOeCY0zqtih/ mDCWo7SXis3O3Yjx3JcIUrKcAdytAG5iwuzd7bEJwdrhIvkV36tPcIsBo OnoSMkFx+5UPS++GxufWhTz4R3YbtFSR5ekS5Ad9AUp2vKINhy4coKD17 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroFAFUWIVOtJV2a/2dsb2JhbABZgwY7UQaDBr5WGYEGFnSCJQEBAQQjETESDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBh3AIBbFVoUgXgSmNAjgGgmk1gRQEmXeQe4Mtgis X-IronPort-AV: E=Sophos;i="4.97,643,1389744000"; d="scan'208";a="27075780" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 13 Mar 2014 02:27:29 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2D2RTCA015967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 13 Mar 2014 02:27:29 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.141]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Wed, 12 Mar 2014 21:27:29 -0500 From: "Rajeshwar Singh Jenwar (rsj)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.txt Thread-Index: AQHPPeiOOW5BcXLSBkueOTatW1ZDU5reSmmg Date: Thu, 13 Mar 2014 02:27:28 +0000 Message-ID: References: <20140312114328.20101.44457.idtracker@ietfa.amsl.com> In-Reply-To: <20140312114328.20101.44457.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.71.204] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/w0nUH7Hni1DXGfqCBU3aoQNwWzU Subject: [IPsec] FW: New Version Notification for draft-amjads-ipsecme-ikev2-data-channel-01.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: Thu, 13 Mar 2014 02:27:38 -0000 SGksDQoNCldlIChBbWphZCBhbmQgSSkgaGF2ZSBwdWJsaXNoZWQgbmV3IHZlcnNpb24gb2YgIkRh dGEgb3ZlciBJS0V2MiBmb3IgYXBwbGljYXRpb24gc2VjdXJpdHkiIGRyYWZ0IGJhc2VkIG9uIGlu cHV0cy9jb21tZW50cyByZWNlaXZlZC4NClBsZWFzZSByZXZpZXcgYW5kIHByb3ZpZGUgY29tbWVu dHMvaW5wdXRzL3F1ZXN0aW9ucy4NCg0KS2luZCBSZWdhcmRzLA0KUmFqDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBNYXJjaCAxMiwgMjAx NCA1OjEzIFBNDQpUbzogQW1qYWQgSW5hbWRhciAoYW1qYWRzKTsgUmFqZXNod2FyIFNpbmdoIEpl bndhciAocnNqKTsgUmFqZXNod2FyIFNpbmdoIEplbndhciAocnNqKTsgQW1qYWQgSW5hbWRhciAo YW1qYWRzKQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1hbWph ZHMtaXBzZWNtZS1pa2V2Mi1kYXRhLWNoYW5uZWwtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWFtamFkcy1pcHNlY21lLWlrZXYyLWRhdGEtY2hhbm5lbC0wMS50eHQNCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQW1qYWQgUy4gSW5hbWRhciBhbmQgcG9z dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1hbWphZHMtaXBzZWNt ZS1pa2V2Mi1kYXRhLWNoYW5uZWwNClJldmlzaW9uOgkwMQ0KVGl0bGU6CQlJS0V2MiBiYXNlZCBs aWdodHdlaWdodCBzZWN1cmUgZGF0YSBjb21tdW5pY2F0aW9uIGRyYWZ0LWFtamFkcy1pcHNlY21l LWlrZXYyLWRhdGEtY2hhbm5lbC0wMSAoRC1JS0UpDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAzLTEy DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxNQ0KVVJMOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFtamFkcy1pcHNl Y21lLWlrZXYyLWRhdGEtY2hhbm5lbC0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hbWphZHMtaXBzZWNtZS1pa2V2Mi1kYXRhLWNo YW5uZWwvDQpIdG1saXplZDogICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YW1qYWRzLWlwc2VjbWUtaWtldjItZGF0YS1jaGFubmVsLTAxDQpEaWZmOiAgICAgICAgICAgaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYW1qYWRzLWlwc2VjbWUtaWtldjIt ZGF0YS1jaGFubmVsLTAxDQoNCkFic3RyYWN0Og0KICAgVGhlIEludGVybmV0IEtleSBFeGNoYW5n ZSAoSUtFdjIpIHByb3RvY29sIHByb3ZpZGVzIGF1dGhlbnRpY2F0aW9uLA0KICAgY29uZmlkZW50 aWFsaXR5LCBpbnRlZ3JpdHksIGRhdGEtb3JpZ2luIGF1dGhlbnRpY2F0aW9uIGFuZCBhbnRpLQ0K ICAgcmVwbGF5LiAgQ3VycmVudGx5LCBJS0V2MiBpcyBtYWlubHkgdXNlZCBhcyBhIGNvbnRyb2wg Y2hhbm5lbCB0bw0KICAgbmVnb3RpYXRlIElQc2VjIFNBKHMpLiAgSVBzZWMgaXMgbm90IHdlbGwg c3VpdGVkIHRvIHByb3ZpZGUgdHJhbnNwb3J0DQogICBsYXllciBzZWN1cml0eSBmb3IgYXBwbGlj YXRpb25zIGFzIGl0IHJlc2lkZXMgYXQgdGhlIG5ldHdvcmsgbGF5ZXINCiAgIGFuZCBtb3N0IG9m IHRoZSBJUHNlYyBpbXBsZW1lbnRhdGlvbnMgcmVxdWlyZSBpbnRlZ3JhdGlvbiBpbnRvDQogICBv cGVyYXRpbmcgc3lzdGVtcyBtYWtpbmcgaXQgZGlmZmljdWx0IHRvIGRlcGxveS4gIElQc2VjIHVz ZXMNCiAgIGRpZmZlcmVudCBzZXNzaW9ucyBmb3IgY29udHJvbCBhbmQgZGF0YSB0cmFmZmljIHdo aWNoIGlzIG5vdCBOQVQgYW5kDQogICBsb2FkIGJhbGFuY2VyIGZyaWVuZGx5LiAgVExTL0RUTFMs IHRoZSBvdGhlciBwb3B1bGFyIHNlY3VyaXR5DQogICBtZWNoYW5pc20gdG8gcHJvdmlkZSB0aGUg YWJvdmUgc2VjdXJpdHkgc2VydmljZXMgZG9lcyBub3QgbWFuZGF0ZQ0KICAgbXV0dWFsIHBlZXIg YXV0aGVudGljYXRpb24gYW5kIERpZmZpZSBIZWxsbWFuIGV4Y2hhbmdlLg0KDQogICBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyBhbiBJS0V2MiBiYXNlZCBsaWdodHdlaWdodCBzZWN1cmUgZGF0YQ0K ICAgY29tbXVuaWNhdGlvbiBwcm90b2NvbCBhbmQgYSB3YXkgdG8gcHJvdmlkZSB0cmFuc3BvcnQg bGF5ZXIgc2VjdXJpdHkNCiAgIGZvciBVRFAgY2xpZW50L3NlcnZlciBhcHBsaWNhdGlvbnMuICBU aGUgcHJvdG9jb2wgcHJvdmlkZXMgaW50ZWdyaXR5DQogICBwcm90ZWN0ZWQgZW5jcnlwdGlvbiBh bmQgaW50ZWdyaXR5LW9ubHkgcHJvdGVjdGlvbiBiYXNlZCBvbg0KICAgYXBwbGljYXRpb24gbmVl ZHMuICBBcyBtb3N0IG9mIHRoZSBJb1QgYXBwbGljYXRpb25zIGFyZSBVRFAgYmFzZWQsDQogICBJ S0V2MiBjYW4gYmUgdXNlZCBmb3Iga2V5IG1hbmFnZW1lbnQgYXMgd2VsbCBzZWN1cmUgZGF0YQ0K ICAgY29tbXVuaWNhdGlvbiBpbiBJb1QgZHVlIHRvIGl0cyBzaW1wbGljaXR5LCBzY2FsYWJpbGl0 eSwNCiAgIGxpZ2h0d2VpZ2h0ZWRuZXNzIGFuZCBlYXNlIG9mIGRlcGxveW1lbnQuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBo dG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcu DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Thu Mar 13 01:51:51 2014 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 6966E1A0993 for ; Thu, 13 Mar 2014 01:51:47 -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 EkvB4gE5N8Gi for ; Thu, 13 Mar 2014 01:51:44 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9A31A097E for ; Thu, 13 Mar 2014 01:51:44 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so751725wiv.15 for ; Thu, 13 Mar 2014 01:51:37 -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:cc:content-type; bh=a8BFrV6mbvMEj1TrdBPY65BG5Ki4VhBlNWQC/IPfvUc=; b=ysq4VrvKDpuWlvJ20wmM4Apr291eNzoX8R9z5M4K1OCjN0vLu7BI9Dgg6boE6uxq8E 2L92VCNUWj6XXAVDEZbDkgk3LMpXLZEj6fDVoswn0tsAhFA7H3n0N1NHbN9p8rFfzPCZ G/FSW3f3P6hJHuVSLf5pP8oEwZzIzjYeoV7jKbYfYWCcteZWKewZiref8f8nW9VvCgw5 XhqzBbKF82bHq6CJy2Hi0x19JdbXywXIOJqhk66y97lNkNv3ssFw0X09VKGDoznD/331 HDqVocr93p4gaV/QD83qZ0UYSsLmFf14JXx4ZhJH/ofQNf3XFVVgLpxR2hSMgObuapve 6f5Q== MIME-Version: 1.0 X-Received: by 10.180.77.129 with SMTP id s1mr573169wiw.56.1394700697465; Thu, 13 Mar 2014 01:51:37 -0700 (PDT) Received: by 10.194.171.225 with HTTP; Thu, 13 Mar 2014 01:51:37 -0700 (PDT) Date: Thu, 13 Mar 2014 09:51:37 +0100 Message-ID: From: Daniel Migault To: "ipsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/sL4l1NJBN8dm9Fs4rSPuzRTVhmE Cc: Valery Smyslov Subject: [IPsec] Fwd: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.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: Thu, 13 Mar 2014 08:51:47 -0000 Hi, Please find the new version for the clone IKE SA draft. This version includes all comments we received. Feel free to let us know if there are more comments to address. BR, Danie Abstract: This document considers a VPN End User setting a VPN with a security gateway where at least one of the peer has multiple interfaces. With the current IKEv2, the outer IP addresses of the VPN are determined by those used by IKEv2 channel. As a result using multiple interfaces requires to set an IKEv2 channel on each interface, or on each paths if both the VPN Client and the security gateway have multiple interfaces. Setting multiple IKEv2 channel involves multiple authentications which may each require multiple round trips and delay the VPN establishment. In addition multiple authentications unnecessarily increase load to the VPN client and the authentication infrastructure. This document presents the Clone IKE SA extension, where an additional IKEv2 channel is derived from an already authenticated IKEv2 channel. The newly created IKEv2 channel is set without the IKEv2 authentication exchange. The newly created IKEv2 channel can then be assigned to another interface using MOBIKE. -------- Original Message -------- Subject: New Version Notification for draft-mglt-ipsecme-clone-ike-sa-01.txt Date: Thu, 13 Mar 2014 01:43:41 -0700 From: To: Valery Smyslov , Valery Smyslov , "Daniel Migault" , Daniel Migault A new version of I-D, draft-mglt-ipsecme-clone-ike-sa-01.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-ipsecme-clone-ike-sa Revision: 01 Title: Clone IKE SA Extension Document date: 2014-03-13 Group: Individual Submission Pages: 16 URL: http://www.ietf.org/internet-drafts/draft-mglt-ipsecme-clone-ike-sa-01.txt Status: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ Htmlized: http://tools.ietf.org/html/draft-mglt-ipsecme-clone-ike-sa-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-clone-ike-sa-01 Abstract: This document considers a VPN End User setting a VPN with a security gateway where at least one of the peer has multiple interfaces. With the current IKEv2, the outer IP addresses of the VPN are determined by those used by IKEv2 channel. As a result using multiple interfaces requires to set an IKEv2 channel on each interface, or on each paths if both the VPN Client and the security gateway have multiple interfaces. Setting multiple IKEv2 channel involves multiple authentications which may each require multiple round trips and delay the VPN establishment. In addition multiple authentications unnecessarily increase load to the VPN client and the authentication infrastructure. This document presents the Clone IKE SA extension, where an additional IKEv2 channel is derived from an already authenticated IKEv2 channel. The newly created IKEv2 channel is set without the IKEv2 authentication exchange. The newly created IKEv2 channel can then be assigned to another interface using MOBIKE. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Thu Mar 13 21:51:15 2014 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 CD2861A001D; Thu, 13 Mar 2014 21:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 HnzL0d3pp1Fv; Thu, 13 Mar 2014 21:51:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B93B1A0021; Thu, 13 Mar 2014 21:51:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140314045111.3778.63692.idtracker@ietfa.amsl.com> Date: Thu, 13 Mar 2014 21:51:11 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Q-dVxW0oyQI1o9DgzlQyZXaAEvw Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 04:51:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Fragmentation Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-fragmentation-06.txt Pages : 23 Date : 2014-03-13 Abstract: This document describes the way to avoid IP fragmentation of large IKEv2 messages. This allows IKEv2 messages to traverse network devices that don't allow IP fragments to pass through. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 13 22:27:57 2014 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 D82251A003D for ; Thu, 13 Mar 2014 22:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 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, 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 Ut9ZHyn6-EBm for ; Thu, 13 Mar 2014 22:27:54 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3511A002F for ; Thu, 13 Mar 2014 22:27:53 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id y1so1399523lam.37 for ; Thu, 13 Mar 2014 22:27:46 -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=TfHQE7W0sAqlzjcTpN33tzdEsZUVriDBQ8flt5ZCGWk=; b=l0q/GQinQy30T5A2Ohw/pTLjx/nKH7XLyg6aK/3hvV1eLqXrHbeBJBbPmGwvR4hldf 4OVZQtWbkuMvEAZ1W/OlYNIZ0uUO0bjQmpS5zqzd0QqixCndfpb+5OljHxdLu4Et3clY CUXXL8uAv6u7f3pyUH6T5as7NGTMjEgqAds4wOPNbQmtuyjFx3mfGeVJRjGlKHL9vTny /Ska1HQU4NKnkgIhmf+jc5z1PRFC5eXgNQVdCEZ5LMlHT703mxNd+naQTDC7N2UlMgLK 6K7idqAyZcssch76hGZdf3EAxEdKIJDiz7bHBt+cax6wuq5RNd9TnUM5MxlmHRqa+tkW zF1A== X-Received: by 10.152.190.135 with SMTP id gq7mr4047028lac.28.1394774866665; Thu, 13 Mar 2014 22:27:46 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id bm3sm4721008lbb.12.2014.03.13.22.27.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 13 Mar 2014 22:27:45 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: References: <20140314045111.3778.63692.idtracker@ietfa.amsl.com> Date: Fri, 14 Mar 2014 09:26:51 +0400 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: http://mailarchive.ietf.org/arch/msg/ipsec/CK35z3vp2iLdbvawZ1OS2IhNL_A Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-06.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: Fri, 14 Mar 2014 05:27:56 -0000 Hi all, the new version of the draft addresses comments, received during IETF LC: - "Encrypted Fragment Payload" is denoted also as "Encrypted and Authenticated Fragment Payload" - IKE_FRAGMENTATION_SUPPORTED is renamed to IKEV2_FRAGMENTATION_SUPPORTED - in Appendix B some text is added for IPv6 - fixed found typos and grammar errors Regards, Valery. ----- Original Message ----- From: To: Cc: Sent: Friday, March 14, 2014 8:51 AM Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-06.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > Title : IKEv2 Fragmentation > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-fragmentation-06.txt > Pages : 23 > Date : 2014-03-13 > > Abstract: > This document describes the way to avoid IP fragmentation of large > IKEv2 messages. This allows IKEv2 messages to traverse network > devices that don't allow IP fragments to pass through. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From jpylkkanen@insidesecure.com Fri Mar 14 03:48:19 2014 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 0F7321A0115 for ; Fri, 14 Mar 2014 03:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 Td_OM1QlLhgd for ; Fri, 14 Mar 2014 03:48:14 -0700 (PDT) Received: from mail.insidefr.com (mx2.insidefr.com [109.26.158.114]) by ietfa.amsl.com (Postfix) with ESMTP id 279711A011F for ; Fri, 14 Mar 2014 03:48:05 -0700 (PDT) Received: from mail.insidefr.com (unknown [10.159.145.201]) by mail.insidefr.com (Postfix) with ESMTP id BB01D702FE for ; Fri, 14 Mar 2014 11:48:12 +0100 (CET) Received: from garlaban.insidefr.com ([10.159.145.201]) by garlaban.insidefr.com ([10.159.145.201]) with mapi; Fri, 14 Mar 2014 11:47:58 +0100 From: Joonas Pylkkanen To: "IPsec@ietf.org" Date: Fri, 14 Mar 2014 11:47:57 +0100 Thread-Topic: INSIDE Secure answers to RFC 5996 and 3948 questionnaires Thread-Index: Ac8ecwd4OyzSDi/4QZiw0eFVD28mIgg/7nDQ Message-ID: <64F7B34BFE23834EA992CE91ABC59C521B5DB34BDF@garlaban.insidefr.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-10.0.0.1412-7.000.1014-20538.005 x-tm-as-result: No--54.963300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_004_64F7B34BFE23834EA992CE91ABC59C521B5DB34BDFgarlabaninsid_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/hRYjlMBxksofcFcNpn0I07ZfNgE X-Mailman-Approved-At: Fri, 14 Mar 2014 09:11:08 -0700 Subject: [IPsec] INSIDE Secure answers to RFC 5996 and 3948 questionnaires 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 Mar 2014 10:50:20 -0000 --_004_64F7B34BFE23834EA992CE91ABC59C521B5DB34BDFgarlabaninsid_ Content-Type: multipart/alternative; boundary="_000_64F7B34BFE23834EA992CE91ABC59C521B5DB34BDFgarlabaninsid_" --_000_64F7B34BFE23834EA992CE91ABC59C521B5DB34BDFgarlabaninsid_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear audience, Here is presented INSIDE Secure QuickSec IPsec toolkit and QuickSec VPNClie= nt answers to RFC 5996 and RFC 3948 questionnaires: Answers to RFC5996 questionnaire: --------------------------------- - Which of the IKEv2 exchanges you support: - IKE_SA_INIT (includes support for SA, KE, Ni, Nr payloads) All implemented and fully supported by QuickSec family of pr= oducts. - IKE_AUTH (includes support for SK, IDi, IDr, AUTH, TSi, TSr payloads) All implemented and fully supported by QuickSec family of pr= oducts. - CREATE_CHILD_SA Supported by QuickSec family of products. - INFORMATIONAL Supported by QuickSec family of products. - Which of the IKEv2 payloads your implementation supports - CERT Certificate - CERTREQ Certificate Request - CP Configuration - D Delete - EAP Extensible Authentication - N Notify - V Vendor ID All above are supported by QuickSec family of products. - Which of the following processing semantics does your implementation supp= ort (y/n): - Can your implementation create a new child SAs with the CREATE_CH= ILD_SA exchange?: Yes, supported by QuickSec family of products. - Can your implementation rekey an IKE SAs with the CREATE_CHILD_SA= Exchange?: Yes, supported by QuickSec family of products. - Can your implementation rekey a Child SAs with the CREATE_CHILD_S= A Exchange?: Yes, supported by QuickSec family of products. - Does your implementation support the INFORMATIONAL exchange? Yes, supported by QuickSec family of products. - Which of the IKEv2 authentication methods you support - PKIX Certificates as specified in section 4 - Shared key authentication as specified in section 4 - Mixed authentication, where responder uses Certificates and initiator uses shared key All above are supported by QuickSec family of products. -- Which of the usage scenarios does your implementation support (s1.1.1, s= 1.1.2, and s1.1.3): All scenarios supported by QuickSec family of products. - What evidence do you have that your implementation can interoperate with = other implementations? INSIDE Secure has always participated IPsec interoperability events= , as well, our QA for our implementation has extensive interoperability tests using other vendor products. - In your opinion, are there unused features in the RFC that greatly increa= se implementation complexity? No - Errata was filed against RFC 5996 and has been included in https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ikev2-rfc5996bis/; a= re any of the incorporated errata problematic for your implementation? No Answers to RFC3948 questionnaire: --------------------------------- Here's a proposed set of question for RFC 3948 implementers: The following questions document whether your implementation supports the s= yntax and semantics of the protocol: - Which of the following packet formats does your implementation support: - UDP-Encapsulated ESP Header Format (y/n): Y: Supported by QuickSec family of products. - IKE Header Format for Port 4500 (y/n): Y: Supported by QuickSec family of products. - NAT-Keepalive Packet Format (y/n): Y: Supported by QuickSec family of products. - Which of the following encapsulation and decapsulation processing rules d= oes your implementation support: - Auxiliary Processing - Tunnel Mode Decapsulation NAT Procedure (y/n): Y: Supported by QuickSec family of products. - Transport Mode Decapsulation NAT Procedure (y/n): Y: Supported by QuickSec family of products. - Transport Mode ESP Encapsulation (y/n): Y: Supported by QuickSec family of products. - Transport Mode ESP Decapsulation (y/n): Y: Supported by QuickSec family of products. - Tunnel Mode ESP Encapsulation (y/n): Y: Supported by QuickSec family of products. - Tunnel Mode ESP Decapsulation (y/n): Y: Supported by QuickSec family of products. - Does your implementation support the NAT keepalive procedure? (y/n): Y: Supported by QuickSec family of products. The following questions document whether interoperability has been achieved= as well as other intangibles the IESG will be interested. - What evidence do you have that your implementation can interoperate with = other implementations? INSIDE Secure has always participated IPsec interoperability events= , as well, our QA for our implementation has extensive interoperability tests using other vendor products. - In your opinion, are there unused features in the RFC that greatly increa= se implementation complexity? No Additional information (optional): Best Regards, [cid:image001.jpg@01CF1B76.D3DF4770] Joonas Pylkk=E4nen Director R&D, Embedded Security Solutions INSIDE Secure JPylkkanen@INSIDESecure.com --_000_64F7B34BFE23834EA992CE91ABC59C521B5DB34BDFgarlabaninsid_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Dear audience,<=
o:p>
 
Here is presented INSIDE Secure QuickSec IPsec to=
olkit and QuickSec VPNClient answers to RFC 5996 and RFC 3948 questionnaire=
s:
 <=
/pre>
 
Answers to RFC5996 questionnaire:
---------------------------------
- Which of the IKEv2 exchanges you support:=

      &n=
bsp; - IKE_SA_INIT (includes support for SA, KE, Ni, Nr payloads)
      &=
nbsp;        All implemented and fully s=
upported by QuickSec family of products.
        - IKE_AUTH (include=
s support for SK, IDi, IDr, AUTH, TSi, TSr
          payloads)<=
o:p>
    &nbs=
p;          All implemented an=
d fully supported by QuickSec family of products.
        - CREATE_C=
HILD_SA
   &n=
bsp;           Supported =
by QuickSec family of products.
        - INFORMATIONAL
      &nbs=
p;        Supported by QuickSec family o=
f products.
- Which of the I=
KEv2 payloads your implementation supports
        - CERT  =
;       Certificate
        - CERTREQ&= nbsp;     Certificate Request        - CP =           Configuration
     &nbs=
p;  - D          &nb=
sp; Delete
   =
;     - EAP       &n=
bsp;  Extensible Authentication
        - N   &n=
bsp;        Notify
        - V&nb=
sp;           Vendor ID
     =
;   All above are supported by QuickSec family of products.<=
/o:p>
 
- Which of the following processing semantics does you=
r implementation support (y/n):
        - Can your implementation cr=
eate a new child SAs with the CREATE_CHILD_SA exchange?:<=
/pre>
       &nbs=
p;       Yes, supported by QuickSec family of=
 products.
   =
;     - Can your implementation rekey an IKE SAs with t=
he CREATE_CHILD_SA Exchange?:
            &=
nbsp;  Yes, supported by QuickSec family of products.
        -=
 Can your implementation rekey a Child SAs with the CREATE_CHILD_SA Exchang=
e?:
    =
           Yes, supported=
 by QuickSec family of products.
        - Does your implementation =
support the INFORMATIONAL exchange?
           =
    Yes, supported by QuickSec family of products.
 
- Which of the IKEv2 authentication methods you support
     =
   - PKIX Certificates as specified in section 4
        -=
 Shared key authentication as specified in section 4
        - Mixed=
 authentication, where responder uses Certificates and
         =
; initiator uses shared key
=
        All above are supported by Quick=
Sec family of products.
 
-- Which of the usage sce=
narios does your implementation support (s1.1.1, s1.1.2, and s1.1.3):<=
/o:p>
     &nb=
sp;  All scenarios supported by QuickSec family of products.
- What evidence do you have that your=
 implementation can interoperate with other implementations?
       =
 INSIDE Secure has always participated IPsec interoperability events, as we=
ll, our QA for our implementation
        has extensive interoperabi=
lity tests using other vendor products.
- In your opinion, are there unused features in the RFC that gr=
eatly increase implementation complexity?
        No
- Errata was filed against RFC 5996 and has=
 been included in
https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-ike=
v2-rfc5996bis/; are any of the
incorporated errata problematic for your i=
mplementation?
  &=
nbsp;     No
 
 
Answers t=
o RFC3948 questionnaire:
---=
------------------------------
Here’s a proposed set of question for RFC 3948 implementers:<=
/o:p>
 
The following questions document whether your implemen=
tation supports the syntax and semantics of the protocol:=

 
- Which of the following packet formats does your implementation s=
upport:
   &n=
bsp;    - UDP-Encapsulated ESP Header Format (y/n):
      =
         Y: Supported by QuickSec f=
amily of products.
 &nb=
sp;      - IKE Header Format for Port 4500 (y/n):<=
o:p>
    &nbs=
p;          Y: Supported by Qu=
ickSec family of products.
&=
nbsp;       - NAT-Keepalive Packet Format (y/=
n):
    =
           Y: Supported b=
y QuickSec family of products.
 
- Which of the fol=
lowing encapsulation and decapsulation processing rules does your implement=
ation support:
  &=
nbsp;     - Auxiliary Processing
        &n=
bsp;      - Tunnel Mode Decapsulation NAT Procedur=
e (y/n):
   &=
nbsp;           &nbs=
p;       Y: Supported by QuickSec family of p=
roducts.
   &=
nbsp;           - Transpo=
rt Mode Decapsulation NAT Procedure  (y/n):
         =
            &nb=
sp; Y: Supported by QuickSec family of products.
        - Transport=
 Mode ESP Encapsulation (y/n):
            =
   Y: Supported by QuickSec family of products.=

        - =
Transport Mode ESP Decapsulation (y/n):
          &nb=
sp;    Y: Supported by QuickSec family of products.
      =
  - Tunnel Mode ESP Encapsulation (y/n):
<=
span lang=3DEN-US>         &nb=
sp;     Y: Supported by QuickSec family of products.
     =
   - Tunnel Mode ESP Decapsulation (y/n):
=

        &nb=
sp;      Y: Supported by QuickSec family of produc=
ts.
 =

- Does your implementation support the NAT ke=
epalive procedure? (y/n):
&n=
bsp;       Y: Supported by QuickSec family of=
 products.
 =

The following questions document wheth=
er interoperability has been achieved as well as other
intangibles the IESG will be interested.
 
=
- What evidence do you have that your implementation can=
 interoperate with other implementations?
        INSIDE Secure has =
always participated IPsec interoperability events, as well, our QA for our =
implementation
  &=
nbsp;     has extensive interoperability tests using ot=
her vendor products.
- In yo=
ur opinion, are there unused features in the RFC that greatly increase impl=
ementation complexity?
 =
;       No
 
Additional information (opt=
ional):
 =

 <=
/span>
Best Regards,
 
3D"=
Joonas Pylkk=E4nen
Director R&D, Embedded Security Solutions
INSIDE Secure
JPylkkanen@INSIDESecure.com
<=
p class=3DMsoNormal> 
= --_000_64F7B34BFE23834EA992CE91ABC59C521B5DB34BDFgarlabaninsid_-- --_004_64F7B34BFE23834EA992CE91ABC59C521B5DB34BDFgarlabaninsid_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=3663; creation-date="Fri, 14 Mar 2014 11:47:56 GMT"; modification-date="Fri, 14 Mar 2014 11:47:56 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEASABIAAD//gAMQXBwbGVNYXJrCv/bAIQABwUFBgUFBwYGBggHBwgKEQsK CQkKFA8PDBEYFRkZFxUXFxodJSAaHCMcFxchLCEjJygqKioZHy4xLSkxJSkqKAEHCAgKCQoTCwsT KBsXGygoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgo/8QB ogAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoLAQADAQEBAQEBAQEBAAAAAAAAAQIDBAUGBwgJ CgsQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJ ChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeI iYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq 8fLz9PX29/j5+hEAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMz UvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3 eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna 4uPk5ebn6Onq8vP09fb3+Pn6/8AAEQgANwCgAwEiAAIRAQMRAf/aAAwDAQACEQMRAD8A+kaK5zxN 450PwlNaw6tcvE9zkoEjZ8AcFjjoOa2ru+tbGzkvbq4jhto13vK7AKB65oAs0V59L8avBscjILu5 lCnG9LZsH6ZxTf8Ahd3g7/nvef8AgMadmK6PQ6K43RPin4U168WyttQMVw5xGlxGY959ATxn2zXR azrWn6BYSahqdyltbR9XbnJ7AAck+wpWHc0KK88/4Xb4O/573n/gMaP+F3eDv+e95/4DGnZiuj0O sDxR4nj8NW0MjWzXDzMVRA+0YHUk4P8AKub/AOF3eDv+e95/4DGtfxTr3heLw7a6nrRE2nXWx7fC NvcsuVKgYI+XJ7VjWjUcGqbtLoa0pU1NOorrqbWh6tHremQX8cbRiUHKNyVIOCM9+nWtKsvRLvTL nRra70xkXTni3xMBtUL3znp3zn3rmL74xeDbG4aD7fJcFOC9vCzJn2bofqOKumpKKUtX1Jm48zcd Ed3WN4q8QR+FtAvNZlhadbZQfKU4LMzBQM9hlhzXK/8AC7vB3/Pe8/8AAY1meNvGujeMfhx4hbSZ pH+ym2EqyRlSN0yYPP8Aun8quxFzr/AvjGPxvoranHZtZtHO0EkRffhgAeGwMjDDsO9dPXlnwHkS LwXfySMERdRkLMxwABFFkk1qXHxo8HQTPELy4m2nG+O3YqfoTii2oX0O/orzz/hd3g7/AJ73n/gM aP8Ahd3g7/nvef8AgMaLMLo9DorL0HxDpniawW/0q6W4gJ2k4IZG/usDyDWpSGeD/tBf8hjSP+vZ /wD0Krfx11K4j0zQNNRytvMjTSKD95lChc+w3H86h+PlpcTatorxQSSK8LRqVQnc+77o9/al+O1p csPDbLBIw8qSLIUn5zswv1q10IfU6bwN8K/DkPh6yutSsY9RvLuFJpHlJKruAIVRnHGevWuk/wCF a+D/APoX7P8A75P+Na3h+GS20HTIJkKSxWkSOp6qwQAitKpuyrI+fPjB4C07wsbLVdHQ21vcSGKS AMSEfGQVzyM4PHbAx1q549fVPEnww8M6w3mTrDn7Ww5JONgkb8VPP+1XR/HyGWTwvYyJGzpFfAuw GQoKMAT6c1FaeL5fh78NvDr3OjS3bXKsjRs/lBASzDcdp6gjAx61XQnqcPoHiz4f2WkWttqnhKS5 vY0xNMu1hI397JYfljitL/hNfhf/ANCVN/3wn/xdKfjFoRJY/D3TiT1Jlj5/8g0n/C4NB/6J5p3/ AH9j/wDjNMB8XjT4WtKqv4OmjQnBby0OPfG+tr403Vje+CNDuNNdGspLlTAYxhdnltgAdsdMdq4T xZ41svGNpb6dpfhC106484MJLbDyvwRtAVFPOffoK6Dxl4e1HRPhJoFpdwuJobxpZlAz5IcSEA+n 3hn3pAWda1O40/4F6NHbuU+2zC3kIODsLSsR+OwA+xNXPhP8NtE1Pw/Frmr2y30t2ziKJydkaqxX oOpJB6+1aUPgy68TfB7S9KCGC/iX7TbpL8oLbnwD6ZVj+YrhPCvxB1/4bLLo2o6S8tuHLi3uMwvG x67WwflPXofUUegHtP8AwrXwf/0L9n/3yf8AGue+I/h/SPD/AMN9cj0qwgsllMBfylwXImTGT37/ AK1zv/DQ/wD1K/8A5UP/ALVXM+KfH+vfEoRaPp2kvFAXDG2ty0ryN23NgfKPp7npSSY7o1PCcrxf BHxOyMVJvGXI9CsAI/Ims/wLH4W03wdqGveItIOpFL9baNVGSMoCMZIA7/pXotp4Au9P+Fd34cQq 2pXMTTSAHgy5DBc/RVXNeX+EvHUvgOzv9E1Xw4L5J5hI8Fy3lFGAAwVZGz0HamI2f+E1+F//AEJU 3/fCf/F1T1bxd8OrnTLuCx8HyxXUkTLDIdq7GI4bIYnjr0q5/wALg0H/AKJ5p3/f2P8A+M0v/C4d BHP/AAr3Tv8Av7H/APGaYGz+z/YX0Ntq97IjpZTtEkRbgOy7txH0yBn/AAr2WuY8B+Kh4v0H+0V0 1tNVJmhWEtuUhQDlTgZHOOnUH0rp6h7lLY5LxX4zbw5ewWsdmJ2dBKzM+0AZIwPfg1B4t8ZX+iW2 k3Wnaa9zDfqzSObaebyRtDLlYUY85PbHFdNe6Rp+otG15ZxTtH9wyLnFRar4f0vXEiTUrNLlIcmM MSNuevQ+wrmpwqqpKU5Xi9l2OicqbpxUY2a3fc87/wCFqa3/ANAv/wAo+p//ABivRPDurf25odjq eYz9qiEmY1dV/AOAw/EA1nf8K98Kf9AWD/vpv8a29P0600mygsLC3S2tbdAkUMYwqKOgAroMDmPH fjG78Ky6XDaWYuWvmlDEwTzFAgB4WFGY5z1xgVi6R4/8Q61qEVha6dbxzS7trXOnahDGMAk5d4Qo 6dzyeOpFdvq/h3Sdf8kapYxXfkEmIvnKE8HBHris7/hXvhT/AKAsH/fTf40Ablkbs2sf25YVusfv BAxKZ9iQDWH4l1zVdP1XRtL0m2s5Z9SabL3cjqsYjTdxtBJJzityysrfTbWO0tIlht4hhI16KKp6 z4c0jxB9n/tXT4bw2zFoTIOYyRgkHtkcUAZ+/wAb/wDPDw//AN/5/wD4ityxN2bSM36wLdY/eC3Y mPPsSAelYf8Awr3wp/0BYP8Avpv8a3LGxttNtYrSzhWG3iGEjXoo60AU9Q1Z7LV9J08RB11B5VZy eU2Rl+B3zitSs3WPD2k+IFgXVbGK7Fu5eLzM/IxGCRjpwSKzf+Fe+FP+gLB/303+NAF/w5qz65pE N/JEsTSPKuxTkDbIyf8AstYXj/xpdeEDo8dpZrdPqVy8JzHLIUCxM+QkSs7fdxwOOp4BrqNO06z0 iyisbC3S2tYQRHEgwqgnPH4k0txp9pdXNrdT28ck9m7PbyMMtEzKUJX0yrEfjQB5bdfF3UrK3kub qxjt4Ihukll0rUkRB6kmDAFd74K1298SeGrPVtQsG0+5uDKGt2V1wFkZVbDgMAyqGGR0atqaGK5h kgmjWWKRSjxuMqykYIIPUEU20tYLG1htLaMRQQII40XoqgYAH0FAHKfEDxpdeEDo8dpZLdPqVy8J JjlkKBY2fISJWdvu44HHU8A1i6X8QfEGr38NjbadAksxIVrjTtQhjGATy7whR07mu51jw9pPiBIU 1WxivBbuZIvMHKMRgkHtwSKzf+Fe+FP+gLB/303+NAG1p5vjZx/2itut3z5gtmYx9TjBYA9Mfjmr VVdP0600qzjsrGFYLeLOyNc4GSSevuTVqgCrcadDc3MVxI9yskSOiiO6ljQhhzlFYKx9CQSOxFVo dBtIPs+ybUD9miaJN+pXD5VupfLne3ozZYdiK0jS0AZkOg2kH2fZNqB+zRNEm/Urh8q3Uvlzvb0Z ssOxFEOg2kH2fZNqB+zRNEm/Urh8q3Uvlzvb0ZssOxFadFAGZDoNpB9n2Tagfs0TRJv1K4fKt1L5 c729GbLDsRRDoNpB9n2Tagfs0TRJv1K4fKt1L5c729GbLDsRWnRQBmQ6DaQfZ9k2oH7NE0Sb9SuH yrdS+XO9vRmyw7EUQ6DaQfZ9k2oH7NE0Sb9SuHyrdS+XO9vRmyw7EVp0UAZkOg2kH2fZNqB+zRNE m/Urh8q3Uvlzvb0ZssOxFEOg2kH2fZNqB+zRNEm/Urh8q3Uvlzvb0ZssOxFadFAGZDoNpB9n2Tag fs0TRJv1K4fKt1L5c729GbLDsRRDoNpB9n2Tagfs0TRJv1K4fKt1L5c729GbLDsRWnRQBmQ6DaQf Z9k2oH7NE0Sb9SuHyrdS+XO9vRmyw7EUQ6DaQfZ9k2oH7NE0Sb9SuHyrdS+XO9vRmyw7EVp0UAZk Og2kH2fZNqB+zRNEm/Urh8q3Uvlzvb0ZssOxFEOg2kH2fZNqB+zRNEm/Urh8q3Uvlzvb0ZssOxFa dFAGZDoNpB9n2Tagfs0TRJv1K4fKt1L5c729GbLDsRRDoNpB9n2Tagfs0TRJv1K4fKt1L5c729Gb LDsRWnRQBmQ6DaQfZ9k2oH7NE0Sb9SuHyrdS+XO9vRmyw7EU610S1tHtHjlvmNpG0cfm6hPIGB6l wzkSH0Z8kdiK0aKAP//Z --_004_64F7B34BFE23834EA992CE91ABC59C521B5DB34BDFgarlabaninsid_-- From nobody Sat Mar 15 23:26:17 2014 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 96AA51A02D1 for ; Sat, 15 Mar 2014 23:26:15 -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 K2b2FypsGRVS for ; Sat, 15 Mar 2014 23:26:13 -0700 (PDT) Received: from mail-ee0-x22f.google.com (mail-ee0-x22f.google.com [IPv6:2a00:1450:4013:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3614E1A001D for ; Sat, 15 Mar 2014 23:26:13 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b15so2859479eek.20 for ; Sat, 15 Mar 2014 23:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=sE2VA/hnAXAoseAvtdz1nX7AxqNE9NIb8WR8K2IdYyg=; b=FCeHZ+SH8VpAaH7gjFHUN/uD3spVTrScQ2ehSeqo9C6/Yz8joBy7D4uqXcDGHRC2o8 PwonvR6oAgMcCYj2lZSRpMyQ+k5aCrrpZq4jhl75Cqi/BjUzq/2u4CnQq85gcjR9D6eF LAEfi+owsp6eOYVyK2SRXZbsQW7k55Q+ZKcoRPsArSN+nnGd6h28qAlF0xX2cSXzQ+40 BT/hKWnRwQsiQvbFmFSDm7TmvF476GxC5Gac4+9xCELT5Evj0ShfMl7m5zVJx3VnaG6J WZh/q18xbYU2Xvp3Zn8Tc3Utb7vH8o0DAXgPtUqIT046e4QQ/vGijN/EhU6x7DgXwJlF YrVA== X-Received: by 10.14.148.134 with SMTP id v6mr5025eej.115.1394951165286; Sat, 15 Mar 2014 23:26:05 -0700 (PDT) Received: from [10.4.5.47] ([80.179.9.115]) by mx.google.com with ESMTPSA id cb5sm29805904eeb.18.2014.03.15.23.26.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 15 Mar 2014 23:26:04 -0700 (PDT) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sun, 16 Mar 2014 08:25:51 +0200 To: ipsec Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Imz_vhMKahV31p8SZg_QIOnLVNY Subject: [IPsec] My view of the requirements from AD-VPN 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: Sun, 16 Mar 2014 06:26:15 -0000 As promised, here's my view of what a short list of requirements for = AD-VPN should be like. First, a few terms: An AD-VPN is a subset of the hosts on the Internet, such that all = traffic between two nodes within the AD-VPN must be protected by IPsec = when it traverses nodes outside of the AD-VPN. An IPsec gateway is a = node within the AD-VPN that protects the traffic for passage across = nodes outside of the AD-VPN. An IPsec host is a node that protects only = its own traffic (common for remote access VPNs). The set of hosts whose = traffic is protected by an IPsec gateway is called its "protected = domain". The AD-VPN can be said to be partitioned into protected = domains. All this can be accomplished with IPsec and IKEv2 as defined in RFCs = 4301, 4303, and 5996. What's missing is dynamic updates to SPD and PAD, = and a way to deal with the complexity of the configuration of large = scale VPNs.=20 So any IPsec gateway or host joining an AD-VPN has to know several = things: - the total AD-VPN. Specifically, whether an IP address (could the the = destination of an outgoing packet or the source of an incoming packet) = is or is not in the AD-VPN. Packets that are destined to outside the = AD-VPN can be sent in the clear over the Internet. - For each host in the AD-VPN, a next-hop gateway.=20 - Credentials for connecting to such a next-hop gateway. - If more protected domains, gateways or hosts are added to the AD-VPN, = we want the node to learn of this. This doesn't have to happen = immediately, but we would like to be able to set an upper bound on how = long it takes. =20 For a simple configuration, there can be one such next-hop gateway for = all addresses (that's a hub). Using a single hub for all the VPN is not = efficient, so even if we accept this as an initial configuration, we = need this to expand.=20 Another requirement of this protocol is to limit the impact of rogue or = compromised nodes. Specifically, such nodes should not be able to alter = the AD-VPN by dynamically removing parts of the protected domains of = other gateways, and checks and limits should be imposed on their ability = to claim parts of the Internet as part of their own protected domains. = This requirement may have a negative impact on usability, for example if = additions to the AD-VPN would require matching configuration on both the = protecting gateway and on some other node (could be a part of the = AD-VPN, like a hub node, or an external server, or maybe an RPKI CA), = but we believe it is essential for security in the face of the = possibility of compromised nodes. So to get all this, we need the following from the solution protocol = (and it could be one protocol, or a whole suite of protocols at = different levels: 1. A protocol for discovery of the AD-VPN, and at least one next-hop = gateway with the credentials to access it. The latter part may be = assumed to be manually configured, but the discovery has to be = automatic, as the total AD-VPN is assumed to change. Note that the other = side of this protocol is not required to be part of the AD-VPN. A server = giving out this information over HTTPS is an acceptable solution, as is = encoding this information in the DNS. =20 2. A protocol for propagating changes to the AD-VPN throughout the = network. This does not have to be a single protocol. For example, We = could have hub spokes that communicate this information through routing = protocols, and spoke nodes that get the information from the hub nodes. = Or trusted nodes that update an HTTPS server, while the other nodes = periodically download said information. The requirement is that = eventually, and after a bounded time period, all nodes will know of the = change. =20 3. A protocol for discovery of more efficient paths through the AD-VPN. = Specifically, such a protocol would allow an IPsec gateway (or an IPsec = host) to create a new tunnel such that the traffic would require fewer = hops on its way to the destination host. This protocol would also need = to handle providing credentials to the nodes. It's not enough to tell a = gateway to set up a tunnel with another gateway at address 192.0.2.5, = You also need to tell what credential that gateway is going to present = (by DN or alternate name, and maybe by public key as in DANE) and also = what IDi/IDr are going to be used in IKE.=20 =20 =20 These are the requirements as I see them. The opinions posted here are = my own, they do not reflect those of my employer, and do not necessarily = reflect those of my co-authors on the AD-VPN draft. Yoav From nobody Thu Mar 20 14:24:18 2014 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 DCCD71A076D for ; Thu, 20 Mar 2014 14:24:16 -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 AQbmtouSSFRp for ; Thu, 20 Mar 2014 14:24:15 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id C23731A042C for ; Thu, 20 Mar 2014 14:24:15 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175]) (authenticated bits=0) by hoffman.proper.com (8.14.8/8.14.7) with ESMTP id s2KLO45l086115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 20 Mar 2014 14:24:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-175.dsl.dynamic.sonic.net [50.1.98.175] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Mar 2014 14:24:03 -0700 References: To: ipsec Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/jEkbcV4puJRxQhWYWzQ4nSUYtrQ Subject: [IPsec] Fwd: [89all] London Meeting Survey 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 Mar 2014 21:24:17 -0000 If you were in London but didn't see this, please consider filling in = the survey. There are also questions for people who weren't in London = but participated remotely. The IAOC pays a lot of attention to the = results of these surveys. Begin forwarded message: > From: Ray Pelletier > Subject: [89all] London Meeting Survey > Date: March 20, 2014 at 1:58:49 PM PDT > To: <89all@ietf.org> >=20 > All; >=20 > This is a short and anonymous survey about your IETF meeting = experience generally and specifically your experience at IETF 89 in = London. It will be used to make improvements at future meetings where = needed (and possible). Feedback on the survey itself is welcome. >=20 > https://www.surveymonkey.com/s/XG5S9VC >=20 > Thanks for attending the meeting and your participation in this = survey. >=20 > Ray From nobody Fri Mar 21 10:20:48 2014 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 718FE1A09AE for ; Fri, 21 Mar 2014 10:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 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, 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 zQDt1I2rs-Av for ; Fri, 21 Mar 2014 10:20:36 -0700 (PDT) Received: from mail-ee0-x229.google.com (mail-ee0-x229.google.com [IPv6:2a00:1450:4013:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 402641A075D for ; Fri, 21 Mar 2014 10:20:36 -0700 (PDT) Received: by mail-ee0-f41.google.com with SMTP id t10so2073574eei.0 for ; Fri, 21 Mar 2014 10:20:26 -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:references :in-reply-to:content-type:content-transfer-encoding; bh=TGKgMmma3fgVAgbagAqsILPKdGkcnYfCDrdkL38C3MM=; b=G9VVbUoj0atEtvbQlrbUvDDY6GyFjipVxtwyVGR31SYxhr6S7lJtc2463dl0dfNJAC IZihwyvnLyfKUE8znGPDUxKGlNEyCxjRXR6UwZw7VWShA0cUmsXpm0PbqUV/+bLoRjQT Nc9EkboevWn5zOFe4SzgyJBHcWJ3eN9y3r73temwVdMNT/UuM4QA3RPMDT1b95oYITEu w/Sr4ysd0cGwpeIXnQaRgy4qnFNRWhaXel24BQK2MYWqSYHfqR2WjjpT4GInsISGzREX Ip9Gha8i5nki3tkwQWoZlCJG/Bh5l6+0HS5bGxrntYNfPUC3BDcf0UmIGCW5MFzwGT2/ d2cg== X-Received: by 10.14.95.8 with SMTP id o8mr33174127eef.15.1395422426284; Fri, 21 Mar 2014 10:20:26 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-179-48-141.red.bezeqint.net. [79.179.48.141]) by mx.google.com with ESMTPSA id m42sm12890462eex.21.2014.03.21.10.20.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 10:20:25 -0700 (PDT) Message-ID: <532C74D6.8000208@gmail.com> Date: Fri, 21 Mar 2014 19:20:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Yoav Nir , ipsec References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Hqr1032m28yLxhs9RtfojDeqS9E Subject: Re: [IPsec] My view of the requirements from AD-VPN 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 Mar 2014 17:20:40 -0000 Hi Yoav, I like your attempt at reducing the requirement set to the minimum. Parts of the text I think do not distinguish well between IPsec hosts (such as remote access clients) and (simple) hosts, that are non-IPsec hosts protected behind a gateway. Presumably simple hosts will be unaffected by this protocol. And in the spirit of minimizing the set of requirements: isn't your #3 solution components just an optimization? I think in many cases a protocol that includes #1 and #2 but not #3 could be sufficient for scale. And then #3 could be added as an extension. Or we can decide that we do not need a fully general #3, and we're good enough with simple shortcuts between two spokes of the same hub. Thanks, Yaron On 03/16/2014 08:25 AM, Yoav Nir wrote: > As promised, here's my view of what a short list of requirements for AD-VPN should be like. > > First, a few terms: > An AD-VPN is a subset of the hosts on the Internet, such that all traffic between two nodes within the AD-VPN must be protected by IPsec when it traverses nodes outside of the AD-VPN. An IPsec gateway is a node within the AD-VPN that protects the traffic for passage across nodes outside of the AD-VPN. An IPsec host is a node that protects only its own traffic (common for remote access VPNs). The set of hosts whose traffic is protected by an IPsec gateway is called its "protected domain". The AD-VPN can be said to be partitioned into protected domains. > > All this can be accomplished with IPsec and IKEv2 as defined in RFCs 4301, 4303, and 5996. What's missing is dynamic updates to SPD and PAD, and a way to deal with the complexity of the configuration of large scale VPNs. > > So any IPsec gateway or host joining an AD-VPN has to know several things: > - the total AD-VPN. Specifically, whether an IP address (could the the destination of an outgoing packet or the source of an incoming packet) is or is not in the AD-VPN. Packets that are destined to outside the AD-VPN can be sent in the clear over the Internet. > - For each host in the AD-VPN, a next-hop gateway. > - Credentials for connecting to such a next-hop gateway. > - If more protected domains, gateways or hosts are added to the AD-VPN, we want the node to learn of this. This doesn't have to happen immediately, but we would like to be able to set an upper bound on how long it takes. > > For a simple configuration, there can be one such next-hop gateway for all addresses (that's a hub). Using a single hub for all the VPN is not efficient, so even if we accept this as an initial configuration, we need this to expand. > > Another requirement of this protocol is to limit the impact of rogue or compromised nodes. Specifically, such nodes should not be able to alter the AD-VPN by dynamically removing parts of the protected domains of other gateways, and checks and limits should be imposed on their ability to claim parts of the Internet as part of their own protected domains. This requirement may have a negative impact on usability, for example if additions to the AD-VPN would require matching configuration on both the protecting gateway and on some other node (could be a part of the AD-VPN, like a hub node, or an external server, or maybe an RPKI CA), but we believe it is essential for security in the face of the possibility of compromised nodes. > > So to get all this, we need the following from the solution protocol (and it could be one protocol, or a whole suite of protocols at different levels: > > 1. A protocol for discovery of the AD-VPN, and at least one next-hop gateway with the credentials to access it. The latter part may be assumed to be manually configured, but the discovery has to be automatic, as the total AD-VPN is assumed to change. Note that the other side of this protocol is not required to be part of the AD-VPN. A server giving out this information over HTTPS is an acceptable solution, as is encoding this information in the DNS. > > 2. A protocol for propagating changes to the AD-VPN throughout the network. This does not have to be a single protocol. For example, We could have hub spokes that communicate this information through routing protocols, and spoke nodes that get the information from the hub nodes. Or trusted nodes that update an HTTPS server, while the other nodes periodically download said information. The requirement is that eventually, and after a bounded time period, all nodes will know of the change. > > 3. A protocol for discovery of more efficient paths through the AD-VPN. Specifically, such a protocol would allow an IPsec gateway (or an IPsec host) to create a new tunnel such that the traffic would require fewer hops on its way to the destination host. This protocol would also need to handle providing credentials to the nodes. It's not enough to tell a gateway to set up a tunnel with another gateway at address 192.0.2.5, You also need to tell what credential that gateway is going to present (by DN or alternate name, and maybe by public key as in DANE) and also what IDi/IDr are going to be used in IKE. > > > These are the requirements as I see them. The opinions posted here are my own, they do not reflect those of my employer, and do not necessarily reflect those of my co-authors on the AD-VPN draft. > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Fri Mar 21 16:25:33 2014 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 EC0FD1A06DF for ; Fri, 21 Mar 2014 16:25:31 -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 KzIQMTicHJY8 for ; Fri, 21 Mar 2014 16:25:30 -0700 (PDT) Received: from mail-ee0-x230.google.com (mail-ee0-x230.google.com [IPv6:2a00:1450:4013:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id D0F931A0444 for ; Fri, 21 Mar 2014 16:25:29 -0700 (PDT) Received: by mail-ee0-f48.google.com with SMTP id b57so2315750eek.35 for ; Fri, 21 Mar 2014 16:25:19 -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=TLNUZh7Z/Y01oRM0VGexTNCCJytjlufRxLjtbR4Y3ew=; b=pfcRrW7I19XbVv/FTxBJynDnAdiHgHtQy/UrS9AwgQsR9/cz2RJM1vXu5WDwOEQepC WoWjHUP8lntzB2sXlqnqorK4znCe+jjWfkyYDELJY0Zdr8c4JzNe1IIR7FNjA4dhP+58 hrShuK4cnLoAPVQr5jCYitMstmps1A8YxAbEZqKkdluyA20SQjlk+kLcPn1O9CfOzW5m 4em2rT54o0OWp5GqX55UYU0DA3GbV0ut8EkIxxDOam5KhbDJuExVhJ80mhnQ6fiCW1Z8 +7GxTlhvA7VzhNhSlx/6POm7ri1SdmAmY5FqPD3myyAbvJx41rWY+rdGUCcunFixPqvM j4JQ== X-Received: by 10.14.126.73 with SMTP id a49mr50692093eei.46.1395444319841; Fri, 21 Mar 2014 16:25:19 -0700 (PDT) Received: from [192.168.1.100] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id x45sm14846521eeu.23.2014.03.21.16.25.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 16:25:18 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <532C74D6.8000208@gmail.com> Date: Sat, 22 Mar 2014 01:25:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2CD37189-69B4-4BE8-ACD4-D6CC8E6C4146@gmail.com> References: <532C74D6.8000208@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/iHrQmuXir-9MIcFN6LSGZL6LByU Cc: ipsec Subject: Re: [IPsec] My view of the requirements from AD-VPN 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 Mar 2014 23:25:32 -0000 On Mar 21, 2014, at 7:20 PM, Yaron Sheffer = wrote: > Hi Yoav, >=20 > I like your attempt at reducing the requirement set to the minimum. >=20 > Parts of the text I think do not distinguish well between IPsec hosts = (such as remote access clients) and (simple) hosts, that are non-IPsec = hosts protected behind a gateway. Presumably simple hosts will be = unaffected by this protocol. >=20 > And in the spirit of minimizing the set of requirements: isn't your #3 = solution components just an optimization? I think in many cases a = protocol that includes #1 and #2 but not #3 could be sufficient for = scale. And then #3 could be added as an extension. Or we can decide that = we do not need a fully general #3, and we're good enough with simple = shortcuts between two spokes of the same hub. >=20 Without #3 we are left with the easy configuration - a few hubs meshed = together, and all other nodes know about 1 hub each. This has some = issues: - The hubs have very large peak loads. - A failure of a hub is catastrophic - the VPN goes away. - Increased latency because traffic goes through multiple hops. Both of these points together make the hubs insanely expensive. They = need to have hardware (both in the gateways themselves and in the = network links) that will carry the peak load without introducing even = more latency, and they need to have enough redundancy to practically = never go down. Both of these are solved problems, but they=92re problems = you need to throw a lot of money at to solve.=20 So without #3, I am not sure the effort is worthwhile. As for a = lightweight #3, that only shortcuts the spokes of a single hub, it=92s = better than nothing, but I can use the example of my company (medium = sized by any measure) that still manages to have two hubs. I=92d rather = that VoIP calls between two remote access clients connected to the = different hubs (think me and Bob) not have to go through both hubs. Yoav= From nobody Mon Mar 24 09:47:15 2014 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 ECE7B1A0269 for ; Mon, 24 Mar 2014 09:47:12 -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 LFlr-lxCaHDr for ; Mon, 24 Mar 2014 09:47:10 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB421A0276 for ; Mon, 24 Mar 2014 09:47:09 -0700 (PDT) Received: from mail54-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE012.bigfish.com (10.9.40.32) with Microsoft SMTP Server id 14.1.225.22; Mon, 24 Mar 2014 16:47:09 +0000 Received: from mail54-tx2 (localhost [127.0.0.1]) by mail54-tx2-R.bigfish.com (Postfix) with ESMTP id E883B460365; Mon, 24 Mar 2014 16:47:07 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzbb2dI98dI9371Ida00hdc73hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h268bh1155h) Received-SPF: pass (mail54-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=praveenys@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(479174003)(377454003)(24454002)(92566001)(49866001)(47736001)(47976001)(50986001)(31966008)(90146001)(98676001)(81686001)(92726001)(4396001)(56816005)(85852003)(81816001)(47446002)(74502001)(83072002)(20776003)(66066001)(59766001)(65816001)(77982001)(19580405001)(19580395003)(80976001)(83322001)(63696002)(79102001)(95666003)(80022001)(95416001)(76796001)(74876001)(54316002)(87936001)(83506001)(56776001)(36756003)(74366001)(46102001)(2656002)(53806001)(93136001)(97336001)(69226001)(97186001)(81342001)(93516002)(51856001)(76482001)(94946001)(86362001)(54356001)(85306002)(81542001)(87266001)(74706001)(94316002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB668; H:CO2PR05MB665.namprd05.prod.outlook.com; FPR:7B77A569.3F604435.BD38DC8.DBA32F7D.20087; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail54-tx2 (localhost.localdomain [127.0.0.1]) by mail54-tx2 (MessageSwitch) id 1395679610795651_22928; Mon, 24 Mar 2014 16:46:50 +0000 (UTC) Received: from TX2EHSMHS001.bigfish.com (unknown [10.9.14.235]) by mail54-tx2.bigfish.com (Postfix) with ESMTP id AADFE480055; Mon, 24 Mar 2014 16:46:50 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS001.bigfish.com (10.9.99.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Mar 2014 16:31:07 +0000 Received: from CO2PR05MB668.namprd05.prod.outlook.com (10.141.230.25) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 24 Mar 2014 16:30:53 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com (10.141.230.11) by CO2PR05MB668.namprd05.prod.outlook.com (10.141.230.25) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 24 Mar 2014 16:30:52 +0000 Received: from CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) by CO2PR05MB665.namprd05.prod.outlook.com ([10.141.230.11]) with mapi id 15.00.0898.005; Mon, 24 Mar 2014 16:30:52 +0000 From: Praveen Sathyanarayan To: Yoav Nir , Yaron Sheffer Thread-Topic: [IPsec] My view of the requirements from AD-VPN Thread-Index: AQHPQOC1IObdycUSXU22LWq4zTUKsJrr0ewAgABl6gCAA83lAA== Date: Mon, 24 Mar 2014 16:30:52 +0000 Message-ID: References: <532C74D6.8000208@gmail.com> <2CD37189-69B4-4BE8-ACD4-D6CC8E6C4146@gmail.com> In-Reply-To: <2CD37189-69B4-4BE8-ACD4-D6CC8E6C4146@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.239.10] x-forefront-prvs: 01604FB62B Content-Type: text/plain; charset="Windows-1252" Content-ID: <4CF5B901903DC84288FF15EE74AD6416@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/5KtpYckOaid-T_FLMB3SE7OeILw Cc: ipsec Subject: Re: [IPsec] My view of the requirements from AD-VPN 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 Mar 2014 16:47:13 -0000 On 3/21/14, 4:25 PM, "Yoav Nir" wrote: > So without #3, I am not sure the effort is worthwhile. +1 for this. We started this effort to solve #3. To me, #1 and #2 are important requirements as well. But #3 is a must. =8B Praveen From nobody Fri Mar 28 06:37:36 2014 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 D80051A0651; Fri, 28 Mar 2014 06:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZUMbvhskw3C8; Fri, 28 Mar 2014 06:37:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3889C1A0648; Fri, 28 Mar 2014 06:37:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140328133729.16552.30120.idtracker@ietfa.amsl.com> Date: Fri, 28 Mar 2014 06:37:29 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/T-xVxvxNMJOMS45V-IHXbiMQpik Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-kivinen-ipsecme-signature-auth-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 13:37:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Signature Authentication in IKEv2 Author : Tero Kivinen Filename : draft-kivinen-ipsecme-signature-auth-05.txt Pages : 17 Date : 2014-03-28 Abstract: The Internet Key Exchange Version 2 (IKEv2) protocol has limited support for the Elliptic Curve Digital Signature Algorithm (ECDSA). The current version only includes support for three Elliptic Curve groups, and there is fixed hash algorithm tied to each curve. This document generalizes the IKEv2 signature support so it can support any signature method supported by the PKIX and also adds signature hash algorithm negotiation. This is generic mechanism, and is not limited to ECDSA, but can also be used with other signature algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-kivinen-ipsecme-signature-auth-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-kivinen-ipsecme-signature-auth-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 31 00:13:00 2014 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 E76991A096E for ; Mon, 31 Mar 2014 00:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 WWB04i0vLDGh for ; Mon, 31 Mar 2014 00:12:55 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B46C11A0966 for ; Mon, 31 Mar 2014 00:12:54 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so2728836wiv.7 for ; Mon, 31 Mar 2014 00:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=d74jOLGcSmCyC6x5olaruo6yIpoNzrBg/BN2hf12X34=; b=OcSkV95kOgOE6gDJTr/VNqPWkUO4mhiqLuVKoX/GOmPAdZdW3/39ImdfsS0X82zheO OqQ6kJX5uoFBYts0JhrJcWQxPVi0/3uxHifJMzYNHR8hgn5Gr1ZZ9BA7OdV/a7NkktNO wLgKLyJCx4HxYBdWj6EeIzSzYMkgrKGA4A98Nj/Ol49wHkznhAernspGSzGVH319Sxgc woXeiqoz0aIMlj54QH0TXHwoVINFWyyqpknZH47jKUydHVgeIf/EUrfmJorCkDaQQR15 USlptomd/l6qqJxbuBBvwSTmqkCYs9DMrWmrMi0xb+YgrKJyqljV2pHOgPts35WwPO82 1INw== X-Received: by 10.194.190.42 with SMTP id gn10mr12214952wjc.9.1396249971164; Mon, 31 Mar 2014 00:12:51 -0700 (PDT) Received: from [172.24.251.171] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id s46sm31014509ees.3.2014.03.31.00.12.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 00:12:50 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_0F69D92B-77EB-4A83-9318-CD124D787A10" Date: Mon, 31 Mar 2014 10:12:45 +0300 References: <20140331064443.17420.20177.idtracker@ietfa.amsl.com> To: ipsec Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aRCCbmy_FehVnIkVwk13-LhNn2M Subject: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-chacha20-poly1305-02.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, 31 Mar 2014 07:12:57 -0000 --Apple-Mail=_0F69D92B-77EB-4A83-9318-CD124D787A10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi. I=92ve posted a new version of the ChaCha20-Poly1305 draft. I have = removed the stand-alone version of both algorithms, leaving only the = combined mode. Reasoning: - The authenticator is not really needed, as we have HMAC-SHA1, = HMAC-SHA2-*, AES-XCBC, GHASH. So we=92re not short on choices for an = algorithm to complement AES-CBC. - Stand-alone ChaCha is fast, but would require an authenticator = anyway, and the mailing list did not show enthusiasm for ChaCha20 + = HMAC-SHA1 - The working group (everyone who commented except Yaron) wanted to = only have the AEAD. - This makes the document only 7 pages long, with only three pages = containing the actual protocol. Comments are, of course, welcome, and I=92d like to repeat my questions = from the London meeting: - Should this be a WG item. - Should we apply for early identifier assignment - Should this be extended for IKE (current draft covers only ESP) Yoav Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nir-ipsecme-chacha20-poly1305-02.txt > Date: March 31, 2014 at 9:44:43 AM GMT+3 > To: Yoav Nir , "Yoav Nir" >=20 >=20 > A new version of I-D, draft-nir-ipsecme-chacha20-poly1305-02.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. >=20 > Name: draft-nir-ipsecme-chacha20-poly1305 > Revision: 02 > Title: ChaCha20 and Poly1305 and their use in IPsec > Document date: 2014-03-31 > Group: Individual Submission > Pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-nir-ipsecme-chacha20-poly1305-02= .txt > Status: = https://datatracker.ietf.org/doc/draft-nir-ipsecme-chacha20-poly1305/ > Htmlized: = http://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-nir-ipsecme-chacha20-poly1305-02 >=20 > Abstract: > This document describes the use of the ChaCha20 stream cipher along > with the Poly1305 authenticator, combined into an AEAD algorithm for > IPsec. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_0F69D92B-77EB-4A83-9318-CD124D787A10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi.

I=92ve posted a new version = of the ChaCha20-Poly1305 draft.  I have removed the stand-alone = version of both algorithms, leaving only the combined mode. =  Reasoning:
 - The authenticator is not really = needed, as we have HMAC-SHA1, HMAC-SHA2-*, AES-XCBC, GHASH. So we=92re = not short on choices for an algorithm to complement = AES-CBC.
 - Stand-alone ChaCha is fast, but would require = an authenticator anyway, and the mailing list did not show enthusiasm = for ChaCha20 + HMAC-SHA1
 - The working group (everyone = who commented except Yaron) wanted to only have the = AEAD.
 - This makes the document only 7 pages long, with = only three pages containing the actual = protocol.

Comments are, of course, welcome, and = I=92d like to repeat my questions from the London = meeting:
 - Should this be a WG item.
 - = Should we apply for early identifier assignment
 - Should = this be extended for IKE (current draft covers only = ESP)

Yoav

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = New Version = Notification for = draft-nir-ipsecme-chacha20-poly1305-02.txt
Date: March 31, 2014 at 9:44:43 AM = GMT+3
To: = Yoav Nir <ynir.ietf@gmail.com>, "Yoav = Nir" <ynir.ietf@gmail.com>
=


A new version of I-D, = draft-nir-ipsecme-chacha20-poly1305-02.txt
has been successfully = submitted by Yoav Nir and posted to the
IETF = repository.

Name: = draft-nir-ipsecme-chacha20-poly1305
Revision: = 02
Title: ChaCha20 and Poly1305 and their = use in IPsec
Document date: 2014-03-31
Group: = Individual Submission
Pages: 7
URL: =            http://www.ietf.org/internet-drafts/draft-nir-ipsecme-chacha= 20-poly1305-02.txt
Status: =         https://datatracker.ietf.org/doc/draft-nir-ipsecme-chacha20-poly1305/=
Htmlized:       http://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-02
= Diff:           http://www.ietf.org/rfcdiff?url2=3Ddraft-nir-ipsecme-chacha20-pol= y1305-02

Abstract:
  This document describes = the use of the ChaCha20 stream cipher along
  with the = Poly1305 authenticator, combined into an AEAD algorithm for
=   IPsec.




Please note that it may take a = couple of minutes from the time of submission
until the htmlized = version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_0F69D92B-77EB-4A83-9318-CD124D787A10-- From nobody Mon Mar 31 01:17:09 2014 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 741881A0980 for ; Mon, 31 Mar 2014 01:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, 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 AMh_wtkTz9AB for ; Mon, 31 Mar 2014 01:17:06 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id BEEB91A097E for ; Mon, 31 Mar 2014 01:17:05 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id k14so5579246wgh.35 for ; Mon, 31 Mar 2014 01:17:02 -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:references :in-reply-to:content-type:content-transfer-encoding; bh=xCu+I3lwmdMlSqROAhehgFj1I+8trKAYfiNa7DsY0dU=; b=lKv9kyrVFM2z/w0YKyhBIXDIUMwjrYgNjPil8GeX/+Ut08TbyK1mujO5ATKgk7+oCj VdAMBWqoGCKT+ze9azM37HEJjIa/oQ668bs5BCVVQ+4u8FZytm7mv0ARrzV1Bm2cm+y1 o0Hee7xj4x9Tw9QYx+ABKNr9JjLPKXu6cFCjVY+587YOlq3jN2AdMLf8hLov+qQvdjTr CcllvnsmShEtOn8TuR6bMD+6j5sSXGcAXOeNfK1VQEm5q7yjwdU4GcPnNE5+ad2ctHv7 RxkkBM1LGxbcRl8kWdqX0jO8KsJGK/NHaT8pT6E/K90P6ZXu+xDNJvqNPxwNXq1l5xsI WS9w== X-Received: by 10.180.101.230 with SMTP id fj6mr10377866wib.27.1396253822070; Mon, 31 Mar 2014 01:17:02 -0700 (PDT) Received: from [10.2.0.25] (93-172-51-64.bb.netvision.net.il. [93.172.51.64]) by mx.google.com with ESMTPSA id u46sm31365119eel.1.2014.03.31.01.17.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 01:17:01 -0700 (PDT) Message-ID: <5339247C.2030609@gmail.com> Date: Mon, 31 Mar 2014 11:17:00 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Yoav Nir , ipsec References: <20140331064443.17420.20177.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/LWX7ex5Jrvpw6Vhzcf0JPB0jRLM Subject: Re: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-chacha20-poly1305-02.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, 31 Mar 2014 08:17:07 -0000 Thank you Yoav. My personal responses below. Also, I would like a comment from someone in the know: ChaCha (or at least its cousin Salsa) has had extensive cryptographic review, including an open competition. I am not sure the same is true for Poly1305, can someone enlighten me? Best, Yaron On 03/31/2014 10:12 AM, Yoav Nir wrote: > Hi. > > I’ve posted a new version of the ChaCha20-Poly1305 draft. [...] > > Comments are, of course, welcome, and I’d like to repeat my questions > from the London meeting: > - Should this be a WG item. Yes, it's time we had good alternative crypto. > - Should we apply for early identifier assignment No, I don't see such a rush to implement. But feel free to prove me wrong. > - Should this be extended for IKE (current draft covers only ESP) Yes, we need alternative crypto for IKE just as we do for ESP. > > Yoav > > Begin forwarded message: > >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-nir-ipsecme-chacha20-poly1305-02.txt* >> *Date: *March 31, 2014 at 9:44:43 AM GMT+3 >> *To: *Yoav Nir >, >> "Yoav Nir" > >> >> >> A new version of I-D, draft-nir-ipsecme-chacha20-poly1305-02.txt >> has been successfully submitted by Yoav Nir and posted to the >> IETF repository. >> >> Name:draft-nir-ipsecme-chacha20-poly1305 >> Revision:02 >> Title:ChaCha20 and Poly1305 and their use in IPsec >> Document date:2014-03-31 >> Group:Individual Submission >> Pages:7 >> URL: >> http://www.ietf.org/internet-drafts/draft-nir-ipsecme-chacha20-poly1305-02.txt >> Status: >> https://datatracker.ietf.org/doc/draft-nir-ipsecme-chacha20-poly1305/ >> Htmlized: >> http://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-02 >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-nir-ipsecme-chacha20-poly1305-02 >> >> Abstract: >> This document describes the use of the ChaCha20 stream cipher along >> with the Poly1305 authenticator, combined into an AEAD algorithm for >> IPsec. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Mar 31 06:10:53 2014 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 002FF1A0863 for ; Mon, 31 Mar 2014 06:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.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, HTML_MESSAGE=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 F6P5Hc7Sqnbe for ; Mon, 31 Mar 2014 06:10:45 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD181A0961 for ; Mon, 31 Mar 2014 06:10:44 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id bs8so3271182wib.5 for ; Mon, 31 Mar 2014 06:10:40 -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 :message-id:references:to; bh=fN36PUo5tWmIccxCrCL012AkTm8GW96W+OHoQ20NDMg=; b=PgZD14uJ/UlsrNv55JJMoOAsbPOtiibpVvyo3fQysMAL71B1rIIuAFbVdNbFztl5pE z58r5YK46XaSEIwg1gwk65diB3Hgla2cfBi7I3m+LUHH2UZVaDo5U6bKIxtryI++5WUa zlVLO103ftKNxo5cRVYQ68Cxb0wIUMMSCT2eTR88aHdc9WxSkCnJ47DsyILgNR/fDo1P vsXkd1Tr9wWdxBAtyK8lZsNxyL5mYLJP3WVMGnjpyfzTcZoVR6fddXDHfotkT5ciwq62 lQIJSk1JXfr094mU7TliigIVtIOWNz8yqG1i0mCtGtd5ZAMo6CmTesdUZaodAuFRfX32 P2Qw== X-Received: by 10.194.92.228 with SMTP id cp4mr3633288wjb.81.1396271440448; Mon, 31 Mar 2014 06:10:40 -0700 (PDT) Received: from [172.24.251.171] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id h47sm32985732eey.13.2014.03.31.06.10.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 31 Mar 2014 06:10:39 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F2763E66-9877-4FAA-A93F-A9C06515CE0E" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Yoav Nir In-Reply-To: <5339247C.2030609@gmail.com> Date: Mon, 31 Mar 2014 16:10:36 +0300 Message-Id: <8937C931-1578-43F8-8ABE-B0AFAB98434F@gmail.com> References: <20140331064443.17420.20177.idtracker@ietfa.amsl.com> <5339247C.2030609@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IavRT_jdPVgpcZHPVrdbqOnaUNA Cc: ipsec Subject: Re: [IPsec] New Version Notification for draft-nir-ipsecme-chacha20-poly1305-02.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, 31 Mar 2014 13:10:48 -0000 --Apple-Mail=_F2763E66-9877-4FAA-A93F-A9C06515CE0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Regarding review of Poly1305. There=92s DJB=92s paper: = http://link.springer.com/chapter/10.1007/11502760_3#page-1 Wang, Lin, and Wu, A Variant of Poly1305 MAC and Its Security Proof: = http://link.springer.com/chapter/10.1007/11596981_55#page-2 (and a few = more from the same authors) Procter & Cid, On Weak Keys and Forgery Attacks against Polynomial-based = MAC Schemes, http://eprint.iacr.org/2013/144.pdf Handschuh & Preneel, Key Recovery Attacks on Universal Hash Functions = Based MAC Algorithms,=20 Do a whole bunch of articles that say =93Poly1305 [some-number] is a = secure MAC algorithm. Now we=92ll talk about something completely = different=94 count? So while there are few papers addressing Poly1306 itself, there are = plenty addressing MACs based on universal hashes, and giving Poly1305 as = an example. Yoav On Mar 31, 2014, at 11:17 AM, Yaron Sheffer = wrote: > Thank you Yoav. My personal responses below. >=20 > Also, I would like a comment from someone in the know: ChaCha (or at = least its cousin Salsa) has had extensive cryptographic review, = including an open competition. I am not sure the same is true for = Poly1305, can someone enlighten me? >=20 > Best, > Yaron >=20 > On 03/31/2014 10:12 AM, Yoav Nir wrote: >> Hi. >>=20 >> I=92ve posted a new version of the ChaCha20-Poly1305 draft. >=20 > [...] >=20 >>=20 >> Comments are, of course, welcome, and I=92d like to repeat my = questions >> from the London meeting: >> - Should this be a WG item. > Yes, it's time we had good alternative crypto. >> - Should we apply for early identifier assignment > No, I don't see such a rush to implement. But feel free to prove me = wrong. >> - Should this be extended for IKE (current draft covers only ESP) > Yes, we need alternative crypto for IKE just as we do for ESP. >>=20 >> Yoav >>=20 >> Begin forwarded message: >>=20 >>> *From: *internet-drafts@ietf.org >>> *Subject: **New Version Notification for >>> draft-nir-ipsecme-chacha20-poly1305-02.txt* >>> *Date: *March 31, 2014 at 9:44:43 AM GMT+3 >>> *To: *Yoav Nir >, >>> "Yoav Nir" > >>>=20 >>>=20 >>> A new version of I-D, draft-nir-ipsecme-chacha20-poly1305-02.txt >>> has been successfully submitted by Yoav Nir and posted to the >>> IETF repository. >>>=20 >>> Name:draft-nir-ipsecme-chacha20-poly1305 >>> Revision:02 >>> Title:ChaCha20 and Poly1305 and their use in IPsec >>> Document date:2014-03-31 >>> Group:Individual Submission >>> Pages:7 >>> URL: >>> = http://www.ietf.org/internet-drafts/draft-nir-ipsecme-chacha20-poly1305-02= .txt >>> Status: >>> = https://datatracker.ietf.org/doc/draft-nir-ipsecme-chacha20-poly1305/ >>> Htmlized: >>> http://tools.ietf.org/html/draft-nir-ipsecme-chacha20-poly1305-02 >>> Diff: >>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-nir-ipsecme-chacha20-poly1305-02 >>>=20 >>> Abstract: >>> This document describes the use of the ChaCha20 stream cipher along >>> with the Poly1305 authenticator, combined into an AEAD algorithm = for >>> IPsec. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org >>> . >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail=_F2763E66-9877-4FAA-A93F-A9C06515CE0E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Regarding review of Poly1305.

Do a whole bunch of = articles that say =93Poly1305 [some-number] is a secure MAC algorithm. = Now we=92ll talk about something completely different=94 = count?

So while there are few papers addressing = Poly1306 itself, there are plenty addressing MACs based on universal = hashes, and giving Poly1305 as an = example.

Yoav


=
On Mar 31, 2014, at 11:17 AM, Yaron Sheffer <yaronf.ietf@gmail.com> = wrote:

Thank you Yoav. My personal = responses below.

Also, I would like a comment from someone in the = know: ChaCha (or at least its cousin Salsa) has had extensive = cryptographic review, including an open competition. I am not sure the = same is true for Poly1305, can someone enlighten = me?

Best,
Yaron

On 03/31/2014 10:12 AM, Yoav Nir = wrote:
Hi.

I=92ve posted a new = version of the ChaCha20-Poly1305 = draft.

[...]


Comments are, of course, welcome, and I=92d like to = repeat my questions
from the London meeting:
 - Should this = be a WG item.
Yes, it's time we had good alternative = crypto.
 - Should we apply for early = identifier assignment
No, I don't see such a rush to = implement. But feel free to prove me wrong.
 - Should this be extended for IKE (current draft = covers only ESP)
Yes, we need alternative crypto for IKE = just as we do for ESP.

Yoav

Begin = forwarded message:

*From: *internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
*Subject: **New Version Notification = for
draft-nir-ipsecme-chacha20-poly1305-02.txt*
*Date: *March 31, = 2014 at 9:44:43 AM GMT+3
*To: *Yoav Nir <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>>= ,
"Yoav Nir" <ynir.ietf@gmail.com <mailto:ynir.ietf@gmail.com>>=


A new version of I-D, = draft-nir-ipsecme-chacha20-poly1305-02.txt
has been successfully = submitted by Yoav Nir and posted to the
IETF = repository.

Name:draft-nir-ipsecme-chacha20-poly1305
Revision:02=
Title:ChaCha20 and Poly1305 and their use in IPsec
Document = date:2014-03-31
Group:Individual Submission
Pages:7
URL:
http://www.ietf.org/internet-drafts/draft-nir-ipsecme-chacha= 20-poly1305-02.txt
Status:
https://datatracker.ietf.org/doc/draf= t-nir-ipsecme-chacha20-poly1305/
Htmlized:
http://tools.ietf.org/htm= l/draft-nir-ipsecme-chacha20-poly1305-02
Diff:
http://www.ietf.org/r= fcdiff?url2=3Ddraft-nir-ipsecme-chacha20-poly1305-02

Abstract:
&= nbsp;This document describes the use of the ChaCha20 stream cipher = along
 with the Poly1305 authenticator, combined into an AEAD = algorithm for
 IPsec.




Please note that it may = take a couple of minutes from the time of
submission
until the = htmlized version and diff are available at tools.ietf.org
<http://tools.ietf.org>.

The = IETF = Secretariat




______________________________= _________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/= mailman/listinfo/ipsec

= = --Apple-Mail=_F2763E66-9877-4FAA-A93F-A9C06515CE0E-- From nobody Mon Mar 31 15:41:23 2014 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 3BBF91A6FA9; Mon, 31 Mar 2014 15:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hwnYbzhJKf4S; Mon, 31 Mar 2014 15:41:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0BA1A6F68; Mon, 31 Mar 2014 15:41:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140331224116.32271.49481.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 15:41:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/HoZYWhu_Sb_L_4RVqO_T1k8fo9w Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-esp-ah-reqts-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 22:41:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : David McGrew Wajdi Feghali Paul Hoffman Filename : draft-ietf-ipsecme-esp-ah-reqts-03.txt Pages : 11 Date : 2014-03-31 Abstract: This Internet Draft is standards track proposal to update to the Cryptographic Algorithm Implementation Requirements for ESP and AH; it also adds usage guidance to help in the selection of these algorithms. The Encapsulating Security Payload (ESP) and Authentication Header (AH) protocols makes use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-esp-ah-reqts/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-esp-ah-reqts-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/