IBAKE: Identity-Based Authenticated Key Exchange
RFC 6539
|
| Document |
Type |
|
RFC - Informational
(March 2012; No errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
ISE
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
ISE state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 6539 (Informational)
|
|
Telechat date |
|
|
|
Responsible AD |
|
Sean Turner
|
|
Send notices to |
|
rfc-ise@rfc-editor.org
|
Independent Submission V. Cakulev
Request for Comments: 6539 G. Sundaram
Category: Informational I. Broustis
ISSN: 2070-1721 Alcatel Lucent
March 2012
IBAKE: Identity-Based Authenticated Key Exchange
Abstract
Cryptographic protocols based on public-key methods have been
traditionally based on certificates and Public Key Infrastructure
(PKI) to support certificate management. The emerging field of
Identity-Based Encryption (IBE) protocols allows simplification of
infrastructure requirements via a Private-Key Generator (PKG) while
providing the same flexibility. However, one significant limitation
of IBE methods is that the PKG 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. This
document specifies the Identity-Based Authenticated Key Exchange
(IBAKE) protocol. IBAKE does not suffer from the key escrow problem
and in addition provides mutual authentication as well as perfect
forward and backward secrecy.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6539.
Independent Submissions Editor Note
This document specifies the Identity-Based Authenticated Key Exchange
(IBAKE) protocol. Due to its specialized nature, this document
experienced limited review within the Internet Community. Readers of
this RFC should carefully evaluate its value for implementation and
deployment.
Cakulev, et al. Informational [Page 1]
RFC 6539 IBAKE March 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
2.1. IBE: Definition ............................................3
2.2. Abbreviations ..............................................3
2.3. Conventions ................................................4
3. Identity-Based Authenticated Key Exchange .......................5
3.1. Overview ...................................................5
3.2. IBAKE Message Exchange .....................................6
3.3. Discussion .................................................7
4. Security Considerations .........................................9
4.1. General ....................................................9
4.2. IBAKE Protocol ............................................10
5. References .....................................................12
5.1. Normative References ......................................12
5.2. Informative References ....................................12
1. Introduction
Authenticated key agreements are cryptographic protocols where two or
more participants authenticate each other and agree on key material
used for securing future communication. These protocols could be
symmetric key or asymmetric public-key protocols. Symmetric-key
protocols require an out-of-band security mechanism to bootstrap a
secret key. On the other hand, public-key protocols traditionally
require certificates and a large-scale Public Key Infrastructure
(PKI). Clearly, public-key methods are more flexible; however, the
requirement for certificates and a large-scale PKI have proved to be
challenging. In particular, efficient methods to support large-scale
certificate revocation and management have proved to be elusive.
Show full document text