Internet DRAFT - draft-huang-tls-ibe
draft-huang-tls-ibe
Network Working Group M. Huang
Internet-Draft Huawei Symantec
Intended status: Informational July 3, 2009
Expires: January 4, 2010
Identity-Based Encryption (IBE) Cipher Suites for Transport Layer
Security (TLS)
draft-huang-tls-ibe-00
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 4, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Huang Expires January 4, 2010 [Page 1]
Internet-Draft IBE for TLS July 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document describes a new key exchange method, Identity-Based
Encryption (IBE) for the Transport Layer Security (TLS) protocol.
This memo specifies an alternative method for transmitting premaster
secret securely between the client and server in a TLS handshake
process. Some new cipher suites are thus introduced into TLS
protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. IBE Overview . . . . . . . . . . . . . . . . . . . . . . . 4
2. Using Identity-Based Encryption . . . . . . . . . . . . . . . 5
2.1. Key-exchange Method . . . . . . . . . . . . . . . . . . . 5
2.2. Client and Server Authentication . . . . . . . . . . . . . 5
3. TLS Extension for IBE . . . . . . . . . . . . . . . . . . . . 5
4. Data Structures and Computations . . . . . . . . . . . . . . . 6
4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. IBE Parameters Extension . . . . . . . . . . . . . . . 7
4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 11
4.4. Server Key Exchange . . . . . . . . . . . . . . . . . . . 11
4.5. Certificate Request . . . . . . . . . . . . . . . . . . . 11
4.6. Client Certificate . . . . . . . . . . . . . . . . . . . . 12
4.7. Client Key Exchange . . . . . . . . . . . . . . . . . . . 12
4.8. Certificate Verify . . . . . . . . . . . . . . . . . . . . 13
5. Cipher suites . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Huang Expires January 4, 2010 [Page 2]
Internet-Draft IBE for TLS July 2009
1. Introduction
In Public Key Infrastructure (PKI) system, the Certification
Authorities (CAs) are deployed in a hierarchical mode. Users who
want to validate a certificate signed by one CA must validate the
identity of the CA which signed it firstly. Completing the
validation of one CA depends on the validation of CAs higher than it
in this hierarchical architecture till the root CA is trusted by the
user. In this procedure, user must get all certificates of CAs
involved in this authority chain and make requests for Certificate
Revocation Lists (CRLs) to check if the certificates are still valid.
Sometimes it may be involved in cross authentication among different
CAs. Users may consume significant time for this processing.
Besides, it is an overburden to maintain and issue certificates and
CRLs.
In Identity-based Encryption (IBE) system, one user can use one of
the other user's public information as its public key rather than its
public key in certificate, such as email address, IP address, domain
name, etc. A sender can encrypt the message with the receiver's
public key without retrieving its certificate. The receiver can
acquire its corresponding private key from the trusted third party
Public Key Generator (PKG) and decrypt the message received from the
sender. Thus in IBE system, users need not to spend time on
retrieving and validating certificates. In some specific
circumstances, it provides a more suitable and convenient method than
PKI does.
In current actual application of TLS, most users would like to ignore
the failure alert of certificate verification that pop up from their
browsers and continue to complete the connections to these HTTPS
websites. This neglect can be utilized by attackers to masquerade
websites using the forged certificates. In IBE-based system, there
is no need to verify the receiver's public key for users. Because
the identity information used as the public key is well-known and
user authentication relies on the authentication performed by PKG.
Therefore, the risks brought by user's neglect will be eliminated.
In P2P applications environment, it is impossible that all users have
their certificates used for authentication in TLS. So it is more
convenient using IBE-based mechanism than PKI relied mechanism when
using TLS to protect data transmission, especially users can use each
other's ID (e.g., email address, IP address, user ID, etc) as the
public key to do encryption.
This document describes additions to TLS to support IBE, applicable
both to TLS Version 1.2 [TLS1.2] and its successors. In particular,
it defines:
Huang Expires January 4, 2010 [Page 3]
Internet-Draft IBE for TLS July 2009
o A key exchange method using the public information as the public
key of the receiver. Client encrypts the premaster secret with
the public key of the server. The server decrypts it with the
corresponding private key retrieved from PKG.
o An authentication method allowing the users to compute digital
signatures using their private keys from the PKG. Each side can
validate the signature with the public key of the other side. It
can support both server authentication and client authentication.
Implementation of this specification requires familiarity with
TLS[TLS1.0][TLS1.1][TLS1.2], and IBE[IBE][IBCS].
1.1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [KEYWORDS].
1.2. IBE Overview
RFC 5408[IBE] describes an IBE-based messaging system and defines the
components of such a system. The server components required for such
a system are the following:
o A Public Parameter Server (PPS):IBE public parameters include
publicly-sharable cryptographic material, known as IBE public
parameters, and policy information for an associated PKG. A PPS
provides a well-known location for secure distribution of IBE
public parameters and policy information that describe the
operation of a PKG.
o A Private-key Generator (PKG):The PKG stores and uses
cryptographic material, known as a master secret, which is used
for generating a user's IBE private key. A PKG accepts an IBE
user's private key request, and after successfully authenticating
them in some way, returns their IBE private key.
The procedures of getting public parameters from PPS and private key
from PKG are described in [IBE]. Users MUST verify the PPS using the
server certificate and the PKG MUST verify the users who request
private keys using their authentication credentials. This provides
confidentiality and integrity of the information transmitted from the
servers (PPS and PKG) to users and appropriate authentication of the
servers (PPS and PKG) and users.
Huang Expires January 4, 2010 [Page 4]
Internet-Draft IBE for TLS July 2009
2. Using Identity-Based Encryption
IBE is a public-key technology for encrypting content-encryption keys
(CEKs). Within the IBE system the receiver's identity (ID) is used
as a public key. This document does not describe the implementation
of the Boneh-Franklin (BF) and Boneh-Boyen (BB1) algorithms, which
are described in detail in [IBCS].
2.1. Key-exchange Method
In this memo, a new key-exchange method is introduced. All of the
key exchange methods which transmit encrypted premaster secret using
public-key encryption can be replaced by the method based on IBE
public-key encryption mechanism. The derivation of the TLS master
secret from the premaster secret and the subsequent generation of
bulk encryption/MAC keys and initialization vectors is independent of
and not impacted by the introduction of IBE.
2.2. Client and Server Authentication
Server authentication in TLS handshake process which has negotiated
IBE cipher suites depends on the server authentication performed by
the PKG. In IBE-based system, an entity makes requests for its
private key corresponding to certain identity information used as a
public key from the PKG. PKG MUST authenticate the requesting entity
to make sure it is the entity who claimed to be. Thus, if the
encrypted premaster secret is decrypted successfully by the server,
it means that the server is successfully authenticated by the PKG and
obtains its private key successfully. Just like in PKI-based system,
clients trust the identity of the server claimed depending on clients
trust the CAs which issued the certificate. In IBE-based system,
client trusts the PKG, so it trusts the server which has been
validated by that PKG.
In the same way, server authenticates the client using IBE-based
mechanism depending on the PKG who generates and transmits the
private key for the client who has been authenticated successfully.
3. TLS Extension for IBE
A new TLS extension is defined in this specification, IBE parameters
extension. Client and server can negotiate appropriate information
when they decide to use an IBE-based cipher suite using this
extension.
This extension is used to negotiate the use of specific set of public
parameters in specific district and thus the use of specific
algorithm supported by each side when negotiating a new session.
Huang Expires January 4, 2010 [Page 5]
Internet-Draft IBE for TLS July 2009
The client may be configured several trusted PPSs and obtain several
sets of public parameters issued by different PPSs. Each set of
public parameters contains several algorithms supported by the PKG.
So the client and server SHOULD negotiate the use of specific set of
public parameters. The client enumerates the sets of public
parameters by including an IBE parameters extension in its
ClientHello message. The server MUST choose one set by including an
IBE parameters extension in its ServerHello message when using IBE-
based cipher suite.
The client may have certain identities (ClientIDs) used as its public
keys. So if the server wants to authenticate the client using IBE-
based mechanism, it SHOULD choose one clientID used to verify the
identity of the client.
The client may know certain server's identities (ServerIDs) which can
be used as the server's public key. The client will list all the
server's IDs it knew in the IBE parameters extension and the server
MUST select or appoint one ID as its public key.
The client MUST NOT include this extension in the ClientHello message
if it does not propose any IBE cipher suites. In the case of session
resumption, the server simply ignores the IBE parameters extension in
the current ClientHello message. This extension only plays a role
during handshakes negotiating a new session.
4. Data Structures and Computations
This section specifies the data structures and computations used by
IBE key-exchange and authentication mechanism. The presentation
language used here is the same as that used in TLS specification.
This memo extends TLS specification, these descriptions should be
merged with those in the TLS specification and any others that extend
TLS. This means that certain structures may not indicate all
possible cases.
4.1. Client Hello
When this message is sent:
This message is sent as the first message when a client sets up a TLS
connection with a server. The client can also send this message as a
response to a HelloRequest or on its own initiative in order to
renegotiate the security parameters in an existing connection.
Structure of this message:
The structure of this message is the same as that defined in TLS
Huang Expires January 4, 2010 [Page 6]
Internet-Draft IBE for TLS July 2009
specification. If the client confirms that it supports IBE-based
mechanism, the cipher suites proposed in this message may contain IBE
cipher suites. If there are IBE cipher suites provided, the IBE
parameters extension specified in 4.1.1 MUST be contained in this
message.
Actions of the sender:
A client that proposes IBE cipher suites in its ClientHello message
appends the IBE parameters extension (along with any others) to this
message. The client MUST send the IBE parameters extension if it
supports IBE and proposes IBE cipher suites.
Actions of the receiver:
A server that receives a ClientHello message containing an IBE
parameters extension MUST select one of the enumerated sets of public
parameters contained in the ClientHello message if it selects an IBE
cipher suite. This selected set of the proposed public parameters
MUST contain the algorithm it supported.
If the server does not understand the IBE parameters extension, or is
unable to complete the IBE handshake while restricting itself to the
enumerated sets of public parameters, it MUST NOT negotiate the use
of an IBE cipher suite. Depending on what other cipher suites are
proposed by the client and supported by the server, this may result
in a fatal handshake failure alert due to the lack of common cipher
suites.
4.1.1. IBE Parameters Extension
This section specifies a new TLS extension that can be included in
the ClientHello message as described in [TLS1.2]. This extension
allows a client to enumerate the sets of public parameters and the
IDs of the server and itself which can be used as their public keys.
The general structure of TLS extensions is described in [TLS1.2], and
this specification adds a new type to ExtensionType defined as
follows:
enum {
ibe_parameters(TBD), (65535)
} ExtensionType;
ibe_parameters: extensions of this type are used to negotiate the set
of public parameters and IDs used in the IBE key exchange method and
IBE authentication.
Huang Expires January 4, 2010 [Page 7]
Internet-Draft IBE for TLS July 2009
The "extension_data" field of this extension is IBEParameters
structure, which contains at least one set of public parameters
retrieved from one PPS. The specific content of IBEParameters is
defined as follows:
struct {
PublicParamsSet public_params_sets;
IDInfo server_id_list;
IDInfo client_id_list;
} IBEParameters;
The items within public_params_sets are ordered according to the
client's preferences (favorite choice first). The specific public
parameters contained in one public parameters set are defined as
follows:
struct {
opaque district_name<1..2^8-1>;
uint16 district_serial;
ValidityPeriod validity_period;
AlgorithmInfo algorithm_info;
opaque ibe_identity_type<1..2^8-1>;
ParamExtension param_extension_list;
} PublicParamsSet;
(1) The district_name field is a string of an URI or IRI of PPS/PKG.
(2) The district_serial field is an integer that indicates a unique
set of IBE public parameters which is available at the URI or IRI
specified by the district_name.
(3) The validity_period field is a structure which defines the period
of validity of a specific set of public parameters. It is defined as
follows:
struct {
opaque not_before[16];
opaque not_after[16];
}ValidityPeriod;
The values of not_before and not_after fields MUST be expressed in
Greenwich Mean Time (Zulu). Times are always expressed by the form
of YYYYMMDDHHMMSSZ.
The client SHOULD send the sets of public parameters falling between
the not_before time and the not_after time. The server MUST NOT
select the public parameters set if it does not.
Huang Expires January 4, 2010 [Page 8]
Internet-Draft IBE for TLS July 2009
(4) The algorithm_info field is a structure containing public
parameters that correspond to IBE algorithm which both the PKG and
the client support. The structure is defined as follows:
struct {
opaque ibe_algorithm_OID<1..2^16-1>;
opaque public_parameter_data<1..2^16-1>;
}AlgorithmInfo;
The ibe_algorithm_OID specifies an IBE algorithm. The OIDs for two
IBE algorithms (the Boneh-Franklin and Boneh-Boyen algorithms) and
their public_parameter_data structures are defined in [IBCS].
The public_parameter_data contains the actual cryptographic
parameters depending on the specific algorithm.
The algorithm_info field MUST contain an OID that identifies one
algorithm and MAY contain OIDs that identify more than one algorithm
supported by the client. The server MUST select one algorithm it
supports and prefers to use.
(5) The ibe_identity_type field specifies an OID which defines the
format used to encode the information that defines the identity of
the user. The OID and the required and optional fields for each OID
are application dependent. An example of it is given in [IBECMS],
which defines the cmsIdentityOID to indicate that identity
information contains an EmailIdentityData type.
(6) The param_extension_list field is a list of additional parameters
which particular implementations may require. The structure of
ParamExtension is defined as follows:
struct {
opaque ibeParamExtensionOID<0..2^16-1>;
opaque ibeParamExtensionValue<0..2^16-1>;
} ParamExtension;
ibeParamExtensionOID specifies the type of an IBE parameter
extension. ibeParamExtensionValue is the content of specific
extension type specified by the extension OID.
Items in server_id_list are strings that can be used as the public
keys of server. The server chooses one ID from this list contained
in the ClientHello message or appoints a new ID which is not
contained in this list. The structure of IDInfo is defined as
follows:
Huang Expires January 4, 2010 [Page 9]
Internet-Draft IBE for TLS July 2009
struct {
opaque id_info<1..2^8-1>;
}IDInfo;
It is RECOMMENDED that the client and the server use the well-known
and unique in certain community identities as their public keys, e.g.
the server's domain name.
The client_id_list field is a list of client identities that can be
used as or be used to compute the public key of client. The server
can select one of the client IDs as the client's public key according
to the configured policies. The selected ID can then be used to
verify the client's signature sent in the client's CertificateVerify
message. The value of the IDInfo can be an IP address, a domain
name, an email address, a phone number or a host name, etc.
The detailed description of public parameters and how to obtain them
from PPS/PKG can be seen in [IBE].
4.2. Server Hello
When this message is sent:
This message is sent in response to a ClientHello message when the
server select an acceptalbe set of algorithms.
Meaning of this message:
This message allows a server to choose one cipher suite. If the
server confirms that it supports IBE and then selects an IBE cipher
suite, it needs to decide which set of IBE public parameters provided
by the client in its IBE parameters extension to be used in IBE key
exchange mechanism.
Structure of this message:
The server's IBE parameters extension has the same structure as the
client's IBE parameters extension, see section 4.1.1. Here extension
data has one item in public_params_sets it chooses, one item in
server_id_list it chooses or appoints and one item in client_id_list.
If there is no ServerID listed in the client's extension, the server
MUST appoint one ServerID in the its IBE parameters extension.
Actions of the sender:
The server informs the client of the selected set of public
parameters used in IBE key exchange, a server ID used as the public
key of the server and a client ID used as the public key of the
Huang Expires January 4, 2010 [Page 10]
Internet-Draft IBE for TLS July 2009
client via appending an IBE parameters extension to this message.
Actions of the receiver:
The client that receives a ServerHello message containing an IBE
parameters extension MUST respect the server's choice of public
parameters set. If there is no IBE parameters extension within the
ServerHello message, this may result in a fatal handshake failure
alert due to the failure of the negotiation.
4.3. Server Certificate
When this message is sent:
This message is sent in all IBE-based key exchange methods after the
ServerHello message.
Structure of this message:
The content of this message is empty when an IBE cipher suite is
selected. The specific content of this message is defined in future
if there are some new circumstances.
4.4. Server Key Exchange
This message is not sent when using IBE cipher suites. The premaster
key is encrypted and sent in client key exchange message. The server
needs to acquire its private key to decrypt out the premaster key.
So there is no need to send server key exchange message.
4.5. Certificate Request
When this message is sent:
This message is sent when the server requests client authentication.
Meaning of this message:
The server uses this message to suggest acceptable client
authentication methods, e.g.IBE-based authentication mechanism.
Structure of this message:
The structure of this message is the same as structure defined in TLS
specification.
When the server requires IBE-based authentication mechanism, the
client certificate type is IBE. The signature and hash algorithms
Huang Expires January 4, 2010 [Page 11]
Internet-Draft IBE for TLS July 2009
listed in supported_signature_algorithms MUST be an IBE signature
mechanism and the appropriate hash algorithms. The
certificate_authorities field is a list of the URIs or IRIs of
acceptable PPSs/PKGs from which the client can choose one to acquire
its private key used in signature. A new ClientCertificateType is
defined as follows:
enum {
IBE(TBD), (255)
} ClientCertificateType;
Actions of the sender:
The server decides which client authentication methods it would like
to use, and conveys this information to the client using the format
defined above or in the TLS specification.
Actions of the receiver:
The client determines whether it has required and suitable
information for use with any of the requested methods and whether to
proceed with client authentication.
4.6. Client Certificate
When this message is sent:
This message is sent in response to a CertificateRequest message.
Structure of this message:
The content of this message is empty when the server wants to
authenticate the client using IBE-based mechanism. The specific
content of this message is defined in future if there are some new
circumstances.
4.7. Client Key Exchange
When this message is sent:
This message is sent when using certain key exchange methods which
require the client to transmit the premaster key to the server. This
message MUST be sent immediately after the client certificate
message.
Structure of this message:
This message conveys the encrypted premaster key to the server. The
Huang Expires January 4, 2010 [Page 12]
Internet-Draft IBE for TLS July 2009
structure is defined as follows:
enum { ibe
} KeyExchangeAlgorithm; /*just list the extending one*/
struct {
select (KeyExchangeAlgorithm) {
case ibe:
EncryptedPreMasterSecret;
} exchange_keys;
} ClientKeyExchange;
Actions of the sender:
The client generates a 48-byte premaster secret, encrypts it with the
public key of the server, and sends the result in this message.
Actions of the receiver:
The server receives the encrypted premaster secret contained in this
message and decrypts out the premaster secret with its private key
acquired from PKG in advance and the selected set of public
parameters.
4.8. Certificate Verify
When this message is sent:
This message is sent after receiving the server's CertificateRequest
message and immediately follow the ClientKeyExchange message.
Meaning of this message:
This message contains the signature information that proves
possession of the private key corresponding to the client's public
key.
Structure of this message:
The structure of this message is the same as that defined in
[TLS1.2].
Actions of the sender:
The client computes its signature over all handshake messages sent or
received starting at client hello and up to but not including this
message. The private key used is acquired from the PKG specified in
the CertificateRequest message.
Huang Expires January 4, 2010 [Page 13]
Internet-Draft IBE for TLS July 2009
Actions of the receiver:
The server extracts the client's signature information from the
CertificateVerify message and verifies it using the clientID selected
by the server in its IBE parameters extension.
5. Cipher suites
The following defines new IBE cipher suites that use the IBE-based
key exchange algorithm.
CipherSuite TLS_IBE_WITH_NULL_MD5
CipherSuite TLS_IBE_WITH_NULL_SHA
CipherSuite TLS_IBE_WITH_NULL_SHA256
CipherSuite TLS_IBE_WITH_RC4_128_MD5
CipherSuite TLS_IBE_WITH_RC4_128_SHA
CipherSuite TLS_IBE_WITH_3DES_EDE_CBC_SHA
CipherSuite TLS_IBE_WITH_AES_128_CBC_SHA
CipherSuite TLS_IBE_WITH_AES_256_CBC_SHA
CipherSuite TLS_IBE_WITH_AES_128_CBC_SHA256
CipherSuite TLS_IBE_WITH_AES_256_CBC_SHA256
Table 1: TLS IBE cipher suites
6. Security Considerations
This document is based on [IBCS] and [IBE], and the relevant security
considerations of those documents apply. Security discussions
specific to IBE, especially masquerading as legitimate PPS/PKG and
DoS attack on PPS/PKG can be found in these documents.
Sizes of BF and BB1 algorithm parameters required achieving standard
levels of bit security. Their usage scenarios are described in
[IBCS]. We assume that the server will be properly configured to
select parameters that provide a sufficient strength required.
Within this document the distribution of the private key is the most
important issue to be considered. The client and the server can
obtain their private key from the PKG through security physical
approaches or security communication channel built between the user
and the PKG.
The security strength of the TLS using IBE cipher suites described in
this document relies on the strength of the mechanism used to
authenticate a user requesting a private key from a PKG. A weak
mechanism used to authenticate users will result in a weak TLS
process relies on the technology. It is required that the
Huang Expires January 4, 2010 [Page 14]
Internet-Draft IBE for TLS July 2009
authentication mechanism used by PKG must be suitably strong.
7. IANA Considerations
IANA is requested to assign:
1. a new ExtensionType value for ibe_parameters in the TLS
ExtensionType Registry maintained at http://www.iana.org/
assignments/tls-extensiontype-values/
tls-extensiontype-values.xhtml.
2. a new ClientCertificateType identifier for IBE_authentication in
the TLS ClientCertificateType Identifiers Registry maintained at
http://www.iana.org/assignments/tls-parameters/
tls-parameters.xhtml.
3. create ten entries in the TLS Cipher Suite Registry maintained at
http://www.iana.org/assignments/tls-parameters/
tls-parameters.xhtml. The new cipher suites are listed in
section 5.
8. Normative References
[IBCS] Boyen, X. and L. Martin, "Identity-Based Cryptography
Standard (IBCS) #1: Supersingular Curve Implementations
of the BF and BB1 Cryptosystems", RFC 5091,
December 2007.
[IBE] Appenzeller, G., Martin, L., and M. Schertler, "Identity-
Based Encryption Architecture and Supporting Data
Structures", RFC 5408, January 2009.
[IBECMS] Martin, L. and M. Schertler, "Identity-Based Encryption
Architecture and Supporting Data Structures", RFC 5409,
January 2009.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 4346, April 2006.
[TLS1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
Huang Expires January 4, 2010 [Page 15]
Internet-Draft IBE for TLS July 2009
Author's Address
Min Huang
Huawei Symantec Technologies Co.,Ltd.
Keshi Building
No.28,Xinxi Road
HaiDian District
Beijing 100085
China
EMail: huangmin@huaweisymantec.com
URI: http://www.huaweisymantec.com
Huang Expires January 4, 2010 [Page 16]
