Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

Bodo Moeller <> Thu, 05 December 2013 11:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 50F0B1ADF68 for <>; Thu, 5 Dec 2013 03:45:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MHSmnpyvQUmi for <>; Thu, 5 Dec 2013 03:45:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id CA9FC1ADF6B for <>; Thu, 5 Dec 2013 03:45:46 -0800 (PST)
Received: from ( []) by (node=mreu3) with ESMTP (Nemesis) id 0LbTTT-1V9fq919Ip-00l3ms; Thu, 05 Dec 2013 12:45:42 +0100
Received: by with SMTP id o6so18281667oag.33 for <>; Thu, 05 Dec 2013 03:45:41 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LD6kZxNKcYaiF2eDL7Mc9dxGoiTriEbPS0pzEgS8fOc=; b=HwpH+cpOnsO6SI5P0NfUOBRyXFBV72sLctoLdosZUaLLF3Hg6KfEd+NTjxKyvd0h77 P/aaRfBSibyptBpNpPw+aAzmyZHU3/l1JoZKwqEb+1QDWcbzP+B6PGhFjx7YpHObJB1S jJ6Hxz641eTUBtvb0HbqsNgcEWjuQF3QOz3P7WTbkeA21g/SyVvZ5LfBujmo7tBAJu7s eKr8p6TgLfxubm+R9xBLRRBeGewMsWgg5M4jaKi8pmFbmdZau9b3drIkC9FDHKR8ehDb i/P6zljIyDxFgJIeiHg01UBUgGcBXLxXP9sfNwW5RaEADPa7UL2LXXQarArLvDJFHPaJ 676A==
MIME-Version: 1.0
X-Received: by with SMTP id g1mr903072obh.59.1386243941069; Thu, 05 Dec 2013 03:45:41 -0800 (PST)
Received: by with HTTP; Thu, 5 Dec 2013 03:45:40 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Thu, 5 Dec 2013 12:45:40 +0100
Message-ID: <>
From: Bodo Moeller <>
To: Mohamad Badra <>
Content-Type: multipart/alternative; boundary=001a11c2b8b2adfdc204ecc81109
X-Provags-ID: V02:K0:sLMmpAAGSJeNU0OZrWijJrPEnxhVV43CwYDm0iD+HGH DLQ3uahLQjgvBgqmXZXWVFKHz5uENouEPVL5SDbGK3xKZD0lhU aVcywn8p+vN98YjNIJt4jSIVR/UJbn43gUuXJraAqanhSkVvuU GVZOHuPJrxLx/JJ8EgYWQAEHtkher3zNjKndENPBZvve+TaizA HexFRki+gAOnMWSXh5Vuy/Jh3vDpb82ZW2e3qKSCvpN6tpqTns K9OJ4SPooOgbMXEsVI7FTek6K7xOIVbwl3ygusnGte6aXc2R3H 6+OVXOC5gxma3LJQdNQtr34bX1J6nk4bTkijNAxp7k6AGDGJ+/ OlW//xepCNr5ukHCGNp+tVBBR7PvpMrQSzsjpCuL0rCFOWg77V 2q2bD1eMa+9ikwSIHLg9eNz7MYjImOHKMoyTR3Xtq24EmKL81Q mxvtX
Cc: "" <>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Dec 2013 11:45:48 -0000

Mohamad Badra <>om>:

For info, I submitted during 2007 and 2008 two documents to enable
> authentication using passwords.
> Both of them are simple, and secure enough to enable password-based
> authentication

That's something different from a password-authenticated key exchange,
though.  In your specs, the client sends the password to the server (in
encrypted form).  If the server isn't actually the legitimate party
expected by the client, this compromises the password.  So the client still
depends heavily on authenticating the server first.

In a *password-authenticated* key exchange, the client doesn't readily
compromise the password if an attacker poses as the server.  So the client
doesn't have to do the usual certificate-based check to authenticate the
server (although, depending on the specific scheme, you could optionally
still do that, to mitigate certain kinds of attacks) -- that's why it's
called "password-authenticated": authentication is inherently based on that
password.  All an attacker posing as the server should get is *one* single
attempt (per client-initiated connection) to guess the password; all the
server will learn, unless that guess happens to be correct, is that that
wasn't the right password.