Network Working Group S. Mamros
Expires May 1997 New Oak Communications
Internet Draft November 1997
Pre-Shared Key Extensions for ISAKMP/Oakley
<draft-mamros-pskeyext-00.txt>
Status of this Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. This draft will
expire six months from date of issue.
1. Abstract
The application of IP Security for remote access over the
Internet requires that it support ''traditional'' authentication
paradigms. This document describes how a traditional
username and passphrase-style mechanism can be integrated into
the existing pre-shared key authentication mechanism in
ISAKMP/Oakley.
2. Introduction
ISAKMP/Oakley [Hark97] provides several authentication
methods. Of these, only the pre-shared key authentication
method can be made to work in the absence of a public key
infrastructure. While it is expected that usage of public
key mechanisms will increase substantially in the near
future, many sites which want to use IP Security as a tunnelling
mechanism for remote access over the Internet may not be
able or willing to convert their existing systems to use
public key technology right away. Thus, these sites will
need to use pre-shared key authentication in one form or
another.
Mamros [Page 1]
Internet Draft - Pre-Shared Key Extensions for ISAKMP Page 2
ISAKMP/Oakley provides both Main Mode and Aggressive Mode
as the two basic methods for establishing an authenticated
key exchange. However, Main Mode using pre-shared key
authentication is restricted to using only the IP addresses
of the initiator and responder as the means to select a key.
Remote access solutions require user-based keying, which
means that Aggressive Mode is the only viable method which
can be used with pre-shared keys.
The major drawback to Aggressive Mode is that, unlike Main
Mode, one cannot protect the identities of the initiator and
responder; these must be transmitted in the clear. Another
element which must be transmitted in the clear is the
responder's hash, designated as HASH_R in [Hark97]. When
pre-shared key authentication is being used, HASH_R is
derived from a combination of the pre-shared key and the
nonces, ISAKMP cookies, and publicly-exchanged Diffie-Hellman
values of both the initiator and responder, plus the
responder's identity. The only "secret" element among those
used to calculate HASH_R is the pre-shared key itself; all
of the other elements are transmitted in the clear in the
first two messages of Aggressive Mode. The security of
HASH_R is thus entirely dependent on the security of the
pre-shared key itself, which in turn relies on the effective
key length.
The "traditional" method of using a username for
identification, and a passphrase for authentication, is
still in common use at many sites. Such sites may be
tempted to map the username/passphrase directly to the
ISAKMP/Oakley pre-shared authentication mechanism, with
the username being used for the initiator's identity
(designated as IDii in [Hark97]) and the passphrase being
employed as the pre-shared key. However, the lack of
identity protection in Aggressive Mode, coupled with a
relatively small search space for text-based passphrases,
makes this approach vulnerable to brute-force searches of
the passphrase via analysis of HASH_R.
This document defines an alternate approach through which
usernames and passphrases may be used in conjunction with
pre-shared key authentication, while providing somewhat
better protection for the identity and also expanding the
brute-force key space. The method described here employs
an additional algorithm for deriving the values used for
IDii and the pre-shared key; these values are then used
as-is in the standard algorithms defined in [Hark97] for
deriving keys and hash values.
Mamros [Page 2]
Internet Draft - Pre-Shared Key Extensions for ISAKMP Page 3
3. Terms and Definitions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as
described in [RFC-2119].
4.1. Derivation of Initiator Identity (IDii)
The initiator identity (IDii) is derived by performing a
SHA-1 [SHA] hash calculation over the username. Any
characters used to terminate or delimit the username string,
such as a zero octet, MUST NOT be included in the hash
calculation. If the environment in which the username is
defined considers usernames to be case-insensitive, any
uppercase alphabetical characters (A-Z) in the username
MUST be converted to their lowercase equivalents (a-z)
before performing the hash calculation.
The initiator places the SHA-1 hash in the Identification
Data field of the Identification Payload designated as IDii
in its initial message to the responder in Aggressive Mode.
The ID Type field MUST be ID_KEY_ID, as defined in [Pip97].
The responder stores a table of SHA-1 hashes mapped to their
respective usernames and their corresponsing passphrases.
4.2. Derivation of the Pre-Shared Key
The pre-shared key is derived by using the HMAC algorithm
[RFC-2104] in conjunction with the SHA-1 hash algorithm,
with the passphrase used as the key and the plaintext
username as the "message". In the notation of [Hark97],
pre-shared-key = prf(passphrase, username)
where the pseudo-random function is HMAC-SHA-1.
As with the IDii derivation described above, terminating
and delimiting characters (such as zero octets) MUST NOT
be included in the calculation. If usernames are case-
insensitive, uppercase alphabetical characters MUST be
converted to lowercase before applying this algorithm.
However, mixed-case passphrases MUST be supported, and the
case of all alphabetic characters in the passphrase MUST be
preserved in the calculation. The resulting 160-bit hash
value MUST be used in its entirety as the pre-shared key.
Mamros [Page 3]
Internet Draft - Pre-Shared Key Extensions for ISAKMP Page 4
5. Security Considerations
The methods described in this document do not purport to
be a solution for all of the problems which face any system
relying on username/passphrase authentication for security.
A weak passphrase can compromise the security of any such
system. Also, physical and logical security of the
username/passphrase database is crucially important.
The method for deriving IDii does provide some level of
identity obfuscation, but it falls short of full identity
protection as provided by Main Mode. One can compare
the value of IDii with the values used in previous exchanges
to determine whether or not the same user initiated a prior
exchange. We rely on the collision and reversability
resistance and properties of SHA-1 to protect the original
username.
The algorithm for deriving the pre-shared key is stronger
than using the passphrase as-is for the key only if the
plaintext username is not revealed to an attacker. Security
administrators may wish to consider the use of different
usernames for remote access under this scheme than those
which are used for other systems such as electronic mail.
6. References
[Hark97] Harkins, D., Carrel, D., "The resolution of ISAKMP with
Oakley", draft-ietf-ipsec-isakmp-oakley-05.txt.
[Pip97] Piper, D., "The Internet IP Security Domain Of Interpretation
for ISAKMP", draft-ietf-ipsec-ipsec-doi-06.txt.
[RFC-2104] Krawczyk, H., Bellare, M., and Canetti, R.,
"HMAC: Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC-2119] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC 2119, March 1997.
[SHA] NIST, FIPS PUB 180-1, Secure Hash Standard, April 1995.
http://csrc.nist.gov/fips/fip180-1.txt (ascii)
http://csrc.nist.gov/fips/fip180-1.ps (postscript)
7. Author's Address
Shawn Mamros
New Oak Communications, Inc.
125 Nagog Park +1 978 266 1011
Acton, Massachusetts, 01720 smamros@newoak.com
Mamros [Page 4]