draft-beaulieu-ike-xauth-02.txt

ipsec vpn

                                                            S. Beaulieu
Internet Draft                                               R. Pereira
Document: <draft-beaulieu-ike-xauth-02.txt>               Cisco Systems
Expires April 2002
                                                           October 2001


               Extended Authentication within IKE (XAUTH)


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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.


1. Abstract

   [IKE] allows a device to set up a secure session by using a
   bidirectional authentication method using either pre-shared keys or
   digital certificates.  However [IKE] does not provide a method to
   leverage legacy authentication methods which are widely deployed
   today.

   This document describes a method for using existing unidirectional
   authentication mechanisms such as RADIUS, SecurID, and OTP within
   IPsec's ISAKMP protocol.  The purpose of this draft is not to
   replace or enhance the existing authentication mechanisms described
   in [IKE], but rather to allow them to be extended using legacy
   authentication mechanisms.

   This protocol is designed in such a way that extended authentication
   may be accomplished using any mode of operation for phase 1 (i.e.
   Main Mode or Aggressive Mode) as well as any authentication method
   supported by [IKE].  This protocol may also be easily extended to
   support new modes or authentication methods.  This protocol does
   however require that the phase 1 authentication method be fully
   secure.




Beaulieu, Pereira                                                    1

       Extended Authentication with ISAKMP/Oakley October 2001


   The authors currently intend this document to be published as an
   Informational RFC, not a standards-track document, so that the many
   IPsec implementations that have implemented to earlier drafts of
   this protocol can have a single stable reference.

   Comments regarding this draft should be sent to [e-mail]
   or to the authors.


2. Conventions used in this document

   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 [2].


3. Introduction

   The following technique allows IPsec's ISAKMP/Oakley [IKE] protocol
   to support extended authentication mechanisms like two-factor
   authentication, challenge/response and other remote access
   unidirectional authentication methods.

   These authentication mechanisms have a large deployment in remote
   access applications and many IT departments have requirements for
   these unidirectional authentication mechanisms.

   This draft defines packet formats for a protocol which allows you to
   carry legacy authentication information from one peer to another.
   It does so by extending the [IKECFG] protocol.  This protocol
   requires a sufficient level of security from the phase 1 SA
   authentication.

   This protocol may be used in conjunction with a multitude of
   combinations of modes (i.e. Main Mode, Aggressive Mode, etc) and
   authentication methods (i.e. Pre-Shared keys, RSA Signatures, DSS
   Signatures, etc).  This protocol has also been designed to work
   with any new modes and authentication methods.

   This draft also specifies how to accomplish legacy authentication
   when used with the existing modes and authentication methods defined
   in IKE (the assumption here being that they offer "sufficient" level
   of security to protect the XAUTH exchange).  This is accomplished by
   extending the [IKE] protocol.


   The document has been published as informational as the IPSRA
   working group will not accept any protocol which extends ISAKMP or
   IKE.  Furthermore, the IPsec working group refuses to accept any
   protocols that deal with remote access.

   At the time of the writing of this draft, the IPSRA working group
   has still not defined a protocol to solve the issue of legacy

Beaulieu, Pereira                                                    2

       Extended Authentication with ISAKMP/Oakley October 2001


   authentication.  XAUTH has been in existance for several years, and
   has successfully proven interoperability.  Several vendors have
   implemented and deployed the protocol.  Several vendors wish to
   implement the protocol but have had problems finding the protocol
   specification.  For this reason, the draft is being republished as
   informational to give new vendors an opportunity to interoperate
   with the many existing vendors who implement this protocol today.



3.1. Changes since last revision.

   The last revision of this document was published as "draft-beaulieu-
   ike-xauth-01.txt"

   o clarified text regarding CHALLENGE attribute
   o clarified text regarding NEXT-PIN attribute


3.2. Extended Authentication

   Two-factor authentication and challenge/response schemes like SDI's
   SecurID and RADIUS are forms of authentication that allow a gateway,
   firewall, or network access server to offload the user
   administration and authentication to a central management server.
   IPsec's ISAKMP/Oakley protocol supports certificates (RSA & DSS),
   shared-secret, and Kerberos as authentication methods, but since the
   authentication methods described within this document are only
   unidirectional authentication methods (client to a
   gateway/firewall), they cannot be used by themselves, but must be
   used in conjunction with the other standard ISAKMP authentication
   methods.

   The technique described within this document utilizes ISAKMP to
   transfer the user's authentication information (name, password) to
   the gateway/firewall (edge device) in a secured ISAKMP message. The
   edge device would then use the appropriate protocol (RADIUS,
   SecurID, OTP) to authenticate the user.  This allows the
   authentication server to be within the private network that the edge
   device is protecting.


