Re: [IPsec] Question on RFC 5723 Session Resumption

[Yaron Sheffer]

Hi Paul and Nupur,

I would also be interested to know what people implemented, because what you're 
suggesting, while possibly "the right thing", is clearly counter to the RFC. 
Sec. 6.2 and Sec. 9.8 are rather clear that no matter who deleted the IKE SA, 
the ticket is revoked and must not be used, and in fact the gateway must keep 
some limited state to ensure it.

So if you want to stay compliant with the RFC, IMHO you'd need a new 
notification for this "delete".

The case of a cluster of gateways is not handled by the RFC. This is alluded to 
at the end of the Introduction.

Thanks,
Yaron

On 8/27/20, 03:52, "IPsec on behalf of Paul Wouters"  wrote:


Hi,

We are working on implementing IKEv2 Session Resumption.
https://tools.ietf.org/html/rfc5723

We are only looking at ticket_by_value at this point.

It is unclear to me what is the behaviour related to Delete/Notify.
The RFC only takes into account situations where the connectivity is
lost and any delete/notify messages would no longer be received by
the responder. It states:

When the client wishes to recover from an interrupted session

But a client could use this mechanism when it wants to go to sleep and
tell the server this as well to avoid liveness probes. So the initiator
could send a delete, then come back later and use its ticket. This would
allow the responder to remove the state without waiting on liveness
timeouts to trigger cleanup of the vansihed client's state.

If the responder does not keep any state (which is the goal here) then it
would not know this session ticket belongs to an IKE SA that was deleted
by the initiator versus deleted by the responder's liveness/timeouts. The
RFC gives no guidance on this.

Similarly, if the responder keeps no state of the tickets it issued, it
would not be able to detect a ticket being used more than once without
the lifetime it set within the ticket itself.

When multiple gateways can read each others encrypted tickets, you could
also not prevent a ticket from being used more than once.

We are interested to know if any implementer bothered to track the issued
tickets and remove them from a list when received back (or timed out)

We are also interested to know if anyone prevents resuming a session
on the server side if the server has received delete/notifies for that
IKE SA.

Paul & Nupur

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


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

Re: [IPsec] Questions about RFC 5723

[Yaron Sheffer]

Paul, please don't hesitate to submit an editorial erratum if you think 
one is needed. If you don't "get" this RFC, it probably means something 
is missing.


Thanks,
Yaron

On 12/07/2019 17:34, Paul Wouters wrote:

On Fri, 12 Jul 2019, Valery Smyslov wrote:


A single (pair of ) IPsec SA is created as result of IKE_AUTH following
IKE_SA_RESUME, as if it follows IKE_SA_INIT instead of IKE_SA_RESUME.
If more IPsec SAs are needed they are created via CREATE_CHILD_SA,
as usual.


Ah I totally missed this part when reading the document. Things make
a lot more sense now. Thanks!


Also, when using PFS, these CREATE_CHILD_SA's would do a DH again, at
which point one wonders why to do resumption at all if you have more
than one IPsec SA, as you would be doing DH's anyway for all children,
you might as well do one more for a regular IKE_SA_INIT ?


In any case you save on authentication (this may involve signature
computing/verification and probably human intervention in case of EAP).


Indeed. Thanks for the clarifications!

I guess formally, we would need to add the previous IKE traffic counters
to the current one, since these are all derived from the same DH.

(yes, for FIPS we need to ensure there is not more than 2^20 or so AES
packets of IKE traffic, even though reaching that would be quite the
accomplishment)

Paul


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

Re: [IPsec] draft-abad-i2nsf-sdn-ipsec-flow-protection

[Yaron Sheffer]

On 18/07/17 17:14, Yoav Nir wrote:

I mostly agree, but one point…


On 18 Jul 2017, at 17:06, Tero Kivinen  wrote:




This I think is important question, i.e., what is the gain for not
running IKEv2 between the nodes?


Simpler gateway, less code, no PK operations, no need for random number 
generator.

The counter-argument is that without all these you can’t setup a TLS session to 
run netconf over.

Yoav

No random number generator? I don't think this is true even for a pure 
ESP endpoint.


Thanks,
Yaron

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

Re: [IPsec] IPsec and SDN

[Yaron Sheffer]

For key management you might want to refer them to the old but still 
useful RFC 4107 .


Thanks,

Yaron


On 18/07/17 10:45, Yoav Nir wrote:
We’re going to have a screaming match tomorrow at TLS about forward 
secrecy.


You don’t have forward secrecy if the session keys were generated by a 
third party. You’re replacing IKE with a three-party system.


But I am more worried about the second issue. I’m not sure SDN is the 
right model for configuring IPsec.


Yoav

On 18 Jul 2017, at 10:34, Paul Wouters > wrote:


ACE on Monday also mentioned this "SPDs without IKE" option. I 
expressed my concern that they believe IKE is only about sharing SPDs 
and keys and warned them against things like devices without 
batteries restarting and getting the same values and end up re-using 
the same counter for AEAD algorithms.


Sent from my iPhone

On Jul 18, 2017, at 10:29, Yoav Nir > wrote:



Hi.

This may be of interest to this working group.

The I2NSF working group is meeting this afternoon at 13:30

On the agenda ([1]) there’s a 10-minute slot for controlling IPsec 
endpoints using SDN ([2]).


I think this draft has two issues:

 1. Their IKE-less case (case #2) has session keys generated on the
controller and forwarded to the IPsec endpoints. IMO this
introduces new ways for the keys to leak.
 2. The information flow in the draft is all from the controller to
the endpoints. The controller is assumed to a-priori know the
entire topology of all endpoints. IMO this is not realistic for
VPNs where often the addresses are allocated by third party ISPs.


I think any SDN or SDN-like solution for populating the SPD and PAD 
would need to have information flowing from the endpoints to the 
controller about the protected domain of that endpoint. Before that 
you can’t generate the SPDs.


OTOH this group failed in creating something like that in the AD-VPN 
work item. Several companies are now offering their own “SD-WAN” 
solution that is partly about automatic configuration of IPsec tunnels.


So in case you’re interested, you can come to the I2NSF meeting and 
hear their presentation.



Yoav

[1] https://www.ietf.org/proceedings/99/agenda/agenda-99-i2nsf-02.txt
[2] 
https://tools.ietf.org/html/draft-abad-i2nsf-sdn-ipsec-flow-protection-03


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




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


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

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Yaron Sheffer]

Once again, we are moving the responsibility over security best 
practices from vendors into users. We should know better by now.


Thanks,
Yaron

On 16/11/16 15:56, Daniel Migault wrote:

Given the discussions on curdle. the trend is to use an empty context
with a clear security recommendation of using dedicated keys for each usage.
Yours
Daniel


On Nov 16, 2016 3:34 PM, "Yoav Nir" <ynir.i...@gmail.com
<mailto:ynir.i...@gmail.com>> wrote:

But yes, I agree that IPsec, TLS and Curdle should come to the same
conclusion either way.

And I think that in light of existing deployment, Ed25519ctx *with*
context is a very hard sell.

Yoav

> On 16 Nov 2016, at 15:32, Yoav Nir <ynir.i...@gmail.com
<mailto:ynir.i...@gmail.com>> wrote:
>
> No, I think he means Ed448 and Ed25519.
>
> Adding context to Ed25519 (so using Ed25519ctx) requires using a
different function than the one available in several implementations
such as libsodium.
>
> If we choose the no context option it doesn’t matter: Ed25519ctx
with empty context == Ed25519ctx
    >
> Yoav
>
>> On 16 Nov 2016, at 13:58, Yaron Sheffer <yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>> wrote:
>>
>> If you mean the same policy for IPsec and TLS, I fully agree.
>>
>> Context prevents cross-protocol attacks, and I wouldn't worry
about "encouraging bad behavior". Users will behave badly whether we
encourage them or not :-)
>>
>> Thanks,
>>  Yaron
>>
>> On 16/11/16 13:47, Daniel Migault wrote:
>>> i would like the same policy - context or no context - applied
to both
>>> EdDSA algo. ctx prevents cross protocol attacks but may
encourage bad
>>> practice.
>>>
>>> Yours,
>>> Daniel
>>>
>>>
>>> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" <yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>
>>> <mailto:yaronf.i...@gmail.com <mailto:yaronf.i...@gmail.com>>>
wrote:
>>>
>>>
>>>
>>>   On 16/11/16 12:41, Paul Wouters wrote:
>>>
>>>
>>>
>>>   On Nov 16, 2016, at 10:49, Yoav Nir
<ynir.i...@gmail.com <mailto:ynir.i...@gmail.com>
>>>   <mailto:ynir.i...@gmail.com
<mailto:ynir.i...@gmail.com>>> wrote:
>>>
>>>   So I suggest to add the following paragraph at the end of
>>>   section 2 of the eddsa draft:
>>>
>>> The context parameter for Ed448 MUST be set to the empty
>>>   string.
>>>
>>>
>>>   I agree. Context seems useful for generic crypto but not for
>>>   something that is already strongly bound by an IETF transport
>>>   protocol.
>>>
>>>   Additionally, we have a similar problem too when allowing the
>>>   same key in IKEv1 and IKEv2 where the key has different
security
>>>   properties.
>>>
>>>   Paul
>>>
>>>
>>>   I don't think there's any cost to having a non-empty context
string,
>>>   e.g. "IKEv2", and there's potentially value. TLS cross-protocol
>>>   attacks show that signatures can be abused even when embedded in a
>>>   transport protocol.
>>>
>>>   The fact that we have the same problem elsewhere is no reason to
>>>   propagate it further.
>>>
>>>   Thanks,
>>>   Yaron
>>>
>>>
>>>   ___
>>>   IPsec mailing list
>>>   IPsec@ietf.org <mailto:IPsec@ietf.org> <mailto:IPsec@ietf.org
<mailto:IPsec@ietf.org>>
>>>   https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>
>>>   <https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>>
>>>
>>>
>

___
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>




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

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Yaron Sheffer]

If you mean the same policy for IPsec and TLS, I fully agree.

Context prevents cross-protocol attacks, and I wouldn't worry about 
"encouraging bad behavior". Users will behave badly whether we encourage 
them or not :-)


Thanks,
Yaron

On 16/11/16 13:47, Daniel Migault wrote:

i would like the same policy - context or no context - applied to both
EdDSA algo. ctx prevents cross protocol attacks but may encourage bad
practice.

Yours,
Daniel


On Nov 16, 2016 1:35 PM, "Yaron Sheffer" <yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>> wrote:



On 16/11/16 12:41, Paul Wouters wrote:



On Nov 16, 2016, at 10:49, Yoav Nir <ynir.i...@gmail.com
<mailto:ynir.i...@gmail.com>> wrote:

So I suggest to add the following paragraph at the end of
section 2 of the eddsa draft:

  The context parameter for Ed448 MUST be set to the empty
string.


I agree. Context seems useful for generic crypto but not for
something that is already strongly bound by an IETF transport
protocol.

Additionally, we have a similar problem too when allowing the
same key in IKEv1 and IKEv2 where the key has different security
properties.

Paul


I don't think there's any cost to having a non-empty context string,
e.g. "IKEv2", and there's potentially value. TLS cross-protocol
attacks show that signatures can be abused even when embedded in a
transport protocol.

The fact that we have the same problem elsewhere is no reason to
propagate it further.

Thanks,
Yaron


___
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>




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

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

[Yaron Sheffer]

On 16/11/16 12:41, Paul Wouters wrote:




On Nov 16, 2016, at 10:49, Yoav Nir  wrote:

So I suggest to add the following paragraph at the end of section 2 of the 
eddsa draft:

  The context parameter for Ed448 MUST be set to the empty string.


I agree. Context seems useful for generic crypto but not for something that is 
already strongly bound by an IETF transport protocol.

Additionally, we have a similar problem too when allowing the same key in IKEv1 
and IKEv2 where the key has different security properties.

Paul


I don't think there's any cost to having a non-empty context string, 
e.g. "IKEv2", and there's potentially value. TLS cross-protocol attacks 
show that signatures can be abused even when embedded in a transport 
protocol.


The fact that we have the same problem elsewhere is no reason to 
propagate it further.


Thanks,
Yaron

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

Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03

[Yaron Sheffer]

Hi Valery,

Yes, these are lossy algorithms, but the TLS/HTTP attacks are all with 
lossless algorithms. And as far as I know, they are applicable to any 
situation where here is an attacker that can force traffic on the wire, 
mixed with other, non-attacker controlled traffic. So IMO they are not 
restricted to just HTTP.


Thanks,
Yaron

On 02/09/16 16:32, Valery Smyslov wrote:

Yaron,
I don't think these attacks are relevant to ESP compression.
As far as I understand, they rely on statistical analysis of the frame
lengthes when phonems are encoded with a lossy compression algorithm. I
don't see how it affects losless compression used in ESP.

Regards,
Valery.



Valery, here's what I could find:

* https://www.cs.jhu.edu/~cwright/oakland08.pdf
* http://www.techeye.net/security/skypes-encryption-destroyed-by-phonemes

And another attack was published recently, but I cannot find it.

So this is for voice, and the better known TLS attack are for HTTP.









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

Re: [IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03

[Yaron Sheffer]

Valery, here's what I could find:

* https://www.cs.jhu.edu/~cwright/oakland08.pdf
* http://www.techeye.net/security/skypes-encryption-destroyed-by-phonemes

And another attack was published recently, but I cannot find it.

So this is for voice, and the better known TLS attack are for HTTP.

Paul, why is this out of scope?

Thanks,
Yaron

On 02/09/16 14:25, Paul Wouters wrote:




On Sep 2, 2016, at 4:55 AM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:

Can we make all the compression algorithms SHOULD NOT instead of MAY?


I would love too (to remove the added complexity) but it is really out of scope 
for the algorithm update document.

Paul



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

[IPsec] Compression, was: Re: draft-mglt-ipsecme-rfc7321bis-03

[Yaron Sheffer]

Can we make all the compression algorithms SHOULD NOT instead of MAY? 
TLS got rid of compression altogether, there are numerous attacks on 
compressed traffic, and even the document states that these algorithms 
are not widely implemented.


Thanks,
Yaron

On 02/09/16 05:49, Paul Wouters wrote:


I just published draft-mglt-ipsecme-rfc7321bis-03 (well and -02)

(ietf announcement of these seems delayed?)

https://tools.ietf.org/html/draft-mglt-ipsecme-rfc7321bis-03

The changes are:

- Update 256-bit key sizes to MUST (except IoT) - similar to 4307bis
- Add Security Section from RFC7321
- Removed MAY algorithms (RC5, CAST, IDEA, ENCR_AES_CCM_16)
- Added note on ENCR_BLOWFISH
- Removed notes on removed MAY list entries (CCM & GCM flavours, GMAC,
CMAC))
- Removed non-ipsec entries and added note to introduction on these
- Removed no longer used RFC-4595 reference

I think this document is now ready for a call for adoption.

Paul

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


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

Re: [IPsec] Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt

[Yaron Sheffer]

On 05/08/16 15:54, Scott Fluhrer (sfluhrer) wrote:



-Original Message- From: IPsec
[mailto:ipsec-boun...@ietf.org] On Behalf Of Yaron Sheffer Sent:
Friday, August 05, 2016 3:49 AM To: ipsec@ietf.org Subject: [IPsec]
Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt

Scott et al.,

It's not great to include a list of algorithms in a particular
document, because it will quickly grow stale. I suggest to add
something like:

The preference of specific algorithms in IKE will likely change
over time. Please consult [rfc4307bis] or its follow-on document
for guidance on which algorithms are preferred and which need to be
avoided.


The point of listing algorithms here is to list which ones are
Quantum Safe, and which are not, as that may not be obvious to an
implementor.  Pointing them to 4307bis isn't helpful, as it doesn't
mention which ones are Quantum Safe.



My point was that nominally QR-resistant algorithms might still get
broken and be deprecated in 4307bis or maybe the next "bis". I guess my 
proposed text didn't make the point clearly enough.



Now, this draft is still fairly early (pending the discussion of
requirements); it is quite unlikely that it will be accepted as-is.
I agree that this might not be the ultimate right spot for it; we
might (say) amend 4307bis to explicitly state which algorithm is QR
or not (and also state that any RFC that defines future algorithms
will include their expected Quantum Resistance in the security
considerations).  However, until we have a landing spot for such
information, I can't think of any place better than this draft.


The trick to that is to add a new column to the IANA table
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5





Thanks, Yaron


 Forwarded Message  Subject: [IPsec] I-D Action:
draft-fluhrer-qr-ikev2-02.txt Date: Thu, 04 Aug 2016 20:45:43
-0700 From: internet-dra...@ietf.org To: i-d-annou...@ietf.org CC:
ipsec@ietf.org


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 of the IETF.

Title   : Postquantum Preshared Keys for IKEv2 Authors
: Scott Fluhrer David McGrew Panos Kampanakis Filename:
draft-fluhrer-qr-ikev2-02.txt Pages   : 12 Date
: 2016-08-04

Abstract: 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-fluhrer-qr-ikev2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-fluhrer-qr-ikev2-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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


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

[IPsec] Fwd: I-D Action: draft-fluhrer-qr-ikev2-02.txt

[Yaron Sheffer]

Scott et al.,

It's not great to include a list of algorithms in a particular document, 
because it will quickly grow stale. I suggest to add something like:


The preference of specific algorithms in IKE will likely change over 
time. Please consult [rfc4307bis] or its follow-on document for guidance 
on which algorithms are preferred and which need to be avoided.


Thanks,
Yaron


 Forwarded Message 
Subject: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
Date: Thu, 04 Aug 2016 20:45:43 -0700
From: internet-dra...@ietf.org
To: i-d-annou...@ietf.org
CC: ipsec@ietf.org


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 
of the IETF.


Title   : Postquantum Preshared Keys for IKEv2
Authors : Scott Fluhrer
  David McGrew
  Panos Kampanakis
Filename: draft-fluhrer-qr-ikev2-02.txt
Pages   : 12
Date: 2016-08-04

Abstract:
   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-fluhrer-qr-ikev2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-fluhrer-qr-ikev2-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Yaron Sheffer]

On 13/06/16 06:00, Yoav Nir wrote:



On 10 Jun 2016, at 5:39 PM, Yaron Sheffer <yaronf.i...@gmail.com
<mailto:yaronf.i...@gmail.com>> wrote:

Hi,

The document takes care to not define Implicit IV for AES-CBC, and I
believe the underlying reason is malleability of the encryption. The
same would apply to AES-CTR. So I would suggest to:

  * Exclude AES-CTR from this draft, or...
  * Better yet, restrict the draft to AEAD algorithms.

BTW, the reference for AES-GCM is incorrect. Should be 4106.

Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key
material. Is that kept intact by the current proposal?



Hi, Yaron

AES-CTR is pretty similar to AES-GCM and AES-CCM, except for the
confusing terminology:

  * The 32-bit per-SA value derived from IKE is called “nonce” in RFC
3686 and “salt” in RFC 4106 (thanks for the corrected reference).
  * The concatenation of 32-bit per-SA value and IV is called “nonce” in
RFC 4106 and doesn’t have a name in RFC 3686.
  * The concatenation of 32-bit per-SA value, IV, and block counter is
called “counter block”  in RFC 3686, but isn’t explicitly mentioned
in RFC 4106. The GCM spec also calls it “counter block”.


AFAICT it is not malleable like CBC. In CBC the issue was that an
attacker knowing the next IV would be able to generate the first block
of the next message such that IV xor Block0 would be whatever the
attacker wanted. That block would be the input to the encryption
function and thus the attacker could force the encryptor to encrypt
whatever block it wanted. With counter mode (or GCM or CCM) the attacker
has no control on the inputs to the encryption function. That is why RFC
3686 has text similar to the other documents:

The same
IV and key combination MUST NOT be used more than once.  The
encryptor can generate the IV in any manner that ensures uniqueness.
Common approaches to IV generation include *incrementing a counter* for
each packet and linear feedback shift registers (LFSRs).

So I think CTR belongs in this draft as much as the others.

And yes, the GCM salt or the CTR nonce are derived in the same way and
used in the same way.

Yoav



AES-CTR is potentially malleable by a MITM who can change counter values 
into ones she'd observed before. However since RFC 3686 is very emphatic 
about the need for integrity protection (Sec. 3.3), we should be fine.


Thanks,
Yaron

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

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

[Yaron Sheffer]

Hi,

The document takes care to not define Implicit IV for AES-CBC, and I 
believe the underlying reason is malleability of the encryption. The 
same would apply to AES-CTR. So I would suggest to:


 * Exclude AES-CTR from this draft, or...
 * Better yet, restrict the draft to AEAD algorithms.

BTW, the reference for AES-GCM is incorrect. Should be 4106.

Speaking of which, AES-GCM in ESP has a "salt" derived from IKE key 
material. Is that kept intact by the current proposal?


Thanks,

Yaron

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

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

[Yaron Sheffer]

On 04/12/2016 12:16 PM, Tero Kivinen wrote:

Yaron Sheffer writes:

Thanks for your response, I am fine with your comments but I have a
question: in Sec. 4.2, we have: "With the use of Digital Signature,
RSASSA-PKCS1-v1.5 MAY be implemented.  RSASSA-PSS MUST be implemented."
And then the table has SHOULD for RSA (as well as ECDSA). How come?


RSASSA-PSS MUST be implemented if Digital Signature authentication
method is implemented, but it can be implemented with multiple hash
algorithms. On the other hand in hash algorithms part we have just one
MUST and that is for SHA2-256.

The reason why RSASSA-PSS with SHA-256 is listed only as SHOULD, is
mostly caused by the fact that Digital Signature authentication method
is still onl SHOULD and we do not have implementations for it, so we
do not have implementor comments for it yet.

