idnits 2.17.1 draft-varjonen-hip-srp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(i) Publication Limitation clause. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 28, 2009) is 5533 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: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '256' on line 522 ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) ** Obsolete normative reference: RFC 5201 (Obsoleted by RFC 7401) ** Obsolete normative reference: RFC 5205 (Obsoleted by RFC 8005) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Host Identity Protocol Varjonen 3 Internet-Draft Helsinki Institute for Information 4 Intended status: Informational Technology 5 Expires: September 1, 2009 February 28, 2009 7 HIP and Strong Password Authentication of Users 8 draft-varjonen-hip-srp-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may not be modified, 14 and derivative works of it may not be created, except to format it 15 for publication as an RFC or to translate it into languages other 16 than English. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 1, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document specifies how to use Secure Remote Password (SRP) 50 protocol in conjunction with Host Identity Protocol (HIP). In order 51 to conceive this conjunction this document specifies three new 52 parameters to be used with HIP control packets. These parameters are 53 used to transport values related to the SRP protocol. This document 54 also specifies how peers should act when these SRP parameters are 55 found from HIP control packets and how this affects middleboxes. 57 Requirements Language 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [RFC2119]. 63 Table of Contents 65 1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. SRP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.1. SRP_CV parameter . . . . . . . . . . . . . . . . . . . . . 7 71 3.2. SRP_CV_M parameter . . . . . . . . . . . . . . . . . . . . 8 72 3.3. SRP_SV Parameter . . . . . . . . . . . . . . . . . . . . . 8 73 3.4. SRP_SV_M Parameter . . . . . . . . . . . . . . . . . . . . 9 74 3.5. SRP_E Parameter . . . . . . . . . . . . . . . . . . . . . 10 75 3.6. SRP_E_M Parameter . . . . . . . . . . . . . . . . . . . . 10 77 4. Handling of SRP Parameters . . . . . . . . . . . . . . . . . . 10 79 5. SRP and middleboxes . . . . . . . . . . . . . . . . . . . . . 12 81 6. Extension to HIP Native API . . . . . . . . . . . . . . . . . 13 83 7. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 14 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Glossary 99 Terminology and notation used in this document is in most parts 100 borrowed from [RFC5054], [SRP-6] and from the original paper 101 describing SRP ([Wu.SRP]). 103 USER: Is the entity that is being authenticated in the SRP protocol. 105 HOST: Denotes the hardware and is identified by its Host Identity. 107 CLIENT: Host in a role of a client that initiate the connection. 109 SERVER: Host in a role of a server that offers service that is 110 protected with username-password tuple. 112 USERNAME, C: String that identifies the USER uniquely to the SERVER 113 and is used in similar fashion as a public key (aka "identity"). 115 PASSWORD, P: String that is user memorable and is used in a similar 116 fashion as private key. 118 VERIFIER: Is computed from PASSWORD in such fashion that it is hard 119 to derive the PASSWORD from the VERIFIER. 121 VERIFIER-BASED: SERVER stores verifiers instead of plain-text 122 passwords. 124 ZERO-KNOWLEDGE PROOF: PASSWORD is not sent on wire between CLIENT and 125 SERVER. SERVER computes VERIFIERs from the values given by the 126 CLIENT. 128 N, g: group parameters (prime and generator), defined in [RFC5054] 129 appendix A. 131 s: salt 133 B, b: server's public and private values 135 A, a: client's public and private values 137 v: verifier, calculated from P. 139 k: SRP-6 multiplier 141 K: Session key 143 M: evidence, calculated from public values and K. 145 The | symbol indicates string concatenation, the ^ operator is the 146 exponentiation operation, and the % operator is the integer remainder 147 operation. H() denotes hash function like SHA-1 (length 160 bits). 148 Interleaved SHA is used in some parts of the protocol (Incorporates 149 two SHA-1 hashes one for even bits and one for odd bits (length 320 150 bits)). Interleaved SHA is used to create the session key, see 151 [RFC2945] for details. 153 Conversion between integers and byte-strings assumes that the 154 resulting byte-string is in network byte order. 156 2. Introduction 158 Host Identity Protocol (HIP) [RFC4423] offers a cryptographic 159 namespace and a way to negotiate a creation of Security Association 160 (SA) between hosts. By default SAs are created by contacting the 161 Responder. With HIP firewalls administrators can access control the 162 connection attempts. In some cases access control based only on HITs 163 is not enough. Organizations can have mobile employees that need 164 access to the organizations network from outside the network. HIP 165 can be used to authenticate the host but by default anyone possessing 166 the machine and keys can create the tunnel. By introducing Secure 167 Remote Password protocol (SRP, [Wu.SRP]) to HIP we can extend the 168 authentication of the host to include the authentication of the user. 170 SRP [RFC2945] offers a strong zero-knowledge proof authentication of 171 a user/client to a server without any need for trusted third party. 172 The SRP protocol can be run in one-way or in two-way mode, in one-way 173 mode only the client is authenticated and in two-way mode client and 174 the server are authenticated. Along with the authentication, peers 175 run key negotiation and after the authentication peers share a 176 session key. Performance wise SRP is slower than Diffie-Hellman 177 [RFC2631] but SRP's performance has been proven as adequate 178 [Performance.SRP]. SRP standardization [RFC2945] defines the SRP in 179 an abstract way leaving most of the details to the hands of the 180 implementors. This is one reason why this document borrows some 181 parts from the other standardized solutions, like [RFC5054] 183 SRP needs some preliminary values stored on the server requiring the 184 authentication. In SRP it is a triplet consisting of username, 185 password verifier and salt. Upon initialization of SRP, user gives a 186 username, a password and SRP implementation takes a random salt. 187 Verifier is calculated from these values (v = g^(SHA(salt| 188 SHA(username)|":"|plain password) % N) and stored on the server 189 requiring the authentication. The prime (N) and generator (g) can be 190 taken from Appendix A of [RFC5054] 191 SRP authentication consists of four messages (see Figure 1, in the 192 first of the messages user tells his/her identity in the manner of 193 supplying a username. The user also provides a public value that is 194 calculated by raising the generator to the power of a random value a 195 and taking the integer remainder of N from the result (A = g^a % N). 196 For the second message the server finds the salt for the user and 197 send its own public value calculated by raising generator to the 198 power of random b, adding it to the verifier of the user and taking 199 the integer remainder of N from the result (B = (v + g^b) % N). By 200 now the peers have enough information on for creation of a session 201 key, for details see [RFC2945]. The third message is the evidence 202 (M1), if verified, it tells if the user knew the password. This is 203 calculated by using the values sent in earlier messages and by using 204 the newly formed session key, in other words the peers are verifying 205 that they know the same key. For the calculation of the evidence M 206 see [RFC2945]. 208 If the negotiation is left to the three messages only the client/ 209 Initiator is authenticated. If the server/responder needs to be 210 authenticated, the server sends a fourth message containing its 211 evidence (M2) 213 The authentication does not need to be run endpoint-to-endpoint. 214 There are cases where the middlebox along the way would be more 215 interested in authenticating the user, for example a firewall on the 216 edge of a corporate network could want to authenticate the user along 217 side the equipment (identified by HIT) before letting the ESP flow 218 through (see Section 5). 220 Initiator Responder 221 C, A 222 --------------------------------> 223 s, B 224 <-------------------------------- 225 Calculate the 226 evidence 227 M1 228 --------------------------------> 229 Verify evidence 231 Calculate the 232 evidence 233 M2 234 <-------------------------------- 235 Verify evidence 237 Figure 1 239 While here, we talk of messages, in case of HIP these messages are 240 converted to mean individual parameters transported in HIP control 241 packets. 243 3. SRP Parameters 245 This section defines six parameters to be used when using SRP with 246 HIP. These packets are SRP_CV, SRP_SV, SRP_E and their middlebox 247 counterparts. The first parameter, named SRP_CV, is the initiating 248 parameter for the SRP negotiation. It contains the username of the 249 user to be authenticated and its public value. SRP_SV stands for 250 server values which contains the salt and servers public value and 251 SRP_E is a parameter to transport the evidence. Parameters ending 252 with _M are identical to the ones that end without _M, only 253 difference is the type number which tells the receiver that _M 254 parameters are not protected by sigantures. Middleboxes are the most 255 probable users of _M parameters, with the exception of pre-creation 256 of R1s discussed in section Section 4. 258 3.1. SRP_CV parameter 260 The SRP_CV parameter is used to convey the users' username and the 261 public value of the client to the server. SRP_CV parameter is used 262 in I1 control packet. Servers can use SRP_CV parameter for access 263 control by checking that the HIT in I1 control packet is valid and 264 also that the user using it is also valid (see section Section 9 for 265 further discussion about SRP_CV). SRP_CV parameter is non-critical 266 and so can be safely ignored if unknown. 268 When mutual authentication is needed, a client can inform the server 269 if it wants to authenticate the user (Administrator in practice) on 270 server/responder by using field R. If field R is set client requires 271 the server to authenticate by default the field R must not be set. 273 0 1 2 3 274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 | Type | Length | 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Length C | Length A | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 |R| Reserved | C / 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 / | A / 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 / | Padding | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 Type TBD-IANA (998) 288 Length Length in octets, excluding Type, Length, and Padding 289 Length C Length of field C in octets 290 Length A Length of field A in octets 291 R Server authentication required if set 292 Reserved Not in use, must be zeroed 293 C Username, length from 8 to 2^8-1 bytes (255) 294 A Public value of client, length from 1 to 2^16-1 bytes 295 (65535) 296 Padding Any Padding, if necessary, to make the TLV a multiple 297 of 8 bytes. 299 3.2. SRP_CV_M parameter 301 On-path middleboxes append this parameter to the control packets. 302 This parameter is identical with SRP_CV differing only by its type 303 number (TBD-IANA (632997)). 305 3.3. SRP_SV Parameter 307 The SRP_SV parameter is used to convey the group and server values to 308 the client. SRP_SV is used in R1 control packet. The group values 309 consist of a prime (N) and a primitive root modulo of N, called 310 generator (g). The server values are the public key of server and a 311 salt found from servers passwd file. Public key of server (B) is a 312 service or application key and not the hosts HI. See Section 4 for 313 further discussion about the usage. 315 0 1 2 3 316 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Length N | Length g | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Length s | Length B | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | N / 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | g / 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | s / 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | B / 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Padding | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Type TBD-IANA (998) 336 Length Length in octets, excluding Type, Length, and Padding 337 Length N Length of field N in octets 338 Length g Length of field g in octets 339 Length s Length of field s in octets 340 Length B Length of field B in octets 341 N Prime, length from 1 to 2^16-1 bytes (65535) 342 g Generator, length from 1 to 2^16-1 bytes (65535) 343 s Salt, length from 1 to 2^8-1 bytes (255) 344 B Public value of server, length from 1 to 2^16-1 bytes 345 (65535) 346 Padding Any Padding, if necessary, to make the TLV a multiple 347 of 8 bytes. 349 3.4. SRP_SV_M Parameter 351 On-path middleboxes append this parameter to the control packets. 352 This parameter is identical with SRP_SV differing only by its type 353 number (TBD-IANA (62998)). See Section 4 for further discussion 354 about the usage. 356 3.5. SRP_E Parameter 358 SRP_E parameter is used to convey the evidence between peers. If 359 this parameter is in I2 it is the clients evidence and if this 360 parameter is in R2 it is the server's evidence. Evidence is produced 361 with interleaved SHA as described earlier and in [RFC2945]. 363 0 1 2 3 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 | M | 370 | | 371 | | 372 | | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Type TBD-IANA (999) 376 Length Length in octets, excluding Type, Length, and Padding 377 M Evidence, length 320 bytes 379 3.6. SRP_E_M Parameter 381 On-path middleboxes append this parameter to the control packets. 382 This parameter is identical with SRP_SV differing only by its type 383 number TBD-IANA (62999). 385 4. Handling of SRP Parameters 387 This section defines how hosts should behave when SRP related 388 parameters are present in HIP control packets. In Figure 2 we 389 present a BEX with one-way SRP parameters (Only relevant parameters 390 are depicted). 392 Initiator Responder 394 I1: SRP_CV 395 --------------------------------> 396 select precomputed R1 397 R1: puzzle, SRP_SV, key, sig 398 <-------------------------------- 399 check sig remain stateless 400 solve puzzle 401 I2: solution, SRP_E, {key}, sig 402 --------------------------------> 403 calculate check puzzle 404 session key check sig 405 R2: sig 406 <------------------------------- 407 calculate session key 408 check sig Verify evidence (M) 410 Figure 2 412 In the following we present a BEX with two-way SRP parameters. The 413 only difference to the previous one-way authentication is the SRP_E 414 parameter in the R2 control packet. 416 Initiator Responder 418 I1: SRP_CV 419 --------------------------------> 420 select precomputed R1 421 R1: puzzle, SRP_SV, key, sig 422 <-------------------------------- 423 check sig remain stateless 424 solve puzzle 425 I2: solution, SRP_E, {key}, sig 426 --------------------------------> 427 calculate check puzzle 428 session key check sig 429 R2: sig, SRP_E 430 <------------------------------- 431 calculate session key 432 check sig Verify evidence (M) 434 HIP Responders pre-create R1s in order to minimize the expensive 435 cryptographic operations before Responder has established state. 436 Using SRP_SV will prevent this. In order to use pre-created R1s, 437 Responders can append SRP_SV_M parameter into the unsigned part of 438 the message. 440 In cases where server requires authentication receives I1 control 441 packets that do not contain SRP_CV parameter, server MAY drop the I1 442 packet or OPTIONALLY answer with NOTIFY control packet containing 443 NOTIFICATION parameter with one of the following status types. 445 NOTIFY MESSAGES - ERROR TYPES Value 446 ------------------------------ ----- 448 BLOCKED_BY_POLICY 42 450 The Responder is unwilling to set up an association 451 for some policy reason (e.g., received HIT is NULL 452 and policy does not allow opportunistic mode). 454 SRP_AUTHENTICATION_REQUIRED 45 456 The Responder is not willing to set up an association 457 because required authentication data is not present. 459 When endpoint receives the SRP_CV_M parameter it can notice that a 460 middlebox on the way is performing authentication, but it may decide 461 not to react to this parameter. More about the middleboxes in 462 section Section 5 464 5. SRP and middleboxes 466 In the following we depict the situation where a middlebox needs to 467 authenticate the user. The middle appends its parameters to the BEX 468 packets traversing through it. 470 Initiator Middlebox Responder 471 .-----------------. 472 I1, SRP_CV_M | | I1, SRP_CV_M 473 -----------------> | |----------------------------> 474 | | 475 R1, + SRP_SV_M | Add SRP_SV_M | R1 476 <----------------- | |<---------------------------- 477 | | 478 I2, + SRP_E_M | Verify SRP_E_M | I2, SRP_E_M 479 -----------------> | Let I2 through |----------------------------> 480 | | 481 R2 | | R2 482 <----------------- | |<----------------------------- 483 '-----------------' 485 Middleboxes can degrade or restrict service such as bandwidth 486 limitation up to refusing connections and reporting access violations 487 when it does not find SRP_E_M parameter from I1 control packet. 489 The freshness of the authentication can be forced by using extensions 490 defined in [HIP.Midauth] 492 6. Extension to HIP Native API 494 In this section we describe extensions to the HIP Native API defined 495 in [Native.API]. The target readers of this section are application 496 programmers. 498 As this section specifies sockets API extensions, it is written so 499 that the syntax and semantics are in line with the POSIX standard 500 [POSIX] as much as possible. The API specified in this section 501 defines how to use socket options to set the used username and 502 password so that the HIP layer can calculate the needed values and 503 negotiate keys. The definition of the API is presented in C language 504 and data types follow the POSIX format; intN_t means a singed integer 505 of exactly N bits (e.g. int16_t) and uintN_t means an unsigned 506 integer of exactly N bits (e.g. uint32_t). 508 +-----------------------------+-----+-----+-----------------+-------+ 509 | optname | get | set | description | dtype | 510 +-----------------------------+-----+-----+-----------------+-------+ 511 | HIP_USERINFO | | o | Set the | * | 512 | | | | username and | | 513 | | | | the password | | 514 | | | | corresponding | | 515 | | | | to it. | | 516 +-----------------------------+-----+-----+-----------------+-------+ 518 *: pointer to hip_userinfo data structure, defined below. 520 struct hip_userinfo { 521 uint8_t username[256]; /* username null terminated */ 522 uint8_t password[256]; /* password null terminated */ 523 }; 525 For example, a username and password can be specified as follows. 527 struct hip_userinfo userinfo; 528 char usern[] = "username"; 529 char passwd[] = "password"; 531 memset(&userinfo, 0, sizeof(userinfo)); 533 /* fill hip_userinfo data structure */ 534 memcpy(&userinfo.username, &usern, sizeof(usern)); 535 memcpy(&userinfo.password, &passwd, sizeof(passwd)); 537 setsockopt(fd, IPPROTO_HIP, HIP_USERINFO, &userinfo, 538 sizeof(userinfo)); 540 7. Design Alternatives 542 Most of the devices (phones, PDAs, laptops) are operated by single 543 user so the main approach described in this document can be used. 544 Problems arise when clients have multiple users. For example, in 545 case where machine A has users Aa and Ab. When Aa connects to server 546 B, he creates a tunnel between the HITs of A and B. The problem in 547 this, related to the SRP, is that now user Ab can also communicate 548 using the same tunnel. Usage of Simultaneous Multi-Access extension 549 [Hip.Sima] solves this multi-user to multi-user problem, because it 550 allows HIP to use flow binding to identify and separate multiple 551 ongoing upper layer data flows. 553 8. IANA Considerations 555 This document defines the SRP related parameters for the Host 556 Identity Protocol [RFC5201]. These parameter are defined in 557 Section 3. A new status type for NOTIFICATION parameter is defined 558 in section Section 4 560 9. Security Considerations 562 Parameter SRP_CV that is sent in I1 control packet can be used for 563 access control but it also advertises the user that currently is 564 using the machine. This can be avoided with similar approach as in 565 [BLIND]. In this approach the username is concatenated to the salt, 566 hashed and so made unreadable to parties not knowing the salt (in 567 [BLIND] nonce). This approach has the disadvantage, that the user 568 has to know his/her salt. Better way would be to concatenate the HIT 569 of the server with the username and hashing the result (UH = H(HIT- 570 of-server | username)). For this to work efficiently, the server 571 needs to index its passwd by the UH and the identification of user 572 should be done based on the UH. While the attacker knows the HIT of 573 the server it has to guess the username with brute force. Still this 574 has a drawback that the hash (UH) stays the same. This could be 575 avoided by sending a nonce with the username, but performance issues 576 arise when the server needs to hash every username it knows with the 577 nonce in order to identify the user. 579 Another way to protect the privacy of the user is to encrypt the 580 SRP_CV with servers public key by using ENCRYPTED parameter, defined 581 in [RFC5201]. This poses a problem of getting the public key of the 582 server. The server can use DNS [RFC5205] or DHT [Opendht.Interface] 583 in order to publish its public key. While the public key is 584 available it poses delays when querying the key. 586 The above ways could be improved by using physical tokens that 587 contain the required information, like the public key or the salt. 588 With physical tokens One Time Passwords (OTP) could be introduced and 589 so making the required authentication tuple into triple containing 590 username, password verifier and OTP. 592 Parameters that are added by the middlebox are not signed. This 593 should not pose any additional security problems. Attacker could 594 replace or alter the SRP_*_M parameters and so letting the 595 authentication fail. This can be done even without SRP parameters 596 just by flipping random bits and so making the HMACs and signatures 597 fail. 599 10. Acknowledgements 601 The authors would like to thank M. Komu J. Koskela, T. Heer and J. 602 Heikkila of fruitful conversations on the subject. 604 11. References 606 11.1. Normative References 608 [HIP.Midauth] 609 Heer, T., "End-Host Authentication for HIP Middleboxes", 610 . 612 [Hip.Sima] 613 Pierrel, S., Jokela, P., and J. Melen, "Simultaneous 614 Multi-Access extension to the Host Identity Protocol", 615 . 617 [Native.API] 618 Komu, M. and T. Henderson, "Basic Socket Interface 619 Extensions for Host Identity Protocol (HIP)", 620 . 622 [Opendht.Interface] 623 Ahrenholz, J., "HIP DHT Interface", 624 . 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, March 1997. 629 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 630 RFC 2631, June 1999. 632 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 633 RFC 2945, September 2000. 635 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 636 (HIP) Architecture", RFC 4423, May 2006. 638 [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, 639 "Using the Secure Remote Password (SRP) Protocol for TLS 640 Authentication", RFC 5054, November 2007. 642 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 643 "Host Identity Protocol", RFC 5201, April 2008. 645 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 646 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 647 April 2008. 649 11.2. Informative References 651 [BLIND] Ylitalo, J. and P. Nikander, "BLIND: A Complete Identity 652 Protection Framework for End-points", Proc. Twelfth 653 International Workshop on Security Protocols, Cambridge, 654 England 04, April 2004. 656 [POSIX] Open group Technical Standard, "IEEE Std. 1003.1-2001 657 Standard for Information Technology -- Portable Operating 658 System Interface (POSIX)", Base Specifications, Issue 6, 659 http://www.opengroup.org/austin 01, December 2001. 661 [Performance.SRP] 662 Hamalainen, P., Hannikainen, M., Niemi, M., and T. 663 Hamalainen, "Performance evaluation of Secure Remote 664 Password protocol>", In IEEE International Symposium on 665 Circuits and Systems, ISCAS 2002 02, Aug 2002. 667 [SRP-6] Wu, T., "SRP-6: Improvements and Refinements to the Secure 668 Remote Password Protocol", 2002, 669 . 671 [Wu.SRP] Wu, T., "The Secure Remote Password Protocol", in 672 Proceedings of the 1998 Internet Society Network and 673 Distributed System Security Symposium, San Diego, CA, 674 March 1998, pp. 97-111 98, 1998. 676 Author's Address 678 Samu Varjonen 679 Helsinki Institute for Information Technology 680 Metsnneidonkuja 4 681 Helsinki 682 Finland 684 Fax: +35896949768 685 Email: samu.varjonen@hiit.fi 686 URI: http://www.hiit.fi