draft-beaulieu-ike-xauth-02.txt

ipsec vpn

                                                    <-- SET(STATUS=OK)
   ACK(STATUS) -->

   If, however, the edge device knows that a challenge will be required
   it may skip the first exchange as follows:

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

5.3 Two-Factor Authentication

   This authentication method combines something the user knows (their
   password) and something that the user has (a token card).

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

   Some mechanisms allow for another optional request of the passcode.

   IPsec Host                                              Edge Device
   --------------                                    -----------------
                          <-- REQUEST(NAME="" PASSWORD="" PASSCODE="")
   REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="323415") -->
                          <-- REQUEST(NAME="" PASSWORD="" PASSCODE="")
   REPLY(NAME="joe" PASSWORD="foobar" PASSCODE="513212") -->
                                                    <-- SET(STATUS=OK)
   ACK(STATUS) -->
5.4 One-Time-Password

   Similar to the Challenge/Response method, this method allows
   authentication that is secure against passive attacks based on
   replaying captured passwords.



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


   IPsec Host                                              Edge Device
   --------------                                    -----------------
                              <-- REQUEST(TYPE=OTP CHALLENGE, NAME="")
   REPLY(TYPE=OTP_CHALLENGE, NAME="joe")-->
                   <-- REQUEST(TYPE=OTP CHALLENGE="otp-md5 499 ke1234"
                                                  NAME="" PASSWORD="")
   REPLY(TYPE=OTP NAME="joe" PASSWORD="5bf0 75d9 959d 036f") -->
                                                    <-- SET(STATUS=OK)
   ACK(STATUS) -->


5.5 User Previously Authenticated

   Some situations may occur where the edge device has already
   authenticated the host and no new authentication is required.  This
   may happen when either the host or the edge device must rekey an
   existing phase 1 SA.  It is important that this method not be used,
   unless the implementation can be sure that the current phase 1 SA
   was created with the same peer as the initial phase 1 SA, which was
   previously authenticated using XAUTH.  There is currently no way
   defined to ensure that two separate phase 1 SAs actually belong to
   the same peer.  One method suggested is to use the ID from the phase
   1 negotiation (available in Main Mode and Aggressive Mode) but only
   if the ID is unique to the user and cannot not be forged.  This
   concept is herein referred to as "ID-Checking".

   Implementation hint:

   o In order to accomplish ID-Checking for Phase 1 Authenticated With
   a Pre-Shared Key (as defined in [IKE]), the pre-shared key lookup
   must be based on the phase 1 ID.  Please note that this method only
   currently works for Aggressive Mode, and may work with modes defined
   in the future.  A static IP address could also be used for shared
   secret lookup, however, the binding of the user to XAUTH session
   would have to use the IP address instead of the ID.


   o In order to accomplish ID-Checking for IKE Phase 1 Authenticated
   With Signatures (as defined in [IKE]), the implementation must
   ensure that the ID provided in the phase 1 exchange matches the ID
   in the peer's certificate which must be signed by a trusted third
   party.



   In the situation where the peer does not require additional
   authentication, the following method is used.

   IPsec Host                                              Edge Device
   -------------                                      ----------------
                                                    <-- SET(STATUS=OK)
   ACK(STATUS) -->


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


5.6 Other Useful Examples

   More useful examples are found in Appendix A.


6 Extensions to ISAKMP-Config

   This protocol uses the mechanisms described in ISAKMP-Config
   [IKECFG] to accomplish its authentication transaction.  This
   protocol uses Configuration Attributes from the private range of
   Isakmp-Config [IKECFG].  To ensure interoperability with past and
   future versions of Extended Authentication, a Vendor ID is provided
   in section 2.

   All ISAKMP-Config messages in an extended authentication transaction
   MUST contain the same ISAKMP-Config transaction identifier.  The
   Message ID in the ISAKMP header follows the rules defined by the
   ISAKMP-Config protocol.

   This protocol can therefore be used in conjunction with any existing
   basic ISAKMP authentication method as defined in [IKE].

   This authentication MUST be used after a phase 1 exchange has
   completed and before any other exchange with the exception of Info
   mode exchanges. If the extended authentication fails, then the phase
   1 SA MUST be immediately deleted.  The edge device MAY choose to
   retry an extended authentication request if the user failed to be
   authenticated, but must do so in the same ISAKMP-Config transaction,
   and MUST NOT send the SET message until the user is authenticated,
   or until the edge device wishes to stop retrying and fail the user.

   Extended Authentication MAY be initiated by the edge device at any
   time after the initial authentication exchange.  For example, RADIUS
   servers may specify that a user only be authenticated for a certain
   time period.  Once that time period has elapsed (minus a possible
   jitter), the edge device may request a new Extended Authentication
   exchange.  If the Extended Authentication exchange fails, the edge
   device MUST tear down all phase 1 and phase 2 SAs associated with
   the user.

   The following are extensions to the ISAKMP-Config [IKECFG]
   specification to support Extended Authentication.