So Digital Signature in general is SHOULD.

SHA2-256 as hash algorithm is MUST when implementing Digital Signature
authentication method.

RSASSA-PSS is MUST when implementing Digital Signature.

That would actually make RSASSA-PSS with SHA-256 a effective MUST, if
Digital Signature is in general supported, but we do not label it as
MUST as complient implementation can still decide not to implement
digital signatures at all.


Coming to think of it, if we want to ensure interoperability between
peers that use RSA certs and peers that use ECDSA certs, then at least
one (probably RSA) needs to be a MUST, even if people are using RFC7427.


Usually this is not a problem, i.e., in normal use the configuration
has just one private key (either rsa or ECDSA) and that is what is
used. If you have ECDSA private key and they implementation does not
support ECDSA, you cannot use that implementation, you need to pick
another implementation. The other end of the configuration is also
configured to trust your private key (either by config, or through
CA), and if it cannot support your private key type you cannot really
configure it that way. I.e., the implementation requirements do not
come from this document, they came from the pre-existing
authentication infrastructure and private keys users have.

Anyways when we make Digital Signature authentication method a MUST,
we can also make RSASSA-PSS with SHA-256 a MUST.

The question there is should we already mark this fact by making it
now SHOULD+, as we do expect it to be next mandatory to implement
algorithm if Digital Signature authentication method really gets
deployed?



IMHO, yes.

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

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

[Yaron Sheffer]

Hi Tero,

Thanks for your response, I am fine with your comments but I have a 
question: in Sec. 4.2, we have: "With the use of Digital Signature, 
RSASSA-PKCS1-v1.5 MAY be implemented.  RSASSA-PSS MUST be implemented." 
And then the table has SHOULD for RSA (as well as ECDSA). How come?


Coming to think of it, if we want to ensure interoperability between 
peers that use RSA certs and peers that use ECDSA certs, then at least 
one (probably RSA) needs to be a MUST, even if people are using RFC7427.


Thanks,
Yaron

On 04/11/2016 02:47 PM, Tero Kivinen wrote:

Yaron Sheffer writes:

4.1: have we considered making "Digital Signature" (#14) a SHOULD+
instead of a SHOULD?


Yes, I think we discussed it, but I think we should really see at
least one implementation before we pick it as SHOULD+ level...

Has anybody implemented this yet?

This is still quite new, i.e., about year old, and as product cycles
tend to be quite slow in the VPN gateways, I have not yet seen any
implementations.


4.2: aren't we trying to move the world to the generic "Digital
Signature", even if they're still using old certs?


Yes.


If we are, then (gasp) PKCS1 v1.5 needs to be SHOULD.


Why? There is no relationship between the RSASSA-PSS and
RSASSA-PKCS1-v1.5 signatures in the certificates and in the AUTH
payload.

I.e., you can have RSASSA-PKCS1-v1.5 signature in the certificate, and
use the RSASSA-PSS with SHA-256 to generate the AUTH payload.

Also as we do say that RSASSA-PSS MUST be implemented, that means that
every implementation which sends out the SIGNATURE_HASH_ALGORITHMS and
conforms to this document, must support RSASSA-PSS, thus
implementations can always use it when using RSA keys.

Only reason to support RSASSA-PKCS1-v1.5 is to support RFC7427
implementations which are made before this 4307bis document came out,
and which do not support RSASSA-PSS required here.


And the table should mention sha256WithRSAEncryption.


Which by defination is then MAY. And it is MAY because it is not using
SHA1 (which would make it SHOULD NOT), and it is using old
RSASSA-PKCS1-v1.5 which is only MAY.

We did remove all MAY lines from the table in last round.



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

Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

[Yaron Sheffer]

I think this document is in very good shape, and almost ready.

The two areas where I think some more discussion may be needed are 
interoperability between IoT and "real" VPNs, and the migration to the 
RFC 7427 Digital Signature solution. See detailed comments below.


1.2: "an algorithm will be set to MAY", replace by "an algorithm will be 
denoted here as MAY".


1.2, last paragraph: I suggest to clarify what we mean by interop with 
IoT, so that we do not fragment IKE2 between the IoT and non-IoT worlds. 
Something like: "Requirement levels that are marked as "IoT" apply to 
IoT devices and to server-side implementations that might presumably 
need to interoperate with them, including any general-purpose VPN 
gateways." Maybe we should clarify it more by defining an IoT Context 
and adding separate lines to some of the tables for IoT vs. non-IoT Context.


3.3: AUTH_DES_MAC - the last sentence doesn't apply to it, so the 
paragraph needs to be rearranged.


4.1: have we considered making "Digital Signature" (#14) a SHOULD+ 
instead of a SHOULD?


4.2: aren't we trying to move the world to the generic "Digital 
Signature", even if they're still using old certs? If we are, then 
(gasp) PKCS1 v1.5 needs to be SHOULD. And the table should mention 
sha256WithRSAEncryption.


Thanks,
Yaron

On 04/08/2016 09:09 PM, Paul Hoffman wrote:

Greetings. As discussed on the list for the past few weeks, and in the
face-to-face meeting in Buenos Aires (which, for many of us, seems to
translate to "too much beef"), draft-ietf-ipsecme-rfc4307bis is ready
for WG Last Call. We would like everyone to review it carefully, given
that there have been some significant changes over the past few months.

This WG Last Call will end on April 22. It would be grand if everyone on
this list would read the draft as if it was brand new and respond on the
list with any problems, any questions, or even just "it is ready to
progress as-is". Extra points are given for reviewers who don't wait
until the last minute.

--Paul Hoffman and Dave Waltermire

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


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

Re: [IPsec] EdDSA Signatures in IKE

[Yaron Sheffer]

"Identity" is the formally correct term, but I think "null" is much 
clearer than "identity". Especially in the context of certificates, 
where "identity" can be mistaken for something else.


Thanks,
Yaron

On 04/08/2016 01:29 AM, Yoav Nir wrote:



On 7 Apr 2016, at 6:12 PM, Tero Kivinen  wrote:

Yoav Nir writes:

Tero: What would it take to register an “identity” hash function for
use with the EdDSA?


I assume you mean new value for the RFC7427 Hash Algorithm registry?
That registry is by expert review, but as "identity" is not
necessarely clear enough for the implementors, I would suggest writing
internet-draft doing the allocation, and also explaining how the
"identity" hash function would be used and where it can be used.

That same draft could also point references to the suitable cfrg
document, and recommend not using the ph versions.


Like this?
https://tools.ietf.org/html/draft-nir-ipsecme-eddsa-00


I.e., if we could use existing hash and signature algorithms then
there would not be need for document, but if we want to define new
"hash" algorithm, then I think we do need document that specifies
where it can be used and how it is "calculated". And that same
document can then also explain the signature algorithms where it is to
be used, and provide references.


On 5 Apr 2016, at 11:09 AM, Yoav Nir  wrote:

Replying to myself...

I’ve been told off-list that it didn’t make sense to introduce the
hot, new algorithm as a MAY. The only reason I’m suggesting this
is that there are currently no implementations to interop with,
and no EdDSA certificates where the public keys might come from.
My main motivation is to MUST NOT the pre-hashed versions because
we don’t need them and again there’s no install base to interop
with.

Thinking it over, the new EdDSA signature algorithm defined in the
CFRG draft[1] can sign arbitrary-sized messages. We traditionally
fed the signature functions hashes of the message because these
signature functions only accepted a limited-size input. That is
why the “digital signature” document (RFC 7427) has a negotiation
and field for hash algorithm. Since we don’t need that with this
particular algorithm, I suggest we don’t. IOW I’m suggesting that
we allocate a new entry in the “IKEv2 Hash Algorithms” registry
called “identity” that will be used only with EdDSA signatures (or
any future signature with the same property).

--
kivi...@iki.fi


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



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

Re: [IPsec] Textual changes to the DDoS draft

[Yaron Sheffer]

After reading the pull request, I suggest that we require the responder 
to verify all 4 puzzles. Although I don't have a proof why this is 
better (e.g. a game theoretic cost/benefit analysis), it would remove an 
unnecessary design decision from implementations at a trivial cost in 
performance.


Thanks,
Yaron

On 02/25/2016 09:50 PM, Valery Smyslov wrote:
That was also my impression. And the draft is already being edited to 
include multiple puzzles.

Valery.

- Original Message -
*From:* Yoav Nir 
*To:* Waltermire, David A. 
*Cc:* ipsec@ietf.org WG 
*Sent:* Friday, February 26, 2016 8:43 AM
*Subject:* Re: [IPsec] Textual changes to the DDoS draft



On 26 Feb 2016, at 2:03 AM, Waltermire, David A.
> wrote:

I haven’t seen any additional feedback on the DDoS draft this
week based on Yoav’s note about the PR [1]. It also looks like
the discussion on chaining puzzles has wrapped up with no changes
needed to the draft [2].


Oh. My impression of [2] was that Valery and I were in agreement
that this change was a good idea, with Scott and Yaron supporting
(not quite as enthusiastically) and with not opinions to the
contrary. Valery and I thought we’d make this change over the
weekend.

Yoav


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



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


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

Re: [IPsec] DDoS Protection - single vs multiple solutions

[Yaron Sheffer]

Scott's idea was different, and possibly better. At the cost of some 
Responder compute work, his idea makes the Initiator's effort nearly 
deterministic.


https://mailarchive.ietf.org/arch/msg/ipsec/30_tZekTBxdYPFVc6B1bXaEMtEQ

Thanks,
Yaron

On 02/17/2016 09:17 PM, Yoav Nir wrote:

On 17 Feb 2016, at 6:09 PM, Yoav Nir  wrote:


A while ago Scott Fluhrer suggested a way to make this more fair

As it turns out, this was first suggested by Yaron:
https://mailarchive.ietf.org/arch/msg/ipsec/_JUTE8p5H6bhFOA1HCuaYX1NCKQ

Scott’s idea was a little different.

Sorry for the confusion.

Yoav


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


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

Re: [IPsec] SLOTH & IKEv2

[Yaron Sheffer]

Sec. 2.6: When a responder detects a large number of half-open IKE SAs, 
it SHOULD reply to IKE_SA_INIT requests with a response containing the 
COOKIE notification.  The data associated with this notification MUST be 
between 1 and 64 octets in length (inclusive), and its generation is 
described later in this section.


On 01/15/2016 11:15 PM, Paul Wouters wrote:

On Fri, 15 Jan 2016, Yoav Nir wrote:

The initiator cannot validate the cookie - it is an opaque blob for 
him. Should he reject

the cookie if its length is more than 64 bytes? Possibly. I don't know.
It's a bit strange to check an opaque object…


It’s an opaque object that the RFC says should be up to 64 bytes.


I tried to find a reference that the cookie is max 64 bytes and coul not
find it. So I concluded the valid max is a regular Notify payload length
specified in two octets, so 65535 bytes. I'm happy to be proven wrong :P

The responder accepts a cookie that it never sent. It doesn’t check 
the cookie because there is, in fact, no DoS attack. That seems wrong.


As I also explain, it is probably motivated by supporting the server
switching to "no longer need cookies" and clients coming with a cookie
not getting denied. I agree that the server should still check any
cookie it receives, or after a timer reject all connections with
a (guaranteed false) cookie. But that would need to be an update to
RFC 7296.

Paul

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


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

Re: [IPsec] SLOTH & IKEv2

[Yaron Sheffer]

However, thank you for bringing in the SLOTH attack.
As fas as I understand from the paper 
http://www.mitls.org/downloads/transcript-collisions.pdf it is based 
on the ability for an attacker to find collisions in a weak hashes 
(md5 and sha1). In particular the authors uses chosen-prefix collision 
attacks

to break some security protocols. They mostly focused on breaking TLS,
but Section VI contains description of a possible attack on IKEv2.

As far as I understnd the attack on IKEv2 it is based on the cookie 
request

feature. The attacker makes a cookie request to the initiator
with the cookie crafted in such a way, that the hash of the 
IKE_SA_INIT message
containing this cookie would collide with the hash of the IKE_SA_INIT 
message

containing attacker-chosen KE payload. It would allow the attacker
to impersonate the initiator.

If I got it right the ability for an attacker to quickly find a hash 
collision
is based (besides using weak hashes) on presumption that the cookie is 
always the very first payload in the message,

as depicted in the Section 2.6 in the RFC 7296. So it is
presumed that the cookie always preceedes any unpredictable
for the attacker values in the message, that allows to perform
an effective chosen-prefix attack on a hash.

So, I think that we can completely thwart this attack (regardless
on the possible weakness of the used hashes) if we make
a recommendation for implementers to put the cookie at the
end of the message. RFC 7296 doesn't imply any restrictions
on the payloads order. However the Section 2.6 states:

  If the IKE_SA_INIT response
  includes the COOKIE notification, the initiator MUST then retry the
  IKE_SA_INIT request, and include the COOKIE notification containing
  the received data as the first payload, and all other payloads
  unchanged.
It's a bit unclear for me whether this MUST is concerned with the 
requirement to retry request only, in which case it is only

a recommendation to place the COOKIE before other payloads,
or the MUST is also applied to the text that COOKIE is the first 
payload (that would be unfortunate).


What does IPsec community think of it? Should we fix the protocol
to thwart this attack completely? Is the recommendation to move the 
COOKIE to the end of the message enough to achive that?

Will this change break many existing implementations?

Regards,
Valery Smyslov.


As far as I can tell, the cookie hash algorithm is an implementation 
decision of the responder and (despite what's implied in the paper) is 
never specified in the protocol. It would be much simpler to add a 
section to the new 4307bis saying that this hash is security-critical, 
and recommending SHA-256 or stronger.


The experience with TLS is that making small protocol changes to protect 
against weak algorithms is not a good long-term strategy. It's just a 
challenge for researchers to come up with better attacks.


I believe the hash-and-URL mechanism is not used in practice. But if it 
is, that's another place where we have hardcoded SHA-1, and maybe we 
should start worrying about it.


Thanks,
Yaron

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-02.txt

[Yaron Sheffer]

Two comments to the new version:
- I suggest you add a reference to RFC 7427 (Signature Auth).
- We still have SHA1 as a MUST in Sec. 4.2. Shouldn't it be deprecated, 
at least to MUST- ?


Thanks,
Yaron

On 01/05/2016 03:31 AM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the IP Security Maintenance and Extensions 
Working Group of the IETF.

 Title   : Algorithm Implementation Requirements and Usage 
Guidance for IKEv2
 Authors : Yoav Nir
   Tero Kivinen
   Paul Wouters
   Daniel Migault
Filename: draft-ietf-ipsecme-rfc4307bis-02.txt
Pages   : 13
Date: 2016-01-04

Abstract:
The IPsec series of protocols makes use of various cryptographic
algorithms in order to provide security services.  The Internet Key
Exchange protocol provides a mechanism to negotiate which algorithms
should be used in any given Security Association.  To ensure
interoperability between different implementations, it is necessary
to specify a set of algorithm implementation requirements and Usage
guidance to ensure that there is at least one algorithm that all
implementations will have available.  This document defines the
current algorithm implementation requirements and usage guidance of
IKEv2.  This document does not update the algorithms used for packet
encryption using IPsec Encapsulated Security Payload (ESP)


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


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

Re: [IPsec] New revision of TCP Encapsulation draft

[Yaron Sheffer]

Hi Samy,

Thanks for the new draft. It addresses most of my comments, but one 
question remains.


I still don't understand why we require that each connection should 
start with an IKE message. The explanation given is "to allow the peer 
to know with which IKE session the traffic is associated." But of course 
the ESP SPI identifies the Child SA, and implicitly, the IKE SA.


Moreover, later in the same section you allow multiple IKE SAs over the 
same connection, which again doesn't work well with the reasoning above.


Best,
Yaron

On 12/08/2015 08:40 AM, Samy Touati wrote:

Hi Yaron and Yoav,

An updated draft addressing your comments has been posted.

https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt

Please check it out, and provide feedback.


Thanks.
Samy.


*From:* Yaron Sheffer <yaronf.i...@gmail.com 
<mailto:yaronf.i...@gmail.com>>

*Sent:* Nov 20, 2015 3:11 PM
*To:* Tommy Pauly; IPsecME WG
*Subject:* Re: [IPsec] New revision of TCP Encapsulation draft

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited
under "prior work", both because it is documented and also because I
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers
will use UDP encapsulation even when there is no NAT on the path, for
example because networks or middleboxes do not support IP protocols
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams
don't send anything) and is hard to understand. There are lots of
networks that use jumbo frames and so hardcoding the value 1500 into the
spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs that
are all associated with the same IKE SA. So I'm wondering why we are
insisting on all Child SAs being in the same connection, and as a result
requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly
that if the connection is closed midway through a message, the recipient
must silently drop the partial message.

You may want to add to the last paragraph of the Security
Considerations: This document explicitly does not define a profile for
TLS when used in this manner, or any relation between identities at the
IPsec level and those at the TLS level ("channel binding").

Thanks,
Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> Hello,
>
> Based on the feedback received at our informal meeting in Yokohama, 
I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:

>
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01
>
> The revisions include:
> - More explanation in the introduction about the motivation, and 
other work that this draft is trying to standardize (3GPP 
recommendations, proprietary IKEv1 IPSec over TCP versions, and SSL VPNs).
> - Comments about maximum IKE and ESP message size within the TCP 
stream, which is effective the MTU of the tunnel.
> - Specify that if the TCP connection is brought down and 
re-established, the first message on the stream must be an IKE message.
> - Detailed considerations about interactions with middleboxes 
(thanks Graham Bartlett for input on this).

>
> In the meeting in Yokohama, there was general agreement that this 
was relevant work that we’d like to keep looking into. Please read the 
document, and provide any feedback you have!

>
> Thanks,
> Tommy
> ___
> IPsec mailing list
> IPsec@ietf.org <mailto:IPsec@ietf.org>
> https://www.ietf.org/mailman/listinfo/ipsec
>

___
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec



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


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

Re: [IPsec] New revision of TCP Encapsulation draft

[Yaron Sheffer]

Hi Tommy,

Thanks for clarifying this point. But I still think we are making a 
protocol change for what can be solved easily at the implementation 
level. Implementations will need to tag each IKE SA with the currently 
valid TCP connection on which responses can be sent. And ESP SAs likely 
already point to their parent IKE SA. So when we have an ESP packet that 
needs to be sent back from the responder, why not look up its associated 
IKE SA and use it to find the TCP connection?


IMHO it would be better if we can stick to the simple model of a TCP 
wrapper for an unordered pile of IKE and ESP messages. This would add 
TCP with the minimal change to ESP, IKE and the relationship between them.


Thanks,
Yaron

On 12/08/2015 10:24 PM, Tommy Pauly wrote:

Hi Yaron,

The original version of the draft did not require that the new TCP 
connection begin with an IKE message, but it was added in response to 
feedback we received at our meeting in Yokohama.


The concern was that the new TCP connection would almost certainly 
have different ports from the old connection. In order for the server 
to send packets back to the client, it needs to know the correct 
mapping for both the IKE SAs and the Child SAs. If we allow an ESP 
packet to be the first packet of a new connection, it may be hard to 
implement a correct server that reacts to that and adjusts all 
associated IKE and Child SA values to use the new port. However, it 
the first packet is an IKE packet, the server can essentially treat it 
as if it were MOBIKE and reset the ports.


In the case of multiple IKE SAs over a TCP connection (which is a new 
edge case that has been brought up), perhaps it would make sense to 
say that for all IKE SAs using the connection, at least one IKE 
message must precede any ESP messages for a Child SA of the IKE SA.


Does this make sense?

Thanks,
Tommy

On Dec 8, 2015, at 2:12 AM, Yaron Sheffer <yaronf.i...@gmail.com 
<mailto:yaronf.i...@gmail.com>> wrote:


Hi Samy,

Thanks for the new draft. It addresses most of my comments, but one 
question remains.


I still don't understand why we require that each connection should 
start with an IKE message. The explanation given is "to allow the 
peer to know with which IKE session the traffic is associated." But 
of course the ESP SPI identifies the Child SA, and implicitly, the 
IKE SA.


Moreover, later in the same section you allow multiple IKE SAs over 
the same connection, which again doesn't work well with the reasoning 
above.


Best,
Yaron

On 12/08/2015 08:40 AM, Samy Touati wrote:

Hi Yaron and Yoav,

An updated draft addressing your comments has been posted.

https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-tcp-encaps-02.txt

Please check it out, and provide feedback.


Thanks.
Samy.


*From:* Yaron Sheffer <yaronf.i...@gmail.com>
*Sent:* Nov 20, 2015 3:11 PM
*To:* Tommy Pauly; IPsecME WG
*Subject:* Re: [IPsec] New revision of TCP Encapsulation draft

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be 
cited

under "prior work", both because it is documented and also because I
believe it is implemented by a vendor.

In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers
will use UDP encapsulation even when there is no NAT on the path, for
example because networks or middleboxes do not support IP protocols
other than TCP and UDP."

"Although a stream" - this paragraph is not worded very well (streams
don't send anything) and is hard to understand. There are lots of
networks that use jumbo frames and so hardcoding the value 1500 into 
the

spec may not be a good idea.

I can think of HA cases where several gateways are handling ESP SAs 
that

are all associated with the same IKE SA. So I'm wondering why we are
insisting on all Child SAs being in the same connection, and as a 
result

requiring that an IKE message be the preamble to any new connection.

Although it might seem obvious, I think Sec. 3 should say explicitly
that if the connection is closed midway through a message, the 
recipient

must silently drop the partial message.

You may want to add to the last paragraph of the Security
Considerations: This document explicitly does not define a profile for
TLS when used in this manner, or any relation between identities at the
IPsec level and those at the TLS level ("channel binding").

Thanks,
Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:
> Hello,
>
> Based on the feedback received at our informal meeting in 
Yokohama, I’ve updated the draft for TCP Encapsulation of IKEv2 and ESP:

>
> https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01
>
> The revisions include:
> - More explanation in the introduction about the motivation, and 
other work that this draft is trying to standardize (3GPP 
recommendations, proprietary I

Re: [IPsec] New revision of TCP Encapsulation draft

[Yaron Sheffer]

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
under "prior work", both because it is documented and also because I 
believe it is implemented by a vendor.


In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
will use UDP encapsulation even when there is no NAT on the path, for 
example because networks or middleboxes do not support IP protocols 
other than TCP and UDP."


"Although a stream" - this paragraph is not worded very well (streams 
don't send anything) and is hard to understand. There are lots of 
networks that use jumbo frames and so hardcoding the value 1500 into the 
spec may not be a good idea.


I can think of HA cases where several gateways are handling ESP SAs that 
are all associated with the same IKE SA. So I'm wondering why we are 
insisting on all Child SAs being in the same connection, and as a result 
requiring that an IKE message be the preamble to any new connection.


Although it might seem obvious, I think Sec. 3 should say explicitly 
that if the connection is closed midway through a message, the recipient 
must silently drop the partial message.


You may want to add to the last paragraph of the Security 
Considerations: This document explicitly does not define a profile for 
TLS when used in this manner, or any relation between identities at the 
IPsec level and those at the TLS level ("channel binding").


Thanks,
Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:

Hello,

Based on the feedback received at our informal meeting in Yokohama, I’ve 
updated the draft for TCP Encapsulation of IKEv2 and ESP:

https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01

The revisions include:
- More explanation in the introduction about the motivation, and other work 
that this draft is trying to standardize (3GPP recommendations, proprietary 
IKEv1 IPSec over TCP versions, and SSL VPNs).
- Comments about maximum IKE and ESP message size within the TCP stream, which 
is effective the MTU of the tunnel.
- Specify that if the TCP connection is brought down and re-established, the 
first message on the stream must be an IKE message.
- Detailed considerations about interactions with middleboxes (thanks Graham 
Bartlett for input on this).

In the meeting in Yokohama, there was general agreement that this was relevant 
work that we’d like to keep looking into. Please read the document, and provide 
any feedback you have!

Thanks,
Tommy
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



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

Re: [IPsec] New revision of TCP Encapsulation draft

[Yaron Sheffer]

Hi Tommy,

I also think this is very relevant work. Here are some comments to -01:

I think that Yoav's draft, draft-nir-ipsecme-ike-tcp-01, should be cited 
under "prior work", both because it is documented and also because I 
believe it is implemented by a vendor.


In Sec. 1, under the UDP encapsulation, I suggest to add "Often peers 
will use UDP encapsulation even when there is no NAT on the path, for 
example because networks or middleboxes do not support IP protocols 
other than TCP and UDP."


"Although a stream" - this paragraph is not worded very well (streams 
don't send anything) and is hard to understand. In addition, there are 
lots of networks that use jumbo frames and so hardcoding the value 1500 
into the spec may not be a good idea.


I can think of HA cases where several gateways will handle ESP SAs that 
are all associated with the same IKE SA. So I'm wondering why we are 
insisting of all Child SAs being in the same TCP connection, and as a 
result requiring that an IKE message should be the preamble of any new 
connection.


Although it might seem obvious, I think Sec. 3 should say explicitly 
that if the connection is closed midway through a message, the recipient 
MUST silently drop the partial message.


You may want to add to the last paragraph of the Security 
Considerations: This document explicitly does not define a profile for 
TLS when used in this manner, or any relation between identities at the 
IPsec level and those on the TLS level ("channel binding").


Thanks,
Yaron

On 11/20/2015 11:49 PM, Tommy Pauly wrote:

Hello,

Based on the feedback received at our informal meeting in Yokohama, I’ve 
updated the draft for TCP Encapsulation of IKEv2 and ESP:

https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-01

The revisions include:
- More explanation in the introduction about the motivation, and other work 
that this draft is trying to standardize (3GPP recommendations, proprietary 
IKEv1 IPSec over TCP versions, and SSL VPNs).
- Comments about maximum IKE and ESP message size within the TCP stream, which 
is effective the MTU of the tunnel.
- Specify that if the TCP connection is brought down and re-established, the 
first message on the stream must be an IKE message.
- Detailed considerations about interactions with middleboxes (thanks Graham 
Bartlett for input on this).

In the meeting in Yokohama, there was general agreement that this was relevant 
work that we’d like to keep looking into. Please read the document, and provide 
any feedback you have!

Thanks,
Tommy
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec



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

Re: [IPsec] RFC 4307bis

[Yaron Sheffer]

Looks good. One small correction:

many IKEv2 have not implemented => many IKEv2 implementations do not include

Thanks,
Yaron

On 11/16/2015 06:05 PM, Daniel Migault wrote:

Hi,

Thank you Yaron for your comments. Please find the new update ot the draft:

https://github.com/mglt/drafts/commit/0b2696ada172163930f3733a7c3155d49bca0002

Comment 1:
IKEv1 is out of scope of this document. IKEv1 is deprecated and the
recommendations of this documentmust not be considered for IKEv1.

I change MUST NOT in must not. I left the whole sentence as I beleive,
it provides the reason why IKEv1 is not in scope and state clearly that
applying considerations in this document to IKEv1 is a bad idea.

Comment 2:
I added some clarifying text on why not MUST. To me the obvious reason
is that an algorithm not mentioned in RFC4307 should not have a status
greater than SHOULD -- unless otherwise of course ;-). I though we had
this explanation somewhere, but maybe it is missing and should be added
in the intro for example.

I also provided dome explanation why ESP and IKEv2 are in a different
race which resulted in having AES-GCM not widely deployed for IKEv2

Comment 3:
"As it is not being deployed" as been replaced by "as it is not widely
deployed"

"and now it is known to be weak at least for a nation state" has been
changed to "and now it is known to be weak against a nation-state attacker".

Acknowledgement section has also been updated.

BR,
Daniel


On Tue, Nov 10, 2015 at 4:01 PM, Tero Kivinen <kivi...@iki.fi
<mailto:kivi...@iki.fi>> wrote:

Yaron Sheffer writes:
> The rationale for GCM describes why it's in the table, but seems to
> argue for a MUST (rather than the SHOULD that's in the table). I guess
> there's a reason why we don't have MUST, let's spell it out.

The reason for that is that it is not needed as IKEv2 SA is never used
to transmit huge amounts of data, thus the speed benefits you might
get from there is not needed. Also support for the combined modes do
require support for RFC5282, and there are implementations which have
not done that (as there is no benefits or need for them to implement
it).
--
kivi...@iki.fi <mailto:kivi...@iki.fi>

___
IPsec mailing list
IPsec@ietf.org <mailto:IPsec@ietf.org>
https://www.ietf.org/mailman/listinfo/ipsec




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

Re: [IPsec] RFC 4307bis

[Yaron Sheffer]

A few comments, sorry for not using GitHub.

I think the following text is kinda funny: "IKEv1 is out of scope of 
this document. IKEv1 is deprecated and the recommendations of this 
document MUST NOT be considered for IKEv1." We cannot tell people 
normatively what they can consider and what they cannot. Let's skip the 
capitalized MUST NOT.


The rationale for GCM describes why it's in the table, but seems to 
argue for a MUST (rather than the SHOULD that's in the table). I guess 
there's a reason why we don't have MUST, let's spell it out.


"As the overhead of AUTH_HMAC_SHA2_512 is negligible": suggest to change 
to "as the *additional* overhead".


I believe we should cite RFC 6194 when recommending against SHA-1.

"As it is not being deployed" - I suggest the softer "as it is not 
widely deployed" - we don't really know that nobody had ever deployed it.


"and now it is known to be weak at least for a nation state" - suggest 
to change to "and now it is known to be weak against a nation-state 
attacker".


Thanks,
Yaron

On 11/10/2015 12:33 AM, Yoav Nir wrote:

Or for a diff-style view, see the pull request:
https://github.com/ietf-ipsecme/drafts/pull/8/files

Yoav


On 10 Nov 2015, at 12:30 AM, Daniel Migault
> wrote:

Hi,

You can view the latest changes here:

https://github.com/mglt/drafts/blob/d2d31f6f9f0b4d57c8343826ad23fc546b99a467/draft-ietf-ipsecme-rfc4307bis

We added some text to recommend the status of each recommended algorithms.

On Mon, Nov 9, 2015 at 11:27 AM, Paul Hoffman > wrote:

On 9 Nov 2015, at 5:48, Yoav Nir wrote:

So I’ve merged the changes and submitted version -01 of the draft.

The stub paragraphs explaining the choices of algorithms are
waiting to be filled. Please submit pull requests.


https://github.com/ietf-ipsecme/drafts/blob/master/draft-ietf-ipsecme-rfc4307bis


This is an invitation to the WG to contribute to to this draft. If
you are already familiar with GitHub, submit pull requests as Yoav
said. If you are not yet familiar with GitHub, feel free to send
text to the mailing list, and one of the authors will quickly
enter those for you in GitHub. That is, being able to use GitHub
is *not* required for you to contribute text.

--Paul Hoffman


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


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




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



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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Yaron Sheffer]

If not here, where does this advice go?


I see your point. But for instance for X509 certificates, I really would
like to not make any statement and point to whatever equivalent of PKIX
documents there are on that. Does the TLS WG have any documents on
crypto agility for PKIX?


The TLS list currently has a thread about whether TLS 1.3 should prohibit SHA-1 
only in signatures or also in the certificate chain.


https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E


It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol 
(CertificateVerify message), and current spec prohibits server certificate 
signed with SHA-1 (only EE certificate) when another certificate exists.



For TLS, the industry is moving faster than the WG on this. Chrome 
warnings are causing people to migrate to all-SHA256 certificate chains 
soon. IKE often works with custom certs and private CAs, so the IPsec 
community needs to set its own standards.


Thanks,
Yaron

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

[IPsec] Leadership change

[Yaron Sheffer]

  
  
Dear members of the IPsecME working group,

After co-chairing the IPsecME working group for 7 years ever since its inception, I have decided that both I and the working group could benefit from a change. I have asked the security ADs to relieve me of this position, and I am glad they came up with a worthy co-chair to continue leading the group, alongside Paul.

David Waltermire is with the National Institute of Standards and Technology where he works on standardizing approaches to automate security processes. He has been active at the IETF as a contributor in a number of working groups including SACM and MILE, and as Security Directorate member and reviewer. He has a background in systems, network, and software engineering. David is looking forward to working with the IPsecME working group in this new role. 

I am proud of what we have achieved in the working group and grateful to the small core of old timers and some not-so-old timers who have worked and are still working to maintain IPsec as a secure and relevant part of the Internet's infrastructure. I wish best of luck to Paul, Dave and the rest of the team.

I intend to continue being active within the Security Directorate, so I'll be seeing you, guys and gals.

Thanks,
	Yaron
  


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

Re: [IPsec] My review of draft-nir-ipsecme-curve25519

[Yaron Sheffer]

In the section 3.2 recipient tests there is discussion about checking
that the public key 32-octet string will have last byte in such way
that high-order bit of it is not set.

If this is property of the func(d, G) for curve25519, and curve448,
how can we ever get public values having that bit set? So why it is
only SHOULD to reject that public key? I mean if we receive such
public key, that clearly means that other end is either attacker, or
working incorrectly, and we MUST always reject it.

Or if there is no security issues accepting such public keys, then why
not just say that no checks needs to be done. If we reject such public
key, what behavior should happen in IKE level? Error message, drop
silently? Same as RFC6989?


Tough one. The draft says something about implementation fingerprinting, but if 
some implementations drop this at the IKE level and some don’t that’s is a new 
avenue for fingerprinting. I don’t know which one is right. In any case, *if* 
you make the check *and* it fails *then* it’s appropriate to send an 
INVALID_SYNTAX (although I don’t understand why RFC 6989 recommends that over 
INVALID_KE_PAYLOAD) notification.



RFC 6989 recommends INVALID_SYNTAX because per RFC 7296, 
INVALID_KE_PAYLOAD is used for cases where the initiator is expected to 
retry the exchange. Incorrect DH values are at best a bug and at worst 
an attack, and should not result in an automatic retry.


Thanks,
Yaron

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

Re: [IPsec] PSK mode

[Yaron Sheffer]

Even in a world where quantum computers are a risk that we need to 
consider in our crypto, QKD will still remain a niche.


So to go back to the original question, NTRU+BLISS are a possible 
solution if we care about this problem. QKD is not.


Thanks,
Yaron

On 08/24/2015 06:36 PM, Paul Wouters wrote:

On Mon, 24 Aug 2015, Tero Kivinen wrote:


I think we should continue pushing the
draft-nagayama-ipsecme-ipsec-with-qkd forward, and specify it as
generic method where out of band shared keys can be brought in to the
SKEYSEED or KEYMAT.


+1

Paul

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


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

[IPsec] DDoS draft next steps

[Yaron Sheffer]

  
  
Dear authors and WG members,

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

We would like to see if the working group would be interested in a
more focused draft. Some options:

  Make the draft more attractive by solving the problem of
mobile clients (did I hear "memory-intensive puzzles"? someone
even mentioned Captcha), then try again to get consensus around
it.
  Publish only the protocol part of the document, basically Sec.
3 and 8, as an Experimental RFC.

There are probably other options.


Ideas?


Thanks,
    Yaron


  


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

[IPsec] IPsecME DDoS draft - please review

[Yaron Sheffer]

  
  
Hi,

The authors and the working group brought the draft
(https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/)
into pretty good shape, but we're not done yet. To prepare for the
Prague session with this draft as our only active one, I suggest
that those people who care about DDoS protection give the draft one
more read during the coming week, and send their comments to the
list.

Thanks,
    Yaron

  


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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.txt

[Yaron Sheffer]

Quick nit: the sentence The Pad Length field need not exceed 4 octets 
is a bit confusing, because the Pad Length field is obviously a constant 
2 octets. I would suggest The Padding field's length (and the value of 
the Pad Length field) need not exceed 4 octets.


Thanks,
Yaron

On 06/14/2015 09:46 AM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the IP Security Maintenance and Extensions 
Working Group of the IETF.

 Title   : ChaCha20, Poly1305 and their use in IKE  IPsec
 Author  : Yoav Nir
Filename: draft-ietf-ipsecme-chacha20-poly1305-09.txt
Pages   : 12
Date: 2015-06-13

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-09


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



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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-chacha20-poly1305-09.txt

[Yaron Sheffer]

Sure.

On 06/14/2015 02:11 PM, Yoav Nir wrote:

How about:

OLD:
The Pad Length field need not exceed 4 octets. However, RFC 4303 and this 
specification do not
prohibit using greater pad lengths.

NEW:
The length of the Padding field need not exceed 4 octets. However, neither 
RFC 4303 nor this
specification require using the minimal padding length.

Yoav


On Jun 14, 2015, at 10:37 AM, Yaron Sheffer yaronf.i...@gmail.com wrote:

Quick nit: the sentence The Pad Length field need not exceed 4 octets is a bit 
confusing, because the Pad Length field is obviously a constant 2 octets. I would suggest The 
Padding field's length (and the value of the Pad Length field) need not exceed 4 octets.

Thanks,
Yaron

On 06/14/2015 09:46 AM, internet-dra...@ietf.org wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the IP Security Maintenance and Extensions 
Working Group of the IETF.

 Title   : ChaCha20, Poly1305 and their use in IKE  IPsec
 Author  : Yoav Nir
Filename: draft-ietf-ipsecme-chacha20-poly1305-09.txt
Pages   : 12
Date: 2015-06-13

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


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-chacha20-poly1305/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-ipsecme-chacha20-poly1305-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-chacha20-poly1305-09


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



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




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

[IPsec] IPsecME: agenda items for Prague

[Yaron Sheffer]

  
  
Hi,

Paul and I are working on our agenda for the upcoming meeting. We
have a 1 hr slot planned. If you'd like to claim part of it, do let
us know.

Thanks,
    Yaron
  


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

Re: [IPsec] Ignoring UDP/TCP checksums

[Yaron Sheffer]

This is a great article, but I disagree with his point about IPsec. ESP 
detects malicious or benign data corruption on the wire, and I don't 
think it is the job of IPsec to detect errors that are actually 
introduced by bugs in the sender's network stack. So I think that 
exempting the receiver from verifying the checksum was a correct decision.


Thanks,
Yaron

On 05/14/2015 06:23 PM, Russ Housley wrote:


http://arstechnica.com/information-technology/2015/05/the-discovery-of-apache-zookeepers-poison-packet/

This article describes a set of four bugs that caused a serious problem
for one open source project:

RFC 3948 tells the tale. It states that while using IPSec in NAT-T
Transport mode, the client MAY forgo the validation of the TCP/UDP
checksum under the assumption that packet integrity is already protected
by ESP. ... The assumption made by the authors is invalid, as there is
clearly ample opportunity for corruption prior to ESP/IP formation.
While checksumming is a great way to detect in-flight corruption, it can
also be used as a tool to detect corruption during the formation of the
packet. It is the latter point that was overlooked, and this
optimization has come to bite us. ... We claim this is a bug—intentional
or not.

Russ


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



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

Re: [IPsec] Restarting the discussion about the puzzle

[Yaron Sheffer]

IMO we should choose a reasonable balance and fix it in the document. We 
should care about packet size for sure, but 64 hashes are not that much 
work.


Thanks,
Yaron

On 05/11/2015 06:01 PM, Yoav Nir wrote:



On May 9, 2015, at 7:32 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:

Hi Yoav,

First, I raised a third concern, which is that allowing the client to decide on 
the difficulty of the puzzle it is willing to solve adds unneeded complexity. 
Basically the client doesn't have enough information to make a good decision.

To answer your question, I think we've already been down this path and reducing 
the variance is certainly a good thing.



I’m sure that less variance is better than more variance, but that comes at the 
expense of more work for the responder. So do we set the number of returned 
results to 1, with minimal work for the responder and maximum variance?  Do we 
set it to 8, with a nice balance between fairness and responder work?  Do we 
set it to 64, with a huge packet, a lot of responder work and maximum fairness? 
 Or do we let the responder decide and communicate through the challenge, which 
has some complexity cost?

Yoav




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

Re: [IPsec] Restarting the discussion about the puzzle

[Yaron Sheffer]

Hi Yoav,

First, I raised a third concern, which is that allowing the client to 
decide on the difficulty of the puzzle it is willing to solve adds 
unneeded complexity. Basically the client doesn't have enough 
information to make a good decision.


To answer your question, I think we've already been down this path and 
reducing the variance is certainly a good thing.


Thanks,
Yaron

On 05/07/2015 04:52 PM, Yoav Nir wrote:

Hi.

As a reminder, there were two concerns about the difficulty of puzzles:
• That some clients are weaker than others and therefore are able to 
try less keys in a unit of time
• That individual puzzles might prove more difficult than other 
puzzles, so some “unlucky” initiators might take too long to solve the puzzle.

This is about the second issue. I’d be glad if someone could make a measurement 
of solving the proposed puzzle on an ARM processor so that we can know how much 
of an issue #1 is.

As Tero has mentioned, there are no easy or hard puzzles. Depending on how you 
order your guesses you might stumble upon the solution very quickly, or you 
might be trying millions of keys before hitting the answer. Choose a different 
ordering of your guesses for the same puzzle, and you might get very different 
results.  Still, we don’t like that luck plays such a role.

One way to reduce the variance is to increase the sample size: instead of 
looking for one key for a hard puzzle, we can require the initiator to return 
several correct solutions for an easier puzzle.  The advantage is that it 
indeed reduces the variance. The disadvantage is that the responder’s job 
becomes more difficult, as it has to verify not one but several correct 
solutions.

I’ve run a test of 20 randomly-generated cookies, and set the puzzle difficulty 
to 20 bits when requiring 1 solutions, 19 bits when requiring 2 solutions, 18 
bits when requiring 4 solutions, etc. The full results are in the attached 
Excel file (all results in seconds), but here’s a summary:

Bits | keys | median | % over twice median
-+--++
| 20 |   1  |  0.947 |  30.0%
| 19 |   2  |  1.309 |  15.0%
| 18 |   4  |  1.464 |   5.0%
| 17 |   8  |  1.516 |   1.5%
| 16 |  16  |  1.499 |   0.5%
| 15 |  32  |  1.507 |   0.0%
| 14 |  64  |  1.499 |   0.0%
-+--++——

I could increase the sample to get more accurate results, or look for results 
that are 3 times the median or 3 times the average etc. But just looking at 
this it seems to me that either 8 or 16 keys is the sweet spot, where an 
initiator is not likely to get stuck, a packet is not too big, and the load on 
the responder is not too great.

Comments?

Yoav



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



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

Re: [IPsec] [RFC5723] initiator flag setting in resume exchange

[Yaron Sheffer]

Hi Kathy,

Where not specified otherwise, the IKE_SESSION_RESUME exchange behaves 
exactly like the IKE_SA_INIT exchange.


This means in my opinion, that the client that sends the first 
IKE_SESSION_RESUME message should have the Initiator Flag set. And the 
table in Sec. 5 applies not only to after resumption but in this case, 
to the resumption exchange as well.


Thanks,
Yaron

On 05/04/2015 11:23 PM, Lihua Wan wrote:

Hi all,
In RFC5723 section 5, it mentions

  ++--+
  | State Item | After Resumption |
  ++--+

...

  | Which peer is the original| Determined by the initiator of   |
  | initiator?| IKE_SESSION_RESUME.  |


If client is initiator of IKE_SESSION_RESUME, I understand client is the
original initiator AFTER resumption. So the initiator flag in the IKE
header should be set by client after resumption.
My question is what about the resume request packet during resume
exchange? Should client set the initiator flag in IKE header when it
sends out resume request?

The case is like blow:
1. Gateway initiated IKE rekey completed.
2. Connection is suspened.
3. Client sends a resume request to gateway in the RESUME exchange.

In step 3, should the IKE header sent by Client set the initiator flag?
I know if client sets the initiator flag, then gateway should response
with the initiator flag cleared.
But according to RFC7296 initiator flag explanation, Gateway is the
initiator of last IKE SA rekey. I am not sure which side should be set
the initiator flag during resume exchange.


Thanks.

Kathy


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



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

Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11

[Yaron Sheffer]

I am still a bit confused about Sec. 3 (use in IKEv2):

- Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) 
that the IV is included explicitly, and where exactly it should go?


- In the bullet that describes the IV, I would add text that the IKE 
Message ID is not an option, and why.


- How do we make sure that the key/IV combination is unique between 
Initiator and Responder?


Thanks,
Yaron

On 04/27/2015 01:44 AM, Paul Hoffman wrote:

Greetings again. This begins the two-week WG Last Call on 
draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love 
to hear from people in either of two groups:

- Those who have already reviewed an earlier version of this draft. Please 
re-read the draft now, and let us know if it is perfect, or if there anything 
else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and 
Valery.

- Those who have *not* yet reviewed this draft, but want to help the IETF create good standards in 
this area. If you are an IPsec implementer, or know one at your organization, reviewing this draft 
and sending any comments to the list (even just seems fine or I liked it except 
this one thing) is useful to all of us.

It seems very likely that this new algorithm combination will appear in IKEv2 
and ESP soon, and having folks give a bit more review will help prevent 
whoopsies in the future.

--Paul Hoffman



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

Re: [IPsec] WG Last Call for draft-ietf-ipsecme-chacha20-poly1305: starts now, ends May 11

[Yaron Sheffer]

Clearly we need to mention that the IV is included, despite the text of 
RFC 7296.


You are right about SK_ei/er. The second bullet in Sec. 3 should not 
mention KEYMAT, which is unrelated, and maybe should mention SK_ei/er.


Thanks,
Yaron

On 04/27/2015 11:38 AM, Yoav Nir wrote:



On Apr 27, 2015, at 10:46 AM, Yaron Sheffer yaronf.i...@gmail.com wrote:

I am still a bit confused about Sec. 3 (use in IKEv2):

- Where does it say (in this draft or in Sec. 2.7 of the CFRG draft) that the 
IV is included explicitly, and where exactly it should go?


It says that the IV is 64-bit, same as in section 2, and RFC 7296 section 3.14 
says that the IV is explicit. Although in honesty, it also says that the size 
of the IV is equal to block length, which would make it 512 bits here?  Anyway, 
RFC 7296 does say that this is true only for CBC.


- In the bullet that describes the IV, I would add text that the IKE Message ID 
is not an option, and why.


The whole idea of using sequence number as IV is now gone from the draft. If we 
want to add some path-not-taken text, it should probably go in the Security 
Considerations or maybe another appendix. I don’t really think it is relevant.


- How do we make sure that the key/IV combination is unique between Initiator 
and Responder?


PRF+ generates a bitstring with separate SK_ei and SK_er for the initiator and 
responder respectively. Each is 36 octets (288 bits). While we don’t explicitly 
prevent PRF+ from generating the same 36 bytes twice, good PRFs hardly ever 
will. The same is not true for IKEv1 (RFC 2409) where the same SKEYID_e is used 
by both.


Thanks,
Yaron

On 04/27/2015 01:44 AM, Paul Hoffman wrote:

Greetings again. This begins the two-week WG Last Call on 
draft-ietf-ipsecme-chacha20-poly1305, which ends Monday May 11. We would love 
to hear from people in either of two groups:

- Those who have already reviewed an earlier version of this draft. Please 
re-read the draft now, and let us know if it is perfect, or if there anything 
else you want added or changed. This includes Yaron, PaulW, Tero, ScottF, and 
Valery.

- Those who have *not* yet reviewed this draft, but want to help the IETF create good standards in 
this area. If you are an IPsec implementer, or know one at your organization, reviewing this draft 
and sending any comments to the list (even just seems fine or I liked it except 
this one thing) is useful to all of us.

It seems very likely that this new algorithm combination will appear in IKEv2 
and ESP soon, and having folks give a bit more review will help prevent 
whoopsies in the future.

--Paul Hoffman



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




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

Re: [IPsec] Two questions about draft-ietf-ipsecme-chacha20-poly1305-00

[Yaron Sheffer]

Here's the reason that we do use the 32-bit salt value for GCM - to prevent 
batching attacks.

Consider the case that an attacker is able to collect packets from a billion 
(2^30) sessions; each such session contains a packet with the same IV (say, 
IV=0), and contains a packet with the same known plaintext (or, at least, 
plaintext that satisfies the same known linear equations).  Then, what an 
attacker can do is check a key to see if any of the IV=0 packets used that key, 
in constant time.  The reduces the effort for an attacker to find the n bit key 
for some session from 2^n to 2^{n-30}.  What the salt does is multiply the 
effort involved in this specific attack by a factor of 2^32 (because the 
attacker needs to guess the key and the salt); that way, the attacker needs to 
collect 4 billion sessions before this attack starts to have any advantage over 
a simpler attack that just attacks a single packet (which the salt doesn’t 
protect against).

Now, of course, chacha20 has 256 bit keys; hence even if we decided not to 
apply the same protection, someone with a collection of a billion sessions 
might be able to use this to reduce the effort to 2^226.

I'll let you decide whether this is a compelling argument or not…


I think that for 256-bit keys it’s not that compelling. So the question is 
which is simpler: to do as AES-GCM does, or to set the salt to zero?



It seems to me like a truth in advertising kind of thing: if we use a 
256-bit cipher then people using it expect 256-bit strength, rather than 
2^226. So I would be happy if we can get the salt without having to pay 
in packet length.


Thanks,
Yaron

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

Re: [IPsec] Early code point assignment

[Yaron Sheffer]

Not while the latest revision still has two TBDs, while we're still 
debating two interop-critical issues (padding, salt) and another major 
security issue (IV).


I don't want private use numbers any more than PaulW, but I also don't 
want errata like we had for TLS EtM.


We can iron out these issues within a week or two and then I'd be all in 
favor of a code point assignment.


Thanks,
Yaron

On 04/01/2015 04:26 AM, Yoav Nir wrote:

OK, so this thread kind of got side-tracked about the name of the
algorithm.  I think ENCR_CHACHA20_POLY1305 works for everybody.

What about early code point assignment?

Thanks

Yoav


On Mar 31, 2015, at 12:15 PM, Yoav Nir ynir.i...@gmail.com
mailto:ynir.i...@gmail.com wrote:

One more thing.

I would like to request early code point assignment for
ESP_ChaCha20-Poly1305.

I know that it is the goal of the chairs to bring this to LC sooner
rather than later, but I would like to get started on implementation
sooner rather than later, and the IETF process takes three months at
best, and six months in the more common case.

Thanks

Yoav




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



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

Re: [IPsec] Puzzles in IKEv2

[Yaron Sheffer]

Hi Valery,

Sorry if I was inconsistent on this one.

This is a performance optimization, and it's a trade off for the 
responder: Do I want to cache keys, thereby saving on CPU but wasting 
more memory on potentially useless SAs? So I suggest to make it a MAY, 
not a SHOULD.


Thanks,
Yaron

On 03/06/2015 04:34 AM, Valery Smyslov wrote:

What else could we recommend to do in this situation?
If responder deletes IKE SA in case it receives IKE_AUTH
message that doesn't pass ICV check, then it would give
an attacker an easy way to prevent legitimate initiator
to connect - just monitor the network and once IKE_SA_INIT
from the legitimate client is finished, inject IKE_AUTH message
containing garbage.


I suggest we do similar thing we do for IKEv2 in general. I.e. if you
get IKE_AUTH message which does not pass ICV, you simply drop it. I
would expect most of the implementations do that already. Also before
you can verify the ICV you need to know the SK_a and to be able to get
that you need to calculate SKEYSEED, which requires g^ir, i.e 2nd half
of Diffie-Hellman.


Agree.


So at that point you have already calculated the Diffie-Hellman. Also
implementation would be completley stupid if it would not store the
SKEYSEED and SK_* keys once it has calculated them, so I would expect
every implementation do that already, i.e. they will already keep
them, and there is no need to say anything about this in here.


I think there is no harm if the draft recommends such behaviour
explicitely.
After all, it is about DDoS protection, so every thing that
concerns the desense, even evident, should be spelled out.


If responder keeps half-open IKE SA for a while waiting
for more IKE_AUTH messages, then I see no reason to repeat
calculating D-H shared secret with every received message -
the result will be exacly the same.


Why would anybody ever repeat the D-H secret calculation, when they
have already calculated SKEYSEED (and SK_*) earlier?

Do we also need to say that for future notificaitons it would be nice
for implementations to keep the cached SK_* values stored in IKE SA,
and not to calculate the SK_* from the KE payloads for every single
packet?


That's what the draft recommends.


I do not think we need to say such thing, and I do not think
we need to say that once you have calculated the SK_* you keep them
until you delete the IKE SA.


It's better to spell this out, then to let implementers to do it wrong.

Regards,
Valery.



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

Re: [IPsec] Puzzles in IKEv2

[Yaron Sheffer]

Please keep it a SHOULD, but include the explanation.

Thanks,
Yaron

On 03/06/2015 09:50 PM, Valery Smyslov wrote:

Hi Yaron,


Hi Valery,

Sorry if I was inconsistent on this one.

This is a performance optimization, and it's a trade off for the
responder: Do I want to cache keys, thereby saving on CPU but wasting
more memory on potentially useless SAs? So I suggest to make it a MAY,
not a SHOULD.


At this point of our defense line we are defending against CPU consumption,
not memory consumption. We've already agreed to create an IKE SA state
and the keys,
while computed, adds relatively little to the size of the state.

So I'm reluctant to make it MAY. Probably a lowercase should with some
explanations of the reasons will satisfy you?

Regards,
Valery.


Thanks,
Yaron




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

Re: [IPsec] Puzzles in IKEv2

[Yaron Sheffer]

Hi Valery,

Thanks for the detailed clarification, and I still disagree... This 
situation is very unlikely with correctly functioning peers, and I don't 
think we should recommend acting on unauthenticated information, even if 
it slightly improves performance. Actually, I think it is a prototypical 
premature optimization.


Besides, if this is really a message that was altered in the network, 
how do we know that we produced correct key material?


Thanks,
Yaron

On 04/03/2015 07:47, Valery Smyslov wrote:

Hi Yaron,


Hi Valery,

to make it easier for everyone, I suggest that you submit a new draft 
version.


I completely agree with you - the amount of changes makes it difficult
to track them. We will definitely issue a new version shortly.


Commenting on the pull request, specifically:

If the puzzle is successfully verified and the SK_* key are 
calculated, but  the message authenticity check fails, the responder 
SHOULD save the calculated keys in the IKE SA state while waiting for 
the retransmissions from the initiator. In this case the responder 
may skip verification of the puzzle solution and ignore the Puzzle 
Solution payload in the retransmitted messages.


It seems to me that if any authenticity check fails, the responder 
MUST NOT make any changes at all to its saved state. Anything else 
would complicate implementations and create hard to analyze 
vulnerabilities. The only gain here is saving a single PRF operation 
on the responder's side, and it is not worth it.


I probably wasn't clear enough.

I was talking about the situation when IKE_SA_INIT exchange has been
already completed and the responder is waiting for the first IKE_AUTH
message. At this point the responder has all the needed information
to compute the Diffie-Hellman shared key, the SKEYSEED and the SK_* keys.
However, I assume that the responder should not do it immediately,
as the IKE_AUTH message could never arrive and it would be just
a waste of resources (and a subject to attack). Instead, the responder
starts computing the keys only when the IKE_AUTH request message
arrives. Moreover, if the responder gives a puzzle to the initiator,
then there is no point of doing any expensive computational operations
until the puzzle is verified, and this only can be done when the first
IKE_AUTH message arrives.

Once the IKE_AUTH message is received and the puzzle solution it contains
is verified the responder starts calculating DH shared secret, SKEYSEED
and the SK_* keys. Only after that can it verify authenticity of the 
received
IKE_AUTH message. And if this check fails, then the message must be 
discarded.
However, what the point to discard SK_* keys in this situation? All 
the information

to compute them was in the IKE_SA_INIT, that has been already finished.
We have only postponed the calculation to defend ourselves against 
possible
attack, but once the keys are calculated, we should keep them, since 
their calculation

is costly. And the IKE_AUTH message we've just discarded could be
accidentally altered in the network, so probably the next 
retransmitted message

would be valid, so there is no point in discarding the keys and making
hard work twice.

Does this clarifies the idea?

Regards,
Valery.


Thanks,
Yaron

On 04/03/2015 02:45, Valery Smyslov wrote:

Hi all,

I've updated my previous pull request.
The source file and changes are available at 
https://github.com/ietf-ipsecme/drafts/pull/2


Now it is completely described using puzzles in the IKE_SA_INIT and 
IKE_AUTH exchanges.

Payload formats and IANA considerations
are also provided.

Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec






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

Re: [IPsec] Puzzles in IKEv2

[Yaron Sheffer]

Hi Valery,

to make it easier for everyone, I suggest that you submit a new draft 
version.


Commenting on the pull request, specifically:

If the puzzle is successfully verified and the SK_* key are calculated, 
but  the message authenticity check fails, the responder SHOULD save the 
calculated keys in the IKE SA state while waiting for the 
retransmissions from the initiator. In this case the responder may skip 
verification of the puzzle solution and ignore the Puzzle Solution 
payload in the retransmitted messages.


It seems to me that if any authenticity check fails, the responder MUST 
NOT make any changes at all to its saved state. Anything else would 
complicate implementations and create hard to analyze vulnerabilities. 
The only gain here is saving a single PRF operation on the responder's 
side, and it is not worth it.


Thanks,
Yaron

On 04/03/2015 02:45, Valery Smyslov wrote:

Hi all,

I've updated my previous pull request.
The source file and changes are available at 
https://github.com/ietf-ipsecme/drafts/pull/2


Now it is completely described using puzzles in the IKE_SA_INIT and 
IKE_AUTH exchanges.

Payload formats and IANA considerations
are also provided.

Regards,
Valery Smyslov.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


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

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth

[Yaron Sheffer]

On Feb 27, 2015, at 1:58 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:




That's a good question, and you can see it both ways.

- The draft says that the PAD processing in RFC 4301 needs to be updated for 
this draft, so the draft updates RFC 4301.

- Implementations of RFC 4301 that do not care about IKEv2 using this draft 
should not be updated, so this draft doesn't update 4301, just the 4301 
processing when using IKEv2 and this draft.

I tend toward the second interpretation, but am happy either way. What do 
others think?

--Paul Hoffman


I tend the other way, so we need an example or two. If you read the abstract of RFC 6040, it says: 
On decapsulation, [RFC 6040] updates both RFC 3168 and RFC 4301 to add new behaviours for 
previously unused combinations of inner and outer headers. Which means that even though 
existing implementations are not affected until they encounter these new message variants, we use 
Updates because new implementations are expected to include the new behavior.


That's an interesting example, one from outside our WG. Note, however, that RFC 6040 is 
the *only* RFC that updates RFC 4301 so far. It seems odd that it is the only one like 
this draft that says and you need to change your PAD processing for this new 
thing.

Similarly, RFC 5282 Updates RFC 4306. Even though you only needed to 
change your implementation if you added AEAD. But it's not very 
important either way.


Thanks,
Yaron

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

Re: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth

[Yaron Sheffer]

That's a good question, and you can see it both ways.

- The draft says that the PAD processing in RFC 4301 needs to be updated for 
this draft, so the draft updates RFC 4301.

- Implementations of RFC 4301 that do not care about IKEv2 using this draft 
should not be updated, so this draft doesn't update 4301, just the 4301 
processing when using IKEv2 and this draft.

I tend toward the second interpretation, but am happy either way. What do 
others think?

--Paul Hoffman


I tend the other way, so we need an example or two. If you read the 
abstract of RFC 6040, it says: On decapsulation, [RFC 6040] updates 
both RFC 3168 and RFC 4301 to add new behaviours for previously unused 
combinations of inner and outer headers. Which means that even though 
existing implementations are not affected until they encounter these new 
message variants, we use Updates because new implementations are 
expected to include the new behavior.


Thanks,
Yaron

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

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yaron Sheffer]

Re: session resumption, I would like to propose the following text:

6.1. Session Resumption

When the Responder is under attack, it MAY choose to prefer previously 
authenticated peers who present a session resumption [RFC 5723] ticket. 
The Responder MAY require such Initiators to include a return 
routability ticket in the IKE_SESSION_RESUME message, as allowed by RFC 
5723, Sec. 4.3.2. Note that the Responder SHOULD cache tickets for a 
short time to reject reused tickets (Sec. 4.3.1), and therefore there 
should be no issue of half-open SAs resulting from replayed 
IKE_SESSION_RESUME messages.


Thanks,
Yaron

On 02/09/2015 04:52 PM, Yoav Nir wrote:



On Feb 9, 2015, at 4:03 AM, Paul Wouters p...@nohats.ca wrote:

On Sun, 8 Feb 2015, Yaron Sheffer wrote:


I think we've come a full circle. We now have a proposal that makes 
proof-of-work more deterministic for each type of client (which I find very 
useful). But the weaker clients will always lose, no matter what POW solution 
we choose. This has been a problem with this proposal from day one and it's a 
limitation that we as a group need to decide whether to accept or not.


I'm not yet convinced this proposal will provide a working solution to
the DDOS problem.


Hi, Paul

“solution” is hard. Whatever we do, an attacker with unlimited resources can 
throw more at us.

We could block all regular initiations under load, allowing only RFC 5723 
resumptions. But this allows an attacker to force us into this mode and 
effectively deny service to all initiators that don’t have a saved session.

So instead we can allow resumptions and also make it more costly for the 
attacker to mount the attack on regular initiations. Even an easy puzzle, one 
that my 1.2 GHz single-core ARMv5 with C code can solve in a second is much 
harder than just the return routability that COOKIE provides. The draft has 
text about how to make these puzzles a weapon of last resort, so legitimate 
users hardly ever need to solve them, but even setting the puzzle difficulty to 
something a strong desktop can do 20 times a second, it’s still better than the 
two other alternatives: allow the strong desktop to create 1000 half-open SAs 
in a second, or entirely block the subnet from which the desktop seems to come.

Yoav



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

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yaron Sheffer]

I think we've come a full circle. We now have a proposal that makes 
proof-of-work more deterministic for each type of client (which I find 
very useful). But the weaker clients will always lose, no matter what 
POW solution we choose. This has been a problem with this proposal from 
day one and it's a limitation that we as a group need to decide whether 
to accept or not. In a world where some clients are 100X more powerful 
than others, IMHO this result is something we have to live with.


The only partial solution I see to this problem is to recommend using 
RFC 5723 session resumption, so that clients who have recently connected 
can reconnect even in DoS situations.


Thanks,
Yaron

On 02/06/2015 10:22 AM, Valery Smyslov wrote:

Thinking it over, you don’t really need AES at all, and in any case it
doesn’t matter.
The initiator doesn’t know the key and doesn’t know the algorithm, so
it’s entirely a local matter.


You are right, it's a local matter.


For example, the responder could pick HMAC-SHA256 with a fixed key,
and calculate HMAC-SHA256(K,cookie).
And it’s not even necessary for the initiator to solve all of the
response. We can limit it to 8 Si-s (m=8), each 16 bits
(k=16) even though the output of HMAC-SHA256 is 256 bits. m only
serves to force the initiator to go through
most of the 2^k possibilities.


And another drawback of this approach is that the responder must do
quite a lot of work
to prepare puzzle. It must first calculate S1||S2||…||Sm and then for
each Si calculate Hi.
That is not an enormous work, but comparing with the current zero bits
proposal,
where the puzzle goes for free, it is non insignificant (especially as
we're trying
to protect responder against DoS attack).

And again, my main concern is whether we are solving the right problem.
This approah makes time requiring to solve random puzzle more consistent.
But it doesn't help weak clients, unless we allow them to return as many
Si-s, as they can. But in this case I see no significant advantages
of this approach, but I can see its complexity, increased message size
and increased load on responder.

Valery.


Yoav



On Feb 6, 2015, at 8:30 AM, Valery Smyslov sva...@gmail.com wrote:

I can see two drawbacks with this approach.

First, to make it aligned with algorithm agility, we need to
negotiate not only PRF, but also the encryption algorithm.
And the selection criteria would become more complex.

And second - it significantly increases the size of IKE_SA_INIT
response message, as the puzzle must include m hashes.
With SHA256 and m = 8 it is additional 256 bytes.
With SHA512 and m = 16 it is additional 1024 bytes.
That is not good as it increases the chance for IP fragmentation.

Regards,
Valery.


 On Feb 1, 2015, at 8:38 PM, Scott Fluhrer (sfluhrer)  
sfluh...@cisco.com wrote:

 If you want to tighten up the time between worse case and average
casetime taken by the problem solver, might I suggest this:

 - When the verifier is asked to generate a problem, it pick a nonce
N,and use it to compute m k-bit values
S_1, S_2, ..., S_m (for example, S_1 || S_2 || ... || S_m =
AES_key(N), where the AES key is secret to the verifier),
and publish k, N, HASH(N, S_1), HASH(N, S_2), ..., HASH(N, S_m)

 - To solve the problem, the solver needs to produce the values S_1,
 S_2,  ..., S_m, and send back N, S_1, S_2, ..., S_m

 - The verifier verifies that the value N was what was originally
given(for example, the nonce might include the solver's
IP address and a timestamp), and that the values S_1 ||  S_2 || ...
|| S_m = AES_key(N||0), (or alternatively,
that those values produces the hashes it sent).

 The solver can always solve the problem by computing 2**k hashes;
withmoderate m, we can make it unlikely
that it can be done with significantly fewer hashes; I would suggest
m=4.

 Of course, the cost of doing this is a) larger messages, and b)
largerup-front cost generating the problem
(which, IMHO, isn't too bad -- one AES encryption, and m hash
computations; however, you are free to disagree).


Hi, Scott.

Thanks for the suggestion. Let me see if I understand it correctly:

Responder has a fixed AES key (let’s call it K).

Let’s assume that N is a COOKIE calculated as in RFC 5996.

The responder Calculates S1||S2||…||Sm = AES(K, COOKIE). COOKIE can
be any length,
but for simplicity let’s assume 128-bit so that we don’t have to deal
with IVs, ICs or any other artifacts
of modes of operation. Also, let’s set m=8 and all Si as 16-bit.
So the responder now calculates 8 hashes: for each i Hi =
SHA256(COOKIE || Si) or better yet, Hi = PRF(Si, COOKIE).

The responder sends to the initiator:
- The COOKIE
- Hi for all i.
- The number k, although that can be deduced from the number of His
- An identifier for the PRF algorithm chosen.

The initiator needs to find Si values such that Hi = PRF(Si, COOKIE).
The silly way to do this is to solve run
through all 2^16 possible Si values once for each Hi (8 times), but a

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yaron Sheffer]

