idnits 2.17.1 draft-ietf-tls-passauth-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 349 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (November 20, 1996) is 10019 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Daniel Simon 2 Transport Layer Security Working Group Microsoft Corp. 3 Draft-ietf-tls-passauth-00.txt November 20, 1996 4 Expires: May 25, 1997 6 Addition of Shared Key Authentication to Transport Layer Security (TLS) 8 0. Status Of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ''work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 1. Abstract 29 This document presents a shared-key authentication mechanism for the TLS 30 protocol. It is intended to allow TLS clients to authenticate using a 31 secret key (such as a password) shared with either the server or a 32 third-party authentication service. The security of the secret 33 authentication key is augmented by its integration into the normal 34 SSL/TLS server authentication/key exchange mechanism. 36 2. Introduction 38 Recent transport-layer security protocols for the Internet, such as SSL 39 versions 2.0 and 3.0 [1, 2] and PCT version 1 [3], have effected 40 challenge-response authentication using strictly public-key (asymmetric) 41 cryptographic methods, with no use of out-of-band shared secrets. This 42 choice has both benefits and drawbacks. The primary benefit is improved 43 security: an asymmetric private key used for authentication is only 44 stored in one location, and the out-of-band identification necessary for 45 public key certification need only be reliable, not secret (as an out- 46 of-band shared key exchange must be). In addition, the difficult task 47 of out-of-band shared-key exchange in shared-key authentication systems 48 often leads implementers to resort to human-friendly shared keys 49 (manually typed passwords, for instance), which may be vulnerable to 50 discovery by brute force search or "social engineering". 52 However, shared-key authentication has certain advantages as well. 53 These are, chiefly: 55 - Portability: Precisely because shared keys are often human-remembered 56 passwords or passphrases, they can be transported from (trusted) machine 57 to (trusted) machine with ease--unlike asymmetric private keys, which 58 must be transported using some physical medium, such as a diskette or 59 "smart card", to be available for use on any machine. 61 - Backward Compatibility: Shared-key authentication is in very wide use 62 today, and the cost of conversion to its public-key counterpart may not 63 be worth the extra security, to some installations. 65 - Established Practice: Shared-key authentication has been in use for 66 quite a while, and a valuable body of tools, techniques and expertise 67 has grown up around it. In contrast, public-key authentication is very 68 new, its associated tools and methods are either untested or non- 69 existent, and experience with possible implementation or operation 70 pitfalls simply doesn't exist. 72 These reasons are particularly relevant when individual human users of a 73 service are being authenticated over the Internet, and as a result, 74 virtually all authentication of (human) clients of such services is 75 currently performed using shared passwords. Typically, servers 76 implementing one of the aforementioned transport-layer security 77 protocols, and needing client authentication, simply accept secure 78 (i.e., encrypted and server-authenticated) connections from each client, 79 who then provides a password (or engages in a challenge-response 80 authentication protocol based on a password) over the secure connection 81 to authenticate to the server. 83 Unfortunately, such "secure" connections are often not secure enough to 84 protect passwords, because of the various international legal 85 restrictions that have been placed on the use of encryption. Obviously, 86 secret keys such as passwords should not be sent over weakly encrypted 87 connections. In fact, even a challenge-response protocol which never 88 reveals the password is vulnerable, if a poorly chosen, guessable 89 password is used; an attacker can obtain the (weakly protected) 90 transcript of the challenge-response protocol, then attempt to guess the 91 password, verifying each guess against the transcript. 93 However, it is possible to protect even badly-chosen passwords against 94 such attacks by incorporating shared-key authentication into the 95 transport-layer security protocol itself. These protocols already 96 involve the exchange of long keys for message authentication, and those 97 same keys can be used (without the legal restraints associated with 98 encryption) to provide very strong protection for shared-key-based 99 challenge-response authentications, provided that the mechanism used 100 cannot be diverted for use as a strong encryption method. This latter 101 requirement makes it essential that the shared-key-based authentication 102 occur at the protocol level, rather than above it (as is normally the 103 case today), so that the implementation can carefully control use of the 104 long authentication key. 106 3. Protocol Additions 108 Starting from SSL version 3.0 notation and formats, the following three 109 new HandshakeTypes are added, and included in the Handshake message 110 definition: 112 shared_keys(30), shared_key_request(31), shared_key_verify(32) 114 A new CipherSuite is also included, to allow the client to signal 115 support for shared-key authentication to the server: 117 TLS_AUTH_SHARED_KEY = {x01, x01}; 119 The client's inclusion of this CipherSuite is independent of other 120 listed CipherSuites, and simply indicates to the server the 121 client's support for shared-key authentication. 123 3.1 SharedKeys message 125 The SharedKeys message has the following structure: 127 struct { 128 DistinguishedName auth_services_client<1..65535>; 129 } SharedKeys; 131 This optional message may be sent by the client immediately following 132 the ClientHello message; in fact, if sent, it is actually enclosed 133 within the ClientHello message, immediately following the last defined 134 field of the ClientHello message. (For forward compatibility reasons, 135 the SSL 3.0 ClientHello message is allowed to contain data beyond its 136 defined fields, and because there is no ClientHelloDone message, the 137 server cannot know that an extra message follows the ClientHello unless 138 it is actually included in the ClientHello message itself. A server 139 that does not support shared-key authentication will simply ignore the 140 extra data in the ClientHello message.) Although enclosed within the 141 ClientHello, the SharedKeys message retains the normal structure and 142 headers of a Handshake message. 144 The SharedKeys message contains a list of distinguished names of 145 authentication services to which the client is willing to authenticate. 146 This list need not be exhaustive; if the server cannot find an 147 acceptable authentication service from the list in the SharedKeys 148 message, then the server is free to reply with a list of acceptable 149 services in a subsequent SharedKeyRequest message. 151 In cases where pass-through authentication is used, this message allows 152 clients to be able to notify servers in advance of one or more 153 authentication services sharing a key with the client, so that the 154 server need only fetch (or use up) a challenge from a single service for 155 that client. This message may also be useful in non-pass-through 156 situations; for example, the client may share several keys with the 157 server, associated with identities on different systems (corresponding 158 to different "authentication services" residing on the same server). 159 If a server receives a SharedKeys message, then any subsequent 160 SharedKeyRequest message can contain a single authentication service 161 selected from the client's list. 163 Note that sending a SharedKeys message does not in itself normally 164 reveal significant information about the client's as-yet-unspecified 165 identity or identities. However, if information about the set of 166 authentication services supported by a particular client is at all 167 sensitive, then the client should not send this message. 169 3.2 SharedKeyRequest message 171 The SharedKeyRequest message has the following structure: 173 struct { 174 DistinguishedName auth_service_name; 175 opaque display_string<0..65535>; 176 opaque challenge<0..255>; 177 } AuthService; 179 struct { 180 AuthService auth_services_server<1..65535>; 181 } SharedKeyRequest; 183 This optional message may be sent immediately following the server's 184 first set of consecutive messsages, which includes the ServerHello and 185 (possibly) the Certificate, CertificateRequest and ServerKeyExchange 186 messages, but before the ServerHelloDone message. The 187 auth_services_server field contains a list of distinguished names of 188 shared-key authentication services by which the client can authenticate. 189 The challenge field accompanying each authentication service name 190 contains an optional extra authentication challenge, in case the server 191 needs to obtain one from an authentication service for pass-through 192 authentication. If none is required, then it would simply be an empty 193 (zero-length) field. Similarly, the display_string field may contain 194 information to be used (displayed to the user, for example) during 195 authentication, if needed; its interpretation is left to the 196 implementation. 198 3.3 SharedKeyVerify message 200 The SharedKeyVerify message is sent in response to a SharedKeyRequest 201 message from the server, at the same point at which a CertificateVerify 202 message would be sent in response to a CertificateRequest message. (If 203 both a CertificateRequest and a SharedKeyRequest are sent by the server, 204 then the client may respond with either a CertificateVerify message or a 205 SharedKeyVerify message. Only one of the two messages is ever sent in 206 the same handshake, however.) The SharedKeyVerify message has the 207 following structure: 209 struct { 210 AuthService auth_service; 211 opaque identity<1..65535>; 212 opaque shared_key_response<1..255>; 213 } SharedKeyVerify; 215 The value of auth_service must be identical to one of the AuthService 216 values on the list in SharedKeyRequest.auth_services_server. If the 217 client does not share a key with any of the authentication services 218 listed in the SharedKeyRequest message (and cannot supply a certificate 219 matching the requirements specified in the accompanying 220 CertificateRequest message, if one was sent), then the client returns a 221 "no certificate" alert message (in its normal place in the protocol). 223 The format of the identity field is left to the implementation, and must 224 be inferable from the accompanying value of auth_service. The value of 225 shared_key_response is defined as 227 SharedKeyVerify.shared_key_response 228 hash (auth_write_secret + pad_2 + 229 hash (auth_write_secret + pad_1 + hash (handshake_messages) 230 + SharedKeyVerify.auth_service.auth_service_name 231 + SharedKeyVerify.auth_service.display_string 232 + SharedKeyVerify.auth_service.challenge 233 + SharedKeyVerify.identity + shared_key) ) 235 Here "+" denotes concatenation. The hash function used (hash) is 236 taken from the pending cipher spec. The client_auth_write_secret and 237 server_auth_write_secret values are obtained by extending the 238 key_block by CipherSpec.hash_size bytes beyond the server_write_key (or 239 the server_write_IV, if it is derived from key_block as well), and using 240 this extended portion as the client_auth_write_secret value. (Only the 241 client_auth_write_secret is used, since only the client ever sends a 242 SharedKeyVerify message.) The value of handshake_messages is the 243 concatenation of all handshake messages from the first one sent up to 244 (but not including) the shared_key_verify message. The pad_1 and pad_2 245 values correspond to the ones used for MAC computation in the 246 application_data message. The fields from the SharedKeyVerify message 247 are input with their length prefixes included. 249 4. Normal Authentication 251 A shared-key-based client authentication may proceed as follows: the 252 client includes the TLS_AUTH_SHARED_KEY CipherSuite in its list of 253 CipherSuites in its ClientHello message. It also may or may not send a 254 SharedKeys message along with the ClientHello message, listing the 255 authentication services with which the client shared a key for 256 authentication purposes. In any event, the server sends a 257 SharedKeyRequest handshake message following the ServerHello and 258 accompanying messages containing a list of names of one or more 259 authentication services; if a SharedKeys message was sent, then this 260 list will contain a single choice from the client's SharedKeys message. 261 The client, on receiving the SharedKeyRequest message, selects an 262 authentication service from the server's list (if more than one is 263 offered) and constructs the appropriate authentication response as 264 described above, sending it back, along with its identity and choice of 265 authentication service, in a SharedKeyVerify handshake message. The 266 server itself also constructs the correct authentication response using 267 the known shared key, and checks it against the one provided by the 268 client. The authentication is successful if the two match exactly. 269 Note that if the shared key is password-based, then it would typically 270 be derived from the password using a one-way cryptographic hash 271 function, rather than being the password itself, so that the original 272 password need not be remembered by anyone but the client. 274 5. Pass-through Authentication 276 In some circumstances, it is preferable for shared keys to be stored in 277 one place (a central, well-protected site, for instance) while servers 278 that actually communicate with clients are elsewhere (possibly widely 279 distributed, but maintaining secure connections to the central shared- 280 key server). One of the advantages of the shared-key authentication 281 method proposed here is that it allows "pass-through" authentication by 282 a third party, if the server accepting the public-key key exchange and 283 the server sharing the key with the client happen to be different. (The 284 use of a separately derived authentication key in the response 285 computation makes this possible.) 287 Pass-through authentication might work as follows: The server would 288 either collect random challenges in advance from its authentication 289 services, or request them as needed. (If the client sends a SharedKeys 290 message, then the server can select an authentication service from the 291 client's list, and obtain a challenge from that service alone.) 292 Assuming that the client indicates support for shared-key authentication 293 by including the TLS_AUTH_SHARED_KEY CipherSuite in its list, the server 294 would then send a list of one or more authentication services and 295 associated challenges in a SharedKeyRequest message. The client would 296 then select an authentication service (if more than one is offered), 297 compute the correct authentication response using the above proposed 298 formula, and send it to the server in a SharedKeyVerify message. 300 The server, on receiving a response from a client, would pass it through 301 to the authentication service, along with the values necessary to 302 recalculate it: the client_auth_write_key, the hash of all the 303 handshake messages and the identity field from the certificate verify 304 message. The authentication service would then use the values provided, 305 along with the secret key it shares with the client and the challenge it 306 supplied, to reconstruct the correct value of the response. If this 307 value exactly matches the one provided by the server, then the 308 authentication would succeed; otherwise it would fail. 310 References 312 [1] K. Hickman and T. Elgamal, "The SSL Protocol", Internet Draft 313 (deleted), February 1995. 315 [2] A. Freier, P. Karlton and P. Kocher, "The SSL Protocol Version 316 3.0", Internet Draft , March 1996. 318 [3] J. Benaloh, B. Lampson, D. Simon, T. Spies and B. Yee, The PCT 319 Protocol", Internet Draft , November 1995. 321 Author's Address 323 Daniel Simon 325 Microsoft Corporation 326 One Microsoft Way 327 Redmond, WA 98052 328 Phone: (206) 936-6711 329 Fax: (206) 936-7329 331 Draft-ietf-tls-passauth-00.txt 332 November 20, 1996 333 Expires: May 25, 1997