From nobody Sat Dec 1 01:34:22 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9182612D4E8; Sat, 1 Dec 2018 01:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Kmw3Gzj4PRjp; Sat, 1 Dec 2018 01:34:14 -0800 (PST) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id EAF18129C6B; Sat, 1 Dec 2018 01:34:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 850FE20292; Sat, 1 Dec 2018 10:34:07 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VsHxadkwlq9q; Sat, 1 Dec 2018 10:34:07 +0100 (CET) Received: from [192.168.1.39] (73.red-2-138-17.dynamicip.rima-tde.net [2.138.17.73]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon44.um.es (Postfix) with ESMTPSA id 55D521FE4E; Sat, 1 Dec 2018 10:34:06 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_F82529B5-233B-4502-A774-9BB53D71F8EB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin-Lopez In-Reply-To: Date: Sat, 1 Dec 2018 10:34:06 +0100 Cc: Rafa Marin-Lopez , Yoav Nir , i2nsf@ietf.org, "ipsec@ietf.org WG" Message-Id: <67D2C7A7-2BDC-46CB-B9BC-B5DD16015D2B@um.es> References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 5) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2018 09:34:20 -0000 --Apple-Mail=_F82529B5-233B-4502-A774-9BB53D71F8EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul,all: Here you can find our answers for section 5. > Section 5.1: >=20 > The diagram lists: >=20 > | IKE | IPsec(SPD,PAD) | >=20 > Shouldn't that be: >=20 > | IKE(PAD) | IPsec(SPD, SAD) >=20 > IKE is using the PAD information to tell IPsec to establish SPDs and = SADs) ? [Authors] The PAD is something defined in RFC 4301, which is independent = of the key management protocol. =46rom RFC 4301: "The entry specifies the authentication protocol (e.g., IKEv1, IKEv2, KINK) method" =20 Therefore it is not something attached to the key management protocol = itself but more related with IPsec implemenation. What it is true that = PAD is not implemented in current Linux kernel and usually this = information is set in the IKE implementation. Finally we have only = described in Fig. 1 that SPD and PAD must be configured from the = Controller. The SAD will be managed by the IKEv2 implementation. Same = happens in Fig. 2. >=20 >=20 > Section 5.1.1: >=20 > What does this mean: >=20 > Moreover, an east-west interface is required to exchange = IPsec-related information. [Authors] In SDN terminology an east-west interface is the communication = interface between two controllers. For example: https://tools.ietf.org/html/rfc7426 = If we have two gateways where we need to establish an IPsec SA and both = are under the control of two different controllers then both Security = Controllers needs to exchange information so that they need to agree in = some information so that the configure their own gateways properly (see = Fig. 5). An example: they have to agree that IKEv2 authentication will = be based on raw public keys or pre-shared keys. And if it pre-shared = keys they will have to agree in the PSK (Yes, one option to explore is = IKEv2, more related comments in posterior answers.) >=20 > Section 5.2: >=20 > In this case, the NSF does not deploy IKEv2 and, therefore, the > Security Controller has to perform the management of IPsec SAs by > populating and monitoring the SPD and the SAD. >=20 > I would write: >=20 > In this case, the NSF does not deploy IKEv2 and, therefore, the > Security Controller has to perform the IKE security functions and = management > of IPsec SAs by populating and managing the SPD and the SAD. >=20 > I added "IKE security functions" to make sure some entity is = responsible > for those items that are normally done by IKE (IV generation, prevent = counter > resets for same key, etc). >=20 > I changed monitoring to managing, because I don't understand how it = would "monitor" > the NSF or what it would monitor. I assume also if during monitoring = it finds > something that needs changing (eg vpn tunnel up or down) that it will = do so, > so I think managing is the better word. [Authors] Agreed with this text. Very reasonable. >=20 > For this diagram, I would say IPsec(SPD, SAD) would need to also list = the IKE > security function it needs to use in an IKE-less scenario, which above = I had > called "management of IPsec SAs=E2=80=9D [Authors]=20 How about this non-exhaustive list: - IV generation - prevent counter resets for same key - Generation of pseudo-random cryptographic keys for the IPsec SAs - Rekey of the IPsec SAs based on notification from the NSF (i.e. = expire) - Generation of the IPsec SAs when required based on notifications (i.e. = sadb_acquire) - NAT Traversal discovery and management.=20 - .... What about the following (non-exhaustive) tasks? - SPI random generation - Cryptographic algorithm/s selection - Usage of extended sequence numbers - Establishment of proper traffic selectors=20 - .... >=20 > Section 5.3: >=20 > As mentioned before, a better title would be: IKE vs IKEless >=20 > I would also start this section with: >=20 > Case 1 is more secure, because all security features of IKE are used = to manage > the IPsec SAs. [Authors] We do understand the comment. How about this new text: =E2=80=9CIKE case provides better security properties than IKE-less = case. In particular, the Security Controller is not able to observe what = are the cryptographic keys used to protect data traffic." >=20 > Section 5.3.1: >=20 > For case 1, the rekeying process is carried out by IKEv2, following > the configuration defined in the SPD. >=20 > Technically this is the SPD and SAD, as the SPD would for example list = the > maximum number of packets allowed, but the SAD lists the number of = packets > that have happened. [Authors] Ok. We will replace the text:=20 s/"For case 1, the rekeying process is carried out by IKEv2, following = the configuration defined in the SPD."/"For IKEv2 case, the rekeying = process is carried out by IKEv2, following the configuration defined in = the SPD and SAD." >=20 > I am a bit confused by the rekey description. I guess it assumes that = the > Security Controller sending of information is blocking? Eg when it = tells > the node to install an inbound IPsec SA, it is blocked from doing = anything > else. If this is not the case, then the 3 step program should be = clarified > that it needs to also receive confirmations. And if this is a = non-blocking > process, who is responsible for "retransmits" of these confirmations ? > The same applies to the blocking or time-wait between step 2 and 3. [Authors] Yes, the controller goes through this process in a blocking = way per each step. That is, the Security Controller needs to finish = correctly the step 1 before proceeding with step 2. This is possible = since the Security Controller will receive a NETCONF rpc-reply with OK = after installing the inbound in peer A and the same for peer B. When = receiving both OKs, it can proceed to step 2. The same happens between = step 2 and step 3. The reason of doing this in this way is to prepare first the new inbound = IPsec SAs and everything is ready, then the new outbound IPsec SAs. When = the new outbound IPsec SAs are set, we have observed (at least in Linux = kernel) that the new outbound IPsec SA is immediately used. Since the = other peer has already the corresponding inbound SA no traffic loss = happens. However if we assume that some traffic loss is allowed, we could send = inbound and outbound IPsec SAs in parallell to both nodes involved in = the rekey. What do you think? Regarding retransmission of the confirmation the NETCONF transport = (SSH/TCP or TLS/TCP) will provide this. >=20 > Also, I would say step 3 can be get rid of if the IPsec implementation = can > itself detect traffic on the new IPsec SA and it can delete the old = IPsec > SA itself without instruction from the Security Controller. [Authors] Correct. We were wondering though how common this is (at least = in linux kernels we have not seen this behaviour). Moreover, the = Security Controller should know how this is implemented internally in = the NSF to avoid sending this delete. Either that, or the NETCONF server = in the NSF should pay attention to this by interacting with the kernel = (through netlink=C2=BF?=C2=BF?) and remove it when it sees that traffic. = I have seen that libreswan has a wishlist about this feature. Is there = any movement in this side? >=20 > Section 5.3.2: >=20 > If one of the NSF restarts, it may lose part or all the IPsec = state >=20 > This "may" suggests a very interesting case. I doubt the NSF would = store on > non-volatile memory the IPsec symmetric keys for encryption, and the = counter > or ICV's used. If it could store that, the document needs some text = about > this in the Security Considerations because it will allow for easier = theft > of session material. [Authors] Yes, this "may" is unfortunate because our assumption is that = all this information will be in volatile memory. More specifically, we = assume that NSF does not have any information in the startup-config = (non-volatile), only in the running-config datastore (volatile) >=20 > Rather, I suspect this may really is not true, and all of these = devices would > lose state? [Authors] Correct. Although other aspects could be considered in the = future (for example, is it reasonable to think that IKE configuration = could be in non-volatile as well just in case the node falls?) >=20 > In both cases, the Security Controller MUST be aware of the = affected NSF >=20 > I think this MUST is a little misleading. It is not desired behaviour = but just > an observation - it cannot not know its TCP session died ? Perhaps = write: >=20 > In both cases, the Security Controller is aware of the affected = NSF [Authors] Yes, this is better. >=20 > A similar case for the next sentence MUST keyword: >=20 > Moreover, the Security Controller MUST have a register about all = the > NSFs that have IPsec SAs with the affected NSF. >=20 > so write: >=20 > Moreover, the Security Controller has a register about all the > NSFs that have IPsec SAs with the affected NSF. [Authors] Agree.=20 >=20 >=20 > (It is TBD in the model). >=20 > This remark seems to need to be resolved before publication ? [Authors] It is already fixed but we missed to remove this text. +--rw initial-contact? boolean >=20 > In Case 2, if the Security Controller detects that a NSF has lost = the > IPsec SAs (e.g. it reboots) it will follow similar steps to rekey: > the steps 1 and 2 remain equal but the step 3 will be slightly > different. For example, if we assume that NSF B has lost its state, > the Security Controller MUST only delete the old IPsec SAs from A in > step 3. >=20 > I don't understand why this paragraph about NSF state loss seems to = talk > about "step 3" which can only be referring to the "rekeying process" = of > the previous section. It should only mention that it should configure = new > IPsec SAs between the failed node and all the nodes the failed node = talked > to and only after those are estlibhsed, it can send a delete for the = old > IPsec SAs on the non-failed nodes. This prevents the non-failed nodes = from > leaking plaintext. [Authors] Agree. However I was thinking that failed node may not come to = life again. In such a case, if a failed node falls, the active IPsec SAs in the rest = of non-failed nodes with the failed node are not useful. Therefore, the = SC could first delete the old IPsec SAs on the non-failed nodes. If the = failed node comes to live, then the SC will install first the new = inbound IPsec SAs and after these IPsec SAs are established then to = install the outbound IPsec SAs. What do you think? Having said that, we propose to replace this paragraph with the = following text: "In IKE-less case, if the Security Controller detects that a NSF has = lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs of = the non-failed nodes established with the failed node (step 1). This = prevents the non-failed nodes from leaking plaintext. If the failed node = come to live, the Security Controller will configure the new inbound = IPsec SAs between the failed node and all the nodes the failed talked to = (step 2). After these inbound IPsec SAs have been established, the = Security Controller can configure the outbound IPsec SAs (step 3)." >=20 > Section 5.3.3: >=20 > I'm confused how the Security Controller can know what NAT ports to = convey to > the NSF agent. Without IKE traffic, there is no port NAT mapping? So = unless > the Security Controller _is_ the NAT gateway, it would never know this > information? So I am skeptical if the NAT case can ever work without = IKE. > I also do not know how the Security Controller could decide between = UDP, > TCP or TLS without information from an IKE negotiation. [Authors] Basically as we state in our text, the SDN paradigm generally = assumes the Security Controller will have a view of the network it controls. = Based on this, the Security Controller can know if there is a NAT = configured between two hosts. For example, if you take a look to: =20 https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-17 = =20 the Security Controller could use this netconf module with a gateway = to collect NAT information or even configure a NAT. =20 Regarding the usage of UDP, TCP or TLS, since it controls all the = network it is something that the Security Controller should decide. =20 In any case, if this NETCONF module is not available and the Security = Controller cannot know if a host is behind a NAT or not, then IKE case = should be the right one and not the IKE-less. Best Regards. ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es = ------------------------------------------------------- --Apple-Mail=_F82529B5-233B-4502-A774-9BB53D71F8EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Paul,all:

Here you can find our answers for section 5.

Section 5.1:

The diagram lists:

| =   IKE    | =      IPsec(SPD,PAD)  |

Shouldn't that be:

=        | IKE(PAD) | IPsec(SPD, = SAD)

IKE is using the PAD information to = tell IPsec to establish SPDs and SADs) ?

[Authors] The PAD is something defined = in RFC 4301, which is independent of the key management = protocol.

=46rom= RFC 4301:
"The entry specifies the authentication = protocol
   (e.g., IKEv1, IKEv2, KINK) = method"
   
Therefore = it is not something attached to the key management protocol itself but = more related with IPsec implemenation. What it is true that PAD is not = implemented in current Linux kernel and usually this information is set = in the IKE implementation. Finally we have only described in Fig. 1 that = SPD and PAD must be configured from the Controller. The SAD will be = managed by the IKEv2 implementation. Same happens in Fig. 2.




Section 5.1.1:

What does this mean:

Moreover, = an east-west interface is required to exchange IPsec-related = information.

[Authors]= In SDN terminology an east-west interface is the communication = interface between two controllers.

For example: https://tools.ietf.org/html/rfc7426

If we have two gateways = where we need to establish an IPsec SA and both are under the control of = two different controllers then both Security Controllers needs to = exchange information so that they need to agree in some information so = that the configure their own gateways properly (see Fig. 5). An example: = they have to agree that IKEv2 authentication will be based on raw public = keys or pre-shared keys. And if it pre-shared keys they will have to = agree in the PSK (Yes, one option to explore is IKEv2, more related = comments in posterior answers.)

Section = 5.2:

  In this case, the NSF = does not deploy IKEv2 and, therefore, the
=   Security Controller has to perform the management of IPsec = SAs by
  populating and monitoring the SPD and = the SAD.

I would write:

In this case, the NSF does not deploy IKEv2 and, therefore, = the
Security Controller has to perform the IKE security = functions and management
of IPsec SAs by populating and = managing the SPD and the SAD.

I added "IKE = security functions" to make sure some entity is responsible
for those items that are normally done by IKE (IV generation, = prevent counter
resets for same key, etc).
I changed monitoring to managing, because I don't understand = how it would "monitor"
the NSF or what it would monitor. I = assume also if during monitoring it finds
something that = needs changing (eg vpn tunnel up or down) that it will do so,
so I think managing is the better word.

[Authors] Agreed with this text. Very reasonable.

For this diagram, I would say IPsec(SPD, SAD) = would need to also list the IKE
security function it needs = to use in an IKE-less scenario, which above I had
called = "management of IPsec SAs=E2=80=9D

[Authors] 

How about this non-exhaustive list:

- IV generation
- = prevent counter resets for same key
- Generation of = pseudo-random cryptographic keys for the IPsec SAs
- = Rekey of the IPsec SAs based on notification from the NSF  (i.e. = expire)
- Generation of the IPsec SAs when required = based on notifications (i.e. sadb_acquire)
- NAT = Traversal discovery and management. 
- = ....


What about the following = (non-exhaustive) tasks?
- SPI random = generation
- Cryptographic algorithm/s = selection
- Usage of extended sequence = numbers
- Establishment of proper traffic = selectors 
- ....

Section 5.3:

As mentioned = before, a better title would be: IKE vs IKEless

I would also start this section with:

Case 1 is more secure, because all security features of IKE = are used to manage
the IPsec SAs.

[Authors] We do = understand the comment.

How about this new text:

=E2=80=9CIKE case provides better = security properties than IKE-less case. In particular, the Security = Controller is not able to observe what are the cryptographic keys used = to protect data traffic."




Section 5.3.1:
  For case 1, the rekeying process is carried out = by IKEv2, following
  the configuration defined = in the SPD.

Technically this is the SPD and = SAD, as the SPD would for example list the
maximum number = of packets allowed, but the SAD lists the number of packets
that have happened.

[Authors] Ok. We will = replace the text: 

s/"For case 1, the rekeying process is carried out by IKEv2, = following the configuration defined in the SPD."/"For IKEv2 case, the = rekeying process is carried out by IKEv2, following the configuration = defined in the SPD and SAD."

I am a bit = confused by the rekey description. I guess it assumes that the
Security Controller sending of information is blocking? Eg = when it tells
the node to install an inbound IPsec SA, it = is blocked from doing anything
else. If this is not the = case, then the 3 step program should be clarified
that it = needs to also receive confirmations. And if this is a non-blocking
process, who is responsible for "retransmits" of these = confirmations ?
The same applies to the blocking or = time-wait between step 2 and 3.

[Authors] Yes, the controller goes = through this process in a blocking way per each step. That is, the = Security Controller needs to finish correctly the step 1 before = proceeding with step 2. This is possible since the Security Controller = will receive a NETCONF rpc-reply with OK after installing the inbound in = peer A and the same for peer B. When receiving both OKs, it can proceed = to step 2. The same happens between step 2 and step 3.

The reason of doing this = in this way is to prepare first the new inbound IPsec SAs and everything = is ready, then the new outbound IPsec SAs. When the new outbound IPsec = SAs are set, we have observed (at least in Linux kernel) that the new = outbound IPsec SA is immediately used. Since the other peer has already = the corresponding inbound SA no traffic loss happens.

However if we assume = that some traffic loss is allowed, we could send inbound and outbound = IPsec SAs in parallell to both nodes involved in the rekey. What do you = think?

Regarding= retransmission of the confirmation the NETCONF transport (SSH/TCP or = TLS/TCP) will provide this.

Also, I would say step 3 can = be get rid of if the IPsec implementation can
itself = detect traffic on the new IPsec SA and it can delete the old IPsec
SA itself without instruction from the Security = Controller.

[Authors] Correct. We were wondering = though how common this is (at least in linux kernels we have not seen = this behaviour). Moreover, the Security Controller should know how this = is implemented internally in the NSF to avoid sending this delete. = Either that, or the NETCONF server in the NSF should pay attention to = this by interacting with the kernel (through netlink=C2=BF?=C2=BF?) and = remove it when it sees that traffic. I have seen that libreswan has a = wishlist about this feature. Is there any movement in this = side?

Section 5.3.2:

If one of the NSF restarts, it = may lose part or all the IPsec state

This = "may" suggests a very interesting case. I doubt the NSF would store = on
non-volatile memory the IPsec symmetric keys for = encryption, and the counter
or ICV's used. If it could = store that, the document needs some text about
this in the = Security Considerations because it will allow for easier theft
of session material.

[Authors] Yes, this "may" is unfortunate because our = assumption is that all this information will be in volatile memory. More = specifically, we assume that NSF does not have any information in the = startup-config (non-volatile), only in the running-config datastore = (volatile)

Rather, I suspect this may = really is not true, and all of these devices would
lose = state?

[Authors] Correct. Although other aspects could be = considered in the future (for example, is it reasonable to think that = IKE configuration could be in non-volatile as well just in case the node = falls?)

In both cases, the Security = Controller MUST be aware of the affected NSF

I think this MUST is a little misleading. It is not desired = behaviour but just
an observation - it cannot not know its = TCP session died ? Perhaps write:

In both = cases, the Security Controller is aware of the affected NSF

[Authors] Yes, this is better.


A similar case for the next sentence MUST = keyword:

Moreover, the Security Controller = MUST have a register about all the
NSFs that = have IPsec SAs with the affected NSF.

so = write:

Moreover, the Security Controller = has a register about all the
NSFs that have IPsec SAs with the = affected NSF.

[Authors] Agree. 



(It is TBD in the = model).

This remark seems to need to = be resolved before publication ?

[Authors] It is already fixed but we = missed to remove this text.

+--rw initial-contact?     = boolean

  In Case 2, if the Security = Controller detects that a NSF has lost the
=   IPsec SAs (e.g. it reboots) it will follow similar steps to = rekey:
  the steps 1 and 2 remain equal but the = step 3 will be slightly
  different.  For = example, if we assume that NSF B has lost its state,
=   the Security Controller MUST only delete the old IPsec SAs = from A in
  step 3.

I don't understand why this paragraph about NSF state loss = seems to talk
about "step 3" which can only be referring = to the "rekeying process" of
the previous section. It = should only mention that it should configure new
IPsec SAs = between the failed node and all the nodes the failed node talked
to and only after those are estlibhsed, it can send a delete = for the old
IPsec SAs on the non-failed nodes. This = prevents the non-failed nodes from
leaking plaintext.

[Authors] Agree. = However I was thinking that failed node may not come to life = again.
In such a case, if a failed node falls, the = active IPsec SAs in the rest of non-failed nodes with the failed node = are not useful. Therefore, the SC could first delete the old IPsec SAs = on the non-failed nodes. If the failed node comes to live, then the SC = will install first the new inbound IPsec SAs and after these IPsec SAs = are established then to install the outbound IPsec SAs. What do you = think?

Having = said that, we propose to replace this paragraph with the following = text:

"In = IKE-less case, if the Security Controller detects that a NSF has lost = the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs of the = non-failed nodes established with the failed node (step 1). This = prevents the non-failed nodes from leaking plaintext. If the failed node = come to live, the Security Controller will configure the new inbound = IPsec SAs between the failed node and all the nodes the failed talked to = (step 2). After these inbound IPsec SAs have been established, the = Security Controller can configure the outbound IPsec SAs (step = 3)."


Section 5.3.3:
I'm confused how the Security Controller can know what NAT = ports to convey to
the NSF agent. Without IKE traffic, = there is no port NAT mapping? So unless
the Security = Controller _is_ the NAT gateway, it would never know this
information? So I am skeptical if the NAT case can ever work = without IKE.
I also do not know how the Security = Controller could decide between UDP,
TCP or TLS without = information from an IKE negotiation.

[Authors] Basically as = we state in our text, the SDN paradigm generally assumes
 the Security Controller will have a view of the network = it controls. Based on this, the Security Controller can know if there is = a NAT configured between two hosts. For example, if you take a look = to:
   
  =  https://tools.ietf.org/html/draft-ietf-opsawg-nat-yang-17
   
   the = Security Controller could use this netconf module with a gateway to = collect NAT information or even configure a NAT.
   
   Regarding the = usage of UDP, TCP or TLS, since it controls all the network it is = something that the Security Controller should decide.
   
   In any case, = if this NETCONF module is not available and the Security Controller = cannot know if a host is behind a NAT or not, then IKE case should be = the right one and not the IKE-less.


Best Regards.
-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_F82529B5-233B-4502-A774-9BB53D71F8EB-- From nobody Sat Dec 1 08:10:46 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3501D1277D2 for ; Sat, 1 Dec 2018 08:10:45 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 iR6lwk8QlJE7 for ; Sat, 1 Dec 2018 08:10:44 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF391271FF for ; Sat, 1 Dec 2018 08:10:43 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 436bp91XpvzMRx; Sat, 1 Dec 2018 17:10:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1543680641; bh=JdFmTlgLJN1nWRGCAj29kYd2Dyk2l0aLyPq0BzuQMIA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FPfeUjrjWe5nfjD8vVOJs9ZOs+qrZyPzJJzAls7ZvDdRBV9sudYI7jgDSvqNOpYC3 YtAauWM/GSOArg1mvD/PSWe2tlfxJnJ/F+Pwjhe3l3CHTG7qCpJGG30Hj/a8rB1e7+ oykdEtJVXptRjXBz1LYSJLn77UxR0Bq6W1Asx4uU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id XB4MXPITjSFO; Sat, 1 Dec 2018 17:10:39 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 1 Dec 2018 17:10:39 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6CA96319421; Sat, 1 Dec 2018 11:10:38 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6CA96319421 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5C4D640D37F8; Sat, 1 Dec 2018 11:10:38 -0500 (EST) Date: Sat, 1 Dec 2018 11:10:38 -0500 (EST) From: Paul Wouters To: "Waltermire, David A. (Fed)" cc: IPsecME WG In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2018 16:10:45 -0000 On Fri, 30 Nov 2018, Waltermire, David A. (Fed) wrote: > This message starts a working group last call (WGLC) on draft-ietf-ipsecme-qr-ikev2-04, which will conclude on December 14, 2018 at UTC 23:59. Please review and provide feedback on the -04 version (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/). Please indicate if you believe this draft is ready for publication or if you have comments that must be addressed before the draft progresses to the IESG. I believe the document is ready. We (libreswan) have implemented it and performed successful interop with 3 other vendors (Cisco, Apple, Elvis+) It is important because this eliminates one of the very few reasons left why people would need to run IKEv1 instead of IKEv2. Paul From nobody Mon Dec 3 00:31:39 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A3312777C for ; Mon, 3 Dec 2018 00:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vNBRAcigE0iP for ; Mon, 3 Dec 2018 00:31:36 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374BA126C01 for ; Mon, 3 Dec 2018 00:31:36 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id a16so8438984lfg.3 for ; Mon, 03 Dec 2018 00:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=PqegaVq6ybQtQw34dstZUCXUsPui4JYHGj4BePRjr9s=; b=tYnC8XBKgND1kPVgFL+HcE1BHZVWa2spxUZsMOVMkYQYwcnUarHfCHELkyeq09p+2Y WO+rw62rBEg/1lKsq5+3V1EVbFH7v5M5Njs3psHg1dbkU7lsiFT+meZkmrXq7Yj5jRfS PlUvEU0/atb4xd8ENfWIlWazWMPrn8iPC300Zao+A52hpziGC5TmIkgqxJhuQqe+7fLj Lb3oapbPb/MgKBcyV1skTX1DtnV5PFMUHKT1f4DL5rYI0uUAkAPRMUOnUq71x531EMKa Rhcvs1/SY2pI9wetu2UHLTyPBj9vWRdlYNepa6uq0qp901jIe2LDLadTvbFL8TCWcGUx DlDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=PqegaVq6ybQtQw34dstZUCXUsPui4JYHGj4BePRjr9s=; b=O4fMwBx9CbknCSo6bukg/jFedmSskj+9NF6ngrCyREpkJLfyreJdMo4U1v7MOmhTiT HkU4UGn8waVKRFO4PxpBZhKYdo9C71/FNwaj4+/iVcnso/UZFXj27clE2tjhJoQ1efVa zKfu1zUQqYSEe8QIJSryrn4qT5F8kMY+50riYdMY3NStq135rMeJZFqonmLGNir3R4l8 yoFP1R6xU79G/ITPKxlQdMvU8hVzY3sX5pvN2kE8UKpGUamt8PHU4KE/yITirCYpJnik W98Egr2Wr0f1q5p1Y4thoB4e5GBQi08oY89K7Y+XhTB8Abfqqgh0SHy8SteZNu9cWQ6n Acng== X-Gm-Message-State: AA+aEWYZNahn2HCpMi6mzpWwLPSzwCV0VFe5y94Vv8HoPHKrFhTTLeER lotjV1NDLHkyVqzrionBXQ0= X-Google-Smtp-Source: AFSGD/Vr9mLx6WRHaC4bT2GeNSGDMPdngC8AOW6FyztrhnNxO1hVNYn+Ovk3N81oAD27/H+yfh1MEg== X-Received: by 2002:a19:1cd3:: with SMTP id c202mr8939304lfc.33.1543825894405; Mon, 03 Dec 2018 00:31:34 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n187sm2221238lfn.59.2018.12.03.00.31.33 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Dec 2018 00:31:33 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Waltermire, David A. \(Fed\)'" Cc: "'IPsecME WG'" References: In-Reply-To: Date: Mon, 3 Dec 2018 11:31:33 +0300 Message-ID: <01c101d48ae2$99a77ec0$ccf67c40$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQHv1RvHAMSwEbpxjyf9nMrISBQelwL+nZkIpR4jV3A= Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 08:31:38 -0000 > > This message starts a working group last call (WGLC) on draft-ietf-ipsecme-qr-ikev2-04, which will conclude > on December 14, 2018 at UTC 23:59. Please review and provide feedback on the -04 version > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/). Please indicate if you believe this draft is ready > for publication or if you have comments that must be addressed before the draft progresses to the IESG. > > I believe the document is ready. We (libreswan) have implemented it and > performed successful interop with 3 other vendors (Cisco, Apple, Elvis+) I agree with Paul that the document is ready. I would only add that the protocol is quite stable - no changes were made to it within last year (since December 2017), only some clarifications. Regards, Valery. From nobody Mon Dec 3 05:09:13 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02211130E23 for ; Mon, 3 Dec 2018 05:09:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zXOjEh6Pk5Iv for ; Mon, 3 Dec 2018 05:09:10 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35361130E1C for ; Mon, 3 Dec 2018 05:09:10 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id u18so9057886lff.10 for ; Mon, 03 Dec 2018 05:09:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=ohW3mqloaCmUuqDKX3H25zQ7AqegvR4sGYjZGYNiOOM=; b=H6B22sEEh8tR5tpkqsuRZgmSaPBrfrHt5hu9eAhzMd+h72TlKHsSFB2MS+2BzsvboV W51X5JYx/dWLIGIBsuvCQvjeE4OUQpvSfcYOc6N0o0d7sb/nNBsyx6fCnb4WjuHDAeb/ YfutbJ3HLmpCNK2BrwlhrKir/M/EMCPfl+rhqOGC0fl4Eh6NzsIpyxmSvlver0GrxucF pIxp3YefAQxjnhabKAWBWUH/lczuTdXlphSfpl65gPK+Ht9EnIvZu5IF/IKbY09zZQJ6 FAm90bfXsJbTcjD2QKpJVpHo6lBMvr30Do1W9Zksujpba2DCWpTIUzvl67ySRzCS1bP6 fwPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=ohW3mqloaCmUuqDKX3H25zQ7AqegvR4sGYjZGYNiOOM=; b=Ik0rb+Mf6Rw+WEVVRr7j++u9NTAVOr8UjLG2T9USEpNAlrkVueqboNL359eIue1oTS ZfoEX8zovc9muJaRokf8omYM1TpC3cxXle4Kt3t/HNqy4kNXv7XlvO80kwxktbtskcri UwkeSGcCqhoA6jrbLOxRHmHhXE2vOT63NCQGhHDP+G5sxpqsm/ACk0DnVmHKytg2gYk4 SKbYidPa+AkUyevobJyuWVkECvdcTxxIOo1LsQtpF5MYTTHF8KFIc2pf3aXJhREBNvvi CGuHeyVHGrq5SKIlcd1EC6x9AFdP4DkZ28r3o7nzZSXwNR7UQCq2YcUERKzLakrSv90T Ymkw== X-Gm-Message-State: AA+aEWYFVWY+qGqheMTxDXELlaVWRn4VaxsykMOaB7YMBJsn5XEB8AHU WpqaGX8RBdYpNhziLA5Rly0Clsf0 X-Google-Smtp-Source: AFSGD/WDObRz4jiTJP1gTYpXELOlmIdSo7XRUCuKrWy9+wnH/2S/M7+1PARiCI6tAnS6uT5/Xlo3Kw== X-Received: by 2002:a19:c203:: with SMTP id l3mr8858115lfc.113.1543842547959; Mon, 03 Dec 2018 05:09:07 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o26sm2498090lfl.18.2018.12.03.05.09.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Dec 2018 05:09:07 -0800 (PST) From: "Valery Smyslov" To: "IPsecME WG" References: <154384180519.18304.6269496079887828694.idtracker@ietfa.amsl.com> In-Reply-To: <154384180519.18304.6269496079887828694.idtracker@ietfa.amsl.com> Date: Mon, 3 Dec 2018 16:09:07 +0300 Message-ID: <01d301d48b09$5fe4e570$1faeb050$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQFvpIhkJ6MbBCvQSE8mfruBasP2faY2xncA Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-aux-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 13:09:12 -0000 Hi, I've submitted a new version of the draft-smyslov-ipsecme-ikev2-aux. Major changes: 1. The exchange is renamed from IKE_AUX to INTERMEDIATE (thanks Tommy!). I believe this name reflects its purpose, it's easy to pronounce and hard to mix with existing exchanges. 2. The way the exchange is authenticated in IKE_AUTH is changed to include full transcript from both parties (thank to Scott for suggesting this). 3. The order of the chunks that are input to prf is changed, as well as the position of the prf outputs in the signing blobs. These changes were motivated by implementation experience - they make implementing the exchanges a bit easier. I believe they don't influence security. 4. Some clarifications are added. Comments are more than welcome :-) Regards, Valery. > A new version of I-D, draft-smyslov-ipsecme-ikev2-aux-02.txt > has been successfully submitted by Valery Smyslov and posted to the > IETF repository. > > Name: draft-smyslov-ipsecme-ikev2-aux > Revision: 02 > Title: Intermediate Exchange in the IKEv2 Protocol > Document date: 2018-12-03 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-aux-02.txt > Status: https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-aux/ > Htmlized: https://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-aux-02 > Htmlized: https://datatracker.ietf.org/doc/html/draft-smyslov-ipsecme-ikev2-aux > Diff: https://www.ietf.org/rfcdiff?url2=draft-smyslov-ipsecme-ikev2-aux-02 > > Abstract: > This documents defines a new exchange, called Intermediate Exchange, > for the Internet Key Exchange protocol Version 2 (IKEv2). This > exchange can be used for transferring large amount of data in the > process of IKEv2 Security Association (SA) establishment. > Introducing Intermediate Exchange allows re-using existing IKE > Fragmentation mechanism, that helps to avoid IP fragmentation of > large IKE messages, but cannot be used in the initial IKEv2 exchange. > > > > > 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 Dec 3 05:48:59 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14D0B12D4F2 for ; Mon, 3 Dec 2018 05:48:57 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 NzlI6pgRanSK for ; Mon, 3 Dec 2018 05:48:55 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BD412870E for ; Mon, 3 Dec 2018 05:48:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 437mYc1MTwzFdX; Mon, 3 Dec 2018 14:48:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1543844932; bh=TrVGcl5K44yMaGmzdRB4DELJGk2Ovg+SxoTtg/T8jps=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fT5Y7X61tyKkD8eDlKTWmRsryvu3bY0L7ys9OY5EMUD3Ix5Sok1pcwdBf196am2vX j+8kUVc4YbF4CpSnuRHEaQN94G4CvlMcZthgkIbxHLxBsUNWjfwmNHip89I+PyLOeL QSb7uxSFKchVCgvAapU3pmYQLULKuiK8I2UHlVXI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id GdmWXOCt1mnU; Mon, 3 Dec 2018 14:48:51 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 3 Dec 2018 14:48:50 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5182C12EAE4; Mon, 3 Dec 2018 08:48:49 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5182C12EAE4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 47E5840D37F8; Mon, 3 Dec 2018 08:48:49 -0500 (EST) Date: Mon, 3 Dec 2018 08:48:49 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" In-Reply-To: <01d301d48b09$5fe4e570$1faeb050$@gmail.com> Message-ID: References: <154384180519.18304.6269496079887828694.idtracker@ietfa.amsl.com> <01d301d48b09$5fe4e570$1faeb050$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-aux-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 13:48:57 -0000 On Mon, 3 Dec 2018, Valery Smyslov wrote: > I've submitted a new version of the draft-smyslov-ipsecme-ikev2-aux. Major changes: > > 1. The exchange is renamed from IKE_AUX to INTERMEDIATE (thanks Tommy!). > I believe this name reflects its purpose, it's easy to pronounce and hard to mix > with existing exchanges. It is missing the prefix IKE_ ? In my opinion, IKE_SA_INIT / IKE_AUTH should have been named consistenly, eg either IKE_SA_INIT / IKE_SA_AUTH or IKE_INIT / IKE_AUTH So in that light, this would be better as IKE_INTERMEDIATE INFORMATIONAL should have been IKE_INFORMATIONAL, and CREATE_CHILD_SA is an abomination to act either on IKE or CHILD SA without seperating its exchange :) But if people insist on INTERMEDIATE, I won't complain further. Consistency is already lost so it is time to stop painting :) Paul From nobody Mon Dec 3 06:00:11 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3786129C6B for ; Mon, 3 Dec 2018 06:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3m1OYLYNvjeD for ; Mon, 3 Dec 2018 06:00:04 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A429312870E for ; Mon, 3 Dec 2018 06:00:03 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id n18-v6so11467649lji.7 for ; Mon, 03 Dec 2018 06:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=JUMw8tRX59C/41AYa1l8SWHI9x8r2Ho4cqoTBl0TEb4=; b=YmwjarOK71Yqwcx6GQPzJVVBsNyukk5XRQJQuyAbq+dz3P7iWFfp0pZLPFxitM38T6 aWP83LUY8PDeu1ocwQOFDa0YpO9aTZwyHSfODKPyvgLf2D5/5YcvuOEzknhSmki8qFjv VYNqPFDODanAKEGuO6fBgMmcBjakOVFmEZNLj5EqHDP7Z7+dVZABqsLC2jDxP533ixS4 qJ+pPMudvda5B7lkCRtrmVQNGguyCsBgAZJMx0EKOOE17NxH/r7FPFNWNVgiMl8r7U1S 8vSiDMWLIzONoBbhtrblsJWyiBBeqbId2fwJc9inkTi7qbL96L8GTkzpfWV7Kl9RKOCy W2Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=JUMw8tRX59C/41AYa1l8SWHI9x8r2Ho4cqoTBl0TEb4=; b=gtQyh1lIcaNz77ZcIGv7d4t/Tw+W6DjqqnjY081dDDL68zvPIfe/JdQmJw7DHcrhE8 ctppxw46MiuYFhBvT69f9R+X9cYNGIrrxYp7bbAp/ovY/iT3RbMfsYfD9UoY0MdSr475 WoxTeI6ZA4eUqY0GbmzE8bc7kgiAFwgnBggx1QUtdw8qm+UVjY6Bz6Up6G0asqKkhWEQ 5cp49IFnqAC98tVBH1H3/Q4Dr0booKS7QX3QYhnLFpZemENMXAC3qs7eS2JFJJmmmNaP m0FMtX2zXxD9P4USaBcbVT4d+2l6HZ96VEGXJcK9KGsR1VJ8RexfhX+f11biH55j72t6 Iv9A== X-Gm-Message-State: AA+aEWaO+iJMnoEtCm6GaRnaYFb0yvKvFPR7/3Mk0pEAeFdvemqF/BYj il9DJwp/JnaGsDOHIjW7frOUBz/3 X-Google-Smtp-Source: AFSGD/X4wvsnynDiTB8TTohh0JP8x9JpyE1gnBqMWZi39aoo04I5pwh8t659u1Mo+wDG4yathwpnNg== X-Received: by 2002:a2e:914b:: with SMTP id q11-v6mr9830243ljg.164.1543845601460; Mon, 03 Dec 2018 06:00:01 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e14-v6sm2451915ljb.31.2018.12.03.06.00.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Dec 2018 06:00:00 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: References: <154384180519.18304.6269496079887828694.idtracker@ietfa.amsl.com> <01d301d48b09$5fe4e570$1faeb050$@gmail.com> In-Reply-To: Date: Mon, 3 Dec 2018 17:00:00 +0300 Message-ID: <01dd01d48b10$7c07f1a0$7417d4e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQFvpIhkJ6MbBCvQSE8mfruBasP2fQFZwntNAtSgy2qmFWJvoA== Archived-At: Subject: Re: [IPsec] New Version Notification for draft-smyslov-ipsecme-ikev2-aux-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 14:00:10 -0000 > > 1. The exchange is renamed from IKE_AUX to INTERMEDIATE (thanks Tommy!). > > I believe this name reflects its purpose, it's easy to pronounce and hard to mix > > with existing exchanges. > > It is missing the prefix IKE_ ? As well as INFORMATIONAL and CREATE_CHILD_SA. > In my opinion, IKE_SA_INIT / IKE_AUTH should have been named > consistenly, eg either IKE_SA_INIT / IKE_SA_AUTH or IKE_INIT / IKE_AUTH I agree that it would have been better, but we have what we have now. > So in that light, this would be better as IKE_INTERMEDIATE It's a bit too long in my opinion :-) > INFORMATIONAL should have been IKE_INFORMATIONAL, and CREATE_CHILD_SA > is an abomination to act either on IKE or CHILD SA without seperating > its exchange :) > > But if people insist on INTERMEDIATE, I won't complain further. Definitely not "insist" for now, only "suggest" :-) > Consistency is already lost so it is time to stop painting :) Yes, that was my final thought too. Regards, Valery. > Paul From nobody Mon Dec 3 08:55:50 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7751B130EE9 for ; Mon, 3 Dec 2018 08:55: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 I5uPFFiLStJS for ; Mon, 3 Dec 2018 08:55:46 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D9B130E0E for ; Mon, 3 Dec 2018 08:55:46 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 437rj713ZZzMWS for ; Mon, 3 Dec 2018 17:55:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1543856139; bh=Gd+b2YgTP256Hvg6p6PvwphUUEhak1/174R6JuSFMyE=; h=Date:From:To:Subject; b=ZkAIaHS+4LgbRn++zHGSASbx678w/cyDkN/l2KAjjLjVCBpudiA8mQn5K8XQJvS8Y g1shqEY+JhriRmx3DRta8muYU+xih4R7tMoc3AJKOf/vJUYI9YeF7g3VAxM/UyKmgl FIf6KBNehvubzjg5nyhUfjyhFdKNmmxdGk45u3xo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wsc7EQ2n6U8A for ; Mon, 3 Dec 2018 17:55:37 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Mon, 3 Dec 2018 17:55:37 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3641412EAE4; Mon, 3 Dec 2018 11:55:36 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3641412EAE4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2CAD140D37F8 for ; Mon, 3 Dec 2018 11:55:36 -0500 (EST) Date: Mon, 3 Dec 2018 11:55:36 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] IKE_INIT spoofing from SaudiNet and Zain Data-Jordan ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 16:55:49 -0000 Hi, I've seen reports where our software receives IKE_AUTH requests without the preceeding IKE_INIT request. After some debugging, it seems that two networks, SaudiNet and Zain Data-Jordan, sometimes MITM the IKE_INIT by replying (and I guess generating a IKE SPI for the responder) and then step away to let the IKE_AUTH fail, since the responder never received the original IKE_INIT. Has anyone else seen this as well? Is this some surveilance tool that is being buggy, or is this behaviour the intended result? It seems to be happening intermittently. Paul, almost curious enough to hack in an IKE_INIT request in an IKE_AUTH marked exchange packet :P From nobody Mon Dec 3 14:57:39 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8640130DF9; Mon, 3 Dec 2018 14:57:37 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 V0UHYURK3sMh; Mon, 3 Dec 2018 14:57:34 -0800 (PST) Received: from xenon44.um.es (xenon44.um.es [IPv6:2001:720:1710:601::44]) by ietfa.amsl.com (Postfix) with ESMTP id 29145130DF5; Mon, 3 Dec 2018 14:57:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id 7B83B1FF6A; Mon, 3 Dec 2018 23:57:31 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id utaXewPMuhbm; Mon, 3 Dec 2018 23:57:31 +0100 (CET) Received: from [192.168.1.12] (157.red-83-36-225.dynamicip.rima-tde.net [83.36.225.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon44.um.es (Postfix) with ESMTPSA id D379A200B1; Mon, 3 Dec 2018 23:57:24 +0100 (CET) From: Gabriel Lopez Message-Id: <5ACB4EEB-6BB4-455C-B5DF-5C833E4A9072@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_18FCA7D5-4A20-491D-B0E6-3AE1029FBA50" Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) Date: Mon, 3 Dec 2018 23:50:33 +0100 In-Reply-To: Cc: Gabriel Lopez , Yoav Nir , i2nsf@ietf.org, "ipsec@ietf.org WG" , Rafa Marin Lopez To: Paul Wouters References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2018 22:57:38 -0000 --Apple-Mail=_18FCA7D5-4A20-491D-B0E6-3AE1029FBA50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, all. Answers for section 6 in line. > El 18 nov 2018, a las 7:52, Paul Wouters escribi=C3=B3:= >=20 >=20 >=20 > Section 6.1: >=20 > Note that the use of start and end addresses, means that this can = never work > with IKEv1, that can only negotiate CIDR networks. Perhaps this should = be > explicitely stated somewhere just in case some developer thinks they = can > use IKEv1 for this? [Authors] ok, note that the yang element is explicitely named "IKEv2", = anyway, we can clarify this point in the document. In fact, we believe = that we should proceed with only IKEv2. BTW, we propose to change the model moving from the current "list of TSs = including a list of IP addresses and port ranges" for each policy to a = list of TSs per policy with one local and remote subnets per TS (instead = of "ranges"). What do you think? >=20 > I dont understand the names in: >=20 > next-layer-protocol* ipsec-next-layer-proto >=20 > It talks about ip-address and not ipsec-next-layer-ip-address? = Simiarly it > talks about local-ports. So why not just call this proto or protocol ? [Authors] The label "protocol" is widely used in the model. It is just a = way to identify the context. >=20 > Is selector-priority needed? Can the ts-number not be specified to be = "lower > numer is higher priority=E2=80=9D ? [Authors] It could (in fact, it is ordered by user, which means the = controller in our case) In fact, RFC4301 only specifies that "An SPD is an ordered list of = entries" >=20 >=20 > Why do we have security-protocol? If you are considered about small = footprints, > clearly you would implement only ESP and use ESP-NULL if encryption is = not > needed. And simply not implement AH (which is already optional not = mandatory > to implement for IPsec). Also, this assumes IPCOMP, which has its own = complexity, > would also not be used. I think a case for AH would be very weak, = while a case > for IPCOMP could be made. I'd recommend only supporting ESP, at which = point > you would not need this parameter, or you could keep it for = completeness > sake even though it could only have one value "esp". This would also = allow > an updated ESP or some ESPlite to be used in the future if such a = thing would > be developed. [Authors] We agree with only make use of ESP and ESP-NULL. > If we only go with AEAD algorithms, then the whole ah-algorithms part = can be > removed too. And esp-algorithms could be changed to only contain = esp-encryption > (or could be renamed aead-algorithm) [Authors] Same as before >=20 > I see spd-mark but not spd-security-context (see my Labeled IPsec = draft) [Authors] Regarding the XFRM mark element and the security context described in = the draft, if there is a clear use case for these elements we can keep = them in the model. >=20 > I found the names in lifetimes confusing. "added" really means maxlife = and > "current" really means maxidle I think? So I think the names would be > clearer as "time", "idle", "packets", "bytes". I think the time and = idle > units of uint64 could be narrowed down if the yang language allows = some > kind of timestamp type. [Authors] We have made use of the terminology in RFC2367, Section 2.3.2. = Indeed the yang model has a timestamp (RFC 6991). We can add "time", = "idle", "packets" and "bytes=E2=80=9D. >=20 > I am missing an entry for TFC (confidentiality, padding) ok, It could be included in the model (for IKE and IKE-less cases. > I also see no entry for IPCOMP algorithm. But I am fine with not = allowing > IPCOMP at all :) [Authors] Agree >=20 > I am missing replay window parameters ? Currently, the replay-window parameter is defined only in the SAD = configuration for IKE-less case. It should be also included in the SPD = configuration for IKE case. Do you think we should include the additional replay-seq, replay-oseq, = replay-seq-hi, replay-oseq-hi parameters for IKE-less case? >=20 > I don't know what statefulfragCheck is ? Whether or not to allow IKE fragmentation. (Libreswan/Strongwan support = that, valid values are are yes, (the default), no or force). Probably a better name for this? >=20 > Section 6.2 >=20 > See Section 6.1 comments. >=20 > Why are the encap entries in 6.2 and not 6.1 ? [Authors] For case 2 (IKE-less) espencap is configured like part of the = SA, not the policy. For IKE case encap is part of the IKEv2 = configuration (section 6.4) >=20 > What is the "state?" entry ? [Authors] state is of type sa-state (Larval, Mature, Dying, Dead). These states can be useful when the model is used by the SC to recover = SA's state data from the node or when modelling the sadb_expire message >=20 > Why is rpcs: only here? [Authors] You are right, rpcs should be in a 6.5 section. Note that = notifications are defined for SAD and SPD in IKE-less case and that = there are not notifications for IKE and PAD models >=20 > I would not use minbits, maxbits. All modern ciphers, especially AEAD, = are fixed key sizes. Make it a list of key sizes [Authors] Agree >=20 > I seem to miss the AEAD IV values ? [Authors] This container represents information about the algorithm = supported, we assume that AEAD algorithms can be also represented here = (AES_GCM, AES_CCM, CHACHA20-POLY1305, ....). IV values are not = represented here. > Possibly the truncation values ? [Authors] For auth-trunc values, we will include that in container ah-sa = unless AH is finally removed. >=20 > Section 6.3: >=20 > I only see PSK and RSA algorithms? No ECDSA via RFC 7427 Digital = Signatures? > (no PAKE, we have two IKE PAKE's although it looks like we want an = CFRG new one) [Authors] See answer in Appendix section. >=20 > Should PSK be of type "string". Some people want to hex entry? = Although those are often written > as strings with a 0x prefix. [Authors] Agree >=20 > I see some CRL entries, but no OCSP entries. Is it expected those = URI's are stored within the certificates, > and the received OCSP responses will never be communicated through = this interface? [Authors] Agree. We can add CRL and OCSP URLs >=20 > I see no local and remote part, meaning that only symmetric = authentication methods can be used. IKEv2 supports > asymmetric authentication methods as well. Especially when using EAP = and sometimes with AUTHHNULL, this method > is very asymmetric. So I believe this entry needs to be split in a = local/remote auth method. [Authors] Agree >=20 > Section 6.4: >=20 > type-autostartup issues... >=20 > typedef type-autostartup { > type enumeration { > enum ALWAYSON { description " ";} > enum INITIATE-ON-DEMAND {description " ";} > enum RESPOND-ONLY {description " ";} > } > description "Different types of how IKEv2 starts the IPsec SAs"; >=20 > With libreswan we have similar keywords, and run into some interesting = issues. We found what is really needed is to > know the current state and the connection desired state. for example, = when using ondemand and the connection is up, > it is important to know it is up because of ondemand. So that when you = receive a Delete request, you can go back > to ondemand state. If you dont keep this state then you cannot tell = the difference between alwayson/ondemand if > the connection is "up". Similarly, we had issues where connections has = a definition like above, but the administrator > performs an action. It is unclear if such an action is considered a = temporary override or basically a runtime update > of the configuration. So lets say we are in respondonly, and the = administrator brings the connection up. Now the other > end sends a delete. Do you assume you are in alwayson state or in = ondemand state? And if you believe alwayson, be > prepared for a war with the remote endpoint that keeps sending deletes = because it wants to be down. [Authors] Do you think this is something the model should consider? We = mean that, after all, behing the model we will have an implementation = (could be libreswan, strongswan etc.. that it will deal with these = aspects) It is true that we should define clearly what ALWAYSON, = INITIATE-ON-DEMAND, RESPOND-ONLY, etc=E2=80=A6 >=20 >=20 > Why is there nat-traversal and espencap. Why not just have espencap = allow to have a value of 'none=E2=80=99 ? [Authors] Agree > IKEv2 allows more then one oaddr (eg multiple SOURCE NAT IPs) but the = value is not a list? [Authors] Agree for the IKE case. For pfkey_v2 (setkey), it does not allow to specify oaddr. For xfrm, it does allow to specify only one oaddr. Does make it sense to allow more than one oaddr for IKE-less case? >=20 > The terms phase1-* should be called ike-* or ike-sa-* as phase1/phase2 = is IKEv1 terminalogy not used for IKEv2. [Authors] Agree. We can replace phase1-* by ike-sa-* and phase2-* by = ike-child-sa-*. >=20 > Why is combined-enc-intr needed? These are stored with the encalg = entries anyway. [Authors] Agree. >=20 > I see: >=20 > +--rw local > | +--rw (my-identifier-type)? >=20 > +--rw remote > | +--rw (my-identifier-type)? >=20 > I think "my-identifier-type" should be "identifier-type". Talking = about "my" for the remote peer is very confusing. [Authors] Agree. >=20 > my-identifier-type does not support the value ID_NONE from RFC 7619 [Authors] Agree. We will include that in the model. >=20 > Why is there no secion for ike-lifetime-{soft|hard} ? We also have = FIPS requirements that IKE SA's cannot do more > then X bytes for Y algorithm. And also bringing down idle IKE SA's = etc. [Authors] We can include a soft/hard lifetime (seconds) for IKE SA. What does it = means a soft/hard lifetime (bytes) for IKE SA. It is implemented in = current distributions? >=20 > I think "added", "used", "bytes" "packets" should be called lifetime, = idletime, maxbytes and maxpackets [Authors] See comment above. >=20 > The timestamp values "added" and "used" could have a better type than = uint64, eg unix epoch of unixtime or something? [Authors] Current implementations make use of __u64 or even uint32_t. Anyway, we = can modify the type. What do you propose? >=20 > the term ike-stats was confusing me. I thought at first these were the = global IKE statistics, like how many tunnels > are up, how many errors received, but it turned out to be the state of = a singe IKE SA. So perhaps ike-sa-state is a > better term? [Authors] Agree. > IKE state I expect things like SPIi and SPIr as listed here. [Authors] global IKE statictics could be obtained by the SC through the = ike-sa-state info for each IKE SA. >=20 > I am not sure why there are three nat-* bools instead of one value = representing the nat-state? Possibly because we > use a number of bits to indicate which of the NAT properties are set, = and you don't do this kind of bit mapping in > yang? >=20 [Authors] That could be represented with uint8 and using three bits , is = that what you mean? We thought was clearer to have three booleans. > I dont see an entry for "latest IKE SA". We have that in libreswan. = You can have multiple IKE SA's when rekeying, > and the older one is just lingering to die. Any operations such as = informational requests, dpd/liveness probes > should only be done with the "latest IKE SA". However, this is kind = of a state on the IKE node, so I am not > sure if this belongs in the yang model or not. [Authors] Is there any scenario where the SC is able to deal with this = information for the IKE case? If so, we can try to model that like state = data.=20 >=20 > I see a total SA's and halfopen SA's but I don't see anything related = to anti-DDOS cookies. Eg the number of half > open SA's before enabling cookies. Perhaps add = half-open-cookies-treshhold ? >=20 [Authors] Several parameters can be configured here: - half-open-threshold: number of half open IKE SAs - half-open-cookies-threshold: number of half open IKE SAs with cookie = activated - half-open-timer: timeout in seconds for connecting IKE SAs. Best regards, Gabi. >=20 ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_18FCA7D5-4A20-491D-B0E6-3AE1029FBA50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Paul, all.

