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

Mohamad Badra <mbadra@gmail.com> Thu, 05 December 2013 13:36 UTC

Return-Path: <mbadra@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056AF1ADEC0 for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 05:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WD-2vlUqhswh for <tls@ietfa.amsl.com>; Thu, 5 Dec 2013 05:36:29 -0800 (PST)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8DE1ADFB7 for <tls@ietf.org>; Thu, 5 Dec 2013 05:36:29 -0800 (PST)
Received: by mail-ve0-f178.google.com with SMTP id c14so13503706vea.23 for <tls@ietf.org>; Thu, 05 Dec 2013 05:36:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HUO072LFtlQu5piQkDNF9hN/pKIabPvEBA651Gi7Gqo=; b=cLDMvIYl5aIHLhTKpj0QwrKZLWKh6h/VfJ+NrPFqaQEYpHti5iJWEttn9OhS5nKkTM INX+nJArCSOAvtAArdCXpMrb75PF6Oqjen814xzf137s1rOgfT6erOSfPn5sBR6THGB3 pNF+p+VlFpDQ0Ppe5cVgVZYKb2IAhXkTMNQNgsbbN54ACfWu9gNFk+mxDWHLBaJjTild WPTOruwg3Pe19OTxmNI9UUpdIPjaTujyDLR7rk/6E8U6Q7m3yH5VJkZhNDEXu013nDlM MJUN7W0FX2WLMeMN6Hindywm61awkekFsfdaxRuHF0CR5golo8LHLenhfGgykEnX7wBb meGw==
MIME-Version: 1.0
X-Received: by 10.220.147.16 with SMTP id j16mr5733220vcv.28.1386250585669; Thu, 05 Dec 2013 05:36:25 -0800 (PST)
Received: by 10.221.43.138 with HTTP; Thu, 5 Dec 2013 05:36:25 -0800 (PST)
In-Reply-To: <CADMpkcJXK8Yg6OSYjouz1u07ScEwYvpfCWF16YPgGrM-Lvra6A@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <CACsn0cmtP_dF7N2op4DZUwR8t-fW30GmtdqQoteZ+9Y0oH3dUg@mail.gmail.com> <a4b1729af4966e99df1582943f02a0a8.squirrel@www.trepanning.net> <CACsn0cksrU2GErd6FkZPkXKXK4pSJhTbBoJ-0C-14jsM=UY2iQ@mail.gmail.com> <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net> <CACsn0c=PnB2CA8rpNtcOp6RRLNWHEPN-aN+AdWSF7FJM2wZOog@mail.gmail.com> <CAOhHAXw5Px1mB9ogtniBHwLknTT6F0db4=gEOr+RcXxf2bCQ_A@mail.gmail.com> <CADMpkcJXK8Yg6OSYjouz1u07ScEwYvpfCWF16YPgGrM-Lvra6A@mail.gmail.com>
Date: Thu, 05 Dec 2013 17:36:25 +0400
Message-ID: <CAOhHAXzjsZ6xNCc2KAeLSify1prVzaZUk1GdUj-QC3qAJ-SP4g@mail.gmail.com>
From: Mohamad Badra <mbadra@gmail.com>
To: Bodo Moeller <bmoeller@acm.org>
Content-Type: multipart/alternative; boundary="047d7b3436d2bab7d004ecc99de8"
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Dec 2013 13:36:31 -0000

On Thu, Dec 5, 2013 at 3:45 PM, Bodo Moeller <bmoeller@acm.org> wrote:

>
> 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.
>


Agree. The purpose was to enable client's password-based authentication to
server storing password in clear text or the password's hash ( e.g., LDAP
and EAP).

It cannot be used without a server-side certificate - at least for the
first connection - but if the client share a password with the server, the
public key of the server could be installed on the client host (i.e., as
with SSH), in which case the client will not depend on authenticating the
server during every session.

​Best regards,
Badra​