Host Identity Protocol Varjonen Internet-Draft Helsinki Institute for Information Intended status: Informational Technology Expires: September 1, 2009 February 28, 2009 HIP and Strong Password Authentication of Users draft-varjonen-hip-srp-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. 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 on September 1, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Varjonen Expires September 1, 2009 [Page 1] Internet-Draft HIP SRP February 2009 Abstract This document specifies how to use Secure Remote Password (SRP) protocol in conjunction with Host Identity Protocol (HIP). In order to conceive this conjunction this document specifies three new parameters to be used with HIP control packets. These parameters are used to transport values related to the SRP protocol. This document also specifies how peers should act when these SRP parameters are found from HIP control packets and how this affects middleboxes. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. SRP Parameters . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. SRP_CV parameter . . . . . . . . . . . . . . . . . . . . . 7 3.2. SRP_CV_M parameter . . . . . . . . . . . . . . . . . . . . 8 3.3. SRP_SV Parameter . . . . . . . . . . . . . . . . . . . . . 8 3.4. SRP_SV_M Parameter . . . . . . . . . . . . . . . . . . . . 9 3.5. SRP_E Parameter . . . . . . . . . . . . . . . . . . . . . 10 3.6. SRP_E_M Parameter . . . . . . . . . . . . . . . . . . . . 10 4. Handling of SRP Parameters . . . . . . . . . . . . . . . . . . 10 5. SRP and middleboxes . . . . . . . . . . . . . . . . . . . . . 12 6. Extension to HIP Native API . . . . . . . . . . . . . . . . . 13 7. Design Alternatives . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Varjonen Expires September 1, 2009 [Page 2] Internet-Draft HIP SRP February 2009 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Varjonen Expires September 1, 2009 [Page 3] Internet-Draft HIP SRP February 2009 1. Glossary Terminology and notation used in this document is in most parts borrowed from [RFC5054], [SRP-6] and from the original paper describing SRP ([Wu.SRP]). USER: Is the entity that is being authenticated in the SRP protocol. HOST: Denotes the hardware and is identified by its Host Identity. CLIENT: Host in a role of a client that initiate the connection. SERVER: Host in a role of a server that offers service that is protected with username-password tuple. USERNAME, C: String that identifies the USER uniquely to the SERVER and is used in similar fashion as a public key (aka "identity"). PASSWORD, P: String that is user memorable and is used in a similar fashion as private key. VERIFIER: Is computed from PASSWORD in such fashion that it is hard to derive the PASSWORD from the VERIFIER. VERIFIER-BASED: SERVER stores verifiers instead of plain-text passwords. ZERO-KNOWLEDGE PROOF: PASSWORD is not sent on wire between CLIENT and SERVER. SERVER computes VERIFIERs from the values given by the CLIENT. N, g: group parameters (prime and generator), defined in [RFC5054] appendix A. s: salt B, b: server's public and private values A, a: client's public and private values v: verifier, calculated from P. k: SRP-6 multiplier K: Session key M: evidence, calculated from public values and K. Varjonen Expires September 1, 2009 [Page 4] Internet-Draft HIP SRP February 2009 The | symbol indicates string concatenation, the ^ operator is the exponentiation operation, and the % operator is the integer remainder operation. H() denotes hash function like SHA-1 (length 160 bits). Interleaved SHA is used in some parts of the protocol (Incorporates two SHA-1 hashes one for even bits and one for odd bits (length 320 bits)). Interleaved SHA is used to create the session key, see [RFC2945] for details. Conversion between integers and byte-strings assumes that the resulting byte-string is in network byte order. 2. Introduction Host Identity Protocol (HIP) [RFC4423] offers a cryptographic namespace and a way to negotiate a creation of Security Association (SA) between hosts. By default SAs are created by contacting the Responder. With HIP firewalls administrators can access control the connection attempts. In some cases access control based only on HITs is not enough. Organizations can have mobile employees that need access to the organizations network from outside the network. HIP can be used to authenticate the host but by default anyone possessing the machine and keys can create the tunnel. By introducing Secure Remote Password protocol (SRP, [Wu.SRP]) to HIP we can extend the authentication of the host to include the authentication of the user. SRP [RFC2945] offers a strong zero-knowledge proof authentication of a user/client to a server without any need for trusted third party. The SRP protocol can be run in one-way or in two-way mode, in one-way mode only the client is authenticated and in two-way mode client and the server are authenticated. Along with the authentication, peers run key negotiation and after the authentication peers share a session key. Performance wise SRP is slower than Diffie-Hellman [RFC2631] but SRP's performance has been proven as adequate [Performance.SRP]. SRP standardization [RFC2945] defines the SRP in an abstract way leaving most of the details to the hands of the implementors. This is one reason why this document borrows some parts from the other standardized solutions, like [RFC5054] SRP needs some preliminary values stored on the server requiring the authentication. In SRP it is a triplet consisting of username, password verifier and salt. Upon initialization of SRP, user gives a username, a password and SRP implementation takes a random salt. Verifier is calculated from these values (v = g^(SHA(salt| SHA(username)|":"|plain password) % N) and stored on the server requiring the authentication. The prime (N) and generator (g) can be taken from Appendix A of [RFC5054] Varjonen Expires September 1, 2009 [Page 5] Internet-Draft HIP SRP February 2009 SRP authentication consists of four messages (see Figure 1, in the first of the messages user tells his/her identity in the manner of supplying a username. The user also provides a public value that is calculated by raising the generator to the power of a random value a and taking the integer remainder of N from the result (A = g^a % N). For the second message the server finds the salt for the user and send its own public value calculated by raising generator to the power of random b, adding it to the verifier of the user and taking the integer remainder of N from the result (B = (v + g^b) % N). By now the peers have enough information on for creation of a session key, for details see [RFC2945]. The third message is the evidence (M1), if verified, it tells if the user knew the password. This is calculated by using the values sent in earlier messages and by using the newly formed session key, in other words the peers are verifying that they know the same key. For the calculation of the evidence M see [RFC2945]. If the negotiation is left to the three messages only the client/ Initiator is authenticated. If the server/responder needs to be authenticated, the server sends a fourth message containing its evidence (M2) The authentication does not need to be run endpoint-to-endpoint. There are cases where the middlebox along the way would be more interested in authenticating the user, for example a firewall on the edge of a corporate network could want to authenticate the user along side the equipment (identified by HIT) before letting the ESP flow through (see Section 5). Varjonen Expires September 1, 2009 [Page 6] Internet-Draft HIP SRP February 2009 Initiator Responder C, A --------------------------------> s, B <-------------------------------- Calculate the evidence M1 --------------------------------> Verify evidence Calculate the evidence M2 <-------------------------------- Verify evidence Figure 1 While here, we talk of messages, in case of HIP these messages are converted to mean individual parameters transported in HIP control packets. 3. SRP Parameters This section defines six parameters to be used when using SRP with HIP. These packets are SRP_CV, SRP_SV, SRP_E and their middlebox counterparts. The first parameter, named SRP_CV, is the initiating parameter for the SRP negotiation. It contains the username of the user to be authenticated and its public value. SRP_SV stands for server values which contains the salt and servers public value and SRP_E is a parameter to transport the evidence. Parameters ending with _M are identical to the ones that end without _M, only difference is the type number which tells the receiver that _M parameters are not protected by sigantures. Middleboxes are the most probable users of _M parameters, with the exception of pre-creation of R1s discussed in section Section 4. 3.1. SRP_CV parameter The SRP_CV parameter is used to convey the users' username and the public value of the client to the server. SRP_CV parameter is used in I1 control packet. Servers can use SRP_CV parameter for access control by checking that the HIT in I1 control packet is valid and also that the user using it is also valid (see section Section 9 for further discussion about SRP_CV). SRP_CV parameter is non-critical Varjonen Expires September 1, 2009 [Page 7] Internet-Draft HIP SRP February 2009 and so can be safely ignored if unknown. When mutual authentication is needed, a client can inform the server if it wants to authenticate the user (Administrator in practice) on server/responder by using field R. If field R is set client requires the server to authenticate by default the field R must not be set. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length C | Length A | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| Reserved | C / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | A / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD-IANA (998) Length Length in octets, excluding Type, Length, and Padding Length C Length of field C in octets Length A Length of field A in octets R Server authentication required if set Reserved Not in use, must be zeroed C Username, length from 8 to 2^8-1 bytes (255) A Public value of client, length from 1 to 2^16-1 bytes (65535) Padding Any Padding, if necessary, to make the TLV a multiple of 8 bytes. 3.2. SRP_CV_M parameter On-path middleboxes append this parameter to the control packets. This parameter is identical with SRP_CV differing only by its type number (TBD-IANA (632997)). 3.3. SRP_SV Parameter The SRP_SV parameter is used to convey the group and server values to the client. SRP_SV is used in R1 control packet. The group values consist of a prime (N) and a primitive root modulo of N, called generator (g). The server values are the public key of server and a salt found from servers passwd file. Public key of server (B) is a Varjonen Expires September 1, 2009 [Page 8] Internet-Draft HIP SRP February 2009 service or application key and not the hosts HI. See Section 4 for further discussion about the usage. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length N | Length g | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length s | Length B | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | N / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | s / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | B / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD-IANA (998) Length Length in octets, excluding Type, Length, and Padding Length N Length of field N in octets Length g Length of field g in octets Length s Length of field s in octets Length B Length of field B in octets N Prime, length from 1 to 2^16-1 bytes (65535) g Generator, length from 1 to 2^16-1 bytes (65535) s Salt, length from 1 to 2^8-1 bytes (255) B Public value of server, length from 1 to 2^16-1 bytes (65535) Padding Any Padding, if necessary, to make the TLV a multiple of 8 bytes. 3.4. SRP_SV_M Parameter On-path middleboxes append this parameter to the control packets. This parameter is identical with SRP_SV differing only by its type number (TBD-IANA (62998)). See Section 4 for further discussion about the usage. Varjonen Expires September 1, 2009 [Page 9] Internet-Draft HIP SRP February 2009 3.5. SRP_E Parameter SRP_E parameter is used to convey the evidence between peers. If this parameter is in I2 it is the clients evidence and if this parameter is in R2 it is the server's evidence. Evidence is produced with interleaved SHA as described earlier and in [RFC2945]. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | M | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD-IANA (999) Length Length in octets, excluding Type, Length, and Padding M Evidence, length 320 bytes 3.6. SRP_E_M Parameter On-path middleboxes append this parameter to the control packets. This parameter is identical with SRP_SV differing only by its type number TBD-IANA (62999). 4. Handling of SRP Parameters This section defines how hosts should behave when SRP related parameters are present in HIP control packets. In Figure 2 we present a BEX with one-way SRP parameters (Only relevant parameters are depicted). Varjonen Expires September 1, 2009 [Page 10] Internet-Draft HIP SRP February 2009 Initiator Responder I1: SRP_CV --------------------------------> select precomputed R1 R1: puzzle, SRP_SV, key, sig <-------------------------------- check sig remain stateless solve puzzle I2: solution, SRP_E, {key}, sig --------------------------------> calculate check puzzle session key check sig R2: sig <------------------------------- calculate session key check sig Verify evidence (M) Figure 2 In the following we present a BEX with two-way SRP parameters. The only difference to the previous one-way authentication is the SRP_E parameter in the R2 control packet. Initiator Responder I1: SRP_CV --------------------------------> select precomputed R1 R1: puzzle, SRP_SV, key, sig <-------------------------------- check sig remain stateless solve puzzle I2: solution, SRP_E, {key}, sig --------------------------------> calculate check puzzle session key check sig R2: sig, SRP_E <------------------------------- calculate session key check sig Verify evidence (M) HIP Responders pre-create R1s in order to minimize the expensive cryptographic operations before Responder has established state. Using SRP_SV will prevent this. In order to use pre-created R1s, Varjonen Expires September 1, 2009 [Page 11] Internet-Draft HIP SRP February 2009 Responders can append SRP_SV_M parameter into the unsigned part of the message. In cases where server requires authentication receives I1 control packets that do not contain SRP_CV parameter, server MAY drop the I1 packet or OPTIONALLY answer with NOTIFY control packet containing NOTIFICATION parameter with one of the following status types. NOTIFY MESSAGES - ERROR TYPES Value ------------------------------ ----- BLOCKED_BY_POLICY 42 The Responder is unwilling to set up an association for some policy reason (e.g., received HIT is NULL and policy does not allow opportunistic mode). SRP_AUTHENTICATION_REQUIRED 45 The Responder is not willing to set up an association because required authentication data is not present. When endpoint receives the SRP_CV_M parameter it can notice that a middlebox on the way is performing authentication, but it may decide not to react to this parameter. More about the middleboxes in section Section 5 5. SRP and middleboxes In the following we depict the situation where a middlebox needs to authenticate the user. The middle appends its parameters to the BEX packets traversing through it. Varjonen Expires September 1, 2009 [Page 12] Internet-Draft HIP SRP February 2009 Initiator Middlebox Responder .-----------------. I1, SRP_CV_M | | I1, SRP_CV_M -----------------> | |----------------------------> | | R1, + SRP_SV_M | Add SRP_SV_M | R1 <----------------- | |<---------------------------- | | I2, + SRP_E_M | Verify SRP_E_M | I2, SRP_E_M -----------------> | Let I2 through |----------------------------> | | R2 | | R2 <----------------- | |<----------------------------- '-----------------' Middleboxes can degrade or restrict service such as bandwidth limitation up to refusing connections and reporting access violations when it does not find SRP_E_M parameter from I1 control packet. The freshness of the authentication can be forced by using extensions defined in [HIP.Midauth] 6. Extension to HIP Native API In this section we describe extensions to the HIP Native API defined in [Native.API]. The target readers of this section are application programmers. As this section specifies sockets API extensions, it is written so that the syntax and semantics are in line with the POSIX standard [POSIX] as much as possible. The API specified in this section defines how to use socket options to set the used username and password so that the HIP layer can calculate the needed values and negotiate keys. The definition of the API is presented in C language and data types follow the POSIX format; intN_t means a singed integer of exactly N bits (e.g. int16_t) and uintN_t means an unsigned integer of exactly N bits (e.g. uint32_t). Varjonen Expires September 1, 2009 [Page 13] Internet-Draft HIP SRP February 2009 +-----------------------------+-----+-----+-----------------+-------+ | optname | get | set | description | dtype | +-----------------------------+-----+-----+-----------------+-------+ | HIP_USERINFO | | o | Set the | * | | | | | username and | | | | | | the password | | | | | | corresponding | | | | | | to it. | | +-----------------------------+-----+-----+-----------------+-------+ *: pointer to hip_userinfo data structure, defined below. struct hip_userinfo { uint8_t username[256]; /* username null terminated */ uint8_t password[256]; /* password null terminated */ }; For example, a username and password can be specified as follows. struct hip_userinfo userinfo; char usern[] = "username"; char passwd[] = "password"; memset(&userinfo, 0, sizeof(userinfo)); /* fill hip_userinfo data structure */ memcpy(&userinfo.username, &usern, sizeof(usern)); memcpy(&userinfo.password, &passwd, sizeof(passwd)); setsockopt(fd, IPPROTO_HIP, HIP_USERINFO, &userinfo, sizeof(userinfo)); 7. Design Alternatives Most of the devices (phones, PDAs, laptops) are operated by single user so the main approach described in this document can be used. Problems arise when clients have multiple users. For example, in case where machine A has users Aa and Ab. When Aa connects to server B, he creates a tunnel between the HITs of A and B. The problem in this, related to the SRP, is that now user Ab can also communicate using the same tunnel. Usage of Simultaneous Multi-Access extension [Hip.Sima] solves this multi-user to multi-user problem, because it allows HIP to use flow binding to identify and separate multiple ongoing upper layer data flows. Varjonen Expires September 1, 2009 [Page 14] Internet-Draft HIP SRP February 2009 8. IANA Considerations This document defines the SRP related parameters for the Host Identity Protocol [RFC5201]. These parameter are defined in Section 3. A new status type for NOTIFICATION parameter is defined in section Section 4 9. Security Considerations Parameter SRP_CV that is sent in I1 control packet can be used for access control but it also advertises the user that currently is using the machine. This can be avoided with similar approach as in [BLIND]. In this approach the username is concatenated to the salt, hashed and so made unreadable to parties not knowing the salt (in [BLIND] nonce). This approach has the disadvantage, that the user has to know his/her salt. Better way would be to concatenate the HIT of the server with the username and hashing the result (UH = H(HIT- of-server | username)). For this to work efficiently, the server needs to index its passwd by the UH and the identification of user should be done based on the UH. While the attacker knows the HIT of the server it has to guess the username with brute force. Still this has a drawback that the hash (UH) stays the same. This could be avoided by sending a nonce with the username, but performance issues arise when the server needs to hash every username it knows with the nonce in order to identify the user. Another way to protect the privacy of the user is to encrypt the SRP_CV with servers public key by using ENCRYPTED parameter, defined in [RFC5201]. This poses a problem of getting the public key of the server. The server can use DNS [RFC5205] or DHT [Opendht.Interface] in order to publish its public key. While the public key is available it poses delays when querying the key. The above ways could be improved by using physical tokens that contain the required information, like the public key or the salt. With physical tokens One Time Passwords (OTP) could be introduced and so making the required authentication tuple into triple containing username, password verifier and OTP. Parameters that are added by the middlebox are not signed. This should not pose any additional security problems. Attacker could replace or alter the SRP_*_M parameters and so letting the authentication fail. This can be done even without SRP parameters just by flipping random bits and so making the HMACs and signatures fail. Varjonen Expires September 1, 2009 [Page 15] Internet-Draft HIP SRP February 2009 10. Acknowledgements The authors would like to thank M. Komu J. Koskela, T. Heer and J. Heikkila of fruitful conversations on the subject. 11. References 11.1. Normative References [HIP.Midauth] Heer, T., "End-Host Authentication for HIP Middleboxes", . [Hip.Sima] Pierrel, S., Jokela, P., and J. Melen, "Simultaneous Multi-Access extension to the Host Identity Protocol", . [Native.API] Komu, M. and T. Henderson, "Basic Socket Interface Extensions for Host Identity Protocol (HIP)", . [Opendht.Interface] Ahrenholz, J., "HIP DHT Interface", . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006. [RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, "Using the Secure Remote Password (SRP) Protocol for TLS Authentication", RFC 5054, November 2007. [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol Varjonen Expires September 1, 2009 [Page 16] Internet-Draft HIP SRP February 2009 (HIP) Domain Name System (DNS) Extensions", RFC 5205, April 2008. 11.2. Informative References [BLIND] Ylitalo, J. and P. Nikander, "BLIND: A Complete Identity Protection Framework for End-points", Proc. Twelfth International Workshop on Security Protocols, Cambridge, England 04, April 2004. [POSIX] Open group Technical Standard, "IEEE Std. 1003.1-2001 Standard for Information Technology -- Portable Operating System Interface (POSIX)", Base Specifications, Issue 6, http://www.opengroup.org/austin 01, December 2001. [Performance.SRP] Hamalainen, P., Hannikainen, M., Niemi, M., and T. Hamalainen, "Performance evaluation of Secure Remote Password protocol>", In IEEE International Symposium on Circuits and Systems, ISCAS 2002 02, Aug 2002. [SRP-6] Wu, T., "SRP-6: Improvements and Refinements to the Secure Remote Password Protocol", 2002, . [Wu.SRP] Wu, T., "The Secure Remote Password Protocol", in Proceedings of the 1998 Internet Society Network and Distributed System Security Symposium, San Diego, CA, March 1998, pp. 97-111 98, 1998. Author's Address Samu Varjonen Helsinki Institute for Information Technology Metsnneidonkuja 4 Helsinki Finland Fax: +35896949768 Email: samu.varjonen@hiit.fi URI: http://www.hiit.fi Varjonen Expires September 1, 2009 [Page 17]