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]