Answers for section 6 in = line.

El 18 nov 2018, a las 7:52, Paul Wouters = <paul@nohats.ca> = escribi=C3=B3:



Section 6.1:

Note that the use of start and end addresses, = means that this can never work
with IKEv1, that can only = negotiate CIDR networks. Perhaps this should be
explicitely = stated somewhere just in case some developer thinks they can
use IKEv1 for this?

[Authors] ok, note that the yang = element is explicitely named "IKEv2", anyway, we can clarify this point in the document. In fact, we believe that we should proceed with only = IKEv2.

BTW, we propose to change the model = moving from the current "list of TSs including a list of IP addresses and port ranges" for each policy  to a list of TSs per policy with one local and remote subnets per TS (instead of "ranges"). What do you think?



I dont = understand the names in:

= next-layer-protocol*   ipsec-next-layer-proto

It talks about ip-address and not = ipsec-next-layer-ip-address? Simiarly it
talks about = local-ports. So why not just call this proto or protocol ?

[Authors] The label "protocol" is widely used in the = model. It is just a way to identify the context.


Is selector-priority needed? Can the ts-number = not be specified to be "lower
numer is higher priority=E2=80= =9D ?

[Authors] It could (in fact, it is ordered by = user, which means the controller in our case)
In = fact, RFC4301 only specifies that "An SPD is an ordered list of = entries"




Why do we have = security-protocol? If you are considered about small footprints,
clearly you would implement only ESP and use ESP-NULL if = encryption is not
needed. And simply not implement AH = (which is already optional not mandatory
to implement for = IPsec). Also, this assumes IPCOMP, which has its own complexity,
would also not be used. I think a case for AH would be very = weak, while a case
for IPCOMP could be made. I'd recommend = only supporting ESP, at which point
you would not need = this parameter, or you could keep it for completeness
sake = even though it could only have one value "esp". This would also allow
an updated ESP or some ESPlite to be used in the future if = such a thing would
be = developed.

[Authors] We agree with only make use of =  ESP and ESP-NULL.

If we only go with AEAD = algorithms, then the whole ah-algorithms part can be
removed= too. And esp-algorithms could be changed to only contain = esp-encryption
(or could be renamed aead-algorithm)

[Authors] = Same as before


I see spd-mark = but not spd-security-context  (see my Labeled IPsec draft)


[Authors]

Regarding the = XFRM mark element and the security context described in the draft, = if there is a clear use case for these elements we can keep = them in the model.


I found the = names in lifetimes confusing. "added" really means maxlife and
"current" really means maxidle I think? So I think the names = would be
clearer as "time", "idle", "packets", "bytes". I = think the time and idle
units of uint64 could be narrowed = down if the yang language allows some
kind of timestamp = type.

[Authors] We have made use of the terminology = in RFC2367, Section 2.3.2. Indeed the yang model has = a timestamp (RFC 6991). We can add "time", "idle", "packets" = and "bytes=E2=80=9D.


I = am missing an entry for TFC (confidentiality, padding)

ok, It could be included in the model (for IKE = and IKE-less cases.


I also see no entry for = IPCOMP algorithm. But I am fine with not allowing
IPCOMP = at all :)

[Authors] Agree


I = am missing replay window parameters ?


Currently, the replay-window parameter is defined = only in the SAD configuration for IKE-less case. It should be = also included in the SPD configuration for IKE case.

Do you think we should include the = additional replay-seq, replay-oseq, replay-seq-hi, = replay-oseq-hi parameters for IKE-less case?


I don't know what statefulfragCheck is ?


Whether or not to allow IKE fragmentation. = (Libreswan/Strongwan support that, valid values are are yes, (the = default), no or force).

Probably a better name = for this?


Section 6.2

See Section 6.1 comments.

Why = are the encap entries in 6.2 and not 6.1 ?

[Authors] = For case 2 (IKE-less) espencap is configured like part of the SA, = not the policy. For IKE case encap is part of the = IKEv2 configuration (section 6.4)


What is the "state?" entry ?

[Authors] state is of type sa-state (Larval, = Mature, Dying, Dead).
These states can be useful when = the model is used by the SC to recover SA's state data from the = node or when modelling the sadb_expire message


Why is rpcs: only here?


[Authors] You are right, rpcs should be in a = 6.5 section. Note that notifications are defined for SAD and = SPD in IKE-less case and that there are not notifications for = IKE and PAD models


I would not = use minbits, maxbits. All modern ciphers, especially AEAD, are fixed key = sizes. Make it a list of key sizes

[Authors]Agree


I seem to miss = the AEAD IV values ?


[Authors] This container = represents information about the algorithm supported, we assume = that AEAD algorithms can be also represented here (AES_GCM, = AES_CCM, CHACHA20-POLY1305, ....). IV values are not represented = here.

Possibly the truncation values ?

[Authors] = For auth-trunc values, we will include that in container ah-sa = unless AH is finally removed.


Section 6.3:

