[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
          Network Working Group                       S. Mamros
          Expires May 1997                            New Oak Communications
          Internet Draft                              November 1997
                      Pre-Shared Key Extensions for ISAKMP/Oakley
          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
          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
          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,
          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
          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]