[Cfrg] ISE seeks comments on: draft-cakulev-ibake-02.txt

Nevil Brownlee <n.brownlee@auckland.ac.nz> Tue, 05 October 2010 01:08 UTC

Return-Path: <n.brownlee@auckland.ac.nz>
X-Original-To: cfrg@core3.amsl.com
Delivered-To: cfrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B703A6D77 for <cfrg@core3.amsl.com>; Mon, 4 Oct 2010 18:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.92
X-Spam-Level:
X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.679, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B09uQGpsxr2k for <cfrg@core3.amsl.com>; Mon, 4 Oct 2010 18:08:26 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id B38C33A6EC8 for <cfrg@irtf.org>; Mon, 4 Oct 2010 18:08:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=n.brownlee@auckland.ac.nz; q=dns/txt; s=uoa; t=1286240963; x=1317776963; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; z=Message-ID:=20<4CAA7ABA.6020904@auckland.ac.nz>|Date:=20 Tue,=2005=20Oct=202010=2014:09:14=20+1300|From:=20Nevil =20Brownlee=20<n.brownlee@auckland.ac.nz>|MIME-Version: =201.0|To:=20cfrg@irtf.org|CC:=20ISE=20<rfc-ise@rfc-edito r.org>|Subject:=20ISE=20seeks=20comments=20on:=20=20draft -cakulev-ibake-02.txt|Content-Transfer-Encoding:=207bit; bh=B04knvvzHJa5vcaREQhh+ydWCAZJrkXnAiIMx0wJbpk=; b=c3a3R/F0WWhR1XvJGiiseI6pkiJDsqdh+Pqke150VUFDf8vsz7Jnso1C Q+fb/YW05XydqLDO0mVz37KjBnkSZWCUE52m//rDpPQe+v20nqugyzDY/ jfDnenWh3rXBm/aNwgk8jfWhsSugBpsG0GrulP/GYkBO7Ldr1ChnTJVhG Q=;
X-IronPort-AV: E=Sophos;i="4.57,281,1283688000"; d="scan'208";a="29700417"
X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE
X-Ironport-Source: 130.216.38.131 - Outgoing - Outgoing-SSL
Received: from nevil-laptop1.sfac.auckland.ac.nz (HELO [130.216.38.131]) ([130.216.38.131]) by mx2-int.auckland.ac.nz with ESMTP; 05 Oct 2010 14:09:15 +1300
Message-ID: <4CAA7ABA.6020904@auckland.ac.nz>
Date: Tue, 05 Oct 2010 14:09:14 +1300
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: cfrg@irtf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ISE <rfc-ise@rfc-editor.org>
Subject: [Cfrg] ISE seeks comments on: draft-cakulev-ibake-02.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Oct 2010 01:08:28 -0000

Hi CFRG folk:

Violeta Cakulev has submitted this draft to me as an Independent
Submission to the RFC Editor.  Jim Schaad suggested I should ask
for your comments, so ... here's its abstract:

   "Cryptographic protocols based on public key methods are based on
    certificates and large scale public key infrastructure (PKI) to
    support certificate management.  The emerging field of Identity Based
    Encryption protocols allows to simplify the infrastructure
    requirements via a Key Generation Function (KGF) while providing the
    same flexibility.  However one significant limitation of Identity
    Based Encryption methods is that the KGF can end up being a de-facto
    key escrow server with undesirable consequences.  Another observed
    deficiency is a lack of mutual authentication of communicating
    parties.  Here, Identity Based Authenticated Key Exchange (IBAKE)
    Protocol is specified which does not suffer from the key escrow
    problem and in addition provides mutual authentication and a perfect
    forward and backwards secrecy."

Please note that this draft has an IPR statement.

I'd appreciate any comments you care to make about it.

Thanks, Nevil Brownlee (Independent Submissions Editor)

-- 
---------------------------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand