Internet Engineering Task Force R. Pereira
IP Security Working Group TimeStep Corporation
Internet Draft
Expires in six months
May 13, 1998
Extended Authentication Within ISAKMP/Oakley
<draft-ietf-ipsec-isakmp-xauth-02.txt>
Status of this Memo
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@tis.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."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern 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). All Rights Reserved.
Abstract
This document describes a method for using existing unidirectional
authentication mechanisms such as RADIUS, SecurID, and OTP within
IPSec's ISAKMP protocol.
R. Pereira [Page 1]
Internet Draft May-98
Table of Contents
1. Introduction...................................................2
1.1 Extended Authentication.....................................2
1.2 Reader Prerequisites........................................3
1.3 Specification of Requirements...............................3
2. Extended Authentication Method.................................3
2.1 Simple Authentication.......................................4
2.2 Challenge/Response..........................................4
2.3 Two-Factor Authentication...................................4
2.4 One-Time-Password...........................................5
3. Extensions to ISAKMP-Config....................................5
3.1 Message Types...............................................5
3.2 Attributes..................................................6
3.3 Authentication Types........................................7
4. Security Considerations........................................8
5. References.....................................................8
6. Editor's Address...............................................9
7. Full Copyright Statement......................................10
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.
1.1 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
R. Pereira [Page 2]
Internet Draft May-98
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.2 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 of it.
1.3 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 is simply a reply back from the edge device
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 the user.
As with CHAP [CHAP], this protocol can also be used to periodically
authenticate the user during the lifetime of a security
association.
If the client does not have support for the authentication method
requested by the edge device, then it would send back a reply with
R. Pereira [Page 3]
Internet Draft May-98
empty attributes, thus failing the authentication but completing
the transaction.
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(RADIUS NAME PASSWORD)
REPLY(RADIUS NAME PASSWORD) -->
<-- AUTH-OK()
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(RADIUS CHALLENGE NAME PASSWORD)
REPLY(RADIUS NAME PASSWORD) -->
<-- AUTH-OK()
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(SECURID NAME PASSWORD PASSCODE)
REPLY(SECURID NAME PASSWORD PASSCODE) -->
<-- AUTH-OK()
Some mechanisms allow for another request of the passcode.
IPSec Host Edge Device
-------------- -----------------
<-- REQUEST(SECURID NAME PASSWORD PASSCODE)
REPLY(SECURID NAME PASSWORD PASSCODE) -->
<-- REQUEST(SECURID NAME PASSWORD PASSCODE)
REPLY(SECURID NAME PASSWORD PASSCODE) -->
<-- AUTH-OK()
R. Pereira [Page 4]
Internet Draft May-98
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(OTP CHALLENGE NAME PASSWORD)
REPLY(OTP NAME PASSWORD) -->
<-- AUTH-OK()
3. Extensions to ISAKMP-Config
This protocol uses the mechanisms described in ISAKMP-Config
[IKECFG] to accomplish its request/reply transaction through
ISAKMP.
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 SHOULD use an authentication method of shared-secret
and have that shared-secret be null. This, is however, NOT
suggested since the edge-device is NOT authenticated.
This authentication MUST be used after a phase 1 exchange has
completed and before a phase 2 exchange. The Transaction exchange
is therefore attached (appended) to the phase 1 exchanges
(MainMode, AggressiveMode). If the extended authentication fails,
then the phase 1 SA MUST be deleted.
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_AUTH_OK 5
ISAKMP_CFG_AUTH_FAILED 6
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
R. Pereira [Page 5]
Internet Draft May-98
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_AUTH_OK - This message MAY contain a textual message
in the XAUTH_MESSAGE attribute.
o ISAKMP_CFG_AUTH_FAILED - This message MAY contain a textual
message in the XAUTH_MESSAGE attribute.
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
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. This message MAY be displayed to the user to notify
them of the reason why authentication failed or succeed.
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 or passcode. This attribute SHOULD only be sent in an
ISAKMP_CFG_REQUEST message.
R. Pereira [Page 6]
Internet Draft May-98
o XAUTH_DOMAIN - The domain to be authenticated in. This value
will have different meaning depending on the authentication
type.
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-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.
o RADIUS - A RADIUS [RADIUS] server requires 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
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,
R. Pereira [Page 7]
Internet Draft May-98
and SHOULD NOT be included in the reply if it isnt 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, user 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 apply.
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. 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.
5. 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
R. Pereira [Page 8]
Internet Draft May-98
[DIAMETER] P. Calhoun, A. Rubens, "DIAMETER - Base Protocol",
draft-calhoun-diameter-02.txt
[IKE] D. Harkins, D. Carrel, "The Internet Key Exchange
(IKE)", draft-ietf-ipsec-isakmp-oakley-07
[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
6. Editor's Address
Roy Pereira
<rpereira@timestep.com>
TimeStep Corporation
+1 (613) 599-3610 x 4808
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
R. Pereira [Page 9]
Internet Draft May-98
7. 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.
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 [Page 10]
