[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06                                          
Internet Engineering Task Force                             R. Pereira
IP Security Working Group                                  S. Beaulieu
Internet Draft                                    TimeStep Corporation
Expires November 17, 1999
                                                          May 17, 1999



             Extended Authentication within ISAKMP/Oakley
                <draft-ietf-ipsec-isakmp-xauth-04.txt>



Status of this Memo

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

   This document is a submission to the IETF Internet Protocol
   Security (IPSECond) Working Group. Comments are solicited and
   should be addressed to the working group mailing list
   (ipsec@lists.tislabs.com) or to the editor.

   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 draft documents are valid for a maximum of six
   months and may be updated, replaced, or made obsolete 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.

   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), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998-1999).  All Rights
   Reserved.






R. Pereira, S. Beaulieu                                       [Page 1]


Internet Draft                                                  May-99

Abstract

   This document describes a method for using existing unidirectional
   authentication mechanisms such as RADIUS, SecurID, and OTP within
   IPSec's ISAKMP protocol.


Table of Contents


1 Introduction.......................................................2
1.1 Changes Since Last Revision......................................3
1.2 Extended Authentication..........................................3
1.3 Reader Prerequisites.............................................3
1.4 Specification of Requirements....................................4
2 Extended Authentication Method.....................................4
2.1 Simple Authentication............................................5
2.2 Challenge/Response...............................................5
2.3 Two-Factor Authentication........................................6
2.4 One-Time-Password................................................7
2.5 User Previously Authenticated....................................7
3 Extensions to ISAKMP-Config........................................7
3.1 Message Types....................................................8
3.2 Attributes.......................................................9
3.3 Authentication Types............................................10
4 Authentication Method Types.......................................11
5 Other Scenarios for Extended Authentication.......................13
6 Security Considerations...........................................13
7 References........................................................13
8 Acknowledgements..................................................14
9 AuthorsÆ Addresses................................................15
10 Expiration.......................................................15
11 Full Copyright Statement.........................................15




1  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.





R. Pereira, S. Beaulieu                                       [Page 2]


Internet Draft                                                  May-99

1.1 Changes Since Last Revision


   o The last revision of this document was published in the IPSec
   Working Group as
      <draft-ietf-ipsec-isakmp-xauth-03.txt>

   o Some text was added to describe how to separate phase 1 rekeying
   and Extended Authentication.

   o Isakmp authentication method values were defined for Extended
   Authentication.

   o A correction was made in the RADIUS challenge example.  RADIUS
   uses the Message Attribute to transmit a challenge, unless it is a
   CHAP challenge.

   o Added more emphasis on using GENERIC type whenever possible.


1.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 either 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.


1.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.





R. Pereira, S. Beaulieu                                       [Page 3]


Internet Draft                                                  May-99

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


1.4 Specification of Requirements

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD
   NOT", and "MAY" that appear in this document are to be interpreted
   as described in [Bradner97].


2  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 last message sent by the edge device is simply a reply denoting
   failure or success.  The reply MAY have some textual information
   describing the reason for the failure or success.  The edge device
   MAY also request another authentication, like SecurID's next PIN
   request, where the user is required to enter the next passcode to
   further verify itself.

   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 empty attributes, thus failing the authentication but
   completing the transaction.  The last exchange (SET/ACK) MUST also
   be completed.

   The Extended Authentication mechanism does not replace the IKE
   Phase 1 authentication mechanisms.  It simply extends them by
   allowing devices to do two different authentication schemes.  Both
   peers SHOULD still authenticate themselves via the authentication
   methods described in [IKE].





R. Pereira, S. Beaulieu                                       [Page 4]


Internet Draft                                                  May-99

   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;


2.1 Simple Authentication

   Where a user name and password are required for authentication.

   IPSec Host                                              Edge Device
   --------------                                    -----------------
                         <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="")
   REPLY(TYPE=GENERIC 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 CHALLENGE="123456"
                                                  NAME="" PASSWORD="")
   REPLY(TYPE=RADIUS NAME="joe" PASSWORD="E4901AB7") -->
                                                    <-- SET(STATUS=OK)
   ACK(STATUS) -->



2.2 Challenge/Response

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

   IPSec Host                                              Edge Device
   --------------                                    -----------------
                         <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD="")
   REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar") -->
                 <-- REQUEST(TYPE=GENERIC MESSAGE="Enter your password
           followed by your pin number" NAME="" PASSWORD="" REQ_NUM=2)
   REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar0985124") -->
                                                    <-- 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:




R. Pereira, S. Beaulieu                                       [Page 5]


Internet Draft                                                  May-99

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



2.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(TYPE=GENERIC NAME=""
                                             PASSWORD="" PASSCODE="")
   REPLY(TYPE=GENERIC 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(TYPE=GENERIC NAME=""
                                              PASSWORD="" PASSCODE="")
   REPLY(TYPE=GENERIC NAME="joe"
    PASSWORD="foobar" PASSCODE="323415") -->
                          <-- REQUEST(TYPE=GENERIC NAME="" PASSWORD=""
                                                PASSCODE="" REQ_NUM=2)
   REPLY(TYPE=GENERIC NAME="joe"
    PASSWORD="foobar" PASSCODE="513212") -->
                                                    <-- SET(STATUS=OK)
   ACK(STATUS) -->














R. Pereira, S. Beaulieu                                       [Page 6]


Internet Draft                                                  May-99

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

   IPSec Host                                              Edge Device
   --------------                                    -----------------
                   <-- 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) -->


2.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.  The edge device is not sure who the peer is
   because the phase 1 ID is not transmitted until after the proposal
   payloads are exchange.  In this case, the peers may agree to do
   XAUTH even though the remote user still has a valid XAUTH
   authentication.  In such a scenario, this method MAY be used to
   avoid prompting the user.  Edge devices MUST NOT use this
   authentication method in cases where the phase 1 ID does not match
   the previous phase 1 ID.

   In these situations, the following method is used.

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





3  Extensions to ISAKMP-Config

   This protocol uses the mechanisms described in ISAKMP-Config
   [IKECFG] to accomplish its authentication transaction.

   All ISAKMP-Config messages in an extended authentication
   transaction MUST contain the same ISAKMP-Config message ID.

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



R. Pereira, S. Beaulieu                                       [Page 7]


Internet Draft                                                  May-99

   If mutual authentication is not required, then the phase 1
   negotiation MAY use an authentication method of shared-secret and
   have that shared-secret be null.  However, this is STRONGLY
   DISCOURAGED since the edge-device is NOT authenticated.  See the
   Security Considerations section for more detail.

   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.

   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 with initiating a new phase 1 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.


3.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] )

   o 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.

   o ISAKMP_CFG_REPLY - This message MUST contain the filled in
     authentication attributes that were requested by the edge device.

   o 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.

   o ISAKMP_CFG_ACK - This message is sent from the IPSec host


R. Pereira, S. Beaulieu                                       [Page 8]


Internet Draft                                                  May-99

     acknowledging receipt of the authentication result.  Its
     attributes are not relevant and MAY be skipped entirely, thus not
     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.



3.2 Attributes


    Attribute                 Value      Type
    ---------------------     ------     ---------------------
    XAUTH_TYPE                13         Basic
    XAUTH_USER_NAME           14         Variable ASCII string
    XAUTH_USER_PASSWORD       15         Variable ASCII string
    XAUTH_PASSCODE            16         Variable ASCII string
    XAUTH_MESSAGE             17         Variable ASCII string
    XAUTH_CHALLENGE           18         Variable ASCII string
    XAUTH_DOMAIN              19         Variable ASCII string
    XAUTH_STATUS              20         Basic
    XAUTH_REQ_NUMBER          21         Basic

   o XAUTH_TYPE - The type of extended authentication requested whose
     values are described in the next section.  This is a mandatory
     attribute for the ISAKMP_CFG_REQUEST and ISAKMP_CFG_REPLY
     messages.

   o 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.

   o XAUTH_USER_PASSWORD - The user's password.

   o XAUTH_PASSCODE - A token card's passcode.  This SHOULD only be
     used when the password attribute is also used.

   o 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.

   o 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 uses the challenge to hide the password.


R. Pereira, S. Beaulieu                                       [Page 9]


Internet Draft                                                  May-99

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

   o XAUTH_STATUS - A variable that is used to denote authentication
     success (OK=1) or failure (FAIL=0).  This is a mandatory
     attribute for the ISAKMP_CFG_SET message.

   o XAUTH_REQ_NUMBER - The number of times that a request has been
     made, including the current request.  The default value is one
     (1) and thus does not have to be included.  This attribute is
     used to denote that an authentication transaction has had to have
     another authentication request.  The IPSec host should notice
     that this is not a retransmit of the original request, but that
     this is yet another request.  This attribute MUST only be
     included in the ISAKMP_CFG_REQUEST message.



3.3 Authentication Types

     Value         Authentication Required
     -----         ---------------------------------
       0           Generic
       1           RADIUS
       2           OTP
       3           NT Domain
       4           Unix Login
       5           SDI SecurID
       6           AXENT Defender
       7           LeeMah InfoCard
       8           ActiveCard
       9           Secure Computing Enigma (DES Gold)
      10           TACACS
      11           TACACS+
      12           S/KEY
      13           NDS (Netware Directory Services)
      14           DIAMETER
      15           LDAP
      16-32767     Reserved for future use
      32768-65535  Reserved for private use

   o 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.

   o RADIUS - A RADIUS [RADIUS] server requires at least a user name
     and a password, but since RADIUS may be proxying for another type
     of authentication method, both the request and the reply MAY be


R. Pereira, S. Beaulieu                                      [Page 10]


Internet Draft                                                  May-99

     like any of the other extended authentication types.

   o 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].

   o NT Domain - This authentication type provides for user
     authentication by login into a Windows NT(r) domain.  The request
     SHOULD contain empty user name, password and domain attributes.
     The reply MUST contain all of these attributes filled in.  The
     domain attribute is optional for both messages, and SHOULD NOT be
     included in the reply if it isnÆt included in the request.

   o Unix Login - Much like the NT Domain authentication type, but
     this will authenticate the user to a Unix(r) workstation.

   o SDI SecurID, AXENT Defender, LeeMah InfoCard, ActiceCard,
     Enigma/DES Gold - All of these (and others) use smart cards to
     generate a 'passcode' to authenticate the user.  This passcode
     combined with the user's password provides stronger
     authentication than just passwords.  The response MUST include
     the user name, password and the token card's passcode. This
     authentication type MIGHT also include a challenge string in the
     request.

   o TACACS - Defined in [TACACS], this authentication protocol was
     the precursor to RADIUS, thus the same rules apply.

   o TACACS+ - Defined in [TACACS+], this authentication protocol is
     an updated version of the original TACACS protocol, thus the same
     rules apply.

   o S/KEY - This one-time-password scheme defined in [SKEY] was the
     precursor to OTP, thus the same rules applies.

   o NDS - Much like the NT Domain authentication type, but this will
     authenticate the user to a NetWare Directory server.

   o DIAMETER - The next generation RADIUS protocol that is defined in
     [DIAMETER].  The same rules as RADIUS apply.



4  Authentication Method Types

   The following values relate to the ISAKMP authentication method
   attribute used in proposals.  They optionally allow an XAUTH
   implementation to propose use of extended authentication after the


R. Pereira, S. Beaulieu                                      [Page 11]


Internet Draft                                                  May-99

   initial phase 1 authentication.  Values are taken from the private
   use range defined in [IKE] and should be used among mutually
   consenting parties.

    Method                                            Value
   ------------------------------                     -----
    XAUTHInitPreShared                                65001
    XAUTHRespPreShared                                65002
    XAUTHInitDSS                                      65003
    XAUTHRespDSS                                      65004
    XAUTHInitRSA                                      65005
    XAUTHRespRSA                                      65006
    XAUTHInitRSAEncryption                            65007
    XAUTHRespRSAEncryption                            65008
    XAUTHInitRSARevisedEncryption                     65009
    XAUTHRespRSARevisedEncryption                     65010


   An Extended Authentication proposal has two characteristics.

   The first is the direction of the authentication.  Each type
   identifies whether the Initiator or the Resonder is the device
   which should be authenticated using XAUTH.  For example
   XAUTHInitPreShared is a type which demands that the Initiator be
   authenticated.

   Note that an edge device would typically initiate with one of the
   following:
   o XAUTHRespPreShared
   o XAUTHRespDSS
   o XAUTHRespRSA
   o XAUTHRespRSAEncryption
   o XAUTHRespRSARevisedEncryption

   and would typically only accept proposals with the following
   authentication methods:
   o XAUTHInitPreShared
   o XAUTHInitDSS
   o XAUTHInitRSA
   o XAUTHInitRSAEncryption
   o XAUTHInitRSARevisedEncryption

   The second characteristic is the IKE Authentication method to be
   used.  The following table illustrates which keywords in the
   methods described above relate to which Authentication Methods
   described in [IKE] Appendix A.





R. Pereira, S. Beaulieu                                      [Page 12]


Internet Draft                                                  May-99

   "PreShared"            -> pre-shared key
   "DSS"                  -> DSS signatures
   "RSA"                  -> RSA signatures
   "RSAEncryption"        -> Encryption with RSA
   "RSARevisedEncryption" -> Revised encryption with RSA



