[saag] IBAKE draft: draft-cakulev-ibake-00

"Cakulev, Violeta (Violeta)" <violeta.cakulev@alcatel-lucent.com> Tue, 08 December 2009 18:51 UTC

Return-Path: <violeta.cakulev@alcatel-lucent.com>
X-Original-To: saag@core3.amsl.com
Delivered-To: saag@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C7C3A6923 for <saag@core3.amsl.com>; Tue, 8 Dec 2009 10:51:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 VVgYGTQZaXRB for <saag@core3.amsl.com>; Tue, 8 Dec 2009 10:51:06 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 426963A6841 for <saag@ietf.org>; Tue, 8 Dec 2009 10:51:05 -0800 (PST)
Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id nB8IooXx024196 for <saag@ietf.org>; Tue, 8 Dec 2009 12:50:50 -0600 (CST)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id nB8IooPY000231 for <saag@ietf.org>; Tue, 8 Dec 2009 12:50:50 -0600 (CST)
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 8 Dec 2009 12:50:50 -0600
From: "Cakulev, Violeta (Violeta)" <violeta.cakulev@alcatel-lucent.com>
To: "saag@ietf.org" <saag@ietf.org>
Date: Tue, 08 Dec 2009 12:50:48 -0600
Thread-Topic: IBAKE draft: draft-cakulev-ibake-00
Thread-Index: AcpQ90ZMB2bkchhlS4m7hUAhPgwdLgnMEDjg
Message-ID: <AAE76B481E7A0E4C96610790A852B9A624EF33A198@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Subject: [saag] IBAKE draft: draft-cakulev-ibake-00
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/saag>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2009 18:51:12 -0000

Following our IBAKE presentation at the IETF75 SAAG
meeting (http://www.ietf.org/proceedings/75/slides/saag-1/saag-1_files/frame.htm),
we have written a draft specifying IBAKE.

Below is the link to the draft.
http://www.ietf.org/id/draft-cakulev-ibake-00.txt

Comments and questions are welcome.

Thanks,
-Violeta



-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: Monday, October 19, 2009 4:04 PM
To: Cakulev, Violeta (Violeta)
Cc: Sundaram, Ganapathy S (Ganesh)
Subject: New Version Notification for draft-cakulev-ibake-00


A new version of I-D, draft-cakulev-ibake-00.txt has been successfuly submitted by Violeta Cakulev and posted to the IETF repository.

Filename:        draft-cakulev-ibake
Revision:        00
Title:           IBAKE: Identity-Based Authenticated Key Agreement
Creation_date:   2009-10-19
WG ID:           Independent Submission
Number_of_pages: 16

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.



The IETF Secretariat.