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",
<draft-heer-hip-middle-auth-01>.
[Hip.Sima]
Pierrel, S., Jokela, P., and J. Melen, "Simultaneous
Multi-Access extension to the Host Identity Protocol",
<draft-pierrel-hip-sima-00>.
[Native.API]
Komu, M. and T. Henderson, "Basic Socket Interface
Extensions for Host Identity Protocol (HIP)",
<draft-ietf-hip-native-api-05>.
[Opendht.Interface]
Ahrenholz, J., "HIP DHT Interface",
<draft-ahrenholz-hiprg-dht-03>.
[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,
<http://grouper.ieee.org/groups/1363/>.
[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]