5  Other Scenarios for Extended Authentication

   Although this document described a scenario where an IPSec host
   (eg. mobile user) was being authenticated by an edge device (eg.
   firewall/gateway), the methods described can also be used for edge
   device to edge device authentication as well as IPSec host to IPSec
   host authentication.


6  Security Considerations

   Care should be taken when sending sensitive information over public
   networks such as the Internet.  A user's password should never be
   sent in the clear and when sent encrypted, the destination MUST
   have been previously authenticated.  The use of ISAKMP-Config
   [IKECFG] addresses these issues.

   The use of Extended Authentication does not imply that phase 1
   authentication is no longer needed. Phase 1 authentication provides
   a higher level of user authentication by signing ISAKMP packets.
   Extended Authentication does not provide this service.  The removal
   of phase 1 authentication would leave the IPSec session vulnerable
   to a man-in-the-middle attack and other spoofing attacks.


7  References

   [Bradner97]    S. Bradner, "Key words for use in RFCs to Indicate
                  Requirement Levels", RFC2119

   [CHAP]         W. Simpson, "PPP Challenge Handshake Authentication
                  Protocol (CHAP)", RFC1994

   [DIAMETER]     P. Calhoun, A. Rubens, "DIAMETER - Base Protocol",
                  draft-calhoun-diameter-02.txt

   [HYBRID]       M. Litvin, R. Shamir, T. Zegman, "A Hybrid
                  Authentication Mode for IKE", draft-ietf-ipsec-
                  isakmp-hybrid-auth-01

   [IKE]          D. Harkins, D. Carrel, "The Internet Key Exchange
                  (IKE)", RFC2409




R. Pereira, S. Beaulieu                                      [Page 13]


Internet Draft                                                  May-99

   [IKECFG]       R. Pereira, "The ISAKMP Configuration Method",
                  draft-ietf-ipsec-isakmp-cfg-03

   [RADIUS]       C. Rigney, A. Rubens, W. Simpson, S. Willens,
                  "Remote Authentication Dial In User Service
                  (RADIUS)", RFC2138

   [OTP]          N. Haller, C. Metz, "A One-Time Password System",
                  RFC1938

   [SKEY]         N. Haller, "The S/KEY One-Time Password System",
                  RFC1760

   [TACACS]       C. Finseth, "An Access Control Protocol, Sometimes
                  Called TACACS", RFC1492

   [TACACS+]      D. Carrel, L. Grant, "The TACACS+ Protocol Version
                  1.77", draft-grant-tacacs-01.txt

   [OTPEXT]       C. Metz, "OTP Extended Responses", RFC 2243


8  Acknowledgements

   The internet-draft "A Hybrid Authentication Mode for IKE" <draft-
   ietf-ipsec-isakmp-hybrid-auth-01.txt> helped us further enhance
   this specification.  The concept of using new Authentication Method
   identifiers in the SA payload in order to accomplish extended
   authentication originated in the [HYBRID] draft.























R. Pereira, S. Beaulieu                                      [Page 14]


Internet Draft                                                  May-99

9  Authors' Addresses

     Roy Pereira
     <rpereira@timestep.com>
     TimeStep Corporation
     +1 (613) 599-3610 x 4808

     Stephane Beaulieu
     <sbeaulieu@timestep.com>
     TimeStep Corporation
     +1 (613) 599-3610 x 4709


   The IPSec working group can be contacted via the IPSec working
   group's mailing list (ipsec@tis.com) or through its chairs:

     Robert Moskowitz
     rgm@icsa.net
     Internal Computer Security Association

     Theodore Y. Ts'o
     tytso@MIT.EDU
     Massachusetts Institute of Technology


10 Expiration

    This draft expires November 17, 1999


11 Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain
   it or assist in its implementation may be prepared, copied,
   published and distributed, in whole or in part, without restriction
   of any kind, provided that the above copyright notice and this
   paragraph are included on all such copies and derivative works.
   However, this document itself may not be modified in any way, such
   as by removing the copyright notice or references to the Internet
   Society or other Internet organizations, except as needed for the
   purpose of developing Internet standards in which case the
   procedures for copyrights defined in the Internet Standards process
   must be followed, or as required to translate it into languages
   other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.




R. Pereira, S. Beaulieu                                      [Page 15]


Internet Draft                                                  May-99

   This document and the information contained herein is provided on
   an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.













































R. Pereira, S. Beaulieu                                      [Page 16]