Re: [TLS] User Defined Key Pair

"OMAR HASSAN (RIT Student)" <omh1835@rit.edu> Mon, 24 June 2013 16:26 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 D807321E8127 for <tls@ietfa.amsl.com>; Mon, 24 Jun 2013 09:26:04 -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 UikluPSu10Mb for <tls@ietfa.amsl.com>; Mon, 24 Jun 2013 09:25:59 -0700 (PDT)
Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id CC66021E8123 for <tls@ietf.org>; Mon, 24 Jun 2013 09:25:58 -0700 (PDT)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOW00AOZOB8BN@smtp-server.rit.edu> for tls@ietf.org; Mon, 24 Jun 2013 12:25:57 -0400 (EDT)
Received: by mail-ie0-f179.google.com with SMTP id c10so25529077ieb.10 for <tls@ietf.org>; Mon, 24 Jun 2013 09:25:56 -0700 (PDT)
Received: by 10.43.115.3 with HTTP; Mon, 24 Jun 2013 09:25:56 -0700 (PDT)
X-Received: by 10.43.139.5 with SMTP id iu5mr8617995icc.107.1372091156819; Mon, 24 Jun 2013 09:25:56 -0700 (PDT)
X-Received: by 10.43.139.5 with SMTP id iu5mr8617989icc.107.1372091156722; Mon, 24 Jun 2013 09:25:56 -0700 (PDT)
Date: Mon, 24 Jun 2013 19:25:56 +0300
From: "OMAR HASSAN (RIT Student)" <omh1835@rit.edu>
In-reply-to: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com>
Sender: omh1835@rit.edu
To: "Salz, Rich" <rsalz@akamai.com>
Message-id: <CALxQUYGpcKPOAoZ8J56AoUGx8B3JhdmMche8MdQuqD_S=Y22ZQ@mail.gmail.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="001a11c2e9b8fefe6004dfe8dd21"
X-RIT-Received-From: 209.85.223.179
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=uj/dtIZ5Ake7ArQ7W+G8uOkO8Mcx3R8n9ut/p0cyiVE=; b=Pni530q6FAjErzRI25NZF8ZtxU5/aYb4poiZr32Y9+n/Ixb8YmtcQfRvRBN5A0lnDf by0UVoMeUcQLb1Nv2hGqMe7MXnZw5MzdrkJ1p/AsRKdcUFYxm2uAXp4gYW5wYTJN/A3Z CdG4Q688ekFcc8iaO4bK4hvVa98eYxaf+36wM6hmZFT6lSucX/jPEVz+RFWCY4aWBCdc DsLbwlI1ad2F6D81yLOvkXZ6CQt4Wz5qUe6iqUrnXcclS0/1Gb0BLlKSxGbtZxwlxxG2 HTLC4/pFmwuTqEn5fw103g3MNWNFB0rO2gni53nBYuj8zwlCitxy6Dcga2RQMW0lAOOk APyQ==
X-Google-Sender-Auth: E5Ms8AED0mmB6iw7ybyI_FdS8hc
X-Gm-Message-State: ALoCoQkKLIefBVbD1E43FjSbV0FeUcdQmu9rSlYct3sV3wte2D/3dOXIsWMMrT5inLIMn8LGmLWvbSrypCHD+5Pnl0giSrD3et6Fk+lYPFWG9c5/nD6UVoXH58s2ByTOQNCWmbNws/ga
References: <CALxQUYGdagDHr+A4EKN5qPD1jZG+dH8PHwb0-fKJVUN_vC1MSg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com>
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: Mon, 24 Jun 2013 16:26:05 -0000

Hi Rich,

The idea is to separate the generation of the key pair of the server, so
the server will be expecting your public key during the enrollment, and a
message singed by your private key during the sign in.

On the browser level there should be a plugin that has a function to
generate the key pair, that function must generate the same key pair for
the same input parameters.

I didn't include any mathematics details for that function as I was
interesting in abstracting the idea, and for the real implementation there
must be unified implementation across all browsers to generate the same key
pair for the same input parameters in all browsers.

There should be three version of the generate key function as the following:

1) genKeyPair (username, password, security question&answer);
So whenever you provide the same username, password, and the security
question&answer, the same key pair will be generated for you.

2) genKeyPair (username, password, file);
So whenever you provide the same username, password, and the same file from
a usb or hard drive, the same key pair will be generated for you.

3) genKeyPair (username, password, smart card or hardware token);
So whenever you plugin the hardware token or put your smart card, and
provide the same username and password, the same key pair will be generated
for you.

In my prof of concept implementation, I used a standard java method that
will generate the same key pair for the same input string, and I provided a
concatenation of the username, password, and security question&answer.


On Mon, Jun 24, 2013 at 6:29 PM, Salz, Rich <rsalz@akamai.com> wrote:

> I didn’t see any description of your genKeyPair function; is it described
> anywhere?  In particular, it seems to me that it’s stateless – that is, it
> generates the keypair whenever needed, based only on the username,
> password, and a security question&answer.  Is that true?****
>
>                 /r$****
>
> ** **
>
> --  ****
>
> Principal Security Engineer****
>
> Akamai Technology****
>
> Cambridge, MA****
>
> ** **
>