3.3. Reader Prerequisites

   It is assumed that the reader is familiar with the terms and
   concepts described in the "Security Architecture for the Internet
   Protocol" [ArchSec] and "IP Security Document Roadmap" [Thayer97]
   documents.

   Readers are advised to be familiar with both [IKE] and [ISAKMP] as
   well as [IKECFG] since this document is an extension to that
   document.



Beaulieu, Pereira                                                    3

       Extended Authentication with ISAKMP/Oakley October 2001


4. Vendor ID

   XAUTH currently uses attribute numbers from the private ranges of
   both [IKE] and [IKECFG].  In order to ensure interoperability with
   future and past implementations of XAUTH a Vendor ID has been added.
   The Vendor ID payload is sent during the phase 1 exchange as per
   [ISAKMP].  The vendor id payload SHOULD be authenticated whenever
   possible.  Two IKE implementations which support the [KIV] document
   will be capable of doing this.  The Vendor ID for this revision of
   XAUTH is the following 8 bytes.

   Vendor ID = 0x09002689DFD6B712

   If an implementation receives the aforementioned Vendor ID, it can
   assume that the peer also has implemented this protocol and
   therefore is a "mutually consenting party".

   If this document ever advances to the standard-track, then new
   numbers will be assigned by IANA from the appropriate number spaces
   of [IKE] and [IKECFG], thus eliminating the need for a Vendor ID
   payload.




5. Extended Authentication Method

   This specification allows for extended authentication by allowing an
   edge device to request extended authentication from an IPsec host
   (end-node), thus forcing the host to respond with its extended
   authentication credentials.  The edge device will then respond with
   a failed or passed message.

   When the edge device requests extended authentication, it will
   specify the type of extra authentication and any parameters required
   for it.  These parameters MAY be the attributes that it requires for
   authentication and they MAY be information required for the IPsec
   host's reply (e.g. challenge string).

   The Extended Authentication transaction is terminated either when
   the edge device starts a SET/ACK exchange which includes an
   XAUTH_STATUS attribute or when the remote device sends a
   XAUTH_STATUS attribute in a REPLY message.  Please note that a
   remote device can not set XAUTH_STATUS to anything but FAIL.

   The edge device MAY request multiple different authentication
   transactions within one Extended Authentication transaction.  This
   is done by having multiple REQUEST/REPLY pairs, initiated by the
   edge device, before the transaction is terminated as described
   above.  Each REQUEST/REPLY pair MAY have a different value for
   XAUTH_TYPE.



Beaulieu, Pereira                                                    4

       Extended Authentication with ISAKMP/Oakley October 2001


   As with CHAP [CHAP], this protocol can also be used to periodically
   authenticate the user during the lifetime of a security association.

   If the IPsec host does not have support for the authentication
   method requested by the edge device, then it would send back a REPLY
   with the XAUTH_STATUS attribute set to  FAIL, thus failing the
   authentication but completing the transaction.


   The Extended Authentication mechanism does not effect the nature of
   the phase 1 authentication mechanism in any way. Both peers MUST
   authenticate each other via the authentication methods described in
   [IKE] or some other authentication method in the ISAKMP framework.
   There are Security Considerations involved in at least one of the
   authentication methods in [IKE] and this is described in "Security
   Considerations" below.

   This method provides unidirectional authentication only, meaning
   that only one device is authenticated using both IKE authentication
   methods and Extended Authentication.

   Here are some types of extended authentication that this
   specification supports:



5.1 Simple Authentication

   Where a user name and password are required for authentication.

   IPsec Host                                              Edge Device
   --------------                                    -----------------
                                       <-- REQUEST(NAME="" PASSWORD="")
   REPLY(NAME="joe" PASSWORD="foobar") -->
                                                    <-- SET(STATUS=OK)
   ACK(STATUS) -->

   Some authentication mechanisms hide the user password by some type
   of encryption mechanism.


   IPsec Host                                              Edge Device
   --------------                                    -----------------
                                <-- REQUEST(TYPE=RADIUS-CHAP
                                CHALLENGE="123456" NAME="" PASSWORD="")
   REPLY(TYPE=RADIUS-CHAP NAME="joe" PASSWORD="E4901AB7") -->
                                                    <-- SET(STATUS=OK)
   ACK(STATUS) -->

   NOTE: This is a conceptual example of RADIUS-CHAP, for a more
   detailed example, see Appendix A.


5.2  Challenge/Response


Beaulieu, Pereira                                                    5

       Extended Authentication with ISAKMP/Oakley October 2001



   Where a challenge from the edge device must be incorporated with the
   reply.  This makes each reply different.

   IPsec Host                                              Edge Device
   --------------                                    -----------------
                                      <-- REQUEST(NAME="" PASSWORD="")
   REPLY(NAME="joe" PASSWORD="foobar") -->
                  <-- REQUEST(MESSAGE="Enter your password followed by
                                 your pin number" NAME="" PASSWORD="")
   REPLY(NAME="joe" PASSWORD="foobar0985124") -->