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

Tero Kivinen <> Mon, 29 March 2010 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D4FC33A694F for <>; Mon, 29 Mar 2010 05:33:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.469
X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JLiVaaT4MrIr for <>; Mon, 29 Mar 2010 05:33:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4E6083A67DA for <>; Mon, 29 Mar 2010 05:33:00 -0700 (PDT)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id o2TCXIn6004424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Mar 2010 15:33:18 +0300 (EEST)
Received: (from kivinen@localhost) by (8.14.3/8.12.11) id o2TCXE8d012245; Mon, 29 Mar 2010 15:33:14 +0300 (EEST)
X-Authentication-Warning: kivinen set sender to using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Mon, 29 Mar 2010 15:33:14 +0300
From: Tero Kivinen <>
To: Yaron Sheffer <>
In-Reply-To: <>
References: <015701cacc74$9b0f3c20$d12db460$> <> <018001cacd04$d59efc50$80dcf4f0$> <> <> <> <> <> <>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 10 min
Cc:, Dan Harkins <>, Kaz Kobara <>
Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Mar 2010 12:33:02 -0000

Yaron Sheffer writes:
> I'm not suggesting to constrain the protocol. I'm trying to focus the 
> discussion, and focus the criteria. We both know that integrating an 
> existing PAKE into IKEv2 is not such a big deal. But we can spend months 
> debating password management:
> - Do we specify a password policy?
> - Is the policy somehow exposed in the protocol?
> - Do you need special error handling to support password policy ("Your 
> password will be expiring in 3 days")?
> - Do you need special protocol building blocks for password policy, e.g. 
> to allow password change?
> - Do the IKE transport rules (timeouts) need to change to accommodate 
> human input?

As far as I can think all of those would be outside the charter.

> And so on and so forth. This would all be highly important if we're 
> going after the client-gateway case.

I disagree on that. I do not think those are important for the
protocol point of view regardless whether we have client there or not.

> The charter defines the problem we want to solve, based on WG consensus 
> and IESG input. I suggest that we stick to it rather than continue 
> arguing about it.

The charter does not rule client-server or client-gateway out, it
mostly just says that we need to define simplier solution than EAP,
but I do not think it only limits you to server-server or
router-router cases.

For example for home or small office solutions there is no AAA server
and using EAP to do remote access would not be feasible, thus I would
expect most of the people currently use plain PSK in those
environments, and they also do use weak passwords, thus would need
something better.

Also I think that kind of scenario is completely within our charter
(if not, point me to the text which rules that out in our charter,
note that it is still within charter even when that specific example
is not given as example in charter).

Most of the scenario text in charter uses words like "such as",
"usually" etc, i.e they are not limiting charter to only those exact

The goal is defined as:

"The WG will develop a standards-track extension to IKEv2 to allow
mutual authentication based on "weak" (low-entropy) shared secrets.
The goal is to avoid off-line dictionary attacks without requiring the
use of certificates or EAP. "