Re: [TLS] User Defined Key Pair

"OMAR HASSAN (RIT Student)" <omh1835@rit.edu> Fri, 12 July 2013 11:37 UTC

Return-Path: <omh1835@g.rit.edu>
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 D0D8621F9D46 for <tls@ietfa.amsl.com>; Fri, 12 Jul 2013 04:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 eovoEDsw7m8i for <tls@ietfa.amsl.com>; Fri, 12 Jul 2013 04:37:28 -0700 (PDT)
Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id F262B21F9F83 for <tls@ietf.org>; Fri, 12 Jul 2013 04:37:27 -0700 (PDT)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MPT00FCTMYD7F@smtp-server.rit.edu> for tls@ietf.org; Fri, 12 Jul 2013 07:37:26 -0400 (EDT)
Received: by mail-ie0-f182.google.com with SMTP id s9so20353699iec.41 for <tls@ietf.org>; Fri, 12 Jul 2013 04:37:25 -0700 (PDT)
Received: by 10.42.232.200 with HTTP; Fri, 12 Jul 2013 04:37:25 -0700 (PDT)
X-Received: by 10.43.139.5 with SMTP id iu5mr12473575icc.107.1373629045805; Fri, 12 Jul 2013 04:37:25 -0700 (PDT)
X-Received: by 10.43.139.5 with SMTP id iu5mr12473572icc.107.1373629045713; Fri, 12 Jul 2013 04:37:25 -0700 (PDT)
Date: Fri, 12 Jul 2013 14:37:25 +0300
From: "OMAR HASSAN (RIT Student)" <omh1835@rit.edu>
In-reply-to: <7648a5048f19c6f255dbc0cc5d7772d5.squirrel@www.trepanning.net>
Sender: omh1835@rit.edu
To: Dan Harkins <dharkins@lounge.org>
Message-id: <CALxQUYETFnCS0BHQrtCR-O6K48P0q2KitExLTkC5PBjNuPMCtQ@mail.gmail.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary=001a11c2e9b852c29d04e14eefa5
X-RIT-Received-From: 209.85.223.182
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=2agZn8ny+R5sJGXlJGab6jwXxfRxUxwkDhpM9DAuyss=; b=Urmby77sErOG6v4SlJxf3AabODaPNlMknwNNJ7fa2Vs5uSHeXPyhH/0LyqG5G9WGai iNFTydCg5OBQoi0HzhffSxBDXv10PIidKsDJF+xogyI8yFYDlV/2jLswiX+ZhSVuEMcv +l3pfnC9r18VfkOFfnEE3yU+xUsuyOtIa7GY/BGZTy/qaDqW/JTdxCYV7GJF1RFpCAKN O1oCcMILuHDu92OoBDQSalAnWkPVATGIhoJ2FAXpSbxPTEbYhe3oK7+t3FHrYaumClck PPT/Xt1kehKwJrHrPtdgdygwyWC2t7D9kP3Y8ztpqdgvmgPmBv04BSLepaZ3x6h4+Jp5 1bNA==
X-Google-Sender-Auth: N1XPuTeUqc6DI-4PPZPSbD5kljU
X-Gm-Message-State: ALoCoQlLi8UXeoqDecTnfw6VgsKfRT3odj19HsxbCr6wDNTIYp6naXY3QBHuRww2xGVPBMH1zhCC3g3nq2hyEb1D9gicvKYnMn59hxhYMdkmT2ie4H+sELYgbfzaZH54XBo+OtG977YH
References: <CALxQUYGdagDHr+A4EKN5qPD1jZG+dH8PHwb0-fKJVUN_vC1MSg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <CALxQUYGpcKPOAoZ8J56AoUGx8B3JhdmMche8MdQuqD_S=Y22ZQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <CALxQUYF1=oFBk=WZFoey+28j7MV7YvSkAD-YzJSeQ0Dp7uXmEA@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> <CALxQUYFwZ8WyFDmCebvLyHoqsOGNBuCaEjiWhZPx0QyExWzcrw@mail.gmail.com> <7648a5048f19c6f255dbc0cc5d7772d5.squirrel@www.trepanning.net>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] User Defined Key Pair
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, 12 Jul 2013 11:37:32 -0000

Hi Dan,

I believe that your protocol will better suit for customized applications,
but when it comes to websites you will definitely face those issues that I
took about.



It's very common that a SQL injection attack against the website would give
the attacker the opportunity to steal database records, which will allow
the attacker to impersonate the client (I think TLS-SRP adds a little
complexity to protect against that scenario, I am sure you can improve this
part in your protocol)



Also TLS termination is very important, and must be supported by the
protocol, and the first challenge in that regard is that the load balancer
where the TLS connection should be terminated will not have access to the
server database, and I think without access to the server database you will
not be able to terminate the encrypted connection.



Regarding UDKP, I believe that the only valid attack against it is during
the registration. In that case using an initial TLS authenticated
connection will solve this issue, and for all later usages there is no need
to be dependent on certificate authorities.



In UDKP, if the server data has been stolen, the attacker will get only the
public key, and he will not be able to impersonate the client as he will
need the private key. And regarding TLS termination, the load balancer
could use the user public key to terminate the encrypted connection, and
the let the server authenticate the user. You can refer to section 5.2 in
the draft:

http://tools.ietf.org/html/draft-omar-tls-udkp-01#section-5.2

In the coming version of the draft I will put a detailed analysis for the
attack scenarios.


On Thu, Jul 11, 2013 at 6:22 PM, Dan Harkins <dharkins@lounge.org> wrote:

>
>   Hi Omar,
>
> On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote:
> > Hi Dan,
> >
> > I had a quick look at your work item, and I have some questions:
> >
> > What will be the consequences if the server data has be stolen? will the
> > attacker be able to impersonate as the user?
>
>   Successfully stealing records from the server's password file will
> enable the thief to impersonate the client (back to the hacked server)
> for all stolen records.
>
> > How will the password be stored in the server initially?
>
>   That is completely up to the server.
>
> > How will you handle TLS termination that is used many websites to
> > centralize the related measurements and protection against the common SSL
> > attacks in one place, and to allow the application firewalls to validate
> > and check the incoming requests for application-level attacks such as SQL
> > injection and cross-site scripting?
>
>   This is really an operational question. At the risk of sounding flippant
> I guess I'd just say it will be handled in the best way possible.
>
>   You claim in your draft that "UDKP aims to completely replace the TLS
> protocol." That is a much more ambitious goal and you will need to handle
> these sorts of issues. The tls-pwd draft just defines certificate-less
> ciphersuites that are resistant to dictionary attack (and are better than
> the various PSK ciphersuites) for use with the existing TLS protocol.
>
>   regards,
>
>   Dan.
>
> > Thanks
> >
> >
> >
> > On Wed, Jul 10, 2013 at 8:49 PM, Dan Harkins <dharkins@lounge.org>
> wrote:
> >
> >>
> >> On Mon, June 24, 2013 11:34 am, Salz, Rich wrote:
> >> [snip]
> >> > If you are trying to avoid CA's, then why not just use self-signed
> >> > certificates or similar like PGP?
> >>
> >>   Or why not use a protocol that is already a work item of the
> >> TLS working group:
> >>
> >>      http://tools.ietf.org/html/draft-ietf-tls-pwd-00
> >>
> >>   Dan.
> >>
> >>
> >>
> >>
> >
>
>