I only see PSK and = RSA algorithms? No ECDSA via RFC 7427 Digital Signatures?
(no PAKE, we have two IKE PAKE's although it looks like we = want an CFRG new one)

[Authors]
See answer in Appendix = section.


Should PSK be = of type "string". Some people want to hex entry? Although those are = often written
as strings with a 0x prefix.


[Authors]
Agree


I see some CRL entries, but no OCSP entries. = Is it expected those URI's are stored within the certificates,
and the received OCSP responses will never be communicated = through this interface?

[Authors]
Agree. We can add CRL and OCSP = URLs


I see no local and remote = part, meaning that only symmetric authentication methods can be used. = IKEv2 supports
asymmetric authentication methods as well. = Especially when using EAP and sometimes with AUTHHNULL, this method
is very asymmetric. So I believe this entry needs to be split = in a local/remote auth method.

[Authors]Agree


Section = 6.4:

type-autostartup issues...

typedef type-autostartup {
=      type enumeration {
=         enum ALWAYSON { = description " ";}
=         enum INITIATE-ON-DEMAND = {description " ";}
=         enum RESPOND-ONLY = {description " ";}
     }
     description "Different types = of how IKEv2 starts the IPsec SAs";

With = libreswan we have similar keywords, and run into some interesting = issues. We found what is really needed is to
know the = current state and the connection desired state. for example, when using = ondemand and the connection is up,
it is important to know = it is up because of ondemand. So that when you receive a Delete request, = you can go back
to ondemand state. If you dont keep this = state then you cannot tell the difference between alwayson/ondemand = if
the connection is "up". Similarly, we had issues where = connections has a definition like above, but the administrator
performs an action. It is unclear if such an action is = considered a temporary override or basically a runtime update
of the configuration. So lets say we are in respondonly, and = the administrator brings the connection up. Now the other
end sends a delete. Do you assume you are in alwayson state = or in ondemand state? And if you believe alwayson, be
prepared for a war with the remote endpoint that keeps = sending deletes because it wants to be down.

[Authors] = Do you think this is something the model should consider? We mean = that, after all, behing the model we will have = an implementation (could be libreswan, strongswan etc.. that it = will deal with these aspects) It is true that we should define = clearly what ALWAYSON, INITIATE-ON-DEMAND, RESPOND-ONLY, = etc=E2=80=A6



Why is there nat-traversal and espencap. Why not just have = espencap allow to have a value of 'none=E2=80=99 ?


[Authors]
Agree

IKEv2 allows more then one oaddr  (eg multiple SOURCE = NAT IPs) but the value is not a list?

[Authors]
Agree for the IKE case.
For pfkey_v2 (setkey), it does not allow to = specify oaddr.
For xfrm, it does allow to specify = only one oaddr.
Does make it sense to allow more than = one oaddr for IKE-less case?


The terms = phase1-* should be called ike-* or ike-sa-* as phase1/phase2 is IKEv1 = terminalogy not used for IKEv2.

[Authors]Agree. We can replace phase1-* by ike-sa-* and phase2-* = by ike-child-sa-*.


Why is = combined-enc-intr needed? These are stored with the encalg entries = anyway.


[Authors]
Agree.


I see:

+--rw local
=        |   +--rw = (my-identifier-type)?

+--rw = remote
       | =   +--rw (my-identifier-type)?

I = think "my-identifier-type" should be "identifier-type". Talking about = "my" for the remote peer is very confusing.

[Authors]
Agree.


my-identifier-type does not support the value = ID_NONE from RFC 7619

[Authors]
Agree. We will include that in = the model.


Why is there = no secion for ike-lifetime-{soft|hard} ? We also have FIPS requirements = that IKE SA's cannot do more
then X bytes for Y algorithm. = And also bringing down idle IKE SA's etc.

[Authors]We can include a soft/hard lifetime (seconds) for = IKE SA. What does it means a soft/hard lifetime (bytes) = for IKE SA. It is implemented in = current distributions?


I = think "added", "used", "bytes" "packets" should be called lifetime, = idletime, maxbytes and maxpackets

[Authors]See comment above.


The timestamp values "added" and "used" could have a better = type than uint64, eg unix epoch of unixtime or something?

[Authors]Current implementations make use of __u64 or = even uint32_t. Anyway, we can modify the type. What do = you propose?


the term = ike-stats was confusing me. I thought at first these were the global IKE = statistics, like how many tunnels
are up, how many errors = received, but it turned out to be the state of a singe IKE SA. So = perhaps ike-sa-state is a
better term? =

[Authors]
Agree.

IKE state I expect things = like SPIi and SPIr as listed here.

[Authors]
global IKE statictics = could be obtained by the SC through the ike-sa-state info for each = IKE SA.


I am not sure why there are = three nat-* bools instead of one value representing the nat-state? = Possibly because we
use a number of bits to indicate which = of the NAT properties are set, and you don't do this kind of bit mapping = in
yang?


[Authors] That could be represented with uint8 = and using three bits , is that what you mean? We thought = was clearer to have three booleans.

I dont see an entry for "latest IKE SA". We have that in = libreswan. You can have multiple IKE SA's when rekeying,
and= the older one is just lingering to die. Any operations such as = informational requests, dpd/liveness probes
should only be = done with the "latest IKE SA".  However, this is kind of a state on = the IKE node, so I am not
sure if this belongs in the yang = model or not.

[Authors] Is there any scenario where the SC is able to = deal with this information for the IKE case? If so, we can try to model = that like state data. 


I = see a total SA's and halfopen SA's but I don't see anything related to = anti-DDOS cookies. Eg the number of half
open SA's before = enabling cookies. Perhaps add half-open-cookies-treshhold ?


[Authors]
Several parameters can be = configured here:
- half-open-threshold: number of half = open IKE SAs
- half-open-cookies-threshold: number of half = open IKE SAs with cookie activated
- half-open-timer: = timeout in seconds for connecting IKE SAs.

Best regards, Gabi.



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es
=

= --Apple-Mail=_18FCA7D5-4A20-491D-B0E6-3AE1029FBA50-- From nobody Tue Dec 4 10:18:47 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F27130E9D; Tue, 4 Dec 2018 10:18:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-ipsecme-split-dns@ietf.org, David Waltermire , ipsecme-chairs@ietf.org, david.waltermire@nist.gov, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154394752013.4979.13588546042247755495.idtracker@ietfa.amsl.com> Date: Tue, 04 Dec 2018 10:18:40 -0800 Archived-At: Subject: [IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-split-dns-16: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2018 18:18:40 -0000 Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-split-dns-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my DISCUSS. I still don't love this idea / solution, but after asking the DNSOP list for review (https://www.ietf.org/mail-archive/web/dnsop/current/msg24835.html) and getting feedback (https://www.ietf.org/mail-archive/web/dnsop/current/msg24881.html) I've been persuaded that the benefits (with the mitigations) outweigh the risks. ---- Original DISCUSS position ---- I hope I'm just missing something obvious here, but this seems like it may cause a significant security issue. Lots of "regular" users use VPNs for access the Internet, either to bypass censorship / content restrictions, or to improve their privacy. These are not "corporate" / "enterprise" VPNs, but rather public ones - and sometimes they are run by people I wouldn't entirely trust. What is to stop one of these VPN providers setting: INTERNAL_DNS_DOMAIN(www.paypal.com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) or, better yet: INTERNAL_DNS_DOMAIN(com) INTERNAL_DNSSEC_TA(43547,8,1,B6225AB2CC613E0DCA7962BDC2342EA4...) and so being able to spoof DNSSEC for paypal.com / all of .com? This is especially worrying if something like DANE is ever deployed... The draft *does* says: "Other generic or public domains, such as top-level domains, similarly SHOULD NOT be whitelisted." - this doesn't really answer the above. 1: It is increasingly hard to know what is a "real" TLD (.internal? .bank? .home?) 2: How do I programatically tell if www.foo.net is a "public domain"? What is a public domain anyway? How is an implementer supposed to address this? It also says: "Any updates to this whitelist of domain names MUST happen via explicit human interaction to prevent invisible installation of trust anchors." Is my auntie really expected (or competent) to understand what "Your VPN provider, TrustVPN wants to whitelist com. Do you want to allow this? [Y/N]" means? I'm hoping that I'm completely misunderstanding how the INTERNAL_DNSSEC_TA bit works. Also, some of the DNS behavior is handwavey - I think that the document really should be reviewed by DNSOP, but will leave it to Eric to make that call. -------------- This section: " The content of INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA may be passed to another (DNS) program for processing. As with any network input, the content SHOULD be considered untrusted and handled accordingly." feels a bit handwavey. Are there currently any DNSSEC validating clients which can easily take a targeted TA for a specific domain / set of domains? I’m also not quite sure how this interacts with delegations. E.g: example.com 600 IN NS ns01.internal.example And then INTERNAL_DNS_DOMAIN(internal.example) — if the client runs a local recursive, does it need to send the query to ns01 though the VPN or not? From nobody Wed Dec 5 13:29:41 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D982812D4E7; Wed, 5 Dec 2018 13:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 xUf6_dIdqyVh; Wed, 5 Dec 2018 13:29:37 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E30130E95; Wed, 5 Dec 2018 13:29:36 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 7DEF7E86E6890; Wed, 5 Dec 2018 21:29:31 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Dec 2018 21:29:32 +0000 Received: from SJCEML521-MBB.china.huawei.com ([169.254.6.33]) by SJCEML701-CHM.china.huawei.com ([169.254.3.198]) with mapi id 14.03.0415.000; Wed, 5 Dec 2018 13:29:26 -0800 From: Linda Dunbar To: Yoav Nir , Gabriel Lopez CC: "i2nsf@ietf.org" , "ipsec@ietf.org WG" , Paul Wouters , Rafa Marin Lopez Thread-Topic: [I2nsf] [IPsec] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) Thread-Index: AQHUhnHCQWI/aI09rEKRAvt+rExe0aVkvROAgAv4zeA= Date: Wed, 5 Dec 2018 21:29:26 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66B1F6237@SJCEML521-MBB.china.huawei.com> References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com> In-Reply-To: <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.90] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F66B1F6237SJCEML521MBBchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2018 21:29:40 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F66B1F6237SJCEML521MBBchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsaWtlIHRoZSB0aXRsZSBvZiAg4oCcZGlzdHJpYnV0ZWQga2V5aW5n4oCdIChjYXNlIDEpIHZz IOKAnGNlbnRyYWxpemVkIGtleWluZ+KAnSAoQ2FzZSAyKS4NCg0KTGluZGENCg0KRnJvbTogSTJu c2YgW21haWx0bzppMm5zZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9hdiBOaXIN ClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI3LCAyMDE4IDQ6MzkgUE0NClRvOiBHYWJyaWVsIExv cGV6IDxnYWJpbG1AdW0uZXM+DQpDYzogaTJuc2ZAaWV0Zi5vcmc7IGlwc2VjQGlldGYub3JnIFdH IDxpcHNlY0BpZXRmLm9yZz47IFBhdWwgV291dGVycyA8cGF1bEBub2hhdHMuY2E+OyBSYWZhIE1h cmluIExvcGV6IDxyYWZhQHVtLmVzPg0KU3ViamVjdDogUmU6IFtJMm5zZl0gW0lQc2VjXSBSZXZp ZXcgb2YgZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLTAzIChTZWN0 aW9uIDEpDQoNCkEgY291cGxlIG9mIHJlbWFya3MgKHdpdGggbm8gaGF0cykNCg0KSWYgd2XigJly ZSBiaWtlc2hlZGRpbmcgdGhlIG5hbWVzLCBJIHRoaW5rIHRoZSBkaWZmZXJlbmNlIGlzIHRoYXQg aW4gb25lIGNhc2UgdGhlIHR3byBOU0ZzIGdlbmVyYXRlIHRyYWZmaWMga2V5cyBiZXR3ZWVuIHRo ZW1zZWx2ZXMsIGFuZCBpbiB0aGUgb3RoZXIgaXQgaXMgdGhlIGNvbnRyb2xsZXIgdGhhdCBnZW5l cmF0ZXMgdGhlIGtleXMgZm9yIHRoZW0uICBTbyBob3cgYWJvdXQg4oCcZGlzdHJpYnV0ZWQga2V5 aW5n4oCdIHZzIOKAnGNlbnRyYWxpemVkIGtleWluZ+KAnSwgb3IgcGVyaGFwcyDigJxhdXRvbWF0 aWMga2V5aW5n4oCdIHZzIOKAnFNETiBrZXlpbmfigJ0uDQoNCg0KQWxzbywgSSBoYXZlIGJlZW4g YXNrZWQgYnkgc29tZW9uZSBub3Qgb24gdGhpcyBsaXN0IHdoZXRoZXIgb3VyIHdvcmsgY292ZXJz IHRoZSByb2FkIHdhcnJpb3IgdXNlIGNhc2UuIEkgc2FpZCBpdCBkaWRu4oCZdCBhbmQgd29uZGVy ZWQgd2h5LiBTbyBJIGdvdCB0aGVzZSBwb2ludHM6DQoNCiAgKiAgIFJvYWQgd2FycmlvcnMgYXJl IG51bWVyb3VzIGFuZCBub3Qgd2hlcmUgdGhlIGFkbWluaXN0cmF0b3IgY2FuIGNvbmZpZ3VyZSB0 aGVtIG1hbnVhbGx5Lg0KICAqICAgQWRkaXRpb25hbGx5LCB0aGUgY29uZmlndXJhdGlvbiBvZiB3 aGF0IG5ldHdvcmtzLCBnYXRld2F5cyAoTlNGcyksIGFuZCByZXNvdXJjZXMgYSByb2FkIHdhcnJp b3IgbWF5IGFjY2VzcyAoaW4gSVBzZWMgdGVybXMsIHRoZSBTUEQgYW5kIFBBRCkgY2hhbmdlIG9m dGVuLg0KICAqICAgQmVjYXVzZSBvZiB0aGUgYWJvdmUsIHNvbWUgYXV0b21hdGljIG1ldGhvZCBv ZiBjb25maWd1cmluZyBTUEQgYW5kIFBBRCBpcyBuZWVkZWQuDQogICogICBUaGVyZSBpcyBhbHNv IHRoZSBpc3N1ZSBvZiBtdWx0aXBsZSBWUE4gZ2F0ZXdheXMgY292ZXJpbmcgc2ltaWxhciBkb21h aW5zLCBhbmQgVlBOIGdhdGV3YXlzIGJlaW5nIG92ZXJsb2FkZWQgb3IgZG93biBmb3IgbWFpbnRl bmFuY2UsIGFzIHdlbGwgYXMgbWFsZnVuY3Rpb25zIGluIHRoZSBuZXR3b3JrIGJlaGluZCB0aG9z ZSBWUE4gZ2F0ZXdheXMuIFNvIHRoZSBkZWNpc2lvbiBvbiB3aGljaCBnYXRld2F5IGEgcm9hZCB3 YXJyaW9yIHNob3VsZCB1c2UgdG8gYWNjZXNzIGEgcGFydGljdWxhciByZXNvdXJjZSBpcyBhbHNv IGEgbmF0dXJhbCBxdWVzdGlvbiB0byBhc2sgYW4gU0ROIGNvbnRyb2xsZXIuDQoNClNpbmNlIEkg dXNlZCB0byB3b3JrIGZvciBhIFZQTiB2ZW5kb3IsIEkgY2FuIHRlbGwgeW91IHdoYXQgb3VyIHBy b2R1Y3QgZGlkOg0KDQogICogICBUaGUgY3VycmVudCBjb25maWd1cmF0aW9uIHdhcyBmb3JtYXR0 ZWQgKGF1dG9tYXRpY2FsbHkgYnkgYSBtYW5hZ2VtZW50IGZ1bmN0aW9uKSBhcyBhIHRleHQgZmls ZSB0aGF0IHRoZSByb2FkIHdhcnJpb3IgZG93bmxvYWRlZCB0aHJvdWdoIHRoZSBWUE4gZ2F0ZXdh eSAodGhlIGdhdGV3YXkgZG91YmxlZCBhcyBhIHNlcnZlciBzZXJ2aW5nIHRoaXMgb25lIGZpbGUp DQogICogICBUaGUgcHJvcGVyIGdhdGV3YXkgdG8gY29ubmVjdCB0byB3YXMgZGV0ZXJtaW5lZCBi eSBwaW5naW5nIGFsbCBnYXRld2F5cyB0aGF0IHdlcmUgcG9zc2libGUgYWNjb3JkaW5nIHRvIHRo ZSBjb25maWd1cmF0aW9uIGZpbGUuDQogICogICBUaGlzIGRpZCBub3QgYWNjb3VudCBmb3IgYW55 IGludGVybmFsIG5ldHdvcmtpbmcgaXNzdWVzLg0KDQpJIGRvbuKAmXQga25vdyBpZiB0aGlzIHNo b3VsZCBiZSBwYXJ0IG9mICp0aGlzKiBlZmZvcnQsIGJ1dCB0aGVyZSBpcyBhIHVzZSBjYXNlIGZv ciByb2FkIHdhcnJpb3IgU0ROLg0KDQpZb2F2DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F66B1F6237SJCEML521MBBchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTgwMjM4NzMxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTY0MzE4ODIwNDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6ODY4Njg1MDkxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2NzY4NTU5MTQ7fQ0KQGxpc3Qg bDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBsaWtlIHRoZSB0aXRsZSBvZjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4gJm5ic3A7PC9zcGFuPuKAnGRpc3RyaWJ1dGVkIGtleWluZ+KAnSAoY2FzZSAxKSB2cyDigJxj ZW50cmFsaXplZCBrZXlpbmfigJ0gKENhc2UgMikuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TGluZGE8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBJMm5z ZiBbbWFpbHRvOmkybnNmLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPllv YXYgTmlyPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE5vdmVtYmVyIDI3LCAyMDE4IDQ6Mzkg UE08YnI+DQo8Yj5Ubzo8L2I+IEdhYnJpZWwgTG9wZXogJmx0O2dhYmlsbUB1bS5lcyZndDs8YnI+ DQo8Yj5DYzo8L2I+IGkybnNmQGlldGYub3JnOyBpcHNlY0BpZXRmLm9yZyBXRyAmbHQ7aXBzZWNA aWV0Zi5vcmcmZ3Q7OyBQYXVsIFdvdXRlcnMgJmx0O3BhdWxAbm9oYXRzLmNhJmd0OzsgUmFmYSBN YXJpbiBMb3BleiAmbHQ7cmFmYUB1bS5lcyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJ Mm5zZl0gW0lQc2VjXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1w cm90ZWN0aW9uLTAzIChTZWN0aW9uIDEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QSBjb3VwbGUgb2YgcmVtYXJrcyAod2l0aCBubyBoYXRzKTxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2XigJlyZSBiaWtlc2hl ZGRpbmcgdGhlIG5hbWVzLCBJIHRoaW5rIHRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgaW4gb25lIGNh c2UgdGhlIHR3byBOU0ZzIGdlbmVyYXRlIHRyYWZmaWMga2V5cyBiZXR3ZWVuIHRoZW1zZWx2ZXMs IGFuZCBpbiB0aGUgb3RoZXIgaXQgaXMgdGhlIGNvbnRyb2xsZXIgdGhhdCBnZW5lcmF0ZXMgdGhl IGtleXMgZm9yIHRoZW0uICZuYnNwO1NvIGhvdyBhYm91dCDigJxkaXN0cmlidXRlZCBrZXlpbmfi gJ0NCiB2cyDigJxjZW50cmFsaXplZCBrZXlpbmfigJ0sIG9yIHBlcmhhcHMg4oCcYXV0b21hdGlj IGtleWluZ+KAnSB2cyDigJxTRE4ga2V5aW5n4oCdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIEkgaGF2ZSBiZWVuIGFza2VkIGJ5 IHNvbWVvbmUgbm90IG9uIHRoaXMgbGlzdCB3aGV0aGVyIG91ciB3b3JrIGNvdmVycyB0aGUgcm9h ZCB3YXJyaW9yIHVzZSBjYXNlLiBJIHNhaWQgaXQgZGlkbuKAmXQgYW5kIHdvbmRlcmVkIHdoeS4g U28gSSBnb3QgdGhlc2UgcG9pbnRzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVs IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEg bGZvMSI+DQpSb2FkIHdhcnJpb3JzIGFyZSBudW1lcm91cyBhbmQgbm90IHdoZXJlIHRoZSBhZG1p bmlzdHJhdG9yIGNhbiBjb25maWd1cmUgdGhlbSBtYW51YWxseS48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpBZGRpdGlvbmFs bHksIHRoZSBjb25maWd1cmF0aW9uIG9mIHdoYXQgbmV0d29ya3MsIGdhdGV3YXlzIChOU0ZzKSwg YW5kIHJlc291cmNlcyBhIHJvYWQgd2FycmlvciBtYXkgYWNjZXNzIChpbiBJUHNlYyB0ZXJtcywg dGhlIFNQRCBhbmQgUEFEKSBjaGFuZ2Ugb2Z0ZW4uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KQmVjYXVzZSBvZiB0aGUgYWJv dmUsIHNvbWUgYXV0b21hdGljIG1ldGhvZCBvZiBjb25maWd1cmluZyBTUEQgYW5kIFBBRCBpcyBu ZWVkZWQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzEiPg0KVGhlcmUgaXMgYWxzbyB0aGUgaXNzdWUgb2YgbXVsdGlwbGUgVlBOIGdh dGV3YXlzIGNvdmVyaW5nIHNpbWlsYXIgZG9tYWlucywgYW5kIFZQTiBnYXRld2F5cyBiZWluZyBv dmVybG9hZGVkIG9yIGRvd24gZm9yIG1haW50ZW5hbmNlLCBhcyB3ZWxsIGFzIG1hbGZ1bmN0aW9u cyBpbiB0aGUgbmV0d29yayBiZWhpbmQgdGhvc2UgVlBOIGdhdGV3YXlzLiBTbyB0aGUgZGVjaXNp b24gb24gd2hpY2ggZ2F0ZXdheSBhIHJvYWQgd2FycmlvciBzaG91bGQgdXNlDQogdG8gYWNjZXNz IGEgcGFydGljdWxhciByZXNvdXJjZSBpcyBhbHNvIGEgbmF0dXJhbCBxdWVzdGlvbiB0byBhc2sg YW4gU0ROIGNvbnRyb2xsZXIuPG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNpbmNlIEkgdXNlZCB0byB3b3JrIGZvciBhIFZQTiB2ZW5k b3IsIEkgY2FuIHRlbGwgeW91IHdoYXQgb3VyIHByb2R1Y3QgZGlkOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpUaGUgY3VycmVudCBjb25maWd1cmF0aW9uIHdhcyBm b3JtYXR0ZWQgKGF1dG9tYXRpY2FsbHkgYnkgYSBtYW5hZ2VtZW50IGZ1bmN0aW9uKSBhcyBhIHRl eHQgZmlsZSB0aGF0IHRoZSByb2FkIHdhcnJpb3IgZG93bmxvYWRlZCB0aHJvdWdoIHRoZSBWUE4g Z2F0ZXdheSAodGhlIGdhdGV3YXkgZG91YmxlZCBhcyBhIHNlcnZlciBzZXJ2aW5nIHRoaXMgb25l IGZpbGUpPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPg0KVGhlIHByb3BlciBnYXRld2F5IHRvIGNvbm5lY3QgdG8gd2FzIGRldGVy bWluZWQgYnkgcGluZ2luZyBhbGwgZ2F0ZXdheXMgdGhhdCB3ZXJlIHBvc3NpYmxlIGFjY29yZGlu ZyB0byB0aGUgY29uZmlndXJhdGlvbiBmaWxlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NClRoaXMgZGlkIG5vdCBhY2NvdW50 IGZvciBhbnkgaW50ZXJuYWwgbmV0d29ya2luZyBpc3N1ZXMuPG86cD48L286cD48L2xpPjwvdWw+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBrbm93IGlm IHRoaXMgc2hvdWxkIGJlIHBhcnQgb2YgKnRoaXMqIGVmZm9ydCwgYnV0IHRoZXJlIGlzIGEgdXNl IGNhc2UgZm9yIHJvYWQgd2FycmlvciBTRE4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvYXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F66B1F6237SJCEML521MBBchi_-- From nobody Thu Dec 6 02:14:17 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E333D130E23; Thu, 6 Dec 2018 02:14:15 -0800 (PST) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Pu-l5Wj0VnvZ; Thu, 6 Dec 2018 02:14:11 -0800 (PST) Received: from xenon43.um.es (xenon43.um.es [IPv6:2001:720:1710:601::43]) by ietfa.amsl.com (Postfix) with ESMTP id 20A48130DCE; Thu, 6 Dec 2018 02:14:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id C96D521703; Thu, 6 Dec 2018 11:14:08 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qf0OPW4UJpLa; Thu, 6 Dec 2018 11:14:08 +0100 (CET) Received: from [192.168.1.36] (23.red-88-10-88.dynamicip.rima-tde.net [88.10.88.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon43.um.es (Postfix) with ESMTPSA id 74EA921730; Thu, 6 Dec 2018 11:14:05 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_541542A4-482B-4037-9C10-A3C4BA557473" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F66B1F6237@SJCEML521-MBB.china.huawei.com> Date: Thu, 6 Dec 2018 11:06:44 +0100 Cc: Rafa Marin Lopez , Yoav Nir , Gabriel Lopez , "i2nsf@ietf.org" , "ipsec@ietf.org WG" , Paul Wouters Message-Id: References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> <3415DDC9-ED45-462F-B561-E48773E404FB@um.es> <37F4E2D9-47C3-450C-B1E8-649FC901DA82@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F66B1F6237@SJCEML521-MBB.china.huawei.com> To: Linda Dunbar X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 10:14:16 -0000 --Apple-Mail=_541542A4-482B-4037-9C10-A3C4BA557473 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Linda: I still have doubts about these terms. In both cases, there is a = centralized key distribution: with IKE , the controller may distribute = key material (i.g. the PSK for IKE authentication) or some = certification. Without IKE (case 2) the centralized key distribution = refers to IPsec SAs.=20 Moreover the word IKE is important in case 1 , only IKEv2 is considered.=20= Best Regards. > El 5 dic 2018, a las 22:29, Linda Dunbar = escribi=C3=B3: >=20 > I like the title of =E2=80=9Cdistributed keying=E2=80=9D (case 1) vs = =E2=80=9Ccentralized keying=E2=80=9D (Case 2). > =20 > Linda > =C2=A0 <> > From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Tuesday, November 27, 2018 4:39 PM > To: Gabriel Lopez > Cc: i2nsf@ietf.org; ipsec@ietf.org WG ; Paul Wouters = ; Rafa Marin Lopez > Subject: Re: [I2nsf] [IPsec] Review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1) > =20 > A couple of remarks (with no hats) > =20 > If we=E2=80=99re bikeshedding the names, I think the difference is = that in one case the two NSFs generate traffic keys between themselves, = and in the other it is the controller that generates the keys for them. = So how about =E2=80=9Cdistributed keying=E2=80=9D vs =E2=80=9Ccentralized = keying=E2=80=9D, or perhaps =E2=80=9Cautomatic keying=E2=80=9D vs =E2=80=9C= SDN keying=E2=80=9D. > =20 > =20 > Also, I have been asked by someone not on this list whether our work = covers the road warrior use case. I said it didn=E2=80=99t and wondered = why. So I got these points: > Road warriors are numerous and not where the administrator can = configure them manually. > Additionally, the configuration of what networks, gateways (NSFs), and = resources a road warrior may access (in IPsec terms, the SPD and PAD) = change often. > Because of the above, some automatic method of configuring SPD and PAD = is needed. > There is also the issue of multiple VPN gateways covering similar = domains, and VPN gateways being overloaded or down for maintenance, as = well as malfunctions in the network behind those VPN gateways. So the = decision on which gateway a road warrior should use to access a = particular resource is also a natural question to ask an SDN controller. > =20 > Since I used to work for a VPN vendor, I can tell you what our product = did: > The current configuration was formatted (automatically by a management = function) as a text file that the road warrior downloaded through the = VPN gateway (the gateway doubled as a server serving this one file) > The proper gateway to connect to was determined by pinging all = gateways that were possible according to the configuration file. > This did not account for any internal networking issues. > =20 > I don=E2=80=99t know if this should be part of *this* effort, but = there is a use case for road warrior SDN. > =20 > Yoav --Apple-Mail=_541542A4-482B-4037-9C10-A3C4BA557473 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Linda:

I= still have doubts about these terms. In both cases, there is a = centralized key distribution: with IKE , the controller may distribute = key material (i.g. the PSK for IKE authentication) or some = certification. Without IKE  (case 2) the centralized key = distribution refers to IPsec SAs. 

Moreover the word IKE is important in = case 1 , only IKEv2 is considered. 

Best Regards.


El 5 dic 2018, a las 22:29, = Linda Dunbar <linda.dunbar@huawei.com> escribi=C3=B3:

I like the title of  =E2=80=9Cdistrib= uted keying=E2=80=9D (case 1) vs =E2=80=9Ccentralized keying=E2=80=9D = (Case 2).
 
Linda
 
From: I2nsf [mailto:i2nsf-bounces@ietf.org] On Behalf = Of Yoav Nir
Sent: Tuesday, November 27, 2018 = 4:39 PM
To: Gabriel Lopez <gabilm@um.es>
Cc: i2nsf@ietf.org; ipsec@ietf.org WG <ipsec@ietf.org>; Paul = Wouters <paul@nohats.ca>; Rafa Marin Lopez <rafa@um.es>
Subject: Re: [I2nsf] [IPsec] Review = of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Section 1)
 
A couple of remarks (with no hats)
 
If we=E2=80=99re bikeshedding the names, = I think the difference is that in one case the two NSFs generate traffic = keys between themselves, and in the other it is the controller that = generates the keys for them.  So how about =E2=80=9Cdistributed = keying=E2=80=9D vs =E2=80=9Ccentralized keying=E2=80=9D, or perhaps = =E2=80=9Cautomatic keying=E2=80=9D vs =E2=80=9CSDN keying=E2=80=9D.
 
 
Also, I have been asked by someone not on this list = whether our work covers the road warrior use case. I said it didn=E2=80=99= t and wondered why. So I got these points:
  • Road warriors are numerous and not where the = administrator can configure them manually.
  • Additionally, the configuration = of what networks, gateways (NSFs), and resources a road warrior may = access (in IPsec terms, the SPD and PAD) change often.
  • Because of the above, some automatic method of configuring SPD = and PAD is needed.
  • There is also the issue of multiple VPN gateways = covering similar domains, and VPN gateways being overloaded or down for = maintenance, as well as malfunctions in the network behind those VPN = gateways. So the decision on which gateway a road warrior should use to = access a particular resource is also a natural question to ask an SDN = controller.
 
Since I used to work for a VPN vendor, I = can tell you what our product did:
  • The current configuration was = formatted (automatically by a management function) as a text file that = the road warrior downloaded through the VPN gateway (the gateway doubled = as a server serving this one file)
  • The proper gateway to connect to = was determined by pinging all gateways that were possible according to = the configuration file.
  • This did not account for any internal networking = issues.
 
I don=E2=80=99t know if this should be = part of *this* effort, but there is a use case for road warrior SDN.
 
Yoav

= --Apple-Mail=_541542A4-482B-4037-9C10-A3C4BA557473-- From nobody Thu Dec 6 14:48:59 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70CB4131148 for ; Thu, 6 Dec 2018 14:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 llIqI21x0v2L for ; Thu, 6 Dec 2018 14:48:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD44130F53 for ; Thu, 6 Dec 2018 14:48:55 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0EEAA20008 for ; Thu, 6 Dec 2018 17:48:47 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8A78BE9E; Thu, 6 Dec 2018 17:48:52 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8840F144 for ; Thu, 6 Dec 2018 17:48:52 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 22:48:58 -0000 --=-=-= Content-Type: text/plain I'm watching the video (in five minute intervals for unexplained reasons... it seems like I've been watching this video for days). I want to +1 Dan: we need a balanced PAKE. I sincerely wish Tero was right: that there was no excuse not to use digital signatures for good site-to-site, even between companies. The reason we don't have this is because digital signatures keep getting confused with PKIs, something John Gilmore realized 20 years ago. I think we should ask the CFRG to pick a single balanced PAKE for us. If the CFRG want to pick another PAKE for other purposes, that's fine. I think that letting CFRG pick two PAKEs for different purposes might free up the log jam? I also heard Dan offer to remain silent, and I just wanted to get that on the record. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwJp1QACgkQgItw+93Q 3WWpeAf8D9VcZoIv3JPzmeuVOaYKxQacqy2GRUxMUfTSil3oUMaxvtlPmB0THjhu r7KbVLRzYPJ0fuOIibPFqzjlX6QjoyOuvfGSyL6tG/zyg/RAd9txqvQFbL5cFYTp QbWcR0pwZCHdYVQUgB5Y5h87erxMWGLfPDJoU4zsznsZbgWpChxiy/dKekImQCYg hTpw2s/tp+pmpX55quNW0/TWSJusIk2LJZhYPj24ClCH2w7kDJAUz5X/igd75Lrf nYOqL+Qb1/0BL/939+1PVhOIJcFzFHnWADZ9CZ0ris4l/gTA/bdfsWkpiKlcA16y kvmQruMHC+irEQ9Vp4CxFpvOchkKEA== =dKG5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 6 15:27:16 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CE5131225 for ; Thu, 6 Dec 2018 15:27:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 n_tuJgrlk42b for ; Thu, 6 Dec 2018 15:27:10 -0800 (PST) Received: from catfish.maple.relay.mailchannels.net (catfish.maple.relay.mailchannels.net [23.83.214.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08EBA130E5A for ; Thu, 6 Dec 2018 15:27:09 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 423193E34AA; Thu, 6 Dec 2018 23:27:09 +0000 (UTC) Received: from pdx1-sub0-mail-a36.g.dreamhost.com (unknown [100.96.33.121]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E551F3E3B4F; Thu, 6 Dec 2018 23:27:08 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a36.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Thu, 06 Dec 2018 23:27:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Callous-Tangy: 7a0c67df616533a2_1544138829109_2518283362 X-MC-Loop-Signature: 1544138829108:3892669013 X-MC-Ingress-Time: 1544138829108 Received: from pdx1-sub0-mail-a36.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a36.g.dreamhost.com (Postfix) with ESMTP id 79D1D8189E; Thu, 6 Dec 2018 15:27:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=+OO/ojWg5VMLau HsQQCbsBnNhf8=; b=jpM8PNeER8+BeKxEdgmJzjqE7EsWz4DU4Eh4pQMu+WY4Ek E/BRAbzYym2+L4ZQalkANFe5fQRKZNyFnGV7OhVggNJ/JnyPUGr9HStE0paSrsCN hTIhJ7TGbqGTwZoldk7YVu6My74tpMGNuVhqsiTI8QQCsCCWdVRz/gIA6zp3g= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 6F9C88189C; Thu, 6 Dec 2018 15:27:06 -0800 (PST) Date: Thu, 6 Dec 2018 17:27:04 -0600 X-DH-BACKEND: pdx1-sub0-mail-a36 From: Nico Williams To: Michael Richardson Cc: ipsec@ietf.org Message-ID: <20181206232532.GQ15561@localhost> References: <25207.1544136532@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25207.1544136532@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudefkedgudduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2018 23:27:15 -0000 On Thu, Dec 06, 2018 at 05:48:52PM -0500, Michael Richardson wrote: > I'm watching the video (in five minute intervals for unexplained > reasons... it seems like I've been watching this video for days). Which video? > I think we should ask the CFRG to pick a single balanced PAKE for us. They've done so! https://tools.ietf.org/html/draft-irtf-cfrg-spake2 That specifies one non-augmented, and one augmented PAKE. I think the I-D is close to ready to publish. As it happens I sent in some comments this past weekend. Nico -- From nobody Fri Dec 7 19:00:19 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1FB131072 for ; Fri, 7 Dec 2018 19:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 KzbnuesmeHjJ for ; Fri, 7 Dec 2018 19:00:14 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B7B12F295 for ; Fri, 7 Dec 2018 19:00:14 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C78E20008; Fri, 7 Dec 2018 22:00:06 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D84B91C5; Fri, 7 Dec 2018 22:00:11 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D52BF54; Fri, 7 Dec 2018 22:00:11 -0500 (EST) From: Michael Richardson To: Nico Williams cc: ipsec@ietf.org In-Reply-To: <20181206232532.GQ15561@localhost> References: <25207.1544136532@localhost> <20181206232532.GQ15561@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Dec 2018 03:00:18 -0000 --=-=-= Content-Type: text/plain Nico Williams wrote: > > I'm watching the video (in five minute intervals for unexplained > > reasons... it seems like I've been watching this video for days). > > Which video? The video of ipsecme from IETF103. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwLM7sACgkQgItw+93Q 3WXTCAf/eikQVpthkOw6TvBLRSLJkjf+W2IwfPf++RQqtrk/5saRB5MrM9/KhwmI 1eKKY+knOVDBRZtwqMDzC3RBtQqJ9SK6a0r+AWgp64pIfRft27hhmF7eKlFyNtua AwEfLu8v0LgrqPVrH4QvxJcsUrZl1LmtBYdivLI77Pe43TbnL/3oL76zvzM76Odl wm9dIJAK+HqAi5wIkcmu683vF4bp9A5HGlrN/kHzMd1fKT23E/dtWPRqEOrK5aja NXrkNrkMuSbvN3DAsM6MlF0E2I4o7m5mC6cLaVFgjoSWxhq0rf809qqryv6WcdiW JvE8gqzR+W3wHlrgRWlXYgRE5ibqZA== =s7Tg -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 10 00:09:38 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AC3130EB7 for ; Mon, 10 Dec 2018 00:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NKPJdtexk7dd for ; Mon, 10 Dec 2018 00:09:35 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32B38130EB0 for ; Mon, 10 Dec 2018 00:09:35 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id s5-v6so8691584ljd.12 for ; Mon, 10 Dec 2018 00:09:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=EFLg6UO2HOxe53cICj2RRY3OZ6i+5aT46a5bynWxYX8=; b=G3dYZmNswPwK4lejtd3B77nPP9bFrO85BycJISV67OPKdXRDicK+iKPK4PGdwASj0m +3wddBL9m0GRtmY5QNCdjLfBh4MpAxSL1NTk+rl5L4ohhUVBXY3GRez/GNGLW38OPZ2f lhXv4A87cMv0y0eljWRQyddxutkSw5tdQC3Xib9bZrw7Fo6wG5Mb7DEn8lTJNmUpaiVr U7VhgEjYArSqJTCHIF2gZJq9AoJzw/Ua0hKjvxOfyYJBVQnUdA/QsltFQnwRxf3nd+JH /oC6C7cZoDxhCIHharmeUc48vdjwW/zTFfFmq/ZDYaj9YHaQeIfM/F08IP+gbQvHUVVl EPLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=EFLg6UO2HOxe53cICj2RRY3OZ6i+5aT46a5bynWxYX8=; b=WZL7eT6nXFT+d3TaZlGIbQROOu1koj/ObjX8eh2ZHHXPmfYDK++Jpg2j+MfnPcLYl7 x00eFZ7vrwTkLjzzvQyQWAZai3q46k1Bk9h1H/yhut2HxlQwWtjsT/w7kz274jPELPrw ysPb4POglW8xCcuju7zUk2PyXlhXaevixcsRGsCOLBljR6J3vb3xJEf2Hn77VXFzKBp5 W91/93P9S1aPVrR2JXEyg/PgldG9oQC3OytrWZR59SISoQxH0EHGLQ4DyZ+OysHv+EWS QCraV+X4TA4BewS7Jn//Pl0w6hItCkW5memH6LGenm7C0ePtxE/oI7ck51pDYsNVUaRB wy/w== X-Gm-Message-State: AA+aEWak+AMjt5WDXsG3oNfIXUTU1NpzyiQQHBEM4K6NI1GrY8aswObh dxuO/KQMtwtZ7S8s8JUr1TN22Icl X-Google-Smtp-Source: AFSGD/WTtwaWaJzlVJmtW/P6SKR3La20YyWvSqatWBw0nQWpKtQG7kkfKepSaGZ+1RkKesQXW9kNHg== X-Received: by 2002:a2e:b00a:: with SMTP id y10-v6mr6190254ljk.109.1544429372926; Mon, 10 Dec 2018 00:09:32 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s62sm1115786lfg.34.2018.12.10.00.09.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Dec 2018 00:09:32 -0800 (PST) From: "Valery Smyslov" To: "'Nico Williams'" , "'Michael Richardson'" Cc: References: <25207.1544136532@localhost> <20181206232532.GQ15561@localhost> In-Reply-To: <20181206232532.GQ15561@localhost> Date: Mon, 10 Dec 2018 11:09:25 +0300 Message-ID: <026501d4905f$aacf9250$006eb6f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJjEIcGzPEj/22sYW2hroPcukYuWAJuFVfupEcsIDA= Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 08:09:37 -0000 Hi Nico, > > I think we should ask the CFRG to pick a single balanced PAKE for us. > > They've done so! Not so sure. In Bangkok the CFRG just decided to start the process of selecting "one or more" (that after discussion turned out into "zero or more") recommended PAKE(s). Regards, Valery. > https://tools.ietf.org/html/draft-irtf-cfrg-spake2 > > That specifies one non-augmented, and one augmented PAKE. > > I think the I-D is close to ready to publish. As it happens I sent in > some comments this past weekend. > > Nico > -- > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Dec 10 00:22:59 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7321E130F00 for ; Mon, 10 Dec 2018 00:22:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 PtM_SMDeXj8D for ; Mon, 10 Dec 2018 00:22:56 -0800 (PST) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9DD0130EFF for ; Mon, 10 Dec 2018 00:22:55 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id z13so7276010lfe.11 for ; Mon, 10 Dec 2018 00:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:content-language:thread-index; bh=qVcoIlwn4e4Mk8RD13cS+bsCir/O+bBOdzaBEJlWFCM=; b=g2JuBk3kd5kkLB7B+NBE+jdnLaEU3ibzF24UyHoREjIUYUgOtMaZu8jrshVchsXC1l GmKibjA4ywupf0Ys+XEPLbl55B+vz6DoDwtqsseTIBsNzcZR04Es/CHujUGYEWZjnw2u cVMijBxPQv32N8O8HnYh39jeMRUJ+XCkLrnOXrJJM3wcTAPahOckNZ75gNIz9nPvTZw2 pb+8NpKVkAjH2kwtxmRce7xIq/A1J5c67DmaabNgXrwtOmXYJWhhbBZcDNHRPwaVLhSl X1Yb3PU519EpBtqRSnO4ie+WoauO8DorJiNUT1mNhYxlzS8rheMrcoUM7bi9wtjbjMoD RQnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=qVcoIlwn4e4Mk8RD13cS+bsCir/O+bBOdzaBEJlWFCM=; b=pKjB7OYl92hTY2SFWxXgboAKC1/fwVSiIPimPenao0RIclEj1ojAruZgLLTRO7TOR8 7wx5Wtm14C+0ll0aSW5n3nF20YgZbNeeJbuuLmM0UpMz/1NFkyMVlQgCGlTgxgqDhLlv 1dPGYHyc4j2J0f5hvEOc0O6hDpyPz8vNCPpgH4iPYS2txcr4CxZfmojnNe46chW9DIOC EcFxcitHxHtsuz6x0YTGL5TBdag6qGaAbBsH41Hrl8+EZZa2wvMNPgVWMpSQKZi30a97 YmNS2tVYuTxl/EHKfThgvG1doczwauahn2hMXVeeTih3/XSKmtSfiyr+juglmp3STeo1 Ys3Q== X-Gm-Message-State: AA+aEWZ4UQzG7enLJwQiSdpMN7FSXRNA+nDVy3QZ/FlV8MJV7MFsptf4 ihBds5dUun/dBX72edxQPQquwFPI X-Google-Smtp-Source: AFSGD/XIyh4RG809jQF3ytnKFMvjBVc4P3k4frllon0lBA1fyx7D50B1GLA/dYJJNr2V8mHtyk0sdQ== X-Received: by 2002:a19:1f54:: with SMTP id f81mr2133110lff.153.1544430173538; Mon, 10 Dec 2018 00:22:53 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k11-v6sm2055068ljk.40.2018.12.10.00.22.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Dec 2018 00:22:52 -0800 (PST) From: "Valery Smyslov" To: "'Michael Richardson'" , References: <25207.1544136532@localhost> In-Reply-To: <25207.1544136532@localhost> Date: Mon, 10 Dec 2018 11:22:46 +0300 Message-ID: <026601d49061$8809ad30$981d0790$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJjEIcGzPEj/22sYW2hroPcukYuWKRanpIg Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 08:22:58 -0000 Hi Michael, > I'm watching the video (in five minute intervals for unexplained > reasons... it seems like I've been watching this video for days). > > I want to +1 Dan: we need a balanced PAKE. > > I sincerely wish Tero was right: that there was no excuse not to use digital > signatures for good site-to-site, even between companies. The reason we > don't have this is because digital signatures keep getting confused with > PKIs, something John Gilmore realized 20 years ago. > > I think we should ask the CFRG to pick a single balanced PAKE for us. Why do you think balanced PAKE is more appropriate for us than augmented? > If the CFRG want to pick another PAKE for other purposes, that's fine. > I think that letting CFRG pick two PAKEs for different purposes might > free up the log jam? They've just announced in Bangkok a desire to start the process of selecting "zero or more" recommended PAKE(s) for IETF community. I believe IPsec is included :-) Another problem with PAKE is that it must be integrated into IKE somehow. EAP definitely can be used for this, but it's a bit expensive from protocol point of view. We also have RFC 6467, but it's Informational and I'm not sure it's widely supported. And while the RFC 6467 framework is flexible enough, it is still not clear for me if it can accommodate PAKEs like OPAQUE... Regards, Valery. > I also heard Dan offer to remain silent, and I just wanted to get that > on the record. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | network architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > From nobody Mon Dec 10 15:00:25 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C701312F5 for ; Mon, 10 Dec 2018 15:00:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 7GhBx37rc3NH for ; Mon, 10 Dec 2018 15:00:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE671312F4 for ; Mon, 10 Dec 2018 15:00:20 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5380920072; Mon, 10 Dec 2018 18:00:12 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1BFC0E15; Mon, 10 Dec 2018 18:00:18 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1935E9D9; Mon, 10 Dec 2018 18:00:18 -0500 (EST) From: Michael Richardson To: "Valery Smyslov" cc: ipsec@ietf.org In-Reply-To: <026601d49061$8809ad30$981d0790$@gmail.com> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:00:23 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > > I'm watching the video (in five minute intervals for unexplained > > reasons... it seems like I've been watching this video for days). > > > > I want to +1 Dan: we need a balanced PAKE. > > > > I sincerely wish Tero was right: that there was no excuse not to use digital > > signatures for good site-to-site, even between companies. The reason we > > don't have this is because digital signatures keep getting confused with > > PKIs, something John Gilmore realized 20 years ago. > > > > I think we should ask the CFRG to pick a single balanced PAKE for us. > > Why do you think balanced PAKE is more appropriate for us than augmented? Because I share Paul's view that the PSKs we care about are generally identical in both directions, and this use is primarily about site-to-site inter-company VPNs. This is note for road-warrier accesss. I would prefer that the PAKE method was not wrapped in EAP. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwO8AEACgkQgItw+93Q 3WX5Pwf+KwZOdSS+TYcDqPqAcBte/O+e229xcCSeU0CT31ryrM8+juwaTHtlyzRi Vw/KrI2V2ups6gahBAtpXe2YewkU7DOhtjQ3v2hvQhX/Qtc9JwJCEfk3oG8ACx+e L6Xaa9cKZYpxeATdC8xinUyaWcjd5DOT1F14qWcLduU5N+jeARsIiWU6Ya+NvuYL 55spkVctLE7griTmiJGDp+6v17oS8dWvczEtYomgMe4K43EJ9apgEQWCZO4JdBm+ jxWgI0xP8DIe2rkQ5ucUZwQiV8mmFlonBqpR6JLjQqE3RW+Tuvm49f7//Qf5NjM9 lvMCybKyrSqBYwZZCRrVnLB5IUDkuQ== =0z21 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 10 15:12:48 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C2113130B for ; Mon, 10 Dec 2018 15:12: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 nRcogw8a56Ua for ; Mon, 10 Dec 2018 15:12:46 -0800 (PST) Received: from ostrich.birch.relay.mailchannels.net (ostrich.birch.relay.mailchannels.net [23.83.209.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C632C131309 for ; Mon, 10 Dec 2018 15:12:45 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id B488B283149; Mon, 10 Dec 2018 23:12:44 +0000 (UTC) Received: from pdx1-sub0-mail-a45.g.dreamhost.com (unknown [100.96.19.78]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 51FD42831C1; Mon, 10 Dec 2018 23:12:44 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a45.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 10 Dec 2018 23:12:44 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Whispering-Occur: 05d634fb69f11821_1544483564554_1303147066 X-MC-Loop-Signature: 1544483564554:4113991228 X-MC-Ingress-Time: 1544483564553 Received: from pdx1-sub0-mail-a45.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTP id 07472807BE; Mon, 10 Dec 2018 15:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=NF9Ya98jWHmT2O Cok0mI6HTVvIU=; b=kMgR7w4RTmbh97MaI3vWWwVDhZ7x9RQq5ntxJPEiDDtF2q ldIlAdijVT93HArn7Tppx5KXWvYAeDlwR622PrbCC67U153tyZexcLWOF0ybadAw LyibUDTKPlUFBU8hYtaMG/lFgpfzPf1JJlYgCBb686GwzfeurYbC2v0PkL3Zc= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTPSA id 46E03807C2; Mon, 10 Dec 2018 15:12:42 -0800 (PST) Date: Mon, 10 Dec 2018 17:12:40 -0600 X-DH-BACKEND: pdx1-sub0-mail-a45 From: Nico Williams To: Valery Smyslov Cc: 'Michael Richardson' , ipsec@ietf.org Message-ID: <20181210231239.GB15561@localhost> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <026601d49061$8809ad30$981d0790$@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudegiedgtdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:12:47 -0000 On Mon, Dec 10, 2018 at 11:22:46AM +0300, Valery Smyslov wrote: > > I think we should ask the CFRG to pick a single balanced PAKE for us. > > Why do you think balanced PAKE is more appropriate for us than augmented? Speaking for myself rather than Michael, I think augmented is more appropriate when the key is based on a memorable password. However, but transition reasons, it's desirable to support a non-augmented PAKE with _existing_ password-derived keys. Also, even for non-password-derived symmetric keys, a PAKE automatically adds forward security, so it seems like a nice simplification to use a non-balanced PAKE in all cases where the credentials are shared secret keys. So in fact we probably want both. > > If the CFRG want to pick another PAKE for other purposes, that's fine. > > I think that letting CFRG pick two PAKEs for different purposes might > > free up the log jam? > > They've just announced in Bangkok a desire to start the process of selecting > "zero or more" recommended PAKE(s) for IETF community. > I believe IPsec is included :-) Oh? I thought the CFRG SPAKE2 I-D was further along. I'll have to ask the I-D authors and RG chairs. In any case, KITTEN WG is moving along with a Kerberos extension to use the CFRG SPAKE2 protocol -- this is past WGLC and awaiting shepherding to the IESG now. If CFRG ultimately picks a different PAKE, or no PAKE, that could be a problem for the KITTEN work. > Another problem with PAKE is that it must be integrated into IKE > somehow. EAP definitely can be used for this, but it's a bit Do you mean enrolment and password change protocols? Enrolment could be left unspecified, but a password change protocol is required. > expensive from protocol point of view. We also have RFC 6467, but Oh, no, you meant a document like RFC 6467. Yes, such a document would be necessary -- I don't think Michael meant to imply otherwise. > it's Informational and I'm not sure it's widely supported. And while > the RFC 6467 framework is flexible enough, it is still not clear for > me if it can accommodate PAKEs like OPAQUE... It might be possible to build a single IKE extension that can handle any number of PAKEs, since they will generally involve a small number of round trips of exchanges of PAKE-specific octet strings, followed by a generic key confirmation exchange that involves binding in the PAKE's transcripts and at least the IKE ID payloads. There's also the opportunity to add support for second factors (e.g., OTPs). The KITTEN SPAKE work does that, though it's got some issues, so this WG might not want to copy that approach. Note that there are all these things to negotiate: - PAKE - including whether to use a symmetric or augmented variant - curve/group - second factor The KITTEN WG SPAKE work did not include PAKE negotiation nor augmented vs. not-augmented negotiation :( Nico -- From nobody Mon Dec 10 15:20:09 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E905131318 for ; Mon, 10 Dec 2018 15:20:07 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 VB2KnyrIERIo for ; Mon, 10 Dec 2018 15:20:06 -0800 (PST) Received: from golden.birch.relay.mailchannels.net (golden.birch.relay.mailchannels.net [23.83.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C767013130F for ; Mon, 10 Dec 2018 15:20:05 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A593F43BF9; Mon, 10 Dec 2018 23:20:04 +0000 (UTC) Received: from pdx1-sub0-mail-a45.g.dreamhost.com (unknown [100.96.19.78]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 44DF743C2C; Mon, 10 Dec 2018 23:20:04 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a45.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Mon, 10 Dec 2018 23:20:04 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Left-Cellar: 164845ba4e8d9f3e_1544484004507_2202720131 X-MC-Loop-Signature: 1544484004507:4184914632 X-MC-Ingress-Time: 1544484004507 Received: from pdx1-sub0-mail-a45.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTP id CE505807CA; Mon, 10 Dec 2018 15:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Hr7y5/fHieTryY GyUutNCb33JTs=; b=pDqQzYtgu6nN0pCFFptOAMnTuv/zS594FyMUFIrC0NuvJl zZlOFMyP/QvFEroRosnDTz+Ip5EWvTShKLStbYPtG6WrSHk49goH8rr35KKOymsV do32Csi0oD1zcRK+bFoD9gdrK+eCHxpWtyWbWtXZUMLgK+iGHUyQWahmV62f0= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTPSA id 9EDA5807C9; Mon, 10 Dec 2018 15:20:01 -0800 (PST) Date: Mon, 10 Dec 2018 17:20:00 -0600 X-DH-BACKEND: pdx1-sub0-mail-a45 From: Nico Williams To: Michael Richardson Cc: Valery Smyslov , ipsec@ietf.org Message-ID: <20181210231958.GC15561@localhost> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29587.1544482818@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudegiedgtdekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:20:08 -0000 On Mon, Dec 10, 2018 at 06:00:18PM -0500, Michael Richardson wrote: > Valery Smyslov wrote: > > Why do you think balanced PAKE is more appropriate for us than augmented? > > Because I share Paul's view that the PSKs we care about are generally > identical in both directions, and this use is primarily about site-to-site > inter-company VPNs. This is note for road-warrier accesss. There's no reason to not also add support for an augmented PAKE for road warriors. It's true that road warriors are already well-supported via PKIX user certificates, so perhaps there's no need, but it's very little extra work to support both, augmented and non-augmented. (Should I be saying "balanced" instead of "non-augmented"?) > I would prefer that the PAKE method was not wrapped in EAP. +1 From nobody Mon Dec 10 15:45:04 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E506A129BBF for ; Mon, 10 Dec 2018 15:45:01 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Efcm774v0prh for ; Mon, 10 Dec 2018 15:45:00 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10FCB129A87 for ; Mon, 10 Dec 2018 15:45:00 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43DKS82vJBzG6y; Tue, 11 Dec 2018 00:44:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1544485496; bh=fwScq+i/U+DfP4GjHBA9VmftEQ1hZ2KZyu7oMIFYdFo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KmWbWehDLmVNUvryUXfw11evNVAhGy96FRN+JUphWSpQ7FXreudnX+WktJ8bZNNQD GD1Tf+zQZS3tv7g03FsBkmaIsMrFzKIAmTbsTMfruf+XVKi3p50yKQH42c0rPqrKt9 VU79zmUa8EciNdBRwJNIFmC3ebJ2AqGQvWLhm/+k= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id V5YRmdyU6tjV; Tue, 11 Dec 2018 00:44:54 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Dec 2018 00:44:54 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B8881125611; Mon, 10 Dec 2018 18:44:53 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B8881125611 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ACD1B418A294; Mon, 10 Dec 2018 18:44:53 -0500 (EST) Date: Mon, 10 Dec 2018 18:44:53 -0500 (EST) From: Paul Wouters To: Michael Richardson cc: Valery Smyslov , ipsec@ietf.org In-Reply-To: <29587.1544482818@localhost> Message-ID: References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:45:02 -0000 On Mon, 10 Dec 2018, Michael Richardson wrote: >> Why do you think balanced PAKE is more appropriate for us than augmented? > > Because I share Paul's view that the PSKs we care about are generally > identical in both directions I agree here. > , and this use is primarily about site-to-site > inter-company VPNs. This is note for road-warrier accesss. But not here. weak group PSK's for roadwarriors is a thing :( > I would prefer that the PAKE method was not wrapped in EAP. Indeed. As I explained at the last IETF's presentation, it CANNOT use EAP because then site-to-site admins cannot use it to connect two different enterprises because none wants to reconfigure their equipment to trust the other party's authentication infrastructure. EAP is not suitable to interconnect different enterprises. Paul From nobody Mon Dec 10 15:47:32 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1349812D4E6 for ; Mon, 10 Dec 2018 15:47:30 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 1ezhlkWfwkDz for ; Mon, 10 Dec 2018 15:47:28 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7D4129BBF for ; Mon, 10 Dec 2018 15:47:28 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43DKW32MyzzG73; Tue, 11 Dec 2018 00:47:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1544485647; bh=higk4Y4NjZ54jkOC/Pab17SXcE/2b0IHysd3bYhbsQ0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ciN8sEeq5BFm+hDOs7YvH3rgQIxsWa4kC/EM9fCbbzirZa/3mMPAL6p+/9/MMbSuU yJ7QXgDa8VrHObZ3KUpupHK2vIx8qLkbkRLr4g01hO7Kw6CworbRayhximSA9zGnKT U2eMXP945Jfh+w30ffW4BcOalj4UzUXVuMJ7G43U= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id PRiFt4hfQnl9; Tue, 11 Dec 2018 00:47:26 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Dec 2018 00:47:26 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5B916125611; Mon, 10 Dec 2018 18:47:25 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5B916125611 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 520BC418A294; Mon, 10 Dec 2018 18:47:25 -0500 (EST) Date: Mon, 10 Dec 2018 18:47:25 -0500 (EST) From: Paul Wouters To: Nico Williams cc: Michael Richardson , ipsec@ietf.org, Valery Smyslov In-Reply-To: <20181210231958.GC15561@localhost> Message-ID: References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:47:30 -0000 On Mon, 10 Dec 2018, Nico Williams wrote: > There's no reason to not also add support for an augmented PAKE for road > warriors. It's true that road warriors are already well-supported via > PKIX user certificates That is still missing OTP support :( >, so perhaps there's no need, but it's very little > extra work to support both, augmented and non-augmented. I'd want the PAKE method to support OTP. > (Should I be saying "balanced" instead of "non-augmented"?) Explaining these differences on this list would be useful for me and possibly others. Paul From nobody Mon Dec 10 16:16:34 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72AC131338 for ; Mon, 10 Dec 2018 16:16:32 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 Eu9HFAgKn8zn for ; Mon, 10 Dec 2018 16:16:30 -0800 (PST) Received: from catfish.maple.relay.mailchannels.net (catfish.maple.relay.mailchannels.net [23.83.214.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A16131336 for ; Mon, 10 Dec 2018 16:16:30 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D07D6503C6E; Tue, 11 Dec 2018 00:16:29 +0000 (UTC) Received: from pdx1-sub0-mail-a45.g.dreamhost.com (unknown [100.96.29.126]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 70D2D5039AB; Tue, 11 Dec 2018 00:16:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a45.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 11 Dec 2018 00:16:29 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Sponge-Robust: 1b6b6e82082f21ad_1544487389667_1358473951 X-MC-Loop-Signature: 1544487389667:3424771397 X-MC-Ingress-Time: 1544487389666 Received: from pdx1-sub0-mail-a45.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTP id E9989807E0; Mon, 10 Dec 2018 16:16:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bn/pwJng8uNJHp nZYT7Sq+XGmGo=; b=HxD8wKgQq07uFUZBXmGczj/ey7qXpTGcEBzvhzXNxToosa c60IVMGI2S2V6cEcIY6Ldd0RGOISKDbtuBponhvGo+flJnRGHx6/2zfmkdooZjWy NNkgbgVCNjzE0wXxs8z0c7w9JVFJwCGUMm0Le3zLoMDUEdwUA3Nq47PxpEPz4= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a45.g.dreamhost.com (Postfix) with ESMTPSA id 713B4807D9; Mon, 10 Dec 2018 16:16:26 -0800 (PST) Date: Mon, 10 Dec 2018 18:16:24 -0600 X-DH-BACKEND: pdx1-sub0-mail-a45 From: Nico Williams To: Paul Wouters Cc: Michael Richardson , ipsec@ietf.org, Valery Smyslov Message-ID: <20181211001622.GD15561@localhost> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudegiedgvddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 00:16:33 -0000 On Mon, Dec 10, 2018 at 06:47:25PM -0500, Paul Wouters wrote: > On Mon, 10 Dec 2018, Nico Williams wrote: > > >There's no reason to not also add support for an augmented PAKE for road > >warriors. It's true that road warriors are already well-supported via > >PKIX user certificates > > That is still missing OTP support :( If you have the private keys locked unextractably in a hardware token that requires a PIN to unlock, then you have two factors right there. That's not generic two-factor authentication though, and it certainly isn't OTP. > >, so perhaps there's no need, but it's very little > >extra work to support both, augmented and non-augmented. > > I'd want the PAKE method to support OTP. It's doable. > >(Should I be saying "balanced" instead of "non-augmented"?) > > Explaining these differences on this list would be useful for me and > possibly others. A PAKE is a zero-knowledge password proof protocol (ZKPP) that also provides authenticated key exchange with forward security. A ZKPP is a password-based authentication protocol where neither eavesdroppers nor active attackers get to mount off-line dictionary attacks on captured protocol material. I had never seen the word "balanced" used to refer to "not augmented", but I like it. A "balanced" PAKE is one where both sides share a secret or secret- equivalent. An "augmented" PAKE is a PAKE where the credentials are asymmetric so that relying parties (servers, acceptors, responders, whatever you call them) store "verifiers" rather than password-equivalent secrets. A verifier is much like a hash of a password: not password-equivalent, but susceptible to off-line dictionary attack. Compromise of shared secrets (via server compromise) is catastrophic for a balanced PAKE since until you're able to change all the secrets the attacker can impersonate all the users to the server. Compromise of verifiers (via server compromise) is much less disastrous for an augmented PAKE because you have some time in which to change all the weak secrets: the time it would take the attacker to recover passwords via off-line dictionary attack. The verifiers would all be salted, naturally, so if your secrets are reasonably strong then that might be a lot of time to change all those passwords. A balanced PAKE is symmetric as to initiator/responder roles. An augmented PAKE is not quite. The asymmetry in roles in augmented PAKEs means that in order to function as an IKE responder (and thus maintain IKE initiator/responder role symmetry), the IKE PAKE extension would have to permit one side to request that the other initiate the augmented PAKE exchange. Nico -- From nobody Mon Dec 10 16:51:33 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1246131360 for ; Mon, 10 Dec 2018 16:51:25 -0800 (PST) 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 autolearn_force=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 BrVyT05QxEWa for ; Mon, 10 Dec 2018 16:51:23 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC94131339 for ; Mon, 10 Dec 2018 16:51:23 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4747720072; Mon, 10 Dec 2018 19:51:16 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 0DFFFE15; Mon, 10 Dec 2018 19:51:22 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0BC559D9; Mon, 10 Dec 2018 19:51:22 -0500 (EST) From: Michael Richardson To: Paul Wouters cc: Valery Smyslov , ipsec@ietf.org In-Reply-To: References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 00:51:31 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > > Because I share Paul's view that the PSKs we care about are generally > > identical in both directions > > I agree here. > > > , and this use is primarily about site-to-site > > inter-company VPNs. This is note for road-warrier accesss. > > But not here. weak group PSK's for roadwarriors is a thing :( yes, typo, "not for road-warrior" > > I would prefer that the PAKE method was not wrapped in EAP. > > Indeed. As I explained at the last IETF's presentation, it CANNOT use EAP > because then site-to-site admins cannot use it to connect two different > enterprises because none wants to reconfigure their equipment to trust > the other party's authentication infrastructure. > > EAP is not suitable to interconnect different enterprises. +1. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwPCgkACgkQgItw+93Q 3WXEVAf+KIYKQD4ZsY8ePvavrBjmJHQSjfUo26nnwBmvvjMH7zL7JJkiXFhkn02+ 6i7cTL2efFoDa1d1vP+WsQfJ5/Oh5H4gtvgB4okQ9NhD/rOaDRfVzfz5OWllNWJf MSHEtRktIqPL08g9+9abd9tK+dWFT0KnvduTe9WzOhCXVXVZeRf6fQnnGNmzQIiM 1TWLVdIDoNzYJHLn96cwMk1E1aoQOkujMMIqQGd154LsGUO5SVEIPvDl7vNSFAZ6 kp375BEgQ7Yt8ypTqTrLDn9TdfgTMmJFFcZcIQr/y/qvulN6YInk9tcyeXX1OuIZ aI7uwE8YotNDC8ky2bz6jY9CGn21Ig== =2+eC -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 10 17:02:12 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D93A1311D4 for ; Mon, 10 Dec 2018 17:02:10 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 1ewG6rDOTYJ3 for ; Mon, 10 Dec 2018 17:02:08 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED6E112DD85 for ; Mon, 10 Dec 2018 17:02:07 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43DM974HGYzG7D; Tue, 11 Dec 2018 02:02:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1544490123; bh=JGGSm0AQMT6wbdjuP2hdTlDzbzRKqQO7c97SAR5jpDo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=FBXlfgKdmH2R+qIpcMevcfAmrEHHVjVJS/dkYu7A0O/wekk5KZbyRGeZjmo8EFe41 O80ZClZrh+2S0U3eRaftO1T4QAHn1U3hET92ZzJPUn2n9VDX9TpWeFbR5lek2EVYRf yH+0lfw9zhL0p27j4WZhoqk1sdt6ozEzSBaJf59A= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id u-9jdjW2v-tB; Tue, 11 Dec 2018 02:02:02 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Dec 2018 02:02:01 +0100 (CET) Received: from [193.111.228.93] (unknown [193.111.228.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 8DE9E125611; Mon, 10 Dec 2018 20:02:00 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8DE9E125611 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16A405) In-Reply-To: <24842.1544489482@localhost> Date: Mon, 10 Dec 2018 20:01:43 -0500 Cc: Valery Smyslov , ipsec@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8D5228D2-EF4B-4504-888F-BEB202DB6634@nohats.ca> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <24842.1544489482@localhost> To: Michael Richardson Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 01:02:10 -0000 > On Dec 10, 2018, at 19:51, Michael Richardson wrote: >=20 >=20 > Paul Wouters wrote: >>> Because I share Paul's view that the PSKs we care about are generally >>> identical in both directions >>=20 >> I agree here. >>=20 >>> , and this use is primarily about site-to-site >>> inter-company VPNs. This is note for road-warrier accesss. >>=20 >> But not here. weak group PSK's for roadwarriors is a thing :( >=20 > yes, typo, "not for road-warrior" I understood. I disagree with the =E2=80=9Cnot=E2=80=9D. Road warriors using= group psk is a thing, sadly. Paul From nobody Mon Dec 10 17:58:28 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328CB1277D2 for ; Mon, 10 Dec 2018 17:58:26 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 VpvB9lSWzIoK for ; Mon, 10 Dec 2018 17:58:24 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D938126CC7 for ; Mon, 10 Dec 2018 17:58:24 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43DNQ30xDwzG7L; Tue, 11 Dec 2018 02:58:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1544493499; bh=ylszCNGHx8eyhW0kuw6BCwI7bJe6APxa4nmIq3hYn/c=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=uFv76o7JNiAqPw1T2AhlRLajlwj4cRr5kiQnrQ7C+6Ev+Si3YmwYM+rkoJT+6pkTn s45WRJxu6A6040PGfXHxOx5sHWMDx+id1+bjKgDDoCdppA+pmeFcBtjGILiRITcxwv gHclMd5qE6CWZHB7g1U8bnZczsj+8F/dyPAYEWnE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Fe3U-3lmXCKK; Tue, 11 Dec 2018 02:58:17 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Dec 2018 02:58:16 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C043E125611; Mon, 10 Dec 2018 20:58:15 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C043E125611 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B46C3418A29D; Mon, 10 Dec 2018 20:58:15 -0500 (EST) Date: Mon, 10 Dec 2018 20:58:15 -0500 (EST) From: Paul Wouters To: Nico Williams cc: Michael Richardson , ipsec@ietf.org, Valery Smyslov In-Reply-To: <20181211001622.GD15561@localhost> Message-ID: References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 01:58:26 -0000 On Mon, 10 Dec 2018, Nico Williams wrote: >> That is still missing OTP support :( > > If you have the private keys locked unextractably in a hardware token > that requires a PIN to unlock, then you have two factors right there. > That's not generic two-factor authentication though, and it certainly > isn't OTP. Right. So I guess what I'd like PSK-replacement-PAKE to support is using OTP, without EAP. But I guess that's not really possible if I understand things correctly. With XAUTH, we had a way to transfer a password in an encrypted payload, and the password could be in the syntax of ":" If we are going to basically obsolete/deprecate RFC 6628 and 6467, it would be nice if we did it in such a way that we can still have OTP support. >> I'd want the PAKE method to support OTP. > > It's doable. Great :) >> Explaining these differences on this list would be useful for me and >> possibly others. Thanks for these. > A PAKE is a zero-knowledge password proof protocol (ZKPP) that also > provides authenticated key exchange with forward security. A ZKPP is a > password-based authentication protocol where neither eavesdroppers nor > active attackers get to mount off-line dictionary attacks on captured > protocol material. > > I had never seen the word "balanced" used to refer to "not augmented", > but I like it. > > A "balanced" PAKE is one where both sides share a secret or secret- > equivalent. > > An "augmented" PAKE is a PAKE where the credentials are asymmetric so > that relying parties (servers, acceptors, responders, whatever you call > them) store "verifiers" rather than password-equivalent secrets. > > A verifier is much like a hash of a password: not password-equivalent, > but susceptible to off-line dictionary attack. > > Compromise of shared secrets (via server compromise) is catastrophic for > a balanced PAKE since until you're able to change all the secrets the > attacker can impersonate all the users to the server. > > Compromise of verifiers (via server compromise) is much less disastrous > for an augmented PAKE because you have some time in which to change all > the weak secrets: the time it would take the attacker to recover > passwords via off-line dictionary attack. The verifiers would all be > salted, naturally, so if your secrets are reasonably strong then that > might be a lot of time to change all those passwords. > > A balanced PAKE is symmetric as to initiator/responder roles. An > augmented PAKE is not quite. In that case, the gain of augmented PAKE seems small. If the server is compromised, they can just pretend the AUTH payload is OK if they _want_ you to connect to them and get all your traffic. And the client needs to know the password, and not just the verifier. For the case where a VPN gateway should not have the password credentials itself, it would (should?) be using some kind of EAP mechanism anyway? So we don't need an augmented PAKE for that? > The asymmetry in roles in augmented PAKEs means that in order to > function as an IKE responder (and thus maintain IKE initiator/responder > role symmetry), the IKE PAKE extension would have to permit one side to > request that the other initiate the augmented PAKE exchange. that feels the wrong method for a site-to-site VPN connecting two enterprises. One would have a better security after compromise than the other side? So it seems to me one balanced PAKE would be enough, but I'll go reread some older messages again. Paul From nobody Mon Dec 10 18:21:01 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F040C128D68 for ; Mon, 10 Dec 2018 18:20:58 -0800 (PST) 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 autolearn_force=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 XL4BFWgG3Tvz for ; Mon, 10 Dec 2018 18:20:57 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7477E128DFD for ; Mon, 10 Dec 2018 18:20:56 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1396620072; Mon, 10 Dec 2018 21:20:49 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D3235E15; Mon, 10 Dec 2018 21:20:54 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D0E6EE0E; Mon, 10 Dec 2018 21:20:54 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org, Paul Wouters In-Reply-To: <8D5228D2-EF4B-4504-888F-BEB202DB6634@nohats.ca> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <24842.1544489482@localhost> <8D5228D2-EF4B-4504-888F-BEB202DB6634@nohats.ca> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 02:20:59 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: > > On Dec 10, 2018, at 19:51, Michael Richardson wrote: > > > > > > Paul Wouters wrote: > >>> Because I share Paul's view that the PSKs we care about are generally > >>> identical in both directions > >> > >> I agree here. > >> > >>> , and this use is primarily about site-to-site > >>> inter-company VPNs. This is note for road-warrier accesss. > >> > >> But not here. weak group PSK's for roadwarriors is a thing :( > > > > yes, typo, "not for road-warrior" > > I understood. I disagree with the =E2=80=9Cnot=E2=80=9D. Road warriors us= ing group psk is a > thing, sadly. But they aren't cross-domain, they can do EAP-foobar, and they could use a certificate without a lot of hassle about what set of trust anchors. If we stick to the site-to-site then I think we can do something rather simple and quick, and our security considerations section will be much simpler. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwPHwYACgkQgItw+93Q 3WX2xQf/XGwWqmsWHtQ9EIi75eWIwhLr91vwK3zPY04yVRfneMWEkt0W+l9LvdRv 22TKEZI9jcSJvXbGXYV80ikadGwAUvySiIousXZdlkvSNZW7X5Tt+28T3wd+qJ+e 5xcv/inR4DA171gSjePJD18bpKFJrtFKJEPMT9MItIkIJZULlcpHfSu22ATWspsl s3tYGOtlxLBD6km8bJpI8FMlAYUxmeLGmg8gQwVJ9kV3Qms6WUJmGsqW2fmSUiOz hWD2Wlz0y0PTlQ5Cgf9t3vktrC5qpHE65UxzJWQlbRLrw0DDu7KSiv0zpmc22ZPP A03u7lF4Y0wtaJ5gZFPhq4lIrlUmuw== =yuDQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 10 19:01:20 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EE9130DE0 for ; Mon, 10 Dec 2018 19:01:11 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 c63AYB1sGjEz for ; Mon, 10 Dec 2018 19:01:10 -0800 (PST) Received: from ladybird.maple.relay.mailchannels.net (ladybird.maple.relay.mailchannels.net [23.83.214.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1907C130DE2 for ; Mon, 10 Dec 2018 19:01:09 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D1EB01242B5; Tue, 11 Dec 2018 03:01:08 +0000 (UTC) Received: from pdx1-sub0-mail-a1.g.dreamhost.com (unknown [100.96.19.74]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6B8951244EC; Tue, 11 Dec 2018 03:01:08 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a1.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 11 Dec 2018 03:01:08 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Shelf-Sponge: 2cfe19b6352e942a_1544497268651_1576223876 X-MC-Loop-Signature: 1544497268651:1589321050 X-MC-Ingress-Time: 1544497268651 Received: from pdx1-sub0-mail-a1.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a1.g.dreamhost.com (Postfix) with ESMTP id 25C0B8029C; Mon, 10 Dec 2018 19:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=qoVja/OCXs3b48 VWZhzPw/EajmU=; b=jmaXhXXsj+sV0vo4a3mMZuQejpEwiiF8G0o1fG4W13F/qe InXPYtR5UDs0ac+mgv4UdzF8vFj99Fru8J0Jof+eOKdxzd9bGqPC90Wc1FC3SsB4 Ne30N8GBSJW0tCYRS/Fe+vHS65PdlTm817Wo111OcIhdR7RFs4in6M4DmElZg= Received: from localhost (rrcs-172-254-26-194.nyc.biz.rr.com [172.254.26.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a1.g.dreamhost.com (Postfix) with ESMTPSA id 3DBA380249; Mon, 10 Dec 2018 19:01:04 -0800 (PST) Date: Mon, 10 Dec 2018 21:01:02 -0600 X-DH-BACKEND: pdx1-sub0-mail-a1 From: Nico Williams To: Paul Wouters Cc: Michael Richardson , ipsec@ietf.org, Valery Smyslov Message-ID: <20181211030100.GE15561@localhost> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudegiedgheehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepudejvddrvdehgedrvdeirdduleegnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepudejvddrvdehgedrvdeirdduleegpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 03:01:19 -0000 On Mon, Dec 10, 2018 at 08:58:15PM -0500, Paul Wouters wrote: > On Mon, 10 Dec 2018, Nico Williams wrote: > >>That is still missing OTP support :( > > > >If you have the private keys locked unextractably in a hardware token > >that requires a PIN to unlock, then you have two factors right there. > >That's not generic two-factor authentication though, and it certainly > >isn't OTP. > > Right. So I guess what I'd like PSK-replacement-PAKE to support is using > OTP, without EAP. But I guess that's not really possible if I understand > things correctly. No you very much can get PAKE + OTP. We'll get into the details of what is difficult later. > If we are going to basically obsolete/deprecate RFC 6628 and 6467, it > would be nice if we did it in such a way that we can still have OTP > support. Sure. > >A balanced PAKE is symmetric as to initiator/responder roles. An > >augmented PAKE is not quite. > > In that case, the gain of augmented PAKE seems small. If the server is No, the gain of an augmented PAKE is very large. > compromised, they can just pretend the AUTH payload is OK if they _want_ They can do that in both cases, but in the balanced PAKE case the attacker who has the shared secret can not only impersonate the server to the user, but vice-versa, and they can MITM the two. In the augmented case the attacker who has the verifier can impersonate the server to the user, but NOT the user to the server (not without first successfully mounting a dictionary attack on the verifier). > you to connect to them and get all your traffic. And the client needs to > know the password, and not just the verifier. The client is always expected to know the password. The verifier can always be computed from the password (and salt). > For the case where a VPN gateway should not have the password > credentials itself, it would (should?) be using some kind of EAP > mechanism anyway? So we don't need an augmented PAKE for that? EAP has its use: federation. Augmented PAKE is better than augmented in all cases when dealing with a username and password as a credential. Balanced PAKE is only useful (IMO) as a transition tool so that you can start using the PSK secrets you already have as PAKE secrets then change passwords to switch to secret/verifier augmented PAKE from that point forward. > >The asymmetry in roles in augmented PAKEs means that in order to > >function as an IKE responder (and thus maintain IKE initiator/responder > >role symmetry), the IKE PAKE extension would have to permit one side to > >request that the other initiate the augmented PAKE exchange. > > that feels the wrong method for a site-to-site VPN connecting two > enterprises. One would have a better security after compromise than > the other side? It just means that when the SG/whatever wants to initiate an IKE exchange with the user it needs an extra message: "Hey yo, start augmented PAKE with me", followed by the rest of an IKE exchange as if the now-resonder client had initiated. > So it seems to me one balanced PAKE would be enough, but I'll go reread > some older messages again. Please opt for both. Balanced so you can start using existing PSKs, augmented so you can better secure the password database on the server side. Nico -- From nobody Mon Dec 10 20:28:52 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86062126CC7 for ; Mon, 10 Dec 2018 20:28:49 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 ctCw7o-y5P_E for ; Mon, 10 Dec 2018 20:28:48 -0800 (PST) Received: from golden.birch.relay.mailchannels.net (golden.birch.relay.mailchannels.net [23.83.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00D9126C01 for ; Mon, 10 Dec 2018 20:28:47 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C0182124131; Tue, 11 Dec 2018 04:28:46 +0000 (UTC) Received: from pdx1-sub0-mail-a58.g.dreamhost.com (unknown [100.96.11.179]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 669201240EF; Tue, 11 Dec 2018 04:28:46 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a58.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 11 Dec 2018 04:28:46 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Snatch-Spicy: 193bffa84a016354_1544502526603_1030116420 X-MC-Loop-Signature: 1544502526603:3219547074 X-MC-Ingress-Time: 1544502526602 Received: from pdx1-sub0-mail-a58.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTP id 0FA998068C; Mon, 10 Dec 2018 20:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=BDVUfVjX5OQx74QWYbPbkyjrQa0=; b=Z4FF6/cVfws HCf6TU6W39RAUIfrt57/havH44dzOpBprvXx+hoJ8niuO6u1NglFaXpLUtm4uHyb WpxMDpBCSr+NaA/QEbE0J6XbWS4bht8mSz88HMTMSpQaaOOTPzt3JfzU21GGSKrN k+oTQdxTlkBonn24jsjayqtQqslyLJb4= Received: from localhost (rrcs-172-254-26-194.nyc.biz.rr.com [172.254.26.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a58.g.dreamhost.com (Postfix) with ESMTPSA id 26D8D806D3; Mon, 10 Dec 2018 20:28:41 -0800 (PST) Date: Mon, 10 Dec 2018 22:28:39 -0600 X-DH-BACKEND: pdx1-sub0-mail-a58 From: Nico Williams To: Michael Richardson Cc: ipsec@ietf.org, Paul Wouters Message-ID: <20181211042838.GF15561@localhost> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <24842.1544489482@localhost> <8D5228D2-EF4B-4504-888F-BEB202DB6634@nohats.ca> <14559.1544494854@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <14559.1544494854@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudegiedgjedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtugfgjggfsehtkeertddtreejnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedujedvrddvheegrddviedrudelgeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedujedvrddvheegrddviedrudelgedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 04:28:49 -0000 On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote: > Paul Wouters wrote: > > > yes, typo, "not for road-warrior" > > > > I understood. I disagree with the =E2=80=9Cnot=E2=80=9D. Road warrior= s using group psk is a > > thing, sadly. >=20 > But they aren't cross-domain, they can do EAP-foobar, and they could us= e a > certificate without a lot of hassle about what set of trust anchors. >=20 > If we stick to the site-to-site then I think we can do something rather > simple and quick, and our security considerations section will be much > simpler. I mean, if road warriors should always be using either EAP or user certs, then we don't need PAKE for anything because presumably the shared keys used in PSKs are strong enough that PAKEs don't improve security and only slow things down... (I'm assuming you mean to use an EAP method like EAP-PWD (RFCs 5931 and 8146), yes?) Assuming you can always use EAP, the only real reasons to use a PAKE in IKEv2 are: - you're not entirely sure that you don't have weak PSKs and would like to strengthen them - you don't always want EAP for users who don't have certs for reasons that escape me (I wouldn't object, but if EAP fits the bill as to PAKE already, then thw WG could object to spending its resources on adding PAKE to IKEv2.) Right? Nico --=20 From nobody Tue Dec 11 04:03:04 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9006E130DDC for ; Tue, 11 Dec 2018 04:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OQguI0--CB7x for ; Tue, 11 Dec 2018 04:03:00 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808C4130DD0 for ; Tue, 11 Dec 2018 04:03:00 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id l15-v6so12695463lja.9 for ; Tue, 11 Dec 2018 04:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=krTFbLBJCE6LDZBftOebrndYi5ed0hA5gQ+7+aQb3Ik=; b=KNjdpBhkajDck38mRbLg48Hv84vmALmEE4m5Q2BnGRiYamaomE24uPijdigCz5j7V6 srzhcNOzku2gFxAeONUg5n92fdHtt0uBMuaGB5kLxGUJ7ijFSVTqeX5A3clgzVdB45Sv BcgccxFG+I+ZOh4gEyV0eeowy9RSEEvm73Hd/VVbKJ/Af6+QBLx2L03RqJXYGmmXUHUw 5cI37omiUw8NPri9hulglzzJpeSJD95Pnf+pgwurRpHnnklETTLR6lbS+geZhewlOzRK 8hx/7wHodMqmYm/TcFzL3e175U/cvmP1T1LXPRY6zNgTjRe2qmCBY4mLXgfRzkPiUbK3 /sVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=krTFbLBJCE6LDZBftOebrndYi5ed0hA5gQ+7+aQb3Ik=; b=CViBwpoFfbLBvjr6ibbIbuDLeH3t1mDAs2lDLl5WrRybGz4ToIxl7EuVo/jjs2N+nc d2haiGQOgvPkArBA/Ty8rFlCa9q6O+dCILayO+of2lWR7b7WpAhEUegrBkR7LgTRs2V3 5w8bfsbve4ZWbGclJbPi7M5xD8DqV+BiBDuoW1+hKl7nkzw1ZbZTOMYV5SWuLm/bT5Z7 0OwrGy6q0oeyQOjSBy6ziYdcNfWE6AjiboGwEmcAGa4CKNl68/d03Ibcqib7lgp6VxyD KDzm4L3weRRjvqbOZBWolXcvZqHxXUPHCgwgkxALWEXSg1aAILwsTwR+Qc3m9hOX0jXt Nrtg== X-Gm-Message-State: AA+aEWYzakiNIuhvijWu63bhjnma+r98ai9qF8eSj9zUvCVadBVB/2aO CK9eGqiSGGNlEuWvYdan1mgW1Yw1 X-Google-Smtp-Source: AFSGD/XIQ8X4osySWEKUC2uDe9Ne5UKuspKgJgY0B9WIV6Qu3fnhdLf0kpLJ6h6VwwyCbTJnaFgdcA== X-Received: by 2002:a2e:2f15:: with SMTP id v21-v6mr9650591ljv.56.1544529778301; Tue, 11 Dec 2018 04:02:58 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id u15-v6sm2901818lja.63.2018.12.11.04.02.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Dec 2018 04:02:57 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Nico Williams'" Cc: "'Michael Richardson'" , References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> In-Reply-To: Date: Tue, 11 Dec 2018 15:02:51 +0300 Message-ID: <035701d49149$71640f10$542c2d30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJjEIcGzPEj/22sYW2hroPcukYuWAIvYqvHAie7eo0BeQS8egHtaQHgAjk9efMBSdV9YqQCaPYw Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 12:03:02 -0000 Hi Paul, I think that using PAKE for road warriors is more important than for site-to-site VPNs. In the latter case the SGWs are usually administered by (presumably :-)) experienced administrators, who can select a high-entropy PSK, and these PSKs need not to be memorable by users. So, generally speaking, it is more secure to use good PSK than passwords (since any PAKE defends only against passive attacks, an attacker can still perform active probes and the search space is limited for passwords). So I think that augmented PAKE is more important than balanced. It can be used e.g. in those cases when it is impossible to securely store certificate's private key on a user devices. I'm not against selecting balanced PAKE too, but I think it's less important. And I agree that it's better to avoid using EAP for PAKE. But why do you want to deprecate RFC 6467? It is just a framework that must be suitable for any PAKE. Regards, Valery. > >> That is still missing OTP support :( > > > > If you have the private keys locked unextractably in a hardware token > > that requires a PIN to unlock, then you have two factors right there. > > That's not generic two-factor authentication though, and it certainly > > isn't OTP. > > Right. So I guess what I'd like PSK-replacement-PAKE to support is using > OTP, without EAP. But I guess that's not really possible if I understand > things correctly. > > With XAUTH, we had a way to transfer a password in an encrypted payload, > and the password could be in the syntax of ":" > > If we are going to basically obsolete/deprecate RFC 6628 and 6467, it > would be nice if we did it in such a way that we can still have OTP > support. > > >> I'd want the PAKE method to support OTP. > > > > It's doable. > > Great :) > > >> Explaining these differences on this list would be useful for me and > >> possibly others. > > Thanks for these. > > > A PAKE is a zero-knowledge password proof protocol (ZKPP) that also > > provides authenticated key exchange with forward security. A ZKPP is a > > password-based authentication protocol where neither eavesdroppers nor > > active attackers get to mount off-line dictionary attacks on captured > > protocol material. > > > > I had never seen the word "balanced" used to refer to "not augmented", > > but I like it. > > > > A "balanced" PAKE is one where both sides share a secret or secret- > > equivalent. > > > > An "augmented" PAKE is a PAKE where the credentials are asymmetric so > > that relying parties (servers, acceptors, responders, whatever you call > > them) store "verifiers" rather than password-equivalent secrets. > > > > A verifier is much like a hash of a password: not password-equivalent, > > but susceptible to off-line dictionary attack. > > > > Compromise of shared secrets (via server compromise) is catastrophic for > > a balanced PAKE since until you're able to change all the secrets the > > attacker can impersonate all the users to the server. > > > > Compromise of verifiers (via server compromise) is much less disastrous > > for an augmented PAKE because you have some time in which to change all > > the weak secrets: the time it would take the attacker to recover > > passwords via off-line dictionary attack. The verifiers would all be > > salted, naturally, so if your secrets are reasonably strong then that > > might be a lot of time to change all those passwords. > > > > A balanced PAKE is symmetric as to initiator/responder roles. An > > augmented PAKE is not quite. > > In that case, the gain of augmented PAKE seems small. If the server is > compromised, they can just pretend the AUTH payload is OK if they _want_ > you to connect to them and get all your traffic. And the client needs to > know the password, and not just the verifier. > > For the case where a VPN gateway should not have the password > credentials itself, it would (should?) be using some kind of EAP > mechanism anyway? So we don't need an augmented PAKE for that? > > > > The asymmetry in roles in augmented PAKEs means that in order to > > function as an IKE responder (and thus maintain IKE initiator/responder > > role symmetry), the IKE PAKE extension would have to permit one side to > > request that the other initiate the augmented PAKE exchange. > > that feels the wrong method for a site-to-site VPN connecting two > enterprises. One would have a better security after compromise than > the other side? > > So it seems to me one balanced PAKE would be enough, but I'll go reread > some older messages again. > > Paul From nobody Tue Dec 11 04:21:31 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD68C130DD0 for ; Tue, 11 Dec 2018 04:21:30 -0800 (PST) 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 autolearn_force=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 Al31K0gHbbFZ for ; Tue, 11 Dec 2018 04:21:28 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9CE127333 for ; Tue, 11 Dec 2018 04:21:28 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 481BD20072; Tue, 11 Dec 2018 07:21:20 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 14F65E15; Tue, 11 Dec 2018 07:21:26 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 12E949D9; Tue, 11 Dec 2018 07:21:26 -0500 (EST) From: Michael Richardson To: ipsec@ietf.org, Nico Williams cc: Paul Wouters In-Reply-To: <20181211042838.GF15561@localhost> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <24842.1544489482@localhost> <8D5228D2-EF4B-4504-888F-BEB202DB6634@nohats.ca> <14559.1544494854@localhost> <20181211042838.GF15561@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 12:21:31 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Nico Williams wrote: > On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote: > > Paul Wouters wrote: > > > > yes, typo, "not for road-warrior" > > > > > > I understood. I disagree with the =E2=80=9Cnot=E2=80=9D. Road warrior= s using group psk is a > > > thing, sadly. > > > > But they aren't cross-domain, they can do EAP-foobar, and they could us= e a > > certificate without a lot of hassle about what set of trust anchors. > > > > If we stick to the site-to-site then I think we can do something rather > > simple and quick, and our security considerations section will be much > > simpler. > > I mean, if road warriors should always be using either EAP or user > certs, then we don't need PAKE for anything because presumably the > shared keys used in PSKs are strong enough that PAKEs don't improve > security and only slow things down... It's the enterprise-to-enterprise connection that is hard to convert to certificates for the reasons that Paul explained. > (I'm assuming you mean to use an EAP method like EAP-PWD (RFCs 5931 and > 8146), yes?) > > Assuming you can always use EAP, the only real reasons to use a PAKE in > IKEv2 are: > > - you're not entirely sure that you don't have weak PSKs and would like > to strengthen them I think that this is the major reason. > > - you don't always want EAP for users who don't have certs for reasons > that escape me > > (I wouldn't object, but if EAP fits the bill as to PAKE already, then > thw WG could object to spending its resources on adding PAKE to > IKEv2.) I think that a user-oriented PAKE is more useful if it can be backended into a AAA infrastructure, which EAP can. A site-to-site PAKE is more useful if it isolated from any AAA infrastructure. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwPq8UACgkQgItw+93Q 3WVwrggAnZzt2MV0sqT8gEGWxNN9yx472s50BdZ4UZtU+Z7XRiCnGm+sXBSx3dcc /bV1n/fGoSHUNNSANROCwO+TjkfEC2agjdoPFMUo8du+Pmcqg+cy4f3Wj5DPAVxR upix76MRgOfQ1dumf2+St5ugpWjc6OTy9OlgVJ48qA1PxFAb9wVJuCN11xHhIOle cPhxaT/hFpbQzj/GHfKvmrzJ/mI6Igys14eW18aj6yxbpq1E9SrRitE/DOVZAwnz 6imyytiFX4rbqBAjJnFm1+nKy9Hbr1rs2zyIYA4zazqmBpcs4LVzK414qxCugK/X IaFdntTC+VIZIw2RaB6SFOWkaywwXw== =UZL5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 11 04:23:10 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32EFB127333 for ; Tue, 11 Dec 2018 04:23:08 -0800 (PST) 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 autolearn_force=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 fY7o6Bo2QsqR for ; Tue, 11 Dec 2018 04:23:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EBD1130DE2 for ; Tue, 11 Dec 2018 04:23:06 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B522120072; Tue, 11 Dec 2018 07:22:59 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 86E09E15; Tue, 11 Dec 2018 07:23:05 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 864729D9; Tue, 11 Dec 2018 07:23:05 -0500 (EST) From: Michael Richardson To: "Valery Smyslov" cc: "'Paul Wouters'" , "'Nico Williams'" , ipsec@ietf.org In-Reply-To: <035701d49149$71640f10$542c2d30$@gmail.com> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> <035701d49149$71640f10$542c2d30$@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 12:23:08 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > I think that using PAKE for road warriors is more important than for > site-to-site VPNs. In the latter case the SGWs are usually administered > by (presumably :-)) experienced administrators, who can select a high-entropy > PSK, and these PSKs need not to be memorable by users. So, generally > speaking, > it is more secure to use good PSK than passwords (since any PAKE defends > only If we assume highly competent administrators, then we don't need a PAKE at all. What I heard from the IPsecME record was that many in the room felt that this was where ther was a weakness. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwPrCkACgkQgItw+93Q 3WVSegf/fgjk0ghSLJbFf+JFNyq6T+1phaDvDD/OFswKXjJDN5Up7Aw+zektBdnk c4Ghz1/mkxmPyiYFxsDaiuj3BzFfGtK2/vXkYkGjPrwJ95fn+qzAH3UYbu8Y3yj5 aImyZX27XOeZ7AHapgyQIMQQQvk9mwhIcio4XkWV82eg9MP0OAWDtqs/8bEQ4+6O 2QEF8fGLtNquTcaRS8PPk8LXrClxW9na8uAXeD1XZ9GQBr1ugAFqglimG1b+81gl lCZ1agWFhvF4PBGnU4DiTCJj8bw/msoA3rc/pVmltuWU1WKvHHS5BBblHjexo7HU zYVZ4zPxcVGh8tw56xcdglWgzoa04w== =eh4U -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 11 04:30:04 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61233127333; Tue, 11 Dec 2018 04:29:56 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 72F7ogHjw8zD; Tue, 11 Dec 2018 04:29:51 -0800 (PST) Received: from xenon43.um.es (xenon43.um.es [IPv6:2001:720:1710:601::43]) by ietfa.amsl.com (Postfix) with ESMTP id 4B305130DD0; Tue, 11 Dec 2018 04:29:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id D30951FF31; Tue, 11 Dec 2018 13:29:47 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id LkbqUGxFejrP; Tue, 11 Dec 2018 13:29:47 +0100 (CET) Received: from quantum.inf.um.es (quantum.inf.um.es [155.54.204.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon43.um.es (Postfix) with ESMTPSA id D37D21FEBD; Tue, 11 Dec 2018 13:29:45 +0100 (CET) From: Rafa Marin-Lopez Message-Id: <13E3B826-18EB-431A-ACE9-70E7B13B636F@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_C27FF821-CD48-4BF8-A1FE-34A3663B504C" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Date: Tue, 11 Dec 2018 13:29:44 +0100 In-Reply-To: Cc: Rafa Marin-Lopez , Yoav Nir , i2nsf@ietf.org, "ipsec@ietf.org WG" To: Paul Wouters References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> X-Mailer: Apple Mail (2.3445.100.39) Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Appendix A) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 12:29:57 -0000 --Apple-Mail=_C27FF821-CD48-4BF8-A1FE-34A3663B504C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, all: >=20 > Appendix A: >=20 > Why is it "eipsec" and not "ipsec=E2=80=9D ? [Authors] We have fixed this now. >=20 > Why is the organization not the IETF? Is this commonly done for yang = models? [Authors] You're right. We will change this to: "IETF I2NSF (Interface to Network Security Functions) Working Group" >=20 > encryption-algorithm-t - I think this should only list the MUST/SOULD = items, so AES_GCM (1 flavour), AES_CCM (1 flavour) CHACHAPOLY1305 and = NULL >=20 > description "Encryption algorithms -> RFC_5996=E2=80=9D; [Authors] Right. Our doubt here is if we should refer instead to=20 https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-02 such as=20 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-08 is doing. If you check this link you will notice is referring to=20 ct:rsa2048 =20 which is referring to ietf-crypto-types >=20 > RFC 5996 is an obsolete reference. It should either refer to RFC 7296, = or it should simply refer to the IANA registry involved. [Authors] OK. >=20 > integrity-algorithm-t: If the above is agreed, this enumeration should = only contain "none" and the entries from aes-cmac-96 and up. That is, > not contain des,md5,sha1 and aes_xcbc. Same obsolete reference is = used here in the description. [Authors] Ok. >=20 > type-autostartup: Maybe instead of RESPOND-ONLY, a better word is = "STANDBY"? That way, the node could decide itself to bring a connection = up > without _requiring_ a remote signal, and could be triggered locally as = as well as remotely to come up. [Authors] Sounds reasonable. We should provide a better description of = each value as well. >=20 > description "Different types of how IKEv2 starts the IPsec SAs"; >=20 > I would say "different policies of when to start an IKEv2 based IPsec = SA". Does it need clarification this value is ignored or unused for the > "case 2" scenario? [Authors] This typedef is not used in the part of the model associated = to case 2 but we can something in the description.=20 >=20 > auth-protocol-type: This should only contain IKEv2. The enum should = remain in case we get IKEv2.1 or IKEv3 in the future. [Author] Agree. >=20 > description "Peer authentication protocols=E2=80=9D; >=20 > I would say "IKE authentication protocol version", unless you want to = keep the option open to have a non-IKE protocol. But I think that would > run into many more issues of having parameters that are not defined = for IKE? [Author] Agree. >=20 > ipsec-mode: It should only contain Tunnel and Transport Mode. It would = be nice to see some text that forbids using Transport Mode when NAT is > requested, just to avoid a lot of problems and disappointments. = L2TP/IPsec still has major scars due to its use of Transport Mode with = NAT. [Authors] Sounds reasonable. >=20 > esp-encap: as stated before, we are missing the port entry. I can also = image that multiple encaps could be allowed, such as TCP-443 and = TLS-443. > Also note that the RFC for ESP over TCP recommends to continiously = check if UDP encapsulation has become available, since it is so much = prefered > over TCP. But that only makes sense when the remote is a roaming = client, and makes less sense if the network consists of data centers. [Authors] Ok. Let's add the port entry. In any case, I believe that is = something that implementation in the NSF (in particular the NETCONF = server) could check (UDP encapsulation) >=20 > ipsec-protocol: I think this should only contain esp. See earlier = comments. Notably, if supporting ipcomp here, the yang model must be = clear > that it could need an ipcomp + esp IPsec SA for a single 'connection'. = Even if we only leave esp as a valid option, keep this enum in case > we come up with a new esp version of some esp-lite version. [Authors] We are in favour on leaving only ESP. If the WG agrees, let's = proceed that way. >=20 > lifetime-action only has "terminate" and "rekey". For libreswan we use = "clear", "hold" and "restart". The difference > between clear and hold is what kernel policy to install for cleartext = packets. For roadwarrionrs coming in, you > want clear to leave no trace. for a site-to-site VPN you generally = want "hold" to ensure you drop all packets until > a new tunnel is established (possible ondemand, so this is different = from restart) [Authors] Basically we have "terminate" and "rekey" since RFC 4301 says: "Lifetime of this SA: a time interval after which an SA must be replaced with a new SA (and new SPI) or terminated, plus an indication of which of these actions should occur." =20 We are realizing that RFC 4301 should also be updated to reflect these = new possibilities. In any case, could you elaborate a little bit more about the difference = between clear and hold and the effect in the kernel? We are assuming = that affects the SAD. >=20 > ipsec-traffic-direction: >=20 > Traditionally, freeswan ony used inbound/outbound and not forward. = Unfortunately, KAME and Linux/XFRM kept forward there. But I see no use > case for it in these deployments. We have nothing specified in about = ipsec-sa's for the forward (it's basically implied "completely open") > But I understand it might be useful to just specify this because it is = needed. But perhaps more language is then needed to clarify this? [Authors] We think this is an implementation aspect. We think it is = better to remove fwd policy. If fwd policy is required because we have = an implementation based on Linux, the NETCONF server should install that = fwd policy based on the in/out received. >=20 > ipsec-spd-operation: >=20 > The value BYPASS probably means "let go in the clear" but I don't find = the name very obvious. [Authors] It has been extracted from RFC 4301 definition.=20 "Processing info -- which action is required -- PROTECT, BYPASS, or DISCARD." =20 In relation with our previous comment we think it would be worthy to = carry out an update in the RFC 4301 > The operation modes BYPASS and DISCARD cannot be configured with the = current yang parameters > for IKE? How would this be configured, eg to place a DISCARD for = 192.1.2.0/24 ? [Authors] It is not needed to configure it in the IKE model since it is = already configured in the SPD model. The RFC 4301 defines how the SPD is = composed, and following this, we have defined the SPD model regardless = whether we are in IKE case or IKEless case. In other words, both cases = uses the information contained in the SPD model. Having said this, we = think it would be useful to explicitly "link" each connection in IKEv2 = with the SPD entries associated to that connection. For example, per = each connection we could add a list of spd-entry-id, which point to the = SPD entries associated to that connection. =46rom your comment we have = realized that this issue is not well explained in the document. Thus, regardless the case we are using, the policies establishing the = type of traffic and protection to be applied are indicated in the SPD = model (i.e. by means of a list of spd-entry). So the SPD model is used = for both, IKE case and IKE-less case. Thus, we have the following = situation.=20 - For IKE case, the whole configuration is distributed in two parts. = While the IKE SA configuration is represented as =E2=80=9Cike-conn-entries= =E2=80=9D, the the CHILD SA configuration will be found as a list of = =E2=80=9Cspd-entry=E2=80=9D.=20 - For IKE-less case, only the CHILD SA configuration will be accessible = as a list of =E2=80=9Cspd-entry=E2=80=9D. What do you think? > In libreswan > we can configure a connection with type=3Dtransport|tunnel|drop|reject = but that meshes up the > IPsec Mode with the SPD Operation. It is also a bit odd to configure = "IKE" for a "DISCARD" > since it really does not define anything in IKE - it bypasses IKE to = put in an IPsec policy > (SPD). But if the yang model used the ipsec parts to do this, it could = be mixing IKE + manual > IPsec policies, which could really confuse the IKE daemon. I am not = sure what the best fix for > this is. Note REJECT which is DISCARD+ICMP message is not defined = here. Should it? I don't > think Linux/XFRM/netlink supports this. [Authors] As we see it, we are not mixing IKE + manual IPsec policies. = SPD is the central point of configuration for IPsec policies in the = model. In any case, we talk about implementation. In particular, when = the controller configures the SPD first and the IKE model with a = connection, this connection will have a list of spd-entry-id to refer to = the particular SPD entries that it has to configure in the IKE daemon = associated to that connection. About what is happening with drop / = reject and the fix we don't really know either but I think this is not a = problem for the model itself, right? As a note, ip xfrm allows : "allow" = or "block"=20 >=20 > ipsec-next-layer-proto: >=20 > See earlier note. I think this is a really bad name. [Authors] This is defined in RFC 4301 with this name. In ip xfrm is = UPSPEC. is Upper Layer Protocol better? >=20 > ipsec-spd-nam: >=20 > This is the first time I have seen an SPD as having a name. normally = these just have numbers. Or they > have a number that is the link between SPD and SAD (with linux, that = is called reqid=3D) > So maybe add an enum id_number so implementors could map this onto the = linux implementation ? [Authors] RFC 4301 says explicitly in page 28. "- Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address." =09 "An SPD is an ordered list of entries each of which contains the following fields. o Name -- a list of IDs. This quasi-selector = is optional. The forms that MUST be supported are = described above in Section 4.4.1.1 under "Name". =E2=80=9C" But yes, we can replace this name by other identifier, as you suggest. >=20 > auth-method-type: >=20 > See earlier comment about asymmetric authentication. >=20 > This should only contain pre-shared, null, eap, rsa, rfc7427(digital = signatures). That is I think dss-signature can be removed. > I also wonder if this entry needs to have a better difference for the = source of the private/public keypair, eg raw RSA versus > RSA certificate based authentication. I guess this is now implied by = not having a certificate entry? [Authors] Mmmmm... good question. We think we should include at least a = "raw public key" leaf so if the leaf is set then we have raw public key. = If we include certificate then we will have RSA certificate based = authentication. In any case, if ECC-based signature is required we would = also need to support ECC public and private keys. In any case, this part = in the model needs to be udpated to support RFC 7670 and RFC 7427 There is also another aspect: if eap is chosen, what eap method is = allowed. I think a container mentioning the EAP method should be = included. Moreover, we should include a way to send the credentials for = the particular EAP method. >=20 > Also rename description "Peer authentication method" to "IKE = authentication method" (it should mention this is IKE, but also > in case of asymmetric use, this is not neccessarilly for the peer but = how we authenticate _to_ the peer) [Authors] Sounds reasonable >=20 > sa-state: I am not sure why this is needed? Unless someone would want = to manually place larval/acquire states in the kernel > without IKE, but then who is going to listen to these ACQUIRE = messages? A non-IKE daemon? See earlier discussion on this topic. > If you do want to get netlink/pf_key messages for max-counter, = max-bytes etc without IKE, then this would be required. Otherwise > this should be removed. [Authors] This is precisely what we want: "to get netlink/pf_key = messages for max-counter, max-bytes etc without IKE" . This is captured = by the NETCONF server to send notifications to the controller in IKEless = case. Having said this, most probably this state is not completely = required though as we mentioned in section 6's comments , the IPsec SA = appears in the state. It seems too much detail for the regular operation = of the controller, even considering IKEless case. >=20 > lifetime: See earlier comments. >=20 > grouping auth-method-grouping: See earlier comments about asymmetric = authentication and raw vs cert based signatures. Note based > on above entries, this is missing a dss-signature section. So if you = agree with earlier comment to remove dss-signature, then > it not appearing here is fine. [Authors] Yes, we are going to remove dss-signature and extend the = auth-method container to contemplate the use of raw public keys as well = as generic digital signatures (rfc 7427). >=20 > grouping identity-grouping: See earlier comments on ID_NULL / = AUTH_NULL support [Authors] We failed to see this earlier comments about ID_NULL and = AUTH_NULL, could you point us to them? >=20 > grouping port-range: I don't see anywhere that protocol and ports = together are "overloaded" for things like ICMP message types. > Should language be added for that? [Authors] Not sure what are you are referring here... could you = elaborate? We have seen that description should be changed as well. >=20 > SAD and SPD grouping : See earlier note about Security Labels. It = would need to be added here. Linux/XFRM already supports these. [Authors] Not sure about this. Right now, the usage of security labels = seems associated to specific implemenation (Linux/XFRM) and = https://tools.ietf.org/html/draft-sprasad-ipsecme-labeled-ipsec-00 has = not been evolved since March 2018 (is it going to be adopted?). >=20 > I see container-ah and container-esp, but what about container-ipcomp? = Again, if we remove IPCOMP as I'd like, then we are fine > here. but if not, then something needs to be added here. If AH is = removed as I'd recommended, it needs to be removed here. [Authors] That's right. We think we could remove that ipcomp and ah if = the WG is agree. >=20 > container sad-lifetime-soft { > description "SAD lifetime hard state data"; >=20 > that "hard" should be "soft=E2=80=9D. [Authors] Right. >=20 > I am confused that "hard" and "soft" have an action that can be = similar. soft could have an action to just notify userland via > XFRM/PF_key, but "hard" can only have an option "terminate=E2=80=9D ? [Authors] Your comment makes sense.=20 >=20 > container encap: Now I see the sport / dport, but I'm still confused = how this is populated from the higher level Security Controller > communication (if not IKE). Note also the Security Controllers cannot = know the port numbers without sending any traffic so the > NAT gateway crates a mapping. [Authors] As mentioned earlier, this can be informed by the NSF through = a YANG module related with NAT management.=20 >=20 > list traffic-selector-list: Can a traffic selector have a direction of = fwd ? Not in the IKE protocol. [Authors] fwd direction has been removed now. >=20 > leaf mode { type ipsec-mode; description = "transport/tunnel"; } [Authors] True. We will add them but removing BEET. >=20 > This "description" does not match all the available options defined = before. >=20 > container ah-algorithms: See AH comments before. Also see IPCOMP = comments before. [Authors] As mentioned we are in favour of removing AH and IPCOMP if the = WG agrees on that. >=20 > description "Configure ESP encryption" >=20 > Maybe say "Configure ESP/AEAD encryption=E2=80=9D [Authors] This would be applicable if we finally agree that only AEAD = will be used. But in the last e-mail exchange in the mailing list, it = looks like we are not limiting us to a case where only AEAD is allowed.=20= >=20 > spd-mark: >=20 > Note that the IKE case cannot negotiate this spd-mark value. Is such a = capability needed? It is similar to negotiating a Security Context. [Authors] It is in linux kernels and handled by XFRM but we think you're = right and we could remove it from the model. In any case, do you think = there is an important example case for its usage? >=20 >=20 > container spd-lifetime-*: See earlier comments on hard/soft and = acceptable actions [Authors] OK. >=20 > grouping isakmp-proposal: I would call this ike-proposal as isakmp is = kind of an IKEv1 term. See also phase1-* value suggestions earlier to > make those ike-* or ike-sa-* values. This group is also missing pfs=3D = which for IKEv2 only starts to matter when rekeying and whether or not > to do a new DH. [Authors] Agree. We will change the name. Also true about pfs. We will = add this information. >=20 > grouping phase2-info: Call this ipsec-info: or ipsec-sa-info: [Authors] Correct. As mentioned we think it would be better if this = ipsec-sa-info has a lists of spd-entry-id pointing the SPD policies = associated. >=20 > leaf-list pfs_group { type uint32; >=20 > This should really be an enum and not a uint32. [Authors] Ok. We will change it. >=20 > typedef sadb-msg-type: where/when are these used? That is, I = understand the IKE <-> IPsec API uses this, but when does this ever need = to > go over the Security Controller's communication ? [Authors] In IKEless, the sadb_acquire notification carries this = information to the Controller. Basically, what it is happenning is that = the NETCONF server in the NSF captures the sadb_acquire from the kernel = and builds a NETCONF notification which is sent to the Controller. = Having said this, it is true that this is not required anymore since we = know that this type can be only SADB_ACQUIRE since we are sending a = sadb_acquire.=20 >=20 > typedef sadb-msg-satype: same here [Authors] The controller needs to know what IPsec SA should be = negotiated. We have realized that notificiation sabd_acquire should = carry the policy that caused the acquire so that the Controller can know = how to add the IPsec SA. Thus, we propose the following modification to = the sadb_acquire notification: notification sadb_acquire { description "A IPsec SA is required "; uses selector-grouping; container tunnel { when "../mode =3D 'TUNNEL'"; uses tunnel-grouping; description "If TUNNEL mode is used the sadb_acquire = notification carries the endpoints"; } } >=20 > container algorithm-supported: See earlier comments about all moderm = algorithms not having a min/max but only having a limited set, for > current ones this is only 128/192/256 [Authors] Ok. >=20 > Note the version of IKE within the ietf-ipsec namespace only has = IKEv2. I agree with that now but earlier in the document it has IKEv1 > support/entries. So this needs to be made consistent here. [Authors] Correct. We should only keep ikev2 >=20 > container ike-stats: does not contain encaps entry to show if it is = using UDP, TCP or TLS and on which port. [Authors] Are you referrig to the encapsulation of the IKEv2 messages?=20= >=20 > list child-sas: does not contain some "state" that can be negotiated = as part of an IKE session. For example, if narrowing was used, it could > be that the current SPD is more narrow then the "connection" defined = SPD. There seems to be no way to store this. Thus narrowing is not > possible. If narrowing is not in scope here, it should probably be = made more explicit. Otherwise, it needs to be better integrated. [Authors] Basically, we are including a list of child-sas negotiated. = Basically, in terms of implementation, as an example, we would provide = this information with the output, for example, either ip xfrm state list = or using the list-sa event in strongswan = (https://www.strongswan.org/apidoc/md_src_libcharon_plugins_vici_README.ht= ml) >=20 > container number-ike-sas: See earlier note about missing COOKIES = parameter here. >=20 >=20 > SPD related question: Is there support for multiple TSi/TSr generating = a list of spd's in a single Child SA? If so, a Child SA can have > multiple SPDs. Otherwise, it cannot. I dont think the model is very = clear on this aspect. (I speak from experience, libreswan as an > implementation is also not very clearly specified here, and we have = one known interop issue with openbsd's iked because of this) [Authors] So openbsd's iked allows a child SA assocciated to several = policies, right?=20 Regarding your comment " list of spd's in a single Child SA" . Could you = ellaborate a little bit more? The model is not clear in this aspect = since we have not considered this case. Are you referring that a list of = policies are mapped to the same child SA?. In any case, we think this = would be part of the implemenation of the ike model. That is: we are = doing is to inject the SPD entries that have been configured in the SPD = model in the connections defined in the IKEv2 model into the particular = IKEv2 implementation. For example we can use VICI in strongswan for = that. If the IKEv2 implementation is able to associate a list of spd in = single child SA, should the controller be able to say anything about it? = Do you think we should add a flag or something for this? >=20 >=20 > // Those RPCs are needed by a Security Controller in case 2 */ >=20 > Please think about XFRM/netlink and/or ACQUIRE messages that are = needed if there is no IKE daemon. eg when max-counter is reached > or when a hard limit action is performed by the kernel. [Authors] We already have modelled those messages (sadb_acquire is a = notification)=20 notification sadb_acquire { description "A IPsec SA is required "; uses base-grouping; } notification sadb_expire { description "A IPsec SA expiration (soft or hard)"; .... >=20 > I am missing an "SPI already in use" error, in the case it is = attempted to install an SPD that already exists and thus would conflict. >=20 >=20 [Authors] That will happen when the controller sends an NETCONF = edit-config trying to add that an already existing SPI. =46rom NETCONF = rfc "The element is sent in messages if an = error occurs during the processing of an request." Right now, , the spi value is the key element for the list of SAs in the = model for this case, so the NETCONF server will detect it is already = used. If it is already used the NETCONF server considers the SC wants to = "update" de SA, but not to add a new one.=20 =20 It is true that we have NOT defined any explicit "error-message" for = this rpc-error. We will add this. Best Regards. ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_C27FF821-CD48-4BF8-A1FE-34A3663B504C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Paul, all:



Appendix A:

Why is it "eipsec" and not "ipsec=E2=80=9D = ?

[Authors] We have fixed this now.

Why is the organization not the IETF? Is this = commonly done for yang models?

[Authors] You're right. We will change this = to:

"IETF I2NSF (Interface to = Network Security Functions) Working Group"

encryption-algorithm-t - I think this should only list the = MUST/SOULD items, so AES_GCM (1 flavour), AES_CCM (1 flavour) = CHACHAPOLY1305 and NULL

= description "Encryption algorithms -&gt; RFC_5996=E2=80=9D;

[Authors] Right. Our doubt here is if we should = refer instead to 




is doing. If you check this = link you will notice is referring to 

<algorithm = xmlns:ct=3D"urn:ietf:params:xml:ns:yang:ietf-crypto-t\
  =  ypes">ct:rsa2048</algorithm>
  =  
which is referring to ietf-crypto-types


RFC 5996 is an obsolete = reference. It should either refer to RFC 7296, or it should simply refer = to the IANA registry involved.

[Authors] = OK.

integrity-algorithm-t: If the = above is agreed, this enumeration should only contain "none" and the = entries from aes-cmac-96 and up. That is,
not contain = des,md5,sha1 and aes_xcbc.  Same obsolete reference is used here in = the description.

[Authors] Ok.


type-autostartup: Maybe instead of RESPOND-ONLY, a better = word is "STANDBY"? That way, the node could decide itself to bring a = connection up
without _requiring_ a remote signal, and = could be triggered locally as as well as remotely to come up.

[Authors] = Sounds reasonable. We should provide a better description of each value = as well.


=      description "Different types of how IKEv2 = starts the IPsec SAs";

I would say = "different policies of when to start an IKEv2 based IPsec SA". Does it = need clarification this value is ignored or unused for the
"case 2" scenario?

[Authors] = This typedef is not used in the part of the model associated to case 2 = but we can something in the description. 

auth-protocol-type:  This should only contain IKEv2. The = enum should remain in case we get IKEv2.1 or IKEv3 in the future.

[Author] = Agree.


=      description "Peer authentication = protocols=E2=80=9D;

I would say = "IKE authentication protocol version", unless you want to keep the = option open to have a non-IKE protocol. But I think that would
run into many more issues of having parameters that are not = defined for IKE?

[Author] Agree.

ipsec-mode: It = should only contain Tunnel and Transport Mode. It would be nice to see = some text that forbids using Transport Mode when NAT is
requested, just to avoid a lot of problems and = disappointments. L2TP/IPsec still has major scars due to its use of = Transport Mode with NAT.

[Authors] Sounds reasonable.


esp-encap: as stated before, we are missing = the port entry. I can also image that multiple encaps could be allowed, = such as TCP-443 and TLS-443.
Also note that the RFC for = ESP over TCP recommends to continiously check if UDP encapsulation has = become available, since it is so much prefered
over TCP. = But that only makes sense when the remote is a roaming client, and makes = less sense if the network consists of data centers.

[Authors] = Ok. Let's add the port entry. In any case, I believe that is something = that implementation in the NSF (in particular the NETCONF server) could = check (UDP encapsulation)



ipsec-protocol: I think this should only = contain esp. See earlier comments. Notably, if supporting ipcomp here, = the yang model must be clear
that it could need an ipcomp = + esp IPsec SA for a single 'connection'. Even if we only leave esp as a = valid option, keep this enum in case
we come up with a new = esp version of some esp-lite version.

[Authors] = We are in favour on leaving only ESP. If the WG agrees, let's proceed = that way.


lifetime-action = only has "terminate" and "rekey". For libreswan we use "clear", "hold" = and "restart". The difference
between clear and hold is = what kernel policy to install for cleartext packets. For roadwarrionrs = coming in, you
want clear to leave no trace. for a = site-to-site VPN you generally want "hold" to ensure you drop all = packets until
a new tunnel is established (possible = ondemand, so this is different from restart)
[Authors] Basically we have = "terminate" and "rekey" since RFC 4301 says:

"Lifetime of this SA: a time interval after which = an SA must be
      replaced with a new SA (and = new SPI) or terminated, plus an
      = indication of which of these actions should occur."
=  
We are realizing that RFC 4301 should also be updated = to reflect these new possibilities.

In= any case, could you elaborate a little bit more about the difference = between clear and hold and the effect in the kernel? We are assuming = that affects the SAD.


ipsec-traffic-direction:

Traditionally, freeswan ony used inbound/outbound and not = forward. Unfortunately, KAME and Linux/XFRM kept forward there. But I = see no use
case for it in these deployments. We have = nothing specified in about ipsec-sa's for the forward (it's basically = implied "completely open")
But I understand it might be = useful to just specify this because it is needed. But perhaps more = language is then needed to clarify this?

[Authors] = We think this is an implementation aspect. We think it is better to = remove fwd policy. If fwd policy is required because we have an = implementation based on Linux, the NETCONF server should install that = fwd policy based on the in/out received.

ipsec-spd-operation:

The value = BYPASS probably means "let go in the clear" but I don't find the name = very obvious.

[Authors] It has been extracted from RFC 4301 = definition. 

"Processing info = -- which action is required -- PROTECT,
      =        BYPASS, or DISCARD."
=  
In relation with our previous comment we think = it would be worthy to carry out an update in the RFC 4301

The operation modes BYPASS and DISCARD cannot = be configured with the current yang parameters
for IKE? = How would this be configured, eg to place a DISCARD for 192.1.2.0/24 ? =

[Authors] = It is not needed to configure it in the IKE model since it is already = configured in the SPD model. The RFC 4301 defines how the SPD is = composed, and following this, we have defined the SPD model regardless = whether we are in IKE case or IKEless case. In other words, both cases = uses the information contained in the SPD model. Having said this, we = think it would be useful to explicitly "link" each connection in IKEv2 = with the SPD entries associated to that connection. For example, per = each connection we could add a list of spd-entry-id, which point to the = SPD entries associated to that connection. =46rom your comment we have = realized that this issue is not well explained in the = document.

Thus, regardless the case = we are using, the policies establishing the type of traffic and = protection to be applied are indicated in the SPD model (i.e. by means = of a list of spd-entry). So the SPD model is used for both, IKE case and = IKE-less case. Thus, we have the following = situation. 

- For IKE case, the = whole configuration is distributed in two parts. While the IKE SA = configuration is represented as =E2=80=9Cike-conn-entries=E2=80=9D, the = the CHILD SA configuration will be found as a list of = =E2=80=9Cspd-entry=E2=80=9D. 
- For IKE-less case, only = the CHILD SA configuration will be accessible as a list of = =E2=80=9Cspd-entry=E2=80=9D.

What do = you think?



In libreswan
we can configure a = connection with type=3Dtransport|tunnel|drop|reject but that meshes up = the
IPsec Mode with the SPD Operation. It is also a bit = odd to configure "IKE" for a "DISCARD"
since it really = does not define anything in IKE - it bypasses IKE to put in an IPsec = policy
(SPD). But if the yang model used the ipsec parts = to do this, it could be mixing IKE + manual
IPsec = policies, which could really confuse the IKE daemon. I am not sure what = the best fix for
this is. Note REJECT which is = DISCARD+ICMP message is not defined here. Should it? I don't
think Linux/XFRM/netlink supports this.

[Authors] = As we see it, we are not mixing IKE + manual IPsec policies. SPD is the = central point of configuration for IPsec policies in the model. In any = case, we talk about implementation. In particular, when the controller = configures the SPD first and the IKE model with a connection, this = connection will have a list of spd-entry-id to refer to the particular = SPD entries that it has to configure in the IKE daemon associated to = that connection.  About what is happening with drop / reject and = the fix we don't really know either but I think this is not a problem = for the model itself, right? As a note, ip xfrm allows : "allow" or = "block" 

ipsec-next-layer-proto:

See earlier note. I think this is a really bad = name.

[Authors] This is defined in RFC 4301 with this name. = In ip xfrm is UPSPEC.  is Upper Layer Protocol better?

ipsec-spd-nam:

This= is the first time I have seen an SPD as having a name. normally these = just have numbers. Or they
have a number that is the link = between SPD and SAD (with linux, that is called reqid=3D)
So= maybe add an enum id_number so implementors could map this onto the = linux implementation ?

[Authors] RFC 4301 says explicitly in page = 28.

"- Name:  This is not a = selector like the others above.  It is not
    =     acquired from a packet.  A name may be used as a = symbolic
        identifier for an IPsec = Local or Remote address."
"An SPD is an = ordered list of entries each of which contains the
=   following fields.

=           o Name -- a list of IDs.  This = quasi-selector is optional.
      =       The forms that MUST be supported are described = above in
      =       Section 4.4.1.1 under "Name". =E2=80=9C"

But yes, we can = replace this name by other identifier, as you suggest.

auth-method-type:

See earlier = comment about asymmetric authentication.

This= should only contain pre-shared, null, eap, rsa, rfc7427(digital = signatures). That is I think dss-signature can be removed.
I= also wonder if this entry needs to have a better difference for the = source of the private/public keypair, eg raw RSA versus
RSA = certificate based authentication. I guess this is now implied by not = having a certificate entry?

[Authors] Mmmmm... good question. We think we = should include at least a "raw public key" leaf so if the leaf is set = then we have raw public key. If we include certificate then we will have = RSA certificate based authentication. In any case, if ECC-based = signature is required we would also need to support ECC public and = private keys. In any case, this part in the model needs to be udpated to = support RFC 7670 and RFC 7427

 There is also another aspect: if eap is = chosen, what eap method is allowed. I think a container mentioning the = EAP method should  be included. Moreover, we should include a way = to send the credentials for the particular EAP method.


Also rename description "Peer authentication = method" to "IKE authentication method" (it should mention this is IKE, = but also
in case of asymmetric use, this is not = neccessarilly for the peer but how we authenticate _to_ the peer)

[Authors] = Sounds reasonable


sa-state: =  I am not sure why this is needed? Unless someone would want to = manually place larval/acquire states in the kernel
without = IKE, but then who is going to listen to these ACQUIRE messages? A = non-IKE daemon? See earlier discussion on this topic.
If = you do want to get netlink/pf_key messages for max-counter, max-bytes = etc without IKE, then this would be required. Otherwise
this= should be removed.

[Authors] This is precisely what we want: "to get = netlink/pf_key messages for max-counter, max-bytes etc without IKE" . = This is captured by the NETCONF server to send notifications to the = controller in IKEless case. Having said this, most probably this state = is not completely required though as we mentioned in section 6's = comments , the IPsec SA appears in the state. It seems too much detail = for the regular operation of the controller, even considering IKEless = case.

lifetime: See earlier = comments.

grouping auth-method-grouping: = See earlier comments about asymmetric authentication and raw vs cert = based signatures. Note based
on above entries, this is = missing a dss-signature section. So if you agree with earlier comment to = remove dss-signature, then
it not appearing here is = fine.

[Authors] Yes, we are going to remove dss-signature and = extend the auth-method container to contemplate the use of raw public = keys as well as generic digital signatures (rfc 7427).

grouping identity-grouping:  See earlier = comments on ID_NULL / AUTH_NULL support

[Authors] = We failed to see this earlier comments about ID_NULL and AUTH_NULL, = could you point us to them?



grouping port-range: I don't see anywhere that = protocol and ports together are "overloaded" for things like ICMP = message types.
Should language be added for that?

[Authors] = Not sure what are you are referring here... could you elaborate? We have = seen that description should be changed as well.

SAD and SPD grouping : See earlier note about Security = Labels. It would need to be added here. Linux/XFRM already supports = these.

[Authors] Not sure about this. Right now, the usage of = security labels seems associated to specific implemenation (Linux/XFRM) = and https://tools.ietf.org/html/draft-sprasad-ipsecme-labeled-ipsec= -00 has not been evolved since March 2018 (is it going to be = adopted?).

I see container-ah and = container-esp, but what about container-ipcomp? Again, if we remove = IPCOMP as I'd like, then we are fine
here. but if not, = then something needs to be added here. If AH is removed as I'd = recommended, it needs to be removed here.

[Authors] = That's right. We think we could remove that ipcomp and ah if the WG is = agree.

container sad-lifetime-soft {
         = description "SAD lifetime hard state data";

that "hard" should be "soft=E2=80=9D.

[Authors] = Right.

I am confused that "hard" and = "soft" have an action that can be similar. soft could have an action to = just notify userland via
XFRM/PF_key, but "hard" can only = have an option "terminate=E2=80=9D ?

[Authors] = Your comment makes sense. 

container = encap: Now I see the sport / dport, but I'm still confused how this is = populated from the higher level Security Controller
communication (if not IKE). Note also the Security = Controllers cannot know the port numbers without sending any traffic so = the
NAT gateway crates a mapping.

[Authors] = As mentioned earlier, this can be informed by the NSF through a YANG = module related with NAT management. 

list traffic-selector-list: Can a traffic selector have a = direction of fwd ? Not in the IKE protocol.

[Authors] = fwd direction has been removed now.

=            leaf = mode { type ipsec-mode; description "transport/tunnel"; }

[Authors] = True. We will add them but removing BEET.

This "description" does not match all the available options = defined before.

container ah-algorithms: = See AH comments before. Also see IPCOMP comments before.

[Authors] = As mentioned we are in favour of removing AH and IPCOMP if the WG agrees = on that.


= description "Configure ESP encryption"

Maybe say "Configure ESP/AEAD = encryption=E2=80=9D

[Authors] This would be applicable if we finally agree = that only AEAD will be used. But in the last e-mail exchange in the = mailing list, it looks like we are not limiting us to a case where only = AEAD is allowed. 

spd-mark:

Note that the IKE case cannot negotiate this = spd-mark value. Is such a capability needed? It is similar to = negotiating a Security Context.

[Authors] = It is in linux kernels and handled by XFRM but we think you're right and = we could remove it from the model. In any case, do you think there is an = important example case for its usage?


container spd-lifetime-*: See earlier comments = on hard/soft and acceptable actions

[Authors] = OK.

grouping isakmp-proposal: I = would call this ike-proposal as isakmp is kind of an IKEv1 term. See = also phase1-* value suggestions earlier to
make those = ike-* or ike-sa-* values. This group is also missing pfs=3D which for = IKEv2 only starts to matter when rekeying and whether or not
to do a new DH.
[Authors] Agree. We will change the name. Also true = about pfs. We will add this information.


grouping phase2-info: Call this ipsec-info: or = ipsec-sa-info:

[Authors] Correct. As mentioned we think it would be = better if this ipsec-sa-info has a lists of spd-entry-id pointing the = SPD policies associated.

leaf-list = pfs_group { type uint32;



This should really be an enum = and not a uint32.

[Authors] Ok. We will change it.

typedef sadb-msg-type: where/when are these = used? That is, I understand the IKE <-> IPsec API uses this, but = when does this ever need to
go over the Security = Controller's communication ?

[Authors] = In IKEless, the sadb_acquire notification carries this information to = the Controller. Basically, what it is happenning is that the NETCONF = server in the NSF captures the sadb_acquire from the kernel and builds a = NETCONF notification which is sent to the Controller. Having said this, = it is true that this is not required anymore since we know that this = type can be only SADB_ACQUIRE since we are sending a = sadb_acquire. 

typedef = sadb-msg-satype: same here
[Authors] The controller needs to know what IPsec = SA should be negotiated. We have realized that notificiation = sabd_acquire should carry the policy that caused the acquire so that the = Controller can know how to add the IPsec SA. Thus, we propose the = following modification to the sadb_acquire notification:

notification sadb_acquire {
  =     description "A IPsec SA is required ";
  =     uses selector-grouping;
=  container tunnel {
        =   when "../mode =3D 'TUNNEL'";
  =         uses tunnel-grouping;
  =         description "If TUNNEL mode is used the = sadb_acquire notification carries the endpoints";
  =      }
   }

container algorithm-supported: See earlier comments about all = moderm algorithms not having a min/max but only having a limited set, = for
current ones this is only 128/192/256

[Authors] = Ok.

Note the version of IKE within = the ietf-ipsec namespace only has IKEv2. I agree with that now but = earlier in the document it has IKEv1
support/entries. So = this needs to be made consistent here.
[Authors] Correct. We should only = keep ikev2


container = ike-stats: does not contain encaps entry to show if it is using UDP, TCP = or TLS and on which port.

[Authors] Are you referrig to the encapsulation of the = IKEv2 messages? 

list = child-sas: does not contain some "state" that can be negotiated as part = of an IKE session. For example, if narrowing was used, it could
be that the current SPD is more narrow then the "connection" = defined SPD. There seems to be no way to store this. Thus narrowing is = not
possible. If narrowing is not in scope here, it should = probably be made more explicit. Otherwise, it needs to be better = integrated.

[Authors] Basically, we are including a list of = child-sas negotiated. Basically, in terms of implementation, as an = example, we would provide this information with the output, for example, = either ip xfrm state list or using the list-sa event in strongswan (https://www.strongswan.org/apidoc/md_src_libcharon_plugins_vici= _README.html)

container number-ike-sas: See = earlier note about missing COOKIES parameter here.


SPD related question: Is there support for = multiple TSi/TSr generating a list of spd's in a single Child SA? If so, = a Child SA can have
multiple SPDs. Otherwise, it cannot. I = dont think the model is very clear on this aspect. (I speak from = experience, libreswan as an
implementation is also not = very clearly specified here, and we have one known interop issue with = openbsd's iked because of this)

[Authors] = So openbsd's iked allows a child SA assocciated to several policies, = right? 

Regarding your comment = " list of spd's in a single Child SA" . Could you ellaborate a little = bit more? The model is not clear in this aspect since we have not = considered this case. Are you referring that a list of policies are = mapped to the same child SA?. In any case, we think this would be part = of the implemenation of the ike model. That is: we are doing is to = inject the SPD entries that have been configured in the SPD model in the = connections defined in the IKEv2 model into the particular IKEv2 = implementation. For example we can use VICI in strongswan for that. If = the IKEv2 implementation is able to associate a list of spd in single = child SA, should the controller be able to say anything about it? Do you = think we should add a flag or something for this?


// Those RPCs are needed by a = Security Controller in case 2 */

Please = think about XFRM/netlink and/or ACQUIRE messages that are needed if = there is no IKE daemon. eg when max-counter is reached
or = when a hard limit action is performed by the kernel.

[Authors] = We already have modelled those messages (sadb_acquire is a = notification) 

notification = sadb_acquire {
      description "A IPsec SA is = required ";
      uses = base-grouping;
   }

   notification sadb_expire = {
      description "A IPsec SA expiration = (soft or hard)";
 ....


I am missing an "SPI already = in use" error, in the case it is attempted to install an SPD that = already exists and thus would conflict.



[Authors] That will happen when the = controller sends an NETCONF edit-config trying to add that an already = existing SPI. =46rom NETCONF rfc  "The <rpc-error> element is = sent in <rpc-reply> messages if an error
  =  occurs during the processing of an <rpc> = request."

Right now, , the spi value = is the key element for the list of SAs in the model for this case, so = the NETCONF server will detect it is already used. If it is already used = the NETCONF server considers the SC wants to "update" de SA, but not to = add a new one. 
   
It is true that = we have NOT defined any explicit "error-message" for this rpc-error. We = will add this.

Best = Regards.

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_C27FF821-CD48-4BF8-A1FE-34A3663B504C-- From nobody Tue Dec 11 04:49:04 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2EA128A6E for ; Tue, 11 Dec 2018 04:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 W0_Sq4YexlDT for ; Tue, 11 Dec 2018 04:49:01 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D762D127333 for ; Tue, 11 Dec 2018 04:49:00 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id n18so10672339lfh.6 for ; Tue, 11 Dec 2018 04:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=X1zEivJgqwXXgyXrpDXFKBFlpwd+g5RZtECbnQXqmqc=; b=PuCAhntEGLclAYoDx18xUxBYjaxPTUG519ROienOiWd75oco7HSJZ2s7lL8fCKc7VS ULyPAJlHyefFiTLjMnwfO25Dl1w6ZYz9YGyH8NRzW2HJAillYN5v4PTBRdS2kntFn/8W 9xEx2zD/q4n/Lh+23TGxa+iZ7PZo9o3TgClUjWruzowwprAudzH265rFxQyTNEWOtf3G YXgxp1f1p80BzU9zGqZVsg8LwZkL5mAg78iqGhbj1L3il32Fn3G9kXzjtFuWEwZ4Fodz HjJ5pNFAuAotluTcy9p9Y8gW9WLZmh5Kr9pqCXhwPAlDo8dGBSs+RwnLX30jULPtx1CP Elcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=X1zEivJgqwXXgyXrpDXFKBFlpwd+g5RZtECbnQXqmqc=; b=Q/3sghqz90c4zAdYY0X8Rg1jYKYZfDTspsatD8I58frlmtAr8JcshnVH7TUggFhipK 7jwV6Gqnnz+XocCtqhdZOduimwgNB+wqqe+6qDR15KLAjvFVEvbo+iifcgLoBSMC6jdK 5uxIOCMvYJOr+hQdPKDAAmc4xmbJVsOksawsxSThfSghIiz9j2clMdGAK6n5lnsOF9fj sjB5RYJh0O007sUQWxpB4UkcwO5TmbM4FMZ5KFXXC60MI/Vbo4WfG/LV06evhPdOrGu6 jVRYFiFhFhWgxcUPIbZXjKoX7uT8xHLpD0nxpykodI05XrM6pzc8gqYKbDz0jbbX1tdh d9EQ== X-Gm-Message-State: AA+aEWbJTmWDafdpN+LKUnDm+HTY8KHjUHFlPJI/3gcdz6Gz1rWgAoVW crm7nJwUTdProtDmvg8Ra8xP1+Az X-Google-Smtp-Source: AFSGD/VDbb3bEawKi+oMXakTMVfSnLiAqkz+daddF6OwBl+oEMGMadQB6rYYi2Qb5LPj7VFkQdfOZw== X-Received: by 2002:a19:aace:: with SMTP id t197mr9082938lfe.7.1544532538706; Tue, 11 Dec 2018 04:48:58 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e19-v6sm2710143ljf.67.2018.12.11.04.48.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 11 Dec 2018 04:48:58 -0800 (PST) From: "Valery Smyslov" To: "'Michael Richardson'" Cc: "'Paul Wouters'" , "'Nico Williams'" , References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> <035701d49149$71640f10$542c2d30$@gmail.com> <2503.1544530985@localhost> In-Reply-To: <2503.1544530985@localhost> Date: Tue, 11 Dec 2018 15:48:52 +0300 Message-ID: <037201d4914f$dee01ba0$9ca052e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJjEIcGzPEj/22sYW2hroPcukYuWAIvYqvHAie7eo0BeQS8egHtaQHgAjk9efMBSdV9YgFBY3HbAUinL/Kj7id4QA== Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 12:49:03 -0000 > > I think that using PAKE for road warriors is more important than for > > site-to-site VPNs. In the latter case the SGWs are usually administered > > by (presumably :-)) experienced administrators, who can select a high-entropy > > PSK, and these PSKs need not to be memorable by users. So, generally > > speaking, > > it is more secure to use good PSK than passwords (since any PAKE defends > > only > > If we assume highly competent administrators, then we don't need a PAKE > at all. For remote access where certificates or raw public key cannot be used, PAKE is extremely useful. > What I heard from the IPsecME record was that many in the room > felt that this was where ther was a weakness. I see this as a social issue, not a technical one. We can't prevent administrators from being careless, either with PSKs or with passwords. From nobody Tue Dec 11 10:52:50 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEFA130F17; Tue, 11 Dec 2018 10:52:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=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 qpBoF7vFfhYI; Tue, 11 Dec 2018 10:52:46 -0800 (PST) Received: from telmad-lavadora-l1mail1v.puc.rediris.es (te-l1mail1v-out02a.puc.rediris.es [IPv6:2001:720:418:ca03::76]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD07130F20; Tue, 11 Dec 2018 10:52:45 -0800 (PST) X-IPAS-Result: =?us-ascii?q?A2EXAACEBhBcjNMUgNRkHAEBAQQBAQcEAQGBUQcBAQsBg2u?= =?us-ascii?q?EIoEdhnxfl0iNSoF6DYRsAoMPNAkNAQMBAQEBAQECAgIQAQEBJliFPgMDI1YQC?= =?us-ascii?q?QIEBzcCAiISAQUBHIM6ggIEiimQBzyLDYEviSGBDo5RgRGDEogFglcCiSkSjDu?= =?us-ascii?q?LBQcCkVEYgVyFF4pNgwGWIw8hgSU3gVgzgT4GgjaCNBuODD6MHQEB?= X-IronPort-AV: E=Sophos;i="5.56,343,1539640800"; d="scan'208,217";a="244847433" Received: from mail.upct.es (HELO relay1.si.upct.es) ([212.128.20.211]) by smtpout.puc.rediris.es with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Dec 2018 19:52:43 +0100 Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by relay1.si.upct.es (Postfix) with ESMTPSA id 5DDF21CD25; Tue, 11 Dec 2018 19:52:37 +0100 (CET) Received: by mail-it1-f177.google.com with SMTP id m8so11588070itk.0; Tue, 11 Dec 2018 10:52:37 -0800 (PST) X-Gm-Message-State: AA+aEWZe0yo4M+RVnRJ6+TOyFnwvTEBxjLzWh8s7RbeStAgQsE+cKMYS dsCDeb+npD/E8FVK3VvfCIDuJly0zXZhZzC6nVc= X-Google-Smtp-Source: AFSGD/VAjnAb5tvmGmQ4fh6fg7p7T+Xk+gacHUjx+8rMoJ99FfOwy7fjIsuTnF+qHWAnoksBuE11oqoyLjPDODQC/UA= X-Received: by 2002:a24:1a90:: with SMTP id 138mr3114739iti.171.1544554346012; Tue, 11 Dec 2018 10:52:26 -0800 (PST) MIME-Version: 1.0 References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> In-Reply-To: From: =?UTF-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= Date: Tue, 11 Dec 2018 19:52:13 +0100 X-Gmail-Original-Message-ID: Message-ID: To: paul@nohats.ca Cc: ynir.ietf@gmail.com, i2nsf@ietf.org, ipsec@ietf.org, Rafa Marin Lopez , =?UTF-8?Q?Gabriel_L=C3=B3pez_Mill=C3=A1n?= Content-Type: multipart/alternative; boundary="000000000000216657057cc395a4" Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Sections 8 - 9) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 18:52:49 -0000 --000000000000216657057cc395a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Paul, all, Next you can find our answers to your comments on sections 8 and 9. Section 8: Is this section supposed to be an "Implementation Details" Section as per RFC 7942? If so, it is missing the required note to the RFC Editor to remove the entire section before publication as RFC. [Authors] Agree. We will include it. Section 9.1: In case 1, add a note to use only strong PSKs, with a minimal length and strength. [Authors] Agree. We will add it. Section 9.2: when ESP is used Hoping my advise is taken to only use ESP and not AH, and to use ESP-null in the case of encryption being unwanted, please remove this comment as ESP would always be used. includes the keys for integrity and encryption If we only allow AEAD's, maybe rewrite or leave this out. [Authors] s/"In the case 2, the controller sends the IPsec SA information to the SAD that includes the keys for integrity and encryption (when ESP is used)" / "In the case 2, the controller sends the IPsec SA information to the SAD that includes the required cryptographic keys for ESP or AH" Regards, Fernando. --=20 ---------------------------------------------------------------------------= ------------------------- Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa, PhD Department of Sciences and Informatics University Defense Center, (CUD), San Javier Air Force Base, MDE-UPCT C/ Coronel Lopez Pe=C3=B1a, s/n, 30720, San Javier, Murcia - SPAIN Tel: +34 968 189 946 Fax: +34 968 189 970 ---------------------------------------------------------------------------= --------------------------- --000000000000216657057cc395a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul, all,

Next you can find our answers to your comments on sections 8 and 9= .=C2=A0


Section 8:
<= br>
Is this section supposed to be an "Implementation Detail= s" Section as per RFC 7942? If so, it is missing the required
note to the RFC Editor to remove the entire section before publication as= RFC.

[Authors]

Agree. We= will include it.


Sectio= n 9.1:

In case 1, add a note to use only strong PS= Ks, with a minimal length and strength.

[Authors]<= /div>
Agree. We will add it.

Section 9.2:

when ESP is us= ed

Hoping my advise is taken to only use ESP and n= ot AH, and to use ESP-null in the case of encryption being unwanted, please=
remove this comment as ESP would always be used.

<= /div>
includes the keys for int= egrity and encryption

If we only allow AEAD's,= maybe rewrite or leave this out.

[Authors]
<= div>
s/"In the case 2, the controller sends the IPsec SA= information to the SAD that includes the keys for integrity and encryption= (when ESP is used)" /=C2=A0
"In the case 2, the contro= ller sends the IPsec SA information to the SAD that includes the required c= ryptographic keys for ESP or AH"


Regards,
Fernando.

=C2=A0
--
=
---------------------------------------------------------= -------------------------------------------
Fernando Pere=C3=B1=C3=ADguez Garc= =C3=ADa, PhD
Department of Sciences and Informatics
University Defens= e Center, (CUD), San Javier Air Force Base, MDE-UPCT
C/ Coronel Lopez Pe= =C3=B1a, s/n, 30720, San Javier, Murcia - SPAIN
Tel: +34 968 189 946 Fax= : +34 968 189 970
------------------------------------------------------= ------------------------------------------------
--000000000000216657057cc395a4-- From nobody Tue Dec 11 12:25:41 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8DC7130F7E for ; Tue, 11 Dec 2018 12:25: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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 Pz1QjITuP7WH for ; Tue, 11 Dec 2018 12:25:33 -0800 (PST) Received: from common.maple.relay.mailchannels.net (common.maple.relay.mailchannels.net [23.83.214.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86DBC130F67 for ; Tue, 11 Dec 2018 12:25:31 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5F08D3E4A67; Tue, 11 Dec 2018 20:25:30 +0000 (UTC) Received: from pdx1-sub0-mail-a63.g.dreamhost.com (unknown [100.96.35.77]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C09FA3E4D51; Tue, 11 Dec 2018 20:25:27 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a63.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.16.2); Tue, 11 Dec 2018 20:25:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Abortive-Whistle: 6c914f162737e882_1544559928006_2747823817 X-MC-Loop-Signature: 1544559928006:1561097966 X-MC-Ingress-Time: 1544559928005 Received: from pdx1-sub0-mail-a63.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a63.g.dreamhost.com (Postfix) with ESMTP id 9C3DA807D2; Tue, 11 Dec 2018 12:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=8mOLWCl/iKVsnHMjpFt1mc3QDB0=; b=O7bjNjRQ88f uyxzKxEOEeQaKfWCYcepIGifD+AgSMA4zkRuZQqqDOJtQ83LkfLmcrgAoCQ//GQK itPMApPIPUzIyfVYzrqA1IL6hJ7PodnWbLep5Vb8bTC4oL0YFnOb0TECMTSrip+O f8BBFq2wssCvLXBmtTVP2SQ/q3YBbwS4= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 3744F807D0; Tue, 11 Dec 2018 12:25:22 -0800 (PST) Date: Tue, 11 Dec 2018 14:25:19 -0600 X-DH-BACKEND: pdx1-sub0-mail-a63 From: Nico Williams To: Michael Richardson Cc: ipsec@ietf.org, Paul Wouters Message-ID: <20181211202518.GG15561@localhost> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <24842.1544489482@localhost> <8D5228D2-EF4B-4504-888F-BEB202DB6634@nohats.ca> <14559.1544494854@localhost> <20181211042838.GF15561@localhost> <2076.1544530886@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2076.1544530886@localhost> User-Agent: Mutt/1.5.24 (2015-08-30) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrudegjedgudefjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 20:25:41 -0000 On Tue, Dec 11, 2018 at 07:21:26AM -0500, Michael Richardson wrote: > Nico Williams wrote: > > On Mon, Dec 10, 2018 at 09:20:54PM -0500, Michael Richardson wrote: > > > Paul Wouters wrote: > > > > > yes, typo, "not for road-warrior" > > > > > > > > I understood. I disagree with the =E2=80=9Cnot=E2=80=9D. Road war= riors using > > > > group psk is a thing, sadly. > > > > > > But they aren't cross-domain, they can do EAP-foobar, and they > > > could use a certificate without a lot of hassle about what set of > > > trust anchors. > > > > > > If we stick to the site-to-site then I think we can do something > > > rather simple and quick, and our security considerations section > > > will be much simpler. > > > > I mean, if road warriors should always be using either EAP or user > > certs, then we don't need PAKE for anything because presumably the > > shared keys used in PSKs are strong enough that PAKEs don't improve > > security and only slow things down... >=20 > It's the enterprise-to-enterprise connection that is hard to convert > to certificates for the reasons that Paul explained. Is it not better to think of it as federation? Is it not federation? > > (I'm assuming you mean to use an EAP method like EAP-PWD (RFCs 5931 a= nd > > 8146), yes?) > > > > Assuming you can always use EAP, the only real reasons to use a PAKE = in > > IKEv2 are: > > > > - you're not entirely sure that you don't have weak PSKs and would l= ike > > to strengthen them >=20 > I think that this is the major reason. OK, but you can always convert the real weak PSKs to either PK-{I,raw} or EAP depending on whether the "client" is a user or not and/or its capabilities. I'e, this reason doesn't seem pressing, unless what's pressing is that somehow a non-EAP PAKE would be much less work for some implementors or operators (or users) than EAP (w/ EAP-PWD or equivalent). The moment someone says "and let's add OTP" I think EAP is definitely the better answer if it already ticks all the capability boxes. > > - you don't always want EAP for users who don't have certs for reaso= ns > > that escape me > > > > (I wouldn't object, but if EAP fits the bill as to PAKE already, t= hen > > thw WG could object to spending its resources on adding PAKE to > > IKEv2.) >=20 > I think that a user-oriented PAKE is more useful if it can be > backended into a AAA infrastructure, which EAP can. I tend to agree. The only case where that's not true is when you have a site that doesn't already have RADIUS/DIAMETER/WHATEVER AAA infrastructure and would rather not deploy one. Not sure the WG should cater to such users. > A site-to-site PAKE is more useful if it isolated from any AAA > infrastructure. Sure, but does this WG want to cater to that? I think a reasonable compromise would be to add a PAKE (both options, balanced and augmented) but no second factor support. Nico --=20 From nobody Tue Dec 11 12:57:45 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DABA12E036 for ; Tue, 11 Dec 2018 12:57:43 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 ULG1yCiMj9ir for ; Tue, 11 Dec 2018 12:57:41 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11EDF124D68 for ; Tue, 11 Dec 2018 12:57:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43Dshd6Xr1zG8V; Tue, 11 Dec 2018 21:57:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1544561857; bh=4o/pz1MtC4JSDy9BPHBC992Shyu0VMDasRLjdAkoa2Q=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ADWwRAD/VktlGFxGberJqXb0VSk/6G2u2aLJBp+iBgZRRipC82xLX6eKxrwu9R/tq yP3jBFsRqaD1O3x/nLVuJVZTfDzOkT57TnplMSMksVrwwwnw3/TLhB+ePajN5IAwjc vfx0ehvuAVP66hsgk3uAFS+D5XnL9p9mGvwhYfrU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id adumCtdUnX7K; Tue, 11 Dec 2018 21:57:36 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Dec 2018 21:57:35 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id BA2422E75A2; Tue, 11 Dec 2018 15:57:34 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca BA2422E75A2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AD3C3407AA79; Tue, 11 Dec 2018 15:57:34 -0500 (EST) Date: Tue, 11 Dec 2018 15:57:34 -0500 (EST) From: Paul Wouters To: Nico Williams cc: Michael Richardson , ipsec@ietf.org In-Reply-To: <20181211202518.GG15561@localhost> Message-ID: References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <24842.1544489482@localhost> <8D5228D2-EF4B-4504-888F-BEB202DB6634@nohats.ca> <14559.1544494854@localhost> <20181211042838.GF15561@localhost> <2076.1544530886@localhost> <20181211202518.GG15561@localhost> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 20:57:43 -0000 On Tue, 11 Dec 2018, Nico Williams wrote: >>> - you're not entirely sure that you don't have weak PSKs and would like >>> to strengthen them >> >> I think that this is the major reason. > > OK, but you can always convert the real weak PSKs to either PK-{I,raw} > or EAP depending on whether the "client" is a user or not and/or its > capabilities. I hate the idea of turning weak PSKs, possibly already logged by nation states, and turn these into PAKEs. I would really hope people do NOT do that or part of the point of obsoleting PSK's for PAKEs is lost. > I'e, this reason doesn't seem pressing, unless what's pressing is that > somehow a non-EAP PAKE would be much less work for some implementors or > operators (or users) than EAP (w/ EAP-PWD or equivalent). Yes. Please no EAP where possible. > The moment someone says "and let's add OTP" I think EAP is definitely > the better answer if it already ticks all the capability boxes. That I can agree too. In general, the OTP use case is a really a deployment with a human driver in the seat, and not site-to-site or mesh-node encryption. It's almost always remote access vpn within the same organisation. >>> (I wouldn't object, but if EAP fits the bill as to PAKE already, then >>> thw WG could object to spending its resources on adding PAKE to >>> IKEv2.) As explained before. site to site has no way of doing EAP in practise. > I tend to agree. The only case where that's not true is when you have a > site that doesn't already have RADIUS/DIAMETER/WHATEVER AAA > infrastructure and would rather not deploy one. Not sure the WG should > cater to such users. That is a common case, imagine your 4 home users connecting back to your simple home vpn gateway. >> A site-to-site PAKE is more useful if it isolated from any AAA >> infrastructure. > > Sure, but does this WG want to cater to that? Yes we do! One of the goals was to get PSK phased out. So to me this is the primary use case. > I think a reasonable compromise would be to add a PAKE (both options, > balanced and augmented) but no second factor support. I have been convinced this is likely the right way forward. Paul From nobody Tue Dec 11 12:59:28 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0970E130F14; Tue, 11 Dec 2018 12:59:20 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 C1vaSJMjihmF; Tue, 11 Dec 2018 12:59:18 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642AE12E036; Tue, 11 Dec 2018 12:59:18 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43DskY0lSyzG8X; Tue, 11 Dec 2018 21:59:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1544561957; bh=6hx1lXi/ZwAqUY67vHPT43p/jFMNry4gV4+0lj0mibI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XMFYTZlTtLvCK8OUFyXxM7aBhuETvoi98iLd2K2uM84+oCK2CU8HB1LoKPDv2DEAf lVlKn48+A9jeHZQkjbb+vsDEiyf37fEBGDW/ZQQBz4O2TOFKgX5G2jCq2Zhm2xLwXY iKM1UFwzsuE+PYs1QYCXMzMI9CUQfLWV2IoM2t1A= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id N1teXh0kb46A; Tue, 11 Dec 2018 21:59:16 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Dec 2018 21:59:16 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id F42202E75A2; Tue, 11 Dec 2018 15:59:14 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca F42202E75A2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EB906407AA79; Tue, 11 Dec 2018 15:59:14 -0500 (EST) Date: Tue, 11 Dec 2018 15:59:14 -0500 (EST) From: Paul Wouters To: =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez_Garc=EDa?= cc: ynir.ietf@gmail.com, i2nsf@ietf.org, ipsec@ietf.org, Rafa Marin Lopez , =?ISO-8859-15?Q?Gabriel_L=F3pez_Mill=E1n?= In-Reply-To: Message-ID: References: <6839D47C-4074-486F-9350-8EB7B378036C@um.es> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 (Sections 8 - 9) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 20:59:20 -0000 On Tue, 11 Dec 2018, Fernando Pereñíguez García wrote: These answers look fine. Thanks. Paul (the other emails will take a little more time :) > Date: Tue, 11 Dec 2018 13:52:13 > From: Fernando Pereñíguez García > Cc: ynir.ietf@gmail.com, i2nsf@ietf.org, ipsec@ietf.org, > Rafa Marin Lopez , Gabriel López Millán > To: paul@nohats.ca > Subject: Re: [I2nsf] Review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-03 > (Sections 8 - 9) > X-Spam-Flag: NO > > Hi Paul, all, > Next you can find our answers to your comments on sections 8 and 9.  > > > Section 8: > > Is this section supposed to be an "Implementation Details" Section as per RFC 7942? If so, it is missing the required > note to the RFC Editor to remove the entire section before publication as RFC. > > [Authors] > > Agree. We will include it. > > > Section 9.1: > > In case 1, add a note to use only strong PSKs, with a minimal length and strength. > > [Authors] > Agree. We will add it. > > Section 9.2: > > when ESP is used > > Hoping my advise is taken to only use ESP and not AH, and to use ESP-null in the case of encryption being unwanted, please > remove this comment as ESP would always be used. > > includes the keys for integrity and encryption > > If we only allow AEAD's, maybe rewrite or leave this out. > > [Authors] > > s/"In the case 2, the controller sends the IPsec SA information to the SAD that includes the keys for integrity and encryption (when ESP is used)" /  > "In the case 2, the controller sends the IPsec SA information to the SAD that includes the required cryptographic keys for ESP or AH" > > > Regards, > Fernando. > >   > -- > ---------------------------------------------------------------------------------------------------- > Fernando Pereñíguez García, PhD > Department of Sciences and Informatics > University Defense Center, (CUD), San Javier Air Force Base, MDE-UPCT > C/ Coronel Lopez Peña, s/n, 30720, San Javier, Murcia - SPAIN > Tel: +34 968 189 946 Fax: +34 968 189 970 > ------------------------------------------------------------------------------------------------------ > > From nobody Tue Dec 11 17:35:35 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95FC130FD1 for ; Tue, 11 Dec 2018 17:35:32 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 HQZwJ0DFY4yE for ; Tue, 11 Dec 2018 17:35:30 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0225B124D68 for ; Tue, 11 Dec 2018 17:35:30 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43DzsB5YmQzG91; Wed, 12 Dec 2018 02:35:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1544578526; bh=FE9AAEg0feLxK+Fhk/XZfuP7zybeCCL2hHlatZEUKEc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fkyyjNxMfnsK5CWUdi5krMThh3qwAI1YrRSNfFZxiK1puA3X2osJagC7U2wUu7dCX +kvAtVHKm/dNKBRD9X3wXbKqIlRQbZ7+nW4LgrDGt07lfJ2CbPk1i0G2IFsbOTYNKR tbZDE2UWzx6eFRzr4XehhlmuBovn/oKcfxbwiwf8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Pewf6BgEYWik; Wed, 12 Dec 2018 02:35:25 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 12 Dec 2018 02:35:24 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8CABD2E75A2; Tue, 11 Dec 2018 20:35:23 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8CABD2E75A2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 82260407AA79; Tue, 11 Dec 2018 20:35:23 -0500 (EST) Date: Tue, 11 Dec 2018 20:35:23 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: 'Michael Richardson' , 'Nico Williams' , ipsec@ietf.org In-Reply-To: <037201d4914f$dee01ba0$9ca052e0$@gmail.com> Message-ID: References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> <035701d49149$71640f10$542c2d30$@gmail.com> <2503.1544530985@localhost> <037201d4914f$dee01ba0$9ca052e0$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 01:35:33 -0000 On Tue, 11 Dec 2018, Valery Smyslov wrote: >> What I heard from the IPsecME record was that many in the room >> felt that this was where ther was a weakness. > > I see this as a social issue, not a technical one. We can't prevent > administrators from being careless, either with PSKs or with passwords. We can make more secure deployments easier. If the only change on the site-to-site config is to change the keyword "psk" to "pake" and that prevents offline dictionary attacks, that's an easy win. I care a little less for group psk's because well, it is a group so even a pake won't buy us that much extra if dozens or thousands of people have the pake secret. Paul From nobody Wed Dec 12 01:02:57 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3BA131128 for ; Wed, 12 Dec 2018 01:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 2MXDTWn7PJ4x for ; Wed, 12 Dec 2018 01:02:53 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD1F12F295 for ; Wed, 12 Dec 2018 01:02:53 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id e5-v6so15583258lja.4 for ; Wed, 12 Dec 2018 01:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=Hz3+nN2bzmpYB9TPNqNDItmHoadurmoXS2Fun8ymlzQ=; b=J9RC17af5NQMY9rbRKHAt0PNE88N5nRs0sln6KkpXKJIxzMA1JctBr6uTZd5VJV83w LGxW/adVFAjx4LrZSWnh8AURTNUSLfkmkg4D+h9zcDsX4Dk+ZQXQ9VjDw5aF6oPdG/m1 1OtlnUwNIaGtkOLMdIZKYfeADBulAMcnceYC8TqxlPoG4VTkY6oS250vAX7QZxOpl3Xz OYGqNhiFRw4OH0sp9hg9iWja52354F2wN1XAnnAQ9ik4Jme1Hehlr4WMjcV8HhvT3/QT ME03WxtQsfI9pjlaqa8KT5XLjT/+jp/+wHjZ3lw/FFwKq7Q7PPG7wQMxd26z0/PEpmaO djfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=Hz3+nN2bzmpYB9TPNqNDItmHoadurmoXS2Fun8ymlzQ=; b=O26mcaYfhresjur2M2R3qt5G4/QBhx8PbAStumrEzlIFY0VsVlQazxPJdFCMeLCjfY SHr3HvE+sKtCstII2sJuyplNk6ZlXYSr1DhyToONHWpDmesTQ7FCABVDhUURDM8BV2T+ 9Le8q6MCTn6umXKqBzBA0MIwit5LOBb3ddiDSzRaNuO8Wwglt6+cEYbVMx+JjsnlyRbe Ya3wH71bmv3j0vafR4vcDblAmsfpRBkgRTNkMblPTDfVQtwH7SB1ewhQEw1uPsebHD73 xX7U2S5dhvjgVNsVH1yqcmNrUPTpQAxCphp+sRQqJAWXw5fFmODS6ag8ktk+/dB+iJT+ idXg== X-Gm-Message-State: AA+aEWZ99lmS03r6lnmJyHbBqYAiB1t8XxGdnMoHPYbruEadIGSuuKd9 /lKU85A+fhUnSMd/m9ZDhF5eo54b X-Google-Smtp-Source: AFSGD/VdcCb3mrusIz+EM0IPF4MmZltDwcq8B+ciFvg4lL4Wan7l8Jr2zWeRhHLXi5ymSgIZwl/guA== X-Received: by 2002:a2e:9e03:: with SMTP id e3-v6mr11893534ljk.4.1544605371294; Wed, 12 Dec 2018 01:02:51 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g17sm3298223lfj.36.2018.12.12.01.02.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Dec 2018 01:02:50 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'Michael Richardson'" , "'Nico Williams'" , References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> <035701d49149$71640f10$542c2d30$@gmail.com> <2503.1544530985@localhost> <037201d4914f$dee01ba0$9ca052e0$@gmail.com> In-Reply-To: Date: Wed, 12 Dec 2018 12:02:44 +0300 Message-ID: <048601d491f9$72824050$5786c0f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQJjEIcGzPEj/22sYW2hroPcukYuWAIvYqvHAie7eo0BeQS8egHtaQHgAjk9efMBSdV9YgFBY3HbAUinL/IBgnxSZwIoiFHNo9Ie7/A= Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 09:02:56 -0000 > > I see this as a social issue, not a technical one. We can't prevent > > administrators from being careless, either with PSKs or with passwords. > > We can make more secure deployments easier. > > If the only change on the site-to-site config is to change the keyword > "psk" to "pake" and that prevents offline dictionary attacks, that's an > easy win. I'm not so sure. Replacing PSK with password+PAKE could in fact decrease security. Properly chosen PSK provides high level of protection against both passive and active attacks. On the other hand, PAKE, as far as I know, only makes it difficult for passive eavesdropper to perform offline dictionary attack. But an active attacker may still try out all possible password values (due to small search space). Yes, you can easier detect active attackers and block them (and site-to-site VPNs usually have fixed IPs, that simplifies the task), but I still feel a bit uncomfortable by the idea of replacing perfectly secure crypto mechanism with a weaker one. I'd rather educate administrators :-) And note, that no PAKE will save you if administrators will select passwords like "foobar" or "12345". I think that PAKE is a very good mechanism for remote access in situation when certificates (or raw public keys) cannot be used for various reasons. E.g. f simple CPE that has no memory to securely store private key. Regards, Valery. > I care a little less for group psk's because well, it is a group so even > a pake won't buy us that much extra if dozens or thousands of people > have the pake secret. > > Paul From nobody Wed Dec 12 12:52:31 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14950130F4A for ; Wed, 12 Dec 2018 12:52:29 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7Z3hCuYZxs8D for ; Wed, 12 Dec 2018 12:52:26 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3911276D0 for ; Wed, 12 Dec 2018 12:52:26 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id m1so230429wml.2 for ; Wed, 12 Dec 2018 12:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OJebqFurKZKV//30nfhSCJe61w1x2b8ndtKPOFa5hNY=; b=gR64hMevpQafMCuA/rg6ezspYSjnkeGbov6+XU5u6G7oIK7dvZwkQo6lCtB7OlgOGz Y/F4366nZyfjaeSbtJsWKZ5wRDljrUhWH8trUPygZMO9DTW49rZbWArFeDMSUIG4sdRk Ft8NjqDcW5uZEUOLDrsiMSxhbOAfkx8C0TiZE8c5Q4sa8GyAqNqLxzyaFOziEYWYC1B0 E5wNaUAh46DAttm1zs3j4T0kFTlwAxmv7loHkpjFsROqUROZL2Dsf8KsQM3dxhItg60s tEM1mUM5DgXopqNNxMofntWG7yTP43ZVIiATtUnG8wcz5SXRdQTSfx83TKNr0tDmXzXy +6PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OJebqFurKZKV//30nfhSCJe61w1x2b8ndtKPOFa5hNY=; b=DRU1jP9YGx51dB3Ie+UFFHe8sd92DjjJXOdjpt0TC4LllvRal1+iyk1PviWtnmkOTK 57/Qo8hThlub3y+eU1E+JbwTlTeNdjg4pYFIf5HhURtqlnsP1mOXPsmlAD5f1b+L2db4 /9FsB3N1tuTKWSF2x909by58T8YMP4FriBiBZHFjW/fL5aKAg+LPLkgkOM4eTthAg9bJ 8rYTyTcWkvqCgaQpkU9gSuGgDLs5XcilVloNlxYHBWa02e3WUjmf2y7c0nxk6t8Ums2V ZfmJnN5F75Ar5jhTQZPxWQjpHZULJVQdsC3RciaDPsFFPjFBbekW4TROwdIpLUQHYW3B MocQ== X-Gm-Message-State: AA+aEWYkyhqpWQqjms/mx07zRRr6F68L04bQRicAmXFKAoJEsHRSVDxi r0Tz3j5Nsf8/ZQfelYF4vkw= X-Google-Smtp-Source: AFSGD/VFqptHZhVpFM2ZaCJ47q2Ocd4NcOov9kcUycVFEuoWwnvRWYAB/kk8Z5ZL/2wwuY8uNI/kWQ== X-Received: by 2002:a1c:f518:: with SMTP id t24mr7324885wmh.26.1544647944835; Wed, 12 Dec 2018 12:52:24 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id c77sm265797wmh.12.2018.12.12.12.52.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Dec 2018 12:52:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\)) From: Yoav Nir In-Reply-To: <048601d491f9$72824050$5786c0f0$@gmail.com> Date: Wed, 12 Dec 2018 22:52:20 +0200 Cc: Paul Wouters , "ipsec@ietf.org WG" , Michael Richardson , Nico Williams Content-Transfer-Encoding: quoted-printable Message-Id: <201C4873-318D-4AD1-A469-2F8854CAE623@gmail.com> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> <035701d49149$71640f10$542c2d30$@gmail.com> <2503.1544530985@localhost> <037201d4914f$dee01ba0$9ca052e0$@gmail.com> <048601d491f9$72824050$5786c0f0$@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3445.101.1) Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 20:52:29 -0000 Hi, Valery > On 12 Dec 2018, at 11:02, Valery Smyslov = wrote: >=20 >>> I see this as a social issue, not a technical one. We can't prevent >>> administrators from being careless, either with PSKs or with = passwords. >>=20 >> We can make more secure deployments easier. >>=20 >> If the only change on the site-to-site config is to change the = keyword >> "psk" to "pake" and that prevents offline dictionary attacks, that's = an >> easy win. >=20 > I'm not so sure. Replacing PSK with password+PAKE could in fact = decrease security. > Properly chosen PSK provides high level of protection against both = passive > and active attacks. On the other hand, PAKE, as far as I know, > only makes it difficult for passive eavesdropper to perform offline > dictionary attack. But an active attacker may still try out all = possible > password values (due to small search space). Yes, you can easier > detect active attackers and block them (and site-to-site VPNs > usually have fixed IPs, that simplifies the task), but I still feel a = bit uncomfortable > by the idea of replacing perfectly secure crypto mechanism with a = weaker one.=20 > I'd rather educate administrators :-) And note, that no PAKE will > save you if administrators will select passwords like "foobar" or = "12345". >=20 > I think that PAKE is a very good mechanism for remote access > in situation when certificates (or raw public keys) cannot be used > for various reasons. E.g. f simple CPE that has no memory > to securely store private key. I don=E2=80=99t think the idea is to replace a 128-bit PSK derived from = a properly seeded DRBG with =E2=80=9Cip5ecmeRockz!=E2=80=9D using a = PAKE. I think we=E2=80=99re assuming the administrator will configure = =E2=80=9Cip5ecmeRockz!=E2=80=9D (or =E2=80=9Cfoobar=E2=80=9D) regardless = of what we call it, so we might as well give them a better mechanism to = use this value. Yoav= From nobody Wed Dec 12 13:36:39 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB25A1312DB for ; Wed, 12 Dec 2018 13:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 jpecxaqV1Gll for ; Wed, 12 Dec 2018 13:36:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74B21312D9 for ; Wed, 12 Dec 2018 13:36:35 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D2CFA20089 for ; Wed, 12 Dec 2018 16:36:28 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B79E2DF7; Wed, 12 Dec 2018 16:36:34 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B54CE65 for ; Wed, 12 Dec 2018 16:36:34 -0500 (EST) From: Michael Richardson To: "ipsec\@ietf.org WG" In-Reply-To: <201C4873-318D-4AD1-A469-2F8854CAE623@gmail.com> References: <25207.1544136532@localhost> <026601d49061$8809ad30$981d0790$@gmail.com> <29587.1544482818@localhost> <20181210231958.GC15561@localhost> <20181211001622.GD15561@localhost> <035701d49149$71640f10$542c2d30$@gmail.com> <2503.1544530985@localhost> <037201d4914f$dee01ba0$9ca052e0$@gmail.com> <048601d491f9$72824050$5786c0f0$@gmail.com> <201C4873-318D-4AD1-A469-2F8854CAE623@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] replacing PSKs: CFRG and PAKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2018 21:36:38 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > I don=E2=80=99t think the idea is to replace a 128-bit PSK derived from a= properly > seeded DRBG with =E2=80=9Cip5ecmeRockz!=E2=80=9D using a PAKE. Please! The official PSK is "makemetastegoat" =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwRf2IACgkQgItw+93Q 3WVcvAf/aZior37rKaCGJxxCeld6otoZGC4GOhaQUx3HpxwCVAVcXMZ2smgPQCIB a+G592MNv+fuRWDCHOfsC/UsDGhAKloTAuA7ClX9eapEDi0EbiK2Bz8yBOTmdRME /69Nq1VvZ/KNhUvwmjbaM8weoABii5BcJScpntxds1UtBrFLgEIA82KSIXLzZ4ZX 1JWkc1lazcUOo76towPAl7LMULs1zuCTXBIkNbGoZ+lPEpP33zIN4QLD3XVpT/wz M48MCyYFTZlenB6jLnicVDgj7r6w+owns0bpZ8apwcrNtMsznxrO290XzRWkESMK DnX9nVsPjX3Mp+5f7J1pXMWkvx9UrQ== =MR75 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 13 09:40:32 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7CBB130DFA for ; Thu, 13 Dec 2018 09:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dSmcusdj2U7Q for ; Thu, 13 Dec 2018 09:40:27 -0800 (PST) Received: from beechnut.cse-cst.gc.ca (beechnut.cse-cst.gc.ca [205.193.218.37]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091BD1200B3 for ; Thu, 13 Dec 2018 09:40:26 -0800 (PST) From: "Hammell, Jonathan F" To: "'ipsec@ietf.org'" Thread-Topic: Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 Thread-Index: AdSTCe4wj5wa/AqMQCWUoIVyfm/6Ww== Date: Thu, 13 Dec 2018 17:40:23 +0000 Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-classification: UNCLASSIFIED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20181213174027.091BD1200B3@ietfa.amsl.com> Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 17:40:30 -0000 Classification: UNCLASSIFIED The Canadian Centre for Cyber Security has reviewed draft-ietf-ipsecme-qr-i= kev2-04 and recommends the authors address the following comments before pr= oceeding to IESG. 1. The table on Page 8 refers to the term 'HAVE PPK' - this term is not use= d elsewhere in the document. To understand the table the reader is left to = surmise its meaning. We understand the term as the Responder being configu= red with a PPK for the Initiator (identified by the PPK_ID). We recommend= either defining what is meant by 'HAVE PPK' or changing the term from 'HAV= E PPK' to 'Configured with PPK for the initiator' which is how it is descri= bed in the Upgrade procedure or more simply as 'Configured with PPK' . 2. Section Upgrade procedure - We recommend changing the statement "As an o= ptional second step, after all nodes have been upgraded, the administrator = may then go back ... and mark the use of PPK as mandatory." to "After all n= odes have been upgraded, the administrator SHOULD go back ...". 3. IKEv2 with EAP authentication -the EAP-ikev2 protocol description in the= draft is different from that in the EAP-IKEv2 RFC 5106 beyond what we expe= ct because of PPK use (i.e Initiator does not send an AUTH payload in the f= irst EAP-Req message).=20 a. Firstly, none of the message types from RFC 5106 are used in the draft: = EAP-Req, EAP-Res and EAP-Success for example. We recommend using the same n= otation as in the RFC to describe EAP with PPK. b. The draft uses the term "EAP" whose meaning is unclear but assumed to me= an an EAP type message. c. The biggest difference appears to be the fact that it is the Responder w= ho sends the EAP-success message. This may be done because an extra IKE_AUT= H exchange will be performed, but an explanation could be useful. We highlight two messages below (**) from the draft that appear to not = fit the RFC's description. Also it is not clear what is meant by the term E= AP in the messages, we assume that it stands for EAP-Req or EAP-Res. The portion of the description in the draft (without the IKE_SA_INIT and I= KE_AUTH exchanges) is Initiator Responder ---------------------------------------------------------------- HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP} ** HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} ** Compared with the protocol described in RFC 5106 without the initial ex= changes 5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH}) 6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH}) * 7. R<-I: EAP-Success Figure 1: EAP-IKEv2 Full, Successful Protocol Run Best regards, Jonathan On Fri, 30 Nov 2018, Waltermire, David A. (Fed) wrote: > This message starts a working group last call (WGLC) on draft-ietf-ipsecm= e-qr-ikev2-04, which will conclude on December 14, 2018 at UTC 23:59. Pleas= e review and provide feedback on the -04 version (https://datatracker.ietf.= org/doc/draft-ietf-ipsecme-qr-ikev2/). Please indicate if you believe this = draft is ready for publication or if you have comments that must be address= ed before the draft progresses to the IESG. From nobody Thu Dec 13 23:09:19 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A281310BD for ; Thu, 13 Dec 2018 23:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vx-MF7p0ka6y for ; Thu, 13 Dec 2018 23:09:16 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD0A1310BC for ; Thu, 13 Dec 2018 23:09:15 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id n18-v6so3992985lji.7 for ; Thu, 13 Dec 2018 23:09:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=ZGGeTDV+RTIw7XI3XucDiO0rm3Wrlg/66/Ne4t/Okxg=; b=Vwzsq9ft01IRE14boKUaBAnsv+jJxZ2csuqplgUT7jKJ6Ri7eCcnKr8gwrqERyxVlJ eR3NLTMpOhlW3YIhtMuhLY01/kLu2okNmB2aGRxpPUXtt9DDbPE9UZN7/pL/LLpFcJYn kBbWyOKf3D5Pp24eudkcuehQZUcBPOvNgTzdZmRu9QLSN3/CwbYtJiyyPyDtS9ruZWSK PusTJzaX90XV0iC+bJ3d60H9c39muqoyCMunMhKwYHYKVO8yfVirIJyiHDxzgjeual8u RtJ4Hct/x8OReWIAavUtmlzfn1JP2KDxpr8hDOLdjYHiDOCklFATXp86zmDUxa9i2NYM ffWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=ZGGeTDV+RTIw7XI3XucDiO0rm3Wrlg/66/Ne4t/Okxg=; b=IkAD76lJJzsZZmEEjkiQhBfxo5OQRcGlJJbGwY+d7jR+qvwP3k9GYcKxqd2/iNAswH A9MtE/9h9QLFdKMTDhfY6wlAssJGRu7l3qPTDBvgd3+jstGEiLVgcFUs0wpCNeLEBpta b7jHK7WXgCvzHiWocPoJPXjk1upVlmScVrvK+NQLmmIUop74R15cMpVRMVnFA+HMNmvs 39q/Dr2Uh+7o2bffeLsLU1HmAxWDMHcBpeWiQAoHDOGtpwwDncHcXZn7ddabWY65IIWS lEBryW+Q8xC3ra7BNQDHf7zqpaGXyNiQlocOcC1PGZI9c4YmIDp7iN2t57MTHw03O8ie LqYw== X-Gm-Message-State: AA+aEWao38WctM5WRi7ZVwJxptT4z8wmM2rwiTjNgaCHKBiDioZ2KX7n di563nOMYAJCbegt0ID8avutSm0q X-Google-Smtp-Source: AFSGD/XaWFWbnrNJ3kvpd3phX1KjijX2O3GKCVwgIMQViCiBYQp8wN5vi1W+2+iNYJs5MgGYl8+OlA== X-Received: by 2002:a2e:55d3:: with SMTP id g80-v6mr1184742lje.78.1544771353435; Thu, 13 Dec 2018 23:09:13 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q30sm761091lfi.94.2018.12.13.23.09.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Dec 2018 23:09:12 -0800 (PST) From: "Valery Smyslov" To: "'Hammell, Jonathan F'" , References: <20181213174027.091BD1200B3@ietfa.amsl.com> In-Reply-To: <20181213174027.091BD1200B3@ietfa.amsl.com> Date: Fri, 14 Dec 2018 10:08:49 +0300 Message-ID: <01fa01d4937b$dd4edaa0$97ec8fe0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJCuH6YkCsi91nYYVdJKq3SgNeIfqShes+Q Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 07:09:18 -0000 Hi Jonathan, thank you for your review. Please see my comments inline. > The Canadian Centre for Cyber Security has reviewed draft-ietf-ipsecme-qr-ikev2-04 and recommends the > authors address the following comments before proceeding to IESG. > > 1. The table on Page 8 refers to the term 'HAVE PPK' - this term is not used elsewhere in the document. To > understand the table the reader is left to surmise its meaning. We understand the term as the Responder > being configured with a PPK for the Initiator (identified by the PPK_ID). We recommend either defining what > is meant by 'HAVE PPK' or changing the term from 'HAVE PPK' to 'Configured with PPK for the initiator' which > is how it is described in the Upgrade procedure or more simply as 'Configured with PPK' . I see your point. We'll think how to make this text more clear. > 2. Section Upgrade procedure - We recommend changing the statement "As an optional second step, after all > nodes have been upgraded, the administrator may then go back ... and mark the use of PPK as mandatory." to > "After all nodes have been upgraded, the administrator SHOULD go back ...". I don't think the proposed change is justified. The requirement language (MAY, SHOULD, MUST etc.) it IETF documents is usually used in protocol descriptions when some actions are required (or prohibited) to achieve interoperability. Section "Upgrade procedure" is not concerned with the protocol itself, it is just a recommended algorithm for upgrading some system for using PPK. It is not the only algorithm possible. And it isn't concerned with interoperability of different protocol implementations. So, I'd leave the text as is. > 3. IKEv2 with EAP authentication -the EAP-ikev2 protocol description in the draft is different from that in the > EAP-IKEv2 RFC 5106 beyond what we expect because of PPK use (i.e Initiator does not send an AUTH payload > in the first EAP-Req message). This is a confusion. The draft is not relevant to RFC 5106, so the whole comment is a result of misunderstanding. Let me explain. The EAP protocol is a framework for various authentication protocols, called EAP methods. A lot of EAP methods are defined (see https://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml#eap-numbers-4). The IKEv2 accommodates EAP as an alternative way to authenticate peers. How EAP is used in IKEv2 is defined in RFC 7296 - the core IKEv2 spec (in particular see Section 2.16). The confusion comes from the fact, that there is also an EAP method called EAP-IKEv2, defined in RFC 5106. This RFC describes how IKEv2-like protocol can be used inside EAP framework to achieve authentication, but it has nothing to do with how EAP framework is used within IKEv2. The draft is concerned with the latter, clarifying things for PPK use case. It is not concerned with EAP-IKEv2 EAP method. Regards, Valery. > a. Firstly, none of the message types from RFC 5106 are used in the draft: EAP-Req, EAP-Res and EAP-Success > for example. We recommend using the same notation as in the RFC to describe EAP with PPK. > b. The draft uses the term "EAP" whose meaning is unclear but assumed to mean an EAP type message. > c. The biggest difference appears to be the fact that it is the Responder who sends the EAP-success message. > This may be done because an extra IKE_AUTH exchange will be performed, but an explanation could be useful. > > We highlight two messages below (**) from the draft that appear to not fit the RFC's description. Also it is > not clear what is meant by the term EAP in the messages, we assume that it stands for EAP-Req or EAP-Res. > > The portion of the description in the draft (without the IKE_SA_INIT and IKE_AUTH exchanges) is > > Initiator Responder > ---------------------------------------------------------------- > HDR, SK {IDi, [CERTREQ,] > [IDr,] SAi2, > TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP} > ** HDR, SK {EAP} --> > <-- HDR, SK {EAP (success)} ** > > > Compared with the protocol described in RFC 5106 without the initial exchanges > > 5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH}) > 6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH}) > * 7. R<-I: EAP-Success > > Figure 1: EAP-IKEv2 Full, Successful Protocol Run > > > Best regards, > Jonathan > > On Fri, 30 Nov 2018, Waltermire, David A. (Fed) wrote: > > > This message starts a working group last call (WGLC) on draft-ietf-ipsecme-qr-ikev2-04, which will conclude > on December 14, 2018 at UTC 23:59. Please review and provide feedback on the -04 version > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/). Please indicate if you believe this draft is ready > for publication or if you have comments that must be addressed before the draft progresses to the IESG. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Dec 14 12:10:34 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CBD1312E1 for ; Fri, 14 Dec 2018 12:10:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0BlAuSlpbU27 for ; Fri, 14 Dec 2018 12:10:28 -0800 (PST) Received: from beechnut.cse-cst.gc.ca (beechnut.cse-cst.gc.ca [205.193.218.37]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74527130E77 for ; Fri, 14 Dec 2018 12:10:27 -0800 (PST) From: "Hammell, Jonathan F" To: 'Valery Smyslov' , "ipsec@ietf.org" Thread-Topic: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 Thread-Index: AQJCuH6YUAXUojYgn0ejO3ZVIWeMpaShes+QgADhbGA= Date: Fri, 14 Dec 2018 20:10:26 +0000 References: <20181213174027.091BD1200B3@ietfa.amsl.com> <01fa01d4937b$dd4edaa0$97ec8fe0$@gmail.com> In-Reply-To: <01fa01d4937b$dd4edaa0$97ec8fe0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-classification: UNCLASSIFIED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20181214201028.74527130E77@ietfa.amsl.com> Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2018 20:10:32 -0000 Classification: UNCLASSIFIED Hi Valery, Thanks for your quick reply. >> 2. Section Upgrade procedure - We recommend changing the statement "As=20 >> an optional second step, after all nodes have been upgraded, the=20 >> administrator may then go back ... and mark the use of PPK as mandatory.= " to "After all nodes have been upgraded, the administrator SHOULD go back = ...". > > I don't think the proposed change is justified. The requirement language = (MAY, SHOULD, MUST etc.) it IETF documents is usually used in=20 > protocol descriptions when some actions are required (or prohibited) to a= chieve interoperability. Section "Upgrade procedure" is not=20 > concerned with the protocol itself, it is just a recommended algorithm fo= r upgrading some system for using PPK. It is not the only algorithm=20 > possible. And it isn't concerned with interoperability of different proto= col implementations. So, I'd leave the text as is. We agree with your interpretation that a capital SHOULD might not be approp= riate, but we still feel a lowercase "should" in place of "may" will encour= age more administrators to complete the upgrade procedure. =20 >> 3. IKEv2 with EAP authentication -the EAP-ikev2 protocol description=20 >> in the draft is different from that in the >> EAP-IKEv2 RFC 5106 beyond what we expect because of PPK use (i.e=20 >> Initiator does not send an AUTH payload in the first EAP-Req message). > > This is a confusion. The draft is not relevant to RFC 5106, so the whole = comment is a result of misunderstanding. > Let me explain. The EAP protocol is a framework for various authenticatio= n protocols, called EAP methods. > A lot of EAP methods are defined (see https://www.iana.org/assignments/ea= p-numbers/eap-numbers.xhtml#eap-numbers-4). >=20 > The IKEv2 accommodates EAP as an alternative way to authenticate peers. H= ow EAP is used in IKEv2 is defined in RFC 7296 - the core=20 > IKEv2 spec (in particular see Section 2.16). The confusion comes from the= fact, that there is also an EAP method called EAP-IKEv2,=20 > defined in RFC 5106. This RFC describes how IKEv2-like protocol can be us= ed inside EAP framework to achieve authentication, but it has=20 > nothing to do with how EAP framework is used within IKEv2. The draft is c= oncerned with the latter, clarifying things for PPK use case.=20 > It is not concerned with EAP-IKEv2 EAP method. We reviewed this again and you are completely right. Thanks for explaining= the difference. =20 Best regards, Jonathan -----Original Message----- From: Valery Smyslov =20 Sent: December-14-18 2:09 AM To: Hammell, Jonathan F ; ipsec@ietf.org Subject: RE: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 Hi Jonathan, thank you for your review. Please see my comments inline. > The Canadian Centre for Cyber Security has reviewed=20 > draft-ietf-ipsecme-qr-ikev2-04 and recommends the authors address the fol= lowing comments before proceeding to IESG. >=20 > 1. The table on Page 8 refers to the term 'HAVE PPK' - this term is=20 > not used elsewhere in the document. To understand the table the reader is= left to surmise its meaning. We understand the term as the Responder > being configured with a PPK for the Initiator (identified by the PPK_ID).= We recommend either defining what > is meant by 'HAVE PPK' or changing the term from 'HAVE PPK' to=20 > 'Configured with PPK for the initiator' which is how it is described in t= he Upgrade procedure or more simply as 'Configured with PPK' . I see your point. We'll think how to make this text more clear. > 2. Section Upgrade procedure - We recommend changing the statement "As=20 > an optional second step, after all nodes have been upgraded, the=20 > administrator may then go back ... and mark the use of PPK as mandatory."= to "After all nodes have been upgraded, the administrator SHOULD go back .= ..". I don't think the proposed change is justified. The requirement language (M= AY, SHOULD, MUST etc.) it IETF documents is usually used in protocol descri= ptions when some actions are required (or prohibited) to achieve interopera= bility. Section "Upgrade procedure" is not concerned with the protocol itse= lf, it is just a recommended algorithm for upgrading some system for using = PPK. It is not the only algorithm possible. And it isn't concerned with int= eroperability of different protocol implementations. So, I'd leave the text= as is. > 3. IKEv2 with EAP authentication -the EAP-ikev2 protocol description=20 > in the draft is different from that in the > EAP-IKEv2 RFC 5106 beyond what we expect because of PPK use (i.e=20 > Initiator does not send an AUTH payload in the first EAP-Req message). This is a confusion. The draft is not relevant to RFC 5106, so the whole co= mment is a result of misunderstanding. Let me explain. The EAP protocol is a framework for various authentication = protocols, called EAP methods. A lot of EAP methods are defined (see https://www.iana.org/assignments/eap-= numbers/eap-numbers.xhtml#eap-numbers-4). The IKEv2 accommodates EAP as an alternative way to authenticate peers. How= EAP is used in IKEv2 is defined in RFC 7296 - the core IKEv2 spec (in part= icular see Section 2.16). The confusion comes from the fact, that there is = also an EAP method called EAP-IKEv2, defined in RFC 5106. This RFC describe= s how IKEv2-like protocol can be used inside EAP framework to achieve authe= ntication, but it has nothing to do with how EAP framework is used within I= KEv2. The draft is concerned with the latter, clarifying things for PPK use= case.=20 It is not concerned with EAP-IKEv2 EAP method. =20 Regards, Valery. > a. Firstly, none of the message types from RFC 5106 are used in the=20 > draft: EAP-Req, EAP-Res and EAP-Success for example. We recommend using t= he same notation as in the RFC to describe EAP with PPK. > b. The draft uses the term "EAP" whose meaning is unclear but assumed to = mean an EAP type message. > c. The biggest difference appears to be the fact that it is the Responder= who sends the EAP-success message. > This may be done because an extra IKE_AUTH exchange will be performed, bu= t an explanation could be useful. >=20 > We highlight two messages below (**) from the draft that appear to=20 > not fit the RFC's description. Also it is not clear what is meant by the = term EAP in the messages, we assume that it stands for EAP-Req or EAP-Res. >=20 > The portion of the description in the draft (without the IKE_SA_INIT=20 > and IKE_AUTH exchanges) is >=20 > Initiator Responder > ---------------------------------------------------------------- > HDR, SK {IDi, [CERTREQ,] > [IDr,] SAi2, > TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP} > ** HDR, SK {EAP} --> > <-- HDR, SK {EAP (success)} ** >=20 >=20 > Compared with the protocol described in RFC 5106 without the=20 > initial exchanges >=20 > 5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], [NFID], AUTH}) > 6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH}) > * 7. R<-I: EAP-Success >=20 > Figure 1: EAP-IKEv2 Full, Successful Protocol Run >=20 >=20 > Best regards, > Jonathan >=20 > On Fri, 30 Nov 2018, Waltermire, David A. (Fed) wrote: >=20 > > This message starts a working group last call (WGLC) on=20 > > draft-ietf-ipsecme-qr-ikev2-04, which will conclude > on December 14, 2018 at UTC 23:59. Please review and provide feedback=20 > on the -04 version=20 > (https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/). Please i= ndicate if you believe this draft is ready for publication or if you have c= omments that must be addressed before the draft progresses to the IESG. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Dec 17 04:32:13 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F224F128D68 for ; Mon, 17 Dec 2018 04:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1FGUlkSv6GcK for ; Mon, 17 Dec 2018 04:32:10 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9180F1286E7 for ; Mon, 17 Dec 2018 04:32:09 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id i26so9317535lfc.0 for ; Mon, 17 Dec 2018 04:32:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=M+5awjmC2HpIoN95KT0zL4CXDYAiAWtiXkL6S+7/iOk=; b=FCjZexZ20QZzNOYUGW1hkMNfylj/vZhtzZOLV3exMR8gQ/2BWBDdwnYUq4nQPUrN/F CKxXE63ZdOvoG9eE2aKgVKZBFmgDclakmA+Wyz5lh8sSFmbGi+GxdI6InYT97TMY9Nnl 9cmZhaB0nyF219q0Ps84es8JaNFepDL5JXYL7rFBbks8/fK3/tyAxh73KIC+5mvXxCEJ D4oeZshDEzDQmgzEjNRCkiD1v6YoedUHxj+KZNXDG3p2zOlEZZsYyKkZNCh7IuRSD5aY D0vFiZbIuapMqy5qk2v6H7c5VpjsgradbzAKvuKcqUKpF34KNHOKesW3fVgsTBhX359S cTsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=M+5awjmC2HpIoN95KT0zL4CXDYAiAWtiXkL6S+7/iOk=; b=l9Xuv1iNrJGeBWQmXXHl023I2WkIWuBjid/tLEMWvJxePCCI4riiwj7fSgdzd1Y0sg VHvI0KxBB8z6myqScuSwtNfscMpVB804qX1zVnUKI4loXXpxzT9JEJ5DKfO1Qhn4Dp5N 1ydseuB/mZ6EIfkZfZ6q6YrukuOhsXIuibw+OLbuUY5Tn8RFPbvCrahI+FHDESblX7sc TfC3Z7Xl8T+Vi3Dy0FhPwdCX+icTpcmbLiITKXucPRRbTzhx/7Jh37BAPJbCX4cUAdMX KBEegscPDgj63thwPVH3y7NiKD2LkJO2ou2YvWYten6LdugqmtnU8HD7qc9weiQTeCsP GQeQ== X-Gm-Message-State: AA+aEWbKOT38Gv8K/OwAIWGFOusTMdqqN9H7gUO08twFWLspHz0Rmkxt PNqED7HSUrAMe0cgs1LBkprHxypZ X-Google-Smtp-Source: AFSGD/WJ76WbRnaiy50kEHB2OFwNvPEQopEAoixrN5znXXCnPqf9fGs63yYDTpSBKNHu7MRXECqaaw== X-Received: by 2002:a19:d90c:: with SMTP id q12mr6940583lfg.24.1545049927361; Mon, 17 Dec 2018 04:32:07 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id z15-v6sm2941320ljb.9.2018.12.17.04.32.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 17 Dec 2018 04:32:06 -0800 (PST) From: "Valery Smyslov" To: "'Hammell, Jonathan F'" , References: <20181213174027.091BD1200B3@ietfa.amsl.com> <01fa01d4937b$dd4edaa0$97ec8fe0$@gmail.com> <20181214201028.74527130E77@ietfa.amsl.com> In-Reply-To: <20181214201028.74527130E77@ietfa.amsl.com> Date: Mon, 17 Dec 2018 15:31:45 +0300 Message-ID: <02f501d49604$795a8cc0$6c0fa640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJCuH6YkCsi91nYYVdJKq3SgNeIfgHL3FRqAafpUVekivlrcA== Content-Language: ru Archived-At: Subject: Re: [IPsec] WGLC on draft-ietf-ipsecme-qr-ikev2-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2018 12:32:11 -0000 > > I don't think the proposed change is justified. The requirement language (MAY, SHOULD, MUST etc.) it IETF > documents is usually used in > > protocol descriptions when some actions are required (or prohibited) to achieve interoperability. Section > "Upgrade procedure" is not > > concerned with the protocol itself, it is just a recommended algorithm for upgrading some system for using > PPK. It is not the only algorithm > > possible. And it isn't concerned with interoperability of different protocol implementations. So, I'd leave the > text as is. > > We agree with your interpretation that a capital SHOULD might not be appropriate, but we still feel a > lowercase "should" in place of "may" will encourage more administrators to complete the upgrade procedure. OK, I think it's a good suggestion. Thank you, Valery. From nobody Mon Dec 17 20:14:45 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36DF131026 for ; Mon, 17 Dec 2018 20:14:43 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 seBV6mU8HKML for ; Mon, 17 Dec 2018 20:14:42 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F05130FF9 for ; Mon, 17 Dec 2018 20:14:41 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43Jl680FcCz220 for ; Tue, 18 Dec 2018 05:14:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1545106480; bh=LCVrSOmtX9cT27Mem/ZDrISocER3lD44Y7saTBB+83w=; h=Date:From:To:Subject; b=K38ntTulF6c9nwPL9EodK/dRJNLFdVwKxhqOTqRZx91V/ycmquMVDScZ6k9W6HltX i2RXBCI4l4wtzz/cWuVRAnOuKrYIMUjs8FpwqwjafvGm9eA5i22isrYCKkMd3cAxEl Ny4XrH/PSHXf5ApoSXsnx3nneGJCiUf/ZprHQvlQ= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id TZeO56AiZpWk for ; Tue, 18 Dec 2018 05:14:19 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 18 Dec 2018 05:14:18 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 13E644AA4D9; Mon, 17 Dec 2018 23:14:17 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 13E644AA4D9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 07E1940C9588 for ; Mon, 17 Dec 2018 23:14:17 -0500 (EST) Date: Mon, 17 Dec 2018 23:14:17 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 04:14:44 -0000 Recently we had a discussion about mapping IANA entries to a yang model, and the question came up whether we sould add a deprecated marker to the IKE/ESP registries for algorithms. I thought it was a good idea, but not everyone agreed. I just stumbled upon RFC 7696: Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms Section 2.1: Algorithm Identifiers In the IPsec protocol suite, the Internet Key Exchange Protocol version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for the Authentication Header (AH) [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. Such separation is a completely fine design choice. [...] An IANA registry SHOULD be used for these algorithm or suite identifiers. Once an algorithm identifier is added to the registry, it should not be changed or removed. However, it is desirable to mark a registry entry as deprecated when implementation is no longer advisable. So there is even an RFC stating that we should really do this :) I guess the main question is, can we add these via a request to IANA based on RFC 8221 and 8247, or do we need to write a short RFC with requests to IANA? Paul From nobody Mon Dec 17 20:29:59 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F297131064 for ; Mon, 17 Dec 2018 20:29:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RO1X_JSIELym for ; Mon, 17 Dec 2018 20:29:56 -0800 (PST) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113D8131063 for ; Mon, 17 Dec 2018 20:29:56 -0800 (PST) Received: by mail-wm1-x32c.google.com with SMTP id d15so1250509wmb.3 for ; Mon, 17 Dec 2018 20:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o/oF2quubgMQQoHsXiWLSuRgz1DUAUPSp2yc8kbg++Y=; b=mTgKgPujE26sOP4HCJsn/dq3w1Q35BgE6iiwozKkjCTZ909NyUXJNM+1tAvZs4xgHd sXXNyAXXHx6BlnkCf3akwmch+zAAYNhiWY6jba5CqNO7Z+DOVPhmkKQfpXpP+8c51sAz Y0qvKlu0Qs/Uuxcv1pFXrnhk81HmWVPyl6qX4h4SSmr83FKQqnapgcBigqH+ec8yxKnG rXagvj++coqbkT4vJaMu7O+NMPY1WBUX0NPKXNczj8GtXlORYYD/Wu/tiN9b8GKI0XVd 7TqTypNbKVZQr82R7jgDHoKp74UFCeovdRrCJbL1Y4xhSmgOMfsjzAgo71qApNlK3nka KyJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=o/oF2quubgMQQoHsXiWLSuRgz1DUAUPSp2yc8kbg++Y=; b=nZbA3heqU55XMVqsL0C1Aj3o4fD2LFR3dmU04wWorVlA2EVhZdg6KoXjVxIQjM46j/ kt9qiS8d6HQVPQwBruB6c32AvVfTp/y3MBI6zp39qGf3PVB2eUf5JtctnGxjW6ppzzD8 6S8gGuzoROwSa/KxOUVwjUE7e/HanX+g/CwefwKiEUHc9Io8qmawnfR3DRulgpY+CuPo 3q9XLkCdAZc9JwDCttRSPivcQAdOMKvTeEQPDgN06P/UgEfKw7OEh9ArQUNEMTsxjQ7N WDCsxspivPVGj/jMGOifUhUSbAMN5gU3+PkrCg5g92m5QzpGC51mYLXxkFAfbunN8tAt rzXQ== X-Gm-Message-State: AA+aEWakuI9ZSeJ7hpOgkSC+NZpIEB6+dWl2x8uHJEC0Sse9y46Tirrb YDmqM8jHiaMjUuZ48CLaKRM= X-Google-Smtp-Source: AFSGD/V/REo0i+8XFc9ekVxIOhdl2tfJLD7cposhJ1xnoIN18lMuLBqv19ct5qvz8kojN4Rmlmtt3Q== X-Received: by 2002:a1c:df46:: with SMTP id w67mr1508129wmg.51.1545107394469; Mon, 17 Dec 2018 20:29:54 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id v132sm821203wme.20.2018.12.17.20.29.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 17 Dec 2018 20:29:53 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Yoav Nir In-Reply-To: Date: Tue, 18 Dec 2018 06:29:51 +0200 Cc: "ipsec@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 04:29:58 -0000 Hi, Paul I think we need an RFC to at least categorize the algorithms, unless we = want the IANA registry to have stuff like =E2=80=9CSHOULD-=E2=80=9C and = =E2=80=9CMAY+: > On 18 Dec 2018, at 6:14, Paul Wouters wrote: >=20 >=20 > Recently we had a discussion about mapping IANA entries to a yang = model, > and the question came up whether we sould add a deprecated marker to = the > IKE/ESP registries for algorithms. >=20 > I thought it was a good idea, but not everyone agreed. >=20 > I just stumbled upon RFC 7696: Guidelines for Cryptographic Algorithm = Agility and Selecting Mandatory-to-Implement Algorithms >=20 >=20 > Section 2.1: Algorithm Identifiers >=20 > In the IPsec protocol suite, the Internet Key Exchange Protocol > version 2 (IKEv2) [RFC7296] carries the algorithm identifiers for = the > Authentication Header (AH) [RFC4302] and the Encapsulating Security > Payload (ESP) [RFC4303]. Such separation is a completely fine = design > choice. [...] >=20 > An IANA registry SHOULD be used for these algorithm or suite > identifiers. Once an algorithm identifier is added to the registry, > it should not be changed or removed. However, it is desirable to > mark a registry entry as deprecated when implementation is no longer > advisable. >=20 > So there is even an RFC stating that we should really do this :) >=20 > I guess the main question is, can we add these via a request to IANA > based on RFC 8221 and 8247, or do we need to write a short RFC with > requests to IANA? >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Dec 17 20:37:53 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F46131072 for ; Mon, 17 Dec 2018 20:37: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Mfi_yVv24BAY for ; Mon, 17 Dec 2018 20:37:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71CE131071 for ; Mon, 17 Dec 2018 20:37:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43Jlcr3BtHz3Dk; Tue, 18 Dec 2018 05:37:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1545107868; bh=zxtV0HeKqEuv42EKyWbt8vDEV2PVDqTWAYWppslAxdw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=kEZ6tRG2uoa9XNFTEGuyZGgUYpjnSKkAJInzr8uAsqGRqOXQcOX9KpOy3/qxmpRSY oahi+5DXFTT/IppO4tXR7xwvyJCchYwkX/o7QQTVQ5KQ2vMcH/kzP0Ht6ZDXnhP2q9 az0b2wvUSSDZ8CaPf1sEEnlxaFYVVsxOxkiJ3BYI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id QzkeiK0XOASr; Tue, 18 Dec 2018 05:37:27 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 18 Dec 2018 05:37:26 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C55844AA4D9; Mon, 17 Dec 2018 23:37:25 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C55844AA4D9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id BE74F40C9588; Mon, 17 Dec 2018 23:37:25 -0500 (EST) Date: Mon, 17 Dec 2018 23:37:25 -0500 (EST) From: Paul Wouters To: Yoav Nir cc: "ipsec@ietf.org WG" In-Reply-To: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> Message-ID: References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 04:37:51 -0000 On Tue, 18 Dec 2018, Yoav Nir wrote: > I think we need an RFC to at least categorize the algorithms, unless we want the IANA registry to have stuff like “SHOULD-“ and “MAY+: We only need to add the SHOULD NOT and MUST NOT's and possibly some MAY's that are deemed otherwise ancient and deprecated (eg CAST) Anything with a + would surely not be deprecated as it is still climbing up. Anything with a - is still in use and we cannot deprecate it yet. Paul From nobody Mon Dec 17 22:39:38 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1491310C1 for ; Mon, 17 Dec 2018 22:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 jQkCZgbT0xWh for ; Mon, 17 Dec 2018 22:39:35 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6401310B9 for ; Mon, 17 Dec 2018 22:39:35 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id t18-v6so1180964ljd.4 for ; Mon, 17 Dec 2018 22:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=J2G1OmYDPrVaGhcMeBH2A7q2RhIS71IKYSJNrgr4INc=; b=B7MVNpQdz5jMvv9wKXLzQZRXSOM5K10u0XosXfRFJHz6b/PyMXHthUN0tNIDQKs0Fg aFzESdgG9MUKk0SwkS4t4PEvzWq/LJ6UeVErOtN2W2dnoLKqG+7Db5TWodO9812M/Fvy nVzYlIRcUNhg7x+J5DM1/DHzWgCPaHDctpxgDeUaxd684HLgNSWihtkaCpgDQrat8nSs RpjflL4NuOKQT66M46fBpu0Q7sQxCoV0K/HbtfOg0GwpHkhwpW6jyXbhK9rZ3gAWYMov jIVy5Uoy0GpyvBhTujhpU7sSBoemZlLET4Sd+KqoK12uDgCoIulOp3PzJ5QZubMA0oNf DL5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=J2G1OmYDPrVaGhcMeBH2A7q2RhIS71IKYSJNrgr4INc=; b=EZ/r/CUji8bl4WQ2lHKYNTGYBj5K23WhJgQ+kl98E7hYPl/76OGd2oNbthdM7CBI19 TkIlonOkZneI3kn0Ec1WuGaSp8FszQcX5jV3j8ztAvBpR71iyHy9cU9NA/yUQfBjZ2Rc edxFyUNvfkOjF/iOntLiQyx/dhQsE7DrHz+SEnw87fXUOEexTdZjSGWTAx2YmW7/+Z/D /IEEFJ+Xxc5NEsUgHyZGIun+yNfQJj01+tYOKhQJ+wJ0kD/wQBEHH+2oqZvNvyK9wDUd Jn8Ju+y8IvYEcBES9ir3buaEW5ABHW7z3RBAWSm1q9rbJShQ5mKOzxtqNRqrySwlS9TW HXzw== X-Gm-Message-State: AA+aEWb23GV0oPuYZNavD07Axg+dK8j462tUuAX1NLHrveLekM7i3WrV ijp0xJiu2IOqurLPQp8u4nlN9anT X-Google-Smtp-Source: AFSGD/W432hy6zTUZoi2fIn3O1HXL0GLOyvqit3+++xwI0MqJ8eF4bsvLne3aXuLSkGjl0LwitVmjg== X-Received: by 2002:a2e:9a84:: with SMTP id p4-v6mr9007357lji.73.1545115173193; Mon, 17 Dec 2018 22:39:33 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id y14-v6sm2849691ljj.55.2018.12.17.22.39.31 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 17 Dec 2018 22:39:32 -0800 (PST) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Yoav Nir'" Cc: References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> In-Reply-To: Date: Tue, 18 Dec 2018 09:39:11 +0300 Message-ID: <005801d4969c$63215360$2963fa20$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIut8yuWTI0EFyL2Gbj4Rz9MFoCAALU2fizAf0WzV6kqS7WoA== Content-Language: ru Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 06:39:37 -0000 Hi Paul, I think it is a good idea to have some indication in IANA about the = current status of the algorithm, similar to recent changes in the TLS registry (and in fact I initiated = this discussion in Bangkok). > > I think we need an RFC to at least categorize the algorithms, unless = we want the IANA registry to have stuff > like =E2=80=9CSHOULD-=E2=80=9C and =E2=80=9CMAY+: >=20 > We only need to add the SHOULD NOT and MUST NOT's and possibly some > MAY's that are deemed otherwise ancient and deprecated (eg CAST) >=20 > Anything with a + would surely not be deprecated as it is still = climbing > up. Anything with a - is still in use and we cannot deprecate it yet. Well, I think it's a bit too complex for random implementer. I'd prefer to classify all algorithms as follows: 1. Secure, required for interoperability 2. Secure, not required for interoperability 3. Insecure (obsoleted) Regards, Valery. > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Dec 18 06:49:36 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E004F12785F for ; Tue, 18 Dec 2018 06:49:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.161 X-Spam-Level: X-Spam-Status: No, score=-4.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com 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 fSN1l15Wl5Ie for ; Tue, 18 Dec 2018 06:49:33 -0800 (PST) Received: from esa5.dell-outbound.iphmx.com (esa5.dell-outbound.iphmx.com [68.232.153.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8841A126CC7 for ; Tue, 18 Dec 2018 06:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1545144560; x=1576680560; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uiOmdLmtPAnPwT/3pIOWqAtf1jsnPX/WUtmGUx7EVGw=; b=khbs6/HWWCUmulygnyiP0fqNXWXwHbDkKeQ2nAUsIWIEZm6cS5BVcTlH xESsnNebDHrfOyLq0M6sZjJGaN3QyKsCmDrQpG0S4euhr5O2fy8Eu08Y9 ROVkwVic8XvPsHMwspp7s2TTe45scYEDJXylCsfancfSC/akWgUOoNO54 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FaAQAUCBlchieV50NkHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYNsJwqDcoh4ixqCDYkVjlqBZwsBAYRsAheCRSI4EgEDAQECAQECAQE?= =?us-ascii?q?CEAEBARMLCCkvgjYigmUBAQEDARIRETcOBQsCAQgYAgImAgICHyYQAgQOBSK?= =?us-ascii?q?DAIFpAw0ImyQ9AoFuiQYBAQFugS+ICQ2CHYELizSCFoERJx+CHi6CV4F3ARI?= =?us-ascii?q?BH02COzGCJgKgdDAHAo4vgzESBpFXj02JfwIEAgQFAhSBXSBncXB6AYJBgjW?= =?us-ascii?q?OJkABMYw8gR+BHwEB?= X-IPAS-Result: =?us-ascii?q?A2FaAQAUCBlchieV50NkHAEBAQQBAQcEAQGBZYNsJwqDc?= =?us-ascii?q?oh4ixqCDYkVjlqBZwsBAYRsAheCRSI4EgEDAQECAQECAQECEAEBARMLCCkvg?= =?us-ascii?q?jYigmUBAQEDARIRETcOBQsCAQgYAgImAgICHyYQAgQOBSKDAIFpAw0ImyQ9A?= =?us-ascii?q?oFuiQYBAQFugS+ICQ2CHYELizSCFoERJx+CHi6CV4F3ARIBH02COzGCJgKgd?= =?us-ascii?q?DAHAo4vgzESBpFXj02JfwIEAgQFAhSBXSBncXB6AYJBgjWOJkABMYw8gR+BH?= =?us-ascii?q?wEB?= Received: from mx0a-00154901.pphosted.com ([67.231.149.39]) by esa5.dell-outbound.iphmx.com with ESMTP/TLS/AES256-SHA256; 18 Dec 2018 08:49:19 -0600 Received: from pps.filterd (m0142693.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id wBIEh6lk063441 for ; Tue, 18 Dec 2018 09:49:31 -0500 Received: from esa5.dell-outbound2.iphmx.com (esa5.dell-outbound2.iphmx.com [68.232.153.203]) by mx0a-00154901.pphosted.com with ESMTP id 2peyspsabj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 18 Dec 2018 09:49:31 -0500 From: Received: from ausxipps306.us.dell.com ([143.166.148.156]) by esa5.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-SHA256; 18 Dec 2018 20:48:26 +0600 X-LoopCount0: from 10.166.132.54 X-IronPort-AV: E=Sophos;i="5.56,368,1539666000"; d="scan'208";a="251557861" To: CC: , , Thread-Topic: [IPsec] On marking algorithms obsolete in IANA registries Thread-Index: AQHUlohMd9XhTsaN/EyKh5vsPXgog6WETCaAgAACHYCAACIGgIAAiPaA Date: Tue, 18 Dec 2018 14:49:24 +0000 Message-ID: References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> <005801d4969c$63215360$2963fa20$@gmail.com> In-Reply-To: <005801d4969c$63215360$2963fa20$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.143.18.86] Content-Type: text/plain; charset="utf-8" Content-ID: <9EBF302D5E7D5A45B6253279E0F6C8C2@dell.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-12-18_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=878 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1812180126 Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 14:49:35 -0000 DQoNCj4gT24gRGVjIDE4LCAyMDE4LCBhdCAxOjM5IEFNLCBWYWxlcnkgU215c2xvdiA8c215c2xv di5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gW0VYVEVSTkFMIEVNQUlMXSANCj4g DQo+IEhpIFBhdWwsDQo+IA0KPiBJIHRoaW5rIGl0IGlzIGEgZ29vZCBpZGVhIHRvIGhhdmUgc29t ZSBpbmRpY2F0aW9uIGluIElBTkEgYWJvdXQgdGhlIGN1cnJlbnQgc3RhdHVzIG9mIHRoZSBhbGdv cml0aG0sDQo+IHNpbWlsYXIgdG8gcmVjZW50IGNoYW5nZXMgaW4gdGhlIFRMUyByZWdpc3RyeSAo YW5kIGluIGZhY3QgSSBpbml0aWF0ZWQgdGhpcyBkaXNjdXNzaW9uIGluIEJhbmdrb2spLg0KPiAN Cj4+PiBJIHRoaW5rIHdlIG5lZWQgYW4gUkZDIHRvIGF0IGxlYXN0IGNhdGVnb3JpemUgdGhlIGFs Z29yaXRobXMsIHVubGVzcyB3ZSB3YW50IHRoZSBJQU5BIHJlZ2lzdHJ5IHRvIGhhdmUgc3R1ZmYN Cj4+IGxpa2Ug4oCcU0hPVUxELeKAnCBhbmQg4oCcTUFZKzoNCj4+IA0KPj4gV2Ugb25seSBuZWVk IHRvIGFkZCB0aGUgU0hPVUxEIE5PVCBhbmQgTVVTVCBOT1QncyBhbmQgcG9zc2libHkgc29tZQ0K Pj4gTUFZJ3MgdGhhdCBhcmUgZGVlbWVkIG90aGVyd2lzZSBhbmNpZW50IGFuZCBkZXByZWNhdGVk IChlZyBDQVNUKQ0KPj4gDQo+PiBBbnl0aGluZyB3aXRoIGEgKyB3b3VsZCBzdXJlbHkgbm90IGJl IGRlcHJlY2F0ZWQgYXMgaXQgaXMgc3RpbGwgY2xpbWJpbmcNCj4+IHVwLiBBbnl0aGluZyB3aXRo IGEgLSBpcyBzdGlsbCBpbiB1c2UgYW5kIHdlIGNhbm5vdCBkZXByZWNhdGUgaXQgeWV0Lg0KPiAN Cj4gV2VsbCwgSSB0aGluayBpdCdzIGEgYml0IHRvbyBjb21wbGV4IGZvciByYW5kb20gaW1wbGVt ZW50ZXIuDQo+IEknZCBwcmVmZXIgdG8gY2xhc3NpZnkgYWxsIGFsZ29yaXRobXMgYXMgZm9sbG93 czoNCj4gDQo+IDEuIFNlY3VyZSwgcmVxdWlyZWQgZm9yIGludGVyb3BlcmFiaWxpdHkNCj4gMi4g U2VjdXJlLCBub3QgcmVxdWlyZWQgZm9yIGludGVyb3BlcmFiaWxpdHkNCj4gMy4gSW5zZWN1cmUg KG9ic29sZXRlZCkNCj4gDQo+IFJlZ2FyZHMsDQo+IFZhbGVyeS4NCg0KUG9zc2libHkgc29tZSBh bGdvcml0aG1zIGFyZSBjYW5kaWRhdGVzIGZvciAib2Jzb2xldGUiIHN0YXR1cyBub3QgYmVjYXVz ZSB0aGV5IGFyZSBrbm93biB0byBiZSBpbnNlY3VyZSBidXQgYmVjYXVzZSB0aGV5IG5ldmVyIGdv dCB0cmFjdGlvbiBvciBzZWN1cml0eSBhbmFseXNpcy4gIEknbSBub3Qgc3VyZSBpZiBDQVNUIGlz IGFuIGV4YW1wbGUuDQoNCk9uIHRlcm1pbm9sb2d5OiAic2VjdXJlIiBpcyB0b28gc3Ryb25nIGEg c3RhdGVtZW50IGZvciB0aGUgbm9uLWV4cGVydCBhdWRpZW5jZS4gICJCZWxpZXZlZCB0byBiZSBz ZWN1cmUiIHdvdWxkIGJlIG1vcmUgcHJ1ZGVudCwgYnV0IEkgZG9uJ3QgcmVhbGx5IGxpa2UgdGhv c2Ugd29yZHMgZWl0aGVyLiAgQ2FuIHdlIGNvbWUgdXAgd2l0aCBzb21lIHdvcmRzIHRoYXQgZG9u J3Qgc3VnZ2VzdCBhIGd1YXJhbnRlZSB3ZSBjYW4ndCBtYWtlPw0KDQoJcGF1bA0KDQo= From nobody Tue Dec 18 06:58:44 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0CA71277BB for ; Tue, 18 Dec 2018 06:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 O-N-LB8BMzdZ for ; Tue, 18 Dec 2018 06:58:41 -0800 (PST) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26D60126DBF for ; Tue, 18 Dec 2018 06:58:41 -0800 (PST) Received: by mail-lf1-x132.google.com with SMTP id v5so12512197lfe.7 for ; Tue, 18 Dec 2018 06:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=NdvscMaXPUAQCZLYDLRycVj4owX4KbrsZi6jiEx7qDg=; b=G8RPUYPrfoC80EUja/LkVOZT1u79pMNAD21J5p3JqkARLispqaKObSv0gVEo6VileQ xN9i4Dh2I8KeBp+VIPA2X0/etGO8kdhkRGmQ17EDsnGLbr2lUP9ui45AaIGSyKU+SiyM O9oD8Mf8NbC8EBGPEDLF7xziVn76PJ5vZTvBt/AiQ4Zdw5KaCrzJSzWnFgoEFKvjugDF AHBNx9dUlhjnD7nYf2BIg9sW025IinnUcpVRJZn6H8l9S2XFykN34Tqzg6mcpAznfPgr TgHD+cw+GUb7Omk1msnzSn+jcsCKIrlKI5eaTNRd6diXL3x+SyTLagpFMPp9S4zzEv/n lR4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=NdvscMaXPUAQCZLYDLRycVj4owX4KbrsZi6jiEx7qDg=; b=hZtvpZnal/kzNhAQykXk9opEPEU9Gl4Znkoyj7uYt+FNQ7Zxw5krb+Lf1M2aZ2Dpe1 nPYgV3NW2qhcoYoOq2xZ4aefteN0at5Qw7CcOls3OvLPfs5XxrKzsIDxiz9+JgEu8fZE AwogrfBb7l5U0cFEaWC84NTV+Nqnw8UyEUo7am0x6fQfH7NoS4RQzYYNgzxbOzv9ayt+ rttAytcoCzdluGVX6O/2G+AU8Ur8YaiI0l2RDCuPSgNXFYaGdjaQNR5aPOIIu4NjW4mW T7H7C6vBxiDcaqucKZ/FNt64hjBC3pSoMxFG1ZJRZg419Tpr2F+YOMy80mmsllufhBEy mC/w== X-Gm-Message-State: AA+aEWbFuw0nxiAwTV41cvAKKmrAe2iXO+YqQ0NYAiwb403U6bmYGf1f jmCyHqGb7y+zcAbf3j0oQYMQAb96 X-Google-Smtp-Source: AFSGD/X2R8oO0ptVT+6VSssXIurXbYxPx1D/DoQTUu301jg5e9ofnF73wziA9QDX64PnmyG9BZugXA== X-Received: by 2002:a19:a84e:: with SMTP id r75mr10637650lfe.45.1545145118940; Tue, 18 Dec 2018 06:58:38 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id d19-v6sm3059432ljc.37.2018.12.18.06.58.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 18 Dec 2018 06:58:38 -0800 (PST) From: "Valery Smyslov" To: Cc: , , References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> <005801d4969c$63215360$2963fa20$@gmail.com> In-Reply-To: Date: Tue, 18 Dec 2018 17:58:17 +0300 Message-ID: <007801d496e2$1c4f95a0$54eec0e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIut8yuWTI0EFyL2Gbj4Rz9MFoCAALU2fizAf0WzV4BjbPy5wFqDU/XpJIFTYA= Content-Language: ru Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 14:58:43 -0000 Hi Paul, > > Well, I think it's a bit too complex for random implementer. > > I'd prefer to classify all algorithms as follows: > > > > 1. Secure, required for interoperability > > 2. Secure, not required for interoperability > > 3. Insecure (obsoleted) > > > > Regards, > > Valery. > > Possibly some algorithms are candidates for "obsolete" status not because they are known to be insecure but > because they never got traction or security analysis. I'm not sure if CAST is an example. > > On terminology: "secure" is too strong a statement for the non-expert audience. "Believed to be secure" > would be more prudent, but I don't really like those words either. Can we come up with some words that > don't suggest a guarantee we can't make? I agree that more accurate wording is definitely required here. My point was that we need three states for the algorithms - one indicating that the algorithm is recommended (we believe it is secure and it is recommended choice for interoperability), second indicating that algorithm is known to be broken or having insufficient security, and the third, for all other algorithms without known security issues, but that are not (yet?) recommended for interoperability. Regards, Valery. > paul From nobody Tue Dec 18 07:20:21 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D3E130E6E for ; Tue, 18 Dec 2018 07:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 yid4Hwl9fEGy for ; Tue, 18 Dec 2018 07:19:56 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D23312896A for ; Tue, 18 Dec 2018 07:19:54 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43K1sW57Dmz6j for ; Tue, 18 Dec 2018 16:19:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1545146383; bh=Ddmdikj4iG2vc/A6YlrcjONYAO9bMha4o30sny1NLuE=; h=Date:From:To:Subject:In-Reply-To:References; b=I+qC+jpzMG0aPgi/gwFrOJIBkaxX3fx4OeDFYJUa9vgJwZoP19djRUo3DgGlsOxM5 MUWJ1Y8X+rp51QZWp/ZtRweqj4ki+ES3BhPpwcrzlGd/NLscsPjPRRGy1oCpxM5uSq jSEg7Qlfh01cSQ9IXKSMZFL334UaAMd4R/2uEkVI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id L3RlOZhQ8x03 for ; Tue, 18 Dec 2018 16:19:22 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 18 Dec 2018 16:19:20 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B3F1A4A2511; Tue, 18 Dec 2018 10:19:19 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B3F1A4A2511 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ACB05418A294 for ; Tue, 18 Dec 2018 10:19:19 -0500 (EST) Date: Tue, 18 Dec 2018 10:19:19 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> <005801d4969c$63215360$2963fa20$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 15:19:59 -0000 On Tue, 18 Dec 2018, Paul.Koning@dell.com wrote: >> Well, I think it's a bit too complex for random implementer. >> I'd prefer to classify all algorithms as follows: >> >> 1. Secure, required for interoperability >> 2. Secure, not required for interoperability >> 3. Insecure (obsoleted) > Possibly some algorithms are candidates for "obsolete" status not because they are known to be insecure but because they never got traction or security analysis. I'm not sure if CAST is an example. > > On terminology: "secure" is too strong a statement for the non-expert audience. "Believed to be secure" would be more prudent, but I don't really like those words either. Can we come up with some words that don't suggest a guarantee we can't make? When I described the various SHOULD, MAY, MUST and their variants, I was not suggesting of putting that into the IANA registry. The IANA registry should only get "deprecated" or "obsolete". In my view (and I think the RFCs view) deprecrated means "issues found, stop using it" and "obsolete" means "meh, not harmful but no one else is using it anymore". Paul From nobody Tue Dec 18 07:21:53 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F8912D4F2 for ; Tue, 18 Dec 2018 07:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 sgfyI733zGGy for ; Tue, 18 Dec 2018 07:21:51 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6475E12D4EB for ; Tue, 18 Dec 2018 07:21:51 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43K1vy0Lpwz36f; Tue, 18 Dec 2018 16:21:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1545146510; bh=MKxgyvqyULDYQyn+2bv9Lx2r04ApuBEBVELaFfsGTJ8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Gg9us4OI4D0Aw/NKUL2CkibN2b71ow0v4GOb4ia1REp4XbtcXGCV/pnjENbWO1CVZ 7at3sO9rOK5xmhxoHFjykWttpXpSgwER7fxt1YWF0Qgaf/+RWo0AIhqI2q52Kd89Iu l0nj84Olz0Nn8xz/Xfzsk9E2F7AaXG4P3NlMWgRI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Q4l5-AXH5-uu; Tue, 18 Dec 2018 16:21:29 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 18 Dec 2018 16:21:29 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2BAD44A2511; Tue, 18 Dec 2018 10:21:28 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 2BAD44A2511 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 24185418A294; Tue, 18 Dec 2018 10:21:28 -0500 (EST) Date: Tue, 18 Dec 2018 10:21:28 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" In-Reply-To: <005801d4969c$63215360$2963fa20$@gmail.com> Message-ID: References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> <005801d4969c$63215360$2963fa20$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 15:21:53 -0000 On Tue, 18 Dec 2018, Valery Smyslov wrote: > I think it is a good idea to have some indication in IANA about the current status of the algorithm, > similar to recent changes in the TLS registry (and in fact I initiated this discussion in Bangkok). Indeed. And I agreed and I was reminded of this discussion once I stumbled on this RFC that tells us to do it for our IKE/ESP registries :) Paul From nobody Tue Dec 18 07:58:27 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C56A130EA3 for ; Tue, 18 Dec 2018 07:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 C7BxQYO94spm for ; Tue, 18 Dec 2018 07:58:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4D3130EA0 for ; Tue, 18 Dec 2018 07:58:22 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A790A2008C; Tue, 18 Dec 2018 10:58:14 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E41BCB5D; Tue, 18 Dec 2018 10:58:20 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E206EB3D; Tue, 18 Dec 2018 10:58:20 -0500 (EST) From: Michael Richardson To: Paul Wouters cc: Yoav Nir , "ipsec\@ietf.org WG" In-Reply-To: References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 15:58:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul Wouters wrote: >> I think we need an RFC to at least categorize the algorithms, unless >> we want the IANA registry to have stuff like =E2=80=9CSHOULD-=E2=80= =9C and =E2=80=9CMAY+: > We only need to add the SHOULD NOT and MUST NOT's and possibly some > MAY's that are deemed otherwise ancient and deprecated (eg CAST) > Anything with a + would surely not be deprecated as it is still > climbing up. Anything with a - is still in use and we cannot deprecate > it yet. so... I think that we did this in (spirit at least in) RFC8247? It seems that maybe we forgot to tell IANA to deprecate anything that was SHOULD NOT/MUST NOT, or that fell off the list. Maybe this can be clarified as an IESG directive rather than as a new document. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlwZGRwACgkQgItw+93Q 3WVxZQf+MbESCGrF7udrSN5nazOrYT1UuXrYCg4L07cfT0jt8AfoZy7/lt/DNFEs d+1KP+QTgvPSjqNGoMZqlsjiBQdSMpo0MAedGI3DrgJ2szqYgEq66W1wkNY9KFnF +Ab063gu2oNGm5rCN9efbIpSEH46JTbxH0jlbVOqOy1/w16gOMlpe/x5frLf/5X4 3ybmo/BoiDYoL3s/Mr3WkwlppdlYhZMTC2iH+fcBLzpzYBeGTmWGZpWWlay/kC18 KXwIlwzrXZ/P7hO0FxbHc+wPhm9UijIzVAVl0dgwH+oeSfDnvgRV3yXt2WFyHzKc Zt5qMXmHcFwBDcljTFvGVYW1uIivwg== =Mg0A -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Dec 18 12:01:47 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD9D130F06 for ; Tue, 18 Dec 2018 12:01:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mCAwhGbFBoZy for ; Tue, 18 Dec 2018 12:01:42 -0800 (PST) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA161313F3 for ; Tue, 18 Dec 2018 12:01:20 -0800 (PST) Received: by mail-wm1-x32f.google.com with SMTP id m1so3889971wml.2 for ; Tue, 18 Dec 2018 12:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7U7jG8KAZQsBNVs2uuDzkKHVI1zWe2ODzoSGoZzwNvY=; b=uZ+1IHgJ0RL8t3gc7gbNrhycWlUI/ZZmciCCkmHYHMSkn2Z1beHuLevBIHoPPbU1ER mqMbUwyN28u3pXl0/EGjnNcOe+3xlB24rBWL90U0ALmEsbc4FvovH771wfqQNN2m/73u M4BRBy++eOvhx4bHFvQrBIswbTradz6n9vWSjCYr6MtsqGm7smiKlQGQW0UCSCn6A3Rx qqskZVoFY3ZgPilVfkt1qgZ46ywA8agK5Rg1uTqRIdUFcxzUfzyn/kElSDB3KmztycU/ iR7yztJYepc2kBLtIXwOPZL4+AO/bPkW+bS057bW+/vQWGOGpexiRi9L7tkw+kSTwwsz gEjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7U7jG8KAZQsBNVs2uuDzkKHVI1zWe2ODzoSGoZzwNvY=; b=iB2smm0bQ8MQvCtknjUmpa0F5j6c263X9FYi8tFtHVfHgnLg9cqdktrlBR2Kd1X/4P KAU01Lly4YShXyr0Gks16yWEc3vXFjjinbHN7pPwE/M8QYYbaGWyHnv9Mwgbp3g1vryI MSm3nWvtrOj6LEiNlDsB/cQTnG5liQ3o2qRK3iUrcVkEMQ6EMScwtbxMQhPJcx47R7Gm Quiw5C1APKWv9BinUNmLBv9+mIwXDn7cyy7D50DVPlP9u2O2Wqc10VjsbHPM0XEu1yek JN3YmMqasgbjwjYQPdTexJWdouOiucLbQNbE68BbNcROb2QrLAFRcN4wVN1bDWqGOviN AoHg== X-Gm-Message-State: AA+aEWYi68muwsigklQMhgYyDn+n2MmxgMMhkShOh3y67Q1Bliyu7rvk bjU9kqmLrX/qC3qvMcV5WpE= X-Google-Smtp-Source: AFSGD/V3ZSbCzVR80OXkISyow+ISqvjOt1gOV1P2ZbzvJQtQYQwpELoaDmyAokMb0gLEnRSgDVRslA== X-Received: by 2002:a1c:cbc7:: with SMTP id b190mr4783862wmg.13.1545163278560; Tue, 18 Dec 2018 12:01:18 -0800 (PST) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y13sm2719230wrw.85.2018.12.18.12.01.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Dec 2018 12:01:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Yoav Nir In-Reply-To: Date: Tue, 18 Dec 2018 22:01:15 +0200 Cc: "ipsec@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <8AFD9B72-867F-48AC-A38A-9A320479C611@gmail.com> References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> <005801d4969c$63215360$2963fa20$@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2018 20:01:45 -0000 > On 18 Dec 2018, at 17:19, Paul Wouters wrote: >=20 > On Tue, 18 Dec 2018, Paul.Koning@dell.com wrote: >=20 >>> Well, I think it's a bit too complex for random implementer. >>> I'd prefer to classify all algorithms as follows: >>>=20 >>> 1. Secure, required for interoperability >>> 2. Secure, not required for interoperability >>> 3. Insecure (obsoleted) >=20 >> Possibly some algorithms are candidates for "obsolete" status not = because they are known to be insecure but because they never got = traction or security analysis. I'm not sure if CAST is an example. >>=20 >> On terminology: "secure" is too strong a statement for the non-expert = audience. "Believed to be secure" would be more prudent, but I don't = really like those words either. Can we come up with some words that = don't suggest a guarantee we can't make? >=20 > When I described the various SHOULD, MAY, MUST and their variants, I = was > not suggesting of putting that into the IANA registry. The IANA = registry > should only get "deprecated" or "obsolete". In my view (and I think = the > RFCs view) deprecrated means "issues found, stop using it" and > "obsolete" means "meh, not harmful but no one else is using it = anymore=E2=80=9D. I think it=E2=80=99s best to copy what TLS is doing and just add a = =E2=80=9CRecommended=E2=80=9D column with a y/n value to all the = algorithm lists. A prudent administrator enables the algorithms marked =E2=80=9CRecommended= =E2=80=9D and none of the others. An administrator that enables other algorithms will have to explain why = he or she did that when things go wrong. TLS did write a document to change the IANA registries like that. Yoav From nobody Tue Dec 18 20:04:55 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC8D512D84D for ; Tue, 18 Dec 2018 20:04:53 -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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 qZ5TX8JmT0W4 for ; Tue, 18 Dec 2018 20:04:50 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 352701276D0 for ; Tue, 18 Dec 2018 20:04:50 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43KLr808Hkz1p4; Wed, 19 Dec 2018 05:04:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1545192280; bh=DYjMzmqLsjdQNSpFCVpAob3oWcBv6rqPCagoevCtGsg=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=JnUaVl4veoeD/MZMvaL2su5wgogNOA9m6iwnfAMwR/0rAgNOvqcjr70/lBCMs01Kv PehRR1AULImnN0biTGWrZ76FL82g1JBLbycM+IdKjHEM8RA95oECrMyn26VtQZyOVL z5/YbKfIKbWxpe9jmGJmQA7GQvphgUWfAgU8y8GI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id f-mqo-NltB6Y; Wed, 19 Dec 2018 05:04:19 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 19 Dec 2018 05:04:18 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 41D5459F122; Tue, 18 Dec 2018 23:04:17 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 41D5459F122 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3425940C9714; Tue, 18 Dec 2018 23:04:17 -0500 (EST) Date: Tue, 18 Dec 2018 23:04:17 -0500 (EST) From: Paul Wouters To: Yoav Nir cc: "ipsec@ietf.org WG" In-Reply-To: <8AFD9B72-867F-48AC-A38A-9A320479C611@gmail.com> Message-ID: References: <0BD40F44-9677-44CB-9C9B-A755671B5C70@gmail.com> <005801d4969c$63215360$2963fa20$@gmail.com> <8AFD9B72-867F-48AC-A38A-9A320479C611@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] On marking algorithms obsolete in IANA registries X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2018 04:04:54 -0000 On Tue, 18 Dec 2018, Yoav Nir wrote: >> When I described the various SHOULD, MAY, MUST and their variants, I was >> not suggesting of putting that into the IANA registry. The IANA registry >> should only get "deprecated" or "obsolete". In my view (and I think the >> RFCs view) deprecrated means "issues found, stop using it" and >> "obsolete" means "meh, not harmful but no one else is using it anymore”. > > I think it’s best to copy what TLS is doing and just add a “Recommended” column with a y/n value to all the algorithm lists. > > A prudent administrator enables the algorithms marked “Recommended” and none of the others. > > An administrator that enables other algorithms will have to explain why he or she did that when things go wrong. > > TLS did write a document to change the IANA registries like that. Recommended to implement or recommended for use ? For instance, it is recommended to implement MODP 1536, but not recommended to use it. The same is probably true for 3DES? And what about AES_CTR? It's really a MAY so it is not recommended and not not recommended. It's confusing. deprecates/obsolete seems better. It's a negative term applying to both implementation and using. Browsers have too much power, so they can stomp on TLS servers. With IPsec we don't have that much power. Paul From nobody Fri Dec 21 08:38:00 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FC8130E46 for ; Fri, 21 Dec 2018 08:37:57 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 n1S1GJteCPJ7 for ; Fri, 21 Dec 2018 08:37:56 -0800 (PST) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CBD3130E33 for ; Fri, 21 Dec 2018 08:37:56 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id c19-v6so5273722lja.5 for ; Fri, 21 Dec 2018 08:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=tZy/9Oq8k/TSv1RPM3J+Un5oTm74yxuDKDMKPLX9l1Y=; b=kgL2+TY94loVQYIn6H/4W2h3rQIMmCcZs8BK+zgnSs7DCie3wuXfsLM1HeWDf77IEh SKnqNGkdY8gqUZF+aCtznfGY6cBLqocvttcrPT+QyRYIsSZs9E0YmCvBId4Eig11dyBO MO2TpQLWMQXo8RaMocgF2O7yntSHXqeTR/c0vQLjv0zKK2wYA3nQlmW4p+Npw8BkssQZ 97c4NTgxhe2DgbvPu0H+/4MA3BazYwXx8V1iEwucwWvL51YgpJoCmeIkvAYi2b1hCCoh +rBjhbIbyskLaZjFJisirwdKY/TJdGwdEGimncpDvHwVSdaN/+fME/GZTYxxMkukCjYl Xx3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tZy/9Oq8k/TSv1RPM3J+Un5oTm74yxuDKDMKPLX9l1Y=; b=KUPyllyOuxYw8WzjffGmuhiXIuRjAM6TruzDpX3h7KKjxMLRbft3gr9A5pLewH6Q0d pZ2F1vbfVjbEsmUkXjIfuicIr1F2KZydva8ZdGnnLFLLQFKiNRx+5hCpalVz4pfivoXd bTXa5/OODUT4xqA3N5NzAoMUpIxTbUrPCSx56/KzZ8SFxSjfSZh1+hSMSZvoptZVhycw 29KaExXDSFEX0iZa9mTfA29tWuT4zSWvxnB3JPyDsAHfQf2jbnO/w7nqITvDyPklJAEp JZp9PqmsSKS/p4CoFw3mhGmbRR/QiSqmRM/CdE4cMgc3VpfETUGeXOEhcs8Y2b68sKuG Lg4A== X-Gm-Message-State: AJcUukdURanhjXjVBtp3YC8q8fveFs/Xx7XzCgbBnec1bb9VhsZ5J6n6 4bsbKZth6Zc+Dgehu4MyfZ23POAxNsOElaGQG39LhJK9Mw8= X-Google-Smtp-Source: ALg8bN5eXUKMLbcyIjMgSzHkzGjl/9S8XJEcmz959qlj8WNEMefMbO3/Ci3cSCGa64+Yse7JFlkPPqFPlYs9QvSxS4c= X-Received: by 2002:a2e:3218:: with SMTP id y24-v6mr2241008ljy.157.1545410274683; Fri, 21 Dec 2018 08:37:54 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Fri, 21 Dec 2018 08:37:18 -0800 Message-ID: To: "" , saag@ietf.org, IPsecME WG , SPASM Content-Type: multipart/alternative; boundary="000000000000747e33057d8ade10" Archived-At: Subject: [IPsec] Proposed conflict review response for draft--irtf-cfrg-gcmsiv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 16:37:58 -0000 --000000000000747e33057d8ade10 Content-Type: text/plain; charset="UTF-8" I am shepherding the conflict review for this document. I propose to say: The IESG has concluded that this work is related to IETF work done in LAMPS, TLS, and IPSECME, but this relationship does not prevent publishing. -Ekr --000000000000747e33057d8ade10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am shepherding the conflict review for = this document. I propose to say:

The IESG has concluded that this work is related to IETF work done= in LAMPS, TLS, and IPSECME, but this relationship does not prevent publish= ing.

-Ekr

--000000000000747e33057d8ade10-- From nobody Tue Dec 25 07:11:16 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A38130E04; Tue, 25 Dec 2018 07:11:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <154575066894.24030.13252361041324294083@ietfa.amsl.com> Date: Tue, 25 Dec 2018 07:11:08 -0800 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2018 15:11:09 -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 WG of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Valery Smyslov Filename : draft-ietf-ipsecme-qr-ikev2-05.txt Pages : 18 Date : 2018-12-25 Abstract: The possibility of Quantum Computers pose a serious challenge to cryptography algorithms deployed widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a Quantum Computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-05 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-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 Tue Dec 25 07:19:08 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BDE130E52; Tue, 25 Dec 2018 07:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 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_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wDO0A168T8Yc; Tue, 25 Dec 2018 07:18:57 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1231271FF; Tue, 25 Dec 2018 07:18:55 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id e26so9660514lfc.2; Tue, 25 Dec 2018 07:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=0HgCOfs2EvtZk4V02cl7TktoVQlBfDQVp+v+chlfNYs=; b=GYrf3lCMGNP0R+rHA0iCd6m0Id+v+A5TzvtgN/k+IJpOnRP8uu1niuoPSORuLWeYIK G5gH722qA3W9yKtAGnXJptxUctdzWd3DEv6kaZXIZZtWjEeBrfFAquCQoizSmJz7m27x YJI1HNXkEQUqQgBC+0W1DZ+qOuf7ufCjSqMGBBsFaFFeXMbeT93D5LN3iJxgRDGV2aiM gF0YrHPCQ52Nop0OTnwn519HMSfcvEtsnLcDgJORp5712gam8IaGpqIZyVJ4oFGarJPA p1QJfzILlkgAcmaxt8eSvjaKwazERA0dkXeFZNcVbT+ETXSZYIt3QQFEHf5ZRMd94nZc YD9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=0HgCOfs2EvtZk4V02cl7TktoVQlBfDQVp+v+chlfNYs=; b=UijljaMo1k16V+wOYAvGbzvEE+TRa4XFeLgjD2NNryB5R5/HeOKva5aYVN1Fhqh9FK OETndjdwudt5UBcSALwkCDU16TE9mPTTTelG2rR+UKcNI4zWjC4rfotCIoGByOC2NjNR 9w/Agf15XuP/Nk8434N1P72hilu6T17vvpuao25bYtAnhg/Of6UsMsvfhyTmVvHDCQgs TwCafJEJMwY5hgTq+vV8RDwNS8HK0EADBa+f34OnSY77E/wY2G2gvEaRdqx+ybEL6reo 7XbYM8v1pbwj1yXT2V45Svn9UrgdhAdwhF0VpF8Pe8D44gHnG9/brk3IC4Q+ek8dvN4+ yC/Q== X-Gm-Message-State: AA+aEWagN/ZwV9PK0beUPLomTM49AVO3y8MU5SIr4xfHlIrLctGse/+x FcQfxqQiB74y9v0VKoBoS+4= X-Google-Smtp-Source: AFSGD/V+dOnW8QcJPUG3WHnt9HbSXcrFUz7PCObedbiGb7kcLrcCWNLTl53CeGVOKPIaHaEgPF8M6A== X-Received: by 2002:a19:9508:: with SMTP id x8mr8679277lfd.112.1545751133574; Tue, 25 Dec 2018 07:18:53 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s3-v6sm7126921lje.73.2018.12.25.07.18.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 25 Dec 2018 07:18:52 -0800 (PST) From: "Valery Smyslov" To: , Cc: "'Scott Fluhrer'" , "'David McGrew'" , "'Panos Kampanakis'" , References: <154575066894.24030.13252361041324294083@ietfa.amsl.com> In-Reply-To: <154575066894.24030.13252361041324294083@ietfa.amsl.com> Date: Tue, 25 Dec 2018 18:18:49 +0300 Message-ID: <004601d49c65$23561120$6a023360$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIwql0Yj3xeGqcmo5tEYdm9lPa4P6TXdO7A Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Dec 2018 15:19:07 -0000 Hi, a new (-05) version of the "Postquantum Preshared Keys for IKEv2" draft has been posted. The draft contains minor text improvements that addresses comments received during WGLC. Regards, Valery (for the authors). P.S. Merry Christmas (a bit late) and Happy New Year (a bit early)! > 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 WG of the IETF. > > Title : Postquantum Preshared Keys for IKEv2 > Authors : Scott Fluhrer > David McGrew > Panos Kampanakis > Valery Smyslov > Filename : draft-ietf-ipsecme-qr-ikev2-05.txt > Pages : 18 > Date : 2018-12-25 > > Abstract: > The possibility of Quantum Computers pose a serious challenge to > cryptography algorithms deployed widely today. IKEv2 is one example > of a cryptosystem that could be broken; someone storing VPN > communications today could decrypt them at a later time when a > Quantum Computer is available. It is anticipated that IKEv2 will be > extended to support quantum secure key exchange algorithms; however > that is not likely to happen in the near term. To address this > problem before then, this document describes an extension of IKEv2 to > allow it to be resistant to a Quantum Computer, by using preshared > keys. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-qr-ikev2-05 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-qr-ikev2-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-qr-ikev2-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/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Dec 26 09:48:25 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A07C131148 for ; Wed, 26 Dec 2018 09:48: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 UXdaiVrhkJKY for ; Wed, 26 Dec 2018 09:48:23 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC86131144 for ; Wed, 26 Dec 2018 09:48:23 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43Q0nD1CClz3B1; Wed, 26 Dec 2018 18:48:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1545846496; bh=RqCYLRMQdV683KC6sTrfcWptkErQOFA9LiQ8YF8VFA4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UV8XP0qYl/F++RkxB6F1WqO2g2QXfNhEHh955GOyd7+7AcJZ/h0QjaJx1eL6OKgBE iDi1n1AXM1yehBq6bffI036irIgEUBRaLmNbE/dSYA9v7ZosGgyv8xt885TJPaKhWw 9c6epJaKbPStph5KO9eUToJTMfu/k9mCh4SP64Gk= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id YUo36F703Dtq; Wed, 26 Dec 2018 18:48:15 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 26 Dec 2018 18:48:15 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0F910354023; Wed, 26 Dec 2018 12:48:14 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0F910354023 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 048504187620; Wed, 26 Dec 2018 12:48:14 -0500 (EST) Date: Wed, 26 Dec 2018 12:48:13 -0500 (EST) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" In-Reply-To: <004601d49c65$23561120$6a023360$@gmail.com> Message-ID: References: <154575066894.24030.13252361041324294083@ietfa.amsl.com> <004601d49c65$23561120$6a023360$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-qr-ikev2-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2018 17:48:25 -0000 On Tue, 25 Dec 2018, Valery Smyslov wrote: > a new (-05) version of the "Postquantum Preshared Keys for IKEv2" draft > has been posted. The draft contains minor text improvements that > addresses comments received during WGLC. Looks good to me. Paul From nobody Sat Dec 29 02:55:02 2018 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC91F12896A; Sat, 29 Dec 2018 02:55:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, ekr@rtfm.com, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.89.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154608090076.11786.13266401990835774401.idtracker@ietfa.amsl.com> Date: Sat, 29 Dec 2018 02:55:00 -0800 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 104 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2018 10:55:01 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sacm mile tcpinc curdle tls saag cfrg i2nsf Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Eric Rescorla Tero Kivinen David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Dec 30 11:18:03 2018 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEC06128D09; Sun, 30 Dec 2018 11:17: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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 8sl236TS365y; Sun, 30 Dec 2018 11:17:51 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BECEB126C7E; Sun, 30 Dec 2018 11:17:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 43SVZX6wMKzj1; Sun, 30 Dec 2018 20:17:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1546197460; bh=lGNwfAtGMNqtryxwUY08Y9+E1mEOyhAa25vkiPXvgls=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=fyayLhnfymO7AEV5AUg0d7QeYPe2NNsBXxdrtoBFq4qFwl34EE9R6+bT3AjOO2frf OfY//gvCxMmxOxuecbm/Ks4qQxAmqz4JUtXoOorORBQriPube2LT9ffQ0HDyQHKThD WjAt4vValXFTvOO6DKYNex2PK6sYwYcmnZ1WDtho= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id s4DhojmQmtKG; Sun, 30 Dec 2018 20:17:38 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 30 Dec 2018 20:17:37 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5EDAC599802; Sun, 30 Dec 2018 14:17:36 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5EDAC599802 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 52FF1407AA79; Sun, 30 Dec 2018 14:17:36 -0500 (EST) Date: Sun, 30 Dec 2018 14:17:36 -0500 (EST) From: Paul Wouters To: Joe Abley cc: Tony Finch , dnsop , "ipsec@ietf.org WG" , Ted Lemon In-Reply-To: Message-ID: References: <9DBE5370-BEA4-48CE-B9FB-356ED1CCC1E7@icann.org> <033DE6CA-B75E-4B06-A39E-323DCBBBC7A5@fugue.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] [DNSOP] [Ext] Favor: Weigh in on draft-ietf-ipsecme-split-dns? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Dec 2018 19:17:54 -0000 On Tue, 27 Nov 2018, Joe Abley wrote: > On 27 Nov 2018, at 10:02, Tony Finch wrote: > >> Really, I don't think this is (just) a VPN issue: the question of how to >> install DNSSEC trust anchors for private zones has not been solved for the >> general case, so a VPN-only patch seems premature and unhelpfully specific >> to me. As currently no one is able to do internal DNSSEC zones and VPNs, I cannot agree that is is premature or unhelpfully specific. It is a real solution to a real problem. Regardless of any generic solution, you end up with the same kind of considerations we reached here. A whitelist of zones that is securely provisioned and not dynamically updated, and flexibility to roll your internal trust anchor without locking out all your [VPN] clients from accessing internal resources. > To your point, Paul, I did see the text in the applicability and security considerations sections about ignoring the INTERNAL_DNSSEC_TA payloads in the case of non-split-tunnel situations. I understand the restriction to use in split tunnel scenarios, and the requirement to implement a whitelist, but I don't think either of those are particularly strong (and the consequences of ignoring or subverting them are more serious than I think the document gives credit for). When installing provisioning profiles, eg Apple tells you things like "this party can monitor everything you do, are you sure you want to do this". I don't think there is anything more you can do than that. Although if there is, clients can apply those additional security measures as local policy. For instance, a phone or laptop that is under Enterprise Management could forbid DNSSEC_TA installations outside of their signed profiles. Or a phone could decide DNSSEC_TA installations will only ever be accepted when under Enterprise management control. This draft does not forbid any of these kind of decisions. > For the split tunnel restriction, my pedantic objection is that all VPNs whose payload and scaffolding uses a single protocol (e.g. an IPv4 tunnel endpoint to build a tunnel through which to send IPv4) is a split tunnel, since the tunnel endpoint needs necessarily not to be encapsulated by the VPN client. Local networks are also frequently excluded in non-split configurations, too. Where is the strict definition of "split tunnel"? This is a real question; you know more about tunnel semantics than I do. > > My arguably more reasonable observation is that any non-enterprise, Netflix-gaming VPN service that wanted to be a bad actor could simply provide a split tunnel service (according to the definition I was looking for) described as something different, but covering enough of the IPv4 address space that the end-user had no real way of noticing, at which point the INTERNAL_DNSSEC_TA payload could presumably be accepted by the client. Yes they can. Netflix could send you a provisioning profile that says it wants to MITM gmail.com. You could install that because you trust Netflix. Trust is part of a company's success. Let's hope trustworthy companies won't screw around like this. Note also these companies already can trick people into install Root CA's, so this is basically a minor variant of the power they already have to subvert endusers. Sure, people are tricked in installing Random Inc things. They will click okay on any warning. Those people are beyond help. Yes we could not allow enterprises to have DNSSEC (which is basically what you say when you do not allow them to rollover keys indepedently of the VPN configuration) but that would be a tragedy of the commons. > In a strictly enterprise scenario it's not uncommon for the client configuration to be handled by the IT department as part of normal IT asset management. If the IT department is configuring the VPN client, is it really a stretch to imagine that they couldn't install a local validator and trust anchors at the same time? That would solve the .CORP and RFC1918-reverse cases for those end-users without having to worry about nefarious use of these proposed new payloads for end-users whose clients essentially have no informed administrator. If you expect administrators to maintain an accurate whitelist, surely they could just configure TAs and forward zones themselves. If there's no centralised mechanism to update that kind of configuration in a friction-free way to accommodate TA rolls then presumably the devices concerned should all be considered compromised and banned from connecting to the network anyway. VPN users cannot always update their provisioning on the spot, without being on the VPN already. VPN users often don't use the VPN for months, and only use it when traveling for example. Like on a dedicated travel phone. Your suggestion of hardcoding TA keys is imply impractical and won't fly in real operational deployments. It is extremely fragile. Having restrictions on the whitelist was already a compromise. Originally, the draft let IKE update the white list too. We (reluctantly) decided that we didn't want one compromised VPN device to be able to install malicious DNSSEC_TA's. So we limited the whitelist update to a (hopefully more secure) provisioning system. > One more thought; in a possible future where it's applications like browsers that do validation and not an OS-provided stub resolver library, this proposal leaves a gap between the VPN client (which might receive new trust anchor information) and those applications (which need signalling to know that such new trust anchor information exists). That seems worth mentioning, even if it's out of scope to provide a solution. If browsers create that painful world of overriding the OS, they will need to solve that. That is very far out of scope for this VPN draft, and we cannot stall this document for the multi-years discussion on DoH and DOT impact on overriding random DNS trees at whim, by users being ticked into configuring certain DoH/DOT servers. The problem is similar in nature, but totally orthogonal. > As is probably obvious I don't particularly like this proposal, but I also acknowledge that I'm perhaps not the target audience and I'm missing context that would make it seem more useful. If it goes ahead, maybe some of the observations here could help. I think DNSOP needs to realise that DNS VPN configuration is going to happen. With DNSSEC it is going to happen. We need to come up with a solutation that seems least scary while still being deployable. Simply saying no won't change the draft. If the draft doesn't change or is blocked by this, non-standard or draft solutions will be used leading to the same undesired outcome plus vague standards. I still believe the current draft describes the most strict, while still being usable, solution. I'm all up for smarter ideas from smarter people, but we have already sat down with a bunch of security people back at IETF 100, including the ADs and IPsecME chairs, and couldn't come up with something better than the current compromise proposal. Note that formally, the DISCUSS that triggered this was marked as resolved by Warren. I'm happy to discuss this for a bit longer if we are trying to build something that might be better. But we have done Early Code Points already so at some point we have to stop discussing and publish with the rough consensus. Paul