On Feb 8, 2015, at 1:20 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:

I think we've come a full circle. We now have a proposal that makes 
proof-of-work more deterministic for each type of client (which I find very 
useful). But the weaker clients will always lose, no matter what POW solution 
we choose. This has been a problem with this proposal from day one and it's a 
limitation that we as a group need to decide whether to accept or not. In a 
world where some clients are 100X more powerful than others, IMHO this result 
is something we have to live with.

The only partial solution I see to this problem is to recommend using RFC 5723 
session resumption, so that clients who have recently connected can reconnect 
even in DoS situations.


Can a gateway sanely do session resumption when it is under DoS attack? That 
is, can the gateway safely allocate CPU resources to a purported session 
resumption?

--Paul Hoffman



Yes, of course. It just needs to verify the integrity (MAC) of the 
received ticket (as easy or easier than our proposed puzzle 
verification), and then the rest of the exchange is lighter-weight than 
a typical IKE exchange. See 
http://tools.ietf.org/html/rfc5723#section-4.3.2.


Thanks,
Yaron

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

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yaron Sheffer]

Results are actually way better, with the 4X changed into 2X. However it 
seems to me that Scott's proposal is better - slightly more complex but 
certainly more deterministic.


Thanks,
Yaron

On 02/02/2015 08:31 AM, Yoav Nir wrote:

The three-sigma rule applies even with a non-normal distribution.

Anyway, I tried the 64-key sample. Results are slightly better.

Yoav





On Feb 1, 2015, at 7:36 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:

Hi Yoav,

This is good, but I'm not sure if it's good enough. The ratio between min and max (which 
I trust more than the mean +/- 3s rule, because this is not a normal 
distribution) is consistently around 4. So if you have to design your timeouts on a 
particular machine, you would still have a lot of uncertainty. For comparison, could you 
try again with 64 replacing the 16 tries, and with lower bit lengths?

Thanks,
Yaron

On 02/01/2015 11:46 AM, Yoav Nir wrote:

And now it’s really attached.





On Feb 1, 2015, at 11:45 AM, Yoav Nir ynir.i...@gmail.com wrote:



On Jan 31, 2015, at 12:35 AM, Yoav Nir ynir.i...@gmail.com wrote:



On Jan 30, 2015, at 3:37 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:

What I would suggest is: we give the client a single puzzle, and ask it to 
return 16 different solutions. Indeed each puzzle then should be 16X easier. 
The nice thing is, the server should only check *one* of them, at random. The 
client would still need to solve all of them because it doesn't want to risk 
the exchange being rejected because some solutions are invalid (the game theory 
is probably more complex than that, but I think what I'm saying is still close 
to the truth).

So: the client does the same amount of work, the server does the same amount of 
work, but the client run-time is still much more deterministic.


snip /


Note that these are still single core results, and most laptops can do twice or 
four times as much. Now, I know that what I SHOULD be doing is to randomly 
generate 100 “cookies” and then calculate the times for different bit lengths 
for each of them, and then calculate mean and standard deviation. But just by 
looking, it looks like it’s much closer to what we want. 16 bits would be a 
fine puzzle level for my laptop. No idea about a phone, although I could try to 
compile this and run it on an ARM-based appliance, which should match phones.


OK. Now I have done it right. See attached. The data suggests that 15 or 16 
bits is the level of puzzle that for this kind of hardware is challenging but 
not too onerous. Add another bit if we assume (probably correctly) that the 
vast majority of laptops have dual cores at least.

I would like to run a similar test on an ARM processor, though. The 
capabilities of phones and tablets are all over the place, what with different 
versions of ARM processors and devices having anything from dual to octo-core, 
but it would be nice to get ballpark figures.

Yoav







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

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yaron Sheffer]

Hi Yoav,

This is good, but I'm not sure if it's good enough. The ratio between 
min and max (which I trust more than the mean +/- 3s rule, because 
this is not a normal distribution) is consistently around 4. So if you 
have to design your timeouts on a particular machine, you would still 
have a lot of uncertainty. For comparison, could you try again with 64 
replacing the 16 tries, and with lower bit lengths?


Thanks,
Yaron

On 02/01/2015 11:46 AM, Yoav Nir wrote:

And now it’s really attached.





On Feb 1, 2015, at 11:45 AM, Yoav Nir ynir.i...@gmail.com wrote:



On Jan 31, 2015, at 12:35 AM, Yoav Nir ynir.i...@gmail.com wrote:



On Jan 30, 2015, at 3:37 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:

What I would suggest is: we give the client a single puzzle, and ask it to 
return 16 different solutions. Indeed each puzzle then should be 16X easier. 
The nice thing is, the server should only check *one* of them, at random. The 
client would still need to solve all of them because it doesn't want to risk 
the exchange being rejected because some solutions are invalid (the game theory 
is probably more complex than that, but I think what I'm saying is still close 
to the truth).

So: the client does the same amount of work, the server does the same amount of 
work, but the client run-time is still much more deterministic.


snip /


Note that these are still single core results, and most laptops can do twice or 
four times as much. Now, I know that what I SHOULD be doing is to randomly 
generate 100 “cookies” and then calculate the times for different bit lengths 
for each of them, and then calculate mean and standard deviation. But just by 
looking, it looks like it’s much closer to what we want. 16 bits would be a 
fine puzzle level for my laptop. No idea about a phone, although I could try to 
compile this and run it on an ARM-based appliance, which should match phones.


OK. Now I have done it right. See attached. The data suggests that 15 or 16 
bits is the level of puzzle that for this kind of hardware is challenging but 
not too onerous. Add another bit if we assume (probably correctly) that the 
vast majority of laptops have dual cores at least.

I would like to run a similar test on an ARM processor, though. The 
capabilities of phones and tablets are all over the place, what with different 
versions of ARM processors and devices having anything from dual to octo-core, 
but it would be nice to get ballpark figures.

Yoav





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

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yaron Sheffer]

To clarify: I am NOT suggesting that the responder should generate 8 
puzzles (8 cookies). I am suggesting that the initiator should send 8 
different solutions to the same puzzle, using something like Tero's 
proposal.


It is true that the execution time (a.k.a. client-side cost) will 
average out among many clients, so we would be fine WRT DoS protection. 
But it is still worthwhile to reduce the variance, in order to have a 
more deterministic user experience (for VPN clients) and to avoid 
client-side timeouts.


Thanks,
Yaron

On 01/30/2015 02:04 PM, Tero Kivinen wrote:

Valery Smyslov writes:

I also had some concerns on the variance of the times. But then
another thought came to me. Let's look on this issue from the other side.
The responder will use puzzles only when it feels that it is under attack.
It means, that there are a lot of (thouthands, tens of thouthands)
half-open connections. If responder requests that number of puzzles,
then some of them will appear to be easier to solve than the others.
Every initiator is different from another in terms of computing power and
each of them may receive more or less hard puzzle.
It's like an exam - some tasks are more easy to solve, some are harder.
Some clients will be more lucky, some less. That's a lottery.
But all those differences will be averaged for the responder, so why bother?


Yes, it is lottery, as the execution time is randomly distributed over
some max time. I agree that it does not really matter for this case,
as we are protecting server sending the puzzles, and clients do not
have way of knowing which puzzles are hard and which are easy.

Also if client decides it will only try to solve the puzzle for 0.5
seconds and then get new one, that will not help it, as the one he
already has might have been solved by just doing one more try, and the
re is no guarantee that the new one he got is easier.


Also if we require initiator to solve several puzzles, than it will need
to send back all the solutions, that will noticeably increase
IKE message size.


Not that much. The client could find number where:

0x01 + cookie + count1
0x02 + cookie + count2
0x03 + cookie + count3
0x04 + cookie + count4

and send back count cookie + count1-4 or something. The counters
should be smaller than cookie, most likely something that can be
expressed in 32 or 64 bits...

The execution time of the above should be not randomly over the whole
time, but binomial distribution over the time (or something like that,
it is way too long when I have been doing anything like this).


So, while the idea is interesting, I think that the problem it solves
is not important, so why should we bother?


Agree.


But it would be nice, if Yoav (as a person who already has
test bed) could check, that if we solve puzzle for 100
(or better 1000) different cookies, and average the times,
that the results will be less erratic (it would also be great
to measure the deviation of times for each level, not only average).


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

Re: [IPsec] DDoS puzzle: PRF vs Hash

[Yaron Sheffer]

What I would suggest is: we give the client a single puzzle, and ask it 
to return 16 different solutions. Indeed each puzzle then should be 16X 
easier. The nice thing is, the server should only check *one* of them, 
at random. The client would still need to solve all of them because it 
doesn't want to risk the exchange being rejected because some solutions 
are invalid (the game theory is probably more complex than that, but I 
think what I'm saying is still close to the truth).


So: the client does the same amount of work, the server does the same 
amount of work, but the client run-time is still much more deterministic.


Thanks,
Yaron

On 01/30/2015 02:42 PM, Yoav Nir wrote:

I’ll try that later, but suppose we give the client 16 puzzles to solve,
then we expect solving all of them to take 16 times as long, so they can
be 16 times easier. So instead of 22 bits, they can be 18 bits. I’m not
sure if that increased the chance of getting “stung” by a bad outlier or
that it averages better.

But one effect is obvious. If we require the client to solve all
puzzles, the server has to check all 16 parts of the solution, and that
makes it 16x harder for the server.

OTOH if we required to solve just one of the 16, the client could try
all 16 at the same time, and have a better chance of finding a “good”
outlier. Again, I’m not sure which is the dominant effect.

Yoav


On Jan 30, 2015, at 1:27 PM, Valery Smyslov sva...@gmail.com
mailto:sva...@gmail.com wrote:

Hi,
I also had some concerns on the variance of the times. But then
another thought came to me. Let's look on this issue from the other side.
The responder will use puzzles only when it feels that it is under attack.
It means, that there are a lot of (thouthands, tens of thouthands)
half-open connections. If responder requests that number of puzzles,
then some of them will appear to be easier to solve than the others.
Every initiator is different from another in terms of computing power and
each of them may receive more or less hard puzzle.
It's like an exam - some tasks are more easy to solve, some are harder.
Some clients will be more lucky, some less. That's a lottery.
But all those differences will be averaged for the responder, so why
bother?
Also if we require initiator to solve several puzzles, than it will need
to send back all the solutions, that will noticeably increase
IKE message size.
So, while the idea is interesting, I think that the problem it solves
is not important, so why should we bother?
But it would be nice, if Yoav (as a person who already has
test bed) could check, that if we solve puzzle for 100
(or better 1000) different cookies, and average the times,
that the results will be less erratic (it would also be great
to measure the deviation of times for each level, not only average).
Regards,
Valery.

- Original Message -
*From:* Yoav Nir mailto:ynir.i...@gmail.com
*To:* Yaron Sheffer mailto:yaronf.i...@gmail.com
*Cc:* IPsecME WG mailto:ipsec@ietf.org
*Sent:* Friday, January 30, 2015 2:41 AM
*Subject:* Re: [IPsec] DDoS puzzle: PRF vs Hash

Interesting. I’ve tried with a few different “cookies”.

Cookie: 4f331b879f6d02322aa894942f66473d8a1949625c488aa0f4f943b441cfd6f4
Key=…3db1  PRF=…4c82f8b8  #zeros=19  time=0.025
Key=…0002ea6c  PRF=…5faafb80  #zeros=23  time=0.250
Key=…0124159c  PRF=…9136e500  #zeros=24  time=26.013

Cookie: 6756a2fee7047eb87030b5cd7eb97ee24579371f54fecd3bc71f8b028f8c18b1
#zeros=14   time=0.016
#zeros=15   time=0.035
#zeros=19   time=0.134
#zeros=20   time=0.837
#zeros=21   time=1.932
#zeros=22   time=5.646
#zeros=24   time=16.790
#zeros=27   time=17.477

Cookie: 61a3a14b02580773234b8a773305aefed61c067775cea9c4797a406cd30fb14f
#zeros=15   time=0.016
#zeros=17   time=0.434
#zeros=21 time=1.034
#zeros=22   time=1.230
#zeros=23   time=16.213
#zeros=24   time=25.554
#zeros=

Seems like the big issue here is inconsistency. Set the puzzle level
to 22 bits, and it could be solved in a quarter second or in 5.6
seconds or in 1.230. And these are not just outliers - they’re the
first three values I picked at this length.

20 bits seems an acceptable difficulty level, but beyond that it
becomes too erratic.

Yoav


On Jan 29, 2015, at 11:57 PM, Yaron Sheffer yaronf.i...@gmail.com
mailto:yaronf.i...@gmail.com wrote:

Looking at the timing table, there is obviously significant variance
in the time to solve each puzzle, compared to the ideal exponential
curve. For example, for 28 bits we have 250s, whereas for 29 bits
it's 1240s.

Would it make sense to require the initiator to return 4 or 8 solved
puzzles of the given strength? Of course, the responder would
request 2-3 bits of strength less. The net effect should be a lower
variance in run times, i.e. more deterministic run time for any
particular type of client.

Thanks,
Yaron

On 01/29/2015 11:27 PM, Yoav Nir wrote:

Hi all.

Following Valery’s suggestion, I’ve created a pull request for
replacing
the puzzle mechanism:

OLD: appending

Re: [IPsec] Initiator Identity in case of EAP

[Yaron Sheffer]

Valery Smyslov writes:

I don't see how this can be done without breaking existing
implementations, and therefore I am unhappy with the new sentence in
-03, Another example is EAP authentication when the client identity in
ID payload is not used. A responder that receives a new, unknown ID
type should IMHO reject the exchange as syntactically malformed. Even if
some reading of the documents might lead you to think that responders
should be liberal in this case, I see no benefit in breaking the
non-liberal servers by using a novel ID type here.


The text is there because the draft doesn't restrict usage of ID_NULL
to NULL AUthentication only and we were asked to provide
some examples of such usage. I agree that current implementations
won't probably tolerate the described scenario, but I also think that we
should allow ID_NULL to be used in some use cases that might be defined
in the future.

We may remove this sentence that made you unhappy and replace
it with something like:

 If ID_NULL is used with other authentication methods than NULL
 Authentication, then its usage must be defined in appropriate
 document.

BTW, is another example of using ID_NULL in this para is
acceptable to you?


I think removing the sentence saying Another example is EAP
authentication when the client identity in ID payload is not used.
would be good. We already have one example in previous sentence (Raw
public key) which points out why you might want to use ID_NULL with
real authentication, and we do not necessarely need second example.
And for the raw public key case, I do not think we need new document
describing how it is used with ID_NULL...

Of course we need to get the oob-pubkey draft published for that part
of text to be really useful.



I agree with Tero.

Thanks,
Yaron

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

Re: [IPsec] Initiator Identity in case of EAP

[Yaron Sheffer]

Fine with me.

Yaron

On 01/29/2015 04:35 PM, Valery Smyslov wrote:

Valery Smyslov writes:

I don't see how this can be done without breaking existing
implementations, and therefore I am unhappy with the new sentence in
-03, Another example is EAP authentication when the client
identity in
ID payload is not used. A responder that receives a new, unknown ID
type should IMHO reject the exchange as syntactically malformed.
Even if
some reading of the documents might lead you to think that responders
should be liberal in this case, I see no benefit in breaking the
non-liberal servers by using a novel ID type here.


The text is there because the draft doesn't restrict usage of ID_NULL
to NULL AUthentication only and we were asked to provide
some examples of such usage. I agree that current implementations
won't probably tolerate the described scenario, but I also think
that we
should allow ID_NULL to be used in some use cases that might be defined
in the future.

We may remove this sentence that made you unhappy and replace
it with something like:

 If ID_NULL is used with other authentication methods than NULL
 Authentication, then its usage must be defined in appropriate
 document.

BTW, is another example of using ID_NULL in this para is
acceptable to you?


I think removing the sentence saying Another example is EAP
authentication when the client identity in ID payload is not used.
would be good. We already have one example in previous sentence (Raw
public key) which points out why you might want to use ID_NULL with
real authentication, and we do not necessarely need second example.
And for the raw public key case, I do not think we need new document
describing how it is used with ID_NULL...

Of course we need to get the oob-pubkey draft published for that part
of text to be really useful.



I agree with Tero.


In conclusion, is the following text OK?

   ID_NULL is primarily intended to be used with the NULL
   Authentication, but it MAY also be used in other situations, when the
   content of Identification payload does not matter.  For example,
   ID_NULL can be used when authentication is performed via raw public
   keys and the identities are these keys themselves.  If ID_NULL is
   used with other authentication methods than NULL Authentication, then
   the details of its usage must be defined in appropriate document.

Valery.


Thanks,
Yaron




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

Re: [IPsec] WG Last Call on The NULL Authentication Method in IKEv2 Protocol draft-smyslov-ipsecme-ikev2-null-auth

[Yaron Sheffer]

Hi Valery,

The DoS/puzzles document presents a plan for DDoS defense. I believe 
that unauthenticated clients need to be considered as part of this plan. 
I'm OK with the general guidelines in Sec. 3.2, but suggest that the 
DDoS document needs to be beefed up to account for this use case.


Thanks,
Yaron

On 01/26/2015 01:37 PM, Valery Smyslov wrote:

Hi Yaron,

there is already Section 3.2, which discusses possible
impact of NULL Auth on DOS resistance, and
the ddos/puzzles document is already referenced there.
Do you think more words need to be added to this section?

Regards,
Valery.

- Original Message - From: Yaron Sheffer yaronf.i...@gmail.com
To: Paul Wouters p...@nohats.ca; Paul Koning paul_kon...@dell.com
Cc: ipsec@ietf.org; Graham Bartlett (grbartle) grbar...@cisco.com
Sent: Sunday, January 25, 2015 11:09 PM
Subject: Re: [IPsec] WG Last Call on The NULL Authentication Method in
IKEv2 Protocol draft-smyslov-ipsecme-ikev2-null-auth


I would suggest to mention DDOS in this document briefly, but to move
the discussion (maybe add an entire section) to our dedicated
DDOS/puzzles document. For the simple reason that we want to publish the
NULL Auth document sooner.

Since Valery is co-author on both, I guess he gets to write it :-)

Thanks,
Yaron

On 01/23/2015 07:21 PM, Paul Wouters wrote:

On Fri, 23 Jan 2015, Paul Koning wrote:


Sorry for the late reply. Hopefully the following is more clear?

When designing systems which will provide connectivity for
non-authenticated users, the system SHOULD be designed with the
capacity
to support not only the maximum intended number of peers, but also
include
an additional number of sessions which are created due to malicious or
erroneous behaviour. This safety margin will allow a system to still
operate safely under load until it is exceeded.


I understand the sentiment, but this seems like a recommendation that
can’t be tested and can’t really be implemented either.  The trouble
is that the number of malicious sessions is unbounded (and may be
quite large in a DOS scenario).

It might be better simply to point out the limitations of the
machinery: because authentication is not provided in this case, the
receiving system has no way to distinguish legitimate peers from
malicious ones.  As a result, a denial of service attack may prevent
the intended number of legitimate peers from communicating.
Additional session (SA?) capacity may help in such cases.

My point is that this is definitely going to be a case of throwing
some more resources at the problem in the hopes it’s enough, but no
way to predict whether it’s good enough.  Because of that, “SHOULD”
seems inappropriate, and a simple statement of the issue and the
limitations of this new protocol is better.


There are two cases of overload. A legitimate overload by simply having
too many (anonymous) clients, and an overload by malicious clients. It
is hard to tell the difference without authentication.

We could introduce a new notification payload for IKE_INIT that
pre-announces the desire for unauthenticated IKE. A server could then
reject/drop those connections when the load of legitimate clients gets
too high without needing to create more state. If later in the exchange
an attempt for authenticated IKE is made, the connection can be dropped
as malicious. I'm not sure if this will turn out to be a needed feature
to help with the legitimate client overload problem, so I'm tempted to
postpone adding this until we have field reports that it could be
useful.

Currently what we (libreswan) are implementing is counting both halfopen
SAs as well as states associated with unauthenticated IKE SA's. The
halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed
source ip packet could have caused our end to initiate an IKE_INIT.