6.1 Message Types

   Type                        Value
   --------------------------  -----------------------------
    ISAKMP-CFG-REQUEST         ( as defined in [IKECFG] )
    ISAKMP-CFG-REPLY           ( as defined in [IKECFG] )
    ISAKMP-CFG-SET             ( as defined in [IKECFG] )
    ISAKMP-CFG-ACK             ( as defined in [IKECFG] )



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


   ISAKMP-CFG-REQUEST - This message is sent from an edge device to an
   IPsec host trying to request extended authentication.  Attributes
   that it requires sent back in the reply MUST be included with a
   length of zero (0).  Attributes required for the authentication
   reply, such as a challenge string MUST be included with the proper
   values filled in.

   ISAKMP-CFG-REPLY - This message MUST contain the filled in
   authentication attributes that were requested by the edge device or
   if the proper authentication attributes can not be retrieved, then
   this message MUST contain the XAUTH-STATUS attribute with a value of
   FAIL.

   ISAKMP-CFG-SET - This message is sent from an edge device and is
   only used, within the scope of this document, to state the success
   of the authentication.  This message MUST only include the success
   of failure of the authentication and MAY contain some clarification
   text.

   ISAKMP-CFG-ACK - This message is sent from the IPsec host
   acknowledging receipt of the authentication result.  Its attributes
   are not relevant and MAY be skipped entirely, thus no attributes
   SHOULD be included.  This last message in the authentication
   transaction is used solely as an acknowledgement of the previous
   message and to eliminate problems with unacknowledged messages over
   UDP.

6.2 Attributes

    Attribute                 Value      Type
    ---------------------     ------     ---------------------
    XAUTH-TYPE                16520         Basic
    XAUTH-USER-NAME           16521         Variable ASCII string
    XAUTH-USER-PASSWORD       16522         Variable ASCII string
    XAUTH-PASSCODE            16523         Variable ASCII string
    XAUTH-MESSAGE             16524         Variable ASCII string
    XAUTH-CHALLENGE           16525         Variable ASCII string
    XAUTH-DOMAIN              16526         Variable ASCII string
    XAUTH-STATUS              16527         Basic
    XAUTH-NEXT-PIN            16528         Variable ASCII string
    XAUTH-ANSWER              16529         Variable ASCII string

   NOTE: Variable ASCII strings need not be NULL-terminated, as the
   length field in the attribute header is sufficient to properly
   format the strings.

   XAUTH-TYPE - The type of extended authentication requested whose
   values are described in the next section.  This is an optional
   attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY messages.
   If the XAUTH-TYPE is not present, then it is assumed to be Generic.
   The XAUTH-TYPE in a REPLY MUST be identical to the XAUTH-TYPE in the
   REQUEST.  If the XAUTH-TYPE was not present in the REQUEST, then it
   MUST NOT be present in the REPLY.  However, an XAUTH transaction MAY

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


   have multiple REQUEST/REPLY pairs with different XAUTH-TYPE values
   in each pair.

   XAUTH-USER-NAME - The user name MAY be any unique identifier of the
   user such as a login name, an email address, or a X.500
   Distinguished Name.

   XAUTH-USER-PASSWORD - The user's password.

   XAUTH-PASSCODE - A token card's passcode.

   XAUTH-MESSAGE - A textual message from an edge device to an IPsec
   host.  The message may contain a textual challenge or instruction.
   An example of this would be "Enter your password followed by your
   pin number".  The message may also contain a reason why
   authentication failed or succeeded.  This message SHOULD be
   displayed to the user.

   XAUTH-CHALLENGE - A challenge string sent from the edge device to
   the IPsec host for it to include in its calculation of a password.
   This attribute SHOULD only be sent in an ISAKMP-CFG-REQUEST message.
   Typically, the XAUTH-TYPE attribute dictates how the receiving
   device should handle the challenge.  For example, RADIUS-CHAP uses
   the challenge to hide the password.  The XAUTH-CHALLENGE attribute
   MUST NOT be used when XAUTH-TYPE is set to generic.

   XAUTH-DOMAIN - The domain to be authenticated in.  This value will
   have different meaning depending on the authentication type.

   XAUTH-STATUS - A variable that is used to denote authentication
   success (OK=1) or failure (FAIL=0).  This attribute MUST be sent in
   the ISAKMP-CFG-SET message, in which case it may be set to either OK
   or FAIL, and MAY be sent in a REPLY message by a remote peer, in
   which case it MUST be set to FAIL.

   XAUTH-NEXT-PIN - A variable which is used when the edge device is
   requesting that the user choose a new pin number.  This attribute
   MUST NOT be used in conjunction with any attributes other than
   XAUTH-MESSAGE and / or XAUTH-TYPE.

   XAUTH-ANSWER - A variable length ASCII string used to send input to
   the edge device.  An edge device MAY include this attribute in a
   REQUEST message in order to prompt an answer from the user, though
   it MUST be accompanied by an XAUTH-MESSAGE attribute. This attribute
   MUST NOT be used in conjunction with any attributes other than
   XAUTH-TYPE or XAUTH-MESSAGE.

6.3 Authentication Types

    Value         Authentication Required
    -----         ---------------------------------




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


       0           Generic
       1           RADIUS-CHAP
       2           OTP
       3           S/KEY
       4-32767     Reserved for future use
       32768-65535  Reserved for private use

   Generic - A catch-all type that allows for future extensibility and
   a generic mechanism to request authentication information. This
   method allows for any type of extended authentication which does not
   require specific processing, and should be used whenever possible.
   This is the default setting if no XAUTH_TYPE is present.

   RADIUS-CHAP - RADIUS-CHAP is one method of authentication defined in
   [RADIUS] which uses a challenge to hide the password.  In order to
   use the CHAP functionality defined in [RADIUS], the XAUTH_TYPE MUST
   be set to RADIUS-CHAP.  For all other methods defined in [RADIUS]
   (i.e. PAP), the XAUTH_TYPE MUST be set to Generic.

   OTP - One-Time-Passwords as defined in [OTP] uses a challenge string
   to request a certain generated password.  The request SHOULD contain
   a user name, password and a challenge string while the reply MUST
   contain the user name and the generated password.  The challenge
   string is formatted as defined in [OTPEXT].
   S/KEY - This one-time-password scheme defined in [SKEY] was the
   precursor to OTP, thus the same rules applies.