Internet Engineering Task Force R. Pereira
IP Security Working Group S. Beaulieu
Internet Draft TimeStep Corporation
Expires March 1, 2000
September 1, 1999
Extended Authentication within ISAKMP/Oakley
<draft-ietf-ipsec-isakmp-xauth-05.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 (IPSEC) 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 Sep-99
Abstract
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.
Table of Contents
1 Introduction.......................................................2
1.1 Changes Since Last Revision......................................3
1.2 Extended Authentication..........................................3
1.3 Reader Prerequisites.............................................4
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
2.6 Other Useful Examples............................................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
Appendix A..........................................................17
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.
R. Pereira, S. Beaulieu [Page 2]
Internet Draft Sep-99
These authentication mechanisms have a large deployment in remote
access applications and many IT departments have requirements for
these unidirectional authentication mechanisms.
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-04.txt>
o Added text which allows multiple authentication mechanisms to be
used within one XAUTH transaction.
o Added examples of RADIUS CHAP, and Secure ID next PIN mode in
Appendix A
o Added text which describes how to retry if a userÆs input fails
to be authenticated.
o The ISAKMP Message ID now follows the rules defined by the
ISAKMP-Config draft.
o XAUTH_REQ_NUMBER has been removed
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.
R. Pereira, S. Beaulieu [Page 3]
Internet Draft Sep-99
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.
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.
R. Pereira, S. Beaulieu [Page 4]
Internet Draft Sep-99
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 each other via the authentication
methods described in [IKE].
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="")
REPLY(TYPE=GENERIC NAME="joe" PASSWORD="foobar0985124") -->
<-- SET(STATUS=OK)
R. Pereira, S. Beaulieu [Page 5]
Internet Draft Sep-99
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(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="")
REPLY(TYPE=GENERIC NAME="joe"
PASSWORD="foobar" PASSCODE="513212") -->
<-- SET(STATUS=OK)
ACK(STATUS) -->
R. Pereira, S. Beaulieu [Page 6]
Internet Draft Sep-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) -->
2.6 Other Useful Examples
More useful examples are found in Appendix A.
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 transaction
identifier. The Message ID in the ISAKMP header follows the rules
defined by the ISAKMP-Config protocol.
R. Pereira, S. Beaulieu [Page 7]
Internet Draft Sep-99
This protocol can therefore be used in conjunction with any
existing basic ISAKMP authentication method as defined in [IKE].
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. 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.
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.
R. Pereira, S. Beaulieu [Page 8]
Internet Draft Sep-99
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
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.
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
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. The XAUTH_TYPE in a REPLY MUST be identical to the
XAUTH_TYPE in the REQUEST. However, an XAUTH transaction MAY
have multiple REQUEST/REPLY pairs with different XAUTH_TYPE
values in each pair.
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
R. Pereira, S. Beaulieu [Page 9]
Internet Draft Sep-99
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.
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.
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
R. Pereira, S. Beaulieu [Page 10]
Internet Draft Sep-99
of authentication method, both the request and the reply MAY be
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
R. Pereira, S. Beaulieu [Page 11]
Internet Draft Sep-99
implementation to propose use of extended authentication after the
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 Sep-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
or weakening of phase 1 authentication would leave the IPSec
session vulnerable to a man-in-the-middle attack and other spoofing
attacks. Therefore, when using Extended Authentication with Pre-
Shared keys, it is vital that the Pre-Shared key be well chosen and
secure.
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
R. Pereira, S. Beaulieu [Page 13]
Internet Draft Sep-99
[IKE] D. Harkins, D. Carrel, "The Internet Key Exchange
(IKE)", RFC2409
[IKECFG] R. Pereira, "The ISAKMP Configuration Method",
draft-ietf-ipsec-isakmp-cfg-05
[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 Sep-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@lists.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 March 1, 2000
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 Sep-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]
Internet Draft Sep-99
Appendix A
This appendix gives more useful examples of Extended
Authentication.
Secure ID Next PIN mode
=======================
Ipsec Client Ipsec Gateway
------------ -------------
<-- REQUEST(TYPE = Generic, Username = '', Passcode = '')
REPLY(TYPE = Generic, Username = 'joe',
Passcode = '1637364856') -->
<-- REQUEST(TYPE = Generic, Username = '', Password = '',
XAUTH_MESSAGE = 'The system has assigned you a new
PIN, do you wish to see it now?')
REPLY(TYPE = Generic, Username = 'joe', Password = 'y') -->
<-- REQUEST(TYPE = Generic, Username = '', XAUTH_MESSAGE
= 'Your new pin is 1234'
REPLY(TYPE = Generic, Username = 'joe',
Passcode = '1234764456') -->
<-- SET(XAUTH_STATUS = OK)
ACK(XAUTH_STATUS) -->
RADIUS Chap Challenge
=====================
Ipsec Client Ipsec Gateway
------------ -------------
<-- REQUEST(TYPE = RADIUS, Username = '', Password = '',
Challenge = 0x01020304050607080910111213141516)
REPLY(TYPE = RADIUS, Username = 'joe', Password =
'0xaa11121314151617181920212223242526') -->
<-- SET(XAUTH_STATUS = OK)
ACK(XAUTH_STATUS) -->
where the Challenge in the REQUEST is the random number generated
by the edge device, and the Password in the reply contains the ID
used to calculate the hash 'aa' concatenated with the hash of the
(ID+challenge+secret)
R. Pereira, S. Beaulieu [Page 17]
