Internet DRAFT - draft-chudov-cryptopro-tlsprfneg
draft-chudov-cryptopro-tlsprfneg
TLS Working Group Grigorij Chudov
Internet Draft CRYPTO-PRO
Expires November 25, 2005 May 25, 2005
Intended Category: Standards Track
Hash/PRF negotiation in TLS using TLS extensions.
<draft-chudov-cryptopro-tlsprfneg-00.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667.
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 in November 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document presents a method of negotiating some of the
algorithms, used by Transport Layer Security Protocol [TLS], which
are not chosen by cipher suite. Those algorithms are hash function
used for Finished message, and PRF function.
Chudov Informational [Page 1]
Internet-Draft Hash/PRF negotiation in TLS May 2005
This is done using TLS Extensions [TLSEXT] mechanism.
Table of Contents
1 Introduction. . . . . . . . . . . . . . . . . . . . . . . 2
2 Extension Type. . . . . . . . . . . . . . . . . . . . . . 2
3 Changes to the Message Contents . . . . . . . . . . . . . 3
3.1 Client Hello. . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Server Hello. . . . . . . . . . . . . . . . . . . . . . . 4
4 Cryptographic computations affected . . . . . . . . . . . 4
4.1 Finished message verify_data calculation. . . . . . . . . 5
4.2 Key calculation . . . . . . . . . . . . . . . . . . . . . 5
4.3 Computing the master secret . . . . . . . . . . . . . . . 5
5 Security Considerations . . . . . . . . . . . . . . . . . 5
6 References. . . . . . . . . . . . . . . . . . . . . . . . 5
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Addresses. . . . . . . . . . . . . . . . . . . . . . . 6
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 6
1 Introduction
[TLS] Handshake Protocol negotiates a cipher suite, that is used to
provide connection security. A cipher suite specifies key agreement
mechanism, symmetric encryption and MAC calculation, however it does
not affect the hash algorithm and PRF, which are used during
handshake.
However, some applications require different PRF or hash function.
For example, [PSK] (Pre-Shared Key Ciphersuites) have the following
problem with PRF, used by [TLS]: PRF assumes a long random secret,
which can be split in two independent parts, which usually not the
case for PSK. The second example are [GOST] algorithms, which require
a different hash-function.
This document is intended to register a new TLS extension, using
mechanism, defined in [TLSEXT]. The purpose of this extension is to
allow hash and PRF algorithm negotiation.
This document uses the same notation used in the [TLS] Protocol
specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
Chudov Informational [Page 2]
Internet-Draft Hash/PRF negotiation in TLS May 2005
this document are to be interpreted as described in [RFC 2119].
2 Extension Type
A new value, "prf_alg(9)", is added to the enumerated ExtensionType,
defined in [TLSEXT]. This value is used as the extension number for
the extensions in both the client hello message and the server hello
message. This new extension type will be used for hash and PRF
algorithm negotiation.
The client enumerates supported algorithm combinations by including
the appropriate extension in its ClientHello message. By echoing
that extension in its ServerHello, the server selects one of them for
this TLS connection. Section 3 describes the structure of this
extension in further details.
3 Changes to the Message Contents
This section describes the changes to the TLS handshake message
contents when prf_alg extension is present.
3.1 Client Hello
In order to indicate the support of alternative hash and PRF
algorithms clients will include an extension of type "prf_alg" in the
extended client hello message. The general extension mechanism is
described in [TLSEXT].
This extension carries a list of hash/PRF algorithm pairs client can
use. The opaque extension_data field contains DER-encoding of the
TLSExtensionPRFSelectClient sequence. Each TLSExtensionPRFSelect
sequence contains one supported algorithm combination.
TLSExtensionPRFSelect :: SEQUENCE {
hashAlgorithm AlgorithmIdentifier OPTIONAL,
prfAlgorithm AlgorithmIdentifier OPTIONAL
}
TLSExtensionPRFSelectClient :: SEQUENCE OF TLSExtensionPRFSelect
This extension MUST be omitted if the client only supports standard
[TLS] algorithms.
A client that wishes to indicate the support of standard [TLS]
algorithms along with alternative ones MUST include the empty
TLSExtensionPRFSelect sequence with both hashAlgorithm and
Chudov Informational [Page 3]
Internet-Draft Hash/PRF negotiation in TLS May 2005
prfAlgorithm fields omitted, indicating use of default algorithms
(PRF and MD5+SHA1).
Actions of the receiver:
A server that receives a ClientHello containing this extension MUST
use one of the proposed algorithm combinations. If a server is unable
to perform handshake using any of the proposed algorithm sets, it
MUST issue a fatal handshake_failure alert message.
3.2 Server Hello
In reply to an extended Client Hello message containing an extension
of type "prf_alg" server MUST send an extended Server Hello message,
containing the same extension. This extension indicates the server's
agreement to use during handshake one of the algorithm combinations
sent by the client.
When used in Server Hello, this extension carries a single hash/PRF
algorithm combination. The opaque extension_data field contains DER-
encoding of the TLSExtensionPRFSelectServer sequence.
TLSExtensionPRFSelectServer :: TLSExtensionPRFSelect
Actions of the receiver:
A client that receives a ServerHello with this extension makes sure
that server selected one of the algorithm sets, specified in the
corresponding ClientHello extension, and proceeds with a handshake
using the algorithms specified in it.
A client that receives a ServerHello without this extension MUST act
as if the standard [TLS] algorithms combination was specified by the
server.
If server specified combination which is not supported or allowed by
a client, it MUST issue a fatal handshake_failure alert message.
SecurityParameters structure from [TLS] is extended to hold a field
PRFSelect of type TLSExtensionPRFSelect.
SecurityParameters.PRFSelect is equal to the prf_alg extension from
Server Hello message.
Further in this document, PRF_EX stands for function, corresponding
to SecurityParameters.PRFSelect.prfAlgorithm, and HASH_EX stands for
function, corresponding to
SecurityParameters.PRFSelect.hashAlgorithm.
Chudov Informational [Page 4]
Internet-Draft Hash/PRF negotiation in TLS May 2005
If prfAlgorithm field is omitted from SecurityParameters.PRFSelect,
then PRF_EX equals PRF. If hashAlgorithm is omitted, HASH_EX(data)
equals MD5(data)+SHA1(data).
4. Cryptographic computations affected
This extension affects calculation of the following values:
Finished.verify_data, key_block and master_secret.
It does not affect calculations in Certificate Verify and
ServerKeyExchange messages. Hash that is used for signature in those
messages depends only on SignatureAlgorithm.
4.1 Finished message verify_data calculation
When prf_alg extension is present, PRF_EX is used instead of PRF, and
HASH_EX is used instead of MD5+SHA1.
Finished.verify_data = PRF_EX (master_secret, finished_label,
HASH_EX (handshake_messages))
[0..11];
4.2 Key calculation
When prf_alg extension is present, PRF_EX is used instead of PRF.
key_block = PRF_EX(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
4.3 Computing the master secret
When prf_alg extension is present, PRF_EX is used instead of PRF.
master_secret = PRF_EX(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
5 Security Considerations
Avoiding man-in-the-middle algorithm rollback:
When the server allows several hash/PRF algorithms, a man-in-the-
middle algorithm rollback becomes possible. That is, the attacker can
force the client and the server to use a weaker hash/PRF for
handshake, than that which they would normally choose.
Chudov Informational [Page 5]
Internet-Draft Hash/PRF negotiation in TLS May 2005
The server SHOULD only allow one hash/PRF pair to be used, to avoid
this attack.
6 References
[RFC 2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TLS] The TLS Protocol Version 1.0. T. Dierks, C. Allen.
January 1999, RFC 2246.
[TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.
and T. Wright, "Transport Layer Security (TLS) Exten-
sions", RFC 3546, June 2003.
[X.660] ITU-T Recommendation X.660 Information Technology - ASN.1
encoding rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER), 1997.
[PSK] P. Eronen, H. Tschofenig "Pre-Shared Key Ciphersuites for
Transport Layer Security", <draft-ietf-tls-psk-06.txt>,
work in progress.
[GOST] G. Chudov, S. Leontiev "GOST Ciphersuites for Transport
Layer Security", IETF draft, <draft-chudov-cryptopro-
cptls-02.txt>, work in progress.
Acknowledgments
The authors wish to thank:
Russ Hously (Vigil Security, LLC, housley@vigilsec.com) and
Vasilij Sakharov (DEMOS Co Ltd, svp@dol.ru) for initiative,
creating this document.
Author's Addresses
Grigorij Chudov
CRYPTO-PRO
38, Obraztsova,
Chudov Informational [Page 6]
Internet-Draft Hash/PRF negotiation in TLS May 2005
Moscow, 127018, Russian Federation
EMail: chudov@cryptopro.ru
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Chudov Informational [Page 7]
