Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Hi Kaz, the deployment experience has been that between gateways, people abuse PSK authentication by using it with short passwords. Even though in principle they could do better. Thanks, Yaron On 26.3.2010 19:53, Kaz Kobara wrote: Hi Yaron Thank you for your clarification. "betwe

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Hi Dan, I'm afraid I disagree with you on several counts. See below. Thanks, Yaron On 26.3.2010 20:11, Dan Harkins wrote: Telling administrators what they can and cannot do is really not the function of our standards body. If someone wants to use a "long secret" or a password to au

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

> between gateways, people abuse > PSK authentication by using it with short passwords. I agree, but what I wanted to say was this is also true (and even worse) "between clients and gateways". > -Original Message- > From: Yaron Sheffer [mailto:yaronf.i...@gmail.com] > Sent: Saturday, Marc

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Hi Yaron, You say below, "If a protocol can be specified for the general use case, that's very well. But there will be protocols that are only applicable to some specific use cases, and that's fine, too." But then the criteria document says, "This document is limited to the use of password-ba

Re: [IPsec] Question about RFC 5114

Hi Joy When one uses a subgroup like defined in RFC 5114, q (and (p-1)/2q ) must be chosen carefully. Precisely: 1. q must be a prime number of 2k or more bits where k is a security parameter. 2. q must be a divisor of ((p - 1) / 2). 3. Every factors of (p - 1) / (2q) must also be primes compara

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Kaz, On Sat, March 27, 2010 11:00 am, Kaz Kobara wrote: >> between gateways, people abuse >> PSK authentication by using it with short passwords. > > I agree, but what I wanted to say was > this is also true (and even worse) "between clients and gateways". So is there a reason you don't want

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Actually I do want to fix it. All you have to do is use IKEv2 with one of the shining new EAP methods. Such as http://tools.ietf.org/html/draft-harkins-emu-eap-pwd-13. Thanks, Yaron On 27.3.2010 23:46, Dan Harkins wrote: Kaz, On Sat, March 27, 2010 11:00 am, Kaz Kobara wrote: be

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Hi Dan, Again, the criteria document is just following the charter in mentioning this constraint. The protocol we end up with might have all sorts of nice-to-have features and behaviors. But for the criteria, we have to focus on what's important. Use cases that were excluded in the charter (

[IPsec] National Institute of Advanced Industrial Science and Technology (AIST)'s Statement about IPR related to draft-shin-augmented-pake-00

Of interesting to this WG: --Paul Hoffman, Director --VPN Consortium ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Hi Yaron, Since you did not respond to my question, I guess I can infer then that there is no protocol issue _right now_ that would prevent some password authentication scheme from being used with a "client" and a "gateway". That being the case, the criteria document should not constrain any

Re: [IPsec] Question about RFC 5114

> -Original Message- > From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf > Of Kaz Kobara > Sent: Friday, March 26, 2010 6:26 PM > To: lat...@austin.ibm.com; mlepin...@bbn.com; k...@bbn.com > Cc: ipsec@ietf.org; avaga...@redhat.com > Subject: Re: [IPsec] Question about

Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

> So is there a reason you don't want to fix this "between clients > and gateways"? (As most of this WG members have already noticed) PSK in IKE is foolish in the sense that it is vulnerable against off-line dictionary attack while using heavy DH calculation. There is no reason not to fix this