idnits 2.17.1 draft-nisse-secsh-srp-01.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([SSH-USERAUTH], [PROVOS], [SSH-TRANS], [SRP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 167: '... The server MUST NOT send this messa...' RFC 2119 keyword, line 193: '..., and the server MUST NOT send any pro...' RFC 2119 keyword, line 218: '...ring. The client MUST not use a ring u...' RFC 2119 keyword, line 253: '... The server MUST NOT send this messa...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 158 has weird spacing: '... string n...' == Line 164 has weird spacing: '... string s...' == Line 177 has weird spacing: '... string n, ...' == Line 178 has weird spacing: '... string s, ...' == Line 233 has weird spacing: '... string n, ...' == (3 more instances...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: This section sketches the changes needed in order to get away from using a fixed ring. The client MUST not use a ring unless its quality is checked in some way (see next section). I will assume that the client either keeps a list of trusted rings, or makes extensive quality checks at runtime. The name of this keyexchange method is "srp-sha1". -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2001) is 8252 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'SSH-ARCH' is defined on line 390, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-secsh-dh-group-exchange-00 == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-07 == Outdated reference: A later version (-24) exists of draft-ietf-secsh-transport-09 == Outdated reference: A later version (-27) exists of draft-ietf-secsh-userauth-09 Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Niels M�ller 3 draft-nisse-secsh-srp-01.txt 27 March 2001 4 Expires in September 2001 6 Using the SRP protocol as a key exchange method in Secure Shell 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2001). See the Full Copyright 31 Notice below for details. 33 Abstract 35 This memo describes an experimental method for authentication and 36 keyexchange in the Secure Shell protocol. 38 The main virtue of the SRP protocol [SRP] is that it provides 39 authentication based on a small secret (typically a password). It is 40 useful in situations where no authentic host key is known. For Secure 41 Shell, it can be used as a bootstrapping procedure to get the host 42 key of a server in a safe way. SRP also provides authentication of 43 the user, which means that it might make sense to either skip the 44 secsh "ssh-userauth"-service [SSH-USERAUTH] when using SRP, or allow 45 login with the "none" or "external-keyx" method. 47 Conventions and notations 48 Some of the conventions used in this document are taken from [SSH- 49 TRANS], others are from [SRP]. 51 C is the client, S is the server; q is a large safe prime, g is a 52 primitive root. V_S is S's version string; V_C is C's version string; 53 I_C is C's KEXINIT message and I_S S's KEXINIT message which have 54 been exchanged before this part begins. (See [SSH-TRANS] for more 55 information). 57 The ^ operator is the exponentiation operation, and the mod operator 58 is the integer remainder operation. Most implementations perform the 59 exponentiation and remainder in a single stage to avoid generating 60 unwieldy intermediate results. 62 The | symbol indicates ssh-style string concatenation: For any 63 strings A and B, A | B is the encoding of 65 string A 66 string B 68 Computation takes place in the ring Z/q. Actually, most of the action 69 takes place in its multiplicative group, which is generated by g. The 70 ring structure is not absolutely essential, what we really need is a 71 group G and and two mixing operations + and -, unrelated to the group 72 operation, each mapping G x G onto a set that is "almost" equal to G 73 (in the ring case, the image includes zero, which is outside the 74 multiplicative group. This is not really a problem). We must have a = 75 (a + b) - b, for all a, b in G such that also a + b is in G, and this 76 is why it is convenient to use the ring structure. 78 Furthermore, HASH is a hash function (currently SHA1), n is the 79 user's name (used for looking up salt and verifier in the server's 80 database), p is a password, and s is a random salt string. 82 x is constructed from the strings n, p and s as HASH(s | HASH(n | 83 p)), and the verifier is computed as g^x mod q. S keeps a database 84 containing triples , indexed by n. 86 Protocol description 88 1. C renerates a random number a (lg(q) < a < q-1) and computes 89 e = g^a mod q. C sends e and n to S. 91 2. S uses n to find v and s in its database. S generates a random 92 number b, (lg(q) < b < q-1) and computes f = v + g^b mod q. S 93 selects u as the integer corresponding to the first 32 bits of 94 HASH(f). If f or u happens to be zero, S must try another b. S 95 computes K = (e * v^u)^b mod q. S sends s and f to C. 97 3. C gets the password p and computes x = HASH(s | H(n | p)) and 98 v = g^x mod q. C also computes u in the same way as S. Finally, C 99 computes K = (f - v) ^ (a + u * x) mod q. 101 Each party must check that e and f are in the range [1, q-1]. If not, 102 the key exchange fails. 104 Note the addition in step 2, v + g^b mod q, and the corresponding 105 subtraction f - v in step 3, are the only operations that uses the 106 ring structure. C should also check that f - v is non-zero, i.e. 107 belongs to the multiplicative group generated by g. 109 At this point C and S have a shared secret K. They must now prove 110 that they know the same value. Even if we're primarily interested in 111 authenticating the server, the user must prove knowledge of the key 112 *first*. (Otherwise, the server leaks information about the 113 verifier). 115 To do this, the client sends m1 = HMAC(K, H) to the server, where H 116 is the "exchange hash" defined below. After verifying the MAC, the 117 server responds by sending m2 = HMAC(K, e | m1 | H) to the client. 118 Actually, the purpose of this final message exchange is twofold: (i) 119 to prove knowledge of the shared secret key K, completing the SRP 120 protocol, and (ii) to use the shared key K to authenticate the 121 exchange hash. The latter is needed in order to protect against 122 attacks on the algorithm negotiation that happens before the SRP 123 exchange, as well as version rollback attacks. 125 Protocol messages 127 The name of the method, when listed in the SSH_MSG_KEXINIT message, 128 is "srp-ring1-sha1". The SSH_MSG_KEXINIT negotiation determines which 129 hash function is used, as well as the values of q and g. 131 For the "srp-ring1-sha1", q is equal to 2^1024 - 2^960 - 1 + 2^64 * 132 floor( 2^894 Pi + 129093 ). This is the same prime used for "diffie- 133 hellman-group1-sha1" in [SSH-TRANS]. Its hexadecimal value is 135 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 136 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD 137 EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 138 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED 139 EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 140 FFFFFFFF FFFFFFFF. 142 In decimal, this value is 144 179769313486231590770839156793787453197860296048756011706444 145 423684197180216158519368947833795864925541502180565485980503 146 646440548199239100050792877003355816639229553136239076508735 147 759914822574862575007425302077447712589550957937778424442426 148 617334727629299387668709205606050270810842907692932019128194 149 467627007. 151 The generator used for "srp-ring1-ring1" is g = 5. This is different 152 from the generator used in [SSH-TRANS], because we need to generate 153 the entire multiplicative group. 155 First, the client sends: 157 byte SSH_MSG_KEXSRP_INIT 158 string n 159 mpint e 161 The server responds with 163 byte SSH_MSG_KEXSRP_REPLY 164 string s 165 mpint f 167 The server MUST NOT send this message until it has received the 168 SSH_MSG_KEXSRP_INIT message. 170 At this point, both sides can compute the exchange hash H, as the 171 HASH of the concatenation of the following: 173 string V_C, the client's version string (CR and NL excluded) 174 string V_S, the server's version string (CR and NL excluded) 175 string I_C, the payload of the client's SSH_MSG_KEXINIT 176 string I_S, the payload of the server's SSH_MSG_KEXINIT 177 string n, the user name 178 string s, the salt 179 mpint e, exchange value sent by the client 180 mpint f, exchange value sent by the server 181 mpint K, the shared secret 183 The client computes m1 = HMAC(K, H), and sends it to the server, to 184 prove that it knows the shared key. It sends 186 byte SSH_MSG_KEXSRP_PROOF 187 string m1 189 [ Would it be possible to instead send the exchange hash in the 190 clear, e.g. use m1 = H? ] 192 The server verifies that m1 is correct using its own K. If they don't 193 match, the keyexchange fails, and the server MUST NOT send any proof 194 back to the client. 196 Finally, the server computes m2 as the HMAC(K, e | m1 | H) and sends 198 byte SSH_MSG_KEXSRP_PROOF 199 string m2 201 to the client. The client verifies that m2 is correct, and if so, the 202 key exchange is successful and its output is H and K. 204 Message numbers 206 The following message numbers have been defined in this protocol 208 /* Numbers 30-49 used for kex packets. 209 Different kex methods may reuse message numbers in 210 this range. */ 211 #define SSH_MSG_KEXSRP_INIT 30 212 #define SSH_MSG_KEXSRP_REPLY 31 213 #define SSH_MSG_KEXSRP_PROOF 32 215 Ring negotiation 217 This section sketches the changes needed in order to get away from 218 using a fixed ring. The client MUST not use a ring unless its quality 219 is checked in some way (see next section). I will assume that the 220 client either keeps a list of trusted rings, or makes extensive 221 quality checks at runtime. The name of this keyexchange method is 222 "srp-sha1". 224 Each verifier must be associated with a particular ring, which was 225 used when computing the verifier in the first place. Therefore, the 226 server's userdatabase will contain entries where the 227 first three elements are the name, salt and verifier as before, and q 228 and g determines the ring and the generator. 230 C initiates the protocol by sending its user name to the server: 232 byte SSH_MSG_KEXSRP_INIT 233 string n, username 235 Note that e can not be computed yet, as the ring is not known. S 236 replies with 238 byte SSH_MSG_KEXSRP_REPLY 239 mpint q 240 mpint g 241 string s, salt 243 C computes e, and sends it to S: 245 byte SSH_MSG_KEXSRP_VALUE 246 mpint e 248 S computes f and K, and responds with 250 byte SSH_MSG_KEXSRP_VALUE 251 mpint f 253 The server MUST NOT send this message until after it has received e 254 from the client. 256 Now the client kan compute K. Both sides compute the exchange hash as 257 the HASH of the concatenation of the following: 259 string V_C, the client's version string (CR and NL excluded) 260 string V_S, the server's version string (CR and NL excluded) 261 string I_C, the payload of the client's SSH_MSG_KEXINIT 262 string I_S, the payload of the server's SSH_MSG_KEXINIT 263 string n, the user name 264 string s, the salt 265 mpint q 266 mpint g 267 mpint e, exchange value sent by the client 268 mpint f, exchange value sent by the server 269 mpint K, the shared secret 271 The final exchange of SSH_MSG_KEXSRP_PROOF is unchanged. Note that 272 the ability use different rings costs one more roundtrip. 274 Security Considerations 276 This entire draft discusses an authentication and key-exchange system 277 that protects passwords and exchanges keys across an untrusted 278 network. Most of this section is taken from [SRP], which also 279 provides more details. 281 Knowledge of the verifier enables an attacker to mount an offline 282 search (also known as a "dictionary attack") on the user's password, 283 as well as to impersonate the server. So the verifier should be kept 284 secret. The entry can be created on the user's 285 machine and transferred to the server, just like a user's public key, 286 or it could be created on the server. The former approach has the 287 advantage that the cleartext password is not even temporarily known 288 by the server. 290 SRP has been designed not only to counter the threat of casual 291 password-sniffing, but also to prevent a determined attacker equipped 292 with a dictionary of passwords from guessing at passwords using 293 captured network traffic. The SRP protocol itself also resists active 294 network attacks, and implementations can use the securely exchanged 295 keys to protect the session against hijacking and provide 296 confidentiality. 298 The SRP keyexchange was originally designed primarily a user 299 authentication method, but it also provides a peculiar form of host 300 authentication. If SRP succeeds, using a particular user name and 301 password, the client can be confident that the remote server knows 302 some verifier corresponding to that password. But if the same 303 password is used with several servers, the client can't distinguish 304 them from eachother, even if the actual verifiers are not shared 305 between servers. 307 As some of the best know algorithms for computing discrete logarithms 308 use extensive precomputations, it is desirable not to depend on a 309 single fixed group like the multiplicative group used with "srp- 310 ring1-sha1". However, care must be taken whenever the a client starts 311 to use a new ring. Consider an attacker that knows how to compute 312 discrete logarithms in the multiplicative group of a particular ring, 313 and can convince the client to use that group. According to Tom Wu, 314 the worst the attacker can do is getting information that enables him 315 to verify guessed passwords. 317 In "diffie-hellman-group-exchange-sha1" [PROVOS] the client knows the 318 server's hostkey a priori, and uses that to authenticate the groups 319 the server proposes. 321 With SRP, authenticating a proposed ring seems more difficult; if the 322 ring is weak, authenticating it using the negotiated session key 323 proves nothing. 325 SRP also has the added advantage of permitting the host to store 326 passwords in a form that is not directly useful to an attacker. Even 327 if the host's password database were publicly revealed, the attacker 328 would still need an expensive dictionary search to obtain any 329 passwords. The exponential computation required to validate a guess 330 in this case is much more time-consuming than the hash currently used 331 by most UNIX systems. Hosts are still advised, though, to try their 332 best to keep their password files secure. 334 At the time of this writing, SRP is still quite a new protocol, and 335 it is too early to say definitely that it is secure. It is therefore 336 recommended not to use SRP for general remote access that lets the 337 client to execute arbitrary programs on the server. 339 SRP can be used for read-only access to public files (such as the 340 server's host key, or a users known_hosts file). Used in this way, 341 SRP can be used to obtain an authentic public key for the server, 342 while a more conservative authentication mechanism is used for 343 further access. 345 Further questions 347 This document should give a list of rings that can be used, which 348 should include the rings used by libsrp (is there any specification, 349 besides the source code, that lists these rings)? In general, to what 350 extent should the protocol be compatible with libsrp? 352 Rings can be transmitted either by sending modulo and generator 353 explicitly, like above, or by identifyng rings with names or numbers. 355 It may be a good idea to optionally include the server's host key in 356 the SSH_MSG_KEXSRP_REPLY above, and in the exchange hash. It is not 357 needed for the SRP exchange, but it is a convenient way to transmit 358 an authentic host key, and it is useful for key re-exchanges later 359 on. 361 To strengthen host authentication, in the case that a user has the 362 same password on several servers, it may be a good idea to include 363 the hostname somewhere in the computation of x, either in the user 364 name or in the salt. 366 One can also consider adding the description of the group as another 367 element in the computation of x, to add robustness in the "middle- 368 man-sends-booby-trapped-group" scenario. More analysis is needed to 369 say if adding the group description would really help, though. 371 Author's Address 373 Niels M�ller 374 LSH author 375 Sl�tbaksv�gen 48 376 120 51 �rsta 377 Sweden 379 EMail: nisse@lysator.liu.se 381 References 383 [PROVOS] Niels Provos, et al, "Diffie-Hellman Group Exchange for the 384 SSH Transport Layer Protocol", Internet Draft, 385 draft-ietf-secsh-dh-group-exchange-00.txt 387 [SRP] T. Wu, "The SRP Authentication and Key Exchange System", 388 RFC 2945 390 [SSH-ARCH] Ylonen, T., et al, "SSH Protocol Architecture", Internet 391 Draft, draft-ietf-secsh-architecture-07.txt 393 [SSH-TRANS] Ylonen, T., et al, "SSH Transport Layer Protocol", Internet 394 Draft, draft-ietf-secsh-transport-09.txt 396 [SSH-USERAUTH] Ylonen, T., et al, "SSH Authentication Protocol", 397 Internet Draft, draft-ietf-secsh-userauth-09.txt 399 Full Copyright Statement 401 Copyright (C) The Internet Society (1997). All Rights Reserved. 403 This document and translations of it may be copied and furnished to 404 others, and derivative works that comment on or otherwise explain it 405 or assist in its implmentation may be prepared, copied, published and 406 distributed, in whole or in part, without restriction of any kind, 407 provided that the above copyright notice and this paragraph are 408 included on all such copies and derivative works. However, this 409 document itself may not be modified in any way, such as by removing 410 the copyright notice or references to the Internet Society or other 411 Internet organizations, except as needed for the purpose of developing 412 Internet standards in which case the procedures for copyrights defined 413 in the Internet Standards process must be followed, or as required to 414 translate it into languages other than English. 416 The limited permissions granted above are perpetual and will not be 417 revoked by the Internet Society or its successors or assigns. 419 This document and the information contained herein is provided on an 420 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 421 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 422 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 423 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 424 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."