Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Alexey Melnikov]

Hi Valery,

> On 27 Sep 2016, at 12:42, Valery Smyslov  wrote:
> 
> Hi Alexey,
> 
> payload type for the Puzzle Solution Payload is specified in the last sentence
> of Section 8.2:
> 
>  The payload type for the Puzzle Solution payload is .
> 
> It is not included in the diagram in this section since the "Next Payload" 
> field in generic payload header contains the type of the following payload, 
> not the type of payload the diagram depicts.

Ok, this is what I missed. I just wanted to make sure that whoever parses a 
response can figure out where a puzzle solution starts and whether it is 
present.

Thank you,
Alexey



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

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Stephen Farrell]

On 27/09/16 20:07, Valery Smyslov wrote:
> 
> The attacker can however gain some benefits if he/she waits some time
> until the half-open SA is expired on Responder and chooses the same SPI
> and nonce for the next connection request. He/she will receive the same
> puzzle
> if the Responder doesn't change value of secret yet. Note that RFC7296
> recommends
> changing secret frequently if under attack (RFC7296, Section 2.6):
> 
>   The responder should change the value of  frequently, especially
>   if under attack.
> 
> I think we can add some words to the draft that will recommend
> to generate cookie in such a manner, that the cookie is not repeated
> even if the same IP, SPI and nonce are used by Initiator.

Good one. Yeah I think it'd be fine to add that.

All the rest of your and Yoav's responses are good too.

Thanks,
S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Stephen Farrell]

On 27/09/16 20:21, Yoav Nir wrote:
> Looking at the IPR statement you linked to, it does not seem relevant
> to me, but IANAL. The proof-of-work scheme described in the patent
> ([2]) involves setting a time limit for the client to complete the
> puzzle solution. The puzzle in our draft has a set difficulty level,
> but no time limit for the Initiator to solve it.

FWIW, that sounds reasonable to me. But I've given up pondering
what lawyers think about patents so folks can make up their own
minds;-)

S.



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Yoav Nir]

On 27 Sep 2016, at 8:09 PM, Stephen Farrell  wrote:

> This is a nicely written document... thanks!
> 
> - I vaguely recalled that puzzles and IPR rang a bell.  Did
> the WG consider [1]? If not, and if it helps, I'm fine with
> making a 3rd party declaration on that and last call could be
> done again. Or maybe there's a better way to handle it. Or
> maybe the WG considered it and are happy enough already that
> it's not relevant or about to expire or abandoned or
> something.  ("Not relevant" would puzzle me:-)
> 
>   [1] https://datatracker.ietf.org/ipr/417/

We did not consider this one. We did consider a Sun/Oracle patent but 
ultimately worked around this by replacing the type of puzzle. The current 
puzzle is based on the proof-of-work algorithm used in Bitcoins. 

Looking at the IPR statement you linked to, it does not seem relevant to me, 
but IANAL. The proof-of-work scheme described in the patent ([2]) involves 
setting a time limit for the client to complete the puzzle solution. The puzzle 
in our draft has a set difficulty level, but no time limit for the Initiator to 
solve it.

[2] https://libpatent.com/patents/07197639

> - section 3: "if certificates are involved" - you could note
> here that involving certificates can introduce a network
> based delay (OCSP, CRLs etc) that's a little different from
> CPU consumption. (But it's a nit, and you do note a similar
> issue in 4.7.)

True. But I think that for most devices used as IKE responders the bottleneck 
is going to be the amount of CPU they can dedicate to verifying signatures on 
certificates and CRLs/OCSP responses, not the amount of memory they need to 
allocate while they’re waiting for a response from whatever servers on the 
network. IOW if a certain device is capable of verifying the signatures on 
certificate and CRLs for n initiators per second and there is a total network 
delay of t to get all the necessary CRLs or OCSP responses and a memory 
allocation of m for every in-progress IKE Exchange, the same device will be 
able to allocate much more memory than the m*n*t that is needed to support the 
n*t concurrent exchanges.

