7 Network Working Group U. Blumenthal
8 Request for Comments: 4785 P. Goel
9 Category: Standards Track Intel Corporation
13 Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for
14 Transport Layer Security (TLS)
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (C) The IETF Trust (2007).
31 This document specifies authentication-only ciphersuites (with no
32 encryption) for the Pre-Shared Key (PSK) based Transport Layer
33 Security (TLS) protocol. These ciphersuites are useful when
34 authentication and integrity protection is desired, but
35 confidentiality is not needed or not permitted.
39 1. Introduction ....................................................2
40 1.1. Applicability Statement ....................................2
41 2. Conventions Used in This Document ...............................2
42 3. Cipher Usage ....................................................3
43 4. Security Considerations .........................................3
44 5. IANA Considerations .............................................3
45 6. Acknowledgments .................................................3
46 7. References ......................................................4
47 7.1. Normative References .......................................4
48 7.2. Informative References .....................................4
58 Blumenthal & Goel Standards Track [Page 1]
60 RFC 4785 PSK NULL Encryption Ciphersuites for TLS January 2007
65 The RFC for Pre-Shared Key (PSK) based Transport Layer Security (TLS)
66 [TLS-PSK] specifies ciphersuites for supporting TLS using pre-shared
67 symmetric keys. However, all the ciphersuites defined in [TLS-PSK]
68 require encryption. However there are cases when only authentication
69 and integrity protection is required, and confidentiality is not
70 needed. There are also cases when confidentiality is not permitted -
71 e.g., for implementations that must meet import restrictions in some
72 countries. Even though no encryption is used, these ciphersuites
73 support authentication of the client and server to each other, and
74 message integrity. This document augments [TLS-PSK] by adding three
75 more ciphersuites (PSK, DHE_PSK, RSA_PSK) with authentication and
76 integrity only - no encryption. The reader is expected to become
77 familiar with [TLS-PSK] standards prior to studying this document.
79 1.1. Applicability Statement
81 The ciphersuites defined in this document are intended for a rather
82 limited set of applications, usually involving only a very small
83 number of clients and servers. Even in such environments, other
84 alternatives may be more appropriate.
86 If the main goal is to avoid Public-key Infrastructures (PKIs),
87 another possibility worth considering is using self-signed
88 certificates with public key fingerprints. Instead of manually
89 configuring a shared secret in, for instance, some configuration
90 file, a fingerprint (hash) of the other party's public key (or
91 certificate) could be placed there instead.
93 It is also possible to use the Secure Remote Password (SRP)
94 ciphersuites for shared secret authentication [SRP]. SRP was
95 designed to be used with passwords, and it incorporates protection
96 against dictionary attacks. However, it is computationally more
97 expensive than the PSK ciphersuites in [TLS-PSK].
99 2. Conventions Used in This Document
101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
103 document are to be interpreted as described in [RFC2119].
114 Blumenthal & Goel Standards Track [Page 2]
116 RFC 4785 PSK NULL Encryption Ciphersuites for TLS January 2007
121 The three new ciphersuites proposed here match the three cipher
122 suites defined in [TLS-PSK], except that we define suites with null
125 The ciphersuites defined here use the following options for key
126 exchange and hash part of the protocol:
128 CipherSuite Key Exchange Cipher Hash
130 TLS_PSK_WITH_NULL_SHA PSK NULL SHA
131 TLS_DHE_PSK_WITH_NULL_SHA DHE_PSK NULL SHA
132 TLS_RSA_PSK_WITH_NULL_SHA RSA_PSK NULL SHA
134 For the meaning of the terms PSK, please refer to section 1 in [TLS-
135 PSK]. For the meaning of the terms DHE, RSA, and SHA, please refer
136 to appendixes A.5 and B in [TLS].
138 4. Security Considerations
140 As with all schemes involving shared keys, special care should be
141 taken to protect the shared values and to limit their exposure over
142 time. As this document augments [TLS-PSK], everything stated in its
143 Security Consideration section applies here. In addition, as cipher
144 suites defined here do not support confidentiality, care should be
145 taken not to send sensitive information (such as passwords) over
146 connections protected with one of the ciphersuites defined in this
149 5. IANA Considerations
151 This document defines three new ciphersuites whose values are in the
152 TLS Cipher Suite registry defined in [TLS].
154 CipherSuite TLS_PSK_WITH_NULL_SHA = { 0x00, 0x2C };
155 CipherSuite TLS_DHE_PSK_WITH_NULL_SHA = { 0x00, 0x2D };
156 CipherSuite TLS_RSA_PSK_WITH_NULL_SHA = { 0x00, 0x2E };
160 The ciphersuites defined in this document are an augmentation to and
170 Blumenthal & Goel Standards Track [Page 3]
172 RFC 4785 PSK NULL Encryption Ciphersuites for TLS January 2007
177 7.1. Normative References
179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
180 Requirement Levels", BCP 14, RFC 2119, March 1997.
182 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
183 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
185 [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
186 for Transport Layer Security (TLS)", RFC 4279, December
189 7.2. Informative References
191 [SRP] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin,
192 "Using SRP for TLS Authentication", Work in Progress,
204 EMail: urimobile@optonline.net
214 EMail: Purushottam.Goel@intel.com
226 Blumenthal & Goel Standards Track [Page 4]
228 RFC 4785 PSK NULL Encryption Ciphersuites for TLS January 2007
231 Full Copyright Statement
233 Copyright (C) The IETF Trust (2007).
235 This document is subject to the rights, licenses and restrictions
236 contained in BCP 78, and except as set forth therein, the authors
237 retain all their rights.
239 This document and the information contained herein are provided on an
240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
242 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
243 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
244 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
247 Intellectual Property
249 The IETF takes no position regarding the validity or scope of any
250 Intellectual Property Rights or other rights that might be claimed to
251 pertain to the implementation or use of the technology described in
252 this document or the extent to which any license under such rights
253 might or might not be available; nor does it represent that it has
254 made any independent effort to identify any such rights. Information
255 on the procedures with respect to rights in RFC documents can be
256 found in BCP 78 and BCP 79.
258 Copies of IPR disclosures made to the IETF Secretariat and any
259 assurances of licenses to be made available, or the result of an
260 attempt made to obtain a general license or permission for the use of
261 such proprietary rights by implementers or users of this
262 specification can be obtained from the IETF on-line IPR repository at
263 http://www.ietf.org/ipr.
265 The IETF invites any interested party to bring to its attention any
266 copyrights, patents or patent applications, or other proprietary
267 rights that may cover technology that may be required to implement
268 this standard. Please address the information to the IETF at
273 Funding for the RFC Editor function is currently provided by the
282 Blumenthal & Goel Standards Track [Page 5]