Paul

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


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


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

Re: [IPsec] Puzzle algorithm negotiation

[Yaron Sheffer]

I thought fixing the PRF would simplify the implementation, but now I 
realize that it wouldn't.


Thanks,
Yaron

On 01/26/2015 06:52 AM, Yoav Nir wrote:



On Jan 25, 2015, at 8:58 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:

Hi Yoav, Valery,

I agree with Valery's proposed redefinition of the proof-work-work, based on 
the PRF.

I am currently off-line so my question may have been answered in the pull 
request, but: can we make it very clear that the PRF used for the POW must be 
the very same as the one selected by the responder for the IKE SA?


It is possible, but I don’t see why it’s a good thing. Suppose the conversation 
goes like this:

Initiator: I want (AES-CBC-128 or AES-CBC-256) with (AUTH_HMAC-SHA1 or 
AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or PRF_HMAC-SHA256) and (Group 2 or Group 
14)

Responder: First do proof-of-work with PRF_HMAC-SHA256

Initiator: Here’s the proof-of-work, now I want (AES-CBC-128 or AES-CBC-256) 
with (AUTH_HMAC-SHA1 or AUTH_HMAC-SHA256) and (PRF_ HMAC-SHA1 or 
PRF_HMAC-SHA256) and (Group 2 or Group 14).

Responder: Fine, I choose AES-CBC-128 with HMAC-SHA1 and PRF_HMAC-SHA1 and 
Group 2.

What is the benefit of forcing the responder to choose the same PRF algorithm 
twice? What is wrong with having it choose PRF_HMAC-SHA1?  Sure, we *can* do 
this, but why?


People may not like it (I don't) but a major reason for including agility today 
is FIPS silliness. One day people will be forced to rip out any mention of 
SHA-256 from their code, and we don't want to need to reopen the RFC.


Some algorithms are also more fashionable than others.

Yoav



Thanks,
Yaron

On 01/19/2015 12:02 AM, Valery Smyslov wrote:

Hi Yoav,

Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2

Hi,

Valery has created this pull request. During the meeting in Honolulu
and subsequent discussion on the list, several people requested that
there be a negotiation of the algorithm used in the puzzle rather
than fixing it to SHA-256.

The pull request suggests figuring out which algorithms the
Initiator supports by examining the SA payload in the IKE_SA_INIT
request, and using the PRF algorithms.

I’m posting this to the list, even thought we’re not sure about
this. Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC
won’t work with the bitcoin-like puzzle that is currently in the draft.

Why?

For convenience assume a 16-byte cookie, a fixed zero IV (as always
in AES-XCBC) and fixed zero key.

So let Y = AESENC(key, IV XOR COOKIE) = AESENC(zero, COOKIE)
Let Z = AESDEC(key, zero) = AESDEC(zero, zero)
Extend the cookie by Y XOR Z.
The result will give you a 128-bit tag of all zeros. Way too easy.

You forgot about the mandatory 10* padding in AES-XCBC.
So, the result of AESDEC(zero, zero) should not be a random
string, but should look like properly padded one.
But anyway, I think that if we use PRF for puzzles, then the puzzle
definition should be changed.
Let R=PRF(K,S). Then the puzzle should be: using supplied cookie as
message S,
find a key K so, that result R contains the requested number of trailing
zero bits.
I'm not a cryptographer, but I think this variant of puzzle should be secure
for all PRFs, defined in IPsec. Why? First, every secure PRF is a secure
MAC
(not visa versa). This is pointed out by several sources. Then, secure MAC
should not allow attacker to recover a key given the message and
the authentication tag. In our case the authentication tag is not fully
given,
but it must have some properties (desired number of trailing zero bits),
so it is not arbitrary.

Another way to do this is to add a notification in the Initiator’s
request listing the hash algorithms that it supports. We could reuse
the RFC 7427 registry of hash algorithms.

I don't think this is a good idea. First, it will require initiator to
include
a list of supported hash algorithms into request message. This will
unnecessary increase its size in all cases: at this point initiator
has no idea whether responder will ever use puzzles or even
whether it supports them. I think this is a waste of resources,
especially taking into consideration that we may reuse
information, that is always present in the request message.

Personally, I really don’t like this algorithm agility, because we
don’t want to give the Initiator the options of a hard vs easy
puzzle. So suppose the Responder supports two algorithms, SHA-256
and SHA-512, and that the latter is half as fast as the former, then
a SHA-512 puzzle would have to have 1 bit less than the SHA-256
puzzle. But in fact, we know that SHA-512 is faster on 64-bit
platforms, while SHA-256 is faster on 32-bit platforms. Add some
GOST-certified hash to the mix, and the administrator’s task becomes
that much harder.

If the difference in algorithms speeds is significant, then some weights
could be
added to algorithm definitions

Re: [IPsec] WG Last Call on The NULL Authentication Method in IKEv2 Protocol draft-smyslov-ipsecme-ikev2-null-auth

[Yaron Sheffer]

I would suggest to mention DDOS in this document briefly, but to move 
the discussion (maybe add an entire section) to our dedicated 
DDOS/puzzles document. For the simple reason that we want to publish the 
NULL Auth document sooner.


Since Valery is co-author on both, I guess he gets to write it :-)

Thanks,
Yaron

On 01/23/2015 07:21 PM, Paul Wouters wrote:

On Fri, 23 Jan 2015, Paul Koning wrote:


Sorry for the late reply. Hopefully the following is more clear?

When designing systems which will provide connectivity for
non-authenticated users, the system SHOULD be designed with the capacity
to support not only the maximum intended number of peers, but also
include
an additional number of sessions which are created due to malicious or
erroneous behaviour. This safety margin will allow a system to still
operate safely under load until it is exceeded.


I understand the sentiment, but this seems like a recommendation that
can’t be tested and can’t really be implemented either.  The trouble
is that the number of malicious sessions is unbounded (and may be
quite large in a DOS scenario).

It might be better simply to point out the limitations of the
machinery: because authentication is not provided in this case, the
receiving system has no way to distinguish legitimate peers from
malicious ones.  As a result, a denial of service attack may prevent
the intended number of legitimate peers from communicating.
Additional session (SA?) capacity may help in such cases.

My point is that this is definitely going to be a case of throwing
some more resources at the problem in the hopes it’s enough, but no
way to predict whether it’s good enough.  Because of that, “SHOULD”
seems inappropriate, and a simple statement of the issue and the
limitations of this new protocol is better.


There are two cases of overload. A legitimate overload by simply having
too many (anonymous) clients, and an overload by malicious clients. It
is hard to tell the difference without authentication.

We could introduce a new notification payload for IKE_INIT that
pre-announces the desire for unauthenticated IKE. A server could then
reject/drop those connections when the load of legitimate clients gets
too high without needing to create more state. If later in the exchange
an attempt for authenticated IKE is made, the connection can be dropped
as malicious. I'm not sure if this will turn out to be a needed feature
to help with the legitimate client overload problem, so I'm tempted to
postpone adding this until we have field reports that it could be
useful.

Currently what we (libreswan) are implementing is counting both halfopen
SAs as well as states associated with unauthenticated IKE SA's. The
halfopen SA's include _our_ outgoing IKE_INIT requests, as a spoofed
source ip packet could have caused our end to initiate an IKE_INIT.

Paul

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


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

Re: [IPsec] Puzzle algorithm negotiation

[Yaron Sheffer]

Hi Yoav, Valery,

I agree with Valery's proposed redefinition of the proof-work-work, 
based on the PRF.


I am currently off-line so my question may have been answered in the 
pull request, but: can we make it very clear that the PRF used for the 
POW must be the very same as the one selected by the responder for the 
IKE SA?


People may not like it (I don't) but a major reason for including 
agility today is FIPS silliness. One day people will be forced to rip 
out any mention of SHA-256 from their code, and we don't want to need to 
reopen the RFC.


Thanks,
Yaron

On 01/19/2015 12:02 AM, Valery Smyslov wrote:

Hi Yoav,

Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2

Hi,

Valery has created this pull request. During the meeting in Honolulu
and subsequent discussion on the list, several people requested that
there be a negotiation of the algorithm used in the puzzle rather
than fixing it to SHA-256.

The pull request suggests figuring out which algorithms the
Initiator supports by examining the SA payload in the IKE_SA_INIT
request, and using the PRF algorithms.

I’m posting this to the list, even thought we’re not sure about
this. Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC
won’t work with the bitcoin-like puzzle that is currently in the draft.

Why?

For convenience assume a 16-byte cookie, a fixed zero IV (as always
in AES-XCBC) and fixed zero key.

So let Y = AESENC(key, IV XOR COOKIE) = AESENC(zero, COOKIE)
Let Z = AESDEC(key, zero) = AESDEC(zero, zero)
Extend the cookie by Y XOR Z.
The result will give you a 128-bit tag of all zeros. Way too easy.

You forgot about the mandatory 10* padding in AES-XCBC.
So, the result of AESDEC(zero, zero) should not be a random
string, but should look like properly padded one.
But anyway, I think that if we use PRF for puzzles, then the puzzle
definition should be changed.
Let R=PRF(K,S). Then the puzzle should be: using supplied cookie as
message S,
find a key K so, that result R contains the requested number of trailing
zero bits.
I'm not a cryptographer, but I think this variant of puzzle should be secure
for all PRFs, defined in IPsec. Why? First, every secure PRF is a secure
MAC
(not visa versa). This is pointed out by several sources. Then, secure MAC
should not allow attacker to recover a key given the message and
the authentication tag. In our case the authentication tag is not fully
given,
but it must have some properties (desired number of trailing zero bits),
so it is not arbitrary.

Another way to do this is to add a notification in the Initiator’s
request listing the hash algorithms that it supports. We could reuse
the RFC 7427 registry of hash algorithms.

I don't think this is a good idea. First, it will require initiator to
include
a list of supported hash algorithms into request message. This will
unnecessary increase its size in all cases: at this point initiator
has no idea whether responder will ever use puzzles or even
whether it supports them. I think this is a waste of resources,
especially taking into consideration that we may reuse
information, that is always present in the request message.

Personally, I really don’t like this algorithm agility, because we
don’t want to give the Initiator the options of a hard vs easy
puzzle. So suppose the Responder supports two algorithms, SHA-256
and SHA-512, and that the latter is half as fast as the former, then
a SHA-512 puzzle would have to have 1 bit less than the SHA-256
puzzle. But in fact, we know that SHA-512 is faster on 64-bit
platforms, while SHA-256 is faster on 32-bit platforms. Add some
GOST-certified hash to the mix, and the administrator’s task becomes
that much harder.

If the difference in algorithms speeds is significant, then some weights
could be
added to algorithm definitions to make the required time to solve puzzle
roughly the same
on the same platform.

OTOH often when a protocol is published without algorithm agility,
we end up extending it later.

Exactly.

Yoav

Regards,
Valery.


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



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

Re: [IPsec] Pause, then continuation of WG Last Call on The NULL Authentication Method in IKEv2 Protocol draft-ietf-ipsecme-ikev2-null-auth

[Yaron Sheffer]

To be more precise: when -03 is out, Paul and I will issue a second last 
call, complete with a new target date.


Thanks,
Yaron

On 01/23/2015 08:36 AM, Paul Hoffman wrote:

Greetings again. The two-week WG Last Call on 
https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-null-auth ends today but 
reviewers have clearly unearthed a reasonable number of issues with the 
document, all of which seem fixable.

WG: please pause for a moment while the authors incorporate the comments so far.

Valery and PaulW: please put out an -03 within a week (sooner, if possible, in 
order to keep up review momentum).

WG: When the -03 is out, please continue the WG Last Call on the new document, 
looking for both whether the changes meet your expectations as well as any new 
issues.

--Paul Hoffman

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



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

Re: [IPsec] WG Last Call on The NULL Authentication Method in IKEv2 Protocol

[Yaron Sheffer]

  IKEv2 peers have a series of policy databases (see Section 4.4 of
   [RFC4301]) that define which security algorithms and methods should
   be used during establishment of security associations.  To help end
   users select the desired security levels for communications protected
   by IPsec, implementers may wish to provide a mechanism in the IKE
   policy databases to limit the mixing of security levels or to
   restrict combinations of protocols.

Would using this text in the security considerations resolve your issue?
We could change mixing of security levels to mixing authenticated and
un-authenticated security levels”.


I think null authentication is a bit more drastic than a new algorithm to do 
what IPSec/IKE has always done: two way authentication of essentially all 
communication.

For example, what would a PAD entry look like that expresses “NULL 
authentication permitted”?  Where would I find the spec for the algorithm that 
rejects unauthenticated communication when it is supposed to be rejected, and 
accepts it when it it is wanted?  I would expect this to be in RFC 4301 section 
4.4.3.1, so it would seem that the new draft has to amend that section to cover 
these new rules.

paul


And then on the SPD side, I'm not sure we even know what this policy 
would look like. Even if we only allow a single IP, the address 
presented by the peer, the policy would not in general be secure. 
Because a true MITM, one that gets hold of the access router, would be 
able to assume any IP, including for example 8.8.8.8. So should we 
exclude certain services? Certain IP ranges? This could get very messy.


Paul W. is right that IKE gateways had always needed to protect against 
malicious peers, but IMHO the unauthenticated case is qualitatively more 
risky.


Thanks,
Yaron

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

Re: [IPsec] WG Last Call on The NULL Authentication Method in IKEv2 Protocol

[Yaron Sheffer]

  
  
Hi Valery, Paul,

I re-read the new draft and I must say it is much clearer than the
previous version. Still, a few comments:

  Please spell-check the draft. There are numerous typos.
  The "privileged IKE operations" is obviously a bit thin.
"Initial Contact" may be a good example of an operation that
we'd be better off without. But if we don't have any specific
examples, let's remove this section.
  Implementations MAY force... to single host-to-host IPsec SAs.
If we cannot come up with a good way for an unauthenticated peer
to prove ownership of SA ranges (whatever "ownership" might mean
in this context), then I guess we should change the MAY into a
SHOULD.
  We are still using IP addresses to identify peers: "if an IKE
peer receives... from an IP address that matches a configured
connection". I think an IKE peer that supports null auth should
be able to distinguish peers depending on other characteristics,
and should be able to handle mixed configurations/policies even
for a single IP address.
  I suggest adding this short subsection to the Security
Considerations:

Although this document discourages the use of non-null ID
  payloads to identify an unauthenticated peer, IKEv2 provides
  channel bindings capabilities and those may be used to
  authenticate this identity at a later time, while binding the
  authenticated identity with the original IKE exchange. This
  applies to a related but distinct use case, where peers cannot be
  authenticated at the time of the exchange but do not wish to
  remain anonymous. Please see [AutoVPN] for one way of
  after-the-fact authentication of an IKE peer.


[AutoVPN] draft-sheffer-autovpn, 2014.

  


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

Re: [IPsec] WG Last Call on The NULL Authentication Method in IKEv2 Protocol draft-ietf-ipsecme-ikev2-null-auth-01

[Yaron Sheffer]

Hi Valery,

Please see my comments below.

- Unclosed sentence in the abstract: It may be used to preserve 
anonymity of


- Reference to IKEv2: please use RFC 7296.

- 2.1: it may be trivial, but we want to add that the AUTH payload MUST 
be verified by the recipient.


- I don't think that we have consensus on The Identification Data in 
Identity payload for the ID_NULL type MUST be absent. The asserted but 
unproven identity may be used for logging, or may be proven with a later 
authentication. Quoting from an email by Tero: I think the most 
important point of this feature is that the client is UNAUTHENTICATED, 
not that it is ANONYMOUS.


- If endpoint receives a request to create an unauthenticated IKE SA 
from the IP address, which is configured on the endpoint to be 
authenticated, the request SHOULD be rejected. - I don't see why. What 
if there are several peers behind an IP address, some authenticated and 
some not? Maybe we need to think some more about the policy that each of 
the peers should enforce.


- The issue of Traffic Selectors needs better treatment. Should we add a 
MUST for allocation of internal IP addresses?


Thanks,
Yaron

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

Re: [IPsec] RFC 7427 on Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)

[Yaron Sheffer]

This is an important addition to IKEv2. Thank you Tero and Joel, and the 
other members of the design team: Dan Harkins, Johannes Merkle, David 
McGrew and Yoav Nir.


Paul and Yaron

On 01/07/2015 03:56 AM, rfc-edi...@rfc-editor.org wrote:

A new Request for Comments is now available in online RFC libraries.


 RFC 7427

 Title:  Signature Authentication in the Internet
 Key Exchange Version 2 (IKEv2)
 Author: T. Kivinen, J. Snyder
 Status: Standards Track
 Stream: IETF
 Date:   January 2015
 Mailbox:kivi...@iki.fi,
 j...@opus1.com
 Pages:  18
 Characters: 39041
 Updates:RFC 7296

 I-D Tag:draft-kivinen-ipsecme-signature-auth-07.txt

 URL:https://www.rfc-editor.org/info/rfc7427

The Internet Key Exchange Version 2 (IKEv2) protocol has limited
support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
The current version only includes support for three Elliptic Curve
groups, and there is a fixed hash algorithm tied to each group.  This
document generalizes IKEv2 signature support to allow any signature
method supported by PKIX and also adds signature hash algorithm
negotiation.  This is a generic mechanism and is not limited to
ECDSA; it can also be used with other signature algorithms.

This document is a product of the IP Security Maintenance and Extensions 
Working Group of the IETF.

This is now a Proposed Standard.

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

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

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

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


The RFC Editor Team
Association Management Solutions, LLC




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

Re: [IPsec] Some speculations about puzzles

[Yaron Sheffer]

And again for IKE_AUTH, I don't see why with fragmentation you need
one puzzle solution per fragment. The major CPU cost (DH computation,
certificate stuff and decryption) comes once, after the message is
re-assembled. So it seems to me only one puzzle response is needed for
the entire message.


In this case the responder would become succeptible to the attack
when attacker emits forged fragments, that takes place of
good fragments from legitimate initiator in the reassembly queue.
To detect the forgery responder needs to check fragment
authenticity before inserting it into the reassembly queue.
That would require performing DH and calculating
SK_a*, but that is what we are willing to defer unless peer
proves that it is really really wants to setup connection and
is ready to spend quite a lot of resources to do it.

It would be possible to protect with puzzle only the very
first fragment, because as we have calculated SK_a*
it takes very little resources to verify the other fragments,
but fragments can arrive in any order, so puzzle must be
in each fragment. That is a bit unfortunate for the initiator, I admit.



I get your point, but I think this is more than unfortunate, this is 
real ugly. RFC 7383 is primarily about IKE_AUTH, and now, in the case of 
those broken networks that limit the MTU, we are reducing the effective 
MTU yet again.


But I think we're looking at the wrong problem. Let us look at why we 
might need to add puzzles to IKE_AUTH at all. There are two cases:

- The IKE SA is set up by a valid initiator.
- The IKE SA is set up by an attacker.

In the first case, the responder needs to compute SKEYSEED anyway. It 
should compute it once and cache it, even if it sees multiple bogus 
IKE_AUTH messages sent by attackers. Verifying IKE_AUTH messages is 
cheap once SKEYSEED has been computed, because you only need to verify 
that the SK integrity protection is valid. The (valid) initiator pays 
the price once, in the form of an IKE_SA_INIT puzzle.


In the second case, the attacker also pays the price if we have a puzzle 
attached to IKE_SA_INIT. And the responder only computes SKEYSEED once, 
and caches the result. Since SKEYSEED is known to the attacker, it can 
send valid SK payloads, and the responder is forced to validate the 
certificate (expensive). So attaching a puzzle to IKE_AUTH is justified, 
to make the attacker pay for each certificate validation.


But this also shows that the IKE_SA_INIT puzzle is sufficient to 
counteract the cost of computing SKEYSEED (which is all you need for 
reassembly), and when even using fragmentation, this is only done once.


Thanks,
Yaron

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

Re: [IPsec] Some speculations about puzzles

[Yaron Sheffer]

Hi Valery,

Going back to your original message (I guess not everyone read it to the 
end :-)


I don't understand how puzzles for IKE_AUTH can be mandatory without 
breaking the protocol. The responder doesn't even know that the 
initiator supports puzzles. At the very least, we would need to add a 
puzzles supported notification.


And again for IKE_AUTH, I don't see why with fragmentation you need one 
puzzle solution per fragment. The major CPU cost (DH computation, 
certificate stuff and decryption) comes once, after the message is 
re-assembled. So it seems to me only one puzzle response is needed for 
the entire message.


Thanks,
Yaron

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

Re: [IPsec] DDoS Protection issue #226 - Do we need puzzles at all?

[Yaron Sheffer]

I don't buy Yoav's argument but I also think puzzles should stay.

The reason is, puzzles work well in the case where a botnet is attacking 
multiple gateways concurrently. Each gateway can rate-limit the traffic 
directed to it, but unless we associate a significant cost with each 
message, the botnet is as effective against each of the gateways as it 
would be if it was only attacking a single gateway. With puzzles, the 
good guys are helping one another without needing to communicate 
between them.


Thanks,
Yaron

On 11/26/2014 06:46 PM, Michael Richardson wrote:


Yoav Nir ynir.i...@gmail.com wrote:
  I don’t like hard limits. Hard limits allow a very easy form of DoS. If
  everyone in this hotel is behind a single NAT device, then it’s fairly
  easy for me to create multiple half-open SAs from my room until I hit
  the hard limit. After that, everyone will be effectively blocked from

Except now apply CGN in a IPv4-address poor country, and it's not just the
people in the hotel, it's potentially everyone in that area.  Given 300-odd
well distributed, compromised hosts, one could keep the half-SA table full
for much of the  developing world...

So I buy your argument.



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



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

Re: [IPsec] IPsec with QKD status

[Yaron Sheffer]

Hi Rod,

Two quick comments:

- I am fine with the Experimental/ISE route.

- I support the SKEYSEED idea. It makes sense as a single point of 
integration into the protocol, so that if we ever specify a different 
way of generating key material, it would not need to be re-specified for 
QKD. Of course generation of key material depends on PRF algorithms that 
might get weaker over time, but since we're going to use the key 
material for symmetric algorithms anyway, I think this is appropriate - 
the strength of PRF can be correlated to key length of symmetric 
encryption/MAC algorithms.


Thanks,
Yaron

On 11/14/2014 02:13 AM, Rodney Van Meter wrote:

ipsecme-ers,

We have managed to catch a number of people in the halls to discuss
our IPsec with QKD I-D.  Haven't managed to catch Yaron yet.

This mail is long.  First, an admin summary of where we are, then a
technical  writing action item list, and at the bottom a short FYI on
the state of QKD, for the curious.

Here's where I think we are:

* We need this published, so that there is a formal stake in the
   ground as the growing number of commercial QKD implementations get
   around to adding a properly engineered IPsec to their supported
   functionality; existing QKD implementations interface with
   IP-relevant equipment in an ad hoc manner.  (As one person said, It
   may be snake oil, but you're entitled to have interoperable snake
   oil.)
* There is no need for Standards Track at the moment; our goal is
   Experimental RFC as a target for other implementations to aspire to.
   Therefore, we don't think it's necessary to formally adopt this as a
   WG item.  Taking this through the Independent Stream Editor seems to
   be the right approach.  We have consulted with Kathleen Moriarty,
   Sean Turner, Paul Hoffman, Nevill Brownlee and a couple of others
   about this, and they are on board with it.
* Even if it's not a WG item, with your permission keeping the
   discussion public here on the ipsec mailing list seems to be helpful
   and appropriate.
* Several people (Paul Koning, Greg Troxel, Tony Putman, Tero Kivinen)
   have offered comments on the -01 version.  (Sheila Frankel, Alan
   Mink, Sean Turner offered comments on the -00 version that led to
   -01.)  We will address those in turn; a summary is below.  Some of
   these asked for clarification in the writing, some straightforward
   changes in packet formats (potentially affecting IANA
   considerations), a few for significant changes to the semantics.
* This will result in a -02 version sometime in the next few weeks as
   we sort through and address the comments.  Our existing open-source
   implementation corresponds to the -00 draft, but some of these
   changes are significant enough that we don't want to accept or
   reject until we have had a chance to at least assess their
   implementability.
* Following the -02, if people on this list are happy, there will
   certainly be a -03 with wordsmithing.  Somewhere around -03, we will
   probably send to the ISE.  My understanding is that he will tap
   someone to conduct an additional review, and the better we have
   listened to the folks here the smoother that is likely to go.
* Somewhere toward the end of this process, will have to get IANA to
   assign appropriate IDs.

Comments on the above welcome, if we have missed steps or
misinterpreted anything.

Current action item list, coalescing a couple of prior emails.  Had a
long F2F session w/ Tero yesterday, some highlights listed here,
awaiting full written comments.  This list isn't fully orthogonal or
prioritized, but obviously some of the suggestions are mutually
inconsistent.  Conflicts will have to be resolved.

Technical questions:

* Zeroth suggestion is to broaden to any out of band (OOB) key
   generation approach (diplomatic pouch being our canonical example).
   I'm inclined to keep it as focused as possible, but it may well be
   that by the time we have made the changes proposed, that we are 90%
   of the way there.
* Biggest suggestion is to use the QKD material as SKEYSEED, rather
   than directly as the bulk encryption keys.  We are going to have to
   think about this, I'm not sure how it will affect what we are trying
   to accomplish.  As long as we avoid the D-H we have accomplished the
   primary goal, but does using the prf dilute any of the guarantees we
   get from the QKD itself?  e.g., are there vulnerabilities in the prf
   or known limitations in its lifetime (as with the factoring/discrete
   logarithm problem of D-H)?  I'm not sure.  Would it actually add
   anything to take this approach?  I'm not sure.  My first inclination
   is to _not_ adopt this suggestion.
* Second biggest suggestion (made by more than one person) is to stick
   with existing Key Exchange Payload, and just assign a value for the
   D-H Group Num field to indicate QKD.
* Third, fallback is a policy decision, not needed on the wire,
   perhaps.  Just having the right 

Re: [IPsec] Charter review

[Yaron Sheffer]

hats off

Regarding formal security proofs, I strongly disagree.

The current wording is extremely mild. It does not require an actual 
security proof (which would not be realistic), but says The solution 
should be in line with current best practices, including ... possible

formal protocol security proofs.

This to me means that people have looked at the modified protocol and 
can say that the new stuff does not inhibit such a security proof in the 
future, and that we formally understand the security properties that are 
supposed to be provided by the protocol.


We are making a major change to IKE, and as much as I care about its 
goals, we should try to do it right. Relying on the security afforded 
by DH is not easy when in the real world, both peers might be reusing 
exponents and/or using too short DH groups.


Thanks,
Yaron

On 11/07/2014 01:36 AM, Dan Harkins wrote:


On Tue, November 4, 2014 7:21 pm, Brian Weis wrote:

On Oct 31, 2014, at 4:05 PM, Kathleen Moriarty
kathleen.moriarty.i...@gmail.com wrote:


Hi,

The chairs provided text for an updated charter in line with the newly
adopted working group items.  The recharter text has been posted and
I'd like to give the WG a little time to comment prior to adding this
to a telechat for review.


I support the work item looking at defending against DDoS, and have no
objection to the opportunistic work item (after omitting the wording on
channel binding).


   +1

   How about we also get rid of the mention of a formal security proof
of opportunistic encryption? The security is just that afforded by D-H.

   Dan.


Brian



Here is a link:

http://datatracker.ietf.org/doc/charter-ietf-ipsecme/

Thanks.

--

Best regards,
Kathleen

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


--
Brian Weis
Security, Enterprise Networking Group, Cisco Systems
Telephone: +1 408 526 4796
Email: b...@cisco.com

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



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



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

Re: [IPsec] RFC5723: Calculating auth value in IKE_AUTH during Session resumption

[Yaron Sheffer]

Hi Justin,

The IKE key material including SK_px is generated, and then AUTH is 
computed using SK_pi/SK_pr. This is independent on how the IKE SA was 
initiated when it was first set up. So in your example, the RSA private 
key is *not* used during resumption.


This is in fact a benefit of session resumption, because private key 
operations are typically more expensive that computing a PRF.


Thanks,
Yaron

On 10/29/2014 04:38 PM, Justin Lai wrote:

Hi,

I am having some problem understanding how AUTH value is calculated
during IKE_AUTH when a session is resumed using RFC 5723. Is the
AUTH value calculation always going to be AUTH = prf(SK_px, message octets)
regardless of the auth type used?

For example if the auth method used during login was RSA Digital Signature for
both client and gateway auth, then on session resumption, should the auth value
be computed using RSA private key as well or should the AUTH value be
computed using prf(SK_px, message octets)?

Thanks



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



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

[IPsec] Fwd: STD 79, RFC 7296 on Internet Key Exchange Protocol Version 2 (IKEv2)

[Yaron Sheffer]

This is the first Internet Standard to do with an IPsec protocol. Thanks 
Sean Turner for initiating this work, and Tero Kivinen for making it happen!


Paul and Yaron


 Forwarded Message 
Subject: STD 79, RFC 7296 on Internet Key Exchange Protocol Version 2 
(IKEv2)

Date: Fri, 24 Oct 2014 16:17:32 -0700 (PDT)
From: rfc-edi...@rfc-editor.org
Reply-To: i...@ietf.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
CC: ipsec@ietf.org, drafts-update-...@iana.org, rfc-edi...@rfc-editor.org

A new Request for Comments is now available in online RFC libraries.

STD 79
RFC 7296

Title:  Internet Key Exchange Protocol Version 2 (IKEv2)
Author: C. Kaufman, P. Hoffman,
Y. Nir, P. Eronen,
T. Kivinen
Status: Standards Track
Stream: IETF
Date:   October 2014
Mailbox:charliekauf...@outlook.com,
paul.hoff...@vpnc.org,
nir.i...@gmail.com,
p...@iki.fi,
kivi...@iki.fi
Pages:  142
Characters: 354358
Obsoletes:  RFC 5996
See Also:   STD 79

I-D Tag:draft-kivinen-ipsecme-ikev2-rfc5996bis-04.txt

URL:https://www.rfc-editor.org/rfc/rfc7296.txt

This document describes version 2 of the Internet Key Exchange (IKE)
protocol.  IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining Security Associations
(SAs).  This document obsoletes RFC 5996, and includes all of the
errata for it.  It advances IKEv2 to be an Internet Standard.

This document is a product of the IP Security Maintenance and Extensions 
Working Group of the IETF.


This is now an Internet Standard.

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

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

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

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


The RFC Editor Team
Association Management Solutions, LLC




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

Re: [IPsec] A strategy against DoS/DDoS for IKE responders

[Yaron Sheffer]

It seems to me the difference between the two options is not very 
important (assuming reasonable rate limits), because the cost of 
receiving an IKE_AUTH message and detecting an incorrect MAC is not very 
high, after the initial generation of the IKE SA key material.


But Yoav's model also demonstrates that we could get the same effect by 
attaching the puzzle to IKE_AUTH - though I don't see an advantage.


Re: RFC 6989, yes, the test refers to IKE_SA_INIT. But the response 
message does not depend on the received DH public key, so IMHO it's fine 
to postpone the test until IKE_AUTH is received, and before generating 
the IKE shared key.


Thanks,
Yaron


On 10/06/2014 11:31 AM, Graham Bartlett (grbartle) wrote:

Hi

This is a very interesting attack, I would dismiss (1) as it leaves an
implementation open for a semi-easy DOS (just one packet that generates
work rate on both initiator and responder).

Basing the behaviour on (2) the attacker would only have the window from
when the responder sends the SA_INIT, to receiving the (valid) IKE_AUTH.
As Nico said shortening the time is critical, but also once the responder
receives a valid IKE_AUTH it should (IMO) dismiss any more IKE_AUTH
messages it receives.


I guess you could look at rate limiting IKE_AUTH messages if they fail to
decrypt, but then you could drop the legit IKE_AUTH. Unless the attacker
is very very lucky (in their packet generation), or has the authentication
credentials they will not be able to send a valid IKE_AUTH, so the window
that occurs between the responder receiving the valid IKE_AUTH is key.

I see the potential for an attacker dropping, or delaying the legit
IKE_AUTH and then sending many IKE_AUTH as you said, so if the behaviour
was set to 10s if a device detected it was under this attack it should
reduce the window of time to process IKE_AUTH (as Nico said), but once
again this could then drop the legit IKE_AUTH.

As I understand the RFC6989 checks are performed on the public value
received in SA_INIT, no IKE_AUTH. (FROM RFC6989) A receiving peer MUST
check that its peer's public value is valid;, so these checks (as I
understand) would be performed before the responder sends the SA_INIT.

So to summarise, I think that (1) is worse, (2) should be implemented
(maybe with a different timer), but with guidance on what to do should a
device become under attack.

cheers



On 05/10/2014 21:22, Yoav Nir ynir.i...@gmail.com wrote:


Hi, Yaron

On Oct 5, 2014, at 10:56 PM, Yaron Sheffer yaronf.i...@gmail.com wrote:



- I'm not sure what is special about [the case] when an Authentication
request fails to decrypt. Seems to me this is a verified DoS attack

from a specific IP.

I see I wasn¹t clear about this, because both you and Graham missed what
I meant.

Suppose we have a responder where half-open SAs time out after 10
seconds.
This responder receives an Initial Request, and responds with an Initial
Response.
It stores its own private value and the peer¹s public value in the
half-open SA database, keyed by IKE SPIs.
0.5 seconds later, it receives an IKE_AUTH request with the right IKE
SPIs.
It derives the keys (making any ECDH check that¹s needed)
It tries to decrypt the message
The message fails to decrypt (or more likely, the MAC comparison fails)
Now the responder has two options:
(1) delete the entry in the half-open SA database, or
(2) store the derived key, and keep the half-open SA another 9.5 seconds.

(2) has the disadvantage that the attacker can keep sending more junk
packets and get the responder to attempt to decrypt all of them.
(1) has the disadvantage that an attacker can inject a junk IKE_AUTH
request by just copying the IKE SPIs from the IKE_INIT response, which
will prevent the responder from processing the real initiator¹s IKE_AUTH
request.

So I¹m not sure which is worse.

Yoav

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


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

Re: [IPsec] A strategy against DoS/DDoS for IKE responders

[Yaron Sheffer]

Hi Yoav,

Thanks for this excellent analysis. A few comments:

- When using ECDH, part of the cost of step #2 is validating the 
incoming DH public key, per RFC 6989. This assumes you are reusing DH 
parameters, which makes sense in a DoS situation. It may be legit (but 
strange) to defer this validation to follow the integrity check of the 
encrypted payload.


- I'm not sure what is special about [the case] when an Authentication 
request fails to decrypt. Seems to me this is a verified DoS attack 
from a specific IP.


- Your model talks about a single gateway, or a tight cluster of 
gateways. An advantage of puzzles that goes beyond this model is that 
even if your gateways do not share information about suspicious IPs, a 
puzzle generated by each gateway reduces the attacker's power to attack 
any other gateway. This is much more powerful than rate limiting by any 
particular gateway.


Thanks,
Yaron

On 10/05/2014 01:25 PM, Yoav Nir wrote:

Hi

Here are some thoughts about DoS and DDoS protection for an IKE daemon. I think 
this should be discussed before submitting any drafts, because the acceptance 
thread reflected that the problem we want to solve is DoS and DDoS, not just 
the lack of a puzzle mechanism.

If we break down what a responder has to do during an initial exchange, there 
are four stages:

1. When the Initial request arrives, the responder:
  - generates or re-uses a D-H private part.
  - generates a responder SPI
  - stores the private part and peer public part in a half-open SA database.

2. When the Authentication request arrives, the responder:
  - derives the keys from the half-open SA ([1]).
  - decrypts the request.

3. If the Authentication request decrypts properly:
  - validates the certificate chain (if present) in the auth request

Yes, there's a stage 4 where the responder actually derives keys, but when 
talking about (D)DoS, we never get to this stage.

Stage #1 is pretty light on CPU power, but requires some storage, and it's very 
light for the initiator as well. Stage #2 includes private-key operations, so 
it's much heavier CPU-wise. Stage #3 includes a public key operation, and 
possibly many of them.

To attack such a server, an attacker can attempt to either exhaust memory or to 
exhaust CPU. Without any protection, the best avenue is to send multiple faked 
Initial requests, and exhaust memory. This should be easy because those Initial 
requests are cheap.

There are obvious ways for the responder to protect itself even without changes 
to the protocol. It can reduce the time that an entry remains in the half-open 
SA database, and it can limit the amount of concurrent half-open SAs from a 
particular address or prefix. The attacker can overcome this by using spoofed 
source addresses.

The stateless cookie mechanism (that is already in the RFC) prevents an attack 
with spoofed source addresses. This doesn't solve the issue, but it makes the 
address or prefix limiting work. Puzzles do the same thing only more of it. 
They make it harder for an attacker to reach the goal of getting a half-open 
SA. They don't have to be so hard that an attacker can't afford to solve them - 
it's enough that they increase the cost of a half-open SAs for the attacker.

Reducing the amount of time an abandoned half-open SA is kept attacks the issue 
from the other side. It reduces the value the attacker gets from managing to 
create a half-open SA. So if a half-open SA takes 1 KB and it's kept for 1 
minute and the capacity is 60,000 half-open SAs, an attacker would need to 
create 1,000 half-open SAs per second. Reduce the retention time to 3 seconds, 
and the attacker needs to create 20,000 half-open SAs per second. Make each of 
those more expensive, and you're likely to thwart an exhaustion attack against 
responder memory.

At this point, I'm guessing that this is no longer the most efficient DoS 
attack. The attacker has two ways to do better:
  1. Go back to spoofed addresses and try to overwhelm the CPU that deals with 
generating cookies, or
  2. Take the attack to the next level by also sending an Authentication 
request.

I don't think the first thing is something we can deal with at the IKE leve. 
It's probably better left to IPS technology.

Sending an Authentication request is surprisingly cheap. It requires a proper 
IKE header with the correct IKE SPIs, and it requires a single encrypted 
payload. The content of the payload might as well be junk. The responder has to 
perform the relatively expensive key derivation, only to find that the 
Authentication request does not decrypt. Depending on the responder 
implementation, this can be repeated with the same half-open SA (if the 
responder does not delete the half-open SA following an unsuccessful 
decryption). For extra credit, the attacker can send the Authentication request 
just before the entry expires.

Here too, the number of half-open SAs that the attacker can achieve is crucial, 
because each one of 

Re: [IPsec] Call for adoption: Client Puzzles

[Yaron Sheffer]

I agree that if session resumption is implemented, it is a good way to 
reduce the problem drastically. Resuming clients go to the fast track, 
and any new connections get the anti-DOS treatment - cookie- or 
puzzle-based.


To answer Yoav's two objections:

1. This is a standard trade-off. We can only hope people will eventually 
find a way to notify the IKE gateway when a password is changed, which 
would enable longer ticket lifetimes.


2. Quoting RFC 5723:

   This document therefore requires that the ticket be presented to the
   IKEv2 responder only once; under normal circumstances (e.g., no
   active attacker), there should be no multiple use of the same ticket.

   We are not aware of additional security issues associated with ticket
   reuse: the protocol guarantees freshness of the generated crypto
   material even in such cases.  As noted in Section 4.3.1, the gateway
   SHOULD prevent multiple uses of the same ticket.  But this is only an
   extra precaution, to ensure that clients do not implement reuse.  In
   other words, the gateway is not expected to cache old tickets for
   extended periods of time.

Thanks,
Yaron


On 09/25/2014 08:02 PM, Yoav Nir wrote:


On Sep 25, 2014, at 2:27 PM, Tero Kivinen kivi...@iki.fi wrote:


Michael Richardson writes:

Yoav Nir ynir.i...@gmail.com wrote:

One proposal that I kind of liked (and I’m sorry I’ve forgotten who
suggested it) was to relegate the puzzle to a second line of defense,
through the use of some kind of anti-dos ticket. The ticket would be a
bearer token (perhaps an encrypted timestamp) that would allow the
bearer to get by with a much easier version of the puzzle. The


Would this ticket be provided in a Notify, after AUTHentication, in a
previous PARENT-SA?


Wouldn't it be better to use IKEv2 session resumption (RFC 5723) for
those clients coming back.

I.e if you resume old existing session then you do not need to do
puzzle... And after the resume, the ticket is usually changed again,
so the ticket would always be fresh.


That’s possible. But session tickets are different from these tickets in two 
ways:

  1. Session tickets are time-limited with a rather short validity period. If 
policy requires checking the certificate / password every two hours, then the 
ticket cannot be valid for more than that.
  2. Session tickets must not be replayed, so the gateway has to use some very 
strict anti-replay mechanisms.

The proposed tickets can be valid for a long time, and while replay prevention 
is desired, it doesn’t need to be very strict.

This laxness has operational benefits. It’s easier to implement in a cluster of 
gateways, and a ticket will be valid even for a user that hasn’t connected in a 
while. This makes sense because the prize from a replayed RFC 5723 ticket is 
great - a valid, authenticated session. OTOH managing to replay this new kind 
of ticket only gets you a half-open SA without bothering to solve a puzzle.

Yoav


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



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

Re: [IPsec] Mandatory Public Key based authentication with EAP

[Yaron Sheffer]

So for the record, I do think we should add to RFC 5996, at the end of 
the paragraph that starts with An implementation using EAP MUST also 
use a public-key-based something like:


As an exception to this rule, public key authentication of the server is 
not required when using the extension defined in [RFC5998].


Thanks,
Yaron


On 09/22/2014 02:59 PM, Tero Kivinen wrote:


As there has not been any support in the list to add anything like
this to the draft-kivinen-ikev2-rfc5996bis, I assume we do not then
need to change it.



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

Re: [IPsec] Call for adoption: Client Puzzles

[Yaron Sheffer]

So, I'm in favour of adoption of the document, but not in favour of the
currently proposed CPU-bound puzzle solution.

Paul


With WG chair hat on: We should adopt this document if the problem it 
raises needs to be solved (I would say the problem is, DDoS protection 
in the presence of botnets) AND if the document actually solves the 
problem or can be modified without radical changes to do so.


If radical changes are needed, let's by all means discuss them first on 
the list, and then adopt the document.


Thanks,
Yaron

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

[IPsec] Adoption: MOBIKEv2: MOBIKE extension for Transport mode

[Yaron Sheffer]

  
  
Dear working group,

Based on the feedback we received this week, we do not have enough
support to adopt this document, in its current form, as a working
group document. If the document's scope changes significantly in the
future, we may want to reconsider this decision.

Thanks,
    Paul and Yaron
  


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

[IPsec] Call for adoption: Client Puzzles

[Yaron Sheffer]

  
  

  Dear working group,


  This is a call for adopting draft-nir-ipsecme-puzzles-00 as a
  WG document. Please respond to this mail with a Yes or No
and a short rationale, at latest by Friday Sep. 26.

  
  Thanks,
	Yaron



  


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

[IPsec] Adoption: The NULL Authentication Method in IKEv2 Protocol

[Yaron Sheffer]

  
  
Based on the WG discussion this week, there is clear support for
adopting this draft as a WG document. We request the author to
re-publish the current text as a WG document.

Several issues were raised during the call for adoption, and we will
surely discuss them on the list once the draft is published.

Thanks,
    
    Paul and Yaron
  


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

Re: [IPsec] Mandatory Public Key based authentication with EAP

[Yaron Sheffer]

Hi Rahul,

I am not aware of any additional conditions.

EAP-AKA is actually listed in the table in RFC 5998, Sec. 4.

Thanks,
Yaron

On 09/11/2014 08:44 AM, Rahul Vaidya wrote:

Thanks for the quick reply, Yaron,

So does it mean that if an EAP method provides mutual authentication
(e.g., EAP-AKA), then this particular text from 5996 does not apply? Or
are their further conditions which are not mentioned in 5998 where still
the public key based authentication is required?

Regards,
Rahul

On Thu, Sep 11, 2014 at 11:05 AM, Yaron Sheffer yaronf.i...@gmail.com
mailto:yaronf.i...@gmail.com wrote:

Hi Rahul,

This is why RFC 5998 is listed as updates 5996. So RFC 5998 does
apply here. Note that it only applies in specific cases, and for
specific EAP methods.

Yes, we should have updated the text in RFC 5996 to refer to 5998,
but we forgot. Sigh.

Thanks,
 Yaron


On 09/11/2014 06:56 AM, Rahul Vaidya wrote:

Dear IPsec Experts,

In RFC 4306, 5996 as well as
draft-kivinen-ipsecme-ikev2-__rfc5996bis,
there is a statement:

An implementation using EAP MUST also use a public-key-based
authentication of the server to the client before the EAP exchange
begins, even if the EAP method offers mutual authentication.

RFC 5998 which updates 5996 says:
This document specifies how EAP methods that provide mutual
authentication and key agreement can be used to provide extensible
responder authentication for IKEv2 based on methods other than
public
key signatures.

The 2 statements are contradictory, given the 'MUST' requirement for
public -key based authentication in RFC 5996.

I request a view from the IPsec community on whether public key
based
authentication can be avoided without impacting the security of the
connection/network.

Regards,
Rahul Vaidya


_
IPsec mailing list
IPsec@ietf.org mailto:IPsec@ietf.org
https://www.ietf.org/mailman/__listinfo/ipsec
https://www.ietf.org/mailman/listinfo/ipsec




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

[IPsec] Calls for adoption

[Yaron Sheffer]

  
  
Hi ipsecme folks,

At the Toronto meeting we reviewed 3 documents. We would like to
know if the group is interested in adopting one or more of them as
WG documents. We plan to issue separate calls for adoption for each
one, with a duration of one work-week (5 days) each, starting today.

Thanks,
    Yaron
  


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

[IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol

[Yaron Sheffer]

Dear working group,

This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a 
WG document. Please respond to this mail with a Yes or No and a short 
rationale, at latest by Friday Sep. 12.


Thanks,
Yaron

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

Re: [IPsec] Garage door - let's pick a different example

[Yaron Sheffer]

Hi Valery,

I agree the garage system can be made secure, if engineered correctly. 
But garage engineering is out of scope for this draft :-)


IMO the sensor example is much simpler and therefore much better. I 
would suggest that you replace the garage in the draft by a thermometer.


Thanks,
Yaron

On 08/20/2014 02:36 PM, Valery Smyslov wrote:

Hi Yaron,
sorry for late reply - I was on vacation.
I still think that the example is valid. The example describes
the remote opener which
opens the only door. If you want to open different doors using single
opener then you might
run into trouble you described. But  this attack can be thwarted by using
more specific commands: not just open and close, but open garage door,
close kitchen door etc. In this case each door must know its name
and must act only if received command concerns it. Note, that mutual
authentication
is still not needed here.
Another example, where initiator must be authenticated while responder
is not needed to be authenticated is some sensor (e.g. temperature), that
sleeps most of the time, but periodically wakes up, measures something
(like temperature) and sends the result to some server. Clearly, the
sensor must
be authenticated, but the server it connects to may be left unauthenticated
(I presume that the measurement itself is not secret, so no harm
if attacker gets it, authentication is only needed for the server to
be sure it receives authorative data).
Regards,
Valery.
- Original Message -

*From:* Yaron Sheffer mailto:yaronf.i...@gmail.com
*To:* ipsec mailto:ipsec@ietf.org
*Sent:* Friday, July 25, 2014 8:37 PM
*Subject:* [IPsec] Garage door - let's pick a different example

This might sound like a nit, but we have this text in the draft, as
a use case for null auth:

User wants to get some simple action from the remote device.
Consider garage door opener: it must authenticate user to open the
door, but it is not necessary for the user to authenticate the door
opener.  In this case one-way authentication is sufficient.

The problem is, this is an incorrect protocol. Specifically, a MITM
(who might be physically located by the kitchen door), could
redirect the protocol exchange to a door different from the one I
intended to open. Seeing that nothing happens, I will simply press
the remote again and open the garage door, too.

This is of course a generic problem, where unauthenticated protocols
have unforeseen consequences.

Thanks,
 Yaron



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



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

Re: [IPsec] Puzzles draft - another idea

[Yaron Sheffer]

Hi Yoav,

this is a nice idea, but I think it actually performs worse than the 
baseline.


With the previous solution all clients had to expend the same number of 
cycles, but would be served FCFS so from time to time, the good ones 
would be served. With this proposal the attacker can push out the 
legitimate weak clients in a *deterministic* way. If I know all Check 
Point iPhone clients do 10 bits (I assume most implementations will 
choose a value and stick to it, because they do not have any information 
about the effort currently needed), I will configure my botnet to always 
do 11, and push out any legitimate clients.


Thanks,
Yaron

On 07/30/2014 07:45 AM, Yoav Nir wrote:

Hi all

After the meeting on Friday, I talked to Tero and Brian Weis, and Tero
suggested a different sort of puzzle that could make it easier to
support both strong and weak clients. This is sort of like the
proof-of-work used by BitCoin.

 1. Calculate the cookie as before. For an example, let’s assume the
cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets).
 2. A “legacy” initiator will return this exact cookie.
 3. A newer initiator will return the cookie, with some extra bytes.
 4. The “value” of a returned cookie is determined by the number of
trailing zero bits in the SHA-256 hash of the transmitted cookie:

Cookie || extra data

hash

# trailing zero bits
fdbcfa5a430d7201282358a2a034de0013cfe2ae

ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede

1
fdbcfa5a430d7201282358a2a034de0013cfe2ae0182

71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2a256bdfa800

11
fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d

3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e

17
fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679

c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f0

20
fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880

155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d80

23
fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8

6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e294800

27


 5. Initiators are limited (by the construction of the cookie) in the
amount of time they can spend. So powerful clients will manage 23
bits, while weaker clients will only manage 17.
 6. When an Initial request arrives with a cookie, first the first 20
bytes are validated, and then the result is queued by “value”.
 7. When the responder can handle a packet (has room in the half-open SA
table) it processes the entry with the highest value in the queue.
Entries expire after some time even if not handled.


I think if this algorithm is chosen, an attacker can still expend little
effort, get some 5-6 bits, and use that to push out all legacy clients.
We could counter that by having a minimum threshold at something like
10-12 bits, some value that all supported platforms can easily manage in
under 0.5 seconds, and consider all values below that to be equal to
zero (not enough effort to matter).

This could get some more tweaks. But what do people think of this?

Thanks

Yoav

P.S. This is the first time I tried to send a table pasted into Apple
Mail to a mailing list. I apologize in advance if it comes out looking
horrific.



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



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

Re: [IPsec] Puzzles draft - another idea

[Yaron Sheffer]

Makes sense to me.

Yaron

On 07/30/2014 11:45 AM, Yoav Nir wrote:

Hi, Yaron

Suppose our half-open SA table can hold 100,000 entries and we clear
them out after 10 seconds. That allows 10,000 entries per second. More
realistic number are 18 bits for the iPhone and 20 bits for the
attacker, so to block out those iPhones, the attacker would have to
perform 10,000 * 2^20 SHA-256 hashes per second, or about 10 billion
hashes. That’s about 400 server-class hardware working full-time, or a
10,000-way botnet. The draft is all about increasing the work for the
attacker, and I believe this is doing it well. The baseline is sending
20,000 packets per second while only copying the cookie (no PK or hash
operations at all).

It is possible to do as in the current draft, and set a single
difficulty level (say, 18 bits). This allows the attacker a nice and
deterministic way to keep the half-open SA table full, which blocks out
all clients, not just the iPhones.

Yoav

On Jul 30, 2014, at 6:40 PM, Yaron Sheffer yaronf.i...@gmail.com
mailto:yaronf.i...@gmail.com wrote:


Hi Yoav,

this is a nice idea, but I think it actually performs worse than the
baseline.

With the previous solution all clients had to expend the same number
of cycles, but would be served FCFS so from time to time, the good
ones would be served. With this proposal the attacker can push out the
legitimate weak clients in a *deterministic* way. If I know all Check
Point iPhone clients do 10 bits (I assume most implementations will
choose a value and stick to it, because they do not have any
information about the effort currently needed), I will configure my
botnet to always do 11, and push out any legitimate clients.

Thanks,
Yaron

On 07/30/2014 07:45 AM, Yoav Nir wrote:

Hi all

After the meeting on Friday, I talked to Tero and Brian Weis, and Tero
suggested a different sort of puzzle that could make it easier to
support both strong and weak clients. This is sort of like the
proof-of-work used by BitCoin.

1. Calculate the cookie as before. For an example, let’s assume the
   cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets).
2. A “legacy” initiator will return this exact cookie.
3. A newer initiator will return the cookie, with some extra bytes.
4. The “value” of a returned cookie is determined by the number of
   trailing zero bits in the SHA-256 hash of the transmitted cookie:

   Cookie || extra data

   hash

   # trailing zero bits
   fdbcfa5a430d7201282358a2a034de0013cfe2ae

   ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede

   1
   fdbcfa5a430d7201282358a2a034de0013cfe2ae0182

   71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2a256bdfa800

   11
   fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d

   3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e

   17
   fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679

   c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f0

   20
   fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880

   155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d80

   23
   fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8

   6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e294800

   27


5. Initiators are limited (by the construction of the cookie) in the
   amount of time they can spend. So powerful clients will manage 23
   bits, while weaker clients will only manage 17.
6. When an Initial request arrives with a cookie, first the first 20
   bytes are validated, and then the result is queued by “value”.
7. When the responder can handle a packet (has room in the half-open SA
   table) it processes the entry with the highest value in the queue.
   Entries expire after some time even if not handled.


I think if this algorithm is chosen, an attacker can still expend little
effort, get some 5-6 bits, and use that to push out all legacy clients.
We could counter that by having a minimum threshold at something like
10-12 bits, some value that all supported platforms can easily manage in
under 0.5 seconds, and consider all values below that to be equal to
zero (not enough effort to matter).

This could get some more tweaks. But what do people think of this?

Thanks

Yoav

P.S. This is the first time I tried to send a table pasted into Apple
Mail to a mailing list. I apologize in advance if it comes out looking
horrific.



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




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

Re: [IPsec] Garage door - let's pick a different example

[Yaron Sheffer]

On 07/26/2014 02:07 AM, Tero Kivinen wrote:

Yaron Sheffer writes:

This might sound like a nit, but we have this text in the draft, as
a use case for null auth:

User wants to get some simple action from the remote device. Consider garage
door opener: it must authenticate user to open the door, but it is not
necessary for the user to authenticate the door opener.  In this case one-way
authentication is sufficient.

The problem is, this is an incorrect protocol. Specifically, a MITM (who might
be physically located by the kitchen door), could redirect the protocol
exchange to a door different from the one I intended to open. Seeing that
nothing happens, I will simply press the remote again and open the garage
door, too.

This is of course a generic problem, where unauthenticated protocols have
unforeseen consequences.


No, that is not caused by the unauthenticated protocol, but caused by
the same device to be used with two different doors. Even if the
device would do full authentication and would verify that the door is
in his list of doors which can be opened, attacker could still do the
same thing.

Only way to get rid of that, would be to either put display on the
device telling which door responded, or put multiple buttons to the
device and you would have to bind each button to exactly one door
(i.e. each button using separate key or shared secret).

And, not you do not even need man in the middle in cryptographic
sense, just rerouting the packets from the air to the other
destination would be enough.

So for that kind of uses the device would need to be tied to exactly
one door...



What you're saying is that to secure this system, we need authentication 
of the device, either at the IKE level or at the application level (plus 
UI improvements). I agree, and suggest again that this is not a good use 
case for null or one-way authentication.


Thanks,
Yaron

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

[IPsec] Garage door - let's pick a different example

[Yaron Sheffer]

  
  
This might sound like a nit, but we have this text in the draft, as
a use case for null auth:

"User wants to get some simple action from the remote device.
Consider garage door opener: it must authenticate user to open the
door, but it is not necessary for the user to authenticate the door
opener. In this case one-way authentication is sufficient."

The problem is, this is an incorrect protocol. Specifically, a MITM
(who might be physically located by the kitchen door), could
redirect the protocol exchange to a door different from the one I
intended to open. Seeing that nothing happens, I will simply press
the remote again and open the garage door, too.

This is of course a generic problem, where unauthenticated protocols
have unforeseen consequences.

Thanks,
 Yaron
  


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

[IPsec] Puzzles and weak clients

[Yaron Sheffer]

I missed some of the discussion (Meetecho played up again), so maybe 
there's an easier answer. But I think that mere computational 
(CPU-hogging) puzzles are not very useful when the attacker (a desktop 
machine on a botnet) is much more powerful than the legitimate client (a 
last-year iPhone). And as Mike said, the attacker's resources are 
cheaper, because he steals them.


One way to mitigate this problem is by limiting the competition to new 
clients, those who haven't used the VPN for the last (say) 24 hours. The 
gateway could hand out time limited, easy to validate, IP-bound cookies 
to VPN clients. And a VPN client who presents this cookie to the gateway 
is exempted from the puzzle game (but not from the IKE cookie, because 
it proves a legitimate source address which is bound to the cookie).


And even if we add such a mechanism, we still have the problem of 
attackers being favored by this proposal, compared to weak legit 
clients. So maybe puzzles are not a very good idea after all.


Thanks,
Yaron

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

[IPsec] Charter update

[Yaron Sheffer]

  
  
IPsec folks,

Our existing charter (http://tools.ietf.org/wg/ipsecme/charters) is
badly out of date. Below is a proposed charter revision. Please
review and comment on the list. We might also discuss the new
charter in the face-to-face next week.

Thanks,
 Paul and Yaron


IP Security Maintenance and Extensions (ipsecme)


Charter

Current Status: Active

Chairs:
 Paul E. Hoffman paul.hoff...@vpnc.org
 Yaron Sheffer yaronf.i...@gmail.com

Security Area Directors:
 Stephen Farrell stephen.farr...@cs.tcd.ie
 Kathleen Moriarty kathleen.moriarty.i...@gmail.com

Security Area Advisor:
 Kathleen Moriarty kathleen.moriarty.i...@gmail.com

Mailing Lists:
 General Discussion: ipsec@ietf.org
 To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
 Archive: http://www.ietf.org/mail-archive/web/ipsec/

Description of Working Group:

 The IPsec suite of protocols includes IKEv1 (RFC 2409
 and associated RFCs), IKEv2 (RFC 5996), and the IPsec
 security architecture (RFC 4301). IPsec is widely
 deployed in VPN gateways, VPN remote access clients,
 and as a substrate for host-to-host, host-to-network,
 and network-to-network security.
 
 The IPsec Maintenance and Extensions Working Group
 continues the work of the earlier IPsec Working Group
 which was concluded in 2005. Its purpose is to maintain
 the IPsec standard and to facilitate discussion of
 clarifications, improvements, and extensions to IPsec,
 mostly to IKEv2. The working group also serves as a
 focus point for other IETF Working Groups who use IPsec
 in their own protocols.
 
 The current work items include:
 
 Recently discovered incorrect behavior of ISPs poses a
 challenge to IKE, whose UDP messages (especially #3 and #4)
 sometimes get fragmented at the IP level and then dropped
 by these ISPs. There is interest in solving this issue by
 allowing transport of IKE over TCP; this is currently
 implemented by some vendors. The group will standardize such
 a solution.
 
 The WG will review and revise the list of mandatory-to-
 implement algorithms for ESP and AH based on five years of
experience 
 with newer algorithms and cryptographic modes.
 
 The WG will revise the IKEv2 specification with a small number
 of mandatory tests required for the secure operation of IKEv2
 when using elliptic curve cryptography. This work will be based
 on draft-sheffer-ipsecme-dh-checks.

 IKEv2 has had many interoperable implementations and can now be
considered
 a mature protocol. The WG will republish the protocol as an
Internet Standard.

 At the time of writing, all the above are in late stages of the
IETF process.
 Therefore, the WG will go into low-power mode: it will remain
active as a focal point
 for the IPsec community. But it will only take on new work items
if a strong community
 interest can be seen.

 This charter will expire in July 2015 (12 months from approval).
 If the charter is not updated before that time, the WG will be
 closed and any remaining documents revert back to individual
 Internet-Drafts.
 

Goals and Milestones:

 Done - IETF Last Call on large scale VPN use cases and
requirements
 Done - IETF last call on IKE fragmentation solution
 Done - IETF last call on new mandatory-to-implement algorithms

 [No current milestones]
  


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

Re: [IPsec] Charter update

[Yaron Sheffer]

   Recently discovered incorrect behavior of ISPs poses a
   challenge to IKE, whose UDP messages (especially #3 and #4)
   sometimes get fragmented at the IP level and then dropped
   by these ISPs. There is interest in solving this issue by
   allowing transport of IKE over TCP; this is currently
   implemented by some vendors. The group will standardize such
   a solution.


The working group had already reached consensus not to support two
different fragmentation solutions and to only support
draft-smyslov-ipsecme-ikev2-fragmentation, after Yoav's IKE TCP
presentation, I believe in London? So I don't think this item belongs
on the agenda, unless we are looking at revising that earlier decision.


We have a fragmentation draft (almost) past IESG review. So we're not 
revising any decision. The group will standardize such a solution is 
still correct, until we actually publish the document.





Goals and Milestones:

  Done - IETF Last Call on large scale VPN use cases and requirements
  Done - IETF last call on IKE fragmentation solution
  Done - IETF last call on new mandatory-to-implement algorithms

  [No current milestones]


Could we add something about assisting  Opportunistic Encryption, or
whatever term will be used? There is the auth_none draft, and there
will be an OE draft by the libreswan team soon. Those will end up in
ipsecme.


Quoting the new text, the group will only take on new work items if a 
strong community interest can be seen. Do we have other people 
supporting such an addition to the charter?




Paul


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

Re: [IPsec] Charter update

[Yaron Sheffer]

You are revising the decision NOT to have IKE TCP:

 There is interest in solving this issue by
  allowing transport of IKE over TCP; this is currently
  implemented by some vendors. The group will standardize such
  a solution.

If you remove the first sentence, then it only talks about UDP and how
we are working on standarising fragmentation support using UDP.

Paul


OK, makes sense. We need to remove that sentence.

Thanks,
Yaron

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

[IPsec] Stopping work on Auto-Discovery VPN

[Yaron Sheffer]

Dear WG members,

After being unable to reach consensus on a protocol that solves the AD 
VPN problem, we set up a smaller group to discuss the solutions on the 
table and try to reach agreement between the competing proposals. 
Unfortunately, this approach was similarly unsuccessful even after 
multiple phone calls with the respective authors.


As a result, the chairs have decided to officially withdraw this work 
item from the group's agenda. We will work with the ADs to remove it 
from our charter.


We would like to thank the authors of RFC 7018 (Auto-Discovery VPN 
Problem Statement and Requirements), and encourage the authors of the 
protocol proposals to publish them for the benefit of the community.


Regards,

Paul and Yaron

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

Re: [IPsec] Minor thinko in IKEv2 rfc5996bis draft (and RFC 5996)

[Yaron Sheffer]

Hi David,

Thanks for detecting this glitch. I don't think this is worth an 
erratum, given that we are republishing the document.


Thanks,
Yaron

On 05/19/2014 05:09 AM, Black, David wrote:

In looking for something else, I ran across a minor thinko in the
rfc5996bis draft that was inherited from RFC 5996.

Section 3.14, Encrypted Payload, 4th paragraph:

When an authenticated encryption algorithm is used to protect the IKE
SA, the construction of the Encrypted payload is different than what
is described here.  See [AEAD] for more information on authenticated
encryption algorithms and their use in ESP.

[AEAD] is a reference to RFC 5282, Using Authenticated Encryption
Algorithms with the Encrypted Payload of the Internet Key Exchange
version 2 (IKEv2) Protocol.

Hence, a change is in order at the end of the paragraph:

ESP - IKEv2

In the unlikely event that the IESG finds nothing else to change in
the draft :-), an RFC Editor Note ought to suffice to handle this.

Should I also file an erratum against RFC 5996?

Thanks,
--David

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
david.bl...@emc.comMobile: +1 (978) 394-7754


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



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

Re: [IPsec] Fwd: New Version Notification for draft-nir-ipsecme-chacha20-poly1305-02.txt

[Yaron Sheffer]

Thank you Yoav. My personal responses below.

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


Best,
Yaron

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

Hi.

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


[...]



Comments are, of course, welcome, and I’d like to repeat my questions
from the London meeting:
  - Should this be a WG item.

Yes, it's time we had good alternative crypto.

  - Should we apply for early identifier assignment

No, I don't see such a rush to implement. But feel free to prove me wrong.

  - Should this be extended for IKE (current draft covers only ESP)

Yes, we need alternative crypto for IKE just as we do for ESP.


Yoav

Begin forwarded message:


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


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

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

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




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

The IETF Secretariat





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



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