> - 4.2: "ratelimits should be done based on either the /48 or
> /64" - would it be better to say "something between a /48 and
> a /64" maybe? Don't some ISPs assign things in-between?

They do. It even says so earlier in the same paragraph. But the Responder does 
not know what the practices are at the Initiator’s ISP. We know that prefixes 
longer than /64 are too granular and that prefixes shorter than /48 are too 
coarse for marking a certain range of addresses as attacking. I suppose the 
Responder could choose something in between, but I don’t think there’s ever a 
good justification for say /50 or /58. /48 and /64 seem to make the most sense. 

> - 4.4: Did you consider making the "4 keys" requirement tied
> to the PRF algorithm identifier? That would allow for a
> future where e.g. 6 keys are needed for the same PRF, if that
> were ever useful. (Without changing current implementations.)
> I guess you'd need a separate IANA registry that'd initially
> duplicate stuff in that case so maybe not worth doing. (And
> could be done later.)

Since the level of the puzzle is settable by tweaking the required number of 
zero-bits, the number of required answers plays no part in the level of 
difficulty. Rather, it is used to smooth out the puzzle difficulty.  See my 
response to Mirja on this and also 
https://mailarchive.ietf.org/arch/msg/ipsec/v7PFBEWeaT6ZQCjzCmIaxbRnZ8A

> - 7.1.1 - you don't clearly say if the cookie value here can
> be a new one or should be the same as one previously used (if
> one was previously used). That may just be my ignorance of
> IPsec cookies though, but I wondered if there are any cases
> where the initiator gets to work away on the puzzle ahead of
> time if the same cookie is used for multiple interactions.
> There's not much (or zero) of an improvement to the attack
> here, though maybe the attacker could more easily offload
> puzzle solving to someone else in that case?
> 

I see that while I’m typing this Valery has also replied, so I’ll leave this 
part to him, as he replied at length.

Yoav

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

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Valery Smyslov]

Hi Stephen,


--
COMMENT:
--


This is a nicely written document... thanks!


Thank you!


- I vaguely recalled that puzzles and IPR rang a bell.  Did
the WG consider [1]? If not, and if it helps, I'm fine with
making a 3rd party declaration on that and last call could be
done again. Or maybe there's a better way to handle it. Or
maybe the WG considered it and are happy enough already that
it's not relevant or about to expire or abandoned or
something.  ("Not relevant" would puzzle me:-)

   [1] https://datatracker.ietf.org/ipr/417/


The WG didn't consider this particular IPR.


- section 3: "if certificates are involved" - you could note
here that involving certificates can introduce a network
based delay (OCSP, CRLs etc) that's a little different from
CPU consumption. (But it's a nit, and you do note a similar
issue in 4.7.)


The network delay does not necessary take place
(OCSP is optional, CRL may be cached), while CPU consumption 
is unavoidable. 


- 4.2: "ratelimits should be done based on either the /48 or
/64" - would it be better to say "something between a /48 and
a /64" maybe? Don't some ISPs assign things in-between?


This particular sentence was discussed by WG. 
I think that "either /48 or /64" was chosen for simplicity.



- 4.4: Did you consider making the "4 keys" requirement tied
to the PRF algorithm identifier? That would allow for a
future where e.g. 6 keys are needed for the same PRF, if that
were ever useful. (Without changing current implementations.)
I guess you'd need a separate IANA registry that'd initially
duplicate stuff in that case so maybe not worth doing. (And
could be done later.)


Several puzzle solutions help reduce volatility of 
time needed to solve any given puzzle. I don't think
it is related to particular PRF, since any "good" PRF must 
generate pseudorandom result and finding a key for that result 
would always involve a fortune for the Initiator.

The fixed number of keys (4) is a compromise.
We considered setting it to larger value, say 16
(and it would make correlation between puzzle difficulty 
and the time needed to solve it more predictable), 
but it would increase IKE message size in initial exchange.
And it is a bad thing, since it increases the chances that 
the message exceeds MTU and is fragmented by IP,

