[TLS] about the PWD Proposal

zhou.sujing@zte.com.cn Fri, 18 November 2011 08:59 UTC

Return-Path: <zhou.sujing@zte.com.cn>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405D121F84A1 for <tls@ietfa.amsl.com>; Fri, 18 Nov 2011 00:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.917
X-Spam-Level:
X-Spam-Status: No, score=-99.917 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbhnbLkKjxpg for <tls@ietfa.amsl.com>; Fri, 18 Nov 2011 00:59:45 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2744F21F84A0 for <tls@ietf.org>; Fri, 18 Nov 2011 00:59:44 -0800 (PST)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901626001193; Fri, 18 Nov 2011 16:47:21 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 76252.1626001193; Fri, 18 Nov 2011 16:59:18 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAI8xMTP069835 for <tls@ietf.org>; Fri, 18 Nov 2011 16:59:22 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
To: tls@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF48A3B9D8.19A08C28-ON4825794C.002F0B42-4825794C.003162E8@zte.com.cn>
From: zhou.sujing@zte.com.cn
Date: Fri, 18 Nov 2011 16:59:07 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-18 16:59:25, Serialize complete at 2011-11-18 16:59:25
Content-Type: multipart/alternative; boundary="=_alternative 003162E54825794C_="
X-MAIL: mse02.zte.com.cn pAI8xMTP069835
Subject: [TLS] about the PWD Proposal
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 18 Nov 2011 08:59:48 -0000

Hi,
 I am interested in the PWD proposal at the meeting, and run through 
it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4),
 and have the following concerns:

1. In the document, it  says both Client and Server should be able to 
compute PE, which is derived from username, password, salt,etc.
   That means Client or the user should also remember the salt value, in 
that case, salt is meaningless and can be replaced by a longer password.
   This is quite different from the widely known usage of salt, e.g. in 
UNIX operating system, salt is not required to remember by the user, but 
by server to fetch locally by reference to the username. 
  And as far as I know, I am sure the authors also know that, other 
password based key exchanges protocols don't involve salt, but store a 
hash value of password among other things locally.
2. From the figure in the PPT shown at the meeting, I cann't see why the 
protocol should use both "private" and "mask" values, in my opinion, only 
"mask " value shall be OK.
   private value is redundent, and not helpful in security improvement.
   because the current derived shared key is PE^{private_a*private_b} 
according to this document, and
   after removing private value, it will be  PE^{mask_a*mask_b}
   and private, mask value are both generated locally and not transported 
on the wire, so it does not make much difference except making it more 
complex.
3. Now I only talk about the security of the simplified version (as in 
above point 2)
   after simplification the protocol is easier to analysize, it is just 
like an ordinary DH exchange except that the base group generator is PE 
instead of g.
   So the security is reduced to the PE, is it a good group generator 
which has large order? if not then it is insecure.
   Unfortunatly the authors failed to analysize this crucial point.

Thank you for your patience!

Sujing Zhou 
 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.