Internet Draft P. MacKenzie
Document: draft-mackenzie-ips-iscsi-pak-00.txt Lucent Technologies
Expires: November 2002 May 2002
PAK: Password-Authenticated Key Exchange for iSCSI
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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.
Abstract
This draft describes a password-authenticated key exchange protocol
called PAK [PAK,PAK-Orig] that is secure against both a passive
eavesdropper and an active attacker, i.e., one who may insert, block,
or modify messages sent over a network. In particular, it does not
allow either type of attacker to obtain any information that would
enable an off-line dictionary attack on the password. We discuss how
this password-authenticated key exchange protocol may be used with
iSCSI [iSCSI].
1. Introduction
PAK [PAK] is a password-authenticated key exchange protocol that is a
refinement of the Diffie-Hellman-based EKE protocol [EKE]. It is
designed to be secure against both a passive eavesdropper and an
active "man-in-the-middle" attacker, who may insert, block, or modify
messages sent between the participants of the protocol. In
particular, neither type of attacker can obtain information to enable
an offline dictionary attack on the password. Thus the only attack
allowed is an online attack, in which the attacker can test at most
MacKenzie [Page 1]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
one password per online authentication attempt.
The security of the PAK protocol relies on the security of
unauthenticated Diffie-Hellman key exchange [DH], plus the security
of the hash function used. In fact, assuming that the hash function
is random (i.e., assuming the "random oracle" model [BR]), it has
been shown that breaking the PAK protocol with success better than
that of a simple online attack implies that a passive eavesdropper
could break an unauthenticated Diffie-Hellman key exchange [PAK].
2. Notations, Conventions, and Terminology
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.
All hash functions operate on and produce byte strings.
The notation <a|b|...|z> denotes the concatenation of the byte
strings a,b,...,z. The *, ^, and % operators denote multiplication,
exponentiation and modular reduction, respectively. The XOR operator
denotes the exclusive-or operation.
The := operator denotes the assignment of a value to a variable.
For 0<=i<=255, the notation [i] denotes the byte i.
The notation "a := Random(S)" denotes the assignment of a random
element from the set S to the variable a. The notation "Z_a" denotes
the set {0,1,...,a-1} (i.e., the integers modulo a), and for a prime
N, the notation "Z*_N" denotes the set {1,2,...,N-1} (i.e., the
multiplicative group of integers modulo N).
We use the same convention as [Jablon] in implicit conversion between
byte strings and unsigned big integers when necessary, with the first
bits of a byte string representing the high order bits of the
corresponding integer. In particular, we implicitly use the OS2IP
and FE2OSP conversion operators from [IEEE 1363].
We use the following parameters:
N field order, a 1024-bit prime of the form kq + 1
q order of the multiplicative group, a 160-bit prime
k the "co-factor" (about 864-bits)
g a generator of the subgroup of Z*_N of order q
hash a hash function with output in Z*_N based on SHA-1
kdf a hash function with 128-bit output based on SHA-1
MacKenzie [Page 2]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
The parameters N, q, k, and g are of the same type as those used in
the US Government DSA signature algorithm [FIPS186]. Note that for
efficiency these use a 160-bit subgroup of the multiplicative group
modulo N, and thus they allow (short) 160-bit exponents.
In practice, we expect to have a list of fixed standard values for N,
q, k, and g that the two parties in the protocol may agree on. For
instance, the following parameters are used for PAK in the Plan9
distribution [Plan9] (in hex):
N: C41CFBE4D4846F67A3DF7DE9921A49D3B42DC33728427AB159CEC8CBB
DB12B5F0C244F1A734AEB9840804EA3C25036AD1B61AFF3ABBC247CD4
B384224567A863A6F020E7EE9795554BCD08ABAD7321AF27E1E92E3DB
1C6E7E94FAAE590AE9C48F96D93D178E809401ABE8A534A1EC4435973
3475A36A70C7B425125062B1142D
q: E0F0EF284E10796C5A2A511E94748BA03C795C13
k: DF310F4E54A5FEC5D86D3E14863921E834113E060F90052AD332B3241
CEF2497EFA0303D6344F7C819691A0F9C4A773815AF8EAECFB7EC1D98
F039F17A32A7E887D97251A927D093F44A55577F4D70444AEBD06B9B4
5695EC23962B175F266895C67D21C4656848614D888A4
g: 2F1C308DC46B9A44B52DF7DACCE1208CCEF72F69C743ADD4D23271734
44ED6E65E074694246E07F9FD4AE26E0FDDD9F54F813C40CB9BCD4338
EA6F242AB94CD410E676C290368A16B1A3594877437E516C53A6EEE54
93A038A017E955E218E7819734E3E2A6E0BAE08B14258F8C03CC1B30E
0DDADFCF7CEDF0727684D3D255F1
Both hash and kdf are assumed to have the properties of a random
oracle, and thus we define them as follows, using SHA-1 [SHA1] as the
basis:
f1(x) := SHA-1(x) mod 2^128
f2(x,j) := < f1(<[1]|x>) | f1(<[2]|x>) | ... | f1(<[j]|x>) >
kdf(x) := f1(<len(x)|x>)
hash(x) := (f2(<len(x)|x>,9) % (N-1))+1
The function len(x) denotes the bit length of x stored in a 32-bit
word in big-endian order, i.e., high byte first. We prepend len(x)
to x in order to prevent simple padding attacks on SHA-1, given that
our inputs may have variable lengths. Note that hash(x) always
produces a value in Z*_N. Also, in hash(x) we use f2(-,9) instead of
f2(-,8) in order to produce a final output that is more uniformly
distributed in Z*_N.
MacKenzie [Page 3]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
3. PAK protocol
3.1 Initialization
Before any authentication and key exchange protocol, the client and
server must have their shared secrets initialized. The client must
remember a password p, while the server stores
v := (hash(<T0|p>))^(-k) % N,
along with the client's username U, and the paramIndex indicating the
set of parameters (N,q,k,g) to be used. (Note that the server could
simply store the password instead of v, but that would force the
server to do an exponentiation by k in each session.) The value T0
is the type, which is defined below to be [0].
3.2 The PAK protocol
3.2.1 Identification and Parameter Selection
The first two messages are for the client to send a username U to the
server, and for the server to respond with the index of the set of
Diffie-Hellman parameters. As is the case with SRP authentication in
iSCSI, these are announced parameters that cannot be negotiated; the
client MUST either accept them or close the connection.
Client Server
U
----------------------------->
Retrieve (U,v,paramIndex)
Retrieve (N,q,k,g) using paramIndex
paramIndex
<-----------------------------
Retrieve (N,q,k,g) using paramIndex
3.2.2 Key Exchange
The intuition behind the PAK protocol is that it does a standard
unauthenticated Diffie-Hellman, except that it multiplies the
client's Diffie-Hellman value by the hash of the password (raised to
the power k so the result lies in the subgroup of order q). We say
that the client's value is "entangled" with the password. The client
MacKenzie [Page 4]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
then receives the server's Diffie-Hellman value and a key
confirmation hash, and if it is OK, sends out its own key
confirmation hash.
IMPORTANT: As is specified in the protocol description below, the
client MUST receive and verify a key confirmation from the server
before continuing with the protocol. The basic reason is that the
server's Diffie-Hellman value has not been entangled with the
password (see [PAK] for details), and thus without this verification,
an active attacker may obtain enough information to perform an
offline dictionary attack.
On the server side, the server retrieves the entangled value from the
client, checks that it is not equal to zero modulo N, computes its
own Diffie-Hellman value, and disentangles the value retrieved from
the client in order to compute the Diffie-Hellman secret. Then it
sends back its own Diffie-Hellman value and a key confirmation hash,
and waits for the client to send its key confirmation hash.
IMPORTANT: As is specified in the protocol description below, the
server MUST verify that the value received by the client is not equal
to zero modulo N (i.e., that it is not equal to zero nor any multiple
of N). If this is not done, then an active attacker may obtain
enough information to perform an offline dictionary attack.
The protocol is as follows, with the values U, v, N, q, k, and g
taken from the identification and parameter selection protocol above.
MacKenzie [Page 5]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
Client Server
x := Random(Z_q)
a := g^x % N
u := (hash(<T0|p>))^k % N
m := a*u % N
m
----------------------------->
Abort if (m % N) = 0
y := Random(Z_q)
w := g^y % N
a := m*v % N
s := a^y % N
c0 := kdf(<T1|U|m|w|s|v>)
<w,c0>
<-----------------------------
s := w^x % N
v := u^(-1) % N
Abort if c0 <> kdf(<T1|U|m|w|s|v>)
c1 := kdf(<T2|U|m|w|s|v>)
K := kdf(<T3|U|m|w|s|v>)
c1
----------------------------->
Abort if
c1 <> kdf(<T2|U|m|w|s|v>)
K := kdf(<T3|U|m|w|s|v>)
All values from Z*_N input to kdf and hash are assumed to be stored
in big-endian order, and MUST include any necessary leading 0 bits to
be of full size, i.e., |m|=|w|=|s|=|v|=1024. This prevents any types
of unforeseen "collisions" that could occur when hashing two or more
values of variable length, e.g., h("xy"|"z") = h("x"|"yz").
K is the shared session key.
The values T0,T1,T2,T3 are the types of the functions, and are
defined as
T0 := [0]
T1 := [1]
T2 := [2]
T3 := [3]
MacKenzie [Page 6]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
4. Discussion
4.1 External Authentication Servers
We note that authentication in PAK cannot be outsourced to a RADIUS
server that does not implement EAP, since it is essential to the key
exchange to have the password hash v.
4.2 PAK and EAP
The Extensible Authentication Protocol (EAP) (defined in [RFC 2284],
being updated in [2284bis]) describes a framework that allows the use
of multiple authentication mechanisms. In a future draft we will
provide the details of how to incorporate PAK into EAP, most likely
based on [EAP-SRP].
5. Security Considerations
The main reason to use PAK for password-authenticated key exchange is
to obtain the strongest security possible for key exchange, while
using passwords (i.e., relatively short secrets) for authentication.
In particular, PAK achieves security against active attackers, so
that no information is leaked to allow an offline dictionary attack
on the password. By comparison, the DH-CHAP protocol [DH-CHAP] is
only designed to be secure against passive eavesdroppers.
As discussed above, PAK has a mathematical proof of security against
active attackers, when the hash functions are assumed to behave like
random functions. (This is a very common assumption to use for
practical security protocols, such as OAEP [OAEP,OAEP+,RSA-OAEP].)
In comparison, neither the SRP protocol [RFC 2945] nor the SPEKE
protocol [SPEKE] have this level of proven security.
Note that the version of PAK we are proposing does not attempt to
provide security against insider attacks on the server. That is,
someone who obtains the password file from the server may impersonate
a client, without even running a dictionary attack. In constrast,
SRP is designed to force someone who obtains the password file to run
an offline dictionary attack before impersonating a client. There are
extensions to PAK that also provide this security property [PAK], and
these could be proposed in future drafts.
6. Intellectual Property Notice
This is to inform you that Lucent Technologies has applied for and/or
has patent(s) that relates to the attached submission.
MacKenzie [Page 7]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
This submission is being made pursuant to the provisions of IETF IPR
Policy, RFC 2026, Sections 10.3.1 and 10.3.2.
Lucent Technologies Inc. will offer patent licenses for submissions
made by it which are adopted as a standard by your organization as
follows:
If part(s) of a submission by Lucent is included in a standard and
Lucent has patents and/or pending applications that are essential to
implementation of the included part(s) in said standard, Lucent is
prepared to grant - on the basis of reciprocity (grant back) - a
license on such included part(s) on reasonable, non-discriminatory
terms and conditions.
Acknowledgements
The PAK protocol described in this document is a result of work by
the author in collaboration with Victor Boyko, Sarvar Patel, and Eric
Grosse. Many thanks to Daniel Bleichenbacher, Sarvar Patel, Eric
Grosse, and Jeff Fellin for helpful comments on this draft.
References
[BR] M. Bellare, P. Rogaway, "Random oracles are practical: A
Paradigm for Designing Efficient Protocols," In 1st ACM Conference
on Computer and Communications Security, pp. 62-73, November 1993.
[OAEP] M. Bellare, P. Rogaway, "Optimal Asymmetric Encryption," In
Eurocrypt '94 (Lecture Notes in Computer Science 950), pp. 92-111,
1995.
[EKE] Bellovin S., and M. Merritt, "Encrypted Key Exchange:
Password-based protocols secure against dictionary attacks," In
IEEE Symposium on Research in Security and Privacy, pp. 72-84, May
1992.
[DH-CHAP] D. Black, "DH-CHAP: Diffie-Hellman Enhanced CHAP for
iSCSI," draft-black-ips-iscsi-dhchap-00.txt, Work in Progress,
April 2002.
[RFC 2284] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)," RFC 2284, March 1998
[2284bis] L. Blunk, J. Vollbrecht, B Aboba, "Extensible
Authentication Protocol (EAP)," draft-ietf-pppext-rfc2284bis-
03.txt, Work in Progress, 2 April 2002
MacKenzie [Page 8]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
[PAK-Orig] V. Boyko, P. MacKenzie, S. Patel, "Provably Secure
Password Authentication and Key Exchange using Diffie-Hellman,"
Eurocrypt 2000 (Lecture Notes in Computer Science 1807), pp. 156-
171, 2000.
[EAP-SRP] J. Carlson, B. Aboba, H. Haverinen, "EAP SRP-SHA1
Authentication Protocol", draft-ietf-pppext-eap-srp-03.txt, Work
in Progress, July 2001
[RSA-OAEP] E. Fujisaki, T. Okamoto, D. Pointcheval, J. Stern, "RSA-
OAEP is Secure under the RSA Assumption," In Crypto 2001 (Lecture
Notes in Computer Science 2139), pp. 260-274, 2001.
[P1363.2] IEEE P1363.2, "Standard Specifications for Public-Key
Cryptography: Password-Based Techniques", (work in progress),
IEEE, <http://grouper.ieee.org/groups/1363/>.
[FIPS186] FIPS186, "Digital Signature Standard," U.S. Department of
Commerce/NIST National Technical Information Service, Springfield,
VA, 1994.
[SPEKE] D. Jablon, "The SPEKE Password-Based Key Agreement Methods,"
draft-jablon-speke-00.txt, February 2002.
[PAK] P. MacKenzie, "The PAK Suite: Protocols for Password-
Authenticated Key Exchange," manuscript, April 2002.
<http://cm.bell-labs.com/who/philmac/research/pak-suite.pdf>
[SHA1] National Institute of Standards and Technology (NIST),
"Announcing the Secure Hash Standard", FIPS 180-1, U.S.
Department of Commerce, April 1995.
[Plan9] R. Pike, D. Presotto, S. Dorward, B. Flandrena, K. Thompson,
H. Trickey, P. Winterbottom, "Plan 9 from Bell Labs," Computing
Systems, Vol. 8, No. 3, pp. 221-254, 1995. (http://netlib.bell-
labs.com/plan9dist/)
[iSCSI] Satran, J., et. al., "iSCSI", draft-ietf-ips-iscsi-11.txt,
Work in Progress, March 2002.
[OAEP+] V. Shoup, "OAEP Reconsidered," In Crypto 2001 (Lecture Notes
in Computer Science 2139), pp. 239-259, 2001.
[RFC 2945] Wu, T., "The SRP Authentication and Key Exchange System",
RFC 2945, September 2000.
MacKenzie [Page 9]
Internet Draft draft-mackenzie-ips-iscsi-pak-00.txt April 2002
Author's Address
Philip MacKenzie
Lucent Technologies
Bell Laboratories
600 Mountain Ave.
Murray Hill, NJ 07974
Phone: (908) 582-7625
EMail: philmac@lucent.com
Full Copyright Statement
"Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
MacKenzie [Page 10]