with all negative consequences.


- 7.1.1 - you don't clearly say if the cookie value here can
be a new one or should be the same as one previously used (if
one was previously used). That may just be my ignorance of
IPsec cookies though, but I wondered if there are any cases
where the initiator gets to work away on the puzzle ahead of
time if the same cookie is used for multiple interactions.
There's not much (or zero) of an improvement to the attack
here, though maybe the attacker could more easily offload
puzzle solving to someone else in that case?


In IKEv2 the cookie is usually generated by applying hash
function to Initiator's IP, SPI, nonce and some secret maintained
by Responder. Since the cookie must be stateless for the Responder,
it is not stored on the Responder (except for the secret,
which is global and is changed periodically). So, if the Initiator
uses the same IP, same SPIi and the same nonce, it will very likely
receive the same cookie until the secret is changed. However, it won't much 
help an attacker. Once the puzzle is solved and the attacker successfully creates

half-open SA on the Responder, it cannot use the same combination
of IP and SPI to create another one, because all the initial messages
with the same IP+SPI will be delivered to that half-open SA and discarded.

The attacker can however gain some benefits if he/she waits some time
until the half-open SA is expired on Responder and chooses the same SPI and nonce 
for the next connection request. He/she will receive the same puzzle

if the Responder doesn't change value of secret yet. Note that RFC7296 
recommends
changing secret frequently if under attack (RFC7296, Section 2.6):

  The responder should change the value of  frequently, especially
  if under attack.

I think we can add some words to the draft that will recommend
to generate cookie in such a manner, that the cookie is not repeated
even if the same IP, SPI and nonce are used by Initiator.

Thank you,
Valery Smyslov.



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

[IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Stephen Farrell]

Stephen Farrell has entered the following ballot position for
draft-ietf-ipsecme-ddos-protection-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/



--
COMMENT:
--


This is a nicely written document... thanks!

- I vaguely recalled that puzzles and IPR rang a bell.  Did
the WG consider [1]? If not, and if it helps, I'm fine with
making a 3rd party declaration on that and last call could be
done again. Or maybe there's a better way to handle it. Or
maybe the WG considered it and are happy enough already that
it's not relevant or about to expire or abandoned or
something.  ("Not relevant" would puzzle me:-)

   [1] https://datatracker.ietf.org/ipr/417/

- section 3: "if certificates are involved" - you could note
here that involving certificates can introduce a network
based delay (OCSP, CRLs etc) that's a little different from
CPU consumption. (But it's a nit, and you do note a similar
issue in 4.7.)

- 4.2: "ratelimits should be done based on either the /48 or
/64" - would it be better to say "something between a /48 and
a /64" maybe? Don't some ISPs assign things in-between?

- 4.4: Did you consider making the "4 keys" requirement tied
to the PRF algorithm identifier? That would allow for a
future where e.g. 6 keys are needed for the same PRF, if that
were ever useful. (Without changing current implementations.)
I guess you'd need a separate IANA registry that'd initially
duplicate stuff in that case so maybe not worth doing. (And
could be done later.)

- 7.1.1 - you don't clearly say if the cookie value here can
be a new one or should be the same as one previously used (if
one was previously used). That may just be my ignorance of
IPsec cookies though, but I wondered if there are any cases
where the initiator gets to work away on the puzzle ahead of
time if the same cookie is used for multiple interactions.
There's not much (or zero) of an improvement to the attack
here, though maybe the attacker could more easily offload
puzzle solving to someone else in that case?


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

Re: [IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Valery Smyslov]

Hi Alissa,


--
COMMENT:
--

"A typical Initiator or
  bot-net member in 2014 can perform slightly less than a million
  hashes per second per core"

Is this supposed to say 2014? Struck me as a little weird.


