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

Versions: 00                                                            
          Network Working Group                       J. O'Hara, M. Rosselli
          Expires May 1997                            New Oak, Axent
          Internet Draft                              November 1997
          
                        Token Card Extensions for ISAKMP/OAKLEY
                            <draft-ohara-tokencard-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).
          
          
          Abstract
          
          The application of IPsec within corporations requires that it
          integrate existing authentication systems. This internet draft
          describes how 2 such systems from Axent Technologies, Inc. and
          Security Dynamics, Inc. can be integrated into ISAKMP.
          
          
          1. Introduction
          
          This Internet Draft describes a mechanism which will allow token
          card authentication to be used in conjunction with ISAKMP
          pre-shared key mechanisms [Mamr97] for creation of IPsec Security
          Associations (SA). This scheme works "in band" with the ISAKMP
          protocol itself, requiring no additional protocols to be used
          between the initiator and responder.
          
          The ISAKMP/Oakley resolution draft defines four "standard" methods
          for authentication: digital signatures using either the Digital
          Signature Standard (DSS) or RSA algorithms, RSA public key
          encryption, and pre-shared secret keys.  Token card vendors such
          as Security Dynamics and AXENT Technologies, however, rely on other
          methods, such as time-variant passwords or challenge-response
          systems for authentication of users, both methods use external
          servers for authentication.  Neither scheme fits well within the
          four supported ISAKMP authentication methods, since all four
          rely on cryptographic techniques in which some secret key (either
          the private half of a public-private key pair, or a shared
          
          O'Hara                                                 [Page 1]


          Internet Draft  Token Card Extensions for ISAKMP/OAKLEY Page 2
          
          secret key) is always kept closely guarded and never transmitted
          across the network, even in encrypted form.  The token card
          schemes also do not provide a key which can be used for the
          protection of the ISAKMP Phase 1 exchange.
          
          However, ISAKMP/Oakley provides for up to (2^16 - 1) potential
          authentication methods.  A portion of that range is reserved for
          "private use among mutually consenting parties".  To enable token
          card authentication between client and server, we defined 2 new
          values within this range to specify the new authentication methods.
          It is envisioned that if this document becomes working group
          chartered IANA will assign non-private numbers.
          
          The standard authentication mechanisms all provide some form of
          protection against what is known as a "man-in-the-middle" attack,
          where a malicious party located between the client and the server
          swaps in her own Diffie-Hellman public value(s) in place of the
          client's and server's, thus allowing her to intercept and decrypt
          all traffic intended to be encrypted between the two parties.
          This attack can only be prevented by the use of either shared
          secret or public-private pair cryptographic mechanisms.  One
          simple approach to prevent such attacks is the use of a
          pre-shared user/group key, which would not authenticate the user
          but which would stop any man-in-the-middle attacks from anyone who
          does not possess the user/group key.
          
          This document assumes that the reader is familiar with the related
          documents "The resolution of ISAKMP with Oakley" [Hark97], and
          the technical specifics of the token card authentication schemes,
          that provide important background for this specification.
          
          In this document, the key words "MAY", "MUST", "recommended",
          "required", and "SHOULD", are to be interpreted as described in
          [RFC-2119].
          
          
          
          2. ISAKMP Extensions.
          
          We will define two private authentication types as follows:
          
          time-variant       w/  Security Dynamics    65001
          challange-repsonse w/ AXENT Technologies    65003
          
          These authentication types will be used by the initiator in the
          SA payload first sent from client to server as part of the first
          message of an ISAKMP Phase 1 exchange.
          
          The token card authentication methods rely on a pre-shared
          user/group key to help protect against man-in-the-middle attacks.
          This user/group key is used in the exactly same manner as [Hark97]
          uses the key for pre-shared key authentication.  Because a
          
          
          
          O'Hara                                                 [Page 2]


          Internet Draft  Token Card Extensions for ISAKMP/OAKLEY Page 3
          
          identifier is needed to identify the proper key, Main Mode cannot
          be used, since Main Mode is restricted to select it's pre-shared
          key on the basis of IP address alone.  Therefore, Aggressive Mode
          MUST be used.
          
          Using the notation of [Hark97], Aggressive Mode using the token
          card authentication types is described as follows:
          
          
                  Initiator                        Responder
                 -----------                      -----------
               HDR, SA, KE, Ni, IDii -->
                                     <--    HDR, SA, KE, Nr, IDir, HASH_R
               HDR, HASH_I, Np       -->
          
          This scheme is nearly identical to that of Aggressive Mode using
          pre-shared key authentication.  The only additional payload is
          Np, a Nonce payload containing additional token card specific
          data which is required to complete the authentication process.
          
          For all token card authentication mechanisms, the Initiator
          SHOULD encrypt the final message of the Aggressive Mode exchange,
          using the key derived from SKEYID_e as described in [Hark97].
          
          The following two sections describe in further detail the data
          necessary for the two specific token card types supported by
          this draft.
          
          2.1 AXENT TECHNOLOGIES Token Cards.
          
          AXENT Technologies token cards utilize a challenge-response system
          for authentication.  In this mechanism, IDii must identify both
          the user/group key and the token card user.  To do so, IDii should
          be of type ID_KEY_ID as defined in {Pip97], and the data should
          be the group ID concatenated with the tokenholder's user ID.  (It
          is recommended that user/group IDs be of fixed length in order to
          allow the user/group ID and token card user ID to be clearly
          delineated.)
          
          The data in Nr should contain the challenge string, followed by
          a zero octet, followed by zero or more additional octets of random
          data to add entropy to the nonce.  The Initiator should extract
          the challenge string from Nr and present it to the user.
          
          The data in Np must contain the user's response to the challenge.
          The Responder MUST make use of both HASH_I and the response in
          Np in order to authenticate the Initiator.
          
          For generating keying material and hashes, SKEYID is derived as
          follows, using the notation of [Hark97]:
          
          SKEYID = prf(group-key, Ni_b | Nr_b)
          
          
          
          O'Hara                                                 [Page 3]


          Internet Draft  Token Card Extensions for ISAKMP/OAKLEY Page 4
          
          
          
          2.2 SECURITY DYNAMICS Token Cards.
          
          Security Dynamics utilizes a time variant password mechanism for
          authentication.  With this mechanism, IDii only needs to identify
          the group whose key will be used.  The data in Np MUST be the
          token card user ID, followed by a zero octet, followed by the
          time variant password.  The Responder MUST make use of both HASH_I
          and Np in order to authenticate the initiator.
          
          SKEYID is derived using the same algorithm as is used for AXENT
          Technologies token cards, described in section 2.1.
          
          Security Dynamics token authentication has two modes, Next Code,
          and New PIN which are not supported by this extension. Next Code
          mode occurs when a token is out of time synchronization with the
          authentication server, or has exceeded a server-defined threshold
          of incorrect codes. The user is required to enter a second code
          from her token in order to successfully authenticate. New PIN mode
          is used to manage the memorized PIN value associated with each token.
          
          If a user's token is in Next Code mode, the ISAKMP authentication
          will fail, and the user will need to perform an out-of-band exchange
          with the authentication server to resynchronize her token. Likewise,
          if a token is in New PIN mode, the user will need to perform an
          out-of-band exchange with the server, to establish her PIN, before
          authenticating via ISAKMP.
          
          
          3. SECURITY Considerations.
          
          The security of this solution depends on the secrecy of the group
          password [Mamr97], used to secure the SA creation during ISAKMP
          Phase 1 and on the strength of the underlying token mechanisms.
          Care should be taken to protect group password (pre-shared key),
          including regular changes, and use of passwords that will not
          fall to common dictionary attacks. In addition, PIN's and other
          secrets must be protected to keep the underlying tokens secure.
          
          
          4. References
          
          
          [Hark97]  Harkins, D., Carrel, D., "The resolution of ISAKMP with
          Oakley", draft-ietf-ipsec-isakmp-oakley-04.txt.
          
          [Mamr97] Mamros, S., "Pre-shared key extensions for ISAKMP/OAKLEY",
          draft-mamros-pskeyext-00.txt, November 1997.
          
          [MSST96] Maughhan, D., Schertler, M., Schneider, M., and Turner, J.,
          "Internet Security Association and Key Management Protocol (ISAKMP)",
          version 8, draft-ietf-ipsec-isakmp-08.{ps,txt}.
          
          
          O'Hara                                                 [Page 4]


          Internet Draft  Token Card Extensions for ISAKMP/OAKLEY Page 5
          
          
          [Orm96] Orman, H., "The Oakley Key Determination Protocol", version
          1, TR97-92, Department of Computer Science Technical Report,
          University of Arizona.
          
          [Pip97] Piper, D., "The Internet IP Security Domain Of Interpretation
          for ISAKMP", version 5, draft-ietf-ipsec-ipsec-doi-05.txt.
          
          [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
          Requirement Levels", RFC2119, March 1997.
          
          5. Acknowledgments
          
          The authors are indebted to John Linn and John Brainard, both of RSA
          Labs, for their contributions, analysis, and review.
          
          
          6. Authors' Addresses
          
          John O'Hara
          New Oak Communications, Inc.
          125 Nagog Park                                     +1 978 266 1011
          Acton, Massachusetts, 01720                        johara@newoak.com
          
          Michael Rosselli
          AXENT Technologies Defender Business Unit
          201 Ravendale Drive                                +1 650-526-2245
          Mountain View, CA. 94043                           mrosselli@axent.com
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          
          O'Hara                                                 [Page 5]