The -00 version of the document was written in 2014, 
so the estimates came from Yoav's experiments, 
that he conducted at that time, I think.


Regards,
Valery Smyslov.

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

[IPsec] Alissa Cooper's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Alissa Cooper]

Alissa Cooper has entered the following ballot position for
draft-ietf-ipsecme-ddos-protection-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/



--
COMMENT:
--

"A typical Initiator or
   bot-net member in 2014 can perform slightly less than a million
   hashes per second per core"

Is this supposed to say 2014? Struck me as a little weird.


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

Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Yoav Nir]

> On 27 Sep 2016, at 2:42 PM, Valery Smyslov  wrote:
> 
> Hi Alexey,
> 
> payload type for the Puzzle Solution Payload is specified in the last sentence
> of Section 8.2:
> 
>  The payload type for the Puzzle Solution payload is .
> 
> It is not included in the diagram in this section since the "Next Payload" 
> field in generic payload header contains the type of the following payload, 
> not the type of payload the diagram depicts.

But it is depicted in sections 7.1.2 and 7.2.2. In both cases denoted as PS 
(=puzzle solution):

From 7.1.2:
   If the Initiator supports puzzles and is ready to solve them, then it
   tries to solve the given puzzle.  After the puzzle is solved the
   Initiator restarts the request and returns back to the Responder the
   puzzle solution in a new payload called a Puzzle Solution payload
   (denoted as PS, see Section 8.2) along with the received COOKIE
   notification.

   HDR, N(COOKIE), [PS,] SA, KE, Ni, [V+][N+]   —>

From 7.2.2:
   If the IKE_SA_INIT response message contains the PUZZLE notification
   and the Initiator supports puzzles, it MUST solve the puzzle.  Note,
   that puzzle construction in the IKE_AUTH exchange differs from the
   puzzle construction in the IKE_SA_INIT exchange and is described in
   Section 7.2.3.  Once the puzzle is solved the Initiator sends the
   IKE_AUTH request message, containing the Puzzle Solution payload.

   HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
   [IDr,] AUTH, SA, TSi, TSr}   -->




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

Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Valery Smyslov]

Hi Alexey,

payload type for the Puzzle Solution Payload is specified in the last sentence
of Section 8.2:

  The payload type for the Puzzle Solution payload is .

It is not included in the diagram in this section since the "Next Payload" field in generic 
payload header contains the type of the following payload, not the type of payload 
the diagram depicts.


There is also an IANA Considerations Section which also specifies the
payload type for the Puzzle Solution payload.

Thank you,
Valery Smyslov.



Alexey Melnikov has entered the following ballot position for
draft-ietf-ipsecme-ddos-protection-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/



--
COMMENT:
--

I tempted to ballot Yes on on the document. I hope it will get widespread
deployment.

Please excuse my ignorance: Puzzle Solution Payload format - I don't see
the new payload type specified in the diagram. Where is it included?


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

[IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

[Alexey Melnikov]

Alexey Melnikov has entered the following ballot position for
draft-ietf-ipsecme-ddos-protection-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/



--
COMMENT:
--

I tempted to ballot Yes on on the document. I hope it will get widespread
deployment.

Please excuse my ignorance: Puzzle Solution Payload format - I don't see
the new payload type specified in the diagram. Where is it included?


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

Re: [IPsec] Flexible multi-factor authentication

[Wang Jian]

2016-09-27 2:49 GMT+08:00 Paul Wouters :
> You could help by reviewing and telling us you are in favour of
> working group adoption of:
>
> https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-02
>

I am new here. I will try.

> We dont really add goals that have no backers behind them. So if you
> want this process to start, the best way would be:
>
> 1) write a draft and publish it to the list for feedback
>(maybe ask for co-authors to help)
> 2) ask for working group adoption
> 3) get the document ready as per working group consensus
>

I understand that. I will learn how to do these.

First I need some help and suggestion to identify what area should be
work on. For example, a new EAP type or generic EAP chaining
mechanism?

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

Re: [IPsec] Flexible multi-factor authentication

[Wang Jian]

Hi,

It's not only a generic way for authentication conversation, but also
a defined way for authentication conversation.

VPN clients, vpn servers and authentication servers must have a
standard, thus unified user experiences.

- What should be prompted to user during conversation, what should be
interpreted by clients, servers, and AS. Examples
* username and password authentication should be prompted to user if
no credential saved, but quitely handled if credential saved; when
username & password authentication fails, user is prompted to re-enter
* TOTP authentication request by server should be prompted to user, a
message and an input field, and client should not save the TOTP input
* Fingerprint authentication request by server should be prompted to
user and client should use fingerprint sensor (and handling timeout?)

- Input data type: although all input data can be stringified, how to
intepret them and how to handle them? TOTP number? human fingerprint?

- How to distinguish failure or unsupported method, for example
* fingerprint authentication is requested, but client replies that it
doesn't support it. Then alternative method such as TOTP can be used

Commercial SSL VPN vendors can ensure client, server and
authentication server to be in accordance. I think IKEv2 as a
standard, should also cover this area.

EAP-OTP and EAP-GTC in EAP-TTLS can be abused, but if they are not
abused the same way in clients, servers and authentication servers,
can't be used at all for enterprise deployment.

BTW: Can EAP-MD5/EAP-GTC/EAP-OTP be chained in EAP-TTLS in IKEv2? If
yes, any pointer to docs, examples?

Regards,
Wang Jian



2016-09-26 18:35 GMT+08:00 Yoav Nir :
> Hi.
>
> It seems that what you are looking for is a generic way to transport 
> arbitrary strings from server to client and back again.
>
> While not specifically intended for that, both EAP-GTC and EAP-OTP (types 6 
> and 5 respectively) have been (ab)used for that purpose. Not sure if that has 
> happened in the context of IKEv2, though. GTC in a TTLS/PEAP/some other kind 
> of tunneling has been done before, although when running EAP in IKE I don’t 
> think you need yet another tunnel.  I guess it depends on the level of 
> pre-existing trust that exists between the client and the VPN gateway (as 
> opposed to the EAP authentication server).
>
> Yoav
>
>> On 26 Sep 2016, at 10:13 AM, Wang Jian  wrote:
>>
>> Hello,
>>
>> When I researched for VPN solution for my company, IPsec was not an
>> option. Then IKEv2 was an option but yet met our requirements.
>>
>> We chose from several SSL VPNs which also support ESP or UDP
>> transport. The key requirement IKEv2 doesn't meet is MFA functionality
>> and flexibility. Also, split dns functionality is missing.
>>
>> The MFA we finally implemented is like
>>
>> 1. Users first authenticate themselves with username & password
>> 2. according to the user's security group, another OTP authentication
>> step is needed or not. For users that OTP is needed, OTP
>> authentication is prompted or skipped if  (the device,the user) tuple
>> was authenticated recently (i.e. 24 hours)
>>
>> * We could not get unique device id, so IP address and username are
>> used as the tuple. However we prefer to a generated permanent device
>> id by vpn client, the device's manufacturer-assigned id (or derived
>> hash if privacy is a concern), or time-limited http-cookie-like id
>> generated and returned by authenticator.
>>
>> Our flexible 2FA authentication is implemented using RADIUS challenge.
>> The principles are
>>
>> 1. username & password authentication is used to integrated with
>> central user management. For ease of use, VPN client should be capable
>> of store password securely in device
>> 2. authenticator controls the remaining authentication steps, and
>> decides which step should be done or be skipped.
>>
>> Current IKEv2 doesn't provide an EAP authentication method to support
>> such flexible MFA use case. And in the new charter, there is no goal
>> of the kind.
>>
>> IMHO, flexible MFA is most important for large scale enterprise
>> deployment. Please add it as a goal.
>>
>> Regards,
>> Wang Jian
>>
